소비자 앱에서 성능이 저하되는 원인은 무엇입니까? [닫은]

내 Comcast DVR 은 모든 리모컨 키 누름에 응답하는 데 최소 3 초가 걸리므로 텔레비전을 보는 간단한 작업이 좌절스러운 버튼 매쉬 경험으로 만들어집니다. 내 iPhone은 문자 메시지를 표시하는 데 최소 15 초가 걸리고 iPod 앱을 불러 오려고 할 때의 1/4이 충돌합니다. 단순히 이메일을 받고 읽는 데 1 분 이상이 걸립니다. 내 차의 navcom조차도 흐릿하고 반응이 좋지 않은 컨트롤을 가지고 있으며, 몇 초 미만으로두면 연속적인 입력을 삼키는 경우가 많습니다.

이것들은 사용성이 가장 중요한 고정 하드웨어 최종 소비자 가전 제품이지만 기본 응답 성과 대기 시간에는 모두 실패합니다. 그들의 소프트웨어는 너무 느립니다 .

이 뒤에 무엇입니까? 기술적 인 문제입니까, 아니면 사회적 문제입니까? 누가 또는 무엇을 책임 지는가?

이것들은 모두 네이티브 코드가 아닌 관리되고 가비지 수집 언어로 작성 되었기 때문입니까? 이러한 장치 용 소프트웨어를 작성한 사람은 개별 프로그래머입니까? 이 모든 경우에 앱 개발자는 대상으로하는 하드웨어 플랫폼과 기능을 정확히 알고있었습니다. 그들은 그것을 고려하지 않았습니까? "최적화는 모든 악의 뿌리"를 되풀이하는 사람인가? 모든 밀리 초가 몇 분이 될 때까지 매번 "아, 그것은 단지 100ms에 불과하다"는 생각인가? 이 제품들을 처음 구입 한 것이 내 잘못입니까?

그것은 어떤 점에서 때 분명히 "성능이 중요하지 않습니다, 오, 코드 속도에 대해 걱정하지 마십시오"이없이 하나의 답과 주관적인 질문이지만, 나는 종종 말을 여기에 많은 답변을보고 좌절하고있어 않습니다 에 대한 문제 느리고 응답이없고 끔찍한 경험에 갇힌 최종 사용자.

그렇다면 어떤 시점에서 이러한 제품에 문제가 발생 했습니까? 프로그래머가 우리 고객에게이 고통을 피하기 위해 무엇을 할 수 있습니까?

좋은 질문. 내가 매일 보는 것은 이것입니다.

사람들은 좋은 크기의 앱에서 일합니다. 작동하면서 버그와 마찬가지로 성능 문제가 발생합니다. 차이점은-버그는 "나쁜"- "나를 찾아서 고쳐줘"라는 외침입니다. 성능 문제는 단지 거기에 앉아 악화됩니다. 프로그래머들은 종종 " 내 코드에는 성능 문제가 없을 것입니다. 오히려 경영진이 새로운 / 더 큰 / 빠른 기계를 구입해야합니다."라고 말합니다.

사실 개발자가 주기적으로 성능 문제 (실제로는 매우 쉬운 )를 찾기 만하면 문제를 간단히 해결할 수 있습니다.

대신 "최신 상태"는 다음과 같습니다.

1. "초기 최적화 최적화"및 90/10 hoo-haw와 같은 격언에 의존합니다.
2. 프로파일 링에 대해 용감하게 이야기하고 때로는 모든 결과에 대한 SO 질문에서 볼 수 있듯이 종종 실망스러운 결과로 시도하십시오.
3. 경험과 지식으로 위장한 좋은 추측으로 되돌아갑니다.

그러나 실제로는 부정적입니다. 긍정적으로, 이 방법 은 거의 항상 작동하며 더 간단 할 수는 없습니다. 자세한 예 는 다음과 같습니다 .

이것은 기술적 인 문제가 아니라 마케팅 및 관리 문제입니다.

이 시점에서 눈을 돌리고 있을지 모르지만 제발 참아주세요.

회사가 판매하는 것은 "제품"이며, "제품 관리자"를 정의하는 사람들입니다. 기술 회사에서는 다른 많은 사람들이 사용자 경험 전문가 인 yadda yadda에 무게를 둡니다. 그러나 궁극적으로 제품 관리자는 사용자가 얻는 것에 대한 사양을 작성해야합니다.

