urbanescavenger/BiliMT v3.1.1-alpha.4

on GitHub

「WEB-SABR 优先」档不再一开就崩 —— 把 harvest 采集 WebView 的预热从启动高峰挪到「启动稳定 + 用户空闲」的后台窗口(P11-254)。本版接在 v3.1.1-alpha.3 之后,那一版修的是动态页返回丢焦的判据。

变更

• 崩溃不是崩在代码里,是崩在时机上(P11-254):切到「WEB-SABR 优先」档后应用连崩三次
  (真机 logs_live_20261012_232242.log:40 秒内换三个进程,每个都活不过 715 秒)。日志里没有
  Java 崩溃栈、也没有 native 信号,只有 Wrote stack traces to tombstoned(系统在写 ANR 现场)与
  Choreographer: Skipped 246~287 frames(每次冻 45 秒)。
  旧机制:预热是「进程启动后延迟 8 秒」——而这块盒子启动后 10~15 秒正是自家首页 / 动态 /
  YouTube 三路首屏最挤、画面本来就在连跳 200 多帧的时候;预热里的 WebView 冷启(实测 7029ms)
  还只能跑在主线程,两下一叠就超过系统的输入分发超时 ⇒ 用户一按遥控器就 ANR ⇒ 应用被关掉 ⇒
  重启又撞。反证很干净:三个短命进程都死在「8 秒延迟 + 7 秒冷启」这个窗口里,而唯一把预热
  跑完的那个进程活了下来。
• 新机制:预热改成等两个条件都满足才开跑 ——
  ① 启动已稳定:窗口真的上屏之后,再等 20 秒(首屏那波请求落地);
  ② 用户此刻没在动:最近 3 秒没有按键、且没有视频在播(播放器是主线程第一优先消费者)。
  不满足就每 2 秒看一眼,最多让 2 分钟然后照做 —— 绝不跳过(跳过等于让 WEB-SABR 档的首次起播
  自己付 10.9 秒冷启,那正是当初做出这个预热的理由)。档位闸不变:仍只在「WEB-SABR 优先」档做,
  SABR / DASH 档不白起 WebView、不拉那 1.4MB 首页。

同版附带

• 本版代码里同时包含 P11-255(顶档升档判据与其他档统一,撤掉顶档专属的 sustained ≥ need×1.1)
  —— 那是另一路实施的内容,其真机验证见它自己的文档条目,本节不做结论。

待验证(真机)

• 切到「WEB-SABR 优先」档后重启:启动 20 秒内不应再出现 prewarm: 采集 WebView 冷启完成,
  也不应再出现「冻 4 秒以上 + Wrote stack traces to tombstoned」的连崩。
• 预热真正开跑前应能看到 youtube harvest prewarm start: 启动已稳定,等空闲 <N>ms。
• WEB-SABR 首次起播仍不应自己付冷启(harvest 只剩导航 watch 页那 1~2 秒)。
• 逃生(老版本自救):设置 → 播放设置 → YouTube 交付优先级 切回 SABR / DASH 优先。