【六大移动UI框架比较学与练】第1课:搭建环境,创建第一个应用

合集名称:移动开发六大声明式UI框架比较学习合集

合集简介:

聚焦Jetpack Compose、SwiftUI、ArkUI、Compose Multiplatform、React Native、Flutter六大声明式UI框架,以经典示例代码对照讲解,拆解语法与底层渲染原理,区分原生、跨端特性。采用学与练:研习框架原理,每课配套15道多元化习题,理论结合实操,系统掌握现代化移动UI开发体系。

六大框架分类图

跨端框架

Compose Multiplatform
Kotlin / Skia

React Native
JS/TS / 原生组件映射

Flutter
Dart / Skia/Impeller

原生框架

Jetpack Compose
Kotlin / Android

SwiftUI
Swift / Apple

ArkUI
ArkTS / HarmonyOS

全套33课大纲

第一阶段:环境入门与基础认知(1–6)

  1. 第1课:搭建环境,创建第一个应用
  2. 第2课:工程目录结构与基础语法差异对比
  3. 第3课:文本、图片、布局核心组件实战对照
  4. 第4课:样式修饰、尺寸边距与界面样式开发
  5. 第5课:声明式UI核心状态机制入门详解
  6. 第6课:各框架UI渲染更新基础原理初识

第二阶段:状态机制与渲染核心(7–12)

  1. 第7课:状态提升与单向数据流标准实现对照
  2. 第8课:状态装饰器作用域与响应机制深度对比
  3. 第9课:重组刷新底层机制与渲染差异解析
  4. 第10课:不可变数据设计思想与框架实践规范
  5. 第11课:懒加载列表组件性能对比与最优写法
  6. 第12课:UI无效刷新成因与状态性能避坑指南

第三阶段:页面交互与适配(13–17)

  1. 第13课:页面路由跳转、传参与栈管理对比
  2. 第14课:点击、输入、手势交互事件体系对照
  3. 第15课:弹窗、浮层、抽屉通用组件实现对比
  4. 第16课:主题切换与深色模式适配方案
  5. 第17课:多设备屏幕适配与响应式布局开发

第四阶段:通用工程核心能力(18–23)

  1. 第18课:异步并发编程模型与写法全面对照
  2. 第19课:网络请求封装、拦截与异常统一处理
  3. 第20课:本地键值存储与数据库方案对比选型
  4. 第21课:MVVM架构分层规范与落地实践
  5. 第22课:Repository数据仓库模式统一实现
  6. 第23课:系统权限适配与原生能力调用对照

第五阶段:性能优化与工程发布(24–28)

  1. 第24课:UI渲染性能瓶颈与框架优化方案
  2. 第25课:官方调试工具使用与性能排查实战
  3. 第26课:图片加载、缓存策略与内存优化
  4. 第27课:项目模块化与多环境工程配置
  5. 第28课:项目打包、签名与应用上架流程对比

第六阶段:横向总结与技术选型(29–33)

  1. 第29课:六大框架全方位优劣与特性横向对比
  2. 第30课:原生开发与跨端开发核心差异深度总结
  3. 第31课:不同业务场景框架选型最优策略
  4. 第32课:声明式UI五层渲染架构模型深度剖析
  5. 第33课:全系列技术总结与进阶学习路线规划

本文目录


一、为什么要比较这六大框架

1.1 移动开发的“巴别塔困境”

移动开发走到今天,出现了一个看似矛盾的局面。

一方面,声明式 UI 已经成为业界共识。Jetpack Compose、SwiftUI、ArkUI、Compose Multiplatform、React Native、Flutter,无论出自哪家公司、面向哪个平台,都在用同一套核心思想描述界面:UI 是状态的函数。开发者不再手动寻找控件、修改属性,而是声明“当前状态下界面应该长什么样”,由框架负责比较差异并更新。

另一方面,六大框架之间的差异并没有因为思想趋同而消失,反而在工程实践层面越拉越大:

  • 语言不同:Kotlin、Swift、ArkTS、Dart、TypeScript。
  • 渲染路线不同:Compose Runtime、SwiftUI Runtime、ArkUI Runtime、Skia、原生组件映射、Impeller。
  • 状态机制不同:@State、@Observable、@Prop、Snapshot、useState、setState。
  • 平台策略不同:Android 原生、Apple 原生、HarmonyOS 原生、Kotlin 跨端、JS/TS 跨端、Dart 自绘跨端。

这就是移动开发的“巴别塔困境”:思想同源,方言各异,工程体系互不兼容。

一个团队如果只会一个框架,问题不大。但如果面临以下场景,单一框架的知识就不够用了:

  1. 公司同时有 Android、iOS、HarmonyOS 三条业务线。
  2. 团队需要从 React Native 迁移到 Flutter,或从 Flutter 迁移到 Compose Multiplatform。
  3. 技术选型时需要在原生体验、开发效率、包体积、招聘成本之间做权衡。
  4. 面试或晋升时,需要展示对移动 UI 技术全景的理解。
  5. 需要判断某个“跨端方案”是否真的适合自己的业务。

这些场景的共同要求是:你不能只会一个框架,你需要理解多个框架之间的本质差异与共性规律。

1.2 比较的四个层次

本合集不是简单的“API 对照手册”,而是按四个层次逐层深入:

层次名称回答的问题对应能力
第一层语法对照同一个功能,六个框架分别怎么写看得懂
第二层机制解析为什么这样设计,底层如何运作想得通
第三层工程体系构建、依赖、模块化、调试、发布如何组织做得成
第四层设计哲学为什么 Google 选 Compose Runtime,Apple 坚持互操作,Flutter 选自绘选得对

只有走到第四层,你才能在技术选型时说出“为什么选 A 不选 B”,而不是“因为大家都说 A 好”。

1.3 为什么是这六个

移动声明式 UI 框架不止六个。但以下六个覆盖了当前主流技术路线的全部关键分支:

框架代表路线不可替代性
Jetpack ComposeAndroid 原生声明式Android 生态唯一官方方案
SwiftUIApple 原生声明式Apple 生态唯一官方方案
ArkUIHarmonyOS 原生声明式鸿蒙生态唯一官方方案
Compose MultiplatformKotlin 跨端共享 UIKotlin 技术栈跨端唯一成熟方案
React NativeJS/TS 跨端 + 原生组件映射Web 团队进入移动端的最短路径
FlutterDart 自绘跨端自绘渲染路线的代表

这六个框架分别回答不同的问题:

  • 只做 Android,用什么?Jetpack Compose。
  • 只做 iOS,用什么?SwiftUI。
  • 只做 HarmonyOS,用什么?ArkUI。
  • 团队是 Kotlin 背景想跨端,用什么?Compose Multiplatform。
  • 团队是 Web 前端背景想跨端,用什么?React Native。
  • 追求 UI 一致性和自绘控制,用什么?Flutter。

比较这六个,等于一次性覆盖了移动声明式 UI 的全部主要选型分支。

1.4 比较带来的认知升级

