当谈论如何提升视频的体验时，我们需要明确互联网视频市场的背景和现状，并分析用户对于视频体验的期望和挑战。

• 首先，随着移动网络的普及和互联网带宽的不断提升，视频观看已成为互联网的主要应用之一，视频内容也涉及更多的领域，例如教育、电商、社交等。同时，视频流量的份额也逐渐扩大，占据着互联网流量的重要部分。可是，面对海量的视频内容，用户们提出了越来越高的要求，如需要更快的加载速度、更流畅的播放体验、更高的画质和分辨率等，这些要求又产生了一系列挑战。

• 其次，不良的网络环境和设备所带来的影响也是视频体验不理想的重要原因之一，例如网络延迟、带宽瓶颈、设备性能等，这些因素都可能导致视频的卡顿、画面模糊、下载速度慢等质量问题。此外，由于网络环境的差异和视频内容的多样性，保障用户体验变得更加复杂，需要针对不同的用户需求和设备特性，采用不同的优化方案和技术手段。

针对这些问题，我们需要梳理出优化视频体验的技术手段和测试角度，以提高视频的质量和用户的满意度。并通过不断的优化落地，最终来提升视频体验并提高市场竞争力。

上半年我们针对得物视频场景做了数据摸底，主要涉及的场景包含视频流和沉浸视频流，收集的指标包括卡顿率，秒开数据，CPU，内存及主客观质量。从结果来看，我们在内容质量、秒开、卡顿上都有一定的提升空间。

为了优化以上存在的痛点问题，我们针对视频规划了一系列的优化项目，主要从视频质量提升、视频卡顿率优化、视频秒开优化这 3 方面进行整改。

发布入口

• App发布

• 创作者后台发布

• 达人后台发布

发布流程

• 视频素材选择

• 视频封面设置

发布上传

• 获取 Oss 上传地址和 Token

• 将 URL 上传给社区服务端

我们前面讲到视频体验优化的 3 个方向，第一点就是视频质量提升，那么如何能够让我们的视频有所提升，其实重点就是在编码这一块下功夫。这里我们主要介绍得物社区编码处理。

云厂商

• 原视频 720P-H264 窄带高清转码工作流（基础转码）。

• 转码完成后调用【算法服务】去水印&加水印。

• 触发时机：视频发布完成自动触发。

社区服务

• 动态发布接口：

• 保存原视频链接到内容媒体库。

• 转码检查，增加云厂商转码视频检查记录，待检查转码状态。

• 转码检查处理脚本：

• 检查云厂商转码是否完成，完成后保存到内容媒体库，同时请求算法去水印。

• 检查内容媒体中心转码是否完成，完成后保存到内容媒体库。

• 媒体中心回调：

• 接收媒体中心转码回调，更新内容媒体库原视频宽高、时长等信息。

• 往转码检查表增加媒体中心转码的多种转码视频记录待检查转码状态。

• 宽和高同时大于 720 会触发 2 路转码（720P-H265和1080P-H265），否则一路转码（720P-H265）。

• 算法处理回调：

• 接收算法去水印、生成封面图等处理回调，保存处理后内容文件到内容媒体库。

• 去水印类型，MQ 通知中后台视频转码已完成，中后台开始审核流程。

媒体中心

转码服务：

私有化微帧转码服务：

• 接收服务端原视频转码请求，云厂商转码。

• 监听二审二审通过、热门视频、高帧率处理微帧转码。

• 监听打标结果、篮球美妆类视频，视频增强转码。

• 视频首帧截取处理。

• 回调社区服务媒体中心，回传转码完成后视频相关信息。

算法服务：

• 去原视频水印。

• 生成封面图。

• 加品宣水印。

• 策略算法商品封面图。

业务播放流程

前面我们在转码时介绍了很多种不同的转码类型、同时针对不同的转码定义了 Type 的多个枚举值，作用就在于业务这边的播放优先级策略。

• 冷启动读取视频切换策略。

• 视频动态下发兜底播放 URL、转码播放 URL、类型 Type。

首帧加载逻辑

• 可以先看一下下面的例子：

• 首帧获取逻辑

• 播放逻辑策略

• 取得新的视频首帧图片后需要自行拼接裁剪参数，目前统一转 Heic 格式图片，裁剪宽度最大 360（和线上逻辑一致），高度自适配。转成 Heic 可以有效降低文件大小，减少网络传输成本，提升首帧加载速度。

• 优先级：视频首帧的图片缓存 > 双列卡片的封面图片缓存 > 加载首帧网络图并以黑底图兜底。

沉浸流冷启优化

播放器复用

优化前：

优化后：

这里我们可以明显看到优化前，关注流进入到视频详情页会黑一下，优化后就更加丝滑了，肉眼看不出有黑屏的情况。这里我们主要就是使用了播放器复用来解决这个问题，节省创建播放器内核等待时间。

• 创建 View 的时机

• 每次点击提前创建 View 开始解码。

• 跳转后将 View add 到屏幕上。

复用过程就是 A 页面解绑 -B 页面绑定 -B 页面解绑 -A 页面重新绑定。

当然这里，推荐流是比较特殊的，有个共享的播放器实例。

沉浸流冷启优化功能测试完成后，没有发现什么问题，但是在我们性能的每日 DailyRun 报告中发现有一处内存泄漏，并且每一个脚本都报了这个泄漏，查看堆栈信息关键字 ImmersiveVideoInitManager preRenderVideoView，大致猜测是首页沉浸流预渲染导致静态变量没释放的问题，联想到这个技改需求，进一步和开发确认，发现的确是这个需求引入的。通过这个例子，进一步验证功能测试和自动化是相辅相成、相互兜底的，多方组合手段才能提升线上的稳定性。

• 原因：在回归时，发现部分视频倍速播放出现音画不同步的现象，排查发现，该视频是 60fps，2 倍速的话会变成 120fps，播放器渲染不过来了。因此当倍速 *帧率 >60，双端都存在这个问题。

• 解决：在业务方面，我们是没有 60fps 转码的，因此播放器仅支持 60fps 播放，60+ 倍速没有支持，这类视频是百度超分转码没有限制帧率，导致会有部分视频出现60fps，最终双端播放器支持 60+fps 播放解决该问题，同时我们这边其他转码也支持高帧率视频了。

原因：这个问题是当时一个技改 Https 转 Http 播放时出现的一个问题，从关注流到视频详情页我们会切换成 Http 的地址进行播放，当返回时又变成了 Https，播放器接受到的播放地址发生发生变化，导致播放器进行重播了，而不是续播。

解决：外部有播放器，涉及场景切换时兼容这种逻辑。

• 安卓性能基线

• iOS性能基线

• 左移发现问题

  双端累计发现了一些问题，其中有个别问题是版本技改引入，成功左移拦截。

• 发热压测分析报告

性能

• 建立性能基线，覆盖当前业务核心页面，双端性能 Case 稳定运行。

• 针对 Debug 包进行 APM 平台打通，性能异常指标通知提醒，累计发现多个性能问题。

• 针对 Debug 包进行 Crash 拦截，并打通 Crash 平台和 Crash 异常通知提醒 ，累计发现多个 Crash。

• 性能问题归类。

分析

• 针对双端图文、视频、沉浸式、推荐流 4 个场景摸底排查并建立性能基线。

• 针对视频做发热压测分析。

• 推动并支持开发完成视频内容质量、秒开、卡顿上的一系列技改需求。

• 优化后完成性能分析并输出报告，各场景指标排名获得一定的提升，iOS 卡顿率下降 25%、视频失败率：下降 66.6%、首帧加载时长：降低 47%；Android 视频失败率：降低 42.8%；Android 首帧加载时长：降低 46.6%。

在如今这个体验为王的时代，我们在视频的体验上还需投入更多精力，只有不断探索新的技术方案，不断探索新的测试手段，我们才能成为行业的 Top。这也是我们未来努力的方向，比如主客观测评后台、视频转码技术优化、更多的左移、更多的辅助开发做一些分析等等。这需要多方合作，实现共同双赢。

最后感谢大家的耐心阅读！感谢在视频建设过程中合作的各位同学提供的诸多帮助~

关注得物技术，每周一、三、五更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞~
未经得物技术许可严禁转载，否则依法追究法律责任。