作者：于世雷(蓝彻)

通常情况下移动端 APP 由于受到设备性能所限一般较少有场景会处理超量数据，更多的是将复杂数据处理交付给服务端。本质上降低终端强数据处理是很有必要的，降低 CPU 使用率、减少内存抖动可以大幅提升 APP 使用体验。但是有时移动端也不得不处理超量数据，大麦选座就是这样一个强数据处理场景。

那么选座场景具体面对的是怎样的超量数据呢？ 上图是测试过程中使用的“奥运体育场”在大麦 APP 选座场景下绘制的 UI，这个体育场包含了 140+个看台，6 万+个可售座位。我们需要建立数据模型来描述一个座位，它的基本要素会包含座位 id、价格 id、坐标、座位角度、座位位置、座位状态 等等。结合业务场景，在购票流程中的变与不变，我们可以将座位拆分成 2 套数据：

1. 座位静态数据，它包含座位相对不变的部分，比如：座位 id、价格 id、坐标、座位角度、座位位置。

2. 座位动态数据，即座位状态。它是变化最为频繁的，比如：用户下单时座位从可售状态变更为已售状态，用户取消时座位会从已售状态回归到可售状态。

假设我们使用 XML 来描述座位静态数据，使用 JSON 来描述座位动态数据，那么上述体育场 6 万+个座位对应的座位静态数据的文件大小为 9.6M，座位动态数据的文件大小为 1.8M。

想象一个场景：拥有 6 万+座位的超大体育场、偶像级歌手、售前几十万人关注、实时在线选座分钟级别售罄，静态数据的下载、动态数据的刷新、数据的解析与合成，不管对于服务端还是客户端都会是一场考验。当然选座场景自然是不会直接传输这样未经过压缩的数据，但这也从侧面说明了选座场景的数据量级，也就是说选座移动端必须要有能力快速、高效处理数以万计座位的解析、合成、渲染，以保障超级场馆实时在线抢票。

下面我总结了一些核心的提升选座场景用户体验和支撑超大场馆实时在线选座的方案和策略。

接口预加载策略

选座场景相对于其他大麦业务使用到了更多的网络接口及 CDN 下载，从 SKU 页进入一个选座页最少要使用 5 次网络请求才能最终合并成选座 UI。

• 渲染时：

• Areainfo 网络接口 ，选座引导接口主要描述静态看台信息、静态文件 cdn 信息、开关信息等；

• StaticSeat CDN 下载，静态座位文件网络下载；

• StaticSvg CDN 下载，静态 SVG 文件网络下载；

• DynamicInfo 网络接口，场次信息、票档实时信息；

• Seatstatus 网络接口，座位实时状态信息。

• 刷新时：

• DynamicInfo 网络接口，场次信息、票档实时信息；

• Seatstatus 网络接口，座位实时状态信息。

• 选座中：

• Precheck 网络接口，预锁座功能；

• CalcPrice 网络接口，实时算价功能。

已知渲染需要至少使用到”渲染时“标出的 5 个请求，正如木桶效应一样，选座场景的页面加载时长取决于最后一个接口的返回，而通常接口 RT 取决于网络繁忙程度、网络状况、服务端处理能力等，客户端要做的是尽可能将这些网络请求分类、前置化处理，降低网络请求并发对 CPU 瞬时负载。

静态数据预加载

这里的静态主要主要是指"Areainfo"引导数据、”静态座位文件“、”静态 SVG 文件“的预加载策略，特点：他们通常在一个项目上线后很少发生变化，存储于 CDN 服务器中。静态数据预加载策略 就是在进入选座场景之前的链路如 SKU（场次与票档选择页）进行闲时下载。这样可以前置 ”Areainfo“、”StaticSeat“、”StaticSvg“ 请求。

网络接口预加载

一般在 Android App 开发过程中我们会在 Activity.onCreate()方法中触发网络请求，完成页面渲染。在测试的过程中我们发现像选座 Activity 这样的页面，从 startActivity()方法调用到目标 activity.onCreate()之间存在 50-60ms 的调度、创建时间。所以我们将”DynamicInfo“、”Seatstatus“前置到 startActivity()，即启动选座场景时立即发出以上 2 个请求。

