是什么导致消费者应用程序的性能下降？[关闭]

我的Comcast DVR至少需要三秒钟才能响应每次远程控制按键，使看电视的简单任务变成令人沮丧的按钮混搭体验。我的iPhone至少需要15秒才能显示短信，并且在尝试启动iPod应用程序时崩溃1/4。仅接收和阅读电子邮件通常需要一分钟以上的时间。甚至我车中的navcom都具有糊状且反应迟钝的控件，如果我将连续的输入间隔不超过几秒钟，它们通常会吞咽。

这些都是固定硬件最终消费者设备，其可用性应该是最重要的，但是它们都在基本的响应速度和延迟方面都失败了。他们的软件太慢了。

这背后是什么？是技术问题还是社会问题？谁或什么负责？

是否因为它们都是用托管的垃圾收集语言而不是本机代码编写的？是为这些设备编写软件的个人程序员吗？在所有这些情况下，应用程序开发人员都确切知道他们所针对的硬件平台以及其功能是什么。他们没有考虑到这一点吗？难道是那个反复说“优化是万恶之源”的家伙，他使他们误入歧途了吗？直到所有这些毫秒数累加起来才是每次都会“额外增加100毫秒”的心态吗？首先购买这些产品是我的错吗？

这是一个主观的问题，有没有唯一的答案，但我经常受挫在这里看到这么多回答说：“哦，不用担心代码的运行速度，性能并不重要，”在某个时候，当清楚地做事情了陷入缓慢，反应迟钝，糟糕的体验的最终用户。

那么，这些产品在什么时候出问题了？作为程序员，我们如何做才能避免给我们自己的客户造成这种痛苦？

好问题。我每天看到的是这个。

人们使用大型应用程序工作。当它们起作用时，就像漏洞一样，性能问题会逐渐蔓延。区别在于-错误是“不好的”-他们大喊“发现我并修复我”。性能问题只会摆在那儿，并且变得更糟。程序员经常认为“好吧，我的代码不会出现性能问题。相反，管理层需要给我买一台更新/更大/更快的机器。”

事实是，如果开发人员定期只是寻找性能问题（实际上很容易），他们就可以清除它们。

相反，“最新技术”是：

1. 依靠诸如“避免过早优化”和90/10 hoo-haw之类的格言。
2. 在所有关于SO的问题中都可以看到，大胆地谈论概要分析，有时甚至实际尝试，结果常常令人失望。
3. 依靠伪装成经验和知识的良好的旧猜测。

但这确实是负面的。肯定的是，这种方法几乎一直都有效，而且再简单不过了。这是一个详细的示例。

这不是技术问题，而是营销和管理问题。

此时，您可能会翻白眼，但请多多包涵。

公司出售的是他们的“产品”，定义产品的人就是“产品经理”。在科技公司中，很多其他人都在考虑这一点-用户体验专家yadda yadda。但是最终，产品经理负责编写用户应该获得的规格。

因此，让我们来看看您的Comcast DVR。理想情况下，事情将像这样工作：

1. 产品经理在规范中写道：“当用户按下遥控器上的按钮，并且距离DVR 25英尺以内时，DVR必须在250毫秒内对按下做出响应。”
2. 技术人员构建硬件，编写嵌入式软件等。
3. QA测试人员要么批准系统符合规格，要么将其退回给技术团队进行修复。

当然，很多事情都会出错：

• 产品经理无法在规范中添加按钮响应
• 质量检查人员在根据规范进行测试方面表现平平
• 有人选择了不允许满足规范的技术，因此要求被取消了
• 技术人员缺乏人手，或者有人加快了进度，有些经理说：“忘记响应能力-完成其他功能。”
• 产品经理要等到游戏后期才发布响应性要求，直到发货日期才能满足
• 管理层决定直到这么晚才提交任何内容进行质量检查，加速缓慢的代码会破坏产品的稳定性

您看到那里的所有熟练的程序员了吗？没有。

我并不是说我们对性能不好不承担任何责任-通常，编写良好，健壮，高效的代码与编写垃圾一样容易且快速。

但是，实际上，如果产品管理人员和质量检查人员都睡着了，我们的程序员将无法弥补这一点。

