一、性能問題
主要總結為4個類别：
1、卡頓：使用時避免出現卡頓，響應速度快，減少使用者等待的時間，滿足使用者期望。
2、crash：減低 crash 率和 ANR 率，不要在使用者使用過程中崩潰和無響應。
3、耗電：節省流量和耗電，減少使用者使用成本，避免使用時導緻手機發燙。
4、包大小
性能問題的主要原因，但歸根到底，不外乎記憶體使用、代碼效率、合适的政策邏輯、代碼品質、安裝包體積這一類問題。
二、卡頓分析
卡頓的場景有很多，主要有：UI 繪制、應用啟動、頁面跳轉、事件響應；根本原因可以分為兩大類：
1、界面繪制：主要原因是繪制的層級深、頁面複雜、重新整理不合理，該場景更多出現在 UI 和啟動後的初始界面以及跳轉到頁面的繪制上。
1.1、View的繪制中有三個核心步驟，通過Measure和Layout來确定目前需要繪制的View所在的大小和位置，通過繪制(Draw)到surface
1.2、繪制任務太重，繪制一幀内容耗時太長；主線程太忙了，導緻VSYNC信号來時還沒有準備好資料導緻丢幀。
1.3、性能問題需要借助相應的的調試工具，比如檢視 Layout 層次的 Hierarchy View、GPU Profile 工具Systrace UI 性能分析、調試GPU過度繪制、和靜态代碼檢查工具 Lint等，這些工具對性能優化起到非常重要的作用。
2、資料處理：該原因是資料處理量太大，一般分為三種情況，一是資料在處理 UI 線程，二是資料處理占用 CPU 高，導緻主線程拿不到時間片，三是記憶體增加導緻 GC 頻繁，進而引起卡頓。
三、卡頓的解決
1、布局優化，主要通過減少層級、減少測量和繪制時間、提高複用性三個方面入手。總結如下：
減少層級：合理使用ConstraintLayout、RelativeLayout和LinerLayout，合理使用Merge。
提高顯示速度：使用ViewStub，它是一個看不見的、不占布局位置、占用資源非常小的視圖對象。
布局複用：可以通過include、merge、标簽來提高複用。
盡可能少用wrap_content：wrap_content會增加布局measure時計算成本，在已知寬高為固定值時，不用wrap_content。
2，避免過度繪制
過度繪制是指在螢幕上的某個像素在同一幀的時間内被繪制了多次。在多層次重疊的UI結構中，如果不可見的UI也在做繪制的操作，就會導緻某些像素區域被繪制了多次，進而浪費了多餘的CPU以及GPU資源。
移除XML中非必須的背景，移除Window預設的背景、按需顯示占位背景圖檔
适時使用Color.TRANSPARENT，因為透明色Color.TRANSPARENT是不會被渲染的,他是透明的。
自定義View優化。使用canvas.clipRect()來幫助系統識别那些可見的區域，隻有在這個區域内才會被繪制。
3，啟動優化
啟動主要完成三件事：UI布局、繪制和資料準備。是以啟動速度優化就是需要優化這三個過程：
UI布局。應用一般都有閃屏頁，優化閃屏頁的UI布局，可以通過Profile GPU Rendering檢測丢幀情況。
啟動加載邏輯優化。可以采用分布加載、異步加載、延期加載政策來提高應用啟動速度。
資料準備。資料初始化分析，加載資料可以考慮用線程初始化等政策。
先測量activity的啟動時間-------Activity的reportFullyDrawn()方法
windowIsTranslucent設定成true，就可以讓程式在初始化的時候視窗是透明的，初始化結束後程式主界面才會顯示出來，進而也就完全看不到白屏界面了
android:Background設定為圖檔或者背景顔色
4、Application優化
很多第三方元件(包括App應用本身)都在 Application 中進行初始化
必要的元件一定要在主線程中立即初始化(入口 Activity 可能立即會用到)
重要元件的加載一定要在主線程中初始化，但是可以延遲初始化。
其他元件Bugly，x5核心初始化，SP的讀寫，友盟等元件放到子線程中初始化。(子線程初始化不能影響到元件的使用)
5，合理的重新整理機制
資料的變化，需要重新整理頁面來展示新的資料，但頻繁重新整理會增加資源開銷，并且可能導緻卡頓發生，
盡量減少重新整理次數。
盡量避免背景有高的CPU線程運作。
縮小重新整理區域。
四、降低Crash率
1、armeabi相容armeabi-v7和armeabi-v8a以及新的arm體系結構的問題，在gradle裡進行配置支援
2、Java層面借助于Android全局的異常捕捉方式比如Thread.setDefaultUncaughtExceptionHandler()等來實作
C/C++層面，則通過signal的捕捉來處理
3、代碼靜态處理方式和工具
代碼掃描和代碼靜态安全檢測工具可以使用Coverity或類似的工具
通過GodEyes-android或類似的工具進行掃描來避免可能觸發的Crash問題
4、Crash問題分析總結回報補充測試用例和測試場景，加強測試手段。
5、對于空指針問題，越界問題，類查找問題，資源查找問題，非法參數問題，資料傳輸超限問題，資源加載引起的逾時問題，資料庫問題，Bundle加載問題等通過代碼掃描工具以及靜态安全檢測工具并結合Code Review在編譯階段和代碼送出階段就盡可能避免，同時通過增加測試用例包括邊界點測試進一步避免Crash問題。