Android 性能处理

写SharedPreferences的apply函数需要注意，因为Commit函数会阻塞IO，这个函数虽然执行很快，但是系统会有另外一个线程来负责写操作，当apply频率高的时候，该线程就会比较占用CPU资源。类似的还有统计埋点等，在主线程埋点但异步线程提交，频率高的情况也会出现这样的问题。优化过程就是删除不必要的io操作，有些做延后处理。例如统计数据，淘宝减少了采样的频率，并且增加缓存数量，以空间换时间，减少数据库和SharedPreference的读写。在做较多数据库操作的时候也会开启事务功能来减少IO的次数。
其次查看布局性能，一种是直接查看，如onMeasure，OnLayout函数占用的百分比和平均执行时间过高导致的性能问题，很直观就可以看出来。还有就是例如getview中的布局性能，整体的查看inflate的个数和耗时问题的跟踪。还有一种是通过View的draw函数或者buildeDisplayList函数的调用和递归调用次数来判断布局的复杂度。
关于复用问题，比如在listview滑动过一遍后，在对这部分区域做跟踪，如果getview中还有infalte布局，那就是复用还有可以优化的地方。
类的初始化耗时，像构造函数，静态初始化等这些问题很容易忽视，但是在性能优化的后期，这些小的细节点，也是优化的方向，特别是在主线程中调用的时候。

以前在启动阶段会安装主要模块的bundle，首页再启动后过3秒也会发送通知来唤起更多的模块，像淘宝的webview框架，在初始化的时候会把线上活动资源都缓存到本地，这个过程设计到json的解析，下载和解压缩等，非常耗资源等等，这些模块叠加在一起就导致了首页就会直接卡主及白屏很长一段时间，所以对这一种模块改为懒加载，并且要限制拉取活动的数量。还有像购物车，微淘，店铺，旺信等以前是首次启动会安装，也是改为懒加载。因为首次Dexopt会比较费时，特别是安卓5.0以后，所以很多模块都改为懒加载，这样首次使用该模块的时候变慢一点，但是整体启动速度一下就提升了。
首页在欢迎页的时候开始初始化布局等，加快展示。退出的时候以前都是销毁Activity的，为了加快下次启动，释放到图片等主要资源，Activity不做销毁。

发现性能问题的时候首先要分析原因，是卡住还是卡顿，是网络慢的问题，还是是内存问题亦或是其他系统的问题。手淘遇到有时候手机厂商的一些特殊控件的bug也会导致问题。安卓系统本身的内存管理和一些监控软件有时候也会导致性能问题。
通过多种工具额配合找出问题。
有些问题，一个地方存在很可能其他地方也有，可以到类似的模块去查看，如圆形的图案，输入控件在输入法退出时引发的自动刷新问题。
建立程序内的监控，以及代码层面的扫描等，添加性能监控的模块可以实时监控和统计程序中的性能问题。