Android的Java代碼優化

在深刻開發以前，你應該意識到代碼優化不是應用開發的首要任務。提供良好的用戶體驗並專一於代碼的可維護性纔是首要任務。

1.Android如何執行代碼

咱們須要分清楚：最終Android應用只包含Dalvik字節碼，而不是Java字節碼。

APK文件只是簡單的ZIP壓縮文件，能夠用常見的壓縮工具解壓。

Dalvik虛擬機是基於寄存器（虛擬寄存器，非真實的硬件寄存器），Sun的java虛擬機JVM是基於棧。

Java指令是16位的，JVM和DEX指令集基本也是16位。

Android2.2中引入了實時編譯器（JIT）。Dalvik JIT編譯器把Dalvik字節碼編譯成本地代碼，這樣能夠明顯加快執行速度。

在應用的manifest配置裏能夠用Android:vmSafeMode啓用或禁用JIT編譯器。默認是啓動。

2.Java算法優化

Java全部基本類型中（除了boolean），long是64位，int32位，short是16位。全部整數類型都是有符號的。

BigInteger對象能夠容納任意大小的有符號整數，這是解決不少數值超過64位後的一種解決方案。

基於性能方面的考慮，在代碼的關鍵路徑上要儘量避免內存分配。

優化每每使源代碼難於閱讀、理解和維護。強烈建議你先實現一個能運行的解決方案，而後再考慮優化。有一句高德納的名言：「過早的優化是噩夢之源」。

Java語言規範說了兩件事：A、Error類及其子類是普通程序中拋出的異常，它一般是不指望可以恢復的。B、精密的程序可能但願抓住這類異常並試圖從錯誤異常中恢復。

與直覺相反，並不是全部異常都是Exception的子類。全部異常都是Throwable的子類（只有Exception和Error是它的直接子類）。

 

3.緩存結果

Android定義了SparseArray類，當鍵值是整數時，效率比HashMap高。

android.util.LruCache這個3.1版本後的緩存工具類。仍是建議本身寫一個LRU。

API等級，試圖調用不存在的API將致使崩潰。能夠用反射來檢查是否存在SDK_INT字段（是否高於1.6版本）。不過反射會使代碼變慢，所以，在性能相當重要的地方應儘可能避免使用反射。替代的辦法是在靜態初始化塊裏調用Class.forName(),Class.getMethod()確認制定方法是否存在，在性能要求搞的地方只調用Method.invoke()便可。

指定maxSdkVersion可能致使Android更新後，應用自動被卸載，因此不建議指定max sdk version。

Android Market使用minSdkVersion和maxSdkVersion屬性來篩選可供特定設備下載安裝的應用，其它屬性也一樣能夠用來篩選。

 

4.響應能力

在Android基礎組件中的onSomething()方法都是由主線程（UI線程）調用。主線程主要處理：按鍵事件（onKeyDown等）、繪製View（onDraw）和調用生命週期（onCreate等）。應用只有一個主線程，全部的事件都按順序處理。

展開資源是一個開銷相對較大的操做，因此儘可能下降佈局的複雜性。幾個下降佈局複雜性的步驟：A、使用RelativeLayout代替LinearLayout，儘量「扁平化」設計佈局。此外，減小建立的對象數量。B、使用ViewStub推遲對象建立。

優化的基本原則是保持應用的持續響應，讓主線程儘量快得完成任務。

寫程序時，應該始終假定兩種狀況：A、網絡很慢。B、文件系統訪問速度很慢。結論就是不該該在主線程內進行網絡操做或者訪問文件系統。

StrictMode是檢測不良行爲的工具。注意：只在開發階段啓用StrictMode，發佈應用時，記得禁用。

5.SQLite

SQLite語句、事務和查詢。SQLite語句建立時，使用StringBuffer對象（推薦使用）或調用String.format能夠提升性能。

SQLite內部有虛擬機，處理字節碼指令。使用compileStatement讓語句在循環外只編譯一次。

顯示建立事務有如下兩個基本特性：原子提交和性能更好。一次性事務是解決批量或數據庫在持久存儲中的較好方法。

查詢時，只讀取須要的數據纔是上上之選。

以上內容是《Android應用性能優化》第一章節的讀後整理。如須要了解詳細內容或者深刻學習，請查看此書。後續讀後感請繼續關注本博客：

http://blog.csdn.net/forlong401