从350ms到80ms,打造新零售场景下iOS短视频的极致丝滑体验

作者:李凯(神捕)

盒马 Android 短视频秒播优化方案 :拒绝卡顿,揭秘盒马鲜生 APP Android 短视频秒播优化方案

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

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

优化效果对比

以上视频测试基于 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 请求,渲染业务数据。这样保证了视频与业务数据的加载可以异步执行,由于用户主要目光是集中在视频上的,所以从用户的视角直观的来看,页面加载速度变快了。

音频体验优化

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

1. App 启动不打断音乐;

2. 进入音频独占页面(如真香视频、沉浸式视频)时,打断音乐;

3. 退出 App 或退到后台时,恢复音乐;

4. 音频播放不受静音键控制(类似抖音)。

后续优化方向

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

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

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

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

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

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

关注【阿里巴巴移动技术】,每周 3 篇移动技术实践&干货给你思考!