Android應用程序的(de)生命周期；
     在大部份情況下，每個Android應用都将運行在自(zì)己的(de)Linux進程當中。當這個應用的(de)某些代碼需要執行時，進程就會被創建，并且将保持運行，直到該進程不再需要，而系統需要釋放它所占用的(de)內(nèi)存，為(wèi)其他應用所用時，才停止。

        Android一(yī)個重要并且特殊的(de)特性就是，一(yī)個應用的(de)進程的(de)生命周期不是由應用自(zì)身直接控制的(de)，而是由系統，根據運行中的(de)應用的(de)一(yī)些特征來決定的(de)，包括：這些應用對用戶的(de)重要性、系統的(de)全部可(kě)用內(nèi)存。
         對于應用開發者來說，理(lǐ)解不同的(de)應用組件（特别是Activity、Service、Intent Receiver）對應用進程的(de)生命周期的(de)影響，這是非常重要的(de)。如(rú)果沒有正确地(dì)使用這些組件，将會導緻當應用正在處理(lǐ)重要的(de)工作時，進程卻被系統消毀的(de)後果。

        對于進程生命周期，一(yī)個普遍的(de)錯誤就是：當一(yī)個Intent Receiver在它的(de)onReceiveIntent()方法中，接收到一(yī)個intent後，就會從這個方法中返回。而一(yī)旦從這個方法返回後，系統将會認為(wèi)這個Intent Receiver不再處于活動狀态了，也就會認為(wèi)它的(de)宿主進程不需要了（除非宿主進程中還存在其它的(de)應用組件）。從而，系統随時都會消毀這個進程，收回內(nèi)存，并中止其中還在運行的(de)子(zǐ)線程。問題的(de)解決辦法就是，在IntentReceiver中，啓動一(yī)個Service，這樣系統就會知道(dào)在這個進程中，還有活動的(de)工作正在執行。

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

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

  3、服務進程是擁有一(yī)個由startService()方法啓動的(de)Service的(de)進程。盡管這些進程對于使用者是不可(kě)見的(de)，但他們做(zuò)的(de)通常是使用者所關注的(de)事情（如(rú)後台MP3播放器或後台上傳下載數據的(de)網絡服務）。因此，除非為(wèi)了保障前端進程和(hé)可(kě)視(shì)進程的(de)正常運行，系統才會消毀這種進程。

  4、後台進程是擁有一(yī)個用戶不可(kě)見的(de)Activity（onStop()方法已經被調用）的(de)進程。這些進程不直接影響用戶的(de)體驗。如(rú)果這些進程正确地(dì)完成了自(zì)己的(de)生命周期（詳細參考Activity類），系統會為(wèi)了以上三種類型進程，而随時消毀這種進程以釋放內(nèi)存。通常會有很多這樣的(de)進程在運行着，因些這些進程會被保存在一(yī)個LRU列表中，以保證在內(nèi)存不足時，用戶最後看到的(de)進程将在最後才被消毀。

 5、空進程是那些不擁有任何活動的(de)應用組件的(de)進程。保留這些進程的(de)唯一(yī)理(lǐ)由是，做(zuò)為(wèi)一(yī)個緩存，在它所屬的(de)應用的(de)組件下一(yī)次需要時，縮短(duǎn)啓動的(de)時間。同樣的(de)，為(wèi)了在這些緩存的(de)空進程和(hé)底層的(de)核心緩存之間平衡系統資源，系統會經常消毀這些空進程。

      當要對一(yī)個進程進行分類時，系統會選擇在這個進程中所有活動的(de)組件中重要等級最高(gāo)的(de)那個做(zuò)為(wèi)依據。可(kě)以參考Activity、Service、IntentReceiver文檔，了解這些組件如(rú)何影響進程整個生命周期的(de)更多細節。這些類的(de)文檔都對他們如(rú)何影響他們所屬的(de)應用的(de)整個生命周期，做(zuò)了詳細的(de)描述。

針對移動端的(de)網絡優化，适用 Android，同樣适用于 iOS 和(hé) H5

一(yī)個網絡請求可(kě)以簡單分為(wèi)連接服務器 -> 獲取數據兩個部分。
其中連接服務器前還包括 DNS 解析的(de)過程；獲取數據後可(kě)能會對數據進行緩存。

一(yī)、連接服務器優化策略

