作为一名开发，性能优化是永远绕不过去的话题，在日常的开发中，我们可肯定都会接触过。Android 的性能优化其实是非常成熟的了，成熟的套路，成熟的方法论，成熟的开源框架等等。

对于接触性能优化经验较少的开发者来说，可能很少有机会能去学习或者总结出这些成熟的套路，方法论，或者框架。所以作为一位多年长期做性能优化的开发者，在这篇文章中对性能优化的方法论做一些总结，以供大家借鉴。

性能优化的本质

首先，我先介绍一下性能优化的本质。我对其本质的认知是这样的：性能优化的本质是合理且充分的使用硬件资源，让程序的表现更好，并且程序表现更好的目的则是为了获取更多来自客户的留存，使用时长，口碑、利润等收益。

所以基于本质来思考，性能优化最重要的两件事情:

1. 合理且充分的使用硬件资源

2. 让程序表现更好，并取得收益

下面讲一下这两件事情。

合理且充分的使用硬件资源

充分表示能将硬件的资源充分发挥出来，但充分不一定是合理的，比如我们一下子开启了几百个线程，cpu 被充分发挥了，但是并不合理，所以合理表示所发挥出来的硬件资源能给程序表现有正向的作用。

硬件资源包括：CPU，内存，硬盘，电量，流量（不属于硬件资源，不过也归于需要合理使用的资源之一）等等。

下面举几个合理且充分的使用硬件资源的例子：

1. CPU 资源的使用率高，但并不是过载的状态，并且 cpu 资源主要为当前场景所使用，而不是被应用中各个业务所分散消耗。比如我们优化页面打开速度，速度和 cpu 有很大的关系，那么我们首先要确保 cpu 被充分发挥出来了，我们可以使用多线程、在页面打开前提前预加载相关资源等策略，来发挥手机的 cpu。但是在打开页面的时候，我们要合理的确保 cpu 资源主要被打开页面相关的逻辑所使用，比如组件创建，数据获取，页面渲染等等，至于其他和当前打开页面场景联系较少的逻辑，比如周期任务，监控，或者一些预加载等等都可以关闭或者延迟，以此减少非相关任务对 cpu 的消耗，

2. 内存资源缓使用充分，并且又能将 OOM 等异常控制在合理范围内。比如我们做内存优化，内存优化并不是越少越好，相反内存占用多可能让程序更快，但是内存占用也不能太高，所以我们可以根据不同档次机型的 OOM 率，将内存的占用控制在充分使用并且合理的状态，低端机上，通过功能降级等优化，减少内存的使用，高端机上，则可以适当提升内存的占用，让程序表现的更好。

让程序表现更好，并取得收益

我们有很多直接的指标来度量性能优化取得的收益，比如做内存优化可以用 pss，java 内存占用，native 内存占用等等；做速度优化，可以用启动速度，页面打开速度；做卡顿优化，可以用帧率等等。掌握这些指标很重要，我们需要知道如何能正确并且低性能消耗的监控这些指标数据。

除了上面的直接指标外，我们还需要了解性能优化的最终体现指标，用户留存率，使用时长，转换率，好评率等指标。有时候，这些指标才是最终度量我们性能优化成果的数据，比如我们做内存优化，pss 降低了 100 M，但仅仅只是内存占用少了 100M 并没有太大的收益，如果这个 100M 体现在应用的存活时间，转化率的提升上，那这 100 M 的优化就是值得的，我们在向上报告我们产出时，也更容易获得认可。

如何做好性能优化

讲完了性能优化的本质，我再讲讲如何做好性能优化。我主要从下面这三个方面来讲解

1. 知识储备

2. 思考的角度和方式

3. 形成完整的闭环

知识储备

想要做好性能优化，特别是原创性、或者完善并且体系的、或者效果很好的优化，不是我们从网上看一些文章然后模仿一下就能办到的，需要我们有比较扎实的知识储备，然后基于这些知识储备，通过深入思考，去分析我们的应用，寻找优化点。我依然举一些例子，来说明硬件层面，系统层面和软件层面的知识对我们做好性能优化的帮助。

