[译]FaceBook出品：基于Android的内存优化

原文Memory optimization for feeds on Android——[Udi Cohen](https://www.facebook.com/udinic)。

数以百万的人在Android设备上运行FaceBook，浏览着新闻，资讯，大事，页面，朋友圈和他们关心的信息。一个叫Android Feed Platform的团队创建了一个新平台来提供这些信息。因此任何对这个平台的优化，都惠及我们的应用。我们下面着重于滚动的效率，希望能在满足人们求知欲的同时享受如丝顺滑的体验。

为了实现这个目标，我们做了几个自动化工具来测试平台在不同场景和设备上运行的性能，以此衡量出代码在运行时的内存使用率，帧率等。当使用其中一个工具，TraceView，测试发现对Long.valueOf()有频发的调用，使内存中堆积的对象过多，导致崩溃。这篇文章描述了如何解决这个问题，我们权衡的潜在的解决方案的过程，和我们对平台所做的最终优化。

方便的缺点

通过TraceView发现Long.valueOf()的频发调用后，我们进一步地测试发现，在滚动新闻时，意料之外的是这个方法被更频发地调用了。

当我们查看调用堆栈时，发现方法调用者不是Facebook的代码而是编译器的隐式代码插入。调用这个方法用于把long装箱成Long。Java既支持复杂类型，也支持基本类型（像integer，long等关键字），并提供无缝转换。这个特性称为自动装箱，把一个基本类型转化为对应的复杂数据类型。虽然是很便利的特性，同时也创建了对开发者透明的对象。

这些未知对象占用内存总和。

app的heap dump检测出来Long对象占用了很大一部分内存；但是每个对象本身并不大，数量之多令人咂舌。特别使用Dalvik时容易发生问题，不比新一代的Android运行时ART，拥有分代垃圾回收机制，能选择更合适的时机回收数量众多的小对象。当我们将新闻列表上下滚动时，大量对象被创建，垃圾收回策略会让应用暂停，去清理内存。越多的对象堆积，内存回收就更为频繁，导致应用卡顿甚至崩溃，给用户留下劣质的体验。

幸运的是，拥有TraceView和Allocation Tracker这样的好工具，帮我们分析出卡顿的原因，问题处在自动装箱上。我们发现大部分的操作，是把long插入到HashSet<Long>时发生的。（我们使用Hashset<Long>来存储新闻的哈希值，校验新闻是否唯一）。HashSet提供快速的对象获取，因为哈希值计算出来由long表示，然而HashSet<Long>是与复杂对象交互的，当我们调用setStories.put(lStoryHash)时，自动装箱无可避免。

解决方案是，继承Set，使其能与简单类型交互，结果并未如我们想象那么简单。

可行的方案

存在一些与简单类型交互的Set子类，这些库几乎都是十年前的当Java还是J2ME的年代。为了彰显新时代的活力，我们决定在Dalvik/ART上进行测试，确保他们能在更苛刻的条件下表现良好。我们写了个轻量级的测试框架，这些老库将与HashSet一较高下。结果显示这些老库都比HashSet速度快，占用内存少，但是它们内部还是会创建对象，例如TLongHashSet， Trove库的一个类，用1000个例子测试大概分配了2MB内存。

其他测试库，比如PCJ和Colt，结果几乎一致。

已存在的轮子并不符合我们的需求，所以就为Android创建一个合适的Set轮子。看看HashSet的源码实现，简单地使用HashMap来实现复杂的功能。

    public class HashSet<E> extends AbstractSet<E> implements Set<E>, ... {

        transient HashMap<E, HashSet<E>> backingMap;    

        ...

        @Override public boolean add(E object) {
            return backingMap.put(object, this) == null;
        }

        @Override public boolean contains(Object object) {
            return backingMap.containsKey(object);
        }

        ...
    }

往HashSet里添加对象意味这往HashMap里面添加键和HashSet自己的实例作为值。HashSet通过内部HashMap是否包含相同的键值来校验插入的对象。可以选择使用Android优化过的Map来优化HashSet。

介绍LongArraySet

也许你很熟悉LongSparseArray，它是Android提供的一个以long为键的Map。可以这样用：

    LongSparseArray<String> longSparseArray = new LongSparseArray<>();
    longSparseArray.put(3L, "Data");
    String data = longSparseArray.get(3L); // the value of data is "Data"

LongSparseArray的不同于HashMap，当调用mapHashmap.get(KEY5)，HashMap是这样查询的

整个取值的过程是，用键值的哈希值作为下标，在列表中获取值。时间复杂度是O(1)。

而LongSparseArray取值是这样的。

LongSparseArray通过二分查找法在有序的键列表中找到键，时间复杂度是O(log N)，通过键的下标在值队列中取到对应值。

HashMap需要额外分配空间来避免冲突，导致寻址变慢。LongSparseArray创建两个列表使占用内存小，但为了支持二分查找法，需要一块连续的内存空间。当添加的数量大于当前连续内存数时，需要一整块新的连续内存。当总长度超过1000时，LongSparseArray的表现就不太理想啦，存在巨大的性能问题（参考官方文档或者看Google的短视频）

因为LongSparseArray的键是简单类型的，我们可以创造一个新的数据结构，把LongSparseArray作为HashSet的内部类来使用。

就叫LongArraySet吧！

新的数据结构看起来是有希望的，但优化的第一条规则是“测试”。通过先前的测试框架，我们把新的数据结构与HashSet进行比对，通过添加X个item来测试，检查它们内部的结构，随即移除他们。在添加不同数量(X=10,X=100,X=1000….)，同时平均下来每次的操作时间，结果是：

我们发现Contains和Remove操作在运行环境下都有性能提升。随着数量的增加，Add操作耗费更多的时间。这个上面LongSparseArray内部结构造成的——当数量超过1000时，表现就比不上HashMap。在我们自己的应用中，只需要处理几百个item，值得替换一下。

我们也看到内存使用的提升，在看Heap和Allocate Tracker时，我们发现对象创建的数量减少了，下面是

HashSet和LongArraySet在20次循环中添加1000个item的对比结果。

LongArraySet能很好地避免创建Long对象，在这个场景下减少了30%的内存分配。

结论

通过深入了解其他数据结构，我们能够创建出更适合自身的数据结构。垃圾回收运行的次数越少，掉帧的情况发生就越少。使用新的数据结构LongArraySet，和以int为键的IntArraySet，就能优化整个应用的内存使用。

这个例子表明任何可行的方法都需要衡量得出最优解。我们也接受这个方案并不是放之四海而皆准的，对于重量级数据而言，这个提升是有限的，但对于我们来说，是更优解。

你可以在这里找到源码，我们也为接下来面临的挑战而感到兴奋，希望日后还有机会分享更多的干货。