Android應用(yòng)程序的(de)生命周期；
     在大(dà)部份情況下(xià)，每個(gè)Android應用(yòng)都将運行在自己的(de)Linux進程當中。當這(zhè)個(gè)應用(yòng)的(de)某些代碼需要執行時(shí)，進程就會被創建，并且将保持運行，直到該進程不再需要，而系統需要釋放它所占用(yòng)的(de)内存，爲其他(tā)應用(yòng)所用(yòng)時(shí)，才停止。

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

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

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

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

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

  4、後台進程是擁有一個(gè)用(yòng)戶不可(kě)見的(de)Activity（onStop()方法已經被調用(yòng)）的(de)進程。這(zhè)些進程不直接影(yǐng)響用(yòng)戶的(de)體驗。如果這(zhè)些進程正确地完成了(le)自己的(de)生命周期（詳細參考Activity類），系統會爲了(le)以上三種類型進程，而随時(shí)消毀這(zhè)種進程以釋放内存。通(tōng)常會有很多(duō)這(zhè)樣的(de)進程在運行著(zhe)，因些這(zhè)些進程會被保存在一個(gè)LRU列表中，以保證在内存不足時(shí)，用(yòng)戶最後看到的(de)進程将在最後才被消毀。

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

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

針對(duì)移動端的(de)網絡優化(huà)，适用(yòng) Android，同樣适用(yòng)于 iOS 和(hé) H5

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

一、連接服務器優化(huà)策略

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

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

二、獲取數據優化(huà)策略

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

2. 請求合并
即将多(duō)個(gè)請求合并爲一個(gè)進行請求，比較常見的(de)就是網頁中的(de) CSS Image Sprites。 如果某個(gè)頁面内請求過多(duō)，也(yě)可(kě)以考慮做(zuò)一定的(de)請求合并。

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

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

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

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

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

(3) 對(duì)于不同的(de)設備不同網絡返回不同的(de)内容 如不同分(fēn)辨率圖片大(dà)小。

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

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

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

 
三、其他(tā)優化(huà)手段

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

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

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

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

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