圖片緩存：

ImageLoader的知識點講的比較老，暫不總結（題外話：推薦Glide或者Fresco，但是一定要進行二次封裝，否則誰知道哪天心血來潮，想著換個框架試試呢）

圖片加載利器Fresco: 配置文件配置： <uses-permissionandroid:name="android.permission.INTERNET"/> 在application中進行初始化： Fresco.initialize(context); 將程序中顯示圖片的ImageView替換為SimpleDraweeView,并添加fresco命名空間： <!-- 其他元素 --> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:fresco="http://schemas.android.com/apk/res-auto"> 加入SimpleDraweeView: <com.facebook.drawee.view.SimpleDraweeView android:id="@+id/my_image_view" android:layout_width="20dp" android:layout_height="20dp" fresco:placeholderImage="@drawable/my_drawable" /> 在activity或者fragment里面加載網絡圖片： Uri uri =Uri.parse("https://raw.githubusercontent.com/facebook/fresco/gh-pages/static/fresco-logo.png"); SimpleDraweeView draweeView =(SimpleDraweeView) findViewById(R.id.my_image_view); draweeView.setImageURI(uri); Image pipeline工作流： Freso三層緩存概念： ? bitmap緩存：5.0，bitmap緩存在heap堆中。 4.0及以下：bitmap位于ashmem中，而不是java的heap中，不會因為圖片創建，回收引發過多gc,當App切換到后臺，會清空bitmap緩存。 ? 內存緩存：存儲圖片原始壓縮格式，從內存中取出來并解碼，切換后臺，清理內存緩存。 ? 磁盤緩存：存儲在本地，不會丟失。 網上fresco中文文檔可以看下：http://fresco-cn.org/docs/index.html#_

網絡流量優化：

數據進行壓縮處理進行傳輸，使用Gzip

傳輸格式使用json或者protobuffer

盡可能將一個頁面的多個數據請求進行合并處理

使用長連接代替http請求

離開頁面，取消請求（這方面比如我以前用的volley,現在用的okhttp都有提供方法來取消，一般將取消操作統一封裝在基類的onDestory（）里面）。

建立重試機制。一般設置重試三次的操作，只針對get,post要防止重試。

? 圖片流量優化：

客戶端可以通過傳遞寬高，來讓服務器端對圖片進行裁剪，并獲取符合當前顯示控件的的圖片，相對應的對服務器端的壓力比較大。

針對2G以及3G用戶降低圖片的質量，從而減少圖片占據的流量。

其實如果應用對圖片的要求不是很高的話，可以控制應用在2G，3G的網絡環境不加載圖片，而在wifi的情況下加載，當然最好在應用里面設置個可選項供用戶選擇。

?

城市列表數據：

城市列表信息，一般包括以下內容： cityid 城市id cityname 城市名稱 pinyin 城市拼音 jianpin 城市簡拼音 （題外話，一般項目中有兩種方式來獲取城市列表信息： 1，直接db文件或者json文件， 2，每次從服務器端獲取，但是序列化本地，讀取的時候從緩存文件里面讀取 ） 對于2的問題，其實還是有個問題存在的，就是你每次都去序列化這些內容嗎，或者說每次都從服務器端獲取緩存數據庫或者文件里面嗎，很明顯是不明智的。 ? 書里面針對上面的問題，其實在json結構設計的時候進行比較合適的方式來進行解決： {"citys" : {},"isMatch" : false,"version" : 1 } isMatch:表示是否本地version和服務器端城市列表信息的version一致。 version:城市列表數據的版本信息。 citys:城市列表數據。 給城市列表的json數據加上version字段，如果version字段不變化，第二次就不去更新這些內容，當version字段發生變化額時候，再對數據進行遞增。 App這邊的策略：

本地存儲發版前最新的城市列表信息，包含版本信息；

獲取城市列表的時候，將本地城市信息列表里面版本信息帶到接口里面，根據返回的時候，isMatch的字段來判斷是否和服務器端一致，如果一致，讀取客戶端緩存數據，不一致解析并緩存最新的城市列表數據。

接口調用失敗，讀本地緩存城市列表數據。

開gzip壓縮，確保傳輸數據量最少。

無論是解析還是讀取本地緩存的城市信息，一定要異步處理，否則很容易卡頓。

城市列表信息增量更新：?

分為2種情況：

原有的表數據要進行修改。

有新增的城市列表數據。

接下來的方案也是針對這兩種情況進行處理的： 存在對城市信息的操作由三種：

增加新城市信息；

刪除無效的城市信息；

更新已有的城市數據；

解決方法： 給城市信息加上type類型： {"isMatch":false;"version":1,"citys":{{"cityid":1,"cityName":"西安","pinyin":"xian","jianpin":"xa","type":"delete"},{"cityid":2,"cityName":"北京","pinyin":"beijing","jianpin":"bj","type":"update"},{"cityid":3,"cityName":"南京","pinyin":"nanjing","jianpin":"nj","type":"add"}} }

?

delete 刪除 刪除指定cityid的城市信息 update 更新 更新某cityid的城市信息 add 增加 增加新的城市信息

App與html5的交互：

代碼地址：https://github.com/icodeu/AppProgrammingSource/tree/master/3.4%20App%E4%B8%8EHtml5%E4%BA%A4%E4%BA%92 html5和native直接靈活切換： 兩套界面 native html5各一套，通過接口里面字段控制是展示native還是html5界面。 策略：

后臺根據版本配置決定頁面是通過native還是htm5頁面進行展示和交互。

在app啟動的時候，獲取頁面是html5還是native頁面。

頁面跳轉實現松耦合，設計個NavigatorManager類，來控制項目里面所有頁面跳轉操作。

消滅全局變量：

當app切換到后臺，之前存放的全局變量會很容易回收，如果切換回前臺，可能會因為使用某個全局變量，但這時變量為null而崩潰。 解決辦法： 序列化。 使用intent來進行數據傳遞（缺點，不能攜帶數據量大的數據）。 將數據序列化到本地，如果內存中的變量回收，就從本地去獲取。 上面方案的問題：

強制執行序列化操作，容易ANR。

序列化生成的文件，會因為內存不足丟失。

JsonObject ,JsonArray不支持序列化，HashMap<String, Object>不一定支持序列化，ArrayList<HashMap<String, Object>>不一定支持序列化。

2的臨時解決方案： 使用完，清空，然后強制序列化到本地，確保本地文件體積減少。 3的解決方案：以字符串序列化到本地；HashMap<String, Object>，ArrayList<HashMap<String, Object>>建議Object轉為String,否則就要遍歷將Object轉換為String。

如果Activity也被銷毀了呢？

onSaveInstanceState() onRestoreInstanceState() ? User是唯一的全局變量（指的是用戶信息，登錄后獲取到的，客戶端是應該長期緩存的，除非注銷登錄）。

?

總結

以上是生活随笔為你收集整理的第三章 经典场景设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。