我去年接了一个双端项目——既有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理解为版本号全局广播按需订阅的混合体状态是全局可观察的但重组范围被精确控制。另一个特征是快照对协程和异步友好。你在协程里改状态、在回调里改状态、在普通函数里改状态都不需要额外通知UICompose的重组是自动的。这极大简化了异步状态更新的编码。比如一个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对照代码级迁移参考为了让大家能直接抄作业我整理了一张最常用的对照表。这里的对照不是一一对等而是功能对应关系——两边都有对应的替代方案。场景ComposeArkUI组件内可变状态remember { mutableStateOf(x) }State x: T父传子单向值普通函数参数Prop父子双向同步参数回调Link跨层级共享CompositionLocal / ViewModelProvide / Consume应用级/页面级共享ViewModel / SingletonAppStorage / LocalStorage保存进程被杀后的状态rememberSaveableStorageLink / PersistentStorage计算/派生状态derivedStateOfComputed 或 getter 手动计算异步副作用LaunchedEffect / SideEffectonPageShow / onAppear / Watch3.1 组件本地状态remember vs State先看最基础的remember。Compose的remember { mutableStateOf(x) }有两大特性一是变量在重组时保留二是只有被mutableStateOf包裹的值才有可观察性普通变量变了Compose不会感知。很多刚上手的朋友会写remember { x }然后发现界面不更新原因就在这里。ArkUI的State则直接把可观察性和生命周期绑在一个关键字上被State修饰的变量赋值后自动触发组件刷新组件销毁时状态随之销毁。注意State不支持内部属性级别的观察对象里的嵌套属性变了不会刷新。比如State user: User执行this.user.name xUI不会变必须整体重新赋值this.user newUser或者配合Observed/ObjectLinkV1/TraceV2实现嵌套观察。3.2 页面级状态共享ViewModel vs AppStorage/LocalStorageAndroid生态里页面级共享首选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等生命周期方法加WatchV1或新的监听机制在V2监听Trace字段变化。这里尤其要提一个很容易错的点Compose里你想要某个属性变化时做点副作用常用LaunchedEffect(key)或SideEffect而ArkUI的习惯是在字段上用Watch接一个回调。两者表面功能类似但触发时机差异很大Watch在赋值后同步触发而LaunchedEffect在组合进入时触发、key变化时重新执行。如果迁移时直接把Watch当LaunchedEffect用可能会出现状态更新与UI刷新顺序不符的诡异问题。4. 从Compose迁到HarmonyOS最容易踩的四个思维坑4.1 remember的作用域依赖规则Compose的remember绑定的是组合树中的位置组件重组时该位置的变量值会保留。而且remember支持传keysremember(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 StorageLinkAndroid进程被杀后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作用域精确。每个列表项必须有固定的keyitem内部只读取自己需要的字段避免读取整个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的单向数据流靠参数下传回调上抛实现你会在组件的参数列表里看到一堆lambdaonClick、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一一对应起来再用一个点赞按钮列表页跨页面登录态的小项目做迁移练习。这样走一遍你大概率能避开我自己踩过的那些坑。