内存回收1_android原生

每个手机的内存空间接不通，硬件条件并不是我们可以控制的，所以很多时候我们都需要老监控内存，比如当我们做游戏和原生android对接的时候，尤其是使用脚本语言，比如lua，我们就更加需要，此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。

  Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse的ADT插件，并以真机为例，在模拟器中的情  况类似)。用Heap监测应用进程使用内存情况的步骤如下： 　

　经过一段时间的使用总结，改工具得到的结论会比测试得到的结论要少很多，但是该工具用来测试点击icon是否持续增加内存是很有用的，比如测试listview的复用创建是否正常等，但是查看整体内存的时候并不那么可靠。会比实际测试同学得到的内存手啊很多。 　　
1. 启动eclipse后，切换到DDMS视图，并确认Devices视图、Heap视图都是打开的; 　　2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式; 　　
3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息; 　　
4. 点击选中想要监测的进程，比如system_process进程; 　　
5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标; 　　
6. 点击Heap视图中的“Cause GC”按钮; 　　
7. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况[如图所示]。 　　a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作; 　　
b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化; 　　
如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做data object，即数据对 象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据 对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断： 　　
a) 不断的操作当前应用，同时注意观察data object的Total Size值; 　　
b) 正 常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们 不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平; 　　
c) 反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大， 　　直到到达一个上限后导致进程被kill掉。 　　
d) 此处已system_process进程为例，在我的测试环境中system_process进程所占用的内存的data object的Total Size正常情况下会稳定在2.2~2.8之间，而当其值超过3.55后进程就会被kill。 　　
总之，使用DDMS的Heap视图工具可以很方便的确认我们的程序是否存在内存泄漏的可能性。 　　
4.触发GC(垃圾回收) 　　双击heap snapshot文件打开heap viewer，查看在堆中当前分配的内存的详细信息。 　　如果使用DDMS确实发现了我们的程序中存在内存泄漏，那又如何定位到具体出现问题的代码片段，最终找到问题所在呢?如果从头到尾的分析代码逻 辑，那肯定会把人逼疯，特别是在维护别人写的代码的时候。这里介绍一个极好的内存分析工具 – Memory Analyzer Tool(MAT)。 　　
我们再java代码中可以通过一些代码来处理抓取异常抛出时候的快照，如何操作呢： 　　最关键的代码是这句 　　
Debug.dumpHprofData(HPROF_FILE_PATH); 使得我们可以自己控制抓取heap快照的时机 　　
OutOfMemoryError是系统级别的错误，所以一般情况下不该捕获它。 　　
捕获了，并且重新抛出了一个调用了initCause方法的异常，我们也应该截获它，然后修正bug，而不是掩藏它。 　　这样能够让开发人员第一时间关注并解决bug，让我们再开发的时候更加的便利。
我们在这里只是需要抓取内存快照，干完活之后要记得把throwable交给系统来处理 Java代码 　　
mDefaultHandler.uncaughtException(thread, throwable);