最近在研究Android的内存使用的一些情况，用来分析是否在移动应用中存在内存泄露的问题。现以自己的应用，分析下如何使用DDMS来分析。
我是根据网上的一些博客进行的分析，可能会有雷同，只为记录下来以后查看。
1. 安装：
这部分东西都不再讲了，Java环境，Android环境，Eclipse环境都配好的情况下。
2. 手机：
这部分也不用考虑了，我用的小米，也没有考虑是否有过root，应该无所谓的，调试开启是必须的。连接电脑，打开Eclipse。
3. 使用DDMS：
- 启动Eclipse之后，必须要切换到DDMS视图下，同时打开Device视图。
- 手机启动某个需要测试的App，在Eclipse的Device中选中App所启动的进程
- 选中该进程之后，点击Heap视图下的updated heap 按钮，我认为update的概念就是启动对我们需要测试的进程的检测程序
- 选中该按钮之后，点击Cause GC按钮，我认为点击该按钮就是请求我们要测试的进程的数据。当然请求一次之后就不用再次点击该按钮了，因为Heap会刷新页面，来显示当前的内存的变化。
总的情况还是去图上找吧。
4.分析数据：
DDMS 中使用Heap视图来分析的话，基本上就查看1个数据
在Data object 中有叫Total Size的数据。具体的含义就是当前进程中Java的对象所占用的内存总量。
5.判断依据：
一般情况下我的分析是这样的：
a.不断在手机上操作一个功能，如果该数据在不断地增加，则判定该功能模块存在内存泄露问题。
b.如果反复操作该功能之后，有一定范围的起伏，但是又被稳定在某一个有限的范围内，则说明代码良好。
C.如果有效内存手机，可能会出现程序被kill，但是程序被kill并不能代表程序一定有内存泄露。
实战分析：
动作：只是点击App上的查看相册的功能，点击返回，算一次动作。
如图所知在18次点击事件的同时，内存是随着点击次数，只增不减的不断增加，并且在第18次的时候很给力的程序崩溃掉了。
所以可以判定该功能是有很大可能存在内存泄露的。
注：
更多的时候并没有完全像例子中这么明显的内存泄露问题的，所以更多的时候，做内存泄露测试的时候，最好不要局限于一种方式，可以尝试不同的方式来验证我们的想法是否正确。