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文件,相信大家都知道的。
下载: 穹の思念