Android應(yīng)用程序的周期和網(wǎng)絡(luò)優(yōu)化

Android應(yīng)用程序的生命周期；

在大部份情況下，每個Android應(yīng)用都將運行在自己的Linux進(jìn)程當(dāng)中。當(dāng)這個應(yīng)用的某些代碼需要執(zhí)行時，進(jìn)程就會被創(chuàng)建，并且將保持運行，直到該進(jìn)程不再需要，而系統(tǒng)需要釋放它所占用的內(nèi)存，為其他應(yīng)用所用時，才停止。

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

對于應(yīng)用開發(fā)者來說，理解不同的應(yīng)用組件（特別是Activity、Service、Intent Receiver）對應(yīng)用進(jìn)程的生命周期的影響，這是非常重要的。如果沒有正確地使用這些組件，將會導(dǎo)致當(dāng)應(yīng)用正在處理重要的工作時，進(jìn)程卻被系統(tǒng)消毀的后果。

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

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

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

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

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

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

當(dāng)要對一個進(jìn)程進(jìn)行分類時，系統(tǒng)會選擇在這個進(jìn)程中所有活動的組件中重要等級高的那個做為依據(jù)?？梢詤⒖糀ctivity、Service、IntentReceiver文檔，了解這些組件如何影響進(jìn)程整個生命周期的更多細(xì)節(jié)。這些類的文檔都對他們?nèi)绾斡绊懰麄兯鶎俚膽?yīng)用的整個生命周期，做了詳細(xì)的描述。
針對移動端的網(wǎng)絡(luò)優(yōu)化，適用 Android，同樣適用于 iOS 和 H5
一個網(wǎng)絡(luò)請求可以簡單分為連接服務(wù)器 -> 獲取數(shù)據(jù)兩個部分。
其中連接服務(wù)器前還包括 DNS 解析的過程；獲取數(shù)據(jù)后可能會對數(shù)據(jù)進(jìn)行緩存。
一、連接服務(wù)器優(yōu)化策略
1. 不用域名，用 IP 直連
省去 DNS 解析過程，DNS 全名 Domain Name System，解析意指根據(jù)域名得到其對應(yīng)的 IP 地址。 如 http://www.codekk.com 的域名解析結(jié)果就是 104.236.147.76。
首次域名解析一般需要幾百毫秒，可通過直接向 IP 而非域名請求，節(jié)省掉這部分時間，同時可以預(yù)防域名劫持等帶來的風(fēng)險。
當(dāng)然為了安全和擴(kuò)展考慮，這個 IP 可能是一個動態(tài)更新的 IP 列表，并在 IP 不可用情況下通過域名訪問。
2. 服務(wù)器合理部署
服務(wù)器多運營商多地部署，一般至少含三大運營商、南中北三地部署。
配合上面說到的動態(tài) IP 列表，支持優(yōu)先級，每次根據(jù)地域、網(wǎng)絡(luò)類型等選擇最優(yōu)的服務(wù)器 IP 進(jìn)行連接。
對于服務(wù)器端還可以調(diào)優(yōu)服務(wù)器的 TCP 擁塞窗口大小、重傳超時時間(RTO)、大傳輸單元(MTU)等。

二、獲取數(shù)據(jù)優(yōu)化策略
1. 連接復(fù)用
節(jié)省連接建立時間，如開啟 keep-alive。
Http 1.1 默認(rèn)啟動了 keep-alive。對于 Android 來說默認(rèn)情況下 HttpURLConnection 和 HttpClient 都開啟了 keep-alive。只是 2.2 之前 HttpURLConnection 存在影響連接池的 Bug，具體可見：Android HttpURLConnection 及 HttpClient 選擇
2. 請求合并
即將多個請求合并為一個進(jìn)行請求，比較常見的就是網(wǎng)頁中的 CSS Image Sprites。 如果某個頁面內(nèi)請求過多，也可以考慮做一定的請求合并。
3. 減小請求數(shù)據(jù)大小
(1) 對于 POST 請求，Body 可以做 Gzip 壓縮，如日志。
(2) 對請求頭進(jìn)行壓縮
這個 Http 1.1 不支持，SPDY 及 Http 2.0 支持。 Http 1.1 可以通過服務(wù)端對前一個請求的請求頭進(jìn)行緩存，后面相同請求頭用 md5 之類的 id 來表示即可。
4. CDN 緩存靜態(tài)資源
緩存常見的圖片、JS、CSS 等靜態(tài)資源。
5. 減小返回數(shù)據(jù)大小
(1) 壓縮
一般 API 數(shù)據(jù)使用 Gzip 壓縮，下圖是之前測試的 Gzip 壓縮前后對比圖。 android-http-compare
(2) 精簡數(shù)據(jù)格式
如 JSON 代替 XML，WebP 代替其他圖片格式。關(guān)注公眾號 codekk，回復(fù) 20 查看關(guān)于 WebP 的介紹。
(3) 對于不同的設(shè)備不同網(wǎng)絡(luò)返回不同的內(nèi)容 如不同分辨率圖片大小。
(4) 增量更新
需要數(shù)據(jù)更新時，可考慮增量更新。如常見的服務(wù)端進(jìn)行 bsdiff，客戶端進(jìn)行 bspatch。
(5) 大文件下載
支持?jǐn)帱c續(xù)傳，并緩存 Http Resonse 的 ETag 標(biāo)識，下次請求時帶上，從而確定是否數(shù)據(jù)改變過，未改變則直接返回 304。
6. 數(shù)據(jù)緩存
緩存獲取到的數(shù)據(jù)，在一定的有效時間內(nèi)再次請求可以直接從緩存讀取數(shù)據(jù)。
關(guān)于 Http 緩存規(guī)則 Grumoon 在 Volley 源碼解析最后雜談中有詳細(xì)介紹。
三、其他優(yōu)化手段
這類優(yōu)化方式在性能優(yōu)化系列總篇中已經(jīng)有過完整介紹
1. 預(yù)取
包括預(yù)連接、預(yù)取數(shù)據(jù)。
2. 分優(yōu)先級、延遲部分請求
將不重要的請求延遲，這樣既可以削峰減少并發(fā)、又可以和后面類似的請求做合并。
3. 多連接
對于較大文件，如大圖片、文件下載可考慮多連接。 需要控制請求的大并發(fā)量，畢竟移動端網(wǎng)絡(luò)受限。
四、監(jiān)控
優(yōu)化需要通過數(shù)據(jù)對比才能看出效果，所以監(jiān)控系統(tǒng)必不可少，通過前后端的數(shù)據(jù)監(jiān)控確定調(diào)優(yōu)效果。

當(dāng)前名稱：Android應(yīng)用程序的周期和網(wǎng)絡(luò)優(yōu)化
轉(zhuǎn)載注明：http://www.muchs.cn/news39/150689.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、關(guān)鍵詞優(yōu)化、ChatGPT、移動網(wǎng)站建設(shè)、網(wǎng)站制作、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)