在解决内存泄漏问题之前，先来看看如何发觉哪些进程存在内存泄漏，也就是内存泄漏的测试方法。主要有两种测试方法：
（1）模仿用户长时间使用设备，经过一段时间后（例如：几天），查看进程内存的使用情况，对于那些内存大量增长的进程，可以初步怀疑其有内存泄漏。
为了排除进程可能确实需要那么多内存的影响，一般在把大部分测试用例运行一遍之后，这时该分配的内存都已经分配，记录各个进程的内存使用情况，作为检测各个进程是否存在内存泄漏的基点。
进行长时间的操作后，再来记录各个进程的内存使用情况，与前面记录的结果比较，进行分析。
这种测试的好处在于，更加贴近用户的实际情况，结果比较真实可靠，测试成本比较低。其问题在于，虽然发现了有内存泄漏，但并不知道是在哪个测试用例出现的内存泄漏，程序员不得不查看其整个代码来查找原因，这对程序员来讲无疑是个噩梦。
而且这种方法很可能会造成：程序员奉命检查内存泄漏，经过千辛万苦终于找到一个内存泄漏，满心欢喜地修改完成后交工了事。而实际上呢，代码中往往不止一个地点存在内存泄漏。就这样程序员改完之后再测，测完再改，极大地浪费了时间。
虽然这种方法有很多缺点，但鉴于测试成本比较低，不用刻意去操作，还是应该多多使用。毕竟如果你想把东西卖给别人，自己先要用着好用。
（2）针对某个具体的测试用例，检查是否有内存泄漏。这时测试人员需要对每一个测试用例反复操作，比较前后进程的内存使用，以检查是否存在内存泄漏，工作量很大，非常麻烦。
这种方法的好处在于：程序员能够很清楚哪几个操作存在内存泄漏，那么他就可以采用后面讲到的一些方法，去查找内存泄漏，而且也防止了程序员在查到一个内存泄漏之后兴奋不已，草草地交工了事。这样可以提高程序员查找、修复内存泄漏的效率。
缺点在于：成本高，对于一个测试用例，检查其是否存在内存泄漏要比验证其是否工作正常，在时间和精力上要多几倍，因此不能像前面的方法频繁使用。
如果称第一种方法为系统测试的话，那么这种方法就可以称为单元测试。
从修复内存泄漏的角度来讲，程序员更希望采用第二种方法进行测试，针对其测试成本高的问题，可以想一些方法来进行优化。
● 对于用户频繁使用的测试用例要作为重点，经常进行测试验证。如果这些测试用例哪怕出现一点内存泄漏，经过多次操作累积，内存泄漏的数量也是很大的；同理，对于那些不常使用的测试用例，测试的频率可以降低。
● 对于守护进程的测试用例要详细，内存泄漏主要就出现在守护进程中。
● 对于非守护进程，基本可以不测，因为这些进程一退出，内存都还给系统了，但这里有一个隐患：如果这些进程与守护进程存在通信的话，可能导致守护进程出现内存泄漏。
检测设备的内存泄漏是一个长期的过程，需要不断进行测试、修改，千万不要今天想起来了，就测试一下，改完之后，就认为问题都解决了。
