Flutter / iOS 迁移鸿蒙 ArkUI 的真实成本

子玥酱 （掘金 / 知乎 / CSDN / 简书同名）

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- [第一层成本：UI 重写](#第一层成本：UI 重写)
- - [Flutter → ArkUI](#Flutter → ArkUI)
  - [iOS → ArkUI](#iOS → ArkUI)
  - 一个真实经验
- 第二层成本：工程架构重构
- - [Flutter 项目结构](#Flutter 项目结构)
  - [鸿蒙 App 结构](#鸿蒙 App 结构)
  - [Ability 模型](#Ability 模型)
- 第三层成本：状态管理重写
- - [ArkUI 数据共享](#ArkUI 数据共享)
- 第四层成本：插件与系统能力
- - 鸿蒙系统能力
- 第五层成本：团队经验
- - Dart
  - ArkTS
- 一个真实迁移成本模型
- 如何降低迁移成本
- 一个重要结论
- 总结

引言

过去一年，很多团队都在讨论一件事：

要不要把现有 App 迁移到鸿蒙？

尤其是已经有成熟产品的团队，比如：

原生 iOS
Android
Flutter
React Native

很多决策层的第一反应通常是：

"迁移成本大不大？"

很多人会简单地回答一句：

UI 要重写
技术栈不同

但如果你真的做过迁移项目就会知道：

真正的成本，远远不止 UI。

从工程结构到开发模式，再到团队经验，
迁移鸿蒙 ArkUI，本质是一次架构级变化。

第一层成本：UI 重写

这是所有人第一时间想到的成本。

Flutter → ArkUI

Flutter UI 是：

dart 复制代码

Scaffold(
  appBar: AppBar(title: Text('订单')),
  body: ListView.builder(
    itemCount: orders.length,
    itemBuilder: (context, index) {
      return ListTile(
        title: Text(orders[index].title),
      );
    },
  ),
);

ArkUI 写法：

ts 复制代码

@Entry
@Component
struct OrderPage {
  @State orders: Order[] = []

  build() {
    Column() {
      List() {
        ForEach(this.orders, (item: Order) => {
          ListItem() {
            Text(item.title)
          }
        })
      }
    }
  }
}

虽然都是声明式 UI，但有三个明显差异：

组件模型不同
状态机制不同
生命周期不同

所以 UI 基本无法复用。

iOS → ArkUI

iOS SwiftUI：

swift 复制代码

List(orders) { order in
    Text(order.title)
}

ArkUI：

ts 复制代码

List() {
  ForEach(this.orders, (item: Order) => {
    ListItem() {
      Text(item.title)
    }
  })
}

语法很像，但：

SwiftUI 生命周期
ArkUI 状态驱动
路由体系

仍然需要重构。

一个真实经验

很多团队最开始会以为：

"UI 迁移最多两个月。"

但实际情况往往是：

UI 重写只占迁移成本的 30% 左右。

真正复杂的在后面。

第二层成本：工程架构重构

Flutter / iOS 的工程结构，和鸿蒙完全不同。

Flutter 项目结构

复制代码

lib/
  pages/
  widgets/
  services/
  models/

逻辑非常简单。

鸿蒙 App 结构

鸿蒙应用通常是：

复制代码

entry/
  src/
    main/
      ets/
        pages/
        components/
        services/
        models/

但更关键的是：

鸿蒙是 Ability 架构。

Ability 模型

ts 复制代码

import UIAbility from '@ohos.app.ability.UIAbility'

export default class EntryAbility extends UIAbility {
  onCreate() {
    console.log('App started')
  }
}

这里意味着：

生命周期不同
页面管理不同
系统能力调用不同

很多 Flutter 开发者第一次接触 Ability 时都会懵。

第三层成本：状态管理重写

Flutter 常见方案：

Provider
Riverpod
Bloc
GetX

示例：

dart 复制代码

class CounterProvider extends ChangeNotifier {
  int count = 0;

  void increment() {
    count++;
    notifyListeners();
  }
}

ArkUI 的状态机制是：

ts 复制代码

@State count: number = 0

Button('增加')
  .onClick(() => {
    this.count++
  })

但真正复杂的是跨组件状态。

ArkUI 数据共享

ts 复制代码

@Provide counter: number = 0

子组件：

ts 复制代码

@Consume counter: number

这套机制和 Flutter 完全不同，迁移意味着：

所有状态管理逻辑都要重写。

第四层成本：插件与系统能力

Flutter 项目通常依赖大量插件。

例如：

camera
location
push
analytics

示例：

dart 复制代码

CameraController(camera, ResolutionPreset.medium)

迁移鸿蒙后：这些插件很多都不存在，必须调用系统能力。

鸿蒙系统能力

例如相机：

ts 复制代码

import camera from '@ohos.multimedia.camera'

let cameras = await camera.getCameras()

定位：

ts 复制代码

import geolocation from '@ohos.geoLocation'

geolocation.getCurrentLocation()

问题在于：

很多 Flutter 插件逻辑需要重新封装。

这部分往往是最大成本之一。

第五层成本：团队经验

技术迁移最容易被忽略的一点是：

团队学习成本。

例如 ArkTS。

Dart

dart 复制代码

var name = 'Flutter'

ArkTS

ts 复制代码

let name: string = 'Harmony'

看起来很像 TypeScript，但鸿蒙开发还涉及：

DevEco Studio
Ability 生命周期
分布式能力
权限模型

团队从零熟悉这些，通常需要：

1-3 个月。

一个真实迁移成本模型

如果是一个中型 App，假设：

20 个页面
10 个核心模块
15 个插件依赖

迁移成本大概是：

项目	成本占比
UI 重写	30%
工程结构调整	20%
状态管理迁移	15%
插件重写	25%
团队学习	10%

如何降低迁移成本

真正有经验的团队通常不会"全量重写"，而是采用渐进迁移。

第一阶段：核心模块迁移

只迁移：

登录
首页
核心业务

其余继续保留原 App。

第二阶段：能力封装

把业务能力抽象为服务：

ts 复制代码

export class OrderService {
  async queryOrders() {
    return http.get('/orders')
  }
}

这样 UI 重写时逻辑不会动。

第三阶段：组件复用

建立组件库：

复制代码

components/
  CommonList
  Card
  Button

统一 UI 逻辑。

一个重要结论

很多人问：

鸿蒙迁移值不值得？

答案其实不在技术，而在产品战略，如果你的 App 需要：

全场景设备
分布式协同
系统级能力

那么迁移鸿蒙会带来新机会，但如果只是一个普通移动 App：

迁移更多是成本，而不是收益。

总结

Flutter / iOS 迁移鸿蒙 ArkUI 的真实成本，并不只是 UI 重写。

真正的成本来自五个方面：

UI 重写
工程架构调整
状态管理迁移
插件与系统能力重构
团队学习成本

所以迁移鸿蒙，本质上不是一次"代码迁移"，而是：

一次技术栈与工程模式的重构。

理解这一点，你才能真正评估迁移决策。