APP開發(fā)公司詳解怎樣解決對網(wǎng)絡(luò)流量進行優(yōu)化？APP開發(fā)公司資深工程師提醒網(wǎng)絡(luò)流量優(yōu)化工作非常重要，我們知道對App的最低容忍限度是，在2G、3G和4G網(wǎng)絡(luò)環(huán)境下，每個頁面都能打開，都能正常跳轉(zhuǎn)到其他頁面。要能夠完成一次完整的支付流程。慢點兒沒關(guān)系，尤其是2G網(wǎng)絡(luò)。但是動不動就彈出“無法連接到網(wǎng)絡(luò)”或者“網(wǎng)絡(luò)連接超時”的對話框，就是我們開發(fā)人員必須要解決的問題了。深圳
APP開發(fā)公司下面就如何具體進行網(wǎng)絡(luò)流量優(yōu)化進行分享。
APP開發(fā)時通信層面的優(yōu)化讓我們先從MobileAPI層面進行優(yōu)化：
1）MobileAPI接口返回的數(shù)據(jù)，要使用gzip進行壓縮。注意：大于1KB才進行壓縮，否則得不償失。經(jīng)過gzip壓縮后，返回的數(shù)據(jù)量大幅減少。
2）App與MobileAPI之間的數(shù)據(jù)傳遞，通常是遵守JSON協(xié)議的。JSON因為是xml格式的，并且是以字符存在的，在數(shù)據(jù)量上還有可以壓縮的空間。我這里推薦一種新的數(shù)據(jù)傳輸協(xié)議，那就是ProtoBuffer。這種協(xié)議是二進制格式的，所以在表示大數(shù)據(jù)時，空間比JSON小很多。
3）接下來要解決的是頻繁調(diào)用MobileAPI的問題。我們知道，發(fā)起一次網(wǎng)絡(luò)請求，服務(wù)器處理的速度是很快的，主要花費的時間在數(shù)據(jù)傳輸上，也就是這一來一回走路的時間上。走路時間的長度，網(wǎng)絡(luò)運維人員會去負責解決。移動開發(fā)人員需要關(guān)注的是，減少網(wǎng)絡(luò)訪問次數(shù)，能調(diào)用一次MobileAPI接口就能取到數(shù)據(jù)的，就不要調(diào)用兩次。
4）我們知道，傳統(tǒng)的MobileAPI使用的是HTTP無狀態(tài)短連接。使用HTTP協(xié)議的速度遠不如使用TCP協(xié)議，因為后者是長連接。所以我們可以使用TCP長連接，以提高訪問的速度。缺點是一臺服務(wù)器能支持的長連接個數(shù)不多，所以需要更多的服務(wù)器集成。
5）要建立取消網(wǎng)絡(luò)請求的機制。一個頁面如果沒有請求完網(wǎng)絡(luò)數(shù)據(jù)，在跳轉(zhuǎn)到另一個頁面之前，要把之前的網(wǎng)絡(luò)請求都取消，不再等待，也不再接收數(shù)據(jù)。我遇到過一個真實的例子，首頁要在后臺調(diào)用十幾個MobileAPI接口，用戶一旦進入二級頁面，在二級頁面獲取列表數(shù)據(jù)時，經(jīng)常會取不到數(shù)據(jù)，并彈出“網(wǎng)絡(luò)請求超時”的提示。我們通過在App輸出log的方式發(fā)現(xiàn)，二級頁面還在調(diào)用首頁沒有完成的那些MobileAPI接口，App網(wǎng)絡(luò)底層的請求隊列已經(jīng)被阻塞了，原因是在進入下一個頁面時，首頁發(fā)起的網(wǎng)絡(luò)請求仍然存在于網(wǎng)絡(luò)請求隊列中，并沒有移除掉。無論是iOS還是Android，都應(yīng)該在基類（BaseViewController或者BaseActivity）中提供一個cancelRequest的方法，用以在離開當前頁面時清空網(wǎng)絡(luò)請求隊列。
6）增加重試機制。如果MobileAPI是嚴格的RESTful風格，那么我們一般將獲取數(shù)據(jù)的請求接口都定義為get；而把操作數(shù)據(jù)的請求接口都定義為post。這樣的話，我們就可以為所有的get請求配置重試機制，比如get請求失敗后重試3次。有人會問post請求失敗后，是否需要重試呢？我們舉個例子吧，比如說下單接口是個post請求，如果請求失敗那么就會重試3次，直到下單成功。但是有時候post請求并沒有失敗，而是超時了，超時時間是30秒，但是卻31秒返回了，如果因此而重新發(fā)起下單請求，那么就會連續(xù)下單兩次。所以post請求是不建議有重試機制的。此外，對所有的post請求，都要增加防止用戶1分鐘內(nèi)頻繁發(fā)起相同請求的機制，這樣就能有效防止重復下單、重復發(fā)表評論、重復注冊等操作。如果post請求具有防重機制，那么倒是可以增加重試機制。但是要可以在服務(wù)器端靈活配置重試的次數(shù)，可以是0次，意味著不會重試。在App啟動的時候，告訴App所有的MobileAPI接口的重試次數(shù)。
APP開發(fā)時對圖片策略優(yōu)化
首先，我們從圖片層面進行優(yōu)化，這里說的圖片，是根據(jù)MobileAPI返回的圖片URL地址新啟一個線程下載到App本地并顯示的。很多App崩潰的原因就是圖片的問題沒處理好。以下是深圳APP開發(fā)公司在開發(fā)過程中遇到的幾類問題以及相應(yīng)的解決方案。
APP開發(fā)公司提醒要確保下載的每張圖，都符合ImageView控件的大小這對于Android是有難度的，因為手機分辨率千奇百怪，所以App中的圖片，我們大多做成自適應(yīng)的，有時是等比拉伸或縮放圖片的寬和高，有時則固定高度而動態(tài)伸縮寬度，反之亦然。于是我們要求運營人員要事先準備很多套不同分辨率的圖片。我們每次根據(jù)URL請求圖片時，都要額外在URL上加上兩個參數(shù)，width和height，從而要求服務(wù)器返回其中某一張圖，URL如下所示：http://www.aaa.com/a.png?width=100&height=50。如果認為每次準備很多套圖片是件很浪費人力的事情，我還有另一種解決方案，這種方案只需要一張圖。但我們需要事先準備一臺服務(wù)器，稱為ImageServer。具體流程是這樣的：
1）首先，App每次加載圖片，都會把URL地址以及width和height參數(shù)所組成的字符串進行encode，然后發(fā)送給ImageServer，新的URL如下所示：http://www.ImageServer.com/getImage?param=(encodevalue
)2）然后，ImageServer收到這個請求，會把param的值decode，得到原始圖片的URL，以及App想要顯示的這張圖片的width和height。ImageServer會根據(jù)URL獲取到這張原始圖片，然后根據(jù)width和height，重新進行繪制，保存到ImageServer上，并返回給App。
3）最后，App請求到的是一張符合其顯示大小的圖片。接下來收到同樣的請求，直接返回ImageServer上保存的那種圖片即可。但是要每天清一次硬盤，不然過不了幾天硬盤就滿了。如果width和height的比例與原圖的寬高比不一致呢？我們需要再加一個參數(shù)imagetype，以下是定義：
·1表示等比縮放后，裁減掉多余的寬或者高。
·2表示等比縮放后，不足的寬或者高填充白色。當然你也可以定義0表示不進行縮放，直接返回。這種方案的缺點就是，ImageServer頻繁地寫硬盤，硬盤堅持不到兩周就壞掉。所以，我們在損失了幾塊硬盤后，決定事先規(guī)定幾套width和height，App必須嚴格遵守，比如說100×50，200×100，那么就不允許向服務(wù)器發(fā)送類似99×51這樣的圖片尺寸。但這樣規(guī)定，并不能防止App開發(fā)人員犯錯，他在UI上就是不小心為某個ImageView控件指定了99×51這樣的尺寸，那么ImageServer還是會生成這樣的圖片。唯一的辦法就是在出口加以控制，也就是向ImageServer發(fā)起請求的時候。我們會拿99×51
這個實際的圖片尺寸，去輪詢我們事先規(guī)定好的那幾個尺寸100×50和200×100，看更接近哪個，比如說99×51更接近100×50，那么就向ImageServer請求100×50這種尺寸的圖片。找最接近圖片尺寸的辦法是面積法：S=(w1-a)×(w1-w)+(h1-h)×(h1-h)w和h是實際的圖片寬和高，w1和h1是事先規(guī)定的某個尺寸的寬和高。S最小的那個，就是最接近的。
好了，
深圳APP開發(fā)公司本文關(guān)于“怎樣解決對網(wǎng)絡(luò)流量進行優(yōu)化？”就分享到這里。如果您需要聯(lián)系深圳APP開發(fā)公司為你定制開發(fā)高端APP項目，請咨詢我們網(wǎng)站在線客服或者撥打我們APP開發(fā)技術(shù)客服聯(lián)系電話，為您提供詳細的APP開發(fā)解決方案。謝謝關(guān)注，博納網(wǎng)絡(luò)編輯整理。