컴캐스트 DVR을 보자. 이상적으로는 다음과 같이 작동합니다.

1. 제품 관리자는 "사용자가 리모콘의 버튼을 눌렀을 때 DVR에서 25 피트 이내에 있으면 DVR이 250 밀리 초 이내에 프레스에 응답해야합니다"라는 사양에 기록합니다.
2. 기술 담당자는 하드웨어를 구축하고 내장 소프트웨어를 작성하는 등
3. QA 테스터는 시스템이 사양을 충족 함을 승인하거나 수정을 위해 기술 팀에 반송합니다.

물론 많은 일들이 잘못 될 수 있습니다.

• 제품 관리자가 사양에 버튼 응답을 넣지 못했습니다
• 품질 관리 담당자는 사양에 대해 평범한 테스트 작업을 수행합니다.
• 누군가 스펙을 충족시키지 못하는 기술을 선택하여 요구 사항을 충족시키지 못했습니다.
• 기술 직원이 부족하거나 일정을 단축 한 사람이 있으며 일부 관리자는 "응답을 잊어 버리십시오.이 다른 기능은 완료하십시오"라고 말합니다.
• 제품 관리자는 게임 늦게까지 응답 성 요구 사항을 게시하지 않습니다. 출시 날짜까지는 충족 할 수 없습니다.
• 경영진은 늦게까지 QA 테스트를 위해 아무것도 제출하지 않기로 결정하고 느린 코드를 가속화하면 제품이 불안정해질 수 있습니다

거기에 모든 펙리스 프로그래머가 있습니까? 없었습니다.

나쁜 성능에 대해서는 전혀 책임을지지 않습니다. 종종 정크를 쓰는 것만 큼 강력하고 효율적인 코드를 작성하는 것이 쉽고 빠릅니다.

그러나 실제로 제품 관리 및 QA 직원이 모두 잠 들어 있으면 프로그래머는이를 보완 할 수 없습니다.

FWIW, 나는 대부분의 소비자 제품의 끔찍한 인터페이스에 전적으로 동의합니다. 저는 약 25 년간 UI 코드를 작성해 왔으며 우아함과 단순함을 위해 노력하고 있습니다. 실제로 너무 많이 생각하기 때문에 문제가됩니다. 잘못 디자인 된 사용자 인터페이스를 파악하는 데 어려움을 겪기 때문에 가난한 아내는 미디어 센터에서 대부분의 장치를 실행합니다.

프로그래머가 완벽하지 않기 때문입니다.

나는 임베디드 것들의 프로그래머입니다. 내 코드 중 일부가 완벽하지 않습니다. 내 임베디드 코드의 대부분은 빠릅니다.

프로젝트 종료시 성능 문제를 해결하는 것은 매우 어렵습니다.

때때로, 일을 단순하게 유지하기 위해 (심지어 버그가 아닌 실제적인 시간에 테스트 가능하고 개발 가능한 테스트 가능) 메인 애플리케이션의 일부가 아닌 "서비스"에 대한 원격 입력과 같은 것들을 계층화합니다. 최종 결과, 대기 시간. 대안은 모 놀리 식 응용 프로그램에 모든 것을 넣는 것이 C 또는 C ++ (두 가지 가장 일반적인 임베디드 언어)의 버그 재앙입니다.

때때로 임베디드 장치에는 사용자가 원하는 것을하지 않는 프로세스 스케줄러가 있습니다. 임베디드 개발자로 고치기가 어렵습니다.

계층화로 인한 대기 시간으로 인해 복잡성으로 인해 지연이 발생합니다. 기능을 요청했습니다. 오래된 3210과 같은 정말 오래된 Nokia를 사용해보십시오. Zippy fast UI. 많은 기능이 없습니다.

개발자가 더 똑똑하지 않기 때문에 기능이 서로를 죽이는 것을 방지하기 위해 더 빠른 하드웨어가 추상화에 흡수됩니다. (또는 iPhone의 경우가 아닙니다)

디자인이 진행됨에 따라 UI 성능을 테스트해야합니다.

지정하지 않으면 개발자가 익숙해집니다. 우리 모두이 일을합니다. "내 아기는 못 생겼어"

그리고 그것은 GC 언어가 아닙니다. 임베디드 Realtime Java는 매우 빠르다. (반면 임베디드 파이썬은 총 개입니다)

