在Android應用程序開發中關于性能的優化是一個永恒的話題，以下是在實際開發和學習中關于性能優化的一些見解。
1：內存管理
在Android系統上并沒有為內存提供交換區，它是通過分頁和內存映射的機制來管理內存，這就說明任何你修改的內存都會存在RAM中，因此唯一完整釋放內存的方法是釋放那些對象的引用，當這個對象沒有被任何其他對象所引用的時候它就能夠被GC回收。
(1)：限制應用的內存
為了維持多任務的功能環境，Android為每一個app都設置了一個硬性的heap size限制。heap size的大小會因為不同設備的不同RAM大小而各有差異。如果你的app已經到了heap的限制大小并且再嘗試分配內存的話，會引起OutOfMemoryError的錯誤。
你也許想要查詢當前設備的heap size限制大小是多少，然后決定cache的大小。可以通過getMemoryClass()來查詢。這個方法會返回一個整數，表明你的應用的heap size限制。
(2)：切換應用
Android不會在用戶切換應用時候做交換內存的操作。當用戶剛開始啟動了一個應用，系統會為它創建了一個進程，但是當用戶離開這個應用，此進程并不會立即被銷毀。系統會把這個進程放到cache中，如果用戶后來再回到這個應用，此進程就能夠被完整恢復，從而實現應用的快速切換。
如果你的應用中有一個被緩存的進程，這個進程會占用暫時不需要使用到的內存，會被保留在內存中，這會對系統的整體性能有影響。因此當系統開始進入低內存狀態時，它會由系統根據特定的算法來kill進程。
(3)：慎用Services
service用于在后臺執行一些耗時操作，只用當它執行任務的時候才開啟，否則其他時刻都應該不工作，service完成任務之后要主動停止，否則如果用戶發現有常駐后臺行為的應用并且可能卸載它甚至引起內存泄漏。
當你開啟一個service，系統會傾向為了保留這個service而一直保留service所在的進程。這使得進程的運行代價很高，因為系統沒有辦法把service所占用的RAM空間騰出來讓給其他組件。
推薦使用IntentService， 它會在工作線程處理完交代給它的intent任務之后自動停止。
(4)：UI隱藏時釋放內存
當應用 UI處于可見時，你應該釋放你的應用UI上所占用的所有內存資源。在這個時候釋放UI資源可以顯著的增加系統緩存進程的能力，它會對用戶體驗有著很直接的影響。例如當用戶從你的app的某個activity跳轉到另外一個activity時前面activity的onStop()會被執行。因此你應該實現onStop回調，并且在此回調里面釋放activity的資源，例如釋放網絡連接，注銷監聽廣播接收者。
(5)：避免盲目獲取heap
可以通過在清單文件下的application標簽下添加largeHeap=true的屬性來聲明一個更大的heap空間。如果你這樣做，你可以通過getLargeMemoryClass())來獲取到一個更大的heap size。
然而，能夠獲取更大heap的設計本意不是提供給整個應用，而是為了一小部分會消耗大量RAM的應用(例如一張圖片的編輯)。不要盲目因為你需要使用大量的內存而去請求一個大的heap size。只有當你清楚的知道哪里會使用大量的內存并且為什么這些內存必須被保留時才去使用large heap。
需要說明的是通過設置large heap屬性并不一定能夠獲取到更大的heap。在某些機器上，large heap的大小和通常的heap size是一樣的。
(6)：避免Bitmap浪費
加載一個bitmap時，僅僅需要保留適配當前屏幕設備分辨率的數據即可，如果原圖高于你的設備分辨率，需要做縮小的動作。值得注意的是bitmap的尺寸會對內存呈現出2次方的增加。
(7)：使用定制的數據容器
如SparseArray, SparseBooleanArray, 與 LongSparseArray。 通常的HashMap的實現方式更加消耗內存。SparseArray避免了key與value的自動裝箱和拆箱。
(8)：警惕內存開銷
枚舉類型的內存消耗通常是靜態變量的2倍。你應該盡量避免在Android上使用枚舉。
在Java中的每一個類(包括匿名內部類)都會使用大概500 bytes。
每一個類的實例開銷大約是12-16 bytes。
向HashMap添加一個entry需要額一個額外占用的32 bytes的entry對象。
(9)：謹慎使用第三方類庫
如果一個類庫與你的實際需求吻合度較小，你應該考慮自己去實現，而不是導入一個大而全的解決方案，因為它里面包含的各種資源也是對內存的消耗。
2：代碼優化
高效的代碼需要滿足下面兩個原則：
1.)不要做冗余的工作
2.)盡量避免過多的內存分配
(1)：避免創建不必要的對象
避免創建更多的臨時對象，更少的對象意味者更少的gc動作，即使gc支持并發操作但還是會對用戶體驗有比較直觀的影響。
(2)：選擇使用Static
如果你不需要訪問一個對象的值，請保證這個方法是static類型的，這樣方法調用將快15%-20%。
(3)：避免Getter和Setter方法
Getters和Setters方法在面向對象程序設計上是一個良好的習慣，但在Android上這不是一個好的寫法，因為虛函數的調用比起直接訪問變量要耗費更多。
(4)：使用for-each 循環
for-each 循環可以被用在實現了 Iterable 接口的 collections 以及數組上，增強的for-each循環寫法會和迭代器寫法的效率一樣，且更加清晰直觀。
(5)：避免使用float類型
Android系統中float類型的數據存取速度是int類型的一半，盡量優先采用int類型。
float 和 double 的速度是一樣的，同樣條件下使用 double 。
3：布局文件性能
Layout 是 Android 應用中直接影響用戶體驗的關鍵部分。如果實現的不好，你的 Layout 會導致程序非常占用內存并且 UI 運行緩慢。
(1)：避免過多嵌套
?Layout轉化為視圖需要經過初始化、布局和繪制的過程，如果布局嵌套導致層級過深，上面的初始化，布局和繪制操作就更加耗時。
(2)：使用include標簽重用layouts
為了高效重用整個的 Layout，你可以使用include標簽把其他 Layout 嵌入當前 Layout，比如可以把自定義的toolbar應用于每個需要的頁面。
(3)：ListView優化
ListView 滑動繪制Item時經常使用 findViewById()，這樣會降低性能。即使是 Adapter 返回一個用于回收的 inflate 后的視圖，你仍然需要查看這個元素并更新它。避免頻繁調用 findViewById() 的y有效方法之一就是使用 ViewHolder。
4：多線程
(1)：使用線程池
如果你只需要一個任務執行一次使用一個IntentService就可以。但是Android中的網絡操作是相當頻繁的，你需要提供一個管理線程的集合。 為了做這個管理線程的集合，使用一個ThreadPoolExecutor實例。
一個線程池能運行多個并行的任務實例，因此你要能保證你的代碼是線程安全的，從而你需要給會被多個線程訪問的變量加上同步代碼塊(synchronized block)。
(2)：與UI線程通信
1.)Handler屬于Android系統的線程管理框架的一部分,用于線程之間的通信。
2.)Rxjava能夠很好的實現線程之間的相互切換。
5：ANR
ANR指應用程序無響應，發生原因通常是應用程序在UI線程執行耗時操作。比如：
Activity內對輸入事件，5秒內都無響應。
BroadReceiver不能夠在10秒內結束接收到任務。
(1)：Android程序通常是執行在默認的UI線程中的。這意味著在UI線程中執行的任何長時間的操作都可能觸發ANR，因此，任何執行在UI線程的方法都應該盡可能的快速。特別是，在activity的生命周期的方法onCreate()與onResume()方法中應該盡可能的做比較少的事情。類似網絡或數據庫操作等可能長時間執行的操作，都應該執行在工作線程中。
(2)：BroadcastReceiver的超時時間是10秒，應用程序應該避免在BroadcastReceiver中執行費時的任務。如果需要的話可以啟動一個IntentService來響應BroadcastReceiver的長時間任務。
