關于Android內存管理及性能優化的一些細節
1、使用優化過的數據容器。
在Android framework下，建議使用優化過的數據容器比如：SparseArray,SparseBooleanArray,LongSparseArray。通用的HashMap實現的內存使用率非常的低，因為他需要為每一個mapping創建一個分離的entry object。另外，SparseArray類避免了系統對有些key的自動裝箱，因而帶來了更高的效率。2、注意內存的開銷。
注意你使用的語言和第三方庫的成本和開銷，要自始至終的將這些因素考慮在你的程序設計中。通常，有些事情表面上看著沒什么問題但實際上的開銷讓人驚嘆。比如：·枚舉相對于靜態常量來說，需要兩倍甚至更多的內存。你應該完全避免在Android中使用枚舉。
·每一個在java中的類（包括匿名內部類）使用大約500 bytes的代碼量。
·每一個類的實例擁有12-16 bytes的RAM消耗。
·放置一個單獨的實體到HashMap中，一個額外加的實體對象分配需要花費32 bytes。
</span></span>
3、關于代碼的抽象
抽象是一個好的編程的基礎，因為抽象可以提高代碼的靈活性和可維護性。然而抽象也帶來了一定的花銷，一般情況下，他們有更多的代碼需要執行，需要更多的時間和更多RAM來將這些代碼映射到內存中。因此，如果你的抽象不能帶來巨大的好處，你就應該割掉你的贅肉。</span>
4、避免依賴注入框架
雖然注入框架給我們帶來了很多方便，但是在使用這些框架的時候，框架需要花費很多時間來掃描我們自己寫的代碼，甚至會將哪些你根本不需要的東西也加載到內存中。</span>
5、小心的使用擴展庫
很多擴展庫的代碼不是針對手機環境開發的，可能在用到移動客戶端的時候會導致很低的效率。因此在使用之前，需要評估一下其占用內存的大小。即使庫針對手機開發，也會有潛在的危險，因為每一個Library做的事情不盡相同。比如，一個Library使用nano protobufs而另一個使用micro protobufs。現在，在你的app中就有兩個protobuf。類似情況經常發生。
</span>
6、使用混淆器移除不必要的代碼
ProGuard工具通過移除無用代碼，使用語意模糊來保留類，字段和方法來壓縮，優化和混淆代碼。可以使你的代碼更加完整，更少的RAM 映射頁。</span>
7、使用多個進程（注意是process 不是 thread ok？）
如果這適合你的app，可能幫助你管理你的app的內存就是將你的app多個部分分配到多個進程中。該技術必須小心使用并且大多數應用不應該運行在多個進程下。這個技術的主要應用是后臺工作跟天臺工作一樣重要的情況下。典型應用就是：當音樂播放器從服務器下載并長時間播放音樂，一般將其分為兩個進程：一個是 UI，另一個位置后臺服務的運行。</span>like this:
</span>
<service android:name=".PlaybackService" android:process=":background" />
process后面需要記住要有個":",這表示該進程屬于你的app。
一般情況下，一塊基本的空進程需要的內存大小在1.4m左右。
adb shell dumpsys meminfo com.example.android.apis:empty
8、基本性能優化方法的基本原則：
1）不要做你不必要的工作；2）不要申請不必要的內存；
例如，你明明知道一個方法返回一個String之后，你需要對這個String重新進行修改，那么就不要返回一個String，返回一個StringBuffer會是你更好的選擇。
再比如，使用int比使用Integer占用更少的空間。這個大家肯定都是曉得的。
數組比一個Map擁有更好的性能。
如果你的方法不需要訪問類字段，那么讓你的方法是static的吧，這將會帶來15%-20%速度的提升。
對于常量，請盡量使用static and final定義。如果使用final定義常量之后，會減少編譯器在類生成時初始化<clinit>方法調用時對常量的存儲，對于int型常量，將會直接使用其數值來進行替換，而對于String對象將會使用相對廉價的“string constant”指令來替換字段查找表。雖然這個方法并不完全對所有類型都有效，但是，將常量聲明為static final絕對是一個好的做法。
避免Getters/Setters。雖然在一般的面向對象的設計模式中使用Getter和Setter是稀松平常的事情，但是在Android中使用getters/Setters是一個非常糟糕的主意，方法的調用相對于直接查找字段來說十分的昂貴。在沒有JIT的情況下，直接對字段進行訪問要比通過Getter訪問快了近3倍。在有JIT的情況下，前者比后者快近7倍。
使用最新的循環方式。比如增強for。
避免使用浮點類型。在某些可以的情況下，將浮點替換成整型數據，然后進行計算會得到更精確的結果和更快的速度。
小心使用Native Methods。這里需要糾正的是，Native 方法并不一定能提高你應用的速度，有些甚至會拖后腿，因為，首先來說就需要一部分開銷在Java-native transition上，而且JIT并不能對其進行優化。另外你需要為每個你想要在其上運行的系統結構上進行編譯；即便是同一個處理器上，你也可能需要多個版本，比如為G1上的ARM處理器編譯的就不能很好的在Nexus One的ARM上運行。Native代碼最主要的用途是，你已經有了很多native 代碼，并且你迫切希望接入Android中。而不是使用Native Method來提高你應用中某部分代碼的運行速度。
對于效率的提高除了使用遵守上面兩條外基本準則外，選擇合適的算法和數據結構也是非常關鍵的。
9、關于UI上的一些問題
Hierarchy Viewer 通過他，可以看到你自己的Layout文件存在的問題。你可以看到你的Layout每一部分計算，布局，渲染所需要的時間。盡量的使你的Layout扁平話，深度最好保持 在三層之內 。 RelativeLayout 是解決使用LinearLayout堆疊多層問題的利劍。那些為了方便 使 用LinearLayout的layout_weight屬性 的哥們，需要重點注意，這個屬性真的可以減慢measure速度。所以在使用之前，一定要再三考慮，是否真的不能通過其他方法來完成你要的效果？官方文檔上 推薦使用RelativeLayout和GridLayout來避免Layout深度過深的問題 。
之前看文檔，Google提供一個叫 ViewSub 的控件來優化那些不是必須要立即在UI上顯示的控件，感興趣的同學可以去看看。在API Level 1中就提供了這個東西，但是在實際開發中很少見到有人用或者提及（可能是我孤陋寡聞，公司就兩個Android開發，另一個還要轉IOS，我們倆的 Android技術就代表了我們公司的Android技術能力，想想真悲哀！），其實蠻好用的。
重用Layout。可以使用<include/> <merge/>將其他布局嵌入到當前布局中。
ListView的優化：ViewHolder的使用；AsyncTask的使用；針對ListView當前滑動狀態，對圖片數據的加載進行控制；（ListView在配以AsyncTask加載圖片時需要注 意圖片的加載完顯示的位置以及圖片的緩存問題，具體可以參考Google的 Demo ）
10、將大消耗操作交給多個線程。
11、如果你的應用需要發送Broadcast但是又不希望別的應用獲取到，或者你不希望處理別的應用發送的同樣的action，那么請使用LocalBroadcastManager。
該類是在Android Support v4中提供的，用來在同一個應用內的不同組件之間發送Broadcast。好處上面說了，可以保證應用的私密性。會比全局廣播有更高的效率，但是官方文檔沒有說明具體數值。具體使用方法：
LocalBroadcastManager.getInstance(this).registerReceiver( mStateReceiver, mStatusIntentFilter);
LocalBroadcastManager.getInstance(this).sendBroadcast(localBroadcastIntent);
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！