Android應用程序的生命周期和網絡優化

Android應用程序的生命周期；

在大部份情況下，每個Android應用都將運行在自己的Linux進程當中。當這個應用的某些代碼需要執行時，進程就會被創建，并且將保持運行，直到該進程不再需要，而系統需要釋放它所占用的內存，為其他應用所用時，才停止。

Android一個重要并且特殊的特性就是，一個應用的進程的生命周期不是由應用自身直接控制的，而是由系統，根據運行中的應用的一些特征來決定的，包括：這些應用對用戶的重要性、系統的全部可用內存。

對于應用開發者來說，理解不同的應用組件（特別是Activity、Service、IntentReceiver）對應用進程的生命周期的影響，這是非常重要的。如果沒有正確地使用這些組件，將會導致當應用正在處理重要的工作時，進程卻被系統消毀的后果。

對于進程生命周期，一個普遍的錯誤就是：當一個IntentReceiver在它的onReceiveIntent()方法中，接收到一個intent后，就會從這個方法中返回。而一旦從這個方法返回后，系統將會認為這個IntentReceiver不再處于活動狀態了，也就會認為它的宿主進程不需要了（除非宿主進程中還存在其它的應用組件）。從而，系統隨時都會消毀這個進程，收回內存，并中止其中還在運行的子線程。問題的解決辦法就是，在IntentReceiver中，啟動一個Service，這樣系統就會知道在這個進程中，還有活動的工作正在執行。

為了決定在內存不足情況下消毀哪個進程，Android會根據這些進程內運行的組件及這些組件的狀態，把這些進程劃分出一個“重要性層次”。這個層次按順序如下：
1、前端進程是擁有一個顯示在屏幕最前端并與使用者做交互的Activity（它的onResume已被調用）的進程，也可能是一個擁有正在運行的IntentReceiver（它的onReceiveIntent()方法正在運行）的進程。在系統中，這種進程是很少的，只有當內存低到不足于支持這些進程的繼續運行，才會將這些進程消毀。通常這時候，設備已經達到了需要進行內存整理的狀態，為了保障用戶界面不停止響應，只能消毀這些進程；

2、可視進程是擁有一個用戶在屏幕上可見的，但并沒有在前端顯示的Activity（它的onPause已被調用）的進程。例如：一個以對話框顯示的前端activity在屏幕上顯示，而它后面的上一級activity仍然是可見的。這樣的進程是非常重要的，一般不會被消毀，除非為了保障所有的前端進程正常運行，才會被消毀。

3、服務進程是擁有一個由startService()方法啟動的Service的進程。盡管這些進程對于使用者是不可見的，但他們做的通常是使用者所關注的事情（如后臺MP3播放器或后臺上傳下載數據的網絡服務）。因此，除非為了保障前端進程和可視進程的正常運行，系統才會消毀這種進程。

4、后臺進程是擁有一個用戶不可見的Activity（onStop()方法已經被調用）的進程。這些進程不直接影響用戶的體驗。如果這些進程正確地完成了自己的生命周期（詳細參考Activity類），系統會為了以上三種類型進程，而隨時消毀這種進程以釋放內存。通常會有很多這樣的進程在運行著，因些這些進程會被保存在一個LRU列表中，以保證在內存不足時，用戶最后看到的進程將在最后才被消毀。

5、空進程是那些不擁有任何活動的應用組件的進程。保留這些進程的較早理由是，做為一個緩存，在它所屬的應用的組件下一次需要時，縮短啟動的時間。同樣的，為了在這些緩存的空進程和底層的核心緩存之間平衡系統資源，系統會經常消毀這些空進程。

當要對一個進程進行分類時，系統會選擇在這個進程中所有活動的組件中重要等級最高的那個做為依據?？梢詤⒖糀ctivity、Service、IntentReceiver文檔，了解這些組件如何影響進程整個生命周期的更多細節。這些類的文檔都對他們如何影響他們所屬的應用的整個生命周期，做了詳細的描述。

針對移動端的網絡優化，適用Android，同樣適用于iOS和H5
一個網絡請求可以簡單分為連接服務器->獲取數據兩個部分。
其中連接服務器前還包括DNS解析的過程；獲取數據后可能會對數據進行緩存。
一、連接服務器優化策略
1.不用域名，用IP直連
省去DNS解析過程，DNS全名DomainNameSystem，解析意指根據域名得到其對應的IP地址。如http://www.codekk.com的域名解析結果就是104.236.147.76。
首次域名解析一般需要幾百毫秒，可通過直接向IP而非域名請求，節省掉這部分時間，同時可以預防域名劫持等帶來的風險。
當然為了安全和擴展考慮，這個IP可能是一個動態更新的IP列表，并在IP不可用情況下通過域名訪問。
2.服務器合理部署
服務器多運營商多地部署，一般至少含三大運營商、南中北三地部署。
配合上面說到的動態IP列表，支持優先級，每次根據地域、網絡類型等選擇最優的服務器IP進行連接。
對于服務器端還可以調優服務器的TCP擁塞窗口大小、重傳超時時間(RTO)、最大傳輸單元(MTU)等。
二、獲取數據優化策略
1.連接復用
節省連接建立時間，如開啟keep-alive。
Http1.1默認啟動了keep-alive。對于Android來說默認情況下HttpURLConnection和HttpClient都開啟了keep-alive。只是2.2之前HttpURLConnection存在影響連接池的Bug，具體可見：AndroidHttpURLConnection及HttpClient選擇
2.請求合并
即將多個請求合并為一個進行請求，比較常見的就是網頁中的CSSImageSprites。如果某個頁面內請求過多，也可以考慮做一定的請求合并。
3.減小請求數據大小
(1)對于POST請求，Body可以做Gzip壓縮，如日志。
(2)對請求頭進行壓縮
這個Http1.1不支持，SPDY及Http2.0支持。Http1.1可以通過服務端對前一個請求的請求頭進行緩存，后面相同請求頭用md5之類的id來表示即可。
4.CDN緩存靜態資源
緩存常見的圖片、JS、CSS等靜態資源。
5.減小返回數據大小
(1)壓縮
一般API數據使用Gzip壓縮，下圖是之前測試的Gzip壓縮前后對比圖。android-http-compare
(2)精簡數據格式
如JSON代替XML，WebP代替其他圖片格式。關注公眾號codekk，回復20查看關于WebP的介紹。
(3)對于不同的設備不同網絡返回不同的內容如不同分辨率圖片大小。
(4)增量更新
需要數據更新時，可考慮增量更新。如常見的服務端進行bsdiff，客戶端進行bspatch。
(5)大文件下載
支持斷點續傳，并緩存HttpResonse的ETag標識，下次請求時帶上，從而確定是否數據改變過，未改變則直接返回304。

6.數據緩存
緩存獲取到的數據，在一定的有效時間內再次請求可以直接從緩存讀取數據。
關于Http緩存規則Grumoon在Volley源碼解析最后雜談中有詳細介紹。

三、其他優化手段
這類優化方式在性能優化系列總篇中已經有過完整介紹
1.預取
包括預連接、預取數據。
2.分優先級、延遲部分請求
將不重要的請求延遲，這樣既可以削峰減少并發、又可以和后面類似的請求做合并。
3.多連接
對于較大文件，如大圖片、文件下載可考慮多連接。需要控制請求的最大并發量，畢竟移動端網絡受限。
四、監控
優化需要通過數據對比才能看出效果，所以監控系統必不可少，通過前后端的數據監控確定調優效果。