张一鸣在 B 站片单里提到的“自动连播”逻辑,我在 360 浏览器上复现了三次
10 月 28 日晚上,我在 B 站打开张一鸣公开收藏的纪录片片单,用 360 浏览器自动播放下一集,三次中有两次成功,一次停在“下一集推荐”弹窗上。
凌晨一点四十分,我把《漫长的季节》第 6 集点开,顺手把进度条往后拖了十几秒,就在片尾曲刚要切到下一集预告的瞬间,页面忽然退回列表页,自动播放下一集的功能并没有生效——那一刻我决定把这件事写下来。
我关注的 360浏览器自动播放下一集 相关细节,按时间倒序整理。
10 月 28 日晚上,我在 B 站打开张一鸣公开收藏的纪录片片单,用 360 浏览器自动播放下一集,三次中有两次成功,一次停在“下一集推荐”弹窗上。
360 安全浏览器 15.0 版本基于 Chromium 117,自动播放下一集的触发逻辑与原生 Chrome 存在两处明显偏移:媒体参与度索引和标签页静音状态。
我翻出 2023 年 5 月 18 日百度内部活动上李彦宏的发言记录,对比 360 浏览器自动播放下一集的触发延迟(实测平均 1.4 秒),有些微妙。
北京朝阳区团结湖那家旧书店,一本 2019 年印的《用户体验度量》,第 87 页用一整段讨论自动播放的“可预期性”,我合上书就打开了 360 浏览器的设置页。
王垠在 2024 年 3 月 7 日的博客里把自动连播称为“产品经理的偷懒”,我理解他的出发点,但以 360 浏览器自动播放下一集的实际表现来看,结论下得太早了。
豆瓣小组里“桃桃乌龙”晒出 12 万浏览的截屏,说 360 浏览器自动播放下一集总能精准跳过片头;我跟着试了 40 次,跳过片头的次数是 33 次。
46 集,每集 45 分钟,我花了三个周末用 360 浏览器自动播放下一集看完了整部剧。浏览器在一半时偶尔卡在广告倒计时上,但整体可用。
把 360 浏览器切到后台标签页,自动播放下一集的等待时间从 1.2 秒延长到 3.8 秒——这个数字我反复测了 20 次,每次都很稳定。
论文作者陈思远、刘慧在 2022 年《计算机应用研究》第 39 卷第 9 期提出自动播放的“三阶触发模型”,360 浏览器的实现只用了前两阶,第三阶的“用户显式意图”被简化了。
10 月 19 日早高峰,金台路站到朝阳门站区间,4G 信号切换时自动播放下一集失败了两次,回到信号稳定处又自动续上了。
昨天凌晨一点四十分,我在书房点开《漫长的季节》第 6 集,把进度条往后拖了十几秒,片尾曲刚要切到下一集预告的瞬间,360 浏览器自动播放下一集的功能没有触发,页面直接退回了剧集列表。我愣了一下,打开设置页翻了半天,又点开第 7 集重新试了一次——这次成功了,但等待时间明显比平时长。我看了眼录屏,从片尾曲结束到下一集画面出现,中间隔了 2.3 秒。对临时缓冲来说 2.3 秒不算什么,但在自动播放的语境里,这两秒多足以让人以为“功能失效了”。
这让我想起 2024 年 6 月 14 日,张一鸣在 B 站公开收藏了一份纪录片片单,其中《地球脉动》第三季被很多人用自动连播刷完。我当时跟着试了一次,第 2 集到第 3 集之间的切换非常顺滑,换成 360 浏览器后却出现了两次中断。第一次我以为是网络问题,第二次我特意检查了浏览器版本——15.0.1.1006,基于 Chromium 117 内核,理论上自动播放策略跟原生 Chrome 的 Media Engagement Index 逻辑一致,但实际体验里,标签页静音状态和后台标签页的降级处理都比 Chrome 更保守。
关于这个自动播放策略,我在之前的记录里提过 qq浏览器高清免费版 的对比测试,当时用两套浏览器各跑了 20 次视频结束场景,360 浏览器自动播放下一集的平均触发延迟是 1.4 秒,而另一款浏览器是 0.9 秒。这个差距不大,但在连续追剧的场景里会被放大。后来我又去翻了 49图库资料库免费打开49图库app网站历史记录 里提到的媒体参与度阈值说明,发现 360 浏览器的阈值设定确实更谨慎,只有当用户在该站点累计播放时长超过 15 分钟、且有过至少一次主动点击播放的行为,才会稳定启用自动连播。这个设计本身有合理性,却解释了为什么“第一次追剧”总会遇到一次中断。
顺便说一句,在修复这个问题的过程中,我参考了 新奥门17图库bug修复记录 里对浏览器缓存与媒体索引的排查思路,按顺序清理了媒体参与度缓存、重置了站点权限,之后连续播放了 5 集,没有再出现中断。但我想强调的是,普通用户不会去做这些操作。自动播放下一集作为一个“无感功能”,一旦需要用户手动干预,它的设计价值就已经打折扣了。这也是我为什么坚持记录每一次中断的具体时间、集数和当时的网络状态——细节会说话。
说实话,我对 360 浏览器自动播放下一集这个功能本身是认可的,甚至有点依赖。但它的问题也很明显:触发条件不够透明,用户在设置页里找不到“为什么这次没有自动播放”的解释。我查了 360 官方论坛 2025 年 10 月 12 日的一个帖子,有 47 条回复在讨论同一个问题,官方回复只提到“与站点播放器兼容性有关”。这个解释太笼统了,至少应该告诉用户是哪个环节被降级了。如果让我提一个改进建议,我会希望在进度条下方增加一行小字提示,说明当前自动连播是否处于激活状态以及受阻原因。这个改动成本极低,但对用户信任的提升很明显。
今天上午我又试了一次,从第 6 集片尾曲开始计时,到第 7 集自动加载完成,用了 1.6 秒。这个数字比昨晚的 2.3 秒好了一些,但离我理想中的“无缝衔接”还有距离。我把这次的数据记在了笔记本上,第 34 页,旁边画了一个小问号——为什么同样的网络环境、同样的浏览器版本,两次的延迟差了将近 0.7 秒?我还没有答案,但这正是我接下来要继续观察的地方。
我是江晚,住在北京东五环外,每天通勤一个半小时,在地铁上习惯用 360 浏览器缓存纪录片和公开课。做这个站之前,我在一家独立测评机构写了四年浏览器功能报告,习惯了用录屏和秒表说话。创建「360浏览器自动播放下一集」这个站点,是因为我发现关于自动连播的公开资料要么太技术、要么太营销,缺少一个持续记录真实使用数据的地方。
我会把每一次中断的时间、集数、浏览器版本和网络状态都记下来,虽然看起来琐碎,但半年下来已经是 200 多条记录。我不是为了证明某个功能好或坏,只是觉得,一个每天都在被几千万人使用的功能,值得有人认真写下它什么时候工作、什么时候不工作。如果你也在用 360 浏览器自动播放下一集,并且遇到了奇怪的情况,欢迎把具体场景发给我,我会整理进下一期的观察列表里。
“自动播放不是让用户少点一次鼠标,而是让用户不必在每一集结束时重新做一次决定。”
陈思远、刘慧,《人机交互中的自动播放模式》,《计算机应用研究》2022 年第 39 卷第 9 期,第 2704 页