1 启动加速
1.1 合理利用启动白屏
应用启动会有一个短暂白屏时间，通过设置activity的windowBackground属性来控制白屏显示内容，达到应用秒启动的效果。
1.2 第三方应用初始化
将第三方服务的初始化放入工作线程中(10%左右的提升)
private void initThirdService(){
new Thread(() -> {
initARouter();
initEaseUI();
initAppConfig();
initUMeng();
}).start();
}
1.3 延时加载
对于一些时间上要求不是那么严格的数据加载，可以考虑延时加载。
AppApplication.getInstance().postDelayed(() -> mGetVersionPresenter.getVersion(), 2000);
1.4 优化实例
ThisTime: 1770
TotalTime: 1770
WaitTime: 1800
把第三方库的初始化放入工作线程中
ThisTime: 1521
TotalTime: 1521
WaitTime: 1543
通过方法耗时分析，找出耗时方法，然后进行优化。
ThisTime: 1307
TotalTime: 1307
WaitTime: 1388
2 查看每个页面启动时间
2.1 命令行
命令行如下：
adb shell am start -W hggtool.hotelgg.com.hggres/com.hotelgg.sale.ui.activity.LionHomeActivity
W大写，LionHomeActivity全路径。
2.2 踩坑路径
踩坑路径：首先启动了app的首页，然后去执行上述命令行。结果提示如下：
Warning: Activity not started, its current task has been brought to the front
Status: ok
Activity: hggtool.hotelgg.com.hggres/com.hotelgg.sale.ui.activity.LionHomeActivity
ThisTime: 0
TotalTime: 0
WaitTime: 75
Complete
如上述提示，Activity并没有被启动，Activity已经处于当前栈顶。
于是，关闭了当前页面，再执行上面的命令行，果然有效。
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=hggtool.hotelgg.com.hggres/com.hotelgg.sale.ui.activity.LionHomeActivity }
Status: ok
Activity: hggtool.hotelgg.com.hggres/com.hotelgg.sale.ui.activity.LionHomeActivity
ThisTime: 1730
TotalTime: 1730
WaitTime: 1817
Complete
这时，想着启动别的页面，又发现了一个错误：
java.lang.SecurityException: Permission Denial: starting Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=hggtool.hotelgg.com.hggres/com.hotelgg.sale.ui.activity.OrderActivity } from null (pid=14886, uid=2000) not exported from uid 10397
来来来，圈出关键字exported，这个单词很熟悉呀，在manifest中可以对每个activity和service进行定义。于是设置android:exported="true"代码后，问题迎刃而解。nice！！
2.3 查看每个方法调用的时间
选中trace java methods，然后点击record-stop来圈出自己需要的时间段。
以下图可以按执行时间从多到少进行排序，如果发现本地方法调用时间过多，可以相应进行优化。
3 各种优化整理
3.1 布局相关
1、尽量减少布局嵌套
2、有布局嵌套时，注意不要重复定义背景色，即子控件如果背景色可以覆盖父控件，那么父控件不需要再次定义背景色；父控件和子控件如果背景色相同，那么只用写一个背景色属性。
3、能用LinearLayout和FrameLayout，就不要用RelativeLayout。
4、ConstraintLayout，ViewStub的使用。
3.2 绘制相关
View的绘制频率保证60fps是最佳的，尽量降低onDraw方法中的复杂度。所以在onDraw中不要创建新的局部对象，不要做耗时的任务。
3.3 防止内存泄漏
整体来说，内存泄漏，一个较短生命周期的对象，被一个较长生命周期的对象引用或持有，从而导致较短生命周期对象无法被GC回收。
1、比如该传递application对象的地方，传递了activity。
2、非静态内部类handler的使用。
3、一些资源的释放和回收，比如数据库，io流，bitmap等。
4、静态集合的不合理使用，比如进行回收和清理的逻辑，导致只增不减。
在非静态内部类handler的使用中，会引起一个话题，强，软，弱，虚引用问题。
软引用：内存不足时进行回收；
弱引用：GC触发时进行回收。
虚引用：GC触发时进行回收，为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知，可以作为对象回收的监听器。如果一个对象被虚引用持有着，那么当垃圾回收时，对象将被回收，但是虚引用会加入到一个引用队列中去，我们可以通过队列知道哪些对象被回收了。
在activity中使用非静态handler内部类，一般容易发生内存泄漏。针对这个问题，有两点优化。
第一，handler修改为静态；
第二，在activity的onDestroy方法中调用handler的removeCallbacksAndMessages方法。
经过实验，其实只做第二点优化也是可以的，但是还是有可能出现泄漏，因为gc时机不确定，如果removeCallbacksAndMessages调用立马gc，这时其实是有可能不能回收掉相应的activity。
所以修改为静态内部类，其生命周期与应用等同，引用的上下文为application，直接消除了这个顾虑。
3.4 Bitmap优化
3.5 其他优化
1、重用资源，比如三角形按钮，可以通过旋转生成另外一种图片形式。
2、合理使用矢量图。
3、使用xml中的<shape>标签创建一些简单的图形。
4、一些重量级操作及时资源释放。