这样就可以将需要并发的请求打散、按其特点进行分类、分阶段执行。即可利用静态数据不易变更的特性进行前置下载，也兼顾到动态数据的实时性获取。

静态数据缓存

正如上述提及的”奥运体育场“，其包含了数以万计的座位信息、复杂的 SVG 文件。解析合成都是较为耗时的操作，如果只是使用一次随即丢弃肯定是非常浪费资源的。在选座场景抢票过程中，用户可能会在”售前“、”售中“反复进入”商品详情“、”SKU“、”选座“页面，为这类静态数据做缓存策略是非常有必要的，这可以大幅降低 CDN 下载压力，提升 SVG、座位结构对象的复用率，降低 CPU 内存抖动程度。

选座场景提供了 BaseLoader、策略性 Cache 对全场景进行数据预加载、内存缓存管理，通过对软引用的使用，即保持了静态数据高效可复用，也避免由于内存紧张而出现强未使用态的强引用静态数据无法及时释放的情况。

1. ImageLoader，支持 SVG、JPG 加载、缓存

2. Seat3DVrImageDataLoader，支持 VR 图像下载、解密等

3. Seat3DVrDataLoader，支持 VR 结构化数据下载、解密等

4. SeatLoader，支持多种静态座位数据的下载、解密、缓存等

静态数据压缩

静态座位数据压缩

静态座位数据压缩方案，内部代号“Quantum”是大麦自研的一套针对选座静态座位数据进行压缩解压的一套解决方案，其主要组成部分包含了核心解压缩算法、加密解密方案、数据完整性校验等。

观察静态座位数据的结构，可以总结出一些特点：包含大量的数值型字段如 Long 型的座位 id、Int 型的座位编号、Int 型的座位角度、Long 型的价格 id、Int 型的坐标 以及批量重复的看台号、排号等。数值型字段非常适合使用差值法组合 Ziazag 整数算法进行压缩，批量重复性的看台、排号等信息非常适合字典方式简化存储。Zigzag 的核心思想就是通过位运算、原码及补码的转换移除数值型内存二进制中“无意义的 0”，仅存储从 1 开始的“有效数据”，从而达成对数据的压缩，数值绝对值越小压缩比率越高。

以下是关于“Quantum”方案与原大麦选座场景静态数据方案的对比。

压缩效率：相比于”XML+GZIP"，“Quantum+GZIP”压缩后的静态文件缩减了 70%以上。

解析速度：相比于"XML Pull"解析方案，“Quantum”座位解析时长总体缩减了 80%以上。

静态 VR 数据压缩

静态 VR 数据指的是一套描述看台-座位-关联的 VR 数据信息的一套数据，大麦选座场景使用了 Google Protocol Buffers 来存储 VR 结构化数据，以”北京某剧院“ 的 VR 数据为例 使用 JSON 文件来描述 VR 结构数据的文件大约为 640KB，当使用 Protocol Buffers 时 文件的大小约为 250KB，而经过 GZIP 压缩后仅有 8KB 大小。

压缩效率：相比于使用 JSON 描述 VR 结构化数据，使用 Protocol Buffers 文件大小缩减了 35%以上。实际上 Protocol Buffers 内部使用了 Ziazag 整数压缩算法，VR 结构化数据中存在座位 id 属于 Long 型，Protocol 虽然可以进行一定程度的压缩，但由于其算法对整型绝对值越小压缩比率越高的特点，我们仍然可以通过差值法进一步缩减 Protocol 压缩比率，但从 GZIP 压缩后的结果来看已经足够小了。暂时未启动进一步优化。

相关链接：Google Developers | Protocol Buffers

座位动态数据压缩

座位的动态数据，这里指的就是座位的状态。假设使用 2 代表可售、8 代表已售，早期大麦选座场景使用 JSON 来描述”座位 id“与”状态“的映射关系。假定我们使用 JSON 格式以文本文件来存储“奥运体育场”座位状态，6 万+个座位对应的状态文件的大小为 1.8M。

