共计 5557 个字符，预计需要花费 14 分钟才能阅读完成。
内容作为 App 产品新的促活点，受到了越来越多的器重与投入，短视频则是减少用户粘性、减少用户停留时长的一把利器。短视频的内容与体验间接关系到用户是否违心长时停留，盒马也提出全链路内容视频化的布局，以实现商品力表白的晋升。目前已有短视频场景包含：首页、搜寻、商品详情、达人秀、沉迷式视频、真香视频、盒区首页 feeds 流、话题、UGC 内容、话题合集落地页、社群、菜谱、盒拍一键剪、直播回放、weex 等。
作者|神捕
审校|泰一
本次优化的指标是将盒马 App 与支流短视频 App 体验对齐，如抖音、手淘等。优化具体的硬性指标有播放成功率、卡顿率、秒开率。另外，为了反馈用户观看短视频过程中的实在体验，盒马还新增了体感指标：首帧渲染时长。
优化成果比照
https://www.youku.com/video/X…
以上视频测试基于 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 端短视频的体验优化实际。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实际技术文章，在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云产品技术交换群，和业内大咖一起探讨音视频技术，获取更多行业最新信息。
