app优化方法

APP核心价值肯定是在于业务的，因此我们传统上对于性能优化的态度都是有余力的时候来关注，哪怕在《Android应用性能优化》一书中也讲到“代码优化应该最后去做，甚至完全可能不用去做。”在这样的思路下，我们对性能问题的发现和解决都是严重滞后的。

然而从另外一个角度来看，越来越多数据表明，应用的性能对用户留存和活跃度都有很大影响（具体可以参考 Why You Should Care about Your Android App's Performance），并且受移动设备本身的性能限制，相比PC应用移动应用的性能优化尤其值得关注。事实上也有越来越多团队在加大这方面投入，例如Instagram团队花了一年时间做重构，优化性能。我们在这方面的投入也在逐渐加大。

回过头来思考为什么传统上，我们觉得性能问题应该最后关注。一方面诚然是因为核心价值在于业务，另外一方面是性能问题的分析和优化成本很高。因此目前大家的普遍手段是在APP中加入性能监控的代码，在线上发现问题后再来修复。

然而如果我们能把性能监控和修复的成本降低，将性能工作尽早介入到整个项目流程中，这样就可以从源头低成本地防止性能问题的产生，从而可以更专心做好业务。

在开发，测试，灰度，发布各个阶段对性能问题的关注和诉求是不一样的，所采取具体措施也有所不同。例如开发阶段主要是防止低性能的设计，编码，例如可以通过IDE插件在编码阶段就对低性能的代码进行告警。测试阶段，可以基于实验室环境，对卡顿，流量，IO，内存，启动速度等等性能数据进行详尽的自动化测试，越详细越好。灰度阶段是基于线上环境，对一些核心性能点进行监测。发布后则只针对一些核心指标进行粗粒度的监控。

前日偶然在《APK瘦身记》看到NibleDroid，发现其思想跟我们是一致的，并且自动化做的真的很好！只需上传一个APK包，从静态的方法数，包大小分析，到动态运行过程中的启动时间，内存开销，网络流量，IO读写，耗时函数，以及完整的函数trace都一目了然，而且还支持和历史版本的对比！由此可见，在这一块，我们跟业界的思考是一致的，并且他们已经走在前面。NibleDroid甚至接下去想自动帮你修复性能问题，上传一个包，它自动解包，自动修复性能问题，再自动打包，重新下载即可。我们需要加油学习赶上。

简单贴几张NibleDroid的功能截图，读者可以自行从对Facebook的分析中了解其完整的功能。

冷启动速度分析，直观看到启动时间，启动过程中耗时方法数，内存泄露，使用内存峰值，网络流量，磁盘IO。

具体的耗时函数与内存泄漏点

应用中各个知名SDK使用CPU的情况

完整的调用栈，有点类似于AndroidStudio中的TraceView，不过这里第二行表示各个线程。

时间线，横轴表示时间。表示各个线程在时间线上的执行情况。每个线程可以展开，看到具体的函数调用。

甚至还能直观地看到线程之间的锁。

此外还有包大小的分析，包括各个总大小，包含的大文件，各个知名SDK所占的大小，各种文件类型的大小。还有方法数分析等等，不一一列出，读者自己把玩一下就很清楚了。