本篇主要是對 google推出的效能優化典範 進行乙個通篇的整理… 主要在於一些具體的優化技巧、至於60fps、掉幀、gc、記憶體抖動、閾值…等等這些效能術語的概念裡面不做多概括，請自行查閱…
本篇從以下幾點延伸擴充套件…
systrace：systrace 在android ddms 裡自帶，可以用來跟蹤 graphics 、view 和 window 的資訊，發現一些深層次的問題。很麻煩，限制大，實際除錯中我基本用不到；
track：track 在 android ddms裡自帶，是個很棒的用來跟蹤構造檢視的時候哪些方法費時，精確到每乙個函式，無論是應用函式還是系統函式，我們可以很容易地看到掉幀的地方以及那一幀所有函式的呼叫情況，找出問題點進行優化。
避免在ondraw方法裡面執行物件的建立：類似ondraw等頻繁呼叫的方法，一定需要注意避免在這裡做建立物件的操作，因為他會迅速增加記憶體的使用，而且很容易引起頻繁的gc，甚至是記憶體抖動；
stringbuilder：在有些時候，**中會需要使用到大量的字串拼接的操作，這種時候有必要考慮使用stringbuilder來替代頻繁的「+」；
避免在for語句內建立物件；
…記憶體物件的洩漏，會導致一些不再使用的物件無法及時釋放，這樣一方面占用了寶貴的記憶體空間，很容易導致後續需要分配記憶體的時候，空閒空間不足而出現oom。
顯然，這還使得每級generation的記憶體區域可用空間變小，gc就會更容易被觸發，容易出現記憶體抖動，從而引起效能問題。
最新的leakcanary開源控制項，可以很好的幫助我們發現記憶體洩露的情況，更多關於leakcanary的介紹，請看這裡 中文使用說明。另外也可以使用傳統的mat工具查詢記憶體洩露，請參考這裡（便捷的中文資料）
activity context被傳遞到其他例項中，這可能導致自身被引用而發生洩漏：
注意臨時bitmap物件的及時**
注意***的登出：
注意快取容器中的物件洩漏：
注意webview的洩漏：
注意cursor物件是否及時關閉：
綜合考慮裝置記憶體閾值與其他因素設計合適的快取大小：
onlowmemory()與ontrimmemory()：
android使用者可以隨意在不同的應用之間進行快速切換。為了讓background的應用能夠迅速的切換到forground，每乙個background的應用都會占用一定的記憶體。android系統會根據當前的系統的記憶體使用情況，決定**部分background的應用記憶體。如果background的應用從暫停狀態直接被恢復到forground，能夠獲得較快的恢復體驗，如果background應用是從kill的狀態進行恢復，相比之下就顯得稍微有點慢。
當應用程序退到後台正在被cached的時候，可能會接收到從ontrimmemory()中返回的下面的值之一：
請注意：當系統開始清除lru快取中的程序時，雖然它首先按照lru的順序來執行操作，但是它同樣會考慮程序的記憶體使用量以及其他因素。占用越少的程序越容易被留下來。
try catch某些大記憶體分配的操作:
資源檔案需要選擇合適的資料夾進行存放
謹慎使用static物件：
特別留意單例物件中不合理的持有：
珍惜services資源
優化布局層次，減少記憶體消耗
謹慎使用「抽象」程式設計
謹慎使用依賴注入框架
謹慎使用多程序：
使用proguard來剔除不需要的**
謹慎使用第三方libraries：
heap viewer：檢視當前記憶體快照，便於對比分析哪些物件有可能發生了洩漏。
乙個處於完全工作狀態的無線電會大量消耗電量，因此需要學習如何在不同能量狀態下進行過渡，當無線電沒有工作時，節省電量，當需要時嘗試最小化與無線電波供電有關的延遲。
典型的 3g 無線電網路有三種能量狀態：
使用預取（prefetching）與**（bundle）的方式進行資料的傳輸，這些操作都是為了最小化電量的消耗。
如：當電池低於20%時 給出提示「請充電…」
….battery historian是android 5.0開始引入的新api。通過下面的指令，可以得到裝置上的電量消耗資訊：
$ adb shell dumpsys batterystats > ***.txt //得到整個裝置的電量消耗資訊
$ adb shell dumpsys batterystats > com
.package
$ python historian.py ***.txt > ***.html開啟這個轉換過後的html檔案，可以看到類似traceview生成的列表資料，這裡的資料資訊量很大，這裡就不展開了。
開啟乙個執行緒 大概耗時4*10^6 納秒 與 64k+記憶體；
了解這些系統提供的多執行緒工具類分別適合在什麼場景下，可以幫助我們選擇合適的解決方案，避免出現不可預期的麻煩。雖然使用多執行緒可以提高程式的併發量，但是我們需要特別注意因為引入多執行緒而可能伴隨而來的記憶體問題。舉個例子，在activity內部定義的乙個asynctask，它屬於乙個內部類，該類本身和外面的activity是有引用關係的，如果activity要銷毀的時候，asynctask還仍然在執行，這會導致activity沒有辦法完全釋放，從而引發記憶體洩漏。所以說，多執行緒是提公升程式效能的有效手段之一，但是使用多執行緒卻需要十分謹慎小心，如果不了解背後的執行機制以及使用的注意事項，很可能引起嚴重的問題。
由於時間關係先寫到這裡，待續…
Android效能優化
android效能優化 1.http用gzip壓縮，設定連線超時時間和響應超時時間 http請求按照業務需求，分為是否可以快取和不可快取，那麼在無網路的環境中，仍然通過快取的httpresponse瀏覽部分資料，實現離線閱讀。2.listview 效能優化 1 復用convertview 在geti...
Android效能優化
1.節制地使用service 如果應用程式當中需要使用service來執行後台任務的話，請一定要注意只有當任務正在執行的時候才應該讓service執行起來。另外，當任務執行完之後去停止service的時候，要小心service停止失敗導致記憶體洩露的情況 2.當介面不可見時釋放記憶體 當使用者開啟另...
Android效能優化
本篇主要是對 google推出的效能優化典範 進行乙個通篇的整理 主要在於一些具體的優化技巧 至於60fps 掉幀 gc 記憶體抖動 閾值 等等這些效能術語的概念裡面不做多概括，請自行查閱 本篇從以下幾點延伸擴充套件 systrace systrace 在android ddms 裡自帶，可以用來跟...