디지털 입력의 읽기 스위치를 UI로 프로그램을 작성합니다. 여전히 바운스 해제를해야하는데, 바운스 해제는 몇 층으로되어 있기 때문에 스위치를 빠르게 빠르게 튕기는 것은 효과가 없습니다. 이상적으로 펌웨어 스택의 맨 아래에 디 바운스 로직이 있었지만 하드웨어가 작동하는 방식은 아닙니다.

일부 DVD 플레이어는 "꺼내기"스크립트를 실행하여 꺼내기 만합니다. DVR은 개발 비용을 제고하기 위해 이러한 접근 방식을 취했을 수 있습니다. 그런 다음 CPU 또는 RAM을 건너 뛰고 빨라집니다.

이것들은 모두 네이티브 코드가 아닌 관리되고 가비지 수집 언어로 작성 되었기 때문입니까?

아니요. 느린 코드는 관계없이 제대로 작동하지 않습니다. 물론, 특정 언어는 다른 문제를 해결하면서 특정 부류의 문제를 일으킬 수 있습니다. 그러나 좋은 프로그래머는 충분한 시간이 주어지면 해결 방법을 찾을 수 있습니다.

이러한 장치 용 소프트웨어를 작성한 사람은 개별 프로그래머입니까?

부분적으로 대부분의 경우 최소한 기여 요인 일 가능성이 높습니다. 이것은 좋은 프로그래머가 수요가 많고 공급이 부족한 산업의 불행한 부작용입니다. 또한 다양한 수준의 기술적 능력 사이의만이 상당히 클 수 있습니다. 따라서 때로는 특정 소프트웨어를 구현하려는 프로그래머가 소프트웨어 를 작동시키기 만하면 축하받을 수 있다고 생각 합니다.

이 모든 경우에 앱 개발자는 대상으로하는 하드웨어 플랫폼과 기능을 정확히 알고있었습니다. 그들은 그것을 고려하지 않았습니까?

부분적으로 처음에는 정확한 하드웨어 플랫폼이 알려져 있지 않을 것입니다. 소프트웨어 개발 중에 여러 제조업체와 병렬로 협상되기도합니다. 실제로 초기 릴리스 이후 기본 하드웨어에 대한 변경은 적을 수도 있지만 반드시 중요하지는 않습니다. 그러나 일반적인 기능을 알고 있다는 데 동의합니다.

문제의 일부는 소프트웨어가 하드웨어에서 개발되지 않았으며 에뮬레이터에서 수행된다는 것입니다. 이로 인해 에뮬레이터가 100 % 정확하더라도 실제 장치 성능을 설명하기가 어렵습니다.

물론 이것은 출시 전에 적절한 프로토 타입 하드웨어에 대한 테스트가 불충분하다는 것을 실제로 정당화하지는 않습니다. 그 책임은 아마도 dev / qa 컨트롤 외부에 있습니다.

"최적화는 모든 악의 뿌리"를 되풀이하는 사람인가?

아니, 나는 그들이 어쨌든 그를 듣지 않는다고 확신한다. 그렇지 않으면 그는 너무 자주 인용되지 않을 것입니다 ( " 초기 최적화 ..."로 가정). :-디

너무 많은 프로그래머가 최적화와 관련하여 두 가지 극단 중 하나를 취할 가능성이 큽니다.

• 그들은 그것을 완전히 무시합니다.
• 또는 실제 성능 요구 사항 과 아무 관련이없는 미세한 부분에 집착합니다 . 실제 예산 문제가 발생 하고 실제 성능 문제를 안전하게 최적화하기에는 코드가 난독 화되는 결과가 초래됩니다 .

모든 밀리 초가 몇 분이 될 때까지 매번 "아, 그것은 단지 100ms에 불과하다"는 생각인가?

혹시. 분명히 Sleep(100)사지의 출혈을 늦추는 데 사용되는 티슈 페이퍼와 동등한 것으로 사용 된 경우 문제가 예상됩니다. 그러나 문제가 그보다 미묘하다고 생각합니다.

문제는 현대 컴퓨팅 하드웨어 (내장 장치 포함)가 사람들이 인정하는 것보다 훨씬 빠릅니다. "경험이 풍부한"프로그래머조차 대부분의 컴퓨터가 얼마나 빠른지 이해하지 못합니다. 100ms는 매우 오랜 시간 입니다. 그렇게되면서이 "매우 오랜 시간"은 두 가지 방법을 삭감합니다.

