关于应用中过多的imageView和listView导致的不定时的oom（主要是bitmap 被VM buget 限制）和电子书的实现

网上流传的关于bitmap内存泄漏的解决方案，都是两种 ： 1.减小图片的大小，即使用options.insampesize，但是还是不能彻底的解决偶尔的oom。2.去掉bitmap被指向的引用，让system.gc来处理这个问题，但是bitmap是在native层分配内存，而且在多个activity存在得应用中无法根本上除掉bitmap得引用（除非再程序一开始时，成员都规定再onDestory里除掉再本activity里对bitmap的引用，可以得到，这是个教训），幸好bitmap提供了一个recycle的方法，让java可以主动的让native层的bitmap释放空间（这个方法解决了我的问题）。

再次说到我们这次遇到oom的问题，开始使用 eclipse自带的leap查看堆大小的使用，完全没有达到24M或8M就抛出oom，网上说的8MBitmap内存限制到我现在看来，感觉不是很靠谱，因为linux采用的内存策略是和硬盘交换的，所以理论上说（看别人写的）没有准确的内存计算，而eclipse看到的只是DVM的大小无法显示C++层的内存。所以使用adb shell 工具

 adb shell "dumpsys meminfo com.package.name" 可以查看到大部分需要看到的内存。使用了这个工具才看到我的应用里70%都是再native里的分配的，而且神奇的是我的中内存出现了25M的情况，不知道这个情况是通过linux内存无法准确计算解释，或者 24M是胡人的。 通过这次的OOM，重新搞了一个线程池，来管理下载线程，使打印信息更容易排错，重构了activity的基类，使用Application类实现一些程序的初始化。

下面写程序里比较蛋疼的错误解释：

/**
 * 因为activity的生命周期在启动下一个activity时(this表示当前activity,next表示下一个需要启动的activity)：this.onPause->next.oncreate->next.onstart->next.onresume->this.onStop->this.onDestory
 * 关闭当前activity回到上一个activity(this表示当前activity,pre表示上一个需要启动的activity)：this.onPause->pre.onrestart->pre.onstart->pre.onresume->this.onstop->this.ondestroy
 * 所以在onDestroy里recycle Bitmap，上一个activity先引用了没有回收的bitmap，但是onDestroy才被调用了，故在对当前的activity操作就会出现使用被回收的bitmap的错误
 * 又由于返回上一个activity只是单纯得把压入栈里的activity实例拿出来(这个表达的是：一个listView经过onCreat方法画好，进入onstop状态，等待它回来时不会重新去adapter里getView方法重绘，直接再内存块里拿出之前的数据画。)
 * 
 * @author demo
 *
 */

在电子书中实现绘图：图片大小 分辨率 长*宽*Config.模式 = 图片大小 ------------------------->480*800*Config.argb8888 = 480*800*4 = 1536000B = 1.5M

由于需要 两张 图片 才能作出 翻页效果 故 1.5M*2 = 3M ，加上一个drawable里存放的背景，需要打开一个应用里的电子书需要大概 5M得内存分配，由于应用其他地方使用了过多的内存没有释放，无法打开 电子书功能。电子书里实现 加粗某些文字，跳转到指定位置。由于是通过XML解析出目录和内容和加粗，都是通过记录 该跳转的开始位置实现。

以上为一部分总结，有时间再补充。