https://github.com/nostra13/Android-Universal-Image-Loader
整合上述源码
资源是好不容易下载到的，关于代码，没什么好说的。
说点这期间遇到的问题。
漫画 的每一话大概有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<String, Bitmap>(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<Integer, Void, Bitmap> {
// 在后台加载图片。
@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文件，相信大家都知道的。
下载: 穹の思念