商城APP開發(fā)關(guān)于在低流量模式圖片處理以及城市列表解決方案。商城APP開發(fā)注意在2G和3G網(wǎng)絡(luò)環(huán)境下，我們應(yīng)該適當(dāng)降低圖片的質(zhì)量。降低圖片質(zhì)量，相應(yīng)的圖片大小也會降低，我們稱為低流量模式。還記得我們前面提到的ImageServer嗎？我們可以在URL中再增加一個參數(shù)quality，2G網(wǎng)絡(luò)下這個值為50%，3G網(wǎng)絡(luò)下這個值為70%，我們把這個參數(shù)傳遞給ImageServer，從而ImageServer在繪制圖片時，就會將jpg圖片質(zhì)量降低為50%或70%，這樣返回給App的數(shù)據(jù)量就大大減少了。在列表頁，這種效果最為明顯，能極大的節(jié)省用戶流量。
商城APP開發(fā)關(guān)于在極速模式下解決方案
深圳
APP開發(fā)公司發(fā)現(xiàn)，在2G和3G網(wǎng)絡(luò)環(huán)境下，用戶大多對圖片不感興趣，他們可能就是想快速下單并支付，我們需要額外設(shè)計一些頁面，區(qū)別于正常模式下圖文并茂的頁面，我們將這些只有文字的頁面稱為極速模式。比如，首頁往往圖片占據(jù)多數(shù)，而且這些圖片大多數(shù)從網(wǎng)絡(luò)動態(tài)下載的，在2G網(wǎng)絡(luò)下，這些圖片是很浪費流量的。所以在極速模式下，我們需要設(shè)計一個只有純文字的首頁。在每次開啟App進(jìn)入首頁前會先進(jìn)行預(yù)判，如果發(fā)現(xiàn)當(dāng)前網(wǎng)絡(luò)環(huán)境為2G、3G或4G，但是當(dāng)前模式為正常模式，就會彈出一個對話框詢問用戶，是否要進(jìn)入極速模式以節(jié)省流量。如果是WiFi網(wǎng)絡(luò)環(huán)境，但當(dāng)前模式是極速模式，也會提示用戶是否要切換回正常模式，以看到最炫的效果。僅在開啟App時提示用戶極速模式是不夠的，我們在設(shè)置頁也要提供這個開關(guān)，供用戶手動切換。
商城APP開發(fā)關(guān)于城市列表的設(shè)計
很多，App都有城市列表這一功能?？此坪唵危拖竦卿浌δ芤粯?，做好它并不容易。商城APP開發(fā)公司將關(guān)于城市列表數(shù)據(jù)整理一份城市列表的數(shù)據(jù)包括以下幾個字典：
·cityId：城市Id。
·cityName：城市名稱。
·pinyin：城市全拼。
·jianpin：城市簡拼。
其中，全拼和簡拼是用來在App本地做字母表排序和關(guān)鍵字檢索的。我曾經(jīng)經(jīng)歷過把城市列表數(shù)據(jù)寫死在本地文件的做法，日積月累，就會產(chǎn)生兩個問題：·Android和iOS維護(hù)的數(shù)據(jù)，差異會越來越大。·一千多個城市，每次從本地加載都要很長時間。針對問題1的解決辦法是，寫一個文本分析工具，找出Android和iOS各自維護(hù)文件的不同數(shù)據(jù)。iOS開發(fā)人員喜歡使用plist文件作為數(shù)據(jù)存儲的載體，最好能和Android統(tǒng)一使用一份xml文件，這樣便于管理類似城市列表這樣的數(shù)據(jù)。針對問題2的解決方案是，對于一千多個城市，意味著每次都要解析xml城市數(shù)據(jù)文件，既然每次讀取數(shù)據(jù)都很慢，那么我們干脆就把序列化過的城市列表直接保存到本地文件，跟隨App一起發(fā)布。這樣，每次讀取這個文件時，就直接進(jìn)行反序列化即可，速度得到很大提升。把城市列表數(shù)據(jù)保存在本地，有個很煩的事情，就是每次增加新的城市，都要等下次發(fā)版，因為數(shù)據(jù)是寫死在App本地的。于是，我們把城市列表數(shù)據(jù)做成一個MobileAPI接口，由MobileAPI去后臺采集數(shù)據(jù)，這樣數(shù)據(jù)是最新最準(zhǔn)的。但是這樣做的問題是，這個MobileAPI接口返回的數(shù)據(jù)量會很大，上千筆數(shù)據(jù)，還包括那么多字段，即使打開了gzip壓縮，也會有100k的樣子。于是我們又增加了版本號字段version的概念，這個MobileAPI接口的定義和返回的JSON格式是這樣的：
1）入?yún)?。version，本地存儲的城市列表數(shù)據(jù)對應(yīng)的版本號。
2）返回值。如果傳入?yún)?shù)version和線上最新版本號一致，則返回以下固定格式：{"isMatch":false,"version":1,"cities":[{},]}如果傳入?yún)?shù)version和線上最新版本號不一致，則返回以下格式：{"isMatch":false,"version":1,"cities":[{"cityId":1,"cityName":"北京","pinyin":"beijing","jianpin":"bj"},{"cityId":2,"cityName":"上海","pinyin":"shanghai","jianpin":"sh"},{"cityId":3,"cityName":"平頂山","pinyin":"pingdingshan","jianpin":"pds"}
]}version這個字段由MobileAPI進(jìn)行更新，每當(dāng)有城市數(shù)據(jù)更新時，version可以立即自增+1，也可以積累到一定數(shù)據(jù)后自增+1。具體策略由MobileAPI來決定。基于此，App的策略可以是這樣的：
1）本地仍然保存一份線上最新的城市列表數(shù)據(jù)（序列化后的）以及對應(yīng)的版本號。我們要求每次發(fā)版前做一次城市數(shù)據(jù)同步的事情。
2）每次進(jìn)入到城市列表這個頁面時，將本地城市列表數(shù)據(jù)對應(yīng)的版本號version傳入到MobileAPI接口，根據(jù)返回的isMatch值來決定是否版本號一致。如果一致，則直接從本地文件中加載城市列表數(shù)據(jù)；否則，就解析MobileAPI接口返回的數(shù)據(jù)，在顯示列表的同時，記得要把最新的城市列表數(shù)據(jù)和版本號保存到本地。
3）如果MobileAPI接口沒有調(diào)用成功，也是直接從本地文件中加載城市列表數(shù)據(jù)，以確保主流程是暢通的。
4）每次調(diào)用MobileAPI時，會獲取到大量的數(shù)據(jù)，一般我們會打開gzip對數(shù)據(jù)進(jìn)行壓縮，以確保傳輸?shù)臄?shù)據(jù)量最小。
好了，
深圳APP開發(fā)公司本文“商城APP開發(fā)關(guān)于在低流量模式圖片處理以及城市列表解決方案”就分享到這里。如果您需要聯(lián)系深圳的APP開發(fā)公司為您定制商城APP開發(fā)服務(wù)，請咨詢我們網(wǎng)站在線客服或者撥打我們網(wǎng)站APP開發(fā)技術(shù)客服聯(lián)系電話，為您提供詳細(xì)的高端商城APP開發(fā)解決方案。謝謝關(guān)注，博納網(wǎng)絡(luò)編輯整理。
