1.ViewStub的使用
官方解释：A ViewStub is an invisible, zero-sized View that can be used to lazily inflate layout resources at runtime.
一个activity的布局里面有很多的view，但往往并不是全部都会展现给用户的UI，很多的浮层或组件，都是在特定情况下才需要展示给用户的。之前的方式，时全部的UI元素，统统在布局文件写出来，在oncreateView的时候将所有的元素都初始化，但当前不需要展示的view设置成gone，对用户不可见。
这样固然可以满足功能需求，但对于启动性能却是很不利的，因为设置成gone的view，还是需要inflate，需要实例化，因而会耗费页面初始化的时间和内存。因此将不需要显示的view用viewstub占位，在需要显示的地方在去inflate和显示。
2. 延迟初始化
很多的组件，并不是进入页面立即需要用到的，而是在特定情况下或用户唤起才会使用到。那么这些的初始化就可以延后，在需要用到的时候再进行初始化，以实现资源和cpu的按需分配和使用，减小启动耗时。
3. 布局优化
3.1 include/merge 标签
在业务开发中，有很多view是可以共用的，这些共用的组件可以使用inclue标签，实现view的复用，既优化了代码的清晰度，又减小了开发成本。
但include的使用可能引起布局层级加深的问题，可以用merge标签，让系统删除没有必要的层级嵌套。
3.2 冗余组件清理
布局基本一致，但又有微小的差别可以使用同一个组件实现。如果分别些组件，自然加大了布局初始化和渲染的成本，因此可以组合成一个组件使用。
另外在业务迭代的过程中，因为视觉的变化，组件的布局也在变化，这个过程往往容易产生一些冗余的垃圾组件，需要随时关注和清理，避免无用的组件损耗用户使用app的性能。
3.3 布局层级缩减
有时候，本来是一个非常简单的布局，却 嵌套了多级RelativeLayout 和多级 LinearLayout ！这种看起来很低级的错误，往往发生在业务迭代的过程中，发现了立即精简布局吧。
另外，对于简单布局，LinearLayout 和FrameLayout的性能优于RelativeLayout，但是RelativeLayout可以实现相对布局，因此，若是需要2级以上LinearLayout嵌套才能实现的布局，1级 的RelativeLayout 去实现更好。
4. 线程优化
在activity启动过程中，非常耗时又不是绝对重要的操作，应该在非主线程执行，否则阻塞主线程，导致启动变慢；
绝对重要又一般耗时的操作应该放在主线程，如页面中决定整个页面初始化信息获取的网络请求，因为整个页面的渲染和信息展现都依赖于这个请求的结果，若请求的结果迟迟不回来，页面开启也没办法快。
常见的耗时操作：
（1）Service化的业务 getService方法
（2） 网络请求的构造和请求耗时
（3）文件读写操作
（4）遍历查找操作 等等
5.方法执行效率的优化
注意方法的执行效率，比如查找匹配的算法，不同的算法耗费的cpu资源都会不一样
6. 缓存
同样的信息，又很多地方都需要使用，这时候每个地方各自请求和处理吗？ 这必定是一种浪费，对于需要用到的信息，提前请求缓存下来，需要用到的时候便可以直接提取，自然就节约了cpu资源。
7. 工具
整个优化主要采用trace view工具测试和发现耗时问题，找到耗时点之后一一攻破。
traceview真的很强大，关于这个工具的使用可参考：http://bxbxbai.github.io/2014/10/25/use-trace-view/
androidstudio 3.0之后ddms的入口没了，新的方式参考这个：https://developer.android.google.cn/studio/profile/monitor.html
