如何才能做好Android 性能优化？
从事Android开发的人应该都知道，无论是在工作中还是在面试中，性能优化都是一个绕不过的坎，尤其是在一些大厂中，他们对性能的要求把控很严格，甚至将其定位考核标准之中。
像以下场景或多或少，大家都有遇到过：
- 当你很努力地优化了应用的性能后，用户依然不断抱怨应用卡顿、启动速度慢等问题。
- 当 Leader 直接给到你性能优化的 KPI，内存要降多少，包体积要减多少时，你倍感压力，头疼不已。
- 面试时，面试官不断追问你在开发中做了哪些优化？效果怎样？为什么要这样做？有没更好的方案？难点在哪？
看上去这些问题不是很难，但对于一些只做业务层开发，没有深入的去了解底层知识点的人来说，就比较头痛了。因为优化相关的内容，有不少要涉及到Framework 底层的知识点（比如：启动优化、UI渲染优化等），如果对底层逻辑掌握的不是很好，就没办法做好相关的优化工作。
为什么这么说？
相信大多是开发在做性能优化时，首先都会去找别人之前做过的一些相关案例，然后在套用到自己的应用开发中，虽然此方法看着很好很快捷，但是中间出现了什么问题，一时之间很难快速的定位问题出在哪？即便定位到问题的所在，一但涉及到底层，一时之间也很难解决，因为最终的优化方法和底层优化的逻辑不是你所设计。
根据项目种类应用的场景不同，优化的方案也会有所不同，自然它们的特性也会不一样。比如说，大型应用业务多，中小型应用功能单一，还有 IO 密集型应用、CPU 密集型应用、强调稳定性的应用，以及强调内存低占用的应用等等。面对不用类型的应用和业务，网上的案例就有些捉襟见肘了。
其次，这样做出来的优化并不体系。就拿内存优化举例子，我们可能会先按照网上的方案治理一下内存泄漏，再按照网上的方案优化一下图片。这样做优化不仅零碎，效果可能也不好。体系的优化是一套能覆盖到大部分情况和场景的方案，比如针对 Native 内存的优化方案有 A、B、C，针对 Java 内存的优化方案有 D、E、F，方案中要能清晰说明为什么要这样优化，思路是什么，原理是什么，如何估量和评估效果等等。
如果我们在做优化前没有把这些问题考虑进去，而盲目的去做，最后发现所做的优化很零散，没有一个完成的优化路线，几乎是东拼西凑的这种感觉，更不用说在工作中有什么质的提升了。
这也就是为什么有的人做了好几年的性能优化工作，无论在晋升答辩，还是面试中，依然很难脱颖而出。
那性能优化该怎么做？
性能优化的本质就是让运行在操作系统上的程序更合理的使用硬件资源，所以我们需要从硬件、系统、应用这三个维度入手，才能打造完备的知识体系，真正做好性能优化。
想要精进，要知道如何利用工具做性能优化，还要对底层原理充分了解，对架构设计有一定经验，例如你从任务管理角度做启动优化，就需要精通图论与框架设计，同时还需要熟悉Framework层执行流程，如果你对IO进行优化，就必须精通MMAP原理与框架封装的常用技术等…
这样才算精通对某个领域的性能优化。
精通意味着：
- 在面试环节，性能就是最好的面试题，既能考察候选人的潜力，也能考察其工程能力；
- 在大厂晋升中，其他部门的高级专家在不熟悉候选人业务的情况下，只能去考察底层的硬核知识，而性能问题又是最有区分度的问题
当然，在一些面试中，也会看到一些朋友在简历上**写“精通性能优化”，**但是让其描述，往往就是一些自己编写的业务，一些去除页面多余嵌套、使用线程池、ViewStub 这些非常浅的方案。
其实更多的，面试官还是希望能够听到，线上复杂环境，低端机/弱网等因素下，用户触发的一系列的体验问题。
想要搞清楚这些，那么必须对底层原理有着深度了解，对各种case非常丰富的经验；很多人经常遇到措手不及的问题，大多是对出现问题的情况和处理思路模糊不清，导致此原因就是因为没有搞懂底层原理。
所以考虑到以上总总因素，为了帮助到大家更全面的掌握性能优化和Framework 底层原理，将其在项目中会涉及到的所有核心知识点，都记录在这《性能优化核心知识点》与《Framework 核心知识点》两册之中，便于大家参考。
《Android 性能优化核心笔记》：https://qr18.cn/FVlo89
- 启动优化
- UI渲染优化
- 奔溃优化
- 内存优化
- 卡顿优化
- 存储优化
- 网络优化
- 耗电优化
- 多线程并发优化
- 安装包优化
- ……
《Android Framework学习手册》：https://qr18.cn/AQpN4J
1.Handler 机制实现原理部分：
2.Binder 原理
3.Zygote
4.AMS源码分析
6.深入PMS源码
7.WMS
8.……
