从350ms到80ms，打造新零售场景下 iOS 短视频的极致丝滑体验
作者：李凯(神捕)
本文为盒马 APP 短视频优化方案 iOS 篇，Android 短视频秒播优化方案，可见右侧链接内容 ：拒绝卡顿，揭秘盒马鲜生 APP Android 短视频秒播优化方案
“ 内容作为 App 产品新的促活点，受到了越来越多的重视与投入，短视频则是增加用户粘性、增加用户停留时长的一把利器。短视频的内容与体验直接关系到用户是否愿意长时停留，盒马也提出全链路内容视频化的规划，以实现商品力表达的提升。目前已有短视频场景包括：首页、搜索、商品详情、达人秀、沉浸式视频、真香视频、盒区首页 feeds 流、话题、UGC 内容、话题合集落地页、社群、菜谱、盒拍一键剪、直播回放、weex 等。”
本次优化的目标是将盒马 App 与主流短视频 App 体验对齐，如抖音、手淘等。优化具体的硬性指标有播放成功率、卡顿率、秒开率。另外，为了反应用户观看短视频过程中的真实体验，盒马还新增了体感指标：首帧渲染时长。
优化效果对比
效果视频可点击查看：从350ms到80ms，打造新零售场景下 iOS 短视频的极致丝滑体验
以上视频测试基于 iPhone 6S，可以看到抖音在大多数情况下，在滑到下个视频后，可以立即开始播放；而盒马优化前，滑到下个视频后，会先展示封面图，再继续播放，有个闪跳的过程。优化后的盒马，效果已经与抖音效果接近。
为了衡量优化前后与抖音的体验对比，目前采用录屏数帧的方式，算出视频页面完全展示到首帧渲染时刻的耗时，体感数据如下：
此外还有一些硬性指标的优化，结果如下：
优化方案
在本次优化前期，调研了阿里集团内不少优秀的方案，大多数都是接入了手淘播放器，内核基于开源的 ijkPlayer。但播放器层面本身门槛较高，且手淘已优化较好了，所以本次的优化方向主要集中在上层业务的预加载方案上。具体从以下几个方面入手：
统一视频播放代理与缓存
视频的加载速度，很大程度上取决于从网络下载的耗时，增加视频缓存可以有效提高视频二次播放速度。为实现缓存机制，需要引入代理服务器，接手视频数据下载流程，如下：
A. 优化前播放流程：
B. 优化后播放流程：
业务层往播放器设置 videoUrl 前，先对原始 videoUrl 加密，替换成 127.0.0.1 的本地 proxyUrl, 将请求引导到代理 webServer，此时调用 proxy 模块进行视频原始视频 url 的解析、缓存的读取或远程请求，最终再通过server返回数据给播放器。
视频播放增加中间代理也是业界常见手段，盒马依赖的手淘播放器也有现成的代理服务，但其代理功能放在另一个独立的 DW 库中，对盒马是冗余的，且目前 SDK 暂未支持独立的预下载接口，上层无法做首播优化。所以目前盒马做了独立的代理层，以支持上层灵活的定制。
自建代理还有个好处是，一些业务并非使用统一手淘播放器的场景也能同时享受到缓存服务，比如一些 flutter 页面使用的系统播放器。至少缓存的管理，目前设置了缓存区最大值的保护，在每次 App 回到前台时，进行视频缓存的清理。
针对m3u8的代理与缓存
除了常见的 mp4 视频外，日常还会遇到 m3u8 的视频。该类视频与 mp4 不同，在请求 url 时并非直接返回视频流，而是先返回 playlist 文本，playlist 中才是可播放的各个视频片断，如下：
这种视频的缓存处理，采用的是修改 m3u8 playlist 中的 url，替换为代理 url 实现，就可以走代理了。之前 iOS 侧对 m3u8 的缓存支持有问题会 crash，原因是修改了 m3u8 的 Playlist 的第 1 个视频的 url 为代理 proxyUrl 后，播放第一片段正常，但后续的片段 url 仍是原始 url，手淘播放器在加载这种原始相对 url 路径时，内部会拼接上第一小段的域名和 path，导致第二段以后的 url 有问题，直接 crash。目前的处理方式是，把 playlist 中所有 url 全部改成代理 url 的 fullpath 即可。
这样有了 mp4 和 m3u8 两种视频后，完整流程如下：
独立预加载能力
上述的代理缓存，能提升二次播放速度，但对首次播放的视频，仍然无缓存可用，下载过程依然很耗时。所以需要独立的预加载能力，配合业务层，在合适的时机提前进行视频数据的下载（无渲染）。
目前底层提供[HMVideoLoader preLoadUrls:URLS]方法，内部根据 url 进行视频缓存，下载大小限制 1M。多个视频同时预下载时，串行执行，保证不过多占用带宽，影响业务处理，等用户划动到视频位置时，可以直接开始播放，达到首开速度优化。
需要提下的是，此处的预加载，复用了上述代理类，也以 url 为 key 进行数据缓存，这样后续的二次播放也可以读取同一个的缓存。如果预加载过程中，滑到了该视频开始播放，则先停止预加载任务，避免同个视频的重复下载引起缓存冲突。
视频码率、分辨率优化
视频的预加载、代理缓存，都是基于提前准备视频数据角度考虑，这有个前提，就是准备时间很短，业务可以及时使用，如果视频很大，网络较差，业务又需要立即消费，则可能无法享受到优化效果，所以需要在视频码率、分辨率上进一步优化。
早期盒马都是播的 H264 视频，并且都是高清视频，这在很多 feeds 流上其实是用不上这么大的，影响加载速度且浪费流量。目前已在 cloudVideo 上申请配置了 H265 转码，盒马视频上传后可同时获取 265，264 两路视频，且有高清、标清、普清 3 种分辨率，这样就给端上按业务场景选择带来了自由度。先看下切换后同个视频大小的对比：
A. H264切为H265（都是高清）：原始H264大小为10.6M，切换后变为7.1M
B. 切到H265并且修改分辨率：原始H264为21M，切换后变为8.3M
从这两个例子可以看到，同个视频都是高清前提下，切到 H265 视频后，大小下降了约 30%，如果同时又降低分辨率到标清，视频大小减小非常明显，这意味视频码率下降了，用户可以更快下载到首帧数据。
目前盒马服务端接口已改造支持直接返回 H265 视频地址，iOS 这边的策略是：优先使用 h265，并按当前环境，请求不同分辨率：
A. iOS11 以下，使用 h264；iOS11 及以上，使用 h265(手淘播放器默认已开启硬解)
B. 分辨率，按当前机型（高、中、低）、网络类型（wifi/4g）、当前网络情况（强、弱）定义不同的分辨率请求顺序，如下，最终返回的数组按顺序拼成分辨率参数优先级，比如 hd#sd#ld 表示优先高清。
static NSString * const VIDEO_HD = @"hd";
static NSString * const VIDEO_SD = @"sd";
static NSString * const VIDEO_LD = @"ld";
static NSString * const VIDEO_HD_H265 = @"hd_265";
static NSString * const VIDEO_SD_H265 = @"sd_265";
static NSString * const VIDEO_LD_H265 = @"ld_265";
+ (NSArray*) getExpectedVideoDefinition {
NSArray *VIDEO_PRIORITY_GOOD_ENV = nil;
NSArray *VIDEO_PRIORITY_NORMAL_ENV = nil;
NSArray *VIDEO_PRIORITY_BAD_ENV = nil;
if ([[[UIDevice currentDevice] systemVersion] compare:@"11.0" options:NSNumericSearch] == NSOrderedAscending) {
VIDEO_PRIORITY_GOOD_ENV = @[VIDEO_HD, VIDEO_SD, VIDEO_LD];
VIDEO_PRIORITY_NORMAL_ENV = @[VIDEO_SD, VIDEO_LD, VIDEO_HD];
VIDEO_PRIORITY_BAD_ENV = @[VIDEO_LD, VIDEO_SD, VIDEO_HD];
}
else{
VIDEO_PRIORITY_GOOD_ENV = @[VIDEO_HD_H265, VIDEO_SD_H265, VIDEO_LD_H265];
VIDEO_PRIORITY_NORMAL_ENV = @[VIDEO_SD_H265, VIDEO_LD_H265, VIDEO_HD_H265];
VIDEO_PRIORITY_BAD_ENV = @[VIDEO_LD_H265, VIDEO_SD_H265, VIDEO_HD_H265];
}
AliHADeviceEvaluationLevel deviceLevel = [AliHADeviceEvaluation evaluationForDeviceLevel];
NetworkQualityStatus networkQualityStatus = [[NWNetworkQualityMonitor shareInstance] currentNetworkQualityStatus];
NetworkStatus nwStatus = [[NWReachabilityManager shareInstance] currentNetworkStatus];
NSArray *videoPriority = VIDEO_PRIORITY_NORMAL_ENV;
if (networkQualityStatus == SEMP_StrongSemaphore) {
if (deviceLevel == HIGH_END_DEVICE) {
videoPriority = VIDEO_PRIORITY_GOOD_ENV;
} else {
if (nwStatus == ReachableViaWiFi) {
videoPriority = VIDEO_PRIORITY_NORMAL_ENV;
} else {
videoPriority = VIDEO_PRIORITY_BAD_ENV;
}
}
} else {
if (deviceLevel == HIGH_END_DEVICE || deviceLevel == MEDIUM_DEVICE) {
videoPriority = VIDEO_PRIORITY_NORMAL_ENV;
} else {
videoPriority = VIDEO_PRIORITY_BAD_ENV;
}
}
return videoPriority;
}
沉浸式视频翻页体感优化
上述方案上线完，回头看数据，平均加载速度提升了，但仍然有近 200ms 的加载时长，这其中包括了播放器初始化以及下载或加载缓存数据、渲染首帧的过程，究其原因，在大量用户复杂网络环境下，很难保证所有人都有最佳体验。200ms 在全屏的沉浸式视频场景中，虽然比之前快了很多，还是会让用户感受到瞬间的不流畅，即用户翻到下一页后，仍停留了一小段时间才播放了首帧。更糟糕的是，盒马上的视频，很多视频的封面图是达人自行上传的，很有可能与首帧不一样，这样从封面图跳到首帧的停顿感就更明显了。
为达到抖音那种丝滑的感觉，除了上述措施外，还需要在上层体感上再做一层预处理，这里采用了双播放器策略，如下：
基本流程是，播放当前视频的同时，预先实例化第二个播放器，加载视频 url 并播放到首帧后暂停，第 3、4 个视频进行串行预下载（预下载是纯下载的过程，无渲染逻辑）。在增加了下一个视频的 “预播” 机制后，用户滑到下个视频时，可以立即从首帧的暂停状态恢复为播放，不再需要预先显示封面图，也提高了播放体感上的速度。除视频以外的业务数据的渲染，可以放在用户滑动翻页的过程中进行。
首个视频的加载优化
上述优化了用户翻页的体验，但这种沉浸式页面的第一个视频的加载体验，仍需要单独拿出来优化，因为进入页面时，并没有给它留下预加载时机。如下：
如图所示，进入沉浸式页面时，总需要先请求页面 videoList 数据，然后再串行请求第一个视频的数据，就算加了封面图，也会让用户感受到慢。为此，现在修改策略为右图，在跳到沉浸式页面时需要前个页面提前传入 videoUrl，提前进行播放，同时进行 mtop 请求，渲染业务数据。这样保证了视频与业务数据的加载可以异步执行，由于用户主要目光是集中在视频上的，所以从用户的视角直观的来看，页面加载速度变快了。
音频体验优化
早期盒马这边没关注音频方面的优化，也收到了不少反馈，目前制定优化策略如下：
-
App 启动不打断音乐；
-
进入音频独占页面（如真香视频、沉浸式视频）时，打断音乐；
-
退出 App 或退到后台时，恢复音乐；
-
音频播放不受静音键控制（类似抖音）。
后续优化方向
-
播放器层提供进一步封装：封装视频加载、预加载、双播放器、屏幕内首个视频判断、退出、暂停等所有边界逻辑，目前各个业务需要考虑较多这种边界情况，可以考虑在封装层收掉；
-
页面之间播放进度无缝切换：从小尺寸视频点击切换到沉浸式全屏过程，实现无缝切换，播放进度承接上个页面，音频也不打断。这样可以进一步优化沉浸式页面首个视频的体验，彻底实现“0 耗时”体感；
-
多视频同时播放的性能优化：盒马大多数场景下只会同时播放 1 个视频，但部分业务需要同时播放多个视频，此时对内存、滚动性能提出较高挑战；
-
视频转 Gif：针对部分场景下满屏都是视频又需要同时播放的情况，如果同时实例化 N 个播放器，效果可想而知。考虑尝试在视频内容生产阶段，同步生产 gif 图源，特定场景下 APP 可使用 gif 替换播放器实现预览；
-
视频剪辑—语音转字幕：之前已基于淘拍能力在盒马上建立起了视频剪辑功能，为内容生产者提供常见、简单易用的编辑能力。考虑新增语音转字幕模块，用于增强视频内盒马商品力表达。
下一期我们将继续分享盒马 iOS / Android 端短视频的体验优化实践。
关注【阿里巴巴移动技术】微信公众号，每周 3 篇移动技术实践&干货给你思考！
