I2.04.2prefetch costs bandwidth and battery设计
预取消耗流量与电量
别名: 预取代价 · 流量电量 · prefetch cost
概念解释
预取把下一跳的传输提前，账单也提前：流量和电量会在人还没要这份内容时就被花掉。感知速度不是免费的。蜂窝网络、漫游、低电量、按量计费的用户，为一次可能发生的点击预付的成本是真金白银和一截电池。这条把交换的负项摊开：可预测性再高，代价仍按「取了多少、用了哪条网、设备在什么状态」结算，不按「感觉快了多少」结算。
机制
无线网卡从空闲拉到工作、屏幕已经亮着再加一轮无线电、蜂窝链路保活，都有固定的能量台阶。预取常常发生在人以为自己在「静止阅读」的时候，台阶被悄悄跨过去。流量按字节计，预取的字节和点击后取的字节在账本上同价，区别只是预取有概率用不上。命中率 50% 的预取，相当于每两次下一跳收三次传输的钱。电量还叠了「现在取还是等接上 Wi-Fi 再取」的时机：当前是昂贵网络，预取把将来或许能在廉价网络完成的传输锁死在昂贵区间。
代价还会和当前页争。预取把管道填满时，正在播的视频、正在滚的列表自己会卡，用户感到的不是下一跳变快，是这一跳变慢。账单在后台，卡顿在前台，人很难把两者连成「因为你们在猜我会点什么」。
边界
不计流量的局域网、设备在充电、用户明确点了「预载离线」时，代价被接受甚至被要求，这条的警告要让路。很小的预取（一条标题 JSON）和一部预取的高清视频不在一个量级，不能用同一套禁令。系统自己提供的省流量模式、低电量模式，是用户已经投下的否决票，预取应停或降到仅元数据。预加载当前页马上要画的关键字体、关键脚本，是在付当前等待的账，不是在付可能发生的下一跳，不应和投机预取混成一项「能省则省」。
怎么落地
- 按网络类型和电量设闸：蜂窝、漫游、低电量默认不预取媒体，最多预取轻量元数据；Wi-Fi 且电量充足才放开。
- 给预取预算：同一会话里未命中的字节有上限，超过就停，不要无限赌。
- 尊重系统的省流量 / 低电量声明，把它们当成硬关闭，而不是再弹一次确认。
- 验证：在蜂窝和低电量下走完一条「看起来很聪明」的预取路径，看流量统计和耗电。若下一跳并没有发生，而这些字节和无线电时间已经花了，就要把闸收紧到这条路径默认关闭。