UI 界面性能优化（四）

减少系统GC次数

Android 上的 GC 会引起性能卡顿，必须重点优化。除了于图片内存引起 GC 的优化，我们还做了如下工作：

减少对象分配，找出不必要的对象分配，如可以使用非包装类型时，使用了包装类型，避免 Autoboxing -> unboxing 的过程，同时避免大量对象字符串的+号操作，如果不考虑线程安全引起的问题时，优先使用 StringBuilder，而非StringBuffer去进行字符串操作，Handler.post(Runnable r)等频繁使用。

对象的复用，对于频繁分配的对象需要使用复用池。

尽早释放无用对象的引用，特别是大对象和集合对象，通过置为，及时回收。

防止泄露，除了最基本的文件、流、数据库、网络访问等都要记得关闭以及unRegister自己注册的一些事件外，还要尽量少地使用静态变量和单例。此外通过系统提供的 Android Lint 静态扫描工具可以去提前分析类似的 Handler 泄露和 Thread 造成的内存泄露。

控制finalize方法的使用，在高频率函数中使用重写了finalize的类，会加重 GC 负担，使得性能上有几倍的差别。

合理选择容器，在性能上优先考虑。

数组，即使我们现在习惯了使用容器，也要注意频繁使用容器在性能上的隐患点：首先是扩容开销，HashMap 扩容时重新 Hash 的开销较大。其次是内存开销，HashMap 需要额外的 Map.Entry 对象分配，需要额外内存，也容易产生更多的内存碎片。SparseArray 和 ArrayList 等在内存方面更有优势。再次是遍历，对于实现了RandomAccess接口的容器如 ArryList 的遍历，不应该使用foreach循环。在移动设备中，尽量避免使用枚举，通过自定义的表意清晰的int常量去替代。

用工具监控和精雕细琢：在页面滑动过程中，通过 Android Studio 自带的 Memory Monitor 工具查看内存波动和 GC 情况，还可通过 Allocation Tracker 工具观察分析内存的分配，发现很多小对象的分配问题以及是否存在内存泄露问题。在我们平时的开发工作中，我们还集成了 LeakCannary 去监测内存泄露情况。

利用 Trace For OpenGL 工具找出界面上导致硬件加速耗时的点，例如一些圆角图片的处理等。

其他细节方面的优化

通过 TraceView 工具发现，一些 Banner 轮播广告和文字动画在移出可视区域后，仍然存在定时刷新，不仅耗电也影响帧率。优化措施是在移出可视区域后停止动画轮播。 

中间件的代码被上层业务方调用得比较频繁，容易有较多的高频率函数，也容易产生细节上的问题。除了频繁分配对象外，例如类初始化性能、同步锁的额外开销、接口的调用时间、枚举的使用等都是不能忽视的问题。