只学一个框架,你学到的是“这个框架怎么用”。比较六个框架,你学到的是:

  1. 共性规律:声明式 UI 的本质是什么?状态驱动、单向数据流、组件化、不可变数据,在六个框架中如何体现?
  2. 差异根源:为什么有的框架用 @State,有的用 useState,有的用 @Prop?差异背后是语言设计、平台约束、历史包袱的不同。
  3. 选型依据:什么业务适合原生,什么业务适合跨端?什么团队适合 Flutter,什么团队适合 React Native?
  4. 迁移能力:从 A 框架迁移到 B 框架时,哪些知识可以复用,哪些必须重学?
  5. 架构视野:为什么 React Native 要推出新架构 Fabric?为什么 Flutter 从 Skia 转向 Impeller?这些演进方向揭示了什么趋势?

这五点是单一框架学习无法获得的,也是本合集的核心价值。

1.5 本课在合集中的地位

第1课是整个合集的地基。它不做语法比较,不做性能分析,只做一件事:让六个框架都能跑起来。

原因很简单:比较的前提是可运行。如果 Jetpack Compose 工程跑不起来、SwiftUI 预览崩溃、Flutter 命令找不到,后续所有对照都只是纸上谈兵。所以第1课的目标是:

  1. 建立每个框架的最小可运行工程。
  2. 明确每个框架的版本基线与工具链。
  3. 给出可复现的检查命令与验证方式。
  4. 建立“五层排查模型”,用于定位环境问题。

只有六个框架都能运行,第2课之后的语法对照、状态机制、渲染原理、性能优化才有意义。


二、本课导学

2.1 本课要解决的问题

声明式 UI 框架的语法简洁,但环境搭建涉及编译器、构建系统、平台 SDK、预览系统、设备环境、签名体系六个层次。多数初学者能看懂语法,却卡在环境问题上:

  1. Android Studio 同步失败,Gradle 与 AGP 版本不兼容。
  2. Xcode 预览反复崩溃,模拟器无法连接。
  3. DevEco Studio 模拟器无法启动,SDK 组件缺失。
  4. React Native 的 Metro 端口被占用,Node 版本不匹配。
  5. Compose Multiplatform 的 iOS 目标编译失败,Kotlin/Native 缓存异常。
  6. Flutter 命令无法识别,Android 许可证未接受。

这些问题的共同特点是:报错信息模糊,搜索引擎结果分散,缺乏系统性的排查路径。本课的目标是建立一条“从零到可运行”的完整路径,并给出每个框架的版本基线、操作步骤、验证方式和常见错误的排查方法。

2.2 本课目标

学完本课,你应能:

  1. 说出六大框架当前推荐的工具链版本基线。
  2. 独立创建并运行六个最小工程。
  3. 区分 setContent、@main、@Entry、App()、App 组件、runApp() 六类入口。
  4. 根据报错信息定位到具体层次(语言运行时、SDK、构建工具、预览调试、设备签名)。
  5. 完成15道习题并理解每道题的解析。
  6. 明确每个框架的适用边界与版本敏感项。

2.3 适用边界

本课适用于:

  1. 准备学习声明式 UI 的移动开发者。
  2. 需要横向对比六大框架的技术选型人员。
  3. 需要一份可复现的环境搭建清单的团队。

本课不适用于:

  1. 完全零编程基础的学习者。
  2. 需要直接学习高级状态管理与架构的读者。
  3. 需要生产级签名、上架、合规配置的读者。这些内容将在第27–28课展开。

2.4 术语约定

为避免概念混淆,本课统一以下术语:

术语定义
声明式 UI开发者描述“当前状态对应的界面”,框架负责比较差异并更新 UI
命令式 UI开发者手动获取视图对象并逐步修改属性
原生框架直接使用平台官方 UI 体系,如 Jetpack Compose、SwiftUI、ArkUI
跨端框架一套代码面向多个平台,如 Compose Multiplatform、React Native、Flutter
热重载开发阶段保存代码后,框架快速替换修改部分并保留部分状态
SDK平台开发工具包
构建工具把源码、资源、依赖转换为可运行产物的工具

2.5 版本基线说明

本课以 2026 年 10 月为时间基线,各框架推荐版本如下:

框架推荐版本最低语言要求来源
Jetpack ComposeBOM 2026.08.00(Compose 1.12)Kotlin 2.0+,AGP ≥ 9.1.1Google 官方博客
SwiftUIXcode 26(Swift 6.2)macOS Sequoia 15.6+Apple 官方文档
ArkUIDevEco Studio 6.0.2 ReleaseHarmonyOS SDK 6.0.2(22)华为开发者官网
Compose Multiplatform1.12.0Kotlin 2.1.0+Kotlin 官方文档
React Native0.87Node.js ≥ 22.13.0,AGP 9React Native 官方博客
Flutter3.41.7(Dart 3.11.5)内置 Dart SDKFlutter 官方发布说明

版本敏感提示:移动开发工具链迭代较快,上述版本为 2026 年 10 月的推荐基线。若实际版本有差异,请以各框架官方文档的最新推荐为准。Jetpack Compose 1.12 将 compileSdk 更新为 API 37,要求最低 AGP 9.1.1;React Native 0.87 将 Node.js 最低版本提升至 22.13.0,并默认启用 Strict TypeScript API;Compose Multiplatform 1.12.0 不再支持 iosX64 与 macosX64 目标。这些是近期的重要变更。

2.6 知识地图

为什么要比较

本课导学

环境搭建通用模型

六框架分别搭建

第一个应用

运行验证

常见错误排查

15道习题

知识点总结

比较后的十个深刻感知


三、环境搭建通用模型

3.1 环境搭建的五个层次

无论哪个框架,环境搭建都可抽象为五层。排查环境问题时,应按这五层逐层检查,而不是随机搜索:

第1层:语言运行时
Kotlin / Swift / ArkTS / Dart / Node.js

第2层:平台 SDK
Android SDK / iOS SDK / HarmonyOS SDK

第3层:构建工具
Gradle / Xcode Build / hvigor / Metro / Flutter CLI

第4层:预览与调试
Compose Preview / Canvas / Previewer / Fast Refresh / Hot Reload

第5层:设备与签名
模拟器 / 真机 / 证书 / 端口转发

各层典型问题对照:

层次典型问题
第 1 层:语言运行时JDK 版本错误、Node 版本过低
第 2 层:平台 SDKSDK 未安装、API Level 不匹配
第 3 层:构建工具版本不兼容、依赖下载失败
第 4 层:预览与调试预览崩溃、热重载失效
第 5 层:设备与签名设备未识别、签名失败

3.2 硬件与系统建议

  1. CPU:支持虚拟化,建议 8 核以上。
  2. 内存:建议 16GB 以上,32GB 更佳。
  3. 磁盘:SSD,至少预留 100GB。ArkUI 的 SDK 与模拟器镜像合计约 10GB,Android SDK 与模拟器镜像合计约 20–30GB。
  4. 系统限制:macOS 可覆盖 iOS 与 Android;Windows / Linux 无法完整构建 iOS 原生工程。若需开发 iOS 应用,必须使用 macOS。

3.3 通用软件清单

软件用途是否必需
Git版本控制推荐
JDK 17+Android、Gradle、Flutter必需
Node.js 22.13+React Native 0.87+必需(RN)
Android StudioAndroid、Compose、Flutter、RN推荐
Xcode 26SwiftUI、iOS、CMP iOS、RN iOS必需(iOS)
DevEco StudioArkUI必需(ArkUI)
Flutter SDK 3.41.7Flutter必需(Flutter)
VS CodeFlutter、React Native可选

