恭喜你！你研发了一款新的社交应用。看起来非常厉害但是你不同的收到报告说当用户下载大量的新的个人档缩略图时，应用会出现卡顿情况，并且速度很慢。我是Colt McAnlis, 尽管你处在托管内存环境下，但是不恰当的使用内存依旧会造成一系列的性能问题。在短时间内配置大量对象，也是一个明显的问题， 你应该注意这一点。

你要记住，android 的内存堆是按配置的类型，划分成一个个堆里的区块的。随着这些区块内配置的增长，垃圾回收会开启，从而为未来的配置整理出需要的内存。根据你使用的Runtime的类型，垃圾回收活动可能会成为“世界终结型”的。就是说任何控制的代码遭遇线程后都会停止。垃圾回收活动会运行，直到完成时。才会继续执行。

垃圾回收项目的停止执行，通常不是一个容易被注意到的性能问题。但是，大量这种情况同时且重复的出现时，会很快消耗掉你的帧时间。消耗在垃圾回收活动的时间越多，意味着处理其他事情的时间就减少了。比如渲染和视频流畅。

现在造成垃圾回收大量串联的首要原因是内存流失。实际上，可在短时间内配置大量的对象，并将它们极短时间内进行释放，就会出现内存流失。你懂的，就跟你刚刚编写的那个功能一样，可以查看某个导演的新片有没有收到公共观点的影响，如果还没有受到影响，就配置一系列的社交博文，并将它们推向内部框架。就跟你差不多。

首先，你要冷静下来，实际上这并不是太大的问题。其次，快速配置大量对象，实际上会用大量的内存流失造成对象区块的污染。一旦你达到了保留内存的阀值，垃圾回收活动会启动来整理区间。即使内存配置很微小，但是它们在你的堆内造成的压力，依旧会让垃圾回收启动，这会消耗你宝贵的帧时间。导致用户体验到性能的变化。因为你已经跳过了16毫秒的渲染时间界限。

要解决这一类问题，方法其实也挺直接的。首先，不知道你注意到没有，在内存监控里，你短时间内得到了一大片的垃圾收集活动，而这很有可能是因为你这里出现了大量的内存流失。你可以使用Android Studio 内的Allocation Tracker工具进行更深层次的探索，你会发现一大堆类型相近的对象，它们从差不多相同的调用栈内产生，集中在很短的时间内。这是内存抖动的一个经典的信号，很容易就会发现，这正是你应该展开调查的地方。一旦你确认了元凶，是时候移动代码来解决问题了。这本身也是非常直接了当的。例如，要确保你没有在内循环中为了明显原因配置对象。试着把这些配置移除循环之外，或尽可能完全避开他们。在你视图的onDraw功能里，对于配置对象我也给你相同的建议。实际上这是内部循环的一个相同的问题。任何时间屏幕需要重画时，或者要运用动画时，你都会要一帧帧的召唤这些功能。，这一过程很快就会积累并且为你的堆增加压力。

如果某些情况下，你必须要建新对象，可以考虑考虑对象池模式。实际上，你会有一个用于配置一组对象的对象池，你的代码不必每次都到堆里去，它可以从内存池中抓取可获得的对象。当然这个模式也有弊端，那就是你现在的负责释放对象，在使用完要将它们释放进内存池。也就意味着对于高扰动对象，就会需要一些消耗一些精力，在创建和销毁时合理管理这些对象。