1、使用優化過的資料容器。

在Android framework下，建議使用優化過的資料容器比如：SparseArray,SparseBooleanArray,LongSparseArray。通用的HashMap實現的記憶體使用率非常的低，因為他需要為每一個mapping建立一個分離的entry object。另外，SparseArray類避免了系統對有些key的自動裝箱，因而帶來了更高的效率。

注意你使用的語言和第三方庫的成本和開銷，要自始至終的將這些因素考慮在你的程式設計中。通常，有些事情表面上看著沒什麼問題但實際上的開銷讓人驚歎。比如： ·列舉相對於靜態常量來說，需要兩倍甚至更多的記憶體。你應該完全避免在Android中使用列舉。 ·每一個在java中的類（包括匿名內部類）使用大約500 bytes的程式碼量。 ·每一個類的例項擁有12-16 bytes的RAM消耗。 ·放置一個單獨的實體到HashMap中，一個額外加的實體物件分配需要花費32 bytes。

3、關於程式碼的抽象

抽象是一個好的程式設計的基礎，因為抽象可以提高程式碼的靈活性和可維護性。然而抽象也帶來了一定的花銷，一般情況下，他們有更多的程式碼需要執行，需要更多的時間和更多RAM來將這些程式碼對映到記憶體中。因此，如果你的抽象不能帶來巨大的好處，你就應該割掉你的贅肉。

4、避免依賴注入框架

雖然注入框架給我們帶來了很多方便，但是在使用這些框架的時候，框架需要花費很多時間來掃描我們自己寫的程式碼，甚至會將哪些你根本不需要的東西也載入到記憶體中。

5、小心的使用擴充套件庫

很多擴充套件庫的程式碼不是針對手機環境開發的，可能在用到移動客戶端的時候會導致很低的效率。因此在使用之前，需要評估一下其佔用記憶體的大小。

即使庫針對手機開發，也會有潛在的危險，因為每一個Library做的事情不盡相同。比如，一個Library使用nano protobufs而另一個使用micro protobufs。現在，在你的app中就有兩個protobuf。類似情況經常發生。

6、使用混淆器移除不必要的程式碼

ProGuard工具通過移除無用程式碼，使用語意模糊來保留類，欄位和方法來壓縮，優化和混淆程式碼。可以使你的程式碼更加完整，更少的RAM 對映頁。

7、使用多個程序（注意是process 不是 thread ok？）

如果這適合你的app，可能幫助你管理你的app的記憶體就是將你的app多個部分分配到多個程序中。該技術必須小心使用並且大多數應用不應該執行在多個程序下。這個技術的主要應用是後臺工作跟天台工作一樣重要的情況下。典型應用就是：當音樂播放器從伺服器下載並長時間播放音樂，一般將其分為兩個程序：一個是UI，另一個位置後臺服務的執行。

like this:

<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);

另外Broadcast的註冊一定要放在Activity的有響應的時候註冊，一般在onResume()註冊,在onPause()的時候取消註冊。儘量不要程式走到onDestroy()方法裡面才對Broadcast取消註冊，因為有些時候不會走到該方法，就會導致崩潰或者再次進入介面是多次註冊。

12、關於Fragment使用：

1）無論在哪裡使用getResources()方法，都是需要判斷是否獲取的為null。

2）在使用Fragment+asyntask時的輸出結果中最好使用isAdded()方法來判斷一下，如果為真，那麼才進行後續操作。

13、關於動畫

動畫結束時，不能修改View的層級關係，如果要修改，使用如下方法：

@Overridepublic void onAnimationEnd(Animation animation) {new Handler().post(new Runnable() {public void run() {myLayout.removeView(mRemoveView);}});}