配置文件时，抄录自：Android Performance Patterns: Garbage Collection in Android
写出成功应用的重要一点是让程序员尽可能高效的工作，这样他们可以专注于真正重要的问题。但是有时候这项开发工作，会造成不容易被发现的新的性能问题。我是Colt McAnlis, 虽然Android Runtime为程序员提供了很多高效的机会，但同时它也展现了很多关于性能的隐藏陷阱。你需要关心的最重要的一部分，与你如何配置于使用存储设备有着莫大的关系。
很多编程语言都被视为“高性能”，例如C和C++语言，通常需要程序员自己来管理存储设备。也就是说程序员需要自己在执行代码时，从堆积上配置存储区块，然后在不使用它们的时候，把它们从堆积上释放。
但是在两百万条的代码库里，很容易迷失在逻辑流程中结果就是没办法按意愿释放已经配置的内存。这些配置类型叫做内存泄漏，就是指，配置的内存没有被释放。
现在，另一方面一个管理得当的内存环境，将释放内存这个负担从程序员身上卸了下来。它追踪着每一个内存配置，一旦决定了某一片内存已经不再被程序使用了它会将其释放到堆积里，不需要程序员的干涉。真很棒，因为节省下来的时间可以做其他事。比如争论十字形护手用不用光剑。
好了，管理得当的环境中内存再生的过程，被称为垃圾回收。这是由John McCarthy 在1959提出的概念，以解决LISP编程语言的问题。它主要由2个原则。
1。找到程序例以后都不会用到的数据对象，2重新收回被这些对象占用的资源。想在想一想，垃圾回收可能会是多节的，如果你的程序里现在有20000个配置文件，哪些是不会再被用到的呢？或者说，你应该在何时执行垃圾回收活动来释放没有被使用的内存呢？这些真的是非常难的问题。还好没我们已经多出了近50年的创新与发展，这就是Android Runtime 的垃圾回收比MCCarthy的初始提议要复杂的多的原因。
它进过专门设计，尽可能快速、非入侵，Android Runtime 内存堆被有效的划分为不同的区块，根据配置的类型还根据系统为将来的垃圾回收活动对这些配置的最佳整理。新的对象被配置时，会考虑到这些特点来决定哪一个区块最适合这个配置，这取决于你是用的Android Runtime 的版本。
这里很重要。每一个区块都有制定单位的大小。我们会跟踪记录综合的大小随着区块的扩大，系统会进行垃圾回收处理，从而为将来的配置释放内存。
现在，值得注意的是，由于你使用 的Android Runtime不同，垃圾回收表现也会不同。例如，在DALVIK内很多垃圾回收都是“世界终结型”的。就是说任何运行的代码都会停止，直到垃圾回收结束。万一垃圾回收耗时比平时长，就会很麻烦，或者大量GC同时进行时，也很麻烦。因为这会明显的消耗你的帧时间。
另一款ART相反，扩大了同时的垃圾回收系统的功能，它倾向于移除大的GC停顿，但是还是会在重要的垃圾回收事件的最后出现一个小的暂停。
讲清楚，我们的工程师花了好多时间这些活动会尽可能快的进行，以减少中断和打扰。尽管这样，还是有可能导致你的应用出现一些性能问题。
首先，要知道在规定时间内应用垃圾回收的时间越长，那剩下的用于16毫秒内完成光栅化的逻辑处理时间就更短。如果你有连续的大量垃圾回收，或者长时间的垃圾回收，他可能会超过16毫秒的预期值，这会导致用户视觉上的卡顿，不流畅。
第二，要知道你的码流可能执行一些工作，迫使垃圾回收活动发生的更加频繁，或者让它的持续时间更长。比如，你在向内部循环中进行一大堆重要对象配置时，这会花费很长时间，这样一大堆对象就会污染内存堆。由于额外的内存压力你会很快的错过一大堆垃圾回收活动。这些类型的编程模式比你想象的更常见。
还好Android SDK 有一个强大的工具供你使用。例如，使用Android Studio 里的Memory Monitor 工具，你可以获得高水平的视图，查看你的应用对内存的处理。每当你看见一个配置内存下降时，说明发生了垃圾回收。短时间内频繁地下降可能预示着性能问题。你还可以看见你堆里的活跃对象，还可以看见你对其相应的代码配置，借助Heap 和 Allocation Tracker 工具。将内存转为性能，做起来比说起来难得多。