使用Android 运行环境编写应用的最大好处是这是一个托管内存环境，也就是说你不必担心对象创建以及销毁时产生的额外负担。但是要小心即使是托管内存环境你也有可能面临内存泄漏。我是Colt McAnlis.内存泄漏是一个复杂代码库中常见的问题。如果处理不当，很容易导致很严重的应用性能问题。

你可能记得，Android运行环境中的内存堆会根据配置类型划分成不同的独立的区块，还会根据系统为将来的垃圾处理，对这些配置的最佳整理，来进行划分。当新的对象被配置时，这些特点都会被考虑在内，以便为其找到最佳的位置。这还要根绝你使用的Android运行环境的种类。重点来了。

每一个区块都有指定单位大小。配置文件时，我们会跟踪记录综合的大小。随着区块的扩大系统会进行垃圾回收活动。从而为将来的配置释放内存。这些垃圾回收活动通常不是影响性能的大问题。但是，当它们反复进行时，会迅速消耗帧时间。你花在垃圾回收上的时间越多，处理其他事情的时间越少，比如渲染或音频串流。

现在，导致垃圾回收串联的主要原因是内存泄漏。内存泄漏指的是应用不再使用的对象，但是垃圾回收没有把它们辨认出来。结果它们就一直留在你的内存里，占用了宝贵的空间，不释放给其他对象。当你开始出现更多的内存泄漏时，可用堆上的可用区块就会不断变小，这会导致不断启动垃圾回收以便释放空间用于执行其他程序任务，但是这并不凑效，因为堆的一大部分都无法释放。找到并解决这些泄漏是很棘手的。实际上，你必须清晰理解你的代码，能够确认你代码库的关键活动中的每一项工作都在正常进行为了确认这一类的行为，需要一些详细审查。

现在，假如你想确认，当用户在你的应用里留下活动时之后所有关于这个活动的内存都会被清理。你该怎么做呢？首先你要使用这个Heap工具，在活动开始时抓取这个内存的快照。接下来，你要创建一些已知的或低内存的配置的空白活动，你可以将其转换成你要检查的活动，第三，当你进行转化时，要强制开启一个垃圾回收活动。如果所有东西都销毁得当，那么所有的活动配置都将清除。如果你在第二个堆转储里发现任何可疑数据，那就是本不该存在的内存。切换成Allocation Tracker工具是个很好的法子。可以更深层的挖掘配置出现的情况。使用这个工具，你可以开始追踪配置，从活动开始前直到它上传完成。而且你已经将其转换成了空白的活动。

Allocation Tracker 工具会按照对象创建的顺序给你一个已创建对象列表，并包含它们创建的位置。这样一来你就可以追踪各种类型的流氓分配，并分析出它们为什么没有被释放。