Valdi：Snapchat 开源的 TypeScript 原生跨平台 UI 框架，不走 WebView 与 JS Bridge

跨平台框架的老矛盾是”开发速度 vs 运行性能”：WebView 路线（Cordova/早期混合应用）开发快但体验钝，React Native 用 Bridge 折中，Flutter 自绘引擎绕过原生。2025 年 11 月，Snapchat（Snap Inc.）把内部打磨了 8 年的 Valdi（GitHub Snapchat/Valdi，MIT 协议）开源，走出另一条路：用声明式 TypeScript 写界面，直接编译/映射到平台原生视图，没有 WebView，也没有 React Native 式的异步 JS Bridge。本文基于官方 README、FAQ 与内部文档做客观拆解。

一、背景：Snap 为什么要造自己的框架

官方 FAQ 讲得很直白：Snapchat 的 iOS 与 Android 版本设计基本一致，公司不愿接受”跨平台就必然掉性能、掉精致度”的trade-off。早期评估市面方案后，没有开源方案同时满足：接近原生的性能、双端一致性、随代码库增长启动延迟不膨胀、包体增量小、易于上手、可整页也可嵌入式小组件、类型安全的原生 API 生成。于是自研 Valdi，8 年来驱动 Snap 生产应用的大量界面，官方称 Snap 工程师用 Valdi 写了接近 200 万行 TypeScript；截至 2025 年末，一个 Snapchat 安装包内约有 600 个 .valdimodule 模块。开源仓库创建于 2025-11-06，调研时（2026-10-17）GitHub API 显示约 16,000+ stars。

二、它是什么

Valdi 是一个跨平台 UI 框架：开发者写 TSX 风格的声明式组件，运行时在 iOS（UIKit）、Android（ViewGroup/TextView 等）、macOS 上生成对应的原生视图。官方明确区分于两类方案：不靠 WebView 渲染 HTML，也不靠序列化消息桥（Bridge）批量同步视图树。定位上它不是”React 替代品”，FAQ 直言”我们并不声称 Valdi 严格优于 RN，只是选了另一组 trade-off”。

三、技术机制

三种模块打包形态（FAQ「How does it work」）：

1. JS Source：TS 经 TS 编译器编译后压缩为 JS 源码；
2. JS Bytecode（默认）：压缩后再 AOT 编译为字节码；
3. Native：TS 先编译到 C，再用 clang 编进原生二进制，此时模块内不含 JS。

运行时 JS 引擎支持 JavaScriptCore、QuickJS、Hermes，三种形态的模块之间完全互通（toll-free interop）。

渲染模型不同于 React：TSX 里的 <view>、<MyComponent> 等 XML 语句经专门编译器转成渲染器调用（jsx.beginElement(...)），与 React 创建虚拟 DOM 对象再 diff 不同，Valdi 的 XML 表达式 返回 void、直接 mutate 渲染器栈，渲染期对象分配更少，增量更新更可控。

全局视图回收池（官方 performance-view-recycling 文档）：视图销毁时先把所有属性 reset 回中性态，再按类名放入全局 ViewFactory 池；下次需要同类视图先查池，命中即复用。因为 Valdi 围绕组合设计、视图类种类少，池命中率高，Inflation（创建视图）延迟大幅下降。配合 limitToViewport（默认开），屏幕外条目不 Inflate，滚动进入视口才创建，长列表无需像原生那样手写 UICollectionView/RecyclerView 复用协议。

其他性能设计：C++ 布局引擎跑在主线程、marshalling 开销最小；组件独立重渲染不触发父级；Flexbox 布局并自动支持 RTL；Worker 线程跑后台 JS；原生动画与手势系统。

开发者体验：毫秒级即时热重载（iOS/Android/桌面均无需重编译）；VSCode 内断点、变量检查、性能剖析、堆转储；调试通过 CDP 协议经本地隧道转发到 Hermes 引擎。

渐进式接入：可把 Valdi 组件嵌进现有 UIKit/Android 视图树，也可在 Valdi 里用 <custom-view> 嵌原生视图；性能关键模块可用 C++/Swift/Kotlin/Objective-C 写 polyglot 模块并获得类型安全绑定；自动从 TS 接口生成 Kotlin/Objective-C/Swift 绑定，原生 protobuf 一等支持；Bazel 做可复现增量构建。

四、关键事实表

五、评测方法与口径说明

官方没有给出与 RN/Flutter 的第三方基准对比数字，README 的”native performance”是定性表述；FAQ 中”接近原生”也是 Snap 内部场景结论。所谓 beta 不是”没上过生产”，而是”开源生态的开发者体验还没打磨好”——这一口径需要和普通新项目的 beta 区分开。

六、适用与不适用

适合：已有原生 App、想渐进式复用一部分跨平台 UI/业务逻辑的团队；对启动延迟、包体、长列表滚动有硬性能要求；愿意接受小社区、自己补轮子的工程团队。

不适合：想直接复用 npm 庞大 React 生态的团队；需要 SwiftUI/现代 Apple 生态深度互操作；需要 Web 端生产渲染；追求大厂长期背书与海量社区组件库的项目。

七、优势与局限

优势：

1. 真原生视图 + 无 Bridge，热路径没有序列化往返，长列表靠全局池+视口渲染做到默认高性能；
2. 8 年大规模生产验证（Snap 几乎每个屏幕都用到），不是实验室玩具；
3. 渐进式嵌入双向兼容，不要求整站重写；
4. MIT 协议，无商业限制；三种打包形态可按模块权衡体积与速度。

局限/口径：

1. 不是 React，不兼容 RN 庞大的已发布库生态，API 形似但语义不同，迁移成本不低；
2. 社区与公司背书小：FAQ 自承”由比 Meta 小得多的公司支持、社区小得多、成熟度不如 RN”；
3. Web 目标未就绪：HTML/CSS 渲染器在开发中，官方明确”rough edges, not production-ready”；
4. 无 SwiftUI 互操作层，iOS 运行时用 Objective-C 编写，官方明确无计划重写 Swift 或加 SwiftUI 层；
5. 性能天花板低于纯原生：FAQ 承认相比平台原生，极限性能上限更低，部分平台特性访问不全；
6. 调试在部分场景更弱、有经验的工程师更难招；开源时间短（2025-11），外部文档、第三方组件与长期维护节奏仍待观察。

八、它意味着什么

Valdi 的价值不在于”又一个跨平台框架”，而在于展示了一条被大厂生产验证过的第三条路线：放弃 Web 标准包袱，以原生视图为终点、以 TS 为生产力语言，用视图池和栈式渲染把性能做满。对绝大多数中小团队，它的生态短板决定了它短期不会成为默认选择；但对已有原生存量、性能敏感、愿意自研补位的团队，它值得进入技术选型清单做内部 PoC。

参考来源

• Valdi GitHub 仓库（Snapchat/Valdi）
• Valdi 官方 FAQ
• View Recycling 性能文档
• Valdi Widgets 组件库
• Koala 项目库条目 #1474