3.4 平台检查命令与验证方式

框架检查命令预期输出
Androidadb devices列出已连接的模拟器或真机
iOSxcodebuild -version输出版本号,如 Xcode 26.x
HarmonyOShdc list targets列出已连接设备
Flutterflutter doctor -v各检查项显示绿色对勾
React Nativenpx react-native doctor检查 Android、iOS、环境变量
Compose Multiplatform./gradlew tasks列出可执行任务

3.5 风险操作与回退方式

操作风险回退方式
修改 PATH 环境变量命令冲突备份原 PATH,回退时恢复
安装全局 npm 包版本冲突记录版本,卸载或切换版本
配置代理部分工具链不可用记录原代理设置,回退时清除
安装模拟器镜像磁盘占用大在 SDK Manager 中删除
配置签名证书泄露不提交证书到公开仓库;回退时撤销证书或使用调试签名

四、Jetpack Compose 环境搭建与第一个应用

4.1 版本要求

Jetpack Compose 1.12 是目前最新稳定版本,核心模块已统一到 1.12。关键要求:

  1. Kotlin 2.0+。
  2. AGP 最低 9.1.1(Compose 1.12 将 compileSdk 更新为 API 37)。
  3. Compose BOM 版本 2026.08.00。

4.2 前置条件

  1. 安装 JDK 17 或 Android Studio 推荐版本。
  2. 下载 Android Studio 稳定版。
  3. 准备 Android 模拟器或真机。
  4. 网络可访问 Google Maven 与 Gradle 仓库。

4.3 安装与配置

步骤 1:安装 Android Studio

  1. 下载 Android Studio 稳定版。
  2. 安装时勾选 Android SDK、Android SDK Platform、Android Virtual Device。
  3. 启动后进入 SDK Manager,安装 API Level 37。
  4. 安装 Build Tools、Platform Tools、Emulator。
  5. 配置 ANDROID_HOME 与 PATH。

步骤 2:验证环境

adb devices

预期输出:列出已连接的模拟器或真机。

步骤 3:创建项目

  1. 打开 Android Studio → New Project → Empty Activity。
  2. Language 选择 Kotlin。
  3. Minimum SDK 选择 API 21 以上。
  4. 点击 Finish。

步骤 4:在 build.gradle.kts 中配置 Compose BOM

dependencies {
    implementation(platform("androidx.compose:compose-bom:2026.08.00"))
    implementation("androidx.compose.material3:material3")
    implementation("androidx.compose.ui:ui")
}

4.4 入口代码

package com.example.composefirst

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Text

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MaterialTheme {
                Text("Hello, Jetpack Compose")
            }
        }
    }
}

代码解释:

  1. ComponentActivity 是 Android 活动组件。
  2. setContent 将 Composable 内容设置为 Activity 的 UI。
  3. MaterialTheme 提供 Material 主题。
  4. Text 是声明式文本组件。

4.5 运行与验证

  1. 选择模拟器或真机。
  2. 点击 Run。
  3. 首次构建下载 Gradle 依赖(可能需要 5–15 分钟,取决于网络)。
  4. 验证:模拟器显示“Hello, Jetpack Compose”,控制台出现 BUILD SUCCESSFUL。

4.6 常见错误与排查

错误现象原因修复方法
Gradle 同步失败网络、代理、JDK 版本不匹配检查网络,确认 JDK 17+,配置 Gradle 镜像
Incompatible Compose compiler versionCompose Compiler 与 Kotlin 版本不匹配统一使用 BOM 管理版本,避免手动指定 Compose Compiler 版本
Preview 不显示未 Sync Gradle 或 Compose 编译器版本不对Sync Gradle,检查 BOM 版本
编译超慢首次构建下载依赖配置 Gradle 镜像源,后续增量构建会快

适用边界:Jetpack Compose 仅适用于 Android 原生开发。如需跨端,应评估 Compose Multiplatform。

回退方式:若升级到 Compose 1.12 后出现 AGP 不兼容,可将 BOM 回退到 2026.05.01(Compose 1.11.2),该版本对 AGP 要求较低。


五、SwiftUI 环境搭建与第一个应用

5.1 版本要求

Xcode 26 包含 Swift 6.2 和 iOS 26 SDK,要求 macOS Sequoia 15.6 或更高版本。如果使用 Xcode 27,要求 macOS Tahoe 26.6 或更高,以及 Apple M1 及以上芯片。

5.2 前置条件

  1. macOS 与 Xcode 26。
  2. Apple ID。
  3. iOS Simulator。
  4. 如需真机调试,配置签名与信任证书。

5.3 安装与配置

步骤 1:安装 Xcode

  1. 打开 Mac App Store。
  2. 搜索 Xcode 并安装。
  3. 首次启动安装附加组件。
  4. 配置 Apple ID。
  5. 安装 iOS Simulator。

步骤 2:验证环境

xcodebuild -version
xcrun simctl list devices

预期输出:版本号与模拟器列表。

步骤 3:创建项目

  1. 打开 Xcode → Create New Project → iOS App。
  2. 填写 Product Name、Team、Organization Identifier。
  3. Interface 选择 SwiftUI。
  4. Language 选择 Swift。
  5. 保存并创建。

5.4 入口代码

import SwiftUI

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

struct ContentView: View {
    var body: some View {
        Text("Hello, SwiftUI")
            .padding()
    }
}

代码解释:

  1. @main 标记程序入口。
  2. App 协议定义应用场景。
  3. WindowGroup 管理窗口。
  4. ContentView 遵循 View,body 返回声明式视图。
  5. .padding() 是视图修饰符。

5.5 运行与验证

  1. 点击 Run 运行模拟器。
  2. 使用 Canvas 预览。
  3. 验证:模拟器显示“Hello, SwiftUI”;预览区显示同样文本。

5.6 常见错误与排查

错误现象原因修复方法
SwiftUI Preview 持续崩溃Xcode 27 的 JIT 预览路径问题开启 Use Legacy Preview Execution(Editor → Canvas → Enable Legacy Previews Execution)
预览引用已删除的模拟器模拟器被删除但预览仍引用运行 xcrun simctl --set previews delete all 清理预览模拟器
无法选择 Team未登录 Apple IDXcode → Settings → Accounts 登录

适用边界:SwiftUI 仅适用于 Apple 平台。

回退方式:若 Xcode 26 升级后旧项目构建失败,可在 Apple 开发者网站下载 Xcode 25 并存放在独立目录,不影响新版本。


六、ArkUI 环境搭建与第一个应用

6.1 版本要求

DevEco Studio 6.0.2 Release 配套 HarmonyOS SDK 6.0.2(22)。安装时需要预留约 10GB 空间用于 SDK、ArkTS 编译工具链、Previewer 及模拟器镜像。

6.2 前置条件

  1. Windows 10/11 64 位(BIOS 开启虚拟化)或 macOS 12 及以上。
  2. 内存至少 8GB(推荐 16GB)。
  3. 硬盘预留 100GB 以上可用空间。
  4. 华为开发者账号。

6.3 安装与配置

步骤 1:安装 DevEco Studio

  1. 访问华为开发者官网下载最新版 DevEco Studio 与 HarmonyOS SDK。
  2. 安装路径必须纯英文且不含空格或特殊字符,避免后续编译报错。
  3. 首次启动选择 Do not import settings,同意协议后选择 Standard 安装模式。
  4. 等待 IDE 自动下载 HarmonyOS SDK、ArkTS 编译工具链、Previewer 及模拟器镜像(约 10GB)。

步骤 2:验证 SDK 组件

在 Settings → HarmonyOS SDK 中确认 ArkTS、Toolchains 等组件状态为已安装。

步骤 3:创建项目

  1. 欢迎页点击 Create Project。
  2. 选择 Application → Empty Ability(Stage 模型)。
  3. Language 选择 ArkTS。
  4. Compile SDK 选择最新 API。
  5. 等待同步结束。

6.4 入口代码

@Entry
@Component
struct Index {
  build() {
    Column() {
      Text('Hello, ArkUI')
        .fontSize(20)
    }
    .width('100%')
    .height('100%')
    .justifyContent(FlexAlign.Center)
  }
}

代码解释:

  1. @Entry 表示页面入口。
  2. @Component 表示自定义组件。
  3. build() 返回 UI。
  4. Column 是纵向布局,Text 是文本组件。
  5. .justifyContent 控制主轴对齐。

6.5 运行与验证

  1. Tools → Device Manager 创建并启动模拟器,或连接开启 USB 调试的鸿蒙真机。
  2. 点击 Run。
  3. 验证:模拟器或真机显示“Hello, ArkUI”。

6.6 常见错误与排查

错误现象原因修复方法
模拟器无法启动未开启 Hyper-V 或 BIOS 虚拟化Windows 功能中勾选 Hyper-V 后重启
模拟器启动卡在转圈镜像不完整或显卡驱动问题删除虚拟设备重建,检查虚拟化与显卡驱动
SDK 下载缓慢网络问题切换华为国内镜像源,清除代理缓存
真机无法识别未开启开发者模式连续点击版本号开启开发者模式,启用 USB 调试

适用边界:ArkUI 主要面向 HarmonyOS 生态。

回退方式:若 SDK 升级后项目不兼容,在 SDK Manager 中回退到上一版本。


七、Compose Multiplatform 环境搭建与第一个应用

7.1 版本要求

Compose Multiplatform 1.12.0 支持以下平台:Android 5.0+(API 21)、iOS 14+、macOS 13 arm64、Windows 10、Linux Ubuntu 20.04、Web(WasmGC)。要求 Kotlin 2.1.0+。从 1.11.1 起,不再支持 Apple x86_64 目标(iosX64 和 macosX64 已移除)。

7.2 前置条件

  1. Android Studio + Kotlin Multiplatform 插件。
  2. Xcode 26(iOS 目标)。
  3. JDK 17+。
  4. Gradle。

7.3 创建项目

  1. 使用 Kotlin Multiplatform Wizard。
  2. 选择 Android、iOS、Desktop 目标。
  3. 勾选 Compose Multiplatform。
  4. 生成项目。
  5. 使用 Android Studio 打开。

7.4 共享 UI 代码

// commonMain
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable

@Composable
fun App() {
    MaterialTheme {
        Text("Hello, Compose Multiplatform")
    }
}

Android 入口:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent { App() }
    }
}

iOS 入口:由 SwiftUI 包装 ComposeUIViewController。

7.5 运行与验证

平台命令验证
Android./gradlew :androidApp:installDebug模拟器显示共享 UI
Desktop./gradlew :desktopApp:run桌面窗口显示共享 UI
iOSXcode 打开 iOS 工程运行模拟器显示共享 UI

7.6 常见错误与排查

错误现象原因修复方法
iOS 编译报 Undefined symbolKotlin/Native 缓存问题在 gradle.properties 中添加 kotlin.native.cacheKind=none
compileKotlinIosX64 失败Compose Multiplatform 1.12 不再发布 iosX64 变体移除 iosX64() 目标,仅保留 iosArm64 和 iosSimulatorArm64
iOS 模拟器 SIGSEGVXcode 26 + K/N 2.4.0 兼容性问题关注 JetBrains 的修复版本更新

适用边界:Compose Multiplatform 适合共享 Kotlin 与 Compose UI,但各平台仍有签名要求和平台特定代码。

回退方式:若 1.12.0 出现问题,可回退到 1.10.3,该版本仍支持 iosX64。


八、React Native 环境搭建与第一个应用

8.1 版本要求

