性能优化之怎么学？

Question

性能优化的文章非常多，但是写得精彩的却非常少。为什么会这样？我个人认为原因有以下几点：

1. 优化是伴随着整个开发过程的，是工程师的基本功。

   可以说，人人都需要懂优化 —— 这就是为什么优化相关的文章多的原因。

2. 优化是一个 门槛低，坑多又深 的工程。

   比如 内存优化，你可以很轻松地用 LeakCancary 监控，咔咔地解决 context泄漏、webview销毁 等等这些问题，然后呢？

   你可能会往 bitmap 优化再走一走，更深的呢？native 内存分配？OOM监控？更换序列化方案？view复用？大部分人摘完“所有低垂的果实”，之后就陷入了停滞 —— 这就是为什么精彩的文章稀少的原因。

如何学？

性能优化涉及的知识点，杂且碎还深。

最终呈现出来的效果，不是看一两本书，读几篇博文就能达到的，需要有足够的知识广度深度以及创新思维。

我强烈推荐你，整理好自己的 逻辑结构图 或 目录。

1. 定义问题

第一步，先明确，学习目的。我是来做知识储备的？还是业务需求？不同的学习目的决定了你的方向和深浅。如果做知识准备，可以偏重背景知识，如果是解决业务问题，可以偏重分析工具和解决手段。

第二步，解决问题前，先想想，这个问题是可以被量化的吗？如果无法量化，能通过什么可以定性的手段（问卷、调查）来收集，来得到可观的改进？

第三步，我们要到达一个怎么样的状态？比如耗电优化，我们目的是 解决后台播放手机发热，还是 避开系统耗电规则，避免用户收到“APP正在后台高耗电”。

2. 穷举

整个流程链都进行逐一分析了吗？各个节点的痛点有优化空间吗？

还有更多的解决方式吗？还有疏漏的点吗？翻阅参考资料，官方文档也好，博文也罢，统统记录到结构图中。不适合我们业务的，就浅尝即止，有搞头的，我们就深挖下去。

比如耗电优化：很多博文都 balabala 说 要留意 View 的绘制啦，动画的停止和回收啦，传感器选择合适的采样率啦 这些解决手段，在我的业务项目中都不适合，那我就简单记录下。

遇到 CPU唤醒、网络优化数据压缩 这些解决手段，诶，那我就深入贴合业务考量。

3. 背景知识

一边解决一边把对应知识点的背景知识记录下来。比如耗电优化：我可以了解下

• 谷歌官方在不同 Android版本中对耗电的管控和优化演进
• Android 系统是如何计算电量的
• 快充技术
• 电池材料的发展

你说了解这些知识，有啥用呢？

我们要建立起一套从 应用层到操作系统，再到硬件 的整体认知。扩展宽度，才能知道，我们优化还有哪里可以再努力突破一把，局限于 应用层 的优化，非常受限。

扩展

面对性能问题，我们能做的不仅仅是“事后”优化，还有：

1. 防微杜渐，常规化、流程化

我们常常在什么情况下会开始专项性能优化？

要么是忍无可忍，要么是老板忍无可忍。

往往优化的结果就是 摘完“所有低垂的果实”、“这个历史遗留不好改”，“这个改动影响太大”……

所以性能优化的关键在于如何解决存量问题，同时快速发现增量问题。

• 针对存量问题，采用长短结合。

  我们容易陷入一个两难的境地：如果采取临时措施，虽然能够应对，但没有从根本上解决，后面还可能出现其他问题。如果采取长远措施，虽然能够根本解决掉问题，但是投入大，短期内无法快速落地。

  正确的做法是长短结合，先快速解决表面的问题，避免损失，然后把长期的规划，拆分成一个个小项目或者小迭代，慢慢从根本上解决问题。

• 针对增量问题，搭建并利用好 APM 质量平台，或者加强测试流程，帮助我们快速发现和定位问题。

2. 从问题的源头入手

一个好的架构可以减少甚至避免团队出错，也是打造一款高质量应用非常重要的一环。比如，如果我们 能根据不同性能的机器做 动画的降级、音质的切换，就能 减少线上部分低端机 OOM ；如果我们 能统一图片库，统一系统Service使用入口，就能 方便 hook 做监控。

3. 端正心态

APM 有了，但有些开发的做法常常是 发现空指针加一个判空，发现并发问题加一个锁。

我们应该多多反问，这是最好的解决方案吗？有没有架构可以避免这个问题？深挖背后的原因，浅尝即止要不得，愿我们都有一颗深究的心。

优化的通用原则

如何开始性能优化

强烈推荐一读，本文没有任何优化技巧，没有任何优化方法，围绕的就是一个宏观的抽象来看性能优化这件事情。如果你在软件工程领域“阅历”足够丰富，你就会有恍然大悟的感觉，万物都有联系。

性能调优那些事

再次强烈推荐，简单朴素的通用优化原则。