本文并非讲述Android性能优化方案，主要是回顾2019年我在公司App性能优化方向上的所做的工作和思考，其中包括没做好的事项和“假如再给我一次机会的假想”（这里是哭的表情）。
性能优化也需要ROI
作为Android开发，大部分同学可能会对性能优化这个Topic如数家珍，Google官方在几年前也有“Android性能最佳实践系列”(Android Performance Patterns)，当然，其中大部分的Tips都是需要大家遵循的规范，但是无论理论上怎么说，我们所做的工作最终还是需要为业务服务，不管你是为了提高下载量、优化用户评价、还是提高业务的转化率，都需要给出性能优化的ROI。
数据比直觉重要
当开始做性能优化，你私以为，或者看过很多文章之后觉得内存肯定是需要优化的，所以提出要优化App的内存的时候，很多人（尤其是你的老板）会提出质疑，为什么不是CPU或是其他？毕竟不是每个人都熟读过“Android性能最佳实践系列”，这时候你需要给出数据来说明这一点，尴尬的是，很多拍脑袋得出的结论（要优化内存）往往会被证明并不是很重要，所以首先，我们花了一些时间，找到了各项常用的性能指标对转化率等业务指标的关系，以此量化了一些结论并决定了需要重点优化哪些性能问题。
解决主要矛盾
分析了各项数据之后我们认为，卡顿问题对业务来说的影响很大（只是假设），这时候我们会陷入系统性的思考，如何设计APM系统？如何保证以后类似卡顿不会再出现？如何预防等等。系统性地彻底解决这个问题固然很好，但是眼下还有一周就要发布新版本，现在收到的各方反馈是App运行缓慢，甚至有用户投诉发生了ANR等等问题。
在没有系统支撑的情况下，我们应该把这些显而易见的，对用户影响评估较严重的卡顿问题优先解决，这在才是当下的主要矛盾。
再举个例子，网络请求的成功率和耗时一直是性能优化的重点，但是如何优化？是不是每个请求都需要优化？答案当然是否定的，请求的接口数以百计，如果消耗太多精力在非重要接口上，很容易事倍功半。事实上，我们仅仅针对请求量大、成功率低、耗时高的主流程关键请求做重点的优化，这部分才是会影响用户体验的首要因素。
APM的闭环系统设计
作为基础部门，我们主要负责性能的采集、上报和监控，至于具体的优化落实需要各业务部门的配合，一般来说APM系统有无线端的SDK、后端数据处理和存储、前端性能数据看板和一些报警等等，但实际上我发现，这样还不够。
我希望APM系统不仅仅是App Performance Monitor，更是App Performance Manager，即能够做到性能优化的管理。除了上述的流程外，还应该包括预防、辅助排查和优化、问题反馈和解决，所以我们在设计中加入了比如
- 性能的自动化测试用于预防性能问题
- 本地的性能检测调试开发工具，使得业务开发同学可以更好地排查性能问题
- 每个性能都分派到团队甚至个人，解决完成后标记处理（很遗憾，这点还没有落实）
等等环节，这样整个APM系统的流程就变成了：开发期使用工具检测问题->公测期间自动化测试预防线上性能问题->上线之后观察性能问题并报警分派->业务同学解决之后标记处理->下个版本上线前清空问题。
团队间的配合和落实
从0到1建立这套体系和流程不会是简单的事情，我们在刚开始推进性能优化的时候遇到了很多阻碍，其中一点就是，如何让业务同学的思想上（为什么需要做优化）和行动上（及早优化上线）能够和基础团队高度一致？刚开始我们只是蒙头做APM系统，然后把新功能提供给业务同学使用，慢慢发现实际上很少有团队会主动使用和做优化，导致团队间始终不在一个频道上。
后来的方式是，一方面我们基础团队继续完善系统，另一方面我们每周都会选择一两个有代表性的页面，围绕这个页面结合APM系统去给相关业务团队做性能的检测报告，虽然这个过程是人工的，但是几周的报告之后，业务的积极性会被调动起来，后面就会慢慢接触使用APM并开始做优化。
这个过程有几个好处
- 性能优化推进落实更顺畅
- 团队和个人的技术影响力会加强
- 团队间的沟通会加强，或许“感情”也可以得到培养
其他细节
有效的报警
报警的关键在于不漏报，不多报，报警对象精确到人。尤其是多报约等于不报，撒网式地报警意味着没人承担责任。
性能指标的标准
一开始的性能优化可以用项目的方式推进执行，但如果需要将性能保持好，那还需要制定标准，每个版本都确保按标准执行。
简单优于复杂
复杂的标准、复杂的系统、复杂的指标一般来说都容易夭折，所以务必考虑长期维护的可行性。
最后，我想说，希望大家在被产品、业务方催促交付的同时，要有开发者的坚持，从对用户负责的角度，在繁忙的业务开发之外，花一点时间做性能优化吧。