React Native 0.87 的关键变更:

  1. Node.js 最低版本提升至 22.13.0。
  2. AGP 最低版本 9,Kotlin 2.0+。
  3. Strict TypeScript API 成为默认 JavaScript API,深度导入(如 react-native/Libraries/*)变为类型错误。
  4. Metro 从 0.84 更新到 0.87,源映射生成速度提升 2 倍,内存占用减半。

8.2 前置条件

  1. Node.js 22.13+(推荐使用 nvm 或 fnm 管理版本)。
  2. Android Studio 或 Xcode。
  3. Android SDK 或 iOS 模拟器。

8.3 安装与配置

步骤 1:检查 Node.js 版本

node -v

预期输出:v22.13.0 或更高。

步骤 2:创建项目

npx @react-native-community/cli init MyApp
cd MyApp
npm run android

或使用 Expo:

npx create-expo-app MyApp
cd MyApp
npx expo start

8.4 入口代码

import React from 'react';
import { SafeAreaView, Text, StyleSheet } from 'react-native';

export default function App() {
  return (
    <SafeAreaView style={styles.container}>
      <Text style={styles.title}>Hello, React Native</Text>
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, alignItems: 'center', justifyContent: 'center' },
  title: { fontSize: 20 },
});

8.5 运行与验证

  1. Android:npm run android。
  2. iOS:npm run ios。
  3. 验证:模拟器显示“Hello, React Native”;Metro 控制台显示打包进度。

8.6 常见错误与排查

错误现象原因修复方法
Metro 无法启动,提示端口占用8081 端口被其他进程占用终止占用进程,或更换端口;执行 npx react-native start --reset-cache
真机/模拟器无法连接 Metro端口未转发adb reverse tcp:8081 tcp:8081
升级到 0.87 后 TypeScript 报错深度导入变为类型错误迁移到从 react-native 根路径导入;暂时可使用 opt-out 开关(仅到 0.88)

适用边界:React Native 适合 JS / TS 团队,但复杂原生能力仍需平台开发。

回退方式:若 0.87 的 Strict TypeScript 迁移阻塞,可暂时启用 opt-out 开关,但该开关将在 0.89 移除。


九、Flutter 环境搭建与第一个应用

9.1 版本要求

Flutter 3.41.7(Dart 3.11.5)是当前推荐的生产环境版本,历经 7 个补丁,社区反馈的 Regression 问题已基本修复。Flutter 已内置 Dart SDK,无需单独安装。

9.2 前置条件

  1. Flutter SDK。
  2. Android Studio 或 Xcode。
  3. 模拟器或真机。

9.3 安装与配置

步骤 1:安装 Flutter SDK

  1. 下载 Flutter SDK。
  2. 解压到指定目录。
  3. 配置 PATH。
  4. 运行 flutter doctor 检查环境。

步骤 2:接受 Android 许可证

flutter doctor --android-licenses

步骤 3:创建项目

flutter create my_app
cd my_app
flutter run

9.4 入口代码

import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Center(child: Text('Hello, Flutter')),
      ),
    );
  }
}

9.5 运行与验证

  1. flutter run。
  2. 按 r 热重载,按 R 热重启。
  3. 验证:模拟器显示“Hello, Flutter”;控制台显示热重载成功。

9.6 常见错误与排查

错误现象原因修复方法
flutter 命令找不到PATH 未配置将 Flutter SDK 的 bin 目录添加到 PATH
Android license 错误许可证未接受flutter doctor --android-licenses
Windows 上 flutter doctor 报错SystemRoot 环境变量缺失以管理员身份运行 PowerShell,检查环境变量
Gradle 下载慢网络问题配置 Gradle 镜像源

适用边界:Flutter 自绘渲染,UI 一致性强,但包体积和平台原生能力调用需额外评估。

回退方式:若 3.41.7 出现问题,可回退到 3.38.10(极度稳定的老版本,社区插件适配度高)。


十、六大框架第一个应用对照表

对比项Jetpack ComposeSwiftUIArkUICompose MultiplatformReact NativeFlutter
语言KotlinSwiftArkTSKotlinJS / TSDart
IDEAndroid StudioXcodeDevEco StudioAndroid StudioVS CodeAndroid Studio / VS Code
构建工具GradleXcode BuildhvigorGradleMetro + Gradle / XcodeFlutter CLI
入口标记setContent@main@EntryApp()根组件 ApprunApp()
预览 / 热重载Compose PreviewCanvasPreviewerCompose PreviewFast RefreshHot Reload
渲染路线Compose RuntimeSwiftUI RuntimeArkUI RuntimeSkia原生组件 + FabricSkia / Impeller
平台覆盖AndroidApple 全平台HarmonyOS多平台多平台多平台
适用边界Android 原生Apple 生态HarmonyOSKotlin 跨端JS / TS 跨端Dart 自绘跨端

入口标记与渲染路线直观对比:

入口标记

Jetpack Compose
setContent

SwiftUI
at-main

ArkUI
at-Entry

Compose Multiplatform
App

React Native
根组件 App

Flutter
runApp

说明:为避免 Mermaid 解析器将 @ 识别为链接语法,图中用 at-main、at-Entry 代替 @main、@Entry。

渲染路线

Compose Runtime

Jetpack Compose

SwiftUI Runtime

SwiftUI

ArkUI Runtime

ArkUI

Skia

Compose Multiplatform

原生组件 + Fabric

React Native

Skia / Impeller

Flutter


十一、六大框架环境搭建常见错误排查总表

框架高频错误优先排查验证方式
Jetpack ComposeGradle 同步失败网络、JDK、AGP 版本./gradlew tasks
SwiftUIPreview 崩溃预览执行模式、模拟器xcodebuild -version
ArkUI模拟器无法启动虚拟化、镜像完整性hdc list targets
Compose MultiplatformiOS 编译失败Xcode、Kotlin/Native 缓存Xcode 构建日志
React NativeMetro 启动失败Node 版本、端口占用npx react-native doctor
Flutterflutter 命令找不到PATH、Android 许可证flutter doctor -v

十二、本课核心认知与限制条件

12.1 核心认知

  1. 声明式 UI 的核心是“状态驱动界面”。
  2. 比较六个框架的价值不在于记住 API,而在于理解共性规律、差异根源、选型依据与演进趋势。
  3. 环境问题的排查应按照五层模型(语言运行时 → SDK → 构建工具 → 预览调试 → 设备签名)逐层进行。
  4. 版本兼容性是移动开发环境搭建中最常见的故障原因。
  5. 预览与热重载是声明式 UI 开发效率的关键。
  6. 六大框架语法不同,但工程路径高度相似:安装工具链 → 配置 SDK → 创建工程 → 编写入口 → 运行验证。

12.2 限制条件

  1. 本课只覆盖最小可运行工程,不涉及生产签名、上架、合规。
  2. 本课不展开状态管理、路由、网络、数据库。
  3. 不同框架版本可能影响命令与界面,请以官方文档为准。
  4. Windows / Linux 无法完整构建 iOS 原生工程。
  5. 模拟器与真机行为可能不同,关键功能需真机验证。

12.3 方案选择理由

  1. 先讲“为什么要比较”,是因为技术选型的价值不在 API 对照,而在理解设计哲学与适用边界。
  2. 选择六大框架,是为了覆盖原生与跨端、自绘与原生组件映射、Kotlin 与 JS / TS 与 Dart 多条路线。
  3. 先讲环境搭建,是因为环境是后续所有实验的基础。
  4. 每框架先给最小代码,再给运行验证,是为了避免“只看不跑”。
  5. 加入版本基线与风险回退,是为了让读者明确时效边界。

十三、习题

13.1 选择题(4题)

1. 下列哪个框架主要使用 Kotlin 作为开发语言?

A. SwiftUI
B. Jetpack Compose
C. Flutter
D. ArkUI

参考答案:B

解读:Jetpack Compose 是 Android 原生声明式 UI 工具包,主要使用 Kotlin。SwiftUI 使用 Swift,Flutter 使用 Dart,ArkUI 主要使用 ArkTS。


2. SwiftUI 中,应用入口通常使用哪个标记?

A. @Entry
B. @Component
C. @main
D. runApp()

参考答案:C

解读:SwiftUI 使用 @main 标记应用入口,通常配合 App 协议和 WindowGroup。@Entry、@Component 是 ArkUI 常见标记,runApp() 是 Flutter 入口方式。


3. ArkUI 在 DevEco Studio 中常用的声明式语言是?

A. Dart
B. ArkTS
C. JSX
D. Swift

参考答案:B

解读:ArkUI 主要使用 ArkTS 编写声明式界面。Dart 对应 Flutter,JSX / TSX 常见于 React Native,Swift 对应 SwiftUI。


4. Flutter 创建项目后,首次运行常用命令是?

A. flutter run
B. npm run android
C. gradlew run
D. xcodebuild

参考答案:A

解读:Flutter 创建项目后,通常在项目根目录执行 flutter run。npm run android 常用于 React Native,gradlew 常用于 Android / Compose Multiplatform,xcodebuild 常用于 iOS 原生构建。

13.2 判断题(3题)

5. React Native 使用 JavaScript / TypeScript 编写,但最终会通过原生组件进行渲染。

参考答案:正确

解读:React Native 的 UI 由 React 组件描述,运行时通过桥接或新架构将组件映射到平台原生组件。因此它既保留前端语法,又依赖原生渲染能力。


6. Compose Multiplatform 可以将 Compose UI 代码共享到 Android、iOS、Desktop 等平台。

参考答案:正确

解读:Compose Multiplatform 基于 Kotlin Multiplatform 与 Compose,目标是把共享 UI 放到 commonMain,再由各平台源集完成平台适配,从而实现 Android、iOS、Desktop 等平台复用。


7. Jetpack Compose 只能用于 Android,完全不能与 Kotlin Multiplatform 结合。

参考答案:错误

解读:Jetpack Compose 主要服务 Android,但并非“完全不能”与 Kotlin Multiplatform 结合。Compose Multiplatform 正是基于 Compose 与 KMP 的跨平台方案。表述中的“只能”“完全不能”过于绝对,因此错误。

13.3 填空题(3题)

8. SwiftUI 中,描述视图的核心协议是 ________。

参考答案:View

解读:SwiftUI 中,一个视图通常遵循 View 协议,并实现 body 属性。body 返回声明式视图内容,框架根据状态变化自动更新界面。


9. Flutter 使用 ________ 语言编写。

参考答案:Dart

解读:Flutter 使用 Dart 语言,已内置 Dart SDK,无需单独安装。Dart 支持 JIT 与 AOT,分别服务于开发阶段的热重载与发布阶段的性能优化。


10. React Native 的快速刷新机制通常称为 ________。

参考答案:Fast Refresh

解读:React Native 使用 Metro 打包器,Fast Refresh 可以在保存代码后快速刷新界面,同时尽量保留组件状态。React Native 0.87 将 Metro 更新到 0.87,源映射生成速度提升 2 倍。

13.4 简答题(2题)

11. 简述声明式 UI 与命令式 UI 的核心区别。

参考答案:

命令式 UI 关注“如何做”,开发者需要手动找到视图对象并逐步修改属性,例如设置文本、显示隐藏、更新列表。

声明式 UI 关注“是什么”,开发者描述当前状态对应的界面,框架负责比较差异并更新 UI。状态变化后,界面自动重新计算或重组。

解读:声明式 UI 的核心是“状态驱动界面”。Jetpack Compose、SwiftUI、ArkUI、Compose Multiplatform、React Native、Flutter 都遵循这一思想,但底层刷新机制、渲染方式和平台映射各不相同。


12. 简述 Jetpack Compose 与 Compose Multiplatform 的关系与差异。

参考答案:

Jetpack Compose 是 Google 推出的 Android 原生声明式 UI 工具包,主要运行在 Android 平台。

Compose Multiplatform 是 JetBrains 推动的跨平台方案,基于 Kotlin Multiplatform 与 Compose,可以把 Compose UI 共享到 Android、iOS、Desktop 等平台。Compose Multiplatform 1.12.0 支持 Android 5.0+、iOS 14+、macOS 13 arm64 等平台。

两者语法高度相似,但 Jetpack Compose 更偏 Android 原生,Compose Multiplatform 更偏多平台共享与平台源集组织。

解读:可以简单记为:Jetpack Compose 是 Android 原生 UI 基础,Compose Multiplatform 是在 KMP 体系下复用 Compose 能力的跨端方案。学习 Jetpack Compose 后,再学 Compose Multiplatform 会更容易。

13.5 代码补全 / 实操题(2题)

13. 补全 Flutter 入口代码:

void main() => runApp(________);

参考答案:

void main() => runApp(const MyApp());

解读:runApp() 接收一个根 Widget。MyApp 通常是 StatelessWidget 或 StatefulWidget。如果构造函数是 const,可以写成 const MyApp()。


14. 从六大框架中任选一个,写出输出“Hello, 六大声明式UI”的最小页面,并说明运行命令。

参考答案:以 Jetpack Compose 为例:

package com.example.hello

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.material3.Text

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            Text("Hello, 六大声明式UI")
        }
    }
}

运行命令:

./gradlew installDebug

或在 Android Studio 中直接点击 Run。

解读:本题考察入口写法与最小 UI 描述。Jetpack Compose 的入口是 setContent,界面由 @Composable 函数描述。其他框架也可完成同样任务:SwiftUI 用 @main 与 Text,ArkUI 用 @Entry 与 Text,Compose Multiplatform 用共享 App(),React Native 用根组件与 Text,Flutter 用 runApp() 与 Text。

13.6 综合题(1题)

15. 从 IDE、语言、构建工具、预览 / 热重载、运行命令五个维度,制作六大声明式 UI 框架环境搭建对照表。

参考答案:

维度Jetpack ComposeSwiftUIArkUICompose MultiplatformReact NativeFlutter
IDEAndroid StudioXcodeDevEco StudioAndroid StudioVS CodeAndroid Studio / VS Code
语言KotlinSwiftArkTSKotlinJS / TSDart
构建工具GradleXcode BuildhvigorGradleMetro + Gradle / XcodeFlutter CLI
预览 / 热重载Compose PreviewCanvasPreviewerCompose PreviewFast RefreshHot Reload
运行命令Android Studio Run 或 ./gradlew installDebugCmd + RDevEco Studio Run./gradlew :androidApp:installDebugnpm run android / npm run iosflutter run

解读:本题考察横向综合能力。六个框架虽然语言、IDE、构建工具不同,但环境搭建路径高度相似。对照表可以帮助快速选型,也可以作为后续课程的查询表。


十四、知识点总结

14.1 为什么要比较

  1. 移动开发存在“巴别塔困境”:思想同源,方言各异,工程体系互不兼容。
  2. 比较的四个层次:语法对照 → 机制解析 → 工程体系 → 设计哲学。
  3. 六大框架覆盖了原生与跨端、自绘与原生组件映射、Kotlin 与 JS / TS 与 Dart 的全部主要选型分支。
  4. 比较带来的认知升级:共性规律、差异根源、选型依据、迁移能力、架构视野。
  5. 本课是合集地基,目标是让六个框架都能跑起来。

14.2 环境搭建知识点

  1. Jetpack Compose:Android Studio、Android SDK API 37、Gradle、Kotlin 2.0+、AGP 9.1.1+、BOM 2026.08.00。
  2. SwiftUI:Xcode 26(Swift 6.2)、macOS Sequoia 15.6+、iOS 26 SDK。
  3. ArkUI:DevEco Studio 6.0.2、HarmonyOS SDK 6.0.2(22)、ArkTS、hvigor。
  4. Compose Multiplatform:Kotlin 2.1.0+、Gradle、Xcode 26、Android Studio;1.12.0 支持 Android 5.0+、iOS 14+。
  5. React Native:Node.js 22.13+、Metro 0.87、AGP 9、Kotlin 2.0+。
  6. Flutter:Flutter 3.41.7、Dart 3.11.5(内置)、Android Studio / Xcode。

14.3 第一个应用知识点

  1. Jetpack Compose 入口:setContent。
  2. SwiftUI 入口:@main 与 App。
  3. ArkUI 入口:@Entry 与 @Component。
  4. Compose Multiplatform 入口:共享 App()。
  5. React Native 入口:根组件 App。
  6. Flutter 入口:main() 与 runApp()。

14.4 构建与运行知识点

  1. Gradle:Android、Compose Multiplatform。
  2. Xcode Build System:SwiftUI、iOS。
  3. hvigor:ArkUI。
  4. Metro:React Native。
  5. Flutter CLI:Flutter。
  6. 首次构建通常最慢,后续可增量构建。

14.5 预览与热重载知识点

  1. Compose Preview:快速查看 Composable。
  2. SwiftUI Canvas:实时预览,但 Xcode 27 中可能需要开启 Legacy Preview 模式。
  3. ArkUI Previewer:HarmonyOS 页面预览。
  4. React Native Fast Refresh:JS / TS 代码快速刷新,Metro 0.87 性能显著提升。
  5. Flutter Hot Reload:Widget 树修改热重载。
  6. Compose Multiplatform:可复用 Compose Preview。

14.6 常见错误知识点

  1. SDK 未安装。
  2. 环境变量未配置。
  3. 模拟器未启动。
  4. 签名未配置。
  5. 网络导致依赖下载失败。
  6. 版本不兼容(最常见原因)。
  7. 端口被占用。
  8. 缓存损坏。

14.7 横向对比知识点

跨端框架

Compose Multiplatform
共享 UI 代表

React Native
原生组件映射代表

Flutter
自绘代表

原生框架

Jetpack Compose

SwiftUI

ArkUI

  1. 原生框架:Jetpack Compose、SwiftUI、ArkUI。
  2. 跨端框架:Compose Multiplatform、React Native、Flutter。
  3. 自绘代表:Flutter。
  4. 原生组件映射代表:React Native。
  5. 共享 UI 代表:Compose Multiplatform。
  6. Apple 生态代表:SwiftUI。
  7. Android 生态代表:Jetpack Compose。
  8. HarmonyOS 生态代表:ArkUI。

14.8 学习路线知识点

跑通环境

学组件

学状态

学路由

学网络与存储

学架构

学性能优化

技术选型

  1. 先跑通环境。
  2. 再学组件。
  3. 再学状态。
  4. 再学路由。
  5. 再学网络与存储。
  6. 再学架构。
  7. 再学性能优化。
  8. 最后做技术选型。

十五、本课比较后的十个深刻感知

本课完成了六大框架从零到可运行的完整搭建。在这个具体比较过程中,浮现出十个值得深思的感知。这些感知不是空泛的宏观议论,而是从本课的实际比较内容中提炼出来的,它们将贯穿整个合集,后续每一课都会回到这些感知上,验证、丰富、深化它们。

15.1 感知一:入口代码的差异,暴露了框架的设计哲学

六个框架的第一个应用都只输出一行文本,但入口代码的形态差异极大:

框架入口形态设计哲学
Jetpack ComposesetContent { Text(...) }UI 是 Activity 的一部分,与 Android 生命周期绑定
SwiftUI@main struct MyApp: App { WindowGroup { ... } }UI 是应用场景的描述,强调声明式应用结构
ArkUI@Entry @Component struct Index { build() { ... } }UI 是页面组件的构建结果,与鸿蒙 Ability 体系绑定
Compose Multiplatform@Composable fun App() { ... }UI 是纯函数,平台入口只负责调用
React Nativeexport default function App() { return (...) }UI 是组件树的根,与 React 生态一致
Fluttervoid main() => runApp(const MyApp())UI 是 Widget 树,从 main 函数启动

深刻感知:入口代码是框架设计哲学的“第一印象”。Compose 把 UI 挂在 Activity 上,SwiftUI 把 UI 描述为 App 场景,ArkUI 把 UI 组织为页面组件,Compose Multiplatform 把 UI 抽象为纯函数,React Native 把 UI 当作 React 组件树,Flutter 把 UI 从 main 启动。理解入口,就理解了框架如何看待“UI 与应用的关系”。

15.2 感知二:环境搭建的步骤数量,反映了框架的工具链抽象程度

统计六个框架从零到运行所需的步骤:

框架关键步骤数工具链抽象程度
Jetpack Compose安装 Android Studio → 配置 SDK → 创建项目 → 配置 BOM → 运行中,IDE 集成度高但 Gradle 配置复杂
SwiftUI安装 Xcode → 配置 Apple ID → 创建项目 → 运行高,Apple 全家桶一体化
ArkUI安装 DevEco Studio → 下载 SDK → 配置 hvigor → 创建项目 → 运行中,IDE 集成度高但 SDK 下载量大
Compose Multiplatform安装 Android Studio → 安装 KMP 插件 → Wizard 生成 → 运行中,依赖 Gradle 与 source set 体系
React Native安装 Node.js → 安装 CLI → 创建项目 → 启动 Metro → 运行低,命令行工具链分散
Flutter安装 Flutter SDK → 配置 PATH → doctor 检查 → 创建项目 → 运行中,CLI 统一但需处理 PATH 与许可证

深刻感知:工具链抽象程度决定了上手门槛。Apple 的 Xcode 一体化程度最高,从安装到运行最顺畅;React Native 的命令行工具链最分散,需要手动处理 Node、Metro、Android SDK、Xcode 多套环境;Flutter 通过 flutter doctor 统一检查,但 PATH 配置和许可证接受是常见卡点。工具链的抽象程度,本质上是框架对“开发者体验”的投入程度。

15.3 感知三:检查命令的差异,映射了平台工具链的历史

六个框架的环境检查命令完全不同:

框架检查命令命令来源
Jetpack Composeadb devicesAndroid Debug Bridge,来自 Android SDK
SwiftUIxcodebuild -versionXcode 命令行工具
ArkUIhdc list targetsHarmonyOS Device Connector
Compose Multiplatform./gradlew tasksGradle Wrapper
React Nativenpx react-native doctorReact Native CLI
Flutterflutter doctor -vFlutter CLI

深刻感知:检查命令是平台工具链历史的活化石。adb 来自 Android 早期就有的调试桥,xcodebuild 来自 Apple 的构建系统,hdc 是鸿蒙对 adb 的对标,gradlew 是 Gradle 的包装器,react-native doctor 和 flutter doctor 则是框架自建的诊断工具。命令的命名和来源,反映了框架是“站在平台工具链之上”还是“自建工具链”。

15.4 感知四:构建工具的差异,揭示了框架的底层架构

六个框架使用五种构建工具:

框架构建工具底层架构含义
Jetpack ComposeGradle基于 JVM 生态,依赖 Kotlin 编译器插件
SwiftUIXcode Build System基于 LLVM,深度集成 Apple 工具链
ArkUIhvigor基于 Node.js,鸿蒙自建构建系统
Compose MultiplatformGradle多目标构建,依赖 Kotlin Multiplatform
React NativeMetro + Gradle / XcodeJS 打包用 Metro,原生构建用平台工具
FlutterFlutter CLI自建构建系统,调用平台工具链

深刻感知:构建工具的选择,反映了框架如何处理“跨平台”这件事。React Native 采用“分层构建”:JS 用 Metro,原生用平台工具。Flutter 采用“统一构建”:Flutter CLI 统一调度,底层调用平台工具。Compose Multiplatform 采用“Gradle 多目标”:一套 Gradle 配置生成多个平台产物。构建工具的架构,就是框架跨平台策略的缩影。

15.5 感知五:错误类型的分布,反映了框架的耦合度

六个框架的高频错误类型分布:

框架高频错误耦合度含义
Jetpack ComposeGradle 同步失败、版本不兼容与 JVM 生态、AGP、Kotlin 版本强耦合
SwiftUIPreview 崩溃、签名失败与 Xcode 版本、模拟器、签名体系强耦合
ArkUI模拟器无法启动、SDK 下载慢与鸿蒙 SDK、虚拟化、镜像强耦合
Compose MultiplatformiOS 编译失败、Kotlin/Native 缓存与 Xcode、Kotlin/Native、Gradle 强耦合
React NativeMetro 端口占用、Node 版本与 Node 生态、端口、平台工具链耦合
FlutterPATH 未配置、许可证未接受与 SDK 路径、Android 许可证耦合

深刻感知:错误类型的分布,就是框架耦合度的地图。Gradle 同步失败说明 Compose 与 JVM 生态强耦合;Preview 崩溃说明 SwiftUI 与 Xcode 版本强耦合;Metro 端口占用说明 React Native 与 Node 生态强耦合。理解耦合点,就能预判问题高发区。

15.6 感知六:版本敏感项,暴露了框架的演进速度

六个框架在本课版本基线中的敏感项:

框架版本敏感项演进速度
Jetpack ComposecompileSdk 更新为 API 37,要求 AGP 9.1.1+快,与 Android 平台节奏同步
SwiftUIXcode 26 要求 macOS 15.6+,Xcode 27 要求 M1+中,与 Apple 年度发布节奏同步
ArkUISDK 6.0.2(22) 配套 DevEco 6.0.2中,与鸿蒙版本节奏同步
Compose Multiplatform1.12.0 不再支持 iosX64快,Kotlin 生态迭代迅速
React Native0.87 强制 Node.js 22.13+,Strict TypeScript快,社区驱动迭代
Flutter3.41.7 历经 7 个补丁快,但补丁版本趋于稳定

深刻感知:版本敏感项是框架演进速度的晴雨表。Compose 和 React Native 的版本敏感项最多,说明它们迭代最快;SwiftUI 和 ArkUI 与平台年度节奏同步,相对稳定;Flutter 通过补丁版本收敛问题,稳定性逐步提升。选型时,版本敏感项多的框架需要更强的版本管理能力。

15.7 感知七:预览与热重载的差异,体现了开发体验的优先级

六个框架的预览与热重载能力对比:

框架预览方式热重载状态保持开发体验优先级
Jetpack ComposeCompose Preview部分保持高,但受 Gradle 构建速度影响
SwiftUICanvas / Preview通常保持高,但 Xcode 27 预览稳定性下降
ArkUIPreviewer通常不保持中,依赖重新编译
Compose MultiplatformCompose Preview部分保持中,iOS 端预览能力有限
React NativeFast Refresh尽量保持高,Metro 0.87 性能显著提升
FlutterHot Reload保持 State最高,Hot Reload 是核心卖点

深刻感知:预览与热重载的优先级,反映了框架对“开发反馈循环”的重视程度。Flutter 把 Hot Reload 作为核心卖点,React Native 持续优化 Fast Refresh,Compose 和 SwiftUI 都在强化预览能力。反馈循环越短,开发效率越高;但反馈循环的稳定性,比速度更重要。

15.8 感知八:系统限制,揭示了框架的平台策略

本课中最重要的系统限制是:Windows / Linux 无法完整构建 iOS 原生工程。

框架能否在 Windows 上完整开发平台策略含义
Jetpack Compose可以(Android)Android 原生,跨平台友好
SwiftUI不可以(必须 macOS)Apple 生态封闭,绑定 macOS
ArkUI可以(Windows 支持良好)鸿蒙生态,Windows 优先
Compose Multiplatform部分(Android / Desktop 可,iOS 不可)Kotlin 跨端,iOS 仍需 macOS
React Native部分(Android 可,iOS 需 macOS)JS 跨端,iOS 仍需 macOS
Flutter部分(Android 可,iOS 需 macOS)Dart 跨端,iOS 仍需 macOS

深刻感知:系统限制是平台策略的直接体现。Apple 通过 macOS 限制维持生态封闭性;Android 和鸿蒙对 Windows 友好;所有跨端框架在 iOS 构建上都无法绕开 macOS。选择跨端框架,不能绕开平台策略的限制。

15.9 感知九:从环境搭建看框架的“第一印象”差异

六个框架给开发者的第一印象差异极大:

框架第一印象原因
Jetpack Compose工程化、配置多Gradle + BOM + 编译器插件
SwiftUI优雅、一体化Xcode 全家桶 + 声明式语法
ArkUI类前端、装饰器多ArkTS + 装饰器体系
Compose Multiplatform复杂但强大KMP + source set + 多目标
React Native熟悉、工具分散React 语法 + 命令行工具链
Flutter统一、CLI 友好Flutter CLI + Widget 树

深刻感知:第一印象决定了学习曲线。Compose 的工程化配置让 Android 开发者熟悉但让新手畏惧;SwiftUI 的优雅让 Apple 开发者舒适但绑定平台;ArkUI 的类前端语法让 Web 开发者容易上手;Compose Multiplatform 的复杂度反映了跨端的工程代价;React Native 的熟悉感来自 React 生态;Flutter 的统一感来自自建工具链。第一印象不是好坏,而是框架定位的体现。

15.10 感知十:从环境搭建看设计空间

最后一个感知,也是最重要的:

本课虽然只做了环境搭建,但已经能看出六个框架在设计空间中的位置。

设计维度可选范围六框架的位置
语言静态 / 动态Kotlin、Swift、ArkTS、Dart 静态;TypeScript 可选静态
渲染原生 / 映射 / 自绘Compose、SwiftUI、ArkUI 原生;RN 映射;Flutter、CMP 自绘
跨端不跨 / 共享逻辑 / 共享 UI / 共享一切原生不跨;RN 共享逻辑;CMP 共享 UI;Flutter 共享一切
工具链平台集成 / 自建Apple 集成;Flutter 自建;RN 混合
状态追踪手动 / 自动RN 手动为主;Compose、SwiftUI、ArkUI 自动

深刻感知:环境搭建是设计空间的“入口体验”。Compose 的 Gradle 配置反映了它与 JVM 生态的绑定;SwiftUI 的 Xcode 一体化反映了 Apple 的生态封闭;Flutter 的 CLI 统一反映了自绘路线的独立性;React Native 的工具链分散反映了它“桥接两端”的定位。通过环境搭建,你已经在体验框架的设计哲学。

15.11 十个感知总览

感知核心观点
感知一入口代码的差异,暴露了框架的设计哲学
感知二环境搭建的步骤数量,反映了框架的工具链抽象程度
感知三检查命令的差异,映射了平台工具链的历史
感知四构建工具的差异,揭示了框架的底层架构
感知五错误类型的分布,反映了框架的耦合度
感知六版本敏感项,暴露了框架的演进速度
感知七预览与热重载的差异,体现了开发体验的优先级
感知八系统限制,揭示了框架的平台策略
感知九从环境搭建看框架的“第一印象”差异
感知十从环境搭建看设计空间

这十个感知,全部来自本课的实际比较内容。它们不是空泛的议论,而是从入口代码、环境步骤、检查命令、构建工具、错误类型、版本敏感项、预览热重载、系统限制、第一印象、设计空间十个具体角度提炼出来的。后续每一课都会回到这些感知上,用新的比较内容验证它们、丰富它们、深化它们。


下期预告

【六大移动UI框架比较学与练】第2课:工程目录结构与基础语法差异对比

Logo

开源鸿蒙跨平台开发社区汇聚开发者与厂商,共建“一次开发,多端部署”的开源生态,致力于降低跨端开发门槛,推动万物智联创新。

更多推荐