滴滴老司机开车：启动速度优化（老司机滴滴车）

码个蛋(codeegg)第 805 次推文

作者：渡口一艘船

博客：https://juejin.im/post/5dc589406fb9a04aa2035cab

码妞看世界

1. 背景

国际化司机端机器参差不齐，拉美司机端机型都是非常低端，特别是巴西，拉取omega数据统计内存2G及以下，占比70% ，而澳洲司机端都是高端三星机器平均内存都是4G以上，因而我们必须得"压榨"我们的代码，吝啬的分配cpu以及内存。

2. 发现问题

介入卡顿优化之后，发现有个Top3的ANR以及一些相关卡顿

【ANR】at com.sdu.didi.component.controlpanel.ControlPanelView$15.onAnimationUpdate(ControlPanelView.java:154)

在拉美一些配置一般的机型上容易出现，大多是内存只有1G和2G的机型,根据omenga信息可以定位到ANR是由于首页出车动画在波纹属性动画刷新的时候会卡顿，卡顿严重了就ANR了，而且首页出车动画基本是一直在跑着的，确实影响用户体验。

3. 分析问题

分析代码

看了下代码

嗯，不卡才怪呢，之前的同学为了实现这个无限循环的波纹动效，通过自定义一个圆点view，然后通过属性动画改变这个圆点的宽高、透明度，然后在动画变化时requestLayout，这个效果是实现了，但是性能是极差的，属性动画这些操作都是主线程去执行的在高端机型是可能性能hold住但是拉美的手机上有的直接就扛不住了，看来需要压榨一下我们的代码了。

4. 解决问题

SurfaceView

Android中 View是通过刷新来重绘视图，系统通过发出VSYNC信号来进行屏幕的重绘，刷新的时间间隔是16ms,如果我们可以在16ms以内将绘制工作完成，则没有任何问题，如果我们绘制过程逻辑很复杂，并且我们的界面更新还非常频繁，这时候就会造成界面的卡顿，影响用户体验，为此Android提供了SurfaceView来解决这一问题.

SurfaceView 继承自View，是 Android 中一种比较特殊的视图（View），

它跟普通View最大的区别是它有自己的Surface，在WMS中有对应的WindowState，在SurfaceFlinger中有Layer
一般的Activity包含的多个View会组成View hierachy的树形结构，只有最顶层的DecorView，也就是根结点视图，才是对WMS可见的。这个DecorView在WMS中有一个对应的WindowState。相应地，在SF中对应的Layer。
而SurfaceView自带一个Surface，这个Surface在WMS中有自己对应的WindowState，在SF中也会有自己的Layer。虽然在App端它仍在View hierachy中，但在Server端（WMS和SF）中，它与宿主窗口是分离的。这样的好处是对这个Surface的渲染可以放到单独线程去做，渲染时可以有自己的GL context。这对于一些游戏、视频等性能相关的应用非常有益，因为它不会影响主线程对事件的响应。

综合这些特点，SurfaceView 一般用在游戏、视频、摄影等一些复杂 UI 且高效的图像的显示，这类的图像处理都需要开单独的线程来处理。它的优点如下

SurfaceView 通过子线程中进行画面更新，View 则在主线程中进行画面更新。
SurfaceView 用于被动更新，如频繁画面更新，View 则用于主动更新，如触摸点击等事件响应等。
SurfaceView 在底层实现了双缓冲机制，效率大大提升了，View 则没有。

下面清晰说明了SurfaceView的原理

如果当前画面需要不停绘制或者数据处理量较大时，为避免 UI 线程堵塞，就用 SurfaceView 代替 View。

SurfaceView拥有独立的绘图表面，即它不与其宿主窗口共享同一个绘图表面，由于拥有独立的绘图表面，因此SurfaceView的UI就可以在一个独立的线程中进行行绘制，由于不占用主线程资源,使得它可以实现大多复杂而高效的界面绘制，如视频播放 VideoView和OpenGl es的GLSurfaceView 直播软件的不停地点赞动效、天气软件的全屏雨雪动效、游戏中的流水、云之类的变化等等。

使用SurfaceView一顿操作之后使用 HandlerThread SurfaceView一顿操作后（公司管得紧，项目代码不准外放o(╥﹏╥)o）

我们使用一台小米2s(内存2G)来看下效果，

5. 效果

前置条件：小米2s 内存2G、只运行2个软件（司机端、模拟定位软件）、打开app后置于首页出车页面无其他操作