DartNative 最近被拿来和 Flutter、React Native 放在同一张桌上讨论，容易把话题带成框架战争。对 CTO 和产品工程负责人来说，更有价值的问题不是谁在社交媒体上赢了，而是：如果一个移动团队今天把下一代客户端押在 DartNative 上，得到的原生体验收益，是否足以覆盖预览期、私有实现、订阅许可、包源和生态迁移带来的总成本。
它的技术主张很清楚：用 Dart 写应用，AOT 编译，界面不经过自绘渲染引擎，而是直接驱动 iOS 的 UIKit 和 Android 的 View 系统。官方文档强调没有 JavaScript runtime、没有异步 bridge、没有自定义 renderer；setState、diff、原生视图更新、Yoga 布局和帧提交都在平台主线程上完成。对重交互应用而言，这条路线确实击中了长期痛点：键盘跟随、文本输入、系统导航、列表滚动、系统控件细节和无障碍行为，不再需要把“接近原生”当成目标，而是直接使用原生平台本身。
先承认它解决了一个真问题
很多跨端方案的成本并不体现在第一版功能开发，而是在产品进入精细化阶段后慢慢出现：输入法跟随键盘差一帧，120Hz 设备上复杂页面偶发掉帧，系统导航手势和自定义路由之间需要补丁，文本选择、暗黑模式、动态字体、RTL 布局、相册、相机、通知、内购等能力要靠插件层不断追齐。DartNative 的吸引力在于，它不是在现有中间层上继续加速，而是把尽可能多的 UI 责任交还给平台。
官方 README 和架构文档列出的能力也并非空泛口号。它提供 Flutter 风格的 Column、Row、Text、TextField、ListView、Navigator、Scaffold 等 API；长列表可使用基于 UITableView、RecyclerView 的 FastList / FastGrid；图片加载走平台缓存和解码；系统导航、键盘、搜索栏、日期选择器等能力强调真实平台控件。对已经有 Dart/Flutter 人才的团队，这意味着学习曲线可能比原生双端重写低得多，同时又能获得更贴近平台的体验。
预览期意味着采用节奏要保守
官方 changelog 把 2026 年 7 月 31 日称为 first public preview，并说明 API 已经足够用于发版，但 1.0 前仍会快速变化。后续 9 月 8 日、9 月 12 日、9 月 15 日的更新集中修复 iOS 26 导航栏、搜索栏、日期选择器、RTL、TextField formatter、键盘、tab bar、系统外观、onSubmitted、Android input bar、DefaultTextStyle rebuild、SharedPreferences 长字符串等问题。这是积极信号：团队响应很快，问题来自真实用户反馈，也在真机上验证。
但这些修复同时说明，DartNative 仍处在工程成熟度建立阶段。一个成熟移动栈的风险，不只是“能不能跑 demo”，而是版本升级后是否会改变边界行为、调试路径是否稳定、团队能否在发布窗口内绕过阻断问题、生产 bug 是否能被自己定位而不是等待供应商修复。因此，采用决策不应从旗舰 App 全量重写开始，而应从一条高价值、低耦合、可回滚的业务线开始：例如新产品的 MVP、现有 App 中体验要求很高但平台依赖有限的新模块、内部工具，或用户量可控的独立客户端。
私有实现和订阅许可是核心治理成本
DartNative 的公开仓库说明得很直接：公开部分包含文档、playground、二十多个教程、插件示例和 issue tracker；框架本身在私有仓库中开发，公开仓库看到的是 release，而不是日常开发。LICENSE 也明确写着 DartNative framework、源代码、二进制和工具属于 Presence Network Inc.；有效 license token 给予有限、非独占、不可转让、不可再授权的使用权；订阅有效期间可通过 DartNative 私有包注册表访问软件；订阅过期后已经分发给终端用户的应用可以继续运行，但过期会终止继续构建和部署的权利。
这和采用 MIT/BSD/Apache 许可的开源框架是完全不同的风险模型。团队不能把 DartNative 当作“换一个 pub 包”处理，而要把它放进供应商治理流程：预算审批、采购条款、账号和 license key 管理、离职交接、CI 密钥轮换、包源可用性、法务审查、停服和争议处理。它的 license 包含 sunset commitment：如果软件停更达到约定条件，供应商需在停用后 90 天内以 BSD 3-Clause 发布当时源代码和第一方插件。这降低了极端风险，但它不是等同于今天即可 fork 的开源权利；触发条件、执行能力、第三方组件、商标、license enforcement 基础设施也都有边界。
包注册表和工具链会进入你的发布路径
自有项目需要在 dartpub.dev 订阅、取得 dnk_ 开头的 license key，并使用 dn config 或 dart-define 激活。DartNative 依赖通过 dartpub.dev 获取，dn pub get 还会生成 dn_plugins.lock，官方建议和 pubspec.lock 一起提交。dn CLI 包装 Flutter 工具链，首次运行会下载预构建 engine 到本地缓存；iOS 构建要求 macOS 和 Xcode 26.3 或更新版本，Android 要 Android SDK 36，dn doctor 会检查缺失项。
这些要求本身并不离谱，但会影响组织级成本。CI 镜像要预装或缓存 dn、Zero、Android SDK 36、Xcode 版本；开发机要处理 Flutter 与 DartNative 并存时 PATH 和 IDE SDK 路径的问题；VS Code 默认 dart pub get 可能无法解析 DartNative 包，需要项目级设置关闭自动 pub get。对小团队来说，这些是一天内能解决的工程琐事；对有合规镜像、离线构建、固定 Xcode 窗口和多分支发布线的大团队来说，它们都是发布系统变更。
生态差距不能只看第一方插件数量
官方称有 34 个第一方插件，并覆盖 storage、camera、video、audio、webview、maps、notifications、purchases、on-device AI 等方向。第一方插件免费，且以平台 API 为后端，这是好事。问题在于移动生态的长尾很长：埋点、A/B 实验、崩溃监控、广告、风控、IM、地图地区差异、支付渠道、企业 MDM、可观测性、无障碍测试、自动化 UI 测试、厂商推送、深链、App Clips / widgets / extensions、国内应用商店 SDK，都可能决定项目能否落地。
DartNative 支持插件开发，普通 FFI 插件和带原生视图的插件都有架构说明；但“可开发”不等于“生态已存在”。采用前应该列一张插件矩阵：现有 Flutter / React Native / 原生依赖逐项归类为已经有第一方替代、可用 FFI 快速实现、必须写双端原生封装、短期无法迁移四类。只要关键业务链路里存在两三个重型私有 SDK，就要把插件开发、测试、版本维护和供应商 SDK 升级全部计入总成本。
性能承诺要自己测，而不是引用口号
DartNative 的结构性优势有可信逻辑：真实原生视图、主线程同步调用、Dart AOT、无 JS runtime、无 bridge、长列表复用、平台图片解码，这些都可能改善高交互界面。官方也给出新 iPhone release 包体示例：DartNative 新应用压缩包约 4.4 MB，Flutter 新应用约 5.7 MB；同时说明加入 dartnative_skia 后 iOS 会增加约 9 MB，Android 平台绑定中本来就带有相关库，是否省体积要按平台看。
但 CTO 不应把供应商的性能叙述直接转化为商业承诺。正确做法是选三类代表屏幕做基准：聊天/输入法跟随、长图文列表、系统导航和媒体页。用真机、release/profile 构建、固定数据集、相同网络缓存策略、相同埋点关闭状态，测首帧、交互延迟、滚动帧率、键盘动画、内存峰值、包体、冷启动、热启动和崩溃率。React Native 或 Flutter 已经投入多年优化的项目，不一定会被新框架在所有维度碾压；DartNative 应该在你最痛的体验维度上胜出，而不是在宣传对比表里胜出。
迁移和退出计划要在采用前写好
如果从 Flutter 迁移，DartNative 的 Flutter-compatible API 是优势，但并不意味着无成本。参数差异、渲染模型差异、平台视图行为差异、插件替代、CustomPaint / Skia 取舍、测试用例、CI、发布签名、崩溃符号和监控都要重新验证。官方 getting started 甚至建议借助 LLM 做转换，这说明迁移路径偏自动化友好，但也说明迁移后的验收不能只看编译通过。
退出计划同样要具体。第一，业务层、状态管理、领域模型、网络、缓存、埋点协议尽量保持框架无关，避免把 DartNative widget 和平台插件调用侵入核心业务。第二，保留关键原生 SDK 的薄封装边界，插件层必须有接口测试。第三，重大版本升级前固定可回滚的 dn、插件、Xcode、Android SDK、CI 镜像组合。第四，合同和预算层面明确订阅中断、license key 泄漏、私有 registry 不可用、框架停更、供应商被收购后的处理流程。第五，至少保留一条“重回 Flutter / 原生双端”的粗略估算：哪些代码可复用，哪些必须重写，用户数据和发布节奏如何不中断。
适合采用的团队画像
DartNative 更适合三类团队：第一，产品体验足以影响商业转化，例如社交、创作、消息、消费级 AI、工具型订阅 App，对键盘、列表、手势、导航、输入细节有高要求；第二，团队已经熟悉 Dart/Flutter，但对 Flutter 自绘层在特定场景的体验成本不满意；第三，组织能接受商业框架和私有实现，并有能力做供应商治理、真机基准测试和插件补齐。
不适合的场景也很明确：预算极敏感、必须完全开源可审计、强依赖大量现成社区插件、需要 Web/桌面多端同构、发布系统无法升级到要求的 Xcode/Android SDK、或者团队没有余力承担预览期变化。对这些团队，成熟的 Flutter、React Native 或原生双端可能仍是更稳妥的选择。
一个务实的采用路线
决策可以分四步。第一步，两周技术 spike：跑 playground，复刻一个真实核心页面，接入一到两个关键插件，测真机数据。第二步，一个月试点：开发一个可上线但可回滚的小模块，打通 CI、签名、监控、崩溃、包源和 license 管理。第三步，治理评审：法务、财务、平台工程、移动负责人一起确认订阅、registry、sunset、密钥、离线构建和退出路径。第四步，才是路线图选择：继续只用在体验敏感模块，还是作为新 App 的默认客户端技术。
DartNative 的价值不在于替代所有跨端方案，而在于把“Dart 开发效率”和“真实原生 UI”放在同一个设计里。它值得被严肃评估，也必须被谨慎采购。最稳健的结论是：把它当作高端原生体验的候选技术，而不是社交媒体上的胜负标签；用真实业务屏幕、真实发布链路和真实退出成本来决定是否采用。