硬件层面

在硬件层面，我们需要对处理器的体系结构，存储器的层次结构有一定的了解。如果我们如果不知道 cpu 由几个核组成，哪些是大核，哪些是小核，我们就不会想到将核心线程绑定大核来提升性能的优化方案；如果我们不了解存储结构中寄存器，高速缓存，主存的设计，我们就没法针对这一特性来提升性能，比如将核心数据尽量放在高速缓存中就能提升不少速度相关的性能。

系统层面

对操作系统的熟悉和了解，也是帮助我们做好性能优化不可缺少的知识。我在这里列一下系统层面需要掌握的知识，但不是全的，Linux的知识包括进程的管理和调度，内存管理，虚拟内存，锁，IPC通信等。Android系统的知识包括虚拟机，核心服务如ams，wms等等，渲染，以及一些核心流程，如启动，打开activity，安装等等。

如果我们不了解Linux系统的进程调度系统，我们就没法充分利用进程优先级来帮助我们提升性能；如果我们不熟悉 Android 的虚拟机，那么围绕这虚拟机相关的优化，比如 oom 优化，或者是 gc 优化等等都无法很好的开展。

软件层面

软件层面就是我们自己所开发的 App，在性能优化中，我们需要对自己所开发的应用尽可能的熟悉。比如我们需要知道自己所开发的 App 有哪些线程，都是干嘛的，这些线程的 cpu 消耗情况，内存占用多少，都是哪些业务占用的，缓存命中率多少等等。我们需要知道自己所开发的 App 有哪些业务，这些使用都是干嘛的，使用率多少，对资源的消耗情况等等。

除了上面提到的三个层面的知识，想要深入做好性能优化，还需要掌握更多的知识，比如汇编，编译器、编程语言、逆向等等知识。比如用c++ 写代码就比用java写代码运行更快，我们可以通过将一些业务替换成 c++ 来提高性能；比如编译期间的内联，无用代码消除等优化能减少包体积；逆向在性能优化上的用处也非常大，通过逆向我们可以修改系统的逻辑，让程序表现的更好。

可以看到，想要做好性能优化，需要庞大的知识储备，所以性能优化是很能体现开发者技术深度和广度的，这也是面试时，一定会问性能优化相关的知识的原因。这些知识储备不是一下就能形成的，需要我们慢慢的进行学习和积累。

思考的角度及方式

讲完了知识储备，再讲讲思考的角度和方式。需要注意它和知识储备没有先后关系，并不是说要有了足够的技术知识后才能开始考虑如何思考。思考的角度和方式体现在我们开发的所有生命周期中，即使是新入门的开发，也可以锻炼自己从不同的角度和方式去进行思考。下面就聊一聊我在做性能优化的过程中，在思考的角度和方式上的一些认知。为了让大家能更形象的理解，我就都以启动优化来讲解。

思考角度

我这里主要通过应用层，系统词，硬件层这三个角度来介绍我对启动速度优化的思考。

应用层

做启动速度优化时，如果从应用层来考虑，我会基于业务的维度考虑所加载的业务的使用率，必要性等等，然后制定优先级，在启动的时候只加载首屏使用，或者使用率高的业务。所以接着我就可以设计启动框架用来管理任务，启动框架要设计好优先级，并且能对这些初始化的任务有使用率或者其他性能方面的统计，比如这些任务初始化后，被使用率的概率是多少，又或者初始化之后，对业务的表现提升提现在哪，帮助有多大。

从应用层的思考主要是基于对业务的管控或者对业务进行优化来提升性能。

系统层

以及系统层来考虑启动优化也有很多点，比如线程和线程优先级维度，在启动过程中，如何控制好线程数量，如何提高主线程的优先级，如何减少启动过程中不相关的线程，比如 gc 线程等等。

硬件层

