Blits攻略：和同类怎么选
Blits攻略不能只讲怎么写代码，更要讲什么时候该用、什么时候别用。很多团队在电视端项目里纠结 Blits、React、Vue、原生和 Lightning，真正影响交付的不是语法偏好，而是性能、焦点、团队熟悉度和上线环境。
步骤一：先确定你的运行设备
做 Blits 攻略，第一步不是选框架，而是看设备。电视端和机顶盒的硬件差距很大，有的内存宽裕，有的页面一多就掉帧。普通浏览器页面在电脑上丝滑，不代表在低配盒子上也能跑。
如果你的目标设备偏弱，Blits 或 Lightning 体系会更有价值，因为它们面向大屏渲染做过设计。React、Vue 也能做，但你要自己处理更多性能细节，比如 DOM 数量、图片尺寸、动画开销。
步骤二：把 Blits 和 React/Vue 放一起看
React、Vue 的优势是人多、资料多、生态多。做登录、表单、后台、活动页，它们很舒服。但电视端最麻烦的不是表单，而是焦点移动、遥控器返回、长列表流畅度，这些通用框架没有天然替你解决。
Blits 的优势是更贴近大屏场景，组件写法也比直接写 Lightning 底层更友好。缺点也明显：中文资料少，团队招聘不如 React/Vue 好招，遇到冷门问题时更依赖英文文档和源码阅读。
步骤三：再和原生方案比较
原生 Android TV 或各厂商 SDK 的好处是系统能力强，播放器、遥控器、设备接口通常更直接。问题是开发成本高，跨平台差，UI 迭代没 Web 那么快。
如果你要做强播放器、深度系统集成、厂商定制功能，原生可能更稳。如果主要是内容展示、专题运营、会员页、推荐页，Blits 这类 Web 大屏方案往往迭代更轻。
步骤四：用项目类型做最后判断
内容型首页、影视详情页、EPG 菜单、酒店欢迎屏，这些页面结构规整，Blits 比较合适。因为它们大量使用卡片、列表、焦点、动效，正好踩在 Blits 的舒适区。
反过来，如果你的页面全是复杂图表、富文本编辑、密集表格，Blits 就不是好选择。别为了“看起来专业”硬上大屏框架，技术选型最怕把简单问题复杂化。
步骤五：给团队一个试点窗口
我建议别一拍脑袋全项目迁到 Blits。先拿一个真实页面试两三天：接一组接口数据、做一条横向列表、加返回键、做图片懒加载，再在目标设备上跑。
这个小试点会暴露很多真问题：构建是否顺、调试是否方便、帧率是否稳定、团队是否能读懂代码。比开十次选型会都有用。Blits攻略的核心就一句：用真实页面投票，别用 PPT 投票。
常见问题
Blits 和 Vue 哪个更适合电视端？
如果团队只会 Vue，且设备性能不错，Vue 可以做；如果项目重焦点、重长列表、重低端设备体验，Blits 更值得测试。
Blits 比 Lightning 简单吗？
通常是的。Blits 更偏应用层组件写法，Lightning 更底层。新项目一般先看 Blits，碰到底层性能再研究 Lightning。
Blits 适合商业项目吗？
适合，但前提是目标运行环境验证过。一定要拿真实设备测，不要只在开发机浏览器里判断。