資源是好不容易下載到的，關於代碼，沒什麼好說的。
說點這期間遇到的問題。
漫畫 的每一話大概有20幾個頁面，實際都是jpg圖片，那麼這裡就涉及到
展示圖片，但要確保不出現OOM的異常。
“
當然google的android也為我們封裝好了若干方法，來方便快捷地完成這項工作，如ImageView的setImageBitmap，setImageResource，BitmapFactory的decodeResource等，但是盡量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource來設置一張大圖，因為這些函數在完成decode後，最終都是通過java層的createBitmap來完成的，需要消耗更多內存;
因此，改用先通過BitmapFactory.decodeStream方法，創建出一個bitmap，再將其設為ImageView的source，加載顯示。decodeStream最大的秘密在於其直接調用JNI>>nativeDecodeAsset()來完成decode，無需再使用java層的createBitmap，從而節省了java層的空間
”
上面這段話，網上一搜到處都是。
當我改用BitmapFactory.decodeStream 創建出一個bitmap，再將其設為ImageView的source，後，確實不報異常了。但是新的問題又來了。解析圖片所占的內存小了，但是圖片也被壓縮了，顯示效果不佳。
之後想是否可以使用緩存機制，保證當前頁的前一頁和後一頁加載在內存中，以保證切換畫面流暢，有點類似隊列的模式。
Android 真的提供這樣的機制 -- LruCache類 ，強引用緩存。
mMemoryCache = new LruCache(cacheSize) {
//必須重寫此方法，來測量Bitmap的大小
@Override
protected int sizeOf(String key, Bitmap bitmap) {
// 重寫此方法來衡量每張圖片的大小
return bitmap.getByteCount() ;
}
};
/**
* 添加Bitmap到內存緩存
* @param key
* @param bitmap
*/
public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
if (getBitmapFromMemCache(key) == null /*&& bitmap != null*/) {
mMemoryCache.put(key, bitmap);
}
}
/**
* 從內存緩存中獲取一個Bitmap
* @param key
* @return
*/
public Bitmap getBitmapFromMemCache(String key) {
return mMemoryCache.get(key);
}
class BitmapWorkerTask extends AsyncTask {
// 在後台加載圖片。
@Override
protected Bitmap doInBackground(Integer... params) {
final Bitmap bitmap = BitmapFactory.decodeResource(getResources(), params[0]);
addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
return bitmap;
}
}
確實能緩存，但也許是圖片比較大的原因，程序運行中連續快速切換下一頁時還是會在此處BitmapFactory.decodeResource 報OOM異常。
在最後eclipse生成帶簽名的apk時，我修改的項目的名字，結果更新引用後，出現了感歎號。
這時因為引用的jar包路徑不對了。右鍵項目名稱 BuildPath ---> Configure Build Paht...中，
然後上面有幾個選項卡找到 Libraries中出現紅色叉號的包為路徑錯誤的包，remove掉，重新添加即可。
最後用github上這個開源代碼了，覺得自己水平真菜，弱爆了。。
如下圖：
資源我用ps批處理壓縮過，為了保證清晰度，壓縮比例不大，所以安裝包會比較大。
至於這是不是福利就仁者見仁了，如果你不想用這個程序看，你可以解壓安裝包，資源就在assets文件夾下。
怎麼解壓apk文件，相信大家都知道的。