FWIW，我完全同意大多数消费产品的糟糕界面。我现在已经写UI代码已有25年了，我一直在追求优雅和简单。实际上，这是一个问题，因为我考虑得太多了，现在我很想弄清楚设计不良的用户界面，所以我可怜的妻子最终在媒体中心运行了大多数设备。

因为程序员并不完美。

我是嵌入式事物的程序员。我的某些代码并不完美。我的大多数嵌入式代码都很快。

在项目结束时修复性能问题非常困难。

有时，为了使事情保持简单（因此可测试，可以在现实时间内开发，而不是致命的错误），我们对事物进行分层，例如对不属于主应用程序的“服务”进行远程输入。最终结果，延迟。另一种选择是将所有内容放在一个单片应用程序中，这是C或C ++（两种最常见的嵌入式语言）的越野车灾难。

有时，您的嵌入式设备具有一个进程调度程序，该进程调度程序无法满足您的用户需求。作为嵌入式开发人员很难修复。

由于分层的延迟，复杂性会导致滞后。您要求提供功能。尝试使用真正的旧诺基亚手机，例如旧的3210。Zippy快速UI。功能不多。

我在争辩说开发人员不会变得更聪明，因此更快的硬件会被抽象吸收，以防止功能相互残杀。（或者，对于您的iPhone，不是）

UI性能需要随着设计的进行进行测试。

如果未指定，开发人员将习惯它。我们都这样做。“我的孩子不丑”

这不是GC语言；嵌入式实时Java是如此之快，令人恐惧。（另一方面，嵌入式Python是一只狗）

我编写了一个程序，该程序读取作为UI的数字输入的开关。仍然必须对开关进行反跳操作，因此快速弹动开关是行不通的，因为反跳操作有两层。理想情况下，我会在固件堆栈的底部使用反跳逻辑，但这不是硬件的工作方式。

一些DVD播放器只是运行“弹出”脚本来弹出。您的DVR可能已采用这种方法来保持开发成本合理。然后，您在CPU或RAM上跳过，它很烂。

是否因为它们都是用托管的垃圾收集语言而不是本机代码编写的？

不可以。慢速代码无论如何都会表现不佳。当然，一种特定的语言可能会在解决其他问题的同时引入某些问题。但是优秀的程序员在有足够的时间就可以找到解决方法。

是为这些设备编写软件的个人程序员吗？

部分地。在许多情况下，至少很有可能是一个促成因素。这是一个行业的不幸的副作用，在这个行业中，好的程序员需求旺盛，供应短缺。同样，各种技术能力水平之间的鸿沟也可能很大。因此，有理由说，有时为完成某些软件而工作的程序员可能会受到祝贺。

在所有这些情况下，应用程序开发人员都确切知道他们所针对的硬件平台以及其功能是什么。他们没有考虑到这一点吗？

部分地。首先，可能不知道确切的硬件平台，因为通常在软件开发过程中会与各个制造商并行协商。实际上，初始发行后甚至可能对基础硬件进行很小的更改（但不一定是无关紧要的）。但是，我同意将了解常规功能。

问题的一部分是软件可能不是在硬件上开发的，而是在模拟器中完成的。即使仿真器是100％准确的，这也很难考虑真实的设备性能，而事实并非如此。

当然，这并不能证明在发布之前没有在适当的原型硬件上进行足够的测试。怪罪可能不在dev / qa控制范围之内。

难道是那个反复说“优化是万恶之源”的家伙，他使他们误入歧途了吗？

不，我可以肯定他们不会听他的话。否则，他不会经常被错误引用（这应该是“ 过早的优化...”）。:-D

关于优化，太多的程序员可能会选择两个极端之一。

• 他们要么完全忽略它。
• 否则他们会沉迷于与实际性能要求无关的细节。最终结果是预算用完了，代码过于混乱，无法安全地优化实际性能问题。

直到所有这些毫秒数累加起来才是每次都会“额外增加100毫秒”的心态吗？

可能吧 显然，如果Sleep(100)已将其用作与减缓肢体出血有关的面巾纸的等效物，那么将会出现问题。但是，我怀疑这个问题比这更棘手。

问题是现代计算硬件（包括嵌入式设备）的速度要比人们认为的要快得多。大多数人，甚至是“经验丰富”的程序员也无法理解计算机的速度。100ms是很长的时间- 很长的时间。碰巧的是，这种“很长的时间”削减了两种方式：

• 首先是程序员不必担心计算机的运行速度非常快。（碰巧的是，这样的担忧“ 每秒增加300次值 ”才使我首先来到这里。）
• 第二个问题是，当事情确实花费很长时间时（在计算时间尺度上），它们有时无法表现出应有的关注。所以：
  • 通过网络或与存储设备进行通信时是否忽略了延迟的影响；
  • 如果他们忽略线程阻塞并等待另一个线程的影响；
  • 如果他们忘记了由于计算机运行速度如此之快，它能够重复执行任务的次数远远超过了应有的次数，而开发人员却没有意识到问题
  • ...如果发生这种疏忽的任何组合，则例程将意外地非常缓慢地运行（在计算时间范围内）。重复几次，甚至会被人类注意到-但是固定下来可能很棘手，因为成百上千个相互关联的事物都是自己快速运行的。

首先购买这些产品是我的错吗？

当然是。好吧，不是您本人而是一般消费者。产品通过功能清单出售（和购买）。很少有消费者要求更好的性能。

为了说明我的观点：上一次我想购买手机时，商店甚至没有提供可以在店内玩的演示模型。他们所拥有的只是带有贴纸的塑料外壳，可以显示屏幕的外观。您甚至无法感觉到这样的重量-更不用说性能或可用性了。我的观点是，如果有足够多的人反对这种商业模式，并用他们的钱包投票反对他们的反对意见，那么我们将朝着正确的方向迈出一小步。

但是他们没有，所以我们不是。每年新手机在较快硬件上的运行速度都会变慢。

（未问的问题。）

• 是行销人员的责任？部分地。他们需要发布日期。当上述日期迫在眉睫时，在“使其工作”与“使其更快”之间进行选择就变得轻而易举了。
• 是销售人员的责任？部分地。他们想要清单中的更多功能。他们大肆宣传功能列表并忽略性能。他们（有时）做出不现实的承诺。
• 经理要怪吗？部分地。没有经验的经理可能会犯很多错误，但是即使是非常有经验的经理也可以（很正确）牺牲时间来解决绩效问题，而转向其他方面。
• 规格要怪吗？部分地。如果遗漏了某些规范，那么以后“忘记”它会容易得多。如果没有特别说明，目标是什么？（尽管我个人确实相信，如果团队为自己的工作感到自豪，那么他们将为绩效感到担忧。）
• 教育要怪吗？也许。教育可能永远会倒退。我当然不赞成“教育”，因为它对软件开发有肤浅的了解，因此会迅速吸引初学者。但是，以理论为后盾并灌输学习文化的教育也不错。
• 是要怪升级吗？部分地。新软件，旧硬件确实是诱人的命运。甚至在发布X版本之前，X + 1仍在计划中。新软件兼容，但是旧硬件是否足够快？经过测试了吗？特定的性能修复可能会纳入新软件中-鼓励进行不明智的软件升级。

基本上，我相信有很多贡献因素。因此，不幸的是没有解决之道。但这并不意味着它注定要失败。有一些方法可以改善事物。

那么，这些产品在什么时候出问题了？

恕我直言，我们不能真正确定任何一点。随着时间的流逝，有许多促成因素。

• 豆类专柜：削减成本，市场时机。但是，在没有压力的情况下，我们又可以取得进步吗？
• 行业技术人员的高需求和低供应。不仅是程序员，而且还有经理，测试人员，甚至是销售人员。缺乏技能和经验会导致错误。但话又说回来，它也导致学习。
• 尖端技术。在技​​术成熟之前，它会定期以意想不到的方式咬人。但是话又说回来，它通常首先提供了许多优势。
• 复合并发症。随着时间的流逝，该行业得到了发展：添加了更多的工具，技术，层，技术，抽象，硬件，语言，变体，选项。这使得对现代系统没有“全面”的了解是不可能的。但是，我们也有能力在更短的时间内做更多的事情。

作为程序员，我们如何做才能避免给我们自己的客户造成这种痛苦？

我有一些建议（技术性和非技术性的）都可以帮助您：

• 如果可能，请使用您自己的产品。没有什么比第一手经验更能揭示尴尬，缓慢或不便的事情了。但是，您将需要有意识地避免绕过“内幕知识”造成的缺陷。例如，如果您通过使用后门Python脚本来完成联系人同步时没有问题-您就不会使用“产品”。接下来是下一点...
• 倾听您的用户（最好是第一手，但至少要通过支持获得第二手）。我知道程序员（通常）更喜欢躲藏起来，避免人为干预。但这并不能帮助您发现其他人在使用您的产品时遇到的问题。例如，您可能不会注意到菜单选项很慢，因为您知道所有快捷方式并专门使用它们。即使手册完整记录了所有快捷方式，但有些人仍然会偏爱菜单-尽管速度很慢。
• 努力不断提高您的技术技能和知识。发展技能，以批判性地分析您学到的一切。定期重新评估您的知识。在某些情况下，请准备忘记您认为的知识。带来了...
• 一些技术可能会非常棘手，从而导致细微的误解和错误的实现。通过公知常识或可用工具发展而来的其他项目可能会受到青睐或失宠（例如Singletons）。一些主题非常棘手，以至于它们滋生出大量传播大量错误信息的“病态专家”。我的一个臭虫是围绕多线程的错误信息。好的多线程实现可以显着改善用户体验。不幸的是，许多错误的多线程方法会显着降低性能，增加不稳定的错误，增加死锁风险，使调试复杂化等。因此请记住：仅仅因为“专家”所说的，并没有使它成真。
• 取得所有权。（不，我不是在玩会议室宾果游戏。）与经理，产品负责人，销售人员进行谈判，以获取优先于某些清单项目的性能功能。需要更好的规格。并非幼稚，而是通过提出使人们思考性能的问题。
• 成为挑剔的消费者。选择功能较少但速度更快的手机。（没有更快的CPU，更快的UI。）然后吹牛吧！越来越多的消费者开始要求性能，更多的bean计数器将开始为此预算。

您的第一个错误，以及为什么您会被否决，应该被公然明显地夸大。您真的希望相信iPhone和iPad这么糟糕吗？

最终，客户负责。它取决于成本，客户准备支付的费用以及他们得到的回报。如果他们选择功能而不是速度，那就是他们得到的。如果他们选择价格而不是速度，那就是制造和销售的东西。如果品牌形象更重要.....最终，客户用他们的钱包来决定什么重要和不重要。您可以选择成为一个妓女品牌并购买产品，因为其他人都可以这样做，或者您可以成为一个独立的思想家，在光泽和营销炒作背后寻找东西，然后购买满足您需求的东西。

您是在责怪程序员。他们肯定写了代码，但是没有定义，也没有定义客户需求，硬件，BOM成本，R＆D成本，营销预算.....制造产品的所有要素。 ，那不是软件。

所使用的技术，所使用的语言等与此无关。好的与坏的开发人员，与它无关。任何半个体面的程序员都可以使一段代码运行得更快，响应速度更快，并最终达到目的。我的经验是，体面的程序员在任职时不会破产，而一半体面的程序员则抱怨它“应该”有多少“更好”。

过早的优化有时是不好的，但在足够受限的系统中，如果要获得良好的用户体验或电池寿命则不是必需的。失败是由于在项目开始时就将提供良好的用户体验和体面的电池寿命作为优先考虑的事项，而优先于清洁可维护的软件工程来进行优先处理，即使这在项目开始时就更难维护了。循环一些结构清晰的软件堆栈和方法。

如果您拥有iPhone 3G，Apple会发布一些仅针对较新设备进行了优化的操作系统更新。3G的更高版本的OS更新可能会在3G上提供更好的性能。

DVR切换频道需要花费很长时间，因为它必须先转储缓冲的数据，然后将另一个充满数据的缓冲区排入正在观看的新通道的队列。此缓冲区很可能存储在硬盘驱动器上，因此这些操作需要时间（加上它只能实时填充缓冲区）。使用DVR时，您永远不会观看“实时”节目，它总是被延迟（并非巧合的是，它与切换频道时所感知的延迟同时被延迟）。通过在收音机上收听体育节目的同时，可以轻松地验证这一点。

我认为原因是大多数面向消费者的应用程序是由对软件一无所知的人控制和销售的，他们根据简历或一些虚无的经理的建议雇用开发人员，而不是他们的实际技能和知识。