内容作为 App 产品新的促活点，受到了越来越多的重视与投入，短视频则是增加用户粘性、增加用户停留时长的一把利器。短视频的内容与体验直接关系到用户是否愿意长时停留，盒马也提出全链路内容视频化的规划，以实现商品力表达的提升。目前已有短视频场景包括：首页、搜索、商品详情、达人秀、沉浸式视频、真香视频、盒区首页 feeds 流、话题、UGC 内容、话题合集落地页、社群、菜谱、盒拍一键剪、直播回放、weex 等。

作者｜神捕

审校｜泰一

![](https://ucc.alicdn.com/pic/developer-ecology/8f8530e38bf44edbb29ff344c45879d1.png)

本次优化的目标是将盒马 App 与主流短视频 App 体验对齐，如抖音、手淘等。优化具体的硬性指标有播放成功率、卡顿率、秒开率。另外，为了反应用户观看短视频过程中的真实体验，盒马还新增了体感指标：首帧渲染时长。

## 优化效果对比

> https://v.youku.com/v_show/id_XNTgwMTI2MzgxNg==.html

以上视频测试基于 iPhone 6S，可以看到抖音在大多数情况下，在滑到下个视频后，可以立即开始播放；而盒马优化前，滑到下个视频后，会先展示封面图，再继续播放，有个闪跳的过程。优化后的盒马，效果已经与抖音效果接近。

为了衡量优化前后与抖音的体验对比，目前采用录屏数帧的方式，算出视频页面完全展示到首帧渲染时刻的耗时，体感数据如下：

![](https://ucc.alicdn.com/pic/developer-ecology/3f559865c6854f6d86debc742aa61e61.png)

此外还有一些硬性指标的优化，结果如下：

![](https://ucc.alicdn.com/pic/developer-ecology/2b52e73696694bd18ab589dd4ae17c70.png)

## 优化方案

在本次优化前期，调研了阿里集团内不少优秀的方案，大多数都是接入了手淘播放器，内核基于开源的 ijkPlayer。但播放器层面本身门槛较高，且手淘已优化较好了，所以本次的优化方向主要集中在上层业务的预加载方案上。具体从以下几个方面入手：

### 统一视频播放代理与缓存

视频的加载速度，很大程度上取决于从网络下载的耗时，增加视频缓存可以有效提高视频二次播放速度。为实现缓存机制，需要引入代理服务器，接手视频数据下载流程，如下：

A. 优化前播放流程：

![](https://ucc.alicdn.com/pic/developer-ecology/1fdb5db370414dee9602d8f525f2faaf.png)

B. 优化后播放流程：

![](https://ucc.alicdn.com/pic/developer-ecology/a5ac8cc3868a42d1a053b6f22b6abf93.png)

业务层往播放器设置 videoUrl 前，先对原始 videoUrl 加密，替换成 127.0.0.1 的本地 proxyUrl, 将请求引导到代理 webServer，此时调用 proxy 模块进行视频原始视频 url 的解析、缓存的读取或远程请求，最终再通过 server 返回数据给播放器。

视频播放增加中间代理也是业界常见手段，盒马依赖的手淘播放器也有现成的代理服务，但其代理功能放在另一个独立的 DW 库中，对盒马是冗余的，且目前 SDK 暂未支持独立的预下载接口，上层无法做首播优化。所以目前盒马做了独立的代理层，以支持上层灵活的定制。

自建代理还有个好处是，一些业务并非使用统一手淘播放器的场景也能同时享受到缓存服务，比如一些 flutter 页面使用的系统播放器。至少缓存的管理，目前设置了缓存区最大值的保护，在每次 App 回到前台时，进行视频缓存的清理。

### 针对 m3u8 的代理与缓存

除了常见的 mp4 视频外，日常还会遇到 m3u8 的视频，比如盒马中的直播回放视频。（视频链接）

该类视频与 mp4 不同，在请求 url 时并非直接返回视频流，而是先返回 playlist 文本，playlist 中才是可播放的各个视频片断，如下：

![](https://ucc.alicdn.com/pic/developer-ecology/79801c59028640839a20bd6e4bf367ca.png)

这种视频的缓存处理，采用的是修改 m3u8 playlist 中的 url，替换为代理 url 实现，就可以走代理了。之前 iOS 侧对 m3u8 的缓存支持有问题会 crash，原因是修改了 m3u8 的 Playlist 的第 1 个视频的 url 为代理 proxyUrl 后，播放第一片段正常，但后续的片段 url 仍是原始 url，手淘播放器在加载这种原始相对 url 路径时，内部会拼接上第一小段的域名和 path，导致第二段以后的 url 有问题，直接 crash。目前的处理方式是，把 playlist 中所有 url 全部改成代理 url 的 fullpath 即可。

这样有了 mp4 和 m3u8 两种视频后，完整流程如下：

![](https://ucc.alicdn.com/pic/developer-ecology/31cda781c0d749e09ddddace6a5debba.png)

### 独立预加载能力

上述的代理缓存，能提升二次播放速度，但对首次播放的视频，仍然无缓存可用，下载过程依然很耗时。所以需要独立的预加载能力，配合业务层，在合适的时机提前进行视频数据的下载（无渲染）。

目前底层提供 [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 在全屏的沉浸式视频场景中，虽然比之前快了很多，还是会让用户感受到瞬间的不流畅，即用户翻到下一页后，仍停留了一小段时间才播放了首帧。更糟糕的是，盒马上的视频，很多视频的封面图是达人自行上传的，很有可能与首帧不一样，这样从封面图跳到首帧的停顿感就更明显了。

![](https://ucc.alicdn.com/pic/developer-ecology/8165438e50144ffa82e4173fbd36463b.gif)

为达到抖音那种丝滑的感觉，除了上述措施外，还需要在上层体感上再做一层预处理，这里采用了双播放器策略，如下：

![](https://ucc.alicdn.com/pic/developer-ecology/15f59726ecae4615adf91bb2eaadf7a5.png)

基本流程是，播放当前视频的同时，预先实例化第二个播放器，加载视频 url 并播放到首帧后暂停，第 3、4 个视频进行串行预下载（预下载是纯下载的过程，无渲染逻辑）。在增加了下一个视频的 “预播” 机制后，用户滑到下个视频时，可以立即从首帧的暂停状态恢复为播放，不再需要预先显示封面图，也提高了播放体感上的速度。除视频以外的业务数据的渲染，可以放在用户滑动翻页的过程中进行。

### 首个视频的加载优化

上述优化了用户翻页的体验，但这种沉浸式页面的第一个视频的加载体验，仍需要单独拿出来优化，因为进入页面时，并没有给它留下预加载时机。如下：

![](https://ucc.alicdn.com/pic/developer-ecology/a14a97bb4b0e43c4a2ccf6fafd06a906.png)
 
如图所示，进入沉浸式页面时，总需要先请求页面 videoList 数据，然后再串行请求第一个视频的数据，就算加了封面图，也会让用户感受到慢。为此，现在修改策略为右图，在跳到沉浸式页面时需要前个页面提前传入 videoUrl，提前进行播放，同时进行 mtop 请求，渲染业务数据。这样保证了视频与业务数据的加载可以异步执行，由于用户主要目光是集中在视频上的，所以从用户的视角直观的来看，页面加载速度变快了。

### 音频体验优化

早期盒马这边没关注音频方面的优化，也收到了不少反馈，目前制定优化策略如下：

1. App 启动不打断音乐。
2. 进入音频独占页面（如真香视频、沉浸式视频）时，打断音乐。
3. 退出 App 或退到后台时，恢复音乐。
4. 音频播放不受静音键控制（类似抖音）。

## 后续优化方向

1. 播放器层提供进一步封装：封装视频加载、预加载、双播放器、屏幕内首个视频判断、退出、暂停等所有边界逻辑，目前各个业务需要考虑较多这种边界情况，可以考虑在封装层收掉。

2. 页面之间播放进度无缝切换：从小尺寸视频点击切换到沉浸式全屏过程，实现无缝切换，播放进度承接上个页面，音频也不打断。这样可以进一步优化沉浸式页面首个视频的体验，彻底实现 “0 耗时” 体感。

3. 多视频同时播放的性能优化：盒马大多数场景下只会同时播放 1 个视频，但部分业务需要同时播放多个视频，此时对内存、滚动性能提出较高挑战。

4. 视频转 Gif：针对部分场景下满屏都是视频又需要同时播放的情况，如果同时实例化 N 个播放器，效果可想而知。考虑尝试在视频内容生产阶段，同步生产 gif 图源，特定场景下 APP 可使用 gif 替换播放器实现预览。

5. 视频剪辑 — 语音转字幕：之前已基于淘拍能力在盒马上建立起了视频剪辑功能，为内容生产者提供常见、简单易用的编辑能力。考虑新增语音转字幕模块，用于增强视频内盒马商品力表达。

下一期我们将继续分享盒马 iOS / Android 端短视频的体验优化实践。

>「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。公众号后台回复【技术】可加入阿里云视频云产品技术交流群，和业内大咖一起探讨音视频技术，获取更多行业最新信息。

ITPub博客

从 350ms 到 80ms，打造 iOS 短视频的极致丝滑体验

最新文章