android應用優化主要從兩方面來考慮，其一是針對記憶體的優化，android裝置的記憶體相比較而言是比較珍貴，應及時**不再使用的記憶體，防止記憶體洩露；其二是針對性能的優化，防止使用者使用是出現卡頓，響應慢或anr。
效能調優android官方有指導性的文件，以及相關的除錯工具，可參考android developer
另外這裡有一篇文章總結android應用效能調優方案的專題，寫得不錯。
本文主要介紹如何使用mat與hierarchy view工具來進行記憶體優化以及如何使用trace view進行效能調優。
在進行記憶體優化前，需要明確的幾個問題：
如果順利解決了以上問題，則優化工作就取得比較理想的成果。
確認記憶體佔用量有兩種方式，
37150 kb: foreground
37150 kb: com.yunos.tv.launcherdemo (pid 14884)
記憶體洩露指的是記憶體中殘留一些物件，而這些物件在應用的後續流程中不再需要使用，但是由於被其它存活物件引用，所以其所占用的記憶體不能被**，隨著這種不可**的無用物件的積累，記憶體會被慢慢吞噬，最終導致outofmemory。
確定是否存在記憶體洩露的方法有兩種：
該圖會列出幾個嫌疑最大的類，包括其實例的數量以及所占用記憶體大小，根據這些資訊，可以分析這些物件包含其他那些物件以及各自的大小是多少、從該物件出發，到gc root的路徑是什麼、該物件被那些物件引用或者引用了哪些物件、該物件所屬類引用了其他哪些類或別其他哪些類引用，具體含義見下表：
選項含義
list objects-with outgoing references
以該物件為起點，向外的引用，指的是該物件引用的其他物件列表
list objects-with incoming references
以該物件為起點，向內的引用，指的是該物件被哪些物件引用
show objects by class-with outgoing references
以該物件所屬類為起點，向外的引用，指的是該物件所屬類引用了哪些類
show objects by class-with incoming references
以該物件所屬類為起點，向內的引用，指的是該物件所屬類類被哪些類引用
path to gc roots-with all references
從gc roots節點到該物件的引用路徑，包含所有引用型別
path to gc roots-exclude weak references
從gc roots節點到該物件的引用路徑，去除所有弱引用，其他類似
merge shortest paths to gc roots-with all references
從gc roots節點到該物件的最短引用路徑，包含所有引用型別
merge shortest paths to gc roots-exclude weak references
從gc roots節點到該物件的最短引用路徑，去除所有弱引用，其他類似
show retained set
列出該物件直接或間接占用的空間具體包含那些物件
通過上述步驟確定哪個類的例項存在洩露或者哪個類占用的記憶體過多，則基本可以通過**來排查記憶體洩露或記憶體瓶頸的位置。
記憶體洩露的最常見的方式是：在view中定義了非static的內部類，並將該內部類註冊到了第三方介面中或註冊到單例中，當view destory時，由於外部持有該view的引用，導致這個view不能被gc**。
常見的洩露場景以及解決方案
主要從以下三個方面來介紹：
工欲善其事，必先利其器。選擇乙個好的工具往往能做到事半功倍。traceview工具很強大，能快速定位出某個操作過程中，好時的操作在**。
在android studio中，使用traceview的步驟如下：
詳細使用方法可以參考[正確使用android效能分析工具——traceview
]( 與 android效能調優工具traceview介紹
android monitor device開啟traceview後，就可以分析應用在執行這個操作時，各個函式所花費的時間。如圖
traceview分為上下兩個主要部分，上面部分列出了應用中執行的所有執行緒在這段時間內的圖形化運**況，下面部分通過函式的樹狀呼叫，顯示了函式的執行時間。
下半部分的**中，標題欄含義如下表：
序號名稱含義1
incl cpu time %
當前函式及其呼叫的子函式執行時所佔cpu時間百分比
2incl cpu time
當前函式及其呼叫的子函式一共執行時所佔cpu時間
3excl cpu time %
當前函式執行時所佔cpu時間百分比(不包含呼叫子函式的執行時間)
4excl cpu time
當前函式執行時所佔cpu時間(不包含呼叫子函式的執行時間)
5incl/excl real time %/na
對比1~4，real time指的是實際執行時間，不包括cpu上下文切換等
6calls + recur calls / total
call表示這個方法呼叫的次數，recur call表示遞迴呼叫次數
7cpu time / call
該函式平均執行時間
8real time / call
該函式平均執行時間，不包括cpu上下文切換等
在了解上述指標後，可以比較直觀的看出各個函式執行時所占用的時間，而且能快速定位到時間最長的函式——也就是效能瓶頸。
一般可以抓住從三個方面切入：
找到效能瓶頸後，需要分析程式的執行流程，包括正常流程和異常流程。
可能的優化措施：
Android應用開發優化
最近總結了一些，android應用開發中，需要注意的一些事項，與大家分享 1.盡量少的宣告全域性變數 2.宣告全域性靜態變數，一定要加final宣告 3.宣告非靜態的全域性變數，最好不要初始化任何值，在使用到的地方，在進行初始化 4.函式中若干次使用全域性變數，應該將全域性變數賦值給本地變數，然後直...
Android應用優化之業務優化
作為程式開發者，我們應該也需要花費一些時間放在業務優化上。很多時候迫於時間的關係，當實現業務的方案並非最優。比如為了實現多張的上傳，很多人直接使用序列操作，儘管這樣比較容易達到效果，但並非最優。由於每個產品的業務並不相同，也就很難有通用的優化方案。首先我們先來設立兩個目標。1 如果有可能，序列業務並...
Android 應用啟動速度優化
開發android應用中，隨著功能越來越多，啟動速度越來越慢。有沒有辦法讓自己應用啟動速度快一點呢？方法是人想出來的。先說說我的實現方法 1 將oncreate 中初始化的內容，移動到執行緒中做初始化，載入等 2 初始化完成之後，通過handler傳送訊息，3 hander 中收到訊息後，再初始化完...