1.8M 看起来并不算很大，但对于先前提到的超级火爆的项目来说，开抢瞬间会出现庞大的目标用户在秒级区间涌入选座场景，服务器要想在极短时间处理如此高并发和数据分发所面临的压力是可想而知的，即便传输过程中使用了压缩方案。

因此早期使用 JSON 数据来表达座位状态的选座场景不得不从缓解服务端压力的角度改变请求策略：即“座位状态分组请求”，进入选座页按服务端给定的看台分组依次、延时进行请求，比如：把 6 万+个座位 按 5000 左右一组，每隔 50ms 请求一批，直到所有座位更新完毕。这意味着一个 6 万+座位的场馆仅其状态的请求就可能长达 600ms 以上，加之其他请求、视图渲染，这类超大型场馆的选座场景很难在 1s 以内完整加载并渲染完毕。

因此我们必须找到新的方案，它应该具备以下特征：一次请求可以获得全部座位状态、请求的数据量要足够的小、客户端设备解析的性能要足够的快。

座位动态压缩策略

所以选座场景推出了动态压缩方案，它本质上并不复杂，观察原始 1.8M JSON 文件，它的"大"主要是因为大量 sid（座位 id）的存在，JSON 本身包含了一下冗余结构。如果移除这些 sid 呢？ 假定座位如果在“静态座位文件”中是有序的，那么服务端就可以按照座位顺序堆积 2、8 状态（2 代表可售、8 代表已售）。比如一个看台编号为“3538263” 它有 7 个座位，座位状态依次是 “2222228”，那么它就可以由“繁复”的 JSON 的一部分转变为 ：“3538263”：“2222228”

而一旦某个状态连续出现 6 个及以上时就可以缩写为 （x,s），上述 case 即可以缩写为 “3538263”：“(6,2)8”。字符的数量是浮动的，因此我们叫它动态压缩方案。

对比原 JSON 方案，我们考虑一个最为复杂的场景“奥运体育场”场馆座位，相邻的座位总是一个可售一个不可售，动态压缩无法进行缩写优化，那么使用 JSON 来返回 6 万+座位的文本文件大小约 0.9M （即 1.8M 的二分之一，因为仅需要返回可售的即可）。如果使用动态压缩方案文本的大小约 67KB，我们可以简化的认为这个文件中存储了 6 万+个连续"2"和"8"，额外附加一下看台 id 信息。不难看出即便是最复杂的场景动态压缩方案描述状态的数据量也是非常小的。

那什么场景会触发极简压缩呢？ 想象如下一个选座场景，刚刚开售，所有座位均未被售出，那么动态压缩方案就会处于极简压缩状态，举个例子: {"3538263":"5000,2"} 即代表"3538263"看台下的 5000 个座位均为可售~以测试使用的“奥运体育场”最复杂场景下估算：

压缩效率：座位状态动态压缩文件相比于 JSON 文本缩减了 90%以上数据传输量。

解析速度：在该场景下使用一加 7Pro：FastJson 还原 6 万+座位耗时 200ms，使用动态解压缩方案仅耗时 5ms，解析时长缩短了 95%以上。

视图层级优化

ViewStub

从上图"布局文件"中，选座场景是大麦中使用 ViewStub 最多的地方，一般可以被懒加载的视图均被转换成 ViewStub，相比于复杂的”暂不可见“视图 ，ViewStub 及其简洁，减少初始化渲染时 View 对象的创建和排版。

视图层级

从"Layout Inspector"可以看到选座场景的布局是相对简洁的，自上而下。”开启过度绘制“全屏处于浅绿色。为了减少视图层级，选座场景把 App 共用基类 Activity 多出用于 Title、错误页等工具性布局都移除掉了，自身提供了非通用，但更简洁的布局，以减少视图层级结构。

绘制性能优化

座位位图复用

图 1 为北京某场馆，座位近 3000 个。我们可以看到一个选座场景一般会包含多个票档，座位的颜色与其票档的颜色一致，一个座位最终如何展示是由：color （座位颜色）、angle（座位角度）、type（座位类型：已售、可售、锁定）、addAlpha（是否已选中）共同决定的，座位的位图是在绘制时根据上面 4 个要素实时通过 SVG 绘制出来的，相同 4 要素的座位会复用已经创建的同一位图。

