软件的性能
软件的性能、功耗、稳定性是三个大的方面，从大的方面来说:
性能受限于硬件的性能，相同质量的软件环境,一般来说i3是跑不过i7的;而另一方面，同样在i3上跑，不同质量的软件运行的工作效率是可以相差极大的，甚至是无底限拉低性能，性能分析就是检查软件的bottleneck，发挥硬件的最大性能。
功耗总的来说是不需要工作的硬件停下来，不需要那么高频的硬件降到低频上来，换句话就是以刚好的工作状态来满足用户的需要,功耗分析就是找出来那些额外的功率消耗在哪了。
稳定性就不用多说了，性能和功耗再稳定，稳定性不好也是没人敢用的，加入你正在准备用手机刷NFC，重启了，好尴尬呀，回去一定换掉它。稳定性分析就是各种使用场景，各种极限的测试条件下确保稳定工作。
像brendan gregg说的那样,性能是一个比较主观的指标,也是一个非常广泛的指标;
泛指用户使用的一切场景能够提供良好的使用体验,而开发没有那么多精力来尝试所有的场景,所以一般来说都是控制常见场景的性能指标;
常见的PC性能指标:
画面流畅,不卡顿
按键响应速度快:
网络速度快:
使用场景:玩大型网游,浏览网页,在线看电影,远程会议,下载文件,办公
用户使用的感觉最终是由应用来反馈的,所以性能指标不仅包括系统还有应用;
系统给应用提供地基,所以地基一定要牢,性能一定要好(怎么算好这也是一项大工程);应用在上面搭台唱戏, 地下观众只看到最终应用的效果,所以应用也是需要满足性能指标的;所以我们看到android不仅自身做了大量 的性能优化工作,而且还给应用开发提供了很多优化参考,以最终能够达到理想的机器整体使用体验良好的效果;
而在开发的过程中,引起性能的问题主要有两类:架构上的问题和小问题
架构上设计时如果没有充分考虑性能或者没有预料到性能下降的场景,很明显架构上很可能存在许多的问题,在理论上就已经不满足性能指标了,所以无论再怎么优化也没用;
我们可能也需要重新设计架构,这个从大型软件上基本都可以看到,架构被重构了N+1次,Linux kernel的进程调度系统;
小问题:架构上没有问题时,那么另一种可能是我们的性能被很多很多的小问题给拉低了,最后病入膏肓,谁也救不了;我遇到了一个项目开发,里面整了大量的临时方案,从commit message上
看到了非常多的临时fix方案,我真的不相对这种patch讲太多;
这种临时方案author可能觉着是奇思妙想,这样就可以解决问题,但是其他开发接手的时候满脑袋问号?为什么这样提?当时发生什么情况了?
很可能后面的patch一个一个覆盖上去,谁也不知道最初的原因了,这样系统进入迅速死亡期;
不光是小项目,大项目也是一个道理,由于持续的开发,代码越来越多,越来越臃肿,已经不可能有人完全看懂所有的code了,里面会加入各种patch(完全看不懂,谁看谁怀孕);
杜绝临时方案,尽可能地拖延软件死亡的时间;针对性的进行性能测试并且立时解决.
