内存分配

编写高效的移动应用不是件容易的事，尤其Android上的应用依赖于Dalvik虚拟机的垃圾回收机制进行自动内存管理。如果不注意内存分配，这种机制本身就会引起性能问题。

        在性能敏感的代码路径上，如：视图的布局和绘制、游戏的逻辑代码等，进行任何与内存分配相关的操作都要付出代价的。多次内存分配之后，垃圾回收器将会剔除并停止你的应用，以释放部分内存。大部分时间里，垃圾回收进行的相当快，以致于不会被察觉到。然而，当你对list进行滑动或试图在游戏中击败对手的时候，发生了垃圾回收操作，可能你会突然察觉应用的性能或响应速度下降。垃圾回收消耗100～200ms是很正常的。比较而言，平滑的动画，需要在16～33ms内完成一帧的绘制，如果动画突然出现10帧的中断，可以肯定，用户会注意到。

        大部分时间里，垃圾回收是由大量小而短暂的对象触发的。部分垃圾收集器，如：分代垃圾收集器，能够优化对象的收集，这样，应用程序就不会被经常中断。不幸的是，Android的垃圾收集器无法进行这类优化，在性能关键的代码路径上创建短周期对象将使得应用开销极大。

        为避免频繁的垃圾回收，Android在其SDK中携带了一个非常有用的工具：allocation tracker（内存分配跟踪器）。allocation tracker是DDMS的一部分，DDMS必须已被用于调试。要使用allocation tracker，首先必须启动位于SDK的tools/目录下的标准版的DDMS，因为，Eclipse插件中嵌入的DDMS目前还无法进行内存分配跟踪。

        一旦DDMS运行，只需简单的选择应用进程并单击allocation tracker标签，就会打开一个新的窗口，单击“Start Tracing”按钮；然后，让应用运行你想分析的代码。运行完毕后，单击“Get Allocations”按钮，一个已分配对象的列表就会出现第一个表格中。单击第一个表格中的任何一项，在表格二中就会出现导致该内存分配的栈跟踪信息。通过allocation tracker，不仅知道分配了哪类对象，还可以知道在哪个线程、哪个类、哪个文件的哪一行。下面这幅截图展示了一次分配结果，是由Shelves在滑动ListView时截取的。

        尽管在性能关键的代码路径上移除所有的内存分配操作不是必须的，甚至有时候是不可能的，但allocation tracker可以帮你识别代码中的一些重要问题。举例来说，我在许多应用中发现的一个普遍错误：每次进行绘制都创建一个新的Paint对象。将Paint的创建移到一个实例区域里，是一个能极大提高程序性能的简单举措。我非常鼓励你去细读Android源码，从中你会发现我们是如何在性能关键的代码路径上减少内存分配操作的。同时，你还会因此而发现更多由Android 提供的API，这将有助于你进行对象复用。