手机淘宝性能优化全记录

手机淘宝作为一个航母级的应用，承载了100多个业务方，部分是H5的形式接入，还有超过50个Native的业务方。为了规避安卓DEX65535的方法数限制以及各业务独立开发等需要，淘宝工程师门也是采用了多DEX(多Bundle)的开发形式，而且手淘作为一个以图片显示为重点的APP，在性能上不可避免的遇到了比较多的问题。

手机淘宝遇到了那些性能问题?淘宝技术专家使用那些优化分析工具找出各种性能瓶颈的?在应用界面到中间件的优化过程中，淘宝又有那些经验与我们分享?你不在现场?没关系，王曜东演讲的技术要点就在这里。

手机淘宝遭遇的5大性能问题

1、APP启动慢

2、界面跳转慢

3、事件相应慢

4、滑动和动画卡顿

5、展现内容慢

手机淘宝的目前使用的主要优化工具

开发者选项中和Android提供了多个分析工具。

• GPU Profile：查看每一帧的绘制情况。除了查看帧率，我还会用这个工具检查各个界面在静默状态下的不必要的刷新问题。
• Show GPU Overdraw：查看过渡绘制用的工具，因为手淘的很多界面效果也比较复杂，很容易出现过渡绘制。
• Dump View Hierarchy：用于查看界面的布局、View和层级嵌套情况。特别是在没有源代码的情况下，查看非常方便。
• TraceView：强大的性能跟踪工具，也是我们在优化中用的最多的工具。
• SysTrace：主要用于查看UI的绘制问题，跟踪CPU执行情况等。
• Trace OpenGL：可以录制每一帧的绘制过程，逐个绘制命令查看。
• AlloCation Tracker：内存分配跟踪，也是个调试性能的强大工具。
• Threads 工具可以显示所有线程信息及查看线程正在执行的代码。
• Heap和Memory Monitor：查看内存的分配和变化情况。Memory Monitor还可以查看内存的抖动和GC情况。

TraceView作为最主要的工具，王曜东特别强调了手淘在优化过程中的一些经验。比如找出高频率调用函数有时候会比较特殊，要结合实际代码，比如写SharedPreferences的apply函数需要注意，因为Commit函数会阻塞IO，这个函数虽然执行很快，但是系统会有另外一个线程来负责写操作，当apply频率高的时候，该线程就会比较占用CPU资源。类似的还有统计埋点等，在主线程埋点但异步线程提交，频率高的情况也会出现这样的问题。

其次查看布局性能，一种是直接查看，如onMeasure，OnLayout函数占用的百分比和平均执行时间过高导致的性能问题，很直观就可以看出来。还有就是例如getview中的布局性能，整体的查看inflate的个数和耗时问题的跟踪。还有一种是通过View的draw函数或者buildeDisplayList函数的调用和递归调用次数来判断布局的复杂度。

关于复用问题，比如在listview滑动过一遍后，在对这部分区域做跟踪，如果getview中还有infalte布局，那就是复用还有可以优化的地方。

类的初始化耗时，像构造函数，静态初始化等这些问题很容易忽视，但是在性能优化的后期，这些小的细节点，也是优化的方向，特别是在主线程中调用的时候。

手淘启动过程优化详解

启动过程优化是所有大型APP都会遇到的问题，启动慢，加载多。手淘也不例外，手淘的模块非常多，各业务方都希望在启动的时候都能把自己先初始化起来，加上手淘也是分了很多了dex文件的，这样在首次启动的时候不仅要dexpot这些模块的dex，还有主dex中的不少模块有初始化动作。

▲手机淘宝启动过程优化

▲启动变慢案例分析

1、分析各个模块的线程数量，检查线程池的合理性。通过去掉不必要的线程和线程池，再控制线程池的并发数。减少启动阶段的线程以及控制线程的启动时机。

