主要有以下三方面：
1.業務/功能
2.符合邏輯的互動
3.優秀的效能
android 系統作為以移動裝置為主的作業系統，硬體配置是有一定的限制的，雖然配置現在越來越高階，但仍然無法與 pc 相比，在 cpu 和記憶體上使用不合理或者耗費資源多時，就會碰到記憶體不足導致的穩定性問題、cpu 消耗太多導致的卡頓問題等。
具體的效能問題總結:
戶體驗的效能問題:
1.流暢
2.穩定
3.省電、省流量
4.安裝包小
快：使用時避免出現卡頓，響應速度快，減少使用者等待的時間，滿足使用者期望。
穩：減低 crash 率和 anr 率，不要在使用者使用過程中崩潰和無響應。
省：節省流量和耗電，減少使用者使用成本，避免使用時導致手機發燙。
小：安裝包小可以降低使用者的安裝成本。
要想達到這4個目標，具體實現是在右邊框裡的問題：卡頓、記憶體使用不合理、**質量差、**邏輯亂、安裝包過大，這些問題也是在開發過程中碰到最多的問題，在實現業務需求同時，也需要考慮到這點，多花時間去思考，如何避免功能完成後再來做優化，不然的話等功能實現後帶來的維護成本會增加。
卡頓上的優化:
ui 繪製、應用啟動、頁面跳轉、事件響應
這4種卡頓場景的根本原因可以分為兩大類：
1.介面繪製。
主要原因是繪製的層級深、頁面複雜、重新整理不合理，由於這些原因導致卡頓的場景更多出現在 ui 和啟動後的初始介面以及跳轉到頁面的繪製上。
2.資料處理。
導致這種卡頓場景的原因是資料處理量太大，一般分為三種情況，一是資料在處理 ui 執行緒，二是資料處理占用 cpu 高，導致主線程拿不到時間片，三是記憶體增加導致 gc 頻繁，從而引起卡頓。
造成卡頓的根本原因:
根據android 系統顯示原理可以看到，影響繪製的根本原因有以下兩個方面：
1.繪製任務太重，繪製一幀內容耗時太長。
2.主線程太忙，根據系統傳遞過來的 vsync 訊號來時還沒準備好資料導致丟幀。
繪製耗時太長，有一些工具可以幫助我們定位問題。主線程太忙則需要注意了，主線程關鍵職責是處理使用者互動，在螢幕上繪製畫素，並進行載入顯示相關的資料，所以特別需要避免任何主線程的事情，這樣應用程式才能保持對使用者操作的即時響應。總結起來，主線程主要做以下幾個方面工作：
除此之外，應該盡量避免將其他處理放在主線程中，特別複雜的資料計算和網路請求等。
解決卡頓的優化:
1，布局優化
布局是否合理主要影響的是頁面測量時間的多少，我們知道乙個頁面的顯示測量和繪製過程都是通過遞迴來完成的，多叉樹遍歷的時間與樹的高度h有關，其時間複雜度 o(h)，如果層級太深，每增加一層則會增加更多的頁面顯示時間，所以布局的合理性就顯得很重要。
那布局優化有哪些方法呢，主要通過減少層級、減少測量和繪製時間、提高復用性三個方面入手。
總結如下：
2，避免過度繪製
過度繪製是指在螢幕上的某個畫素在同一幀的時間內被繪製了多次。在多層次重疊的 ui 結構中，如果不可見的 ui 也在做繪製的操作，就會導致某些畫素區域被繪製了多次，從而浪費了多餘的 cpu 以及 gpu 資源。
如何避免過度繪製呢，如下：
3，啟動優化
通過對啟動速度的監控，發現影響啟動速度的問題所在，優化啟動邏輯，提高應用的啟動速度。啟動主要完成三件事：ui 布局、繪製和資料準備。因此啟動速度優化就是需要優化這三個過程：
4，合理的重新整理機制
在應用開發過程中，因為資料的變化，需要重新整理頁面來展示新的資料，但頻繁重新整理會增加資源開銷，並且可能導致卡頓發生，因此，需要乙個合理的重新整理機制來提高整體的 ui 流暢度。合理的重新整理需要注意以下幾點：
5，其他
在實現動畫效果時，需要根據不同場景選擇合適的動畫框架來實現。有些情況下，可以用硬體加速方式來提供流暢度。
SQL 提高效能
參考部落格 非常感謝博主分享。1.set nocount on 關閉行基數資訊，減少網路通訊，提高程式效能。2.count 1 count 2 count name count 前三種效果一樣，count 找出最短的列，所以建議用count 1 效率高。3.with nolock 大量的查詢，會導致...
android高效能編碼
學習郭霖大神部落格 一 避免建立不必要物件 拼接字串使用stringbuilder或者stringbuffer要比 連線符效能高，因為加號連線符會建立多與物件，拼接的字串越長，加號連線符的效能越低。2 盡量使用基本資料型別代替封裝資料型別，int比integer更加高效。二 靜態優於抽象 如果不需要...
開啟opcache提高效能
在開啟opcache之前，我們先介紹一下編譯與解釋 編譯器是把源程式的每一條語句都編譯成機器語言，並儲存成二進位制檔案，這樣執行時計算機可以直接以機器語言來執行此程式，速度很快 而直譯器則是只在執行程式時,才一條一條的解釋成機器語言給計算機來執行，所以執行速度是不如編譯後的程式執行的快的。解釋型語言...