Android性能功耗问题总结
误区：花费90%的精力去解决10%的性能优化
目标：花20%的精力去解决80%的关键性能优化
问题分类
启动慢（启动时间优化），卡顿（渲染优化）
- 启动慢：分冷启动和热启动
启动慢大部分是因为卡顿，根据测试标准不同，也可能是因为动画或者通知UI线程更新的时间点晚了，比如延时显示某个View
- 卡顿：
卡顿的主要原因是UI线程被阻塞，当绘制一帧超过16ms，将发生丢帧，当丢帧超过30帧时，Choreographer将打印log提示：
Skipped xx frames! The application may be doing too much work on its main thread.
60 * 16 = 960ms 60fps流畅
冷启动是需要优化onCreate和onResume的过程
热启动是需要优化onResume的过程
如何查看冷启动和热启动的耗时？
- 冷启动：关键log ActivityManager: Displayed可以直接看时间
起点：ActivityManager_activity: startActivityMayWait
终点：ActivityManager: EVENT_APP_ACTIVITY_DISPLAYED_FINISH reportData:
adb shell am start -W -S <包名/完整类名>
- 热启动：关键log onResume
起点：ActivityManager_activity: startActivityMayWait
终点：WindowManager: finishDrawingWindow
启动时间优化：
1.使用ViewStub延迟加载
2.如果使用fragment可以分步载入，不要一次全部显示
3.非UI事务放到子线程或者使用handler延迟执行
4.简化初始化的流程，优化UI布局
渲染优化：
场景：
1.绘制的层级深、页面复杂
2.数据处理：UI线程处理数据，数据处理线程繁忙抢占CPU
3.频繁GC
渲染优化解决方法：
使用Merge标签（减少层级）
RelativeLayout避免嵌套，LinearLayout避免使用权重（https://blog.csdn.net/l_215851356/article/details/56695722）
考虑使用ConstraintLayout
使用ViewStub
如果有确定值，避免wrap_content
避免数据处理卡主线程
性能问题与内存
多线程带来的内存问题
有时候为了性能，会把一个操作抛到子线程，很多时间写起来方便，就直接通过写new Thread(){…}.start();的方式来实现，这种方式每次都创建一个Thread，压力测试时可能会短时间内创建大量线程，如果是网络请求，还会产生大量socket链接，内存开销大，可能产生OOM。
有的使用线程池，但是使用cached或者fixed等Executors创建出来简单的线程池，没有设置拒绝策略，如果大量地加到线程池中，阻塞队列无限增加，也可能产生OOM。
还有一种使用ThreadHandler，在应用退出时HandlerThread没有quit，导致HandlerThread不能释放，产生内存泄露，长时间压力测试可能出现OOM。
高内存带来的性能问题
当内存很低，不足以分配给新对象时，会触发GC，这个耗时会引起实际执行时间的增加，比如当load一张特别大的图片时候就可能触发GC，这时候就会发生卡顿。
所以性能问题和内存问题是相关的，但性能问题中很多时候都伴随着内存问题，在解决性能问题的时候要考虑会不会引入内存问题，修改问题时需要选择一个让两者都高效折中值。
内存泄露常见场景
资源使用未关闭
注册广播，listener未注销
非静态内部类滥用
单例滥用
Handler阻塞
使用Android device monitor，Android profiler分析
非正常使用的情况：
1.调用了wakelock没有释放
2.某个高优先级的进程对某个低优先级进程的Service设置了死亡后重启，当低内存的情况，低优先级的service不停地被系统杀掉，高优先级的进程不停地收到回调，重新拉起servie并做一些初始化操作。
3.进程中起了一个永远不会停的操作，如使用百度定位sdk，启动了，成功定位后没有关掉，导致一直循环定位。
4.误操作的终止条件太高。如语音误唤醒，语音唤醒分两次，第一次会做一些初始化操作来提速，等第二次真正唤醒后再拉起界面，如果第二次确认是误唤醒就销毁。如果初始化过程不能有效被打断，销毁过程将被滞后，导致每次误唤醒都是一次完整的初始化和销毁。原本从第一次唤醒到确认是误唤醒只有2s，但是等到真正整个过程终止可能要花10s甚至半分钟，功耗成几十倍增长。
《Android移动性能实战》（腾讯SNG专项测试团队 编著）
http://www.cnblogs.com/cr330326/p/8011523.html
https://blog.csdn.net/yingshukun/article/details/79304817
熟悉业务
理解原理
大胆猜测
动手验证