2、通过MAT等工具，找出那些分配过多的对象和数量特别多的对象，我们前面看到很多的容器，其实大部分都用不到，不需要在启动时就创建。淘宝工程师也发现首页缓存的布局太多，浪费较多的资源，所以需要减少缓存的数量。通过Systrace，可以发现在网络线程，统计，主线程等GC很多，所以对频繁创建的对象如网络库的Byte数组，Buffer等做复用。

3、当有较多的主线程耗时，需要将主线程中的耗时操作都异步处理或者移除。

4、IO：通过TraceView可以发现SharedPreference有2个线程经常占用很多的CPU时间，还有几个下载文件的线程如update等以及数据库操作这些都是IO操作。优化过程就是删除不必要的io操作，有些做延后处理。例如统计数据，淘宝减少了采样的频率，并且增加缓存数量，以空间换时间，减少数据库和SharedPreference的读写。在做较多数据库操作的时候也会开启事务功能来减少IO的次数。

5、以前在启动阶段会安装主要模块的bundle，首页再启动后过3秒也会发送通知来唤起更多的模块，像淘宝的webview框架，在初始化的时候会把线上活动资源都缓存到本地，这个过程设计到json的解析，下载和解压缩等，非常耗资源等等，这些模块叠加在一起就导致了首页就会直接卡主及白屏很长一段时间，所以对这一种模块改为懒加载，并且要限制拉取活动的数量。还有像购物车，微淘，店铺，旺信等以前是首次启动会安装，也是改为懒加载。因为首次Dexopt会比较费时，特别是安卓5.0以后，所以很多模块都改为懒加载，这样首次使用该模块的时候变慢一点，但是整体启动速度一下就提升了。

6、降级摇一摇功能的检测频率，减少地理信息的数量

7、首页在欢迎页的时候开始初始化布局等，加快展示。退出的时候以前都是销毁Activity的，为了加快下次启动，释放到图片等主要资源，Activity不做销毁。

手机淘宝各界面的优化

GPU过渡绘制的优化

不需要显示的布局及时隐藏

去掉层叠布局中多余的背景设置

图片控件有前景内容的时候不显示背景

界面背景定义到Activity的主题中

减少Drawable的复杂Shape使用

自定义控件onDraw函数减少绘制层次

自定义控件使用canvas.clipRect

优化布局性能

优化层级

灵活使用布局

减少View数量

异步infalte或者提前infalte

自己做控件的回收复用

加快界面显示

主线程不做耗时操作

减少主线程GC停顿

利用本地缓存

减少数据传输和解析时间

注意线程优先级

利用局部刷新

总结：

1、发现性能问题的时候首先要分析原因，是卡住还是卡顿，是网络慢的问题，还是是内存问题亦或是其他系统的问题。手淘遇到有时候手机厂商的一些特殊控件的bug也会导致问题。安卓系统本身的内存管理和一些监控软件有时候也会导致性能问题。

2、通过多种工具额配合找出问题。

3、有些问题，一个地方存在很可能其他地方也有，可以到类似的模块去查看，如圆形的图案，输入控件在输入法退出时引发的自动刷新问题。

4、建立程序内的监控，以及代码层面的扫描等，手淘自己的代码平台有一些性能的扫描，但还不够完善，手淘APP内部也有性能监控的模块可以实时监控和统计程序中的性能问题。

5、冰冻三尺非一日之寒。代码扫描和监控等本身都有一定的局限性，而且监控本身就会导致一定的性能损耗。所以一个性能好的APP应该防患于未然，从源头抓起，只有开发人员都对Java和android相关的性能相当熟悉，在开发的时候处处考虑到性能和内存问题，追求卓越，才能防微杜渐，这也是手机淘宝接下来努力的方向之一。

优化是没有止境的，虽然通过这几个月的优化，手淘在内存使用上下降了接近50%，平均帧率提高了近20%，首页的GC减少了90%。但是在低内存，低性能的手机上，手淘还是面临很多的挑战，需要不断的去优化，也需要从源头上就把性能这块提升。