• 첫 번째는 프로그래머가 컴퓨터가하는 일에 대해 불필요하게 걱정한다는 것입니다. (이것은 처음에 나를 여기로 이끌었던 " 초당 300 번씩 값을 증가시키는 것 "과 같은 문제였습니다 .)
• 두 번째는 시간이 오래 걸리는 경우 (컴퓨팅 타임 스케일에서) 때때로 우려를 표시하지 못하는 것입니다. 그래서:
  • 네트워크를 통해 또는 저장 장치와 통신 할 때 대기 시간의 영향을 무시하는 경우
  • 스레드가 차단되어 다른 스레드를 기다리는 영향을 무시하는 경우
  • 컴퓨터가 너무 빨리 작동하기 때문에 개발자가 문제를 인식하지 않고도 작업을 훨씬 더 자주 반복 할 수 있다는 사실을 잊어 버린 경우
  • ... 이러한 감독의 조합이 발생하면 계산 시간에 따라 루틴이 예기치 않게 매우 느리게 실행됩니다. 몇 번의 반복으로 인간은 눈에 띄게 될 것입니다. 그러나 수백 개의 상호 연결된 것들이 모두 빠르게 실행되기 때문에 고정하기가 까다로울 수 있습니다.

이 제품들을 처음 구입 한 것이 내 잘못입니까?

네 물론 이죠 글쎄, 당신은 개인적으로가 아니라 소비자입니다. 기능 점검표별로 제품을 판매 (및 구매 )합니다. 더 나은 성능을 요구하는 소비자는 거의 없습니다.

요점을 설명하기 위해 : 마지막으로 휴대 전화를 사고 싶을 때 매장에서는 매장 내에서 재생할 데모 모델을 제공조차 할 수 없었습니다. 그들은 화면이 어떻게 보일지 보여주기 위해 스티커가 달린 플라스틱 껍질 만 가지고있었습니다. 성능이나 유용성뿐만 아니라 무게에 대한 느낌조차 얻을 수 없습니다. 내 요점은 충분한 사람들이 해당 비즈니스 모델에 반대 하고 지갑 으로 투표하여 반대 의견을 표명한다면 올바른 방향으로 나아가는 작은 발걸음이 될 것입니다.

그러나 그들은 그렇지 않으므로 우리는 그렇지 않습니다. 매년 새로운 휴대 전화는 더 빠른 하드웨어에서 더 느리게 실행됩니다.

(질문은 없습니다.)

• 마케팅 담당자가 책임을 져야합니까? 부분적으로 출시일이 필요합니다. 그리고 데이트가 시작될 때 "작동"과 "더 빠르게"사이에서 선택하는 것은 쉬운 일이 아닙니다.
• 영업 사원이 책임을 져야합니까? 부분적으로 그들은 체크리스트에 더 많은 기능을 원합니다. 기능 목록을 과장하고 성능을 무시합니다. 그들은 (때로는) 비현실적인 약속을합니다.
• 관리자가 책임을 져야 하는가? 부분적으로 경험이 부족한 관리자는 많은 실수를 할 수 있지만, 경험이 많은 관리자조차도 다른 문제에 유리하게 성능 문제를 해결하기 위해 시간을 희생 할 수 있습니다.
• 사양은 비난입니까? 부분적으로 무언가가 사양을 벗어나면 나중에 "잊어 버리는"것이 훨씬 쉽습니다. 구체적으로 언급되지 않은 경우 목표는 무엇입니까? (개인적으로 팀이 업무에 자부심을 가지면 성과에 관계없이 걱정할 것입니다.)
• 교육은 비난받을 것인가? 아마도. 교육은 아마도 항상 뒷발에있을 것입니다. 나는 피상적 인 이해 소프트웨어 개발로 초보자를 신속하게 기르는 "교육"에 대해 분명히 반대한다. 그러나 이론으로 뒷받침되고 학습 문화를 심어주는 교육은 나쁘지 않습니다.
• 업그레이드가 책임이 있습니까? 부분적으로 새로운 소프트웨어, 오래된 하드웨어는 실제로 운명을 유혹합니다. 버전 X가 출시되기 전에도 X + 1이 계획 중입니다. 새 소프트웨어는 호환되지만 이전 하드웨어는 충분히 빠릅니까? 테스트 되었습니까? 특정 성능 픽스가 새로운 소프트웨어에 도입되어 잘못된 소프트웨어 업그레이드를 장려 할 수 있습니다.