从硬件层来考虑启动优化，我们可以从 cpu 的利用率，高速缓存cache的命中率等维度来考虑优化。

除了上面提到的这几个角度，我们还可以有更多角度。比如跳出本设备之外来思考，是否可以用其他的设备帮助我们加速启动。google play 就有类似的优化，gp会上传一些其他机器已经编译好的机器码，然后相同的设备下载这个应用时，也会带着这些编译好的机器码一起下载。还有很常用的服务端渲染技术，也是让服务端线渲染好界面，然后直接暂时静态模块来提升页面打开速度；又或者站在用户的角度去思考，想一想到底什么样的优化对用户感知上是有好处的，比如有时候我们再做启动或者页面打开速度优化，会给用户一个假的静态页面让用户感知已经打开了，然后再去绑定真实的数据。

做性能优化时，考虑的角度多一些，全面一些，能帮助我们想出更多的优化方案。

思考方式

除了锻炼我们站在不同的角度思考问题，我们还可以锻炼自己思考问题的方式，这里介绍自上而下和自下而上两种思考方式。

自上而下

我们做启动优化，自上而下的优化思路可能是直接从启动出发，然后分析启动过程中的链路，然后寻找耗时函数，将耗时函数放子线程或者懒加载处理，但是这种方式会导致优化做的不全面。比如将耗时的任务都放在子线程，我们再高端机上速度确实变快了，但是在低端机上，可能会降低了启动速度，因为低端机的 cpu 很差，线程一多，导致 cpu 满载，主线程反而获取不到运行时间。其次，如果从上层来看，一个函数执行耗时久可能并不是这个函数的问题，也可能是因为该函数长时间没有获取到 cpu 时间。

自上而下的思考很容易让我们忽略本质，导致优化的效果不明显或者不完整。

自下而上

自下而上思考就是从底层开始思考，还是以启动优化为例子，自下而上的思考就不是直接分析启动链路，寻找慢函数，而是直接想着如何在启动过程中合理且充分的使用 cpu 资源，这个时候我们的方案就很多了，比如我们可能会想到不同的机型 cpu 能力是不一样的，所以我们会针对高端机和低端机来分别优化，高端机上，我们想办法让cpu利用率更高，低端机上想办法避免 cpu 的超载，同时配合慢函数，线程，锁等知识进行优化，就能制定一套体系并且完整的启动优化方案。

完整的闭环

上面讲的都是如何进行优化，优化很重要，但并不是全部，在实际的性能优化中，我们需要做的有监控，优化，防劣化，数据收益收集等等，这些部分都做好才能形成一个完整的闭环。我一一讲一下这几个部分：

• 监控：完整的监控应用中各项性能的指标，仅仅有指标监控是不够的，我们还需要尽量做归因的监控。比如内存监控，我们不仅仅要监控我们应用的内存指标，还可以还要能监控到各个业务的内存使用占比，大集合，大图片，大对象等等归因项。并且我们的监控同样要基于性能考虑去设计。完整的监控能让我们更高效的发现和解决异常。

• 优化：优化就是前面提到的，合理且充分的使用硬件资源，让程序的表现更好。

• 防劣化：防劣化也是有很多事情可以做的，包括建立完善的线下性能测试，线上监控的报警等。比如内存，我们可以在线下每天通过monkey跑内存泄露并提前治理，这就是防劣化。

• 数据收益收集。学会用好A/B测试，学会关注核心价值的指标。比如我们做内存优化，一味的追求降低应用内存的占用并不是最优，内存占用的多，可能会让我们的程序运行更快，用户体验更好，所以我们需要结合崩溃率，留存等等这种体验核心价值的指标，来确定内存到底要不要继续进行优化或者优化到多少。

小结

上面就是我在多年的性能优化经验中总结出来的认知及方法论。只有了解了这些方法论，我们才能在进行性能优化时，如鱼得水，游刃有余。

作者：helson赵子健
链接：https://juejin.cn/post/7169486107866824717