1. 不用域名，用 IP 直連
省去(qù) DNS 解析過程，DNS 全名 Domain Name System，解析意指根據域名得到其對應的(de) IP 地(dì)址。 如(rú) http://www.codekk.com 的(de)域名解析結果就是 104.236.147.76。
首次域名解析一(yī)般需要幾百毫秒，可(kě)通過直接向 IP 而非域名請求，節省掉這部分時間，同時可(kě)以預防域名劫持等帶來的(de)風險。
當然為(wèi)了安全和(hé)擴展考慮，這個 IP 可(kě)能是一(yī)個動态更新的(de) IP 列表，并在 IP 不可(kě)用情況下通過域名訪問。

2. 服務器合理(lǐ)部署
服務器多運營商多地(dì)部署，一(yī)般至少含三大運營商、南中北三地(dì)部署。
配合上面說到的(de)動态 IP 列表，支持優先級，每次根據地(dì)域、網絡類型等選擇最優的(de)服務器 IP 進行連接。
對于服務器端還可(kě)以調優服務器的(de) TCP 擁塞窗口大小、重傳超時時間(RTO)、最大傳輸單元(MTU)等。

二、獲取數據優化策略

1. 連接複用
節省連接建立時間，如(rú)開啓 keep-alive。
Http 1.1 默認啓動了 keep-alive。對于 Android 來說默認情況下 HttpURLConnection 和(hé) HttpClient 都開啓了 keep-alive。隻是 2.2 之前 HttpURLConnection 存在影響連接池的(de) Bug，具體可(kě)見：Android HttpURLConnection 及 HttpClient 選擇

2. 請求合并
即将多個請求合并為(wèi)一(yī)個進行請求，比較常見的(de)就是網頁中的(de) CSS Image Sprites。 如(rú)果某個頁面內(nèi)請求過多，也可(kě)以考慮做(zuò)一(yī)定的(de)請求合并。

3. 減小請求數據大小
(1) 對于 POST 請求，Body 可(kě)以做(zuò) Gzip 壓縮，如(rú)日志。

(2) 對請求頭進行壓縮
這個 Http 1.1 不支持，SPDY 及 Http 2.0 支持。 Http 1.1 可(kě)以通過服務端對前一(yī)個請求的(de)請求頭進行緩存，後面相同請求頭用 md5 之類的(de) id 來表示即可(kě)。

4. CDN 緩存靜态資源
緩存常見的(de)圖片、JS、CSS 等靜态資源。

5. 減小返回數據大小
(1) 壓縮
一(yī)般 API 數據使用 Gzip 壓縮，下圖是之前測試的(de) Gzip 壓縮前後對比圖。 android-http-compare

(2) 精簡數據格式
如(rú) JSON 代替 XML，WebP 代替其他圖片格式。關注公衆号 codekk，回複 20 查看關于 WebP 的(de)介紹。

(3) 對于不同的(de)設備不同網絡返回不同的(de)內(nèi)容 如(rú)不同分辨率圖片大小。

(4) 增量更新
需要數據更新時，可(kě)考慮增量更新。如(rú)常見的(de)服務端進行 bsdiff，客戶端進行 bspatch。

(5) 大文件下載
支持斷點續傳，并緩存 Http Resonse 的(de) ETag 标識，下次請求時帶上，從而确定是否數據改變過，未改變則直接返回 304。

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

 
三、其他優化手段

這類優化方式在性能優化系列總篇中已經有過完整介紹
1. 預取
包括預連接、預取數據。

2. 分優先級、延遲部分請求
将不重要的(de)請求延遲，這樣既可(kě)以削峰減少并發、又可(kě)以和(hé)後面類似的(de)請求做(zuò)合并。

3. 多連接
對于較大文件，如(rú)大圖片、文件下載可(kě)考慮多連接。 需要控制請求的(de)最大并發量，畢竟移動端網絡受限。

四、監控
優化需要通過數據對比才能看出效果，所以監控系統必不可(kě)少，通過前後端的(de)數據監控确定調優效果。

責任編輯：中山網站建設
 【網訊網絡】國(guó)家高(gāo)新技術企業》十年(nián)專注軟件開發，網站建設，網頁設計，APP開發，小程序，微信公衆号開發，定制各類企業管理(lǐ)軟件（OA、CRM、ERP、訂單管理(lǐ)系統、進銷存管理(lǐ)軟件等)！服務熱線：0760-88610046、13924923903，http://www.wansion.net