打开抖音，移动从点击图标到视频开始播放，视频中间只有1.2秒。移动这1.2秒里，视频App要完成网络请求、移动视频解码、视频渲染上屏，移动还要预加载下一条。视频用户觉得理所当然，移动开发者知道这背后全是视频坑。

移动视频App和普通App最大的移动区别在于：它对实时性、流畅度的视频要求近乎苛刻。一个电商App卡顿300毫秒，移动用户可能没感觉；视频App卡顿300毫秒，视频用户直接划走。移动留存率就是这么一点一点丢掉的。

播放器选型：别急着造轮子

很多人一上来就想自己写解码逻辑，觉得用开源库不够“技术”。实际情况是，FFmpeg加ExoPlayer（Android）或AVPlayer（iOS）的组合已经能覆盖90%的场景。真正需要自研的是极端的定制需求，比如短视频的秒开优化、直播的低延迟对抗。

我见过一个团队花了四个月自研播放器内核，结果稳定性还不如ExoPlayer。后来全部回退，把精力放在预加载策略和CDN调优上，首帧时间反而降了40%。教训很直接：把力气花在业务层的体验优化上，比底层重复造轮子划算得多。

预加载策略决定生死

用户滑到第三条视频时才去请求数据，一定来不及。正确的做法是在播放第一条时，就已经把第二条甚至第三条的视频头信息拉下来了。这里的关键不是“多缓存”，而是“缓存多少”。

缓存太多，内存爆炸，低端机直接闪退；缓存太少，滑动时白屏。我们实测下来，短视频场景下预加载2条、每条只取前1MB数据，是个比较稳的平衡点。长视频则不同，需要根据用户观看进度动态调整，看到80%时预加载下一集的前30秒。

还有一个细节：Wi-Fi和4G下的策略必须分开。4G环境用户对流量敏感，预加载要更保守；Wi-Fi下可以放开手脚。这个判断逻辑写起来不复杂，但很多App忽略了。

首帧时间：每100毫秒都是钱

首帧时间（从点击到第一帧画面出现）是视频App最核心的指标。行业平均水平在800毫秒左右，做得好的能压到400毫秒以内。怎么压？

一是提前初始化播放器实例。别等用户点了才创建，在页面渲染时就初始化好，放在对象池里等着。二是视频头信息分离。把moov box放在文件最前面，播放器不用下载完整个文件就能开始解码。三是CDN边缘节点要足够密，物理距离每增加500公里，延迟至少多30毫秒。

有个做社交视频的团队，把首帧从900毫秒优化到500毫秒后，次日留存涨了7个百分点。这个数字很吓人，但逻辑很简单：用户等得越久，越容易失去耐心。

弱网对抗：不是加个进度条就完事

地铁里刷视频，进隧道就断。用户不会怪网络，只会怪App。弱网对抗的核心思路是“降级”而非“等待”。

具体做法：检测到网络抖动时，主动降低码率而不是卡住缓冲。720p降到480p，用户可能察觉不到画质变化，但能感知到卡顿。同时，音频优先于视频——画面可以糊，声音不能断。这个优先级排序在直播场景里尤其重要。

另外，别迷信“智能码率切换”。很多方案切换时会有明显跳变，用户一眼就能看出来。平滑过渡需要缓冲区的精细控制，这块值得花时间调。

写在后边

移动视频App开发没有银弹。每个决策都是取舍：预加载多占内存，码率低影响画质，CDN便宜但节点少。关键是搞清楚你的用户在哪、用什么设备、在什么网络下看视频。脱离场景谈技术方案，全是空话。

最后说一句：别在办公室里测弱网。拿着手机去地铁、电梯、地下车库走一圈，比看一百份测试报告都管用。