体育移动端：用户等比分的那几秒，决定留存

比分页：一屏说清楚

用户打开比分页只想知道三件事：现在几比几、比赛到第几分钟、有没有进球集锦。这三个信息必须在首屏一屏内完成，不需要任何滑动。测试方法也简单：把手机递给一个不看球的人，五秒内说不清比分，这版设计就重来。实测下来，首屏信息完备的比分页，用户停留时长比需要滑动的版本高四成。设计原则：比分用最大字号、比赛时间实时跳动、最近事件卡片放比分正下方。

赛程页：信息密度是门手艺

赛程页的天生矛盾：一天几十场比赛，全塞进去密不透风，精简了又找不到想看的。三个做法：

• 按联赛分组折叠，默认展开用户常看的联赛（这个偏好从行为数据学）。
• 进行中的比赛置顶并高亮，结束的收进「已完赛」。
• 日期切换用横向滑动，别用下拉——单手操作够不着。
• 时区跟随用户所在地显示开赛时间，别只给赛事当地时间的数字。

推送：分寸感大于频次

开赛提醒、比分剧变、终场结果，三类推送的打开率完全不同。开赛提醒打开率最高，比分推送要克制——只在进球、红牌这类剧变时推，普通进球不推的做法反而留存更好。一天超过 5 条推送，卸载率开始明显爬升。推送文案短句直给：「上半场 1-0，蓝队控球六成」好过「快来看最新战况」这种空话。

性能红线

移动端的三条硬指标：首屏 2 秒内可见（3G 模拟环境下）、比分推送到达后 200 毫秒内上屏、App 冷启动 4 秒内进首页。达不到的常见原因不是代码慢，是首屏塞太多——统计模块、推荐位、活动位全挤在首屏，比分反而被挤到第二屏。砍法很简单：首屏只留比分和进行中赛事，其他全部懒加载。

流量与体积

体育用户大量在移动网络下使用，流量敏感是真实的。做法：图片全走 WebP 并按屏幕尺寸裁剪；统计图表默认加载最近一场，历史数据点开再取；比分推送每条控制在 1KB 以内。给个参照：重度用户一天跟十几场比赛，页面做得糙一天能吃掉上百 MB 流量，卸载理由里「费流量」常年排前三。实时数据的推送策略，接的是赛事直播与实时数据方案的链路；数据本身的覆盖与延迟，取决于数据源的选型。