Blits避坑：底层逻辑讲透
Blits避坑的关键，是先理解它为什么和普通网页开发不一样。你写的不是给鼠标点的页面，而是给遥控器、低功耗芯片和远距离观看设计的界面。坑通常不在语法，而在焦点、渲染、图片、状态和设备差异。
焦点逻辑：能看见不等于能操作
普通 Web 页面里，按钮摆上去就能点；Blits 大屏页面里，焦点路径才是用户真正的“手”。最常见的坑是视觉上有按钮，但方向键永远走不到，或者弹窗打开后焦点还停在背景列表上。
正确做法是把焦点当成页面结构的一部分，而不是后补功能。每个区域都要有默认焦点、边界规则和返回规则。尤其是横向列表套纵向列表时，要避免用户按几下方向键后迷路。
渲染性能：少画比会优化更重要
Blits 适合大屏，不代表你可以无限堆节点、堆图片、堆动画。电视设备经常比你的笔记本弱得多，开发机上 60fps，不代表盒子上不掉帧。
这里要对比两种思路：一种是页面全量渲染，先把所有卡片都画出来；另一种是只渲染当前可见区域，滚动时再补。真实项目里，后者更稳。长列表、海报墙、频道页都别偷懒。
图片资源：清晰和流畅要取平衡
大屏项目特别容易掉进高清图陷阱。设计稿看着爽，接口直接给 4K 海报，页面一加载内存飙升，低端设备先卡给你看。Blits 本身救不了超大图片带来的压力。
建议按展示尺寸准备图片：小卡片用小图，大焦点位再换高清图。还有一个实用办法是做占位图，焦点移动时不要立刻触发一堆大图请求，给 100 到 200 毫秒的缓冲，用户快速扫列表时体验更稳。
状态管理：页面切走后别留下脏状态
Blits避坑里，状态问题很隐蔽。比如详情页返回首页后，焦点要不要回到刚才那张卡？弹窗关闭后，列表滚动位置要不要保留？接口刷新后，当前选中项还在不在？
这里有两种处理：临时状态放组件内部，全局状态放统一管理处。别把所有东西都塞全局，也别让跨页面状态散落在多个组件里。后期排查“返回后焦点乱跳”时，你会感谢现在的克制。
设备差异：浏览器通过不算通过
最后一个坑最现实：你在 Chrome 里跑通，不代表在电视系统里跑通。遥控器键值、返回键行为、字体渲染、视频层级、内存限制，都可能和桌面环境不同。
我的习惯是每完成一个核心页面，就上目标设备测一次，而不是等功能全完。尤其是首页、播放入口、登录、支付这几条主链路，越早测越省钱。Blits避坑，本质是把问题提前暴露。
常见问题
Blits 最容易踩的坑是什么？
焦点和性能。新手常把页面画完才想焦点，或者在低端设备上才发现图片和列表太重。
Blits 页面卡顿怎么排查？
先看图片尺寸和渲染数量，再看动画是否过多，最后查状态更新是否导致大范围重绘。不要一上来怪框架。
Blits 需要做兼容测试吗？
必须做。电视、盒子、浏览器内核差异明显，至少要覆盖项目实际投放的主力设备。