1、使用優化過的數據容器。
在Android framework下，建議使用優化過的數據容器比如：SparseArray,SparseBooleanArray,LongSparseArray。通用的HashMap實現的內存使用率非常的低，因爲他需要爲每一個mapping創建一個分離的entry object。另外，SparseArray類避免了系統對有些key的自動裝箱，因而帶來了更高的效率。
2、注意內存的開銷。
注意你使用的語言和第三方庫的成本和開銷，要自始至終的將這些因素考慮在你的程序設計中。通常，有些事情表面上看着沒什麼問題但實際上的開銷讓人驚歎。比如：
·枚舉相對於靜態常量來說，需要兩倍甚至更多的內存。你應該完全避免在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:empty8、基本性能優化方法的基本原則：
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的層級關係，如果要修改，使用如下方法：
@Override
public void onAnimationEnd(Animation animation) {
new Handler().post(new Runnable() {
public void run() {
myLayout.removeView(mRemoveView);
}
});
}