기본적으로 많은 기여 요인이 있다고 생각합니다. 불행히도, 그것을 고칠 실버 총알은 없습니다. 그러나 그것이 운명과 우울함을 의미하지는 않습니다. 개선에 기여할 수있는 방법이 있습니다.

그렇다면 어떤 시점에서 이러한 제품에 문제가 발생 했습니까?

IMHO 우리는 실제로 단일 지점을 식별 할 수 없습니다. 시간이 지남에 따라 진화 한 많은 기여 요인이 있습니다.

• 콩 카운터 : 비용 절감, 시장 타이밍. 그러나 우리는 다시 압력을받지 않고 달성 한 진보를 이루어 냈을까요?
• 업계에서 숙련 된 인력의 수요와 공급이 적습니다. 프로그래머뿐만 아니라 관리자, 테스터 및 영업 사원까지도 가능합니다. 기술과 경험의 부족은 실수로 이어집니다. 그러나 다시 그것은 또한 학습으로 이어집니다.
• 최첨단 기술. 기술이 성숙 할 때까지 정기적으로 예상치 못한 방식으로 물립니다. 그러나 다시 처음에는 많은 이점을 제공했습니다.
• 복합 합병증. 시간이 지남에 따라 더 많은 도구, 기술, 계층, 기술, 추상화, 하드웨어, 언어, 변형, 옵션을 추가하는 업계가 발전했습니다. 이것은 현대 시스템을 "완전히"이해하는 것이 다소 불가능합니다. 그러나 결과적으로 훨씬 짧은 시간에 더 많은 작업을 수행 할 수 있습니다.

프로그래머가 우리 고객에게이 고통을 피하기 위해 무엇을 할 수 있습니까?

도움이 될 수있는 몇 가지 제안 (기술 및 비 기술적)이 있습니다.

• 가능한 한 소파에서 자신의 제품을 사용하십시오. 어색하거나 느리거나 불편한 것을 드러내는 직접적인 경험은 없습니다. 그러나 "내부 지식"으로 인한 결함 우회를 의식적으로 피해야합니다. 예를 들어 백도어 Python 스크립트로 연락처를 동기화하여 연락처 동기화에 문제가없는 경우 "제품"을 사용하지 않는 것입니다. 다음 요점은 ...
• 사용자의 의견을 경청하십시오 (선호하는 것이 바람직하지만 지원을 통해 적어도 초침). 나는 프로그래머들이 (일반적으로) 숨겨져 있고 인간의 상호 작용을 피하는 것을 선호한다는 것을 알고있다. 하지만 제품을 사용할 때 다른 사람들이 겪는 문제를 발견하는 데 도움이되지는 않습니다. 예를 들어 모든 단축키를 알고 독점적으로 사용하기 때문에 메뉴 옵션이 느리다는 것을 알 수 없습니다. 설명서에 모든 바로 가기가 완전히 문서화되어 있어도 일부 사람들은 메뉴를 선호합니다.
• 지속적으로 기술과 지식을 향상 시키려고 노력하십시오. 배운 모든 것을 비판적으로 분석하는 기술을 개발하십시오. 지식을 정기적으로 재평가하십시오. 어떤 경우에는 자신이 알고 있다고 생각한 것을 잊을 수 있도록 준비하십시오. 어느 것이 ...
• 일부 기술 / 기술은 매우 까다로워 미묘한 오해와 잘못된 구현으로 이어질 수 있습니다. 상식이나 이용 가능한 도구의 발전을 통해 다른 사람들은 선호도를 떨어 뜨릴 수 있습니다 (예 : 싱글 톤). 일부 주제는 너무 까다로워서 많은 잘못된 정보를 전파하는 "호 커스-포커스 전문가"를 번식시킵니다. 내 특별한 버그 베어는 멀티 스레딩을 둘러싼 잘못된 정보입니다. 우수한 멀티 스레드 구현은 사용자 경험을 크게 향상시킬 수 있습니다. 불행히도 멀티 스레딩에 대한 많은 잘못된 정보 접근 방식은 성능을 크게 저하시키고, 불규칙한 버그를 증가 시키며, 교착 상태 위험을 증가 시키며, 디버깅을 복잡하게 만듭니다. 따라서 "전문가"가 말한 것이 사실이 아니라고 기억하십시오.
• 소유권을 가지십시오. (심각하게도, 나는 회의실 빙고를하고 있지 않다.) 관리자, 제품 소유자, 영업 담당자와 일부 체크리스트 항목보다 우선하는 성능 기능을 협상한다. 더 나은 사양을 요구하십시오. 유치하지는 않지만 사람들이 성과에 대해 생각하게하는 질문을합니다.
• 안목있는 소비자가 되십시오. 기능은 없지만 속도가 더 빠른 전화를 선택하십시오. (더 빠른 CPU, 더 빠른 UI) 그런 다음 자랑하십시오 ! 더 많은 소비자가 성능 요구를 시작하면할수록 더 많은 빈 카운터가 예산 책정을 시작합니다.