原始方案把座位 4 要素组成一个字符串作为 Key，通过 HashMap 进行座位位图复用，伪代码如下：

private final HashMap<String, Bitmap> mSeatPool = new HashMap();
public Bitmap get(int color, float angel, int type, boolean addAlpha) {    int angelInt = (int) angel;    String key = "key_" + color + "_" + angelInt + "_" + addAlpha + "_" + type;    Bitmap seat = mSeatPool.get(key);    if (seat == null) {        seat = newBitmap(color, angel, type, addAlpha);        mSeatPool.put(key, seat);    }    return seat;}

位图复用的思路是正确的，但是原方案使用的字符串作为 Key 带来 2 个问题，1 是字符串拼接的本质是 StringBuilder 对象的创建；2 是字符串拼接的字符数量>16 个会触发 StringBuilder 的 ensureCapacityInternal 方法；以上述场馆为例每次 touch 事件导致的绘制都会创建近 3000 个 StringBuilder 对象、并触发其扩充 API。反复滑动时必然会导致内存快速增长、GC 的频繁发生。

我首先想到类似的场景就是 Android 视图测量中使用到的 View.MeasureSpec，MeasureSpec 将 int 值高 2 位存储为 Mode，低 30 位存储为 size。利用相同的思路作用于位图复用是非常适用的，优化后选座使用 Long 值作为 Key 存储座位 4 要素，高 8 位存储位图 addAlpha（是否选中），9-16 位存储 type（座位类型：已售、可售、锁定），17-32 位存储 angle（座位角度），最后 32 位存储 color（座位颜色），并且使用 Android 系统优化过的 LongSparseArray 替代 HashMap。这有几个好处，Key 值的计算全程使用位运算，运算速度足够的快，反复滚动时不会再触发 StringBuilder 对象的创建和扩充，内存不会出现激增现象，视图滑动平均帧率提升了 4 帧以上。

利用 Android Studio Profiler 性能分析工具，对位图复用前后进行对比：

1. 优化前的方案在选座视图滑动时存在了大量的 StringBuilder 对象创建，导致 Profiler Method 视图存在大量锯齿。优化后不会在出现大量锯齿，onDraw()中不会在出现对象创建场景。

2. 从内存的角度上看，优化前滑动时会导致内存快速增长，从图中可以看到很快即有 270M 增长到 328M，并触发一轮 GC，而这样的事情会在反复滑动、缩放动画中一直出现，这种内存的抖动势必会影响到绘制性能，虽然 GC 几经 Google 优化，但仍然避免不了”stop the world“。优化后我们可以看到不管如何滑动内存始终保持在 270M 左右。

绘制提效优化

如果只是一张座位的位图，其绘制成本是非常低的。但是当量级足够大时，绘制的性能将受到影响，以图 1 北京某场馆为例，一次 onDraw()就需要绘制近 3000 次座位位图，这对于客户端设备是有一定挑战的。因此选座场景针对大场馆，初始化展示时仅展示看台图，当用户选中某个看台时会自动放大适配屏幕，将处于屏幕中的看台下的座位及其周边可见的座位实时绘制出来。针对小场馆，仅出现在屏幕中的座位会被绘制。这种小技巧对提升绘制效率非常有效。

角度计算优化

图 3 所示，可以看到座位可能存在角度，其一般指向舞台中心。端设备在实时绘制座位时，需要实时计算放大缩小比率结合座位偏转角度才能最终计算出座位的大小。

早期选座场景使用 Matrix 来计算角度问题，平时的绘制我们也可能使用 Matrix 进行相关计算，但无疑在这个地方 Matrix 矩阵计算是浪费性能的。相反优化后使用 Math 三角函数进行计算大幅度提升了带角度的座位大小计算性能。

浮点数据计算优化

