跨平台

Flutter 是 Google 推出的跨平台 UI 工具包，用 Dart 写一份代码即可编译到 iOS、Android、Web、macOS、Windows、Linux、嵌入式设备。它与 KMP/RN 的最大区别是"不映射到原生控件，也不跑在 WebView 里"——Flutter 自带一套 Impeller 渲染引擎，直接向 GPU（Metal / Vulkan）提交绘制命令，从按钮到滚动条的每一个像素都是自己画出来的。 这种"自绘"架构让 Flutter 拥有"双端像素级一致“的超能力，也带来了”iOS 原生设计语言永远慢半拍“的原罪。在 AI Coding 时代，Flutter 的统一性和 GenUI 生态让它成为 LLM 生成 UI 的理想容器，但端侧 AI、Liquid Glass 等 Apple 独占能力的缺失也让它在 iOS 26 时代面临新的挑战。 本文从架构出发，穿透到 Dart VM 编译链、Impeller 渲染管线、iOS 嵌入原理，再到 AI 时代的机遇与陷阱，是一篇写给 iOS 开发者的 Flutter 体系化导读。 一、Flutter 是什么 1.1 一句话定义 Flutter 是一套”声明式 UI + 自绘渲染 + AOT 原生代码“的跨平台框架： 声明式 UI：UI 是 build(context) => Widget 的纯函数结果，状态变 → 重新 build → diff → 更新。 自绘渲染：所有控件都是 Flutter 自己用 Impeller 绘制出来的，不使用 UIKit / SwiftUI 组件。 AOT 编译：发布时 Dart 代码被 gen_snapshot 编译为 ARM64 机器码，与 C++ 引擎一起链接到 Flutter.framework 内。 一句话记忆：Flutter 不是跑在 iOS 上，它是借 iOS 的一块 CAMetalLayer 画自己的东西。 ...

KMP（Kotlin Multiplatform）是 JetBrains 推出的跨平台代码共享方案。它与 Flutter、React Native 的"一套代码一套 UI"思路不同，走的是"业务逻辑共享，UI 原生“的路线：Kotlin 写的网络、数据库、ViewModel、业务规则等代码编译成 iOS/Android/HarmonyOS/Web 可直接使用的二进制产物，而 UI 仍然由各平台原生框架（SwiftUI/UIKit、Jetpack Compose、ArkUI、DOM/Compose Web）自己实现。2023 年 11 月 KMP 正式 Stable；2024 年 6 月华为开发者大会（HDC 2024）上 JetBrains 与华为合作宣布 Kotlin 原生支持 HarmonyOS NEXT，KMP 正式扩展到"Android + iOS + 鸿蒙 + Web"的四端矩阵；随后 Compose Multiplatform for iOS 经历 Alpha → Beta 演进，使得"连 UI 也可以一起共享"成为可选项。 对 iOS 开发者而言，KMP 的意义在于：Android/鸿蒙同事写的 Kotlin 代码你可以像 Swift 一样调用，而代价只是多一个 XCFramework 和一点桥接代码。本文从架构开始，一路讲到编译原理、内存模型、iOS/鸿蒙互操作细节与工程最佳实践。 一、KMP 是什么 1.1 一句话定义 KMP 是 Kotlin 官方的跨平台编译工具链，允许你用 Kotlin 写一份"业务逻辑"代码，编译到多个目标平台： ...

React Native 是 Meta 2015 年开源的跨平台框架，用 JavaScript/TypeScript 写一份业务代码，在 iOS 和 Android 上渲染出真正的原生控件（UIView / android.view.View），而不是像 Flutter 那样自绘，也不是像 H5 那样跑在 WebView 里。经过 2018~2024 年的"新架构"大重构，RN 在 0.76 让 New Architecture（Fabric + TurboModules + JSI + Codegen + Bridgeless）成为默认，并在 0.82（2025 年 10 月）彻底告别旧的 Bridge 时代——这是 RN 十年来最大的一次范式迁移。 对 iOS 开发者而言，RN 的定位很特殊：UI 仍然是 UIKit，但控制 UI 的大脑换成了 JS。这让它一方面拥有"原生 Look & Feel“的天然优势（iOS 26 Liquid Glass 不用等框架跟进），另一方面又背负着”JS/原生边界抖动“的原罪。在 AI Coding 时代，RN 凭借 Web 生态庞大的训练语料和 Expo 工具链成为 LLM 生成代码正确率最高的移动框架，但 JSI 的 C++ 层和 Bridgeless 的新调试链路也让"AI 修 Bug"变得比以前更难。 ...

动态化 DSL（Domain-Specific Language，领域特定语言）是"不改 App 主包、不走应用商店审核，只下发一段描述文件就能改变界面和逻辑"的一类技术。它在 2015~2023 年成为国内大厂客户端的必备基础设施：阿里 DinamicX / Tangram / VirtualView / LuaView、字节 Lynx、腾讯 Mars / 小程序、滴滴 Hummer、美团 MRN / Recce、京东 Taro-Native、拼多多 Lego、支付宝 Nebula / BirdNest、爱奇艺 Doric ……几乎每一家超级 App 都至少造过一套自己的动态化 DSL。 进入 2026 年 AI Coding 时代，动态化 DSL 的定位发生了根本性转变： 过去它服务于"业务迭代速度"——解决包大小限制、审核周期、多端复用问题。 现在它服务于"Agent 生成 UI"——LLM 更擅长生成 JSON / 结构化 DSL 而不是跨平台原生代码，DSL 成为 Generative UI / SDUI（Server-Driven UI）落地移动端的唯一高效载体。 本文从定义出发，讲透动态化 DSL 的历史演进、分类体系、核心渲染管线、关键原理（AST / 表达式引擎 / 布局 / 数据绑定 / 差分），再深入解剖 DinamicX、Tangram、LuaView、Lynx、Hummer、Recce 六大主流方案的工程实现，最后系统分析 AI Coding 时代的优劣势与决策矩阵。 ...