당신의 첫 번째 실수, 그리고 아마도 당신이 왜 투표권을 얻었을지는 명백히 과장된 것입니다. 당신은 정말로 아이폰과 아이 패드가 그렇게 나쁘다고 믿고 있습니까?

궁극적으로 고객은 책임이 있습니다. 비용과 고객이 지불 할 준비물 및 그 대가로 얻는 것입니다. 그들이 속도보다 기능을 선택한다면, 그것이 바로 그들이 얻는 것입니다. 그들이 속도보다 가격을 선택한다면, 그것이 만들어지고 팔리는 것입니다. 브랜드 이미지가 더 중요하다면 ..... 궁극적으로 고객은 지갑으로 결정하고 중요한 것과 그렇지 않은 것을 결정합니다. 다른 사람들이 또는 독립적 인 사고를하고, 광택과 마케팅 과대 광고를 살펴보고, 필요에 맞는 것을 구매하기 때문에 브랜드 창녀가되고 제품을 구매할 수 있습니다.

프로그래머를 비난하고 있습니다. 그들은 코드를 작성했지만 고객 요구 사항, 하드웨어, BOM 비용, R & D 비용, 마케팅 예산 등 제품을 만드는 데 필요한 모든 것을 정의하고 정의해서는 안됩니다. 소프트웨어가 아닙니다.

사용 된 기술, 사용 된 언어 등은 이와 관련이 없습니다. 나쁜 개발자와 좋은 개발자, 아무 상관이 없습니다. 괜찮은 프로그래머라면 누구나 코드를 더 빠르게 실행하고 응답 성이 뛰어나며 궁극적으로 가능합니다. 내 경험은 괜찮은 프로그래머가 결정을 내릴 때 사업을 파산하지 않는 반면, 괜찮은 절반은 "더 나은"것이 얼마나 "더 나은지"불평하는 것이다.

조기 최적화는 때때로 나쁘지만 충분히 제한된 시스템에서 우수한 사용자 경험이나 배터리 수명을 위해 필요한 경우에는 그렇지 않습니다. 실패는 유지 보수가 훨씬 어렵고 짧아도 프로젝트를 시작할 때 좋은 사용자 경험과 알맞은 배터리 수명을 우선 순위로 제공하기 위해 쿠킹보다 유지 보수가 용이 한 소프트웨어 엔지니어링에 우선 순위를 부여하는 결함입니다. 회로 적으로 깔끔하게 설계된 소프트웨어 스택 및 방법론.

iPhone 3G를 사용하는 경우 Apple은 최신 장비에만 최적화 된 몇 가지 OS 업데이트를 출시했습니다. 3G에 대한 이후 OS 업데이트는 3G에서 약간 더 나은 성능을 제공 할 수 있습니다.

DVR은 버퍼링 된 데이터를 먼저 덤프 한 다음보고있는 새 채널에 대한 데이터로 가득 찬 다른 버퍼를 대기시켜야하므로 채널을 변경하는 데 시간이 오래 걸립니다. 이 버퍼는 하드 드라이브에 저장 될 가능성이 높으므로 이러한 작업에는 시간이 걸립니다 (또한 실시간으로 버퍼를 채울 수 있음). DVR을 사용하면 "실시간"프로그래밍을 전혀 볼 수 없으며 항상 지연됩니다 (우연히는 아니지만 채널을 전환 할 때 감지 된 지연 시간과 동시에 지연됩니다). 라디오에서 스포츠 프로그램을 듣는 동시에 스포츠 프로그램을 보면서 쉽게 확인할 수 있습니다.

그 이유는 대부분의 소비자 지향 앱이 소프트웨어에 대해 전혀 모르는 사람들에 의해 제어되고 판매되고 실제 기술과 지식과 달리 이력서 또는 무직 관리자의 추천에 따라 개발자를 고용하기 때문입니다 .