当座位大小实时计算完毕，我们发现在使用 Canvas 进行绘制时，如果将 float 转换成 int 时，会带来非常好的性能提升。但这也会带来一定的体验问题，为什么呢？如果不做任何处理即将浮点转成整型，实时滑动时就可能会出现座位由于精度问题而产生抖动。因此选座场景在这里做了近似处理，在合理阈值内进行 int 转换，即利用整型值计算优势同时将抖动降低到不明显可接受程度。

硬件加速

早期的选座场景并未开启硬件加速，你可能会惊讶于视图为什么没有开启硬件加速，因为绝大多数场景我们并没有主动关心过硬件加速，因为系统默认的 View 和一般的自定义 View 默认就是开启的。为什么早期的选座场景要主动关闭硬件加速呢？

从选座场景上看我们使用了大量的 SVG，无论是场馆底图、场馆图、座位位图都使用了 SVG 进行绘制，我们可以简单的把一个 SVG 看成一个有序的、可绘制的指令集合，在 Android 中我们需要一个简单的可被复用的绘制“容器”，而这个“容器”就是 android.graphics.Picture。查看 Picture 的类描述我们会发现它真的很适合用来记录可绘制指令，但它仍然存在一些问题，以下是类官方描述：

A Picture records drawing calls (via the canvas returned by beginRecording) and can then play them back into Canvas (via draw(Canvas) or Canvas.drawPicture(Picture)).For most content (e.g. text, lines, rectangles), drawing a sequence from a picture can be faster than the equivalent API calls, since the picture performs its playback without incurring any method-call overhead.

Note: Prior to API level 23 a picture cannot be replayed on a hardware accelerated canvas.

从类描述中的“Note”可以看到在 API Level 23 以下的设备无法使用硬件加速，查阅 Google 开发者文档也可以看到，下方图片是 Google 对可支持硬件加速绘制指令、以及第一个支持的 Api Level 进行了一段描述。可以发现在 API 28 是一个分水岭，绝大多数指令在 28 及以上得到了支持。

硬件加速方案：

优化方案对 API Level 进行区分即可，28 以下的设备仍然保持早期的使用软件层进行绘制的方案，对始终不支持硬件加速的绘制指令进行了评估确保我们的生产 SVG 工具中不会出现这些指令，并添加了远程开关以确保遇到问题可实时关闭硬件加速功能，当设备 API LEVEL >=28 时开启硬件加速。此后选座 Android 场景的滑动平均帧率终于在这个阶段突破了 50FPS。

相关链接：Android开发者 | 硬件加速

线程任务处理

在接口的预加载策略中有提到选座场景对选座”渲染时“使用到的请求根据其请求的数据特点、时效要求进行了分阶段、策略性前置。使得渲染时不会在选座页面的 onCreate()同时并发 5 个以上的网络请求。从性能分析工具 Perfetto 我们可以看到主线程、静态座位数据下载解析线程、静态 SVG 下载解析线程等的时间轴即任务处理情况。

1. 从 Perfetto 中我可以观察到分散的策略是生效的，静态座位、SVG 在 SKU 页闲时触发了下载并完成了解析、内存缓存。

2. 从 Perfetto 中关键的渲染任务相关线程无明显的阻塞现象发生。

3. 在进入选座页的同时 DynamicInfo 请求、SeatStatus 请求很快被发起。

4. 座位动态解压缩方案在座位合成过程中非常快速的完成了座位状态合成。

相关工具链接：Perfetto工具

总结

下图是 21 年选座场景在性能监控工具上页面加载时长、滑动平均帧率。可以看到页面加载时长呈现明显的下降趋势，而滑动平均帧率呈现明显的上升趋势。实际上大麦选座场景的页面加载速度超过了 APP 自身 80%以上的核心页面，而选座场景同时也是这些核心页面中网络使用、数据处理最为复杂的页面之一。

截止 2022 年 6 月份 ，页面平均加载时长由 20 年的 850ms 下降到当前的 320ms，页面滑动平均帧率由 20 年的 38 帧上升到 54 帧。选座场景的优化并不是一蹴而就的，而是经历了长期的、持续的性能优化~

以此篇文章，整理记录一下选座场景在持续提升用户体验过程中做过的一些努力 ~