Blits对比：一次项目复盘
Blits对比最有价值的方式，不是列参数表，而是看真实页面怎么从旧方案迁到新方案。下面用一个影视首页改版案例，复盘从评估、试做、踩坑到上线的过程。问题都很具体：焦点怎么走、列表怎么渲染、团队怎么接手。
Q1：这个案例原来是什么情况？
项目是一个电视端影视首页，结构很典型：顶部导航、焦点大图、几排横向海报列表、底部推荐位。旧方案用普通 Web 技术做，电脑上看很顺，放到低配盒子上，连续按遥控器右键会明显卡顿。
当时团队没有立刻全量换框架，而是做 Blits对比试验：拿首页第二屏的“热门电影”列表做样板，同样数据、同样海报数量、同样遥控器操作路径，比较旧实现和 Blits 版本的开发体验与设备表现。
Q2：为什么没有直接用 React 重写？
React 的生态更熟，这是事实。但这个页面的痛点不是组件不够，而是焦点路径、长列表移动和低端设备渲染。用 React 重写，团队仍要自己补一套电视端焦点系统，还要控制 DOM 和动画成本。
Blits 的吸引力在于它本来就面向大屏应用。对这个案例来说，少写一套焦点基础设施，比多找几个现成组件更重要。选型不是选最流行的，而是选最贴近主要矛盾的。
Q3：试做过程中遇到的最大差异是什么？
最大的差异是开发思维。旧页面习惯按视觉分块：这里一个 div，那里一组样式。Blits 版本更适合按“可被遥控器操作的单元”拆组件，比如 Card、Rail、Hero、MenuItem。
这个调整一开始会慢一点，但后面好维护。比如海报卡片获得焦点时放大、显示标题、按确认进详情，这些行为只要在 Card 层处理，所有列表都能复用，不用每个区域写一遍。
Q4：Blits 对比旧方案，哪些地方赢了？
第一是焦点可控。默认焦点、左右边界、返回路径更容易统一。第二是页面结构更贴近电视端，组件职责清晰。第三是性能优化方向更明确，团队会自然关注可见区域、图片加载和动画成本。
但 Blits 不是全胜。新人上手资料少，遇到边缘问题时，搜索中文答案经常不够。还有一些通用 Web 生态里的现成库，不能假设拿来就能用，要看它是否适合大屏运行环境。
Q5：最后这个项目怎么落地？
团队没有一次性重写全站，而是先把首页内容区迁过去，保留旧的播放链路和账号链路。这样风险小：如果 Blits 部分表现不稳定，可以快速回退，不影响核心播放。
上线前做了三类测试：连续方向键快速移动、弱网图片加载、返回键路径。这个案例给我的结论很直接：Blits对比旧 Web 方案，在电视端内容浏览页上优势明显；但迁移要分区做，别拿全站当试验田。
常见问题
Blits 和旧 Web 方案可以混用吗？
视项目架构而定。实践里更稳的方式是按页面或模块逐步迁移，先从内容展示区试点。
Blits 对比 React 最大优势是什么？
在电视端，最大优势通常是焦点和大屏交互模型更贴合，而不是语法本身更先进。
Blits 迁移项目要多久？
不能按框架估，要按页面复杂度估。一个标准内容列表页，熟悉后几天能做出样板；全站迁移要看播放、账号、支付等链路。