1. 背景
在哔哩哔哩海外市场，视频上传是创作者最重要的功能之一，也是创作者对平台忠诚度和满意度的重要影响因素之一。然而，2022年Q3，产品负责人在海外对创作者进行线下访谈的过程中，发现超过50%的创作者对上传体验不满意，主要反馈有两个方面：上传速度慢、上传进度长时间卡住。这些问题严重影响了创作者的上传效率和体验，甚至导致了部分创作者放弃上传或者转投其他平台。
为了优化上传体验，提升视频上传成功率，我们于2022年Q4季度针对海外创作端上传链路进行了专项治理。但在实施之前，我们分析了面临的几方面问题和挑战：
缺少技术数据来分析具体问题，导致我们无法准确定位问题点和优化方向
东南亚相对于国内较弱的网络环境和机型环境，导致了上传链路上存在很多不稳定因素
如何在有限的人力资源下，平衡业务需求和技术需求，让产出最大化。
为了解决这些问题和挑战，我们从数据、产品、技术三个维度组织了一系列的工作
2. 建立指标
首先，建立数据指标来观测和衡量视频上传的效果。我们将视频上传分为两种类型：非先发后传和先发后传，并针对这两种类型建立相应的指标：取消率、失败率、成功率、未知结果率以及投稿成功转化率。通过这些指标，我们可以更清晰地看到视频上传的表现和问题，并根据数据进行优化。
3. 产品维度
基于数据分析，我们发现有两个方面可以从产品层面进行优化：一是增强用户对于上传进度的感知；二是优化用户在上传异常中断后的体验。
3.1 上传进度感知强化
用户在进入先发后传流程后，不清楚自己的视频是否正在上传或是否上传完成。因此，在这种没有感知的情况下将App退入后台、亦或直接杀掉，都会导致视频“上传失败率”和“未知结果率”变大。所以，针对这一点做了细节体验优化：
优化发布页跳转路径，发布后就进入视频管理列表，并提示视频正在上传；
优化视频管理列表上传中的稿件状态；
优化视频上传全局进度浮窗；
Android系统通知栏增加上传进度条。
3.2 上传中断体验优化
用户在遇到进度条长时间停留在某一个百分比上，不知道是视频问题、网络问题还是App问题，也没有收到任何通知或者提示，这些让用户感到困惑。因此，对异常也进行了几点的优化：
在上传过程中，如果检测到网络异常，发布页、视频管理列表、上传浮窗三处都标记为网络异常，且在网络恢复后，自动恢复上传；
App冷启后，自动重新上传异常中断的视频。
通过这些细节改进，我们让用户能够更清晰地感知到上传的状态变化，减少了用户的不确定感和焦虑感，提高了用户的信心和满意度。
4. 技术维度
除了产品层面的优化外，我们还需要从技术层面进行优化。通过数据分析，我们观察到了用户的上传失败率相对国内高出很多。
4.1 分析问题
我们分析可能导致失败率高、进度容易卡住的原因。通过对日志和代码的深入分析，我们发现有以下几个问题：
分片大小太大：视频云配置了10MB作为一个分片的大小，每个分片需要较长时间才能完成上传，在弱网情况下容易出现超时或者失败，失败后该分片就需要从零开始重新上传。所以，在分片没有重新上传到原来的进度情况下，进度会一直卡住；
iOS是单分片上传：旧iOS的分片上传方式是单线程串行上传，没有充分利用多线程的能力。理论上在带宽足够的情况下，多分片并发上传能很大程度上提升上传效率；
进度更新策略问题：安卓端的更新策略是每1秒查询一次上传数据量，每增加400k的数据量，再去更新一次进度。如果网速太慢或文件相对较小，就会导致上传进度不够平滑；
没有断点续传的能力：由于没有实现断点续传功能，当上传任务失败后无法恢复上次的进度，而是需要从零开始重新上传，既耗费带宽，也影响上传效率；
没有后台上传的能力：iOS没有后台继续上传的功能，进入后台很快就会停止上传。而Android没有在service里调用上传功能，进入后台后也相对较容易被后台回收。
4.2 确定优先级
根据2/8原则，将问题进行优先级排序：
解决分片问题：
解决功能优化问题：优化Android进度更新策略、优化iOS单分片的策略；
解决功能缺失问题：开发断点续传功能、开发后台上传功能。
4.3 解决问题
4.3.1 方案
分片调整
针对海外的网络状态，调整分片大小为5MB。
分片上传策略
针对iOS上传时， 单线程串行上传的策略，修改为多线程并发上传，通过preupload接口可配置下发并行线程数。安卓做了进一步的系统资源比对处理，与系统能力比对取MIN，最大程度使用当前手机性能。
进度更新策略
原安卓进度更新策略为每秒读取进度，进度大于400k时更新进度。
此问题在弱网环境下比较突出，安卓由于历史问题，调整更新进度量大小为200k。iOS做法为：每发出一包，放入进度池子，按照每秒读取当前进度池进度
断点续传
任务续传
往常海外业务对任务信息没有做本地化存储。对上传任务，稿件信息等都做了本地化存储方案。用户可能在推到后台、杀掉程序等操作下，任务仍可被自动唤起
分片续传
多分片上传过程中，某些分片可能存在失败的情况，此时此分片会进入自动重试，多次重试仍然失败的话，任务会被标记失败。此处有如下几方面内容
失败可回溯
下次重新发起此上传任务，可从原失败位置再次发起
多节点
旧逻辑中，分片上传过程中，只使用一个节点进行上传，如果此节点失败，可能一直失败。新方案中，使用了多个节点轮询策略
重试多个节点
分片重试过程中，轮翻尝试多个节点，任一节点成功都可继续上传
后台上传
通常程序在退到后台一定时间后，会在一段时间后被系统回收运行资源，此时程序的上传任务可能被暂停。针对此问题，安卓端坐进程做了service保活。任务开启后，如果用户退到后台，则把此任务加入后台运行队列。此能力大大降低用户在上传过程中，被系统终止的情况。
4.3.2 B端平台化
海外大加号工程是基于粉版迁移过来的，由于业务形态的一些差异，Swift重构上传页，但依然延用粉版的代码。我们使用上传组件下沉到国内大仓的基架层的方式。组件在抽象程度上支持上传任意格式的文件，同时在技术上解决了我们提出的问题和缺失的功能。
UpOS上传组件
UpOS是视频云开发的对象存储系统（如图4-1），支持多分片上传、断点续传、边传边转等特性。
图4-1 视频云视频上传链路流程
UpOS SDK上传组件基于视频云对象存储系统进行设计，目标是覆盖移动端所有需要上传文件到该存储系统的业务。2023年Q1已经实现了多业务接入新上传组件，解决了以前相关业务代码在业务层重复开发的问题。各业务接入UpOS SDK后，将所有开发都收拢降到sdk，降低维护成本的同时，还提升了业务开发效率。
UpOS SDK将上传拆分为四大步（如图4-2），分别为：preupload获取上传配置、根据配置获取cid、分片分割与分片上传、合并分片，其中最核心的部分是分片的分割与上传，整体架构（如图4-3），功能包含了：
多分片并发上传
断点续传
后台上传
重试策略
网络监控
进度平滑处理
技术埋点Tracker（不同业务需要依赖注入埋点action）
图4-2 UpOS SDK 视频上传流程
图4-3 UpOS SDK UML设计
接入上传组件
海外仓库与国内大仓是相互独立的（iOS国内和海外都各自维护着自己的bazel仓库），在基架上会有一些版本的差异，甚至是有少部分基架已经做过一些针对性的修改。所以在以平台化的方式将上传组件接入星辰的过程中，我们遇到了三大挑战：以什么形式引入B端组件才足够高效、如何抹平依赖的基架差异问题、如何解决组件依赖拔出萝卜带出泥的问题。
经过多方多次的讨论，B端工程组同学提出了适合目前现状的可行方案。Android端选择以Maven库的方式引入B端组件（如图4-4）。iOS端选择将国内大仓作为子仓的方式引入B端组件，如果部分组件有特殊性，那就在海外业务仓库里建立独立的子仓来维护B端组件。通过这样的方式，我们避免了源码接入组件的问题，同时将这些组件与海外业务进行隔离，方便后期维护。
图4-4 Android组件接入
在基架差异的问题上，一种是海外业务改了基架导致的差异，另外一种是版本差异带来的基架差异。目前暂时通过补齐API的方式来抹平基架的差异。
在解决基架差异的过程中，我们也发现有的依赖太过重，比如只用了一个依赖里的一个值，但是却要因此引入很多不必要的依赖。我们最终通过删除这些不必要的依赖，用依赖注入的方式，让业务方去实现对应需要依赖的功能。
5. 总结与展望
通过产品、技术两个维度的优化，我们取得了不错的效果：
业务测，发布页“投稿成功转化率”(发布页浏览uv ––> 成功投稿uv)老用户提升了6.23%，新用户提升了10.4%，整体提升在8%左右；转化率漏斗；
技术测，上传失败率也从之前的4%左右降到了1%左右；
数据测，我们建立起了长期可观测的视频上传指标，可立刻反馈出视频云抖动带来的问题；
通过这些努力，我们让创作者能够更快更顺畅地上传视频，并且减少了创作者放弃或者流失的可能性。
在这次的完整的专项，B端工程团队为我们总节省了35/人日，让我们看到了B端工程化更强的服务意识，能提供更好的技术和业务组件，让业务方能更快的接入组件，验证市场。同时，我们也看到基架差异会给B端组件平台化带来一些问题，目前的解决方案也不是最好的。海外业务技术团队也正在努力使基架与国内保持统一，相信未来会更容易对接上B端组件。
最后，感谢在这次专项中付出辛劳的B端工程团队、海外业务产品团队以及海外业务技术团队！
