对于智能手机，你常常听到这样的抱怨：电池太不抗用了;玩游戏一点都不流畅;什么破摄像头，把我拍的这么丑……

当然，另一些时候，你听到的抱怨也许是这样的：为什么我的手机总死机?为什么新品刚上市就断货?为什么我刚买没多久它就降价了啊……

第一类抱怨，基本和硬件配置有关，我们纵然无奈，但也有迹可循;第二类问题，则相对有些奇妙，起码，它的现象和本质并不太容易猜透。

今天，我们就来重点分析一下第二类用户的抱怨——关于智能手机的那些怪现象。

死机：有点像买彩票 差别的是中奖率

很多智能手机用户都有过“死机”的经历，画面不动，或者干脆屏幕一黑，常规操作无法恢复其活力的，我们称之为：“手机死了”。

死机和质量有着最根本的关系。苹果的iPhone可能几个月也不死一次，路边的山寨机，常常整得你死去活来。智能手机为什么会死机?

现在假设你和我都穿上了隐身衣，我们悄悄潜伏到手机公司测试部门，看看一部智能手机的测试过程是否符合规矩，为什么会让可能死机的产品通过检验。

在迈进手机研发大厦前，简单介绍下一部手机的诞生流程，以免进去后迷了路。

手机的诞生简单可分为“预研--设计--研发--测试--制造--销售--维护”几个环节。这期间很多流程都是相互交叉，甚至来来回回折腾不休。例如测试会提前到研发初期介入，来保证产品的问题能提前发现，还有即便进入到研发和测试的末期，设计环节也有可能提出新的变更——然后一部分甚至一大部分成果需要推倒重来。

走进测试部，你会发现一台台手机被连接到电脑上，电脑屏幕快速运行着一行行神奇的代码。这便是手机测试的核心环节——跑测试用例。

我们简化下，测试用例是根据经验和需求，设计出手机可能存在的各种场景，简单到“拨出一个电话”，当系统运行这个用例时，电脑把指令传给手机，手机就会真的拨打一个号码，然后反馈一个结果回来：成功，或者失败。

一般手机公司的测试用例库里，会有几万甚至十几万的测试用例，然后根据手机型号的不同，选出其中一部分进行针对性测试。测试通过的，打一个对号，测试不过的，测试员会提交一个“问题单”给测试经理，再通过研发经理辗转到开发对应代码或硬件的工程师手里。

如果问题单被研发人员解决了，会把修改的硬件或软件再次提交给测试部门，进行二次验证（术语叫回归测试）。

一台手机的研发过程，基本上就是开发部门与测试部门的博弈过程，一路的刀光剑影。测试部的KPI就是谁提的问题单更多更狠，开发部的绩效则是保证进度和少出问题。所以，两者基本上就是天敌。

手机研发是个系统活，不可能等到最后再去看是否合格。精明的管理者会在整个流程里设置多个检测点（术语叫TR点），每个点必须实现一部分目标。这样可以做到风险可控。

对于暂时无法解决的问题，测试与研发经过友好或者激烈的讨论，决定“解决掉”，不管了，装作什么事都没发生。

OK，这就是死机的根源。一部分问题单由于能力问题，或者是测试过程太复杂，手机厂商会根据风险评估来把他们屏蔽掉，并且有一个很欣慰的理由——留待后续版本解决。因此，这些没有通过的测试用例，如果偶尔被你在操作时复现了，那基本上就是一个结局——死机。

手机死机的另一个常见可能，和情景无关，叫做“内存溢出”。

实际上，手机每次运行一个程序，都会占用一部分内存，然后在退出是释放掉。但有时候，出于某些设计上的BUG，程序退出后没有释放内存或释放不充分，就导致手机越用内存越少，这时候，如果忽然开启个大程序，剩余内存不足以承担，那就只剩死机或重启一条路了。

对于大部分的功能和应用场景，手机厂商是会负责测试通过，不可能打一个电话就死机。

至于为什么有的手机容易死机，有的手机不容易死机，其实道理也简单。研发能力决定了遗留问题单的多少，测试能力和责任心决定了测试用例的多少，还有各种不可控的因素，例如制造工艺的粗糙、操作环境的变态等，也会提高死机的概率。