磁碟

1. 檔案讀寫：每次開啟、關閉或者讀寫檔案，作業系統都需要經過從使用者態轉換為核心態的切換，這種狀態的切換本身是很消耗效能的，所以為了提高檔案的讀寫效率，就需要儘量減少使用者態和核心態的切換。使用快取可以避免重複讀寫，對於需要多次訪問的資料，在第一次取出資料的時候，將資料放在快取中，下次再訪問的時候，就可以從快取中取出來。
2. Android手機裡面的libsqlite.so呼叫系統的pread64和pwrite64函式進行I/O操作。

3. 序列化：ObjectOutputStream在序列化磁碟的時候，會把記憶體中的每個物件儲存到磁碟，在儲存物件的時候，每一個數據成員會帶來一次I/O操作。因此，在使用ObjectOutputStream

   的時候，在ObjectOutputStream上面再封裝一個輸出流ByteArrayOuputStream先將物件序列化後的資訊寫到快取區中，然後再一次性地寫到磁碟上。

   序列化磁碟讀寫方式	優化前	優化後
   序列化寫磁碟	ObjectOutputStream	BufferedOutputStream + ObjectOutputStream
   ByteArrayOutputStream + ObjectOutputStream
   序列化讀磁碟	ObjectInputStream	BufferedInputStream + ObjectInputStream
   ByteArrayInputStream + ObjectInputStream

   序列化磁碟讀寫方式	優化前後	I/O次數	耗時（ms）
   序列化寫磁碟	優化前	499	162.8
   優化後	1	87.3
   序列化讀磁碟	優化前	719	171.8
   優化後	1	109.9

4. Buffer緩衝區大小：在讀/寫時使用緩衝區可以減少讀寫次數，從而減少了切換核心態的次數，提高讀/寫效率，根據實際經驗，這裡推薦使用的Buffer大小為8KB，這和Java預設的Buffer大小一致，Buffer大小至少應為4KB。當然，Buffer也不是越大越好，Buffer如果太大，會導致申請Buffer的時間邊長，反而整體效率不高。可以採用檔案大小除以讀寫次數得到Buffer的大小。這個方法由兩個影響因子決定，一是Buffer size不能大於檔案大小；二是Buffer size根據檔案儲存所掛載的目錄的Block size來確定Buffer大小，而
   資料庫的pagesize，就是這樣確定的。
5. SQLite：資料庫在開啟後，先不要關閉，在應用程式退出時再關閉。
6. SQLite：在資料庫中，應減少使用AUTOINCREMENT。AUTOINCREMENT可以保證主鍵的嚴格遞增，但是使用AUTOINCREMENT會增加INSERT耗時1倍以上，所以使用AUTOINCREMENT不可以任性，用在該用的敵方效果才佳。
   
   SQLite官方：這個AUTOINCREMENT關鍵字會增加CPU，記憶體，磁碟空間和磁碟I/O的負擔，所以儘量不要用，除非必須。其實通常情況下都不是必需的。
   
   
7. Bitmap解碼：
   （1）解碼Bitmap不要使用decodeFile，因為在Android4.4以上系統效率不高。
   （2）解碼Bitmap使用decodeStream，同時傳入的檔案流BufferedInputStream。
   （3）decodeResource同樣存在效能問題，請用decodeResourceStream。
   解決方案： 
   
   1. 解碼Bitmap要使用decodeStream，不要說使用decodeFile，同時傳給decodeStream的檔案流是BufferedInputStream。
   2. decodeResource同樣存在這個問題，建議使用decodeResourceStream。

專項標準：磁碟

記憶體

記憶體檢測工具集

Android使用的是一個去掉了swap的linux核心（至少在Android4.4以前的版本都是這樣的），這樣就阻礙了Android上的應用程式使用Page out（應用程式使用的記憶體，對作業系統而言都是一張張的page，而對於老化的page，作業系統可以將它們從記憶體中置換到硬碟上，這種操作叫做page out），這一常規的記憶體操作。 
　　Android框架對於程序記憶體的第二個管控特徵是，每個程序都有一個記憶體最高閥值（純淨的Native記憶體申請不算在內），一旦程序申請記憶體突破了這個閥值，將會產生異常，並退出執行時的記憶體空間。簡單的說，也就是Android為每個程序已經分好了一塊蛋糕，至於你吃或者不吃，是你的自己的事情了。但這是否意味著Android應用程式為了效率考慮，應該玩命的申請記憶體，使自己的記憶體沿著天花板滑行，這樣是否最健康呢？答案也不一定。 
Android的第三個管控特徵是，程序都有可能被殺。在實體記憶體吃緊的時候（通常在使用meminfo檢視記憶體概況的PSS總值達到裝置實體記憶體80%的時候），Android框架就開始根據一套自由的LRU程序Cache列表來殺死程序，被殺死的程序在死前將會得到通知，用以儲存現場。而這部分被殺死的程序所騰出來的實體記憶體，就可以用於某些應用程式的記憶體申請需求。

　　Android記憶體框架下的各種管控特徵：

• 沒有Page out， 所以實體記憶體更加金貴。
• 每個程序都有一個記憶體上限，所以蛋糕是已經被分配好的。
• 所有的程序都有被殺的可能，所以要做好被殺準備。

專項標準：記憶體

網路

工具集

工具庫