企业官网建设流程全解析

我去年接了一个双端项目——既有Jetpack Compose写的Android端，又有HarmonyOS的ArkUI版本。一开始我想着："都是声明式编程，Compose和ArkUI应该差不多。"结果真正写起来才发现，UI描述方式的相似只是表象，单是"状态管理"这一块，两边的认知模型就差了不止一个层级。

这篇就专门聊聊Compose和HarmonyOS ArkUI状态管理的对比。这个话题对两种人都适用：一是准备从零接触HarmonyOS的Android开发者，想拿Compose的经验去映射ArkUI；二是已经在鸿蒙上写了一阵子，被各种装饰器搞晕，想知道ArkUI这套设计到底在解决什么问题。我会从底层机制讲起，再给代码级对照，最后分享实际迁移中踩过的大坑。

1. 同时维护双端项目时才看清的事：两套框架的状态管理哲学差异

1.1 从一个小问题开始的对比

有次我在写一个"点赞按钮"，Android端代码大概是：

@Composable fun LikeButton(post: Post, onLikeChange: (Boolean) -> Unit) { var liked by remember { mutableStateOf(false) } Button(onClick = { liked = !liked onLikeChange(liked) }) { Text(if (liked) "已赞" else "点赞") } }

放到ArkUI里就成了：

@Component struct LikeButton { @Prop post: Post; @State liked: boolean = false; build() { Button() { Text(this.liked ? "已赞" : "点赞") }.onClick(() => { this.liked = !this.liked; this.onLikeChange?.(this.liked); }) } }

代码长得挺像，但两者的行为逻辑完全不一样。Compose里你写var liked by remember { mutableStateOf(false) }，"remember"是给状态一个存储容器，真正驱动UI更新的是mutableStateOf这个可观察状态；而ArkUI里，@State本身就是系统级的"状态声明"，框架会拦截对它的赋值并触发该组件所属的刷新。一个是"我主动把数据放进可观察容器"，另一个是"我告诉框架这个变量是我的状态，你来管"。

这种差异背后是两套框架的定位问题。

1.2 前提：两个框架的真正定位

Compose不是一个完整的应用框架，它是Android的UI Toolkit，是Jetpack家族的一员。它的状态管理方案是把状态建模的主动权交给你——你可以用mutableStateOf、StateFlow、ViewModel、甚至第三方库，Compose只负责在状态可观察的前提下做重组。这是"组合优于继承"思想的延续：UI层面框架帮你管，业务状态层面依旧是自由市场。

HarmonyOS的ArkUI（尤其是API 12+的HarmonyOS NEXT版本）则更像是把"声明式UI+应用模型+状态管理"打包成一套整体解决方案。它有完整的Application/UIContext模型、页面路由模型，以及一套装饰器体系来覆盖状态管理的各种场景。框架层面做了更多约束和兜底，开发者选择的自由度小了，但不容易写坏。

这直接导致了一个结果：你在Compose里养成的很多习惯（比如把状态散落在各种remember里、依赖ViewModel做页面级共享），在HarmonyOS里会遇到非常多的框架限制；反之，ArkUI里那些"开箱即用"的装饰器，在Compose里又找不到直接对应物。

1.3 从"状态提升"到"装饰器层级"：核心理念面对面

Compose官方一直强调状态提升：状态尽量放在父级/顶层，通过参数下传，通过回调上抛。比如上面的点赞按钮，更规范的写法是把liked提升到父组件，按钮只负责展示和回调。

而ArkUI把这套思路形式化成了装饰器体系：@State（组件私有）、@Prop（父传子单向同步）、@Link（父子双向同步）、@Provide/@Consume（跨层级共享）、@StorageLink/@StorageProp（应用级共享），每一个装饰器都定义了明确的作用域和同步方向。

说人话就是：Compose用"约定"约束你，ArkUI用"语法"约束你。前者写起来自由，但项目一大很容易失控；后者写起来受约束，但框架能在编译期和运行时检查出不少问题。我个人双端写下来感觉，小Demo区别不大，一旦涉及页面栈、多模块、状态跨层传递，ArkUI的装饰器体系反而让分层更清晰。

2. 底层机制对比：快照广播与装饰器定向刷新

2.1 Compose的状态快照机制

Compose的状态更新依赖一个叫Snapshot的系统。简单说，mutableStateOf创建的值会被快照系统跟踪，任何地方修改它，Compose会记录这次修改，并在下一帧开始时通知所有读取过该状态的组合函数，让它们重新执行——这个流程叫重组。

这里有个关键机制：Compose不是"任何状态变化都全局刷新"，而是依赖读取跟踪。只有真正在组合函数里读过这个状态值的代码，才会被标记为需要重组；没读过的地方不受影响。所以你可以把Compose理解为"版本号全局广播+按需订阅"的混合体：状态是全局可观察的，但重组范围被精确控制。

另一个特征是快照对协程和异步友好。你在协程里改状态、在回调里改状态、在普通函数里改状态，都不需要额外通知UI，Compose的重组是自动的。这极大简化了异步状态更新的编码。比如一个WebSocket推送的在线人数，回调线程里直接改mutableStateOf，界面自动刷新，不需要像传统View系统那样post到主线程，也不需要手动notifyDataSetChanged。

2.2 ArkUI的装饰器模型与V1/V2演进

ArkUI的状态管理可以粗暴分成两个时代。V1时代（API 9-11）以@State、@Prop、@Link、@Provide等装饰器为核心，状态对象一旦通过@Observed装饰，属性的修改会被框架感知并驱动相关组件更新。V2时代（API 12+，也就是HarmonyOS NEXT的主流方案）引入了@ObservedV2和@Trace，这套模型更接近"精细粒度的属性级依赖追踪"——谁读了哪个属性，框架就精准刷新用到该属性的组件。

ArkUI的刷新机制和Compose最大区别在于：ArkUI是在组件树上按"状态声明的作用域"来刷新的。比如@State触发的刷新范围是该组件自身；@Prop是子组件接收父组件状态变化；@Link是父子双向绑定后的双向更新；全局状态通过AppStorage等统一管理。它本质上是一套"按装饰器声明的依赖关系定向通知"的机制，而不是像Compose那样完全靠运行时追踪读取关系。

打个生活化比方：Compose像是一个大办公室里广播"某个文件改了"，只有一直在看那个文件的人才应答；ArkUI则是每张办公桌上挂了清晰的"依赖清单表"，文件一改，系统按清单挨个通知。前者运行时灵活，后者声明期就可预测。

2.3 两种机制的边界条件差异

快照机制让Compose在处理嵌套数据结构、集合变更时比较省心——你改一个列表项的某个属性，只要读取链完整，UI会自动局部刷新。但这也是Compose的坑：如果你在列表项里读取了完整对象而不是具体字段，或者把大对象塞进remember，很可能会出现"状态变了但UI没变"或者"一个属性变化引发大范围重组"的奇怪问题。

ArkUI的V2机制更强调"把状态声明做细"。例如对象里的某个字段想被观察，V2要求你在类属性上用@Trace，否则这个字段的修改不会触发更新。看起来多写代码，但性能模型非常清晰——每一个能触发UI变化的点都是显式的。代价是状态对象稍微复杂一点，装饰器就写到手酸。从Compose切过来的朋友，最容易不适应的是"怎么连字段更新都要声明一下"，但一旦接受这个设定，排查状态BUG的时间会大幅下降。

2.4 状态读取与更新的线程约束差异

Compose对状态更新的线程约束极低，快照系统允许你在任意线程修改状态值，重组调度会帮你切回UI线程执行。但要注意，Compose官方依然推荐在主线程做状态写入，尤其涉及集合类状态时，并发写容易产生不可预期的快照冲突。

ArkUI则不同，装饰器管理的状态在赋值时有明确的主线程要求，因为UI刷新机制直接依赖ArkUI引擎的UI线程任务队列。后台线程直接改@State变量，轻则刷新不生效，重则报错。正确做法是后台任务通过任务分发切回UI线程再写状态，或者用AppStorage配合支持跨线程写入的接口。这里没有谁更好的问题，只是Compose的宽松容易让新手忽视线程安全，ArkUI的严格反而能逼你提前设计好线程边界。

3. 常用状态API对照：代码级迁移参考

为了让大家能直接抄作业，我整理了一张最常用的对照表。这里的对照不是一一对等，而是"功能对应"关系——两边都有对应的替代方案。

3.1 组件本地状态：remember vs @State

先看最基础的remember。Compose的remember { mutableStateOf(x) }有两大特性：一是变量在重组时保留；二是只有被mutableStateOf包裹的值才有"可观察性"，普通变量变了Compose不会感知。很多刚上手的朋友会写remember { x }，然后发现界面不更新，原因就在这里。

ArkUI的@State则直接把"可观察性"和"生命周期"绑在一个关键字上：被@State修饰的变量，赋值后自动触发组件刷新，组件销毁时状态随之销毁。注意@State不支持内部属性级别的观察，对象里的嵌套属性变了不会刷新。比如@State user: User，执行this.user.name = "x"，UI不会变；必须整体重新赋值this.user = newUser，或者配合@Observed/@ObjectLink（V1）/@Trace（V2）实现嵌套观察。

3.2 页面级状态共享：ViewModel vs AppStorage/LocalStorage

Android生态里页面级共享首选ViewModel，它天然具备生命周期解耦和配置变更保留的能力。Compose里配合ViewModel，状态写在一个StateFlow或者mutableStateOf里，页面销毁时自动清理。

HarmonyOS侧的替代是LocalStorage（页面级）和AppStorage（应用级）。LocalStorage是页面内共享的存储单元，通过@LocalStorageProp或@StorageLink把UI状态绑定上去；AppStorage则是全局单例，跨页面跨组件都能访问，配合PersistentStorage还能做持久化。

从设计哲学看，ViewModel是"业务逻辑容器"，你可以在里面处理网络请求、状态合并；而AppStorage更像"跨组件共享数据的仓库"。HarmonyOS实现类似倒计时、登录态这类全局数据用AppStorage很顺手，但把网络请求逻辑也塞进AppStorage就违背了它的设计意图——请务必将业务逻辑保持在服务层/Repository层，AppStorage只做状态存储。

3.3 组合业务状态与副作用处理

Compose的derivedStateOf用于派生状态，比如根据列表长度算进度条百分比；ArkUI V2对应可以靠@Computed来实现，或者直接用getter配合状态引用。SideEffect、LaunchedEffect在ArkUI里对应的是onPageShow/onAppear等生命周期方法，加@Watch（V1）或新的监听机制在V2监听@Trace字段变化。

这里尤其要提一个很容易错的点：Compose里你想要"某个属性变化时做点副作用"，常用LaunchedEffect(key)或SideEffect；而ArkUI的习惯是在字段上用@Watch接一个回调。两者表面功能类似，但触发时机差异很大：@Watch在赋值后同步触发，而LaunchedEffect在组合进入时触发、key变化时重新执行。如果迁移时直接把@Watch当LaunchedEffect用，可能会出现"状态更新与UI刷新顺序不符"的诡异问题。

4. 从Compose迁到HarmonyOS，最容易踩的四个思维坑

4.1 remember的作用域依赖规则

Compose的remember绑定的是"组合树中的位置"，组件重组时该位置的变量值会保留。而且remember支持传keys：remember(x) { mutableStateOf(y) }，当keys变化时重新计算初始值。这给了开发者精确控制状态重置时机的能力。

ArkUI的@State没有"keys"的概念，它就是一个绑定在该组件实例上的状态。你没法通过参数列表让@State在特定条件变化时重置。如果你习惯了靠remember的keys做"当数据源变化时重置本地状态"，在ArkUI里对应方案是：要么把状态提升到父组件由父组件传参控制，要么用@Watch监听父传参数变化然后手动重置。我第一次迁移时，把一个"根据当前用户重新加载草稿"的remember逻辑直接翻译成@State，结果用户切换后旧数据显示了很久，排查半天才发现是@State没有重置机制。

4.2 事件回调里读取"最新状态"的差异

这是我从Compose迁到ArkUI时踩得最疼的一坑。Compose标准做法是用rememberUpdatedState保住"事件回调中读取最新状态"的能力：

val currentValue by rememberUpdatedState(latestValue) LaunchedEffect(Unit) { while (true) { delay(1000) doSomethingWith(currentValue) // 永远是最新值 } }

ArkUI里没有这个等价物，你在组件的方法里直接this.liked拿到的就是当前实例的最新值——因为ArkUI组件方法天然绑定实例。这看起来是"ArkUI更简单"，但实际上它隐藏了一个问题：如果某个异步任务在页面A启动，期间状态在页面B被修改，而任务回调又带回了旧数据，直接赋值给this.liked会把新状态覆盖掉。所以跨异步链路读取或写入全局状态时，务必从AppStorage等全局存储取，不要依赖组件实例字段。

4.3 生命周期与页面重建：rememberSaveable vs @StorageLink

Android进程被杀后Activity会重建，Compose用rememberSaveable保存进入系统的状态，系统自动恢复；ArkUI页面栈重建的时机和策略不同，页面恢复主要依赖两种方式：一是LocalStorage/AppStorage这类贯穿页面和应用的存储，二是系统路由参数。

我开始迁移时犯过一个错误：页面A传了一个Object给页面B，页面B把它当作组件的@State，系统销毁B再恢复时传参已经丢了，界面出现空白。正确做法是：关键数据放进AppStorage或者持久化存储，页面传参只传id/索引这类轻量信息，再通过id去全局存储找完整数据。这个思路和Compose官方建议"导航参数只传id"其实是一致的，但在ArkUI里更容易被忽视，因为它的路由传参能力太方便了。

4.4 对"不可变数据"的执念要放下

Compose社区强调不可变数据、通过copy修改，否则重组判断容易出问题；而ArkUI的装饰器体系是建立在"对象引用+属性级追踪"之上的，V2的@Trace要求你在字段上标注，不要求你每个修改都生成新对象。所以从Compose过来的人，别把copy()的执念带过去，ArkUI直接改字段配合@Trace就能正常工作，硬套不可变模式反而让代码不伦不类。

我见过一个迁移案例：开发者在ArkUI里写this.user = this.user.copy(name = "new")，结果因为每次赋值都生成新对象，页面刷新倒是正常，但调试时发现@Watch回调被重复触发了好几轮。检查下来发现是copy导致的对象引用变化触发了多层订阅更新。后来改成直接改字段加上@Trace，问题立刻消失。在ArkUI里，理解了装饰器的作用边界，就可以放弃很多Compose时代养成的"防御式编程"习惯。

5. 复杂状态场景：列表项、跨页面同步与共享数据

5.1 列表项局部更新的正确姿势

列表是状态管理的重灾区。

Compose里LazyColumn的性能主要靠key稳定和item作用域精确。每个列表项必须有固定的key，item内部只读取自己需要的字段，避免读取整个list对象。否则只改一个点赞数，整列都会重组。我自己排查过一个问题：一个关注按钮的状态变化导致整个列表闪烁，原因就是item内部读取了完整的user对象而不是isFollowed字段。

ArkUI的LazyForEach要求给每个item提供唯一且稳定的key生成器，否则会出现项更新、删减定位混乱的问题。注意ArkUI的LazyForEach在数据刷新时有自己的一套diff逻辑，如果直接修改了@State数组里的元素并赋新数组给LazyForEach，建议在V2下使用@Trace字段级追踪，或确保每个item都是独立@Observed对象，刷新粒度才能到项级。

实测下来，两边要稳定跑出"点击一个item的按钮只局部刷新"的效果，关键都落在"让框架知道哪一项变了"。Compose靠读取追踪，ArkUI靠装饰器追踪。实现难度接近，但排查问题的方法完全不同——Compose要用Layout Inspector数重组次数，ArkUI要检查key生成器和装饰器作用域。

5.2 跨页面同步：路由参数的哲学分歧

Compose导航通常不鼓励在路由参数里塞大对象，官方推荐序列化id后再去Repository取数据，这样可以进程重建时恢复导航栈；ArkUI的路由传参天然支持对象传递，API 12之后还增强了序列化能力，这导致很多鸿蒙开发者习惯直接把整个model塞进路由参数。短期写起来爽，但状态一旦需要跨页面同步，就会面临"多个页面各自持有对象副本"的问题。

我的建议是：ArkUI也尽量传id/轻量参数，对象放AppStorage通过唯一key索引，跨页面同步时天然就是同一个引用。比如一个详情页编辑了标题，列表页需要同步变化，如果两边持有的是同一数据源，列表页监听AppStorage的key变化即可；如果传的是独立副本，你还得折腾事件通知。这本质上不是框架能力问题，而是"单例数据源"和"副本数据源"的架构选择问题，和Android端用"仓库模式"保证数据唯一来源是同一个道理。

5.3 单向数据流的落地形态

Compose的单向数据流靠参数下传+回调上抛实现，你会在组件的参数列表里看到一堆lambda：onClick、onValueChange、onDelete，父子关系一目了然。ArkUI实现同样思路可以这样设计：页面级持有@State，子组件纯展示用@Prop，需要回传事件通过自定义事件回调。

注意ArkUI里$$绑定符很容易让新手写出双向绑定的写法，例如TextInput({ text: $$this.value })，这种写法在Compose里几乎是被教育的反面典型。实际项目里我建议少用$$，尽量手动管理事件回调，可读性和可维护性更好。双端并行维护时，如果一边用lambda回调、一边用双向绑定，心智负担会很大；我后来统一成"Compose回调上抛、ArkUI自定义事件上抛"的写法，两边代码结构高度相似，维护起来轻松很多。

6. 性能陷阱与调试思路：状态膨胀的两种表现

6.1 无谓重组的典型来源

Compose性能问题多数出在两个地方：一是在组合函数里创建不稳定的lambda，导致参数比较失败触发重组；二是把大对象当状态读，一个字段变化整个对象的使用方全重组。排查方法是用Layout Inspector的Recomposition Counts看组件的重组次数，快速定位到高频重组的组件。

ArkUI的典型性能问题则往往出现在装饰器用得太大太粗：把整个页面级数据用@Link往子组件传，子组件一改，整个子树的刷新范围全都动起来。V2时代的排查思路就清晰多了——凡是使用了@Trace的字段就是被追踪的，追踪面越小性能越好。养成"尽量缩小状态作用域"的习惯对两边都适用，只是ArkUI可以通过装饰器的选择直接控制作用域，而Compose需要你刻意控制读取范围。

6.2 调试观察方法

Compose调试状态更新主要靠Layout Inspector看重组，也可以给Composable函数加日志看执行时机。ArkUI更直接——在DevEco Studio里可以看到组件树的刷新标记，@State的值变化时，刷新范围会高亮。这比纯看日志方便太多。

另外两边都支持在自定义状态对象的setter里埋点，但ArkUI的装饰器是编译器处理的，直接改运行时字段并不会触发setter日志，调试时要注意观察对象是普通类还是@Observed类。V2的@Trace在DevEco上有专门的属性依赖追踪面板，可以直接看某个字段被哪些组件读取，这个能力Compose目前还没有完全对等的可视化工具，更多是靠代码审查发现问题。

6.3 组合抽象与逻辑复用上的取舍

最后聊一个容易被忽略的层面：状态管理不只是"变量放哪，怎么改"，更影响你如何组织业务逻辑。Compose允许你把状态逻辑写进普通函数、封装成自定义Composable甚至自定义State类，模式非常多；ArkUI则建议把"页面逻辑"剥离到普通类/Service中，UI组件里尽量只保留表现层状态。

在双端并行项目里，理想做法是核心业务状态与领域逻辑下沉到跨端可复用的纯TS/纯Kotlin层，UI状态管理各按框架规范来。例如"购物车结算逻辑"这类核心业务，两端各写一份很容易出现规则漂移；但UI层的"购物车列表折叠状态""选中项高亮"这种表现层状态，就该完全交给各框架。我目前维护的双端项目，业务层代码已经能做到六成以上共用，状态管理只留在UI壳层，维护成本比早期"UI和业务混在一起写"低了太多。

我个人双端跑了一年多的体会是：真想理解对方框架的状态管理，最快的方式不是背API，而是去理解"状态产生后，谁在跟踪它、跟踪到什么粒度、谁负责通知UI"。Compose把这个权力和责任都给了运行时和你；ArkUI把它放到了编译器和装饰器声明里。没有谁绝对更好，Compose更灵活，适合喜欢自己掌控节奏的团队；ArkUI更规范，适合需要强约束、降低新人试错成本的项目。

如果你正准备拿Compose的经验入门鸿蒙，建议先把remember、mutableStateOf、ViewModel这套东西和@State、@Prop、AppStorage一一对应起来，再用一个"点赞按钮+列表页+跨页面登录态"的小项目做迁移练习。这样走一遍，你大概率能避开我自己踩过的那些坑。