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元素，統(tǒng)統(tǒng)在布局文件寫出來，在oncreateView的時候將所有的元素都初始化套啤，但當前不需要展示的view設置成gone彤侍，對用戶不可見肠缨。
這樣固然可以滿足功能需求，但對于啟動性能卻是很不利的盏阶，因為設置成gone的view晒奕，還是需要inflate，需要實例化名斟，因而會耗費頁面初始化的時間和內存脑慧。因此將不需要顯示的view用viewstub占位，在需要顯示的地方在去inflate和顯示砰盐。
2. 延遲初始化
很多的組件闷袒，并不是進入頁面立即需要用到的，而是在特定情況下或用戶喚起才會使用到岩梳。那么這些的初始化就可以延后囊骤，在需要用到的時候再進行初始化，以實現資源和cpu的按需分配和使用冀值，減小啟動耗時淘捡。
3. 布局優(yōu)化
3.1 include/merge 標簽
在業(yè)務開發(fā)中，有很多view是可以共用的池摧，這些共用的組件可以使用inclue標簽焦除，實現view的復用，既優(yōu)化了代碼的清晰度作彤，又減小了開發(fā)成本膘魄。
但include的使用可能引起布局層級加深的問題乌逐，可以用merge標簽，讓系統(tǒng)刪除沒有必要的層級嵌套创葡。
3.2 冗余組件清理
布局基本一致浙踢，但又有微小的差別可以使用同一個組件實現。如果分別些組件灿渴，自然加大了布局初始化和渲染的成本洛波，因此可以組合成一個組件使用。
另外在業(yè)務迭代的過程中骚露，因為視覺的變化蹬挤，組件的布局也在變化，這個過程往往容易產生一些冗余的垃圾組件棘幸，需要隨時關注和清理焰扳，避免無用的組件損耗用戶使用app的性能。
3.3 布局層級縮減
有時候误续，本來是一個非常簡單的布局吨悍，卻 嵌套了多級RelativeLayout 和多級 LinearLayout ！這種看起來很低級的錯誤蹋嵌，往往發(fā)生在業(yè)務迭代的過程中育瓜，發(fā)現了立即精簡布局吧。
另外栽烂，對于簡單布局爆雹，LinearLayout 和FrameLayout的性能優(yōu)于RelativeLayout，但是RelativeLayout可以實現相對布局愕鼓，因此钙态，若是需要2級以上LinearLayout嵌套才能實現的布局，1級 的RelativeLayout 去實現更好菇晃。
4. 線程優(yōu)化
在activity啟動過程中册倒，非常耗時又不是絕對重要的操作，應該在非主線程執(zhí)行磺送，否則阻塞主線程驻子，導致啟動變慢；
絕對重要又一般耗時的操作應該放在主線程估灿，如頁面中決定整個頁面初始化信息獲取的網絡請求崇呵，因為整個頁面的渲染和信息展現都依賴于這個請求的結果，若請求的結果遲遲不回來馅袁，頁面開啟也沒辦法快域慷。
常見的耗時操作：
（1）Service化的業(yè)務 getService方法
（2） 網絡請求的構造和請求耗時
（3）文件讀寫操作
（4）遍歷查找操作 等等
5.方法執(zhí)行效率的優(yōu)化
注意方法的執(zhí)行效率，比如查找匹配的算法，不同的算法耗費的cpu資源都會不一樣
6. 緩存
同樣的信息犹褒，又很多地方都需要使用抵窒，這時候每個地方各自請求和處理嗎？ 這必定是一種浪費叠骑，對于需要用到的信息李皇，提前請求緩存下來，需要用到的時候便可以直接提取宙枷，自然就節(jié)約了cpu資源掉房。
7. 工具
整個優(yōu)化主要采用trace view工具測試和發(fā)現耗時問題，找到耗時點之后一一攻破慰丛。
traceview真的很強大卓囚，關于這個工具的使用可參考：http://bxbxbai.github.io/2014/10/25/use-trace-view/
androidstudio 3.0之后ddms的入口沒了，新的方式參考這個：https://developer.android.google.cn/studio/profile/monitor.html
