很多做安卓的朋友最近都在聊一句话：安卓开发的天花板不只是安卓本身。尤其是这两年，鸿蒙生态起来之后，招聘需求里开始频繁出现“鸿蒙开发经验优先”，另一边 Kotlin Multiplatform（KMP）也借着跨平台复用的风口，成了中高级岗位面试里的高频话题。再加上项目复杂度上来以后，架构优化从“加分项”变成了“生存项”，再不看就真的跟不上了。
这篇东西写给谁呢？给那些已经能独立完成 App 开发、但还想往上走一步的安卓工程师。你不需要已经写过鸿蒙，也不需要背过 KMP 的底层原理，但最好有一定的 Java/Kotlin 基础和对 Android 四大组件的熟悉度。我会把鸿蒙迁移、KMP 跨平台、架构演进这三条路分别拆开讲，每一条都会聊到核心概念、实操步骤和踩坑经验，最后再整理一份排查手册。看完之后，你应该能对自己的进阶路线有一个更清晰的判断。
1. 进阶方向选择：先想清楚要往哪走
1.1 安卓工程师的三条进阶路径
安卓这个领域发展到今天，单纯“会写界面、会调接口”已经不太够用了。所谓进阶，在我看来其实是三条路：往系统底层走，往跨平台走，往架构和工程质量走。三条路没有绝对的好坏之分，但对应的技能栈、面试侧重和日常工作量完全不一样。
往系统底层走，意味着你要花大量时间在 Framework、AMS/WMS、Binder、Handler 消息机制这些东西上，还要能看懂 AOSP 源码，能用 Perfetto 抓 trace 做性能分析。这条路的护城河很深，因为真的愿意沉下心读源码的人不多，一旦读透，处理疑难 Bug 的效率和普通开发完全不在一个水平。往跨平台走，则是把视野从单端拉到多端，KMP、Flutter、Compose Multiplatform 这些技术能把业务逻辑在安卓、iOS、鸿蒙之间复用，减少重复开发。这条路更看重抽象能力——能不能把平台差异点隔离好，决定你的复用率是 70% 还是 20%。
架构优化这条路则更像“内功修炼”，不管是 MVP、MVVM 还是 MVI，不管是模块化还是组件化，不管是启动速度还是卡顿优化，都属于这一类。它不要求你学一套全新的 API，而是要求你把已有的工程组织方式、编译方式、运行性能重新审视一遍。现实情况是，大多数工作三年左右的安卓工程师，都会同时踩到后两条路——因为跨平台方案要落地，必然涉及分层架构设计；而架构做得不好，跨平台代码就容易变成一团乱麻。
1.2 为什么是鸿蒙、KMP 和架构优化这三个关键词
我之所以把这三件事放在一起说，是因为它们在时间线上几乎是同时发生的。安卓开发者的能力模型正在从“单端业务开发”变成“多端业务抽象+系统级性能调优”，而鸿蒙、KMP 和架构优化恰好对应了这个新模型的三个支点。
鸿蒙解决的是“端”的问题。华为手机的量在那里，鸿蒙生态的设备量也在快速增长，从手机到平板、车机再到智能家居，一套代码可以触达更多设备。对我们开发者来说，这不是“要不要做”的问题，而是“什么时候做”的问题。KMP 解决的是“复用”的问题。如果鸿蒙、安卓、iOS 三端都要维护一套业务代码，人力成本是翻倍的，KMP 让共享逻辑成为可能，恰好补上了跨端复用的缺口。架构优化解决的是“质量”的问题。多端复用之后，代码的复杂度会指数级上升，如果没有清晰的分层和合理的依赖方向，团队协作效率会迅速恶化。
所以这三件事不是三个独立的学习任务，它们是一条链路：鸿蒙带来新端，KMP 提供跨端复用手段，架构优化保证复用过程不乱。理解这条链路，比单独去刷某一个技术的面试题要重要得多。
2. 鸿蒙开发：从安卓迁移过来的关键路径
2.1 先分清鸿蒙的几个概念
很多人听到“鸿蒙”就以为是一套东西，其实这里面的概念至少要拆成三层：OpenHarmony（开源鸿蒙）、HarmonyOS（华为商用系统）和 HarmonyOS NEXT（不再兼容安卓应用的纯血鸿蒙）。
OpenHarmony 是开源底座，任何厂商都可以基于它做自己的发行版，就像 AOSP 和各家安卓 ROM 的关系。HarmonyOS 是华为基于 OpenHarmony 加了自己的商业能力（比如 HMS Core、畅连等）之后发布的操作系统。HarmonyOS NEXT 则是 2024 年以后主推的方向，它砍掉了对安卓 APK 的兼容，只支持鸿蒙原生应用。如果你是刚入门的开发者，记住一句话：未来的主要赛道是 HarmonyOS NEXT，因为纯血鸿蒙的 App 生态还在建设期，现在进场能吃到窗口期红利。
这套关系和安卓很不一样。在安卓世界，Google 开源 AOSP，各家厂商做 ROM，但底层开发模式和 API 基本上是统一的。鸿蒙这边，你写的代码是不是能跑在 OpenHarmony 上，能不能跑在 HarmonyOS NEXT 上，API 的版本差异有多大，都需要在实际开发中去验证。我见过不少朋友一开始没搞懂这些概念，在 OpenHarmony 的源码上纠结了半天，结果发现自己要做的其实是基于 HarmonyOS NEXT 的元服务开发，方向完全跑偏了。
2.2 ArkTS 语言和 ArkUI 声明式范式
鸿蒙应用开发的核心语言是 ArkTS，它是 TypeScript 的超集，但加了严格的静态类型限制。如果你写过 Angular 或者 Vue 的 TypeScript 工程，上手 ArkTS 几乎没有门槛；如果之前只写 Java/Kotlin，则需要先适应一下 TS 的类型系统和语法糖。
ArkUI 的声明式 UI 写法，对安卓开发者来说需要一点思维转换。安卓传统上是 XML 布局加命令式代码，比如findViewById再setText；ArkUI 则是直接声明状态和 UI 的绑定关系，状态变了，UI 自动刷新。这一点和 Jetpack Compose 很像，如果你已经用过 Compose，那几乎是无痛切换。
@Entry @Component struct HomePage { @State message: string = 'Hello HarmonyOS' build() { Column() { Text(this.message) .fontSize(24) .fontWeight(FontWeight.Bold) Button('点击更新') .onClick(() => { this.message = '状态变了，UI 自动刷新' }) } .width('100%') .height('100%') .justifyContent(FlexAlign.Center) } }可以看到，界面结构就是代码里的组件树，状态用@State标记，数据变化驱动 UI 更新。这种范式的核心优势是少写大量样板代码——不用再写 Adapter、ViewHolder、RecyclerView 那套东西，列表直接ForEach渲染即可。
我实际写下来的感受是，ArkUI 的上手速度比当年从 Java 切 Kotlin 还要快，但有个坎必须认真跨过去：状态管理的粒度。在 Compose 里我们习惯了mutableStateOf，在 ArkUI 里则要理解@State、@Prop、@Link、@Provide和@Consume这几种装饰器的区别，尤其是父子组件之间的数据同步方向。很多从安卓转过来的朋友，一开始会下意识地把所有数据都放在页面级@State里，结果页面稍一大，状态更新就乱套了。建议前期就养成习惯：页面级状态用@State，跨页面共享的用AppStorage或者状态管理库，组件内部临时数据尽量不要用全局状态去扛。
2.3 Stage 模型和元服务：鸿蒙独有的应用形态
鸿蒙的 Ability 分为 FA（Feature Ability）模型和 Stage 模型，新项目直接用 Stage 模型就好了，FA 基本属于历史包袱。Stage 模型的核心特点是：每个 Ability 有独立的 UIAbility 或 ExtensionAbility，应用通过 AbilityStage 来管理生命周期，后台任务、卡片、输入法等场景都通过 ExtensionAbility 实现。
这里我特别想提一下元服务。元服务是鸿蒙生态里一个非常独特的东西，它没有传统的“安装-打开”流程，而是一种即用即走的原子化服务形态。用户通过碰一碰、扫码、语音等方式直接拉起元服务界面，用完就走，不需要下载安装。对开发者来说，元服务可以挂载在 HarmonyOS 的桌面卡片、服务中心、负一屏这些入口上。
从安卓工程师的视角理解元服务，最合适的类比是简化版 App 加 Widget 的组合。它适合做轻量场景，比如扫码开共享单车、查看实时公交、支付买单、智能家居控制等。但要注意，元服务的渲染容器和 UI 能力比完整应用要轻量，它跑在轻量级运行环境里，布局能力和 API 范围有限制，不适合承载视频编辑、大型游戏这类重场景。如果你负责的产品有大量高频轻量功能，把其中一部分拆成元服务，用户体验和用户获取成本都会有明显改善。
在实际开发中，很多产品会采用“App 向内承接低频重功能，元服务向外覆盖高频轻场景”的组合策略，这比一上来就把整个 App 改成元服务要稳得多。
2.4 面临继承与迁移：老安卓应用怎么过渡
现在大部分公司不会直接放弃安卓版，而是先做双栈并行：安卓版继续维护，鸿蒙版从核心功能开始适配，逐步拉齐。双栈并行的核心问题有两个：一是代码要不要共享，二是业务节奏怎么排优先级。
这两个问题实际上连在一起。如果纯靠两套团队各自维护，成本太高，而且特性容易不一致。所以我看到比较成功的过渡方案，都是先用 KMP 把核心业务逻辑（网络层、数据层、领域模型）下沉成共享模块，再在两端分别写 UI 层。这样鸿蒙版本从零开始，但拿到的业务逻辑是安卓版验证过的，质量有保障。
优先级方面，我建议不要一上来就覆盖全部功能，而是梳理用户路径：找到日活最高、路径最短的 3 到 5 个核心流程，先把这些流程在鸿蒙端跑通并验证稳定性，再逐步扩大覆盖范围。不要小看这个“逐步扩大”，鸿蒙端的系统服务、权限机制、后台策略和安卓有差异，很多在安卓上正常的逻辑，到鸿蒙上要重新适配，比如后台下载、长连接保活、通知栏消息等。先把核心流程做稳，比快速铺全功能要靠谱得多。
3. KMP 跨平台：让业务逻辑真正实现多端复用
3.1 KMP 到底是什么
KMP（Kotlin Multiplatform）是 JetBrains 推出的跨平台开发方案，核心思路很简单：用 Kotlin 写一套业务逻辑代码，然后编译到不同平台——JVM 字节码给安卓用，native 二进制给 iOS 用，同时也能产出 JS/Wasm 给 Web 用。UI 层不在 KMP 的强制范围内，你可以选择 Compose Multiplatform 做共享 UI，也可以各端保留原生 UI，只共享逻辑层。
很多朋友会把它和 Flutter、React Native 放在一块比较，但它们的定位不太一样。Flutter 是“UI 也要跨”，从渲染引擎到控件都是自己实现，做到了跨端一致性，代价是应用体积增大，且和原生平台能力的交互需要通过 Platform Channel。KMP 是“逻辑跨，UI 可以商量”，你不必为了跨平台而放弃原生体验，尤其是在复杂交互场景下，原生 UI 的优势依然明显。
我的判断是：如果你的团队主要技术栈是 Kotlin 或 Java，那么 KMP 的学习成本和融入成本比 Flutter 低得多，因为它不引入新的 UI 框架，也不改变你写原生界面的方式。
3.2 expect/actual：平台差异的隔离机制
KMP 能跨平台复用的，是纯粹的 Kotlin 代码——计算逻辑、数据转换、网络请求、数据库操作这些都可以共享。但每个平台总有自己独有的东西，比如安卓的 SharedPreferences、iOS 的 NSUserDefaults、各平台的文件目录路径、图片加载库。KMP 的处理方式是用expect和actual这两个关键字做声明和实现分离。
// 共享模块里声明 expect fun platformName(): String // 安卓平台实现 actual fun platformName(): String = "Android" // iOS 平台实现 actual fun platformName(): String = "iOS"规则很简单：共享代码里用expect声明一个函数、类或者属性，然后在每个平台目录下用actual给出具体实现。编译的时候，Kotlin 编译器会检查每个声明都有对应的实现，少一个就编译不过。
这个机制的含金量在哪儿？在于它把“平台差异”显式化了。以前我们的做法是写一堆if (platform == Android)的运行时判断，代码里到处都是分支，新来的人根本不知道哪些逻辑是被平台影响的。用 expect/actual 之后，差异点被明确标在代码结构里，写共享逻辑的人可以完全忽略平台差异，只需要依赖那个“约定好的接口”。这就是跨平台代码整洁度的关键。
不过实际项目里要小心一件事：expect/actual 不能滥用。每定义一个 expect，你就要在至少两个平台给出 actual 实现，维护成本是乘 2 的。所以设计共享模块的时候，先把“一定要共享”的逻辑划出来，比如数据模型、网络层、本地存储、鉴权逻辑、时间计算、格式化规则；那些平台特性很强的逻辑，比如推送、崩溃上报、生物认证，就老老实实在各自端去实现，不要强行塞进共享模块。
3.3 KMP 在安卓+鸿蒙场景下的落地技巧
KMP 对安卓工程师还有一个特别的价值：它可以作为安卓和鸿蒙之间的桥。想象一下，你有安卓端验证过的网络层、数据层，把这些逻辑用 KMP 下沉到共享模块后，鸿蒙端可以直接在 ArkTS 工程里调用这些 Kotlin 模块的能力吗？严格来说不能直接调用，ArkTS 运行时不直接兼容 Kotlin 字节码，但你可以通过两种方式打通：一种是把共享模块产出为 Framework/静态库，通过鸿蒙的 FFI 机制调用；另一种是把共享模块的业务逻辑用 ArkTS 重新实现，只借鉴 KMP 统一下来的接口定义和数据流。
实操层面我更推荐第二种思路的变体：KMP 统一了业务建模和接口语义以后，鸿蒙端用 ArkTS 去实现相同的数据层逻辑，虽然写了两遍，但至少接口是同一套，逻辑能被对照测试覆盖。当然，如果你的架构里采用了 Http 客户端和数据库层都比较薄的设计——比如数据层只是简单的 API 调用加 JSON 解析——那么这种“重写”成本并不高。真正需要避免的是在两端各自把缓存策略、重试机制、错误处理都写得不一样，那才是最失控的局面。
所以 KMP 的落地，与其纠结“代码复用了多少”，不如先追求“行为一致性定义了多清晰”。共享代码是一种方式，共享契约是更底层的目标。
4. 架构优化：让应用在复杂环境下依然稳定可控
4.1 架构演进：从 MVC 到 MVI 的思考路径
安卓架构演进到今天，MVC、MVP、MVVM、MVI 这几个词已经成了面试必问。我理解不少人会觉得架构模式只是“代码组织方式”，但其实它们背后的动力是两件事：状态管理复杂度的提升，和可测试性的要求。
最早 MVC 的问题是 Activity 既当 Controller 又当 View，代码一多，Activity 就成了几千行的上帝类。MVP 通过 Presenter 把逻辑从 View 里抽出来，但 Presenter 持有 View 引用，处理生命周期时需要格外小心。MVVM 引入了 ViewModel 和 LiveData/StateFlow，数据的单向流动更清晰，也天然支持生命周期感知。MVI 则更进一步，把状态收敛成不可变的 UiState，所有事件都化约成 Intent，用一个 Reducer 去生成新的状态。
我个人的倾向是，中小型项目直接上 MVI 会有点“杀鸡用牛刀”，因为它的概念成本和学习成本都不低；但如果你已经在做跨端共享，UI 层只是薄薄一层壳的时候，MVI 反而很合适——因为它让 UI 变成了状态的纯函数渲染，UI 自身逻辑被压缩到最少，正好符合多端 UI 差异性最大、共享价值最低的天然属性。架构模式没有绝对标准，核心是找到状态最集中的地方，然后用最适合团队认知水平的模式去管理它。
4.2 性能优化的关键方向：启动、流畅度、缓存
架构优化不仅仅是代码组织，还包括运行时表现。我认为对安卓应用最致命的三个性能问题依次是：启动速度、滑动流畅度、缓存命中率。
启动速度的优化要从两个阶段着手：Application 的onCreate里做了多少耗时操作，以及首帧之前主线程执行了哪些事务。很多团队会把各种 SDK 初始化都堆在 Application 里，逐个初始化完才进入启动流程，这样启动时间必然被拖长。推荐做法是把初始化按需加载、延迟加载、并行加载三个维度梳理一遍：不需要启动就要用的，挪到对应功能首次进入前懒加载；互相没有依赖的，放到 IO 线程并行执行；必须启动就绪的，也要用启动器之类的框架串成有向无环图来控制时序。
流畅度问题的排查手段，核心是 Systrace/Perfetto。抓 trace 后看主线程有没有长时间执行耗时任务、有没有过度绘制、有没有在滑动时频繁触发 GC。常见的坑有：直接在 Adapter 的onBindViewHolder里做文件 IO 或 JSON 解析、图片库没做内存缓存控制、列表项布局嵌套层级过深。这些都是老生常谈，但在真实项目里依然反复出现，因为大家总想着“先跑起来，性能后面再说”。
缓存优化这块我想结合一个具体案例来说：安卓缓存 RTSP 流。
4.3 结合热点：安卓缓存 RTSP 流的实现细节
有朋友问过我怎么在安卓端缓存 RTSP 流，因为这个场景在车机、安防监控类的 App 里很常见。RTSP 是一个流媒体控制协议，真正传输音视频数据走的是 RTP。安卓上直接支持 RTSP 的播放器不多，ExoPlayer 能处理 RTSP 流，但你要“缓存”它，就有两种思路：要么缓存文件，要么缓存数据分段。
最简单的做法是使用 ExoPlayer 配合自定义DataSource.Factory，在cacheDataSourceFactory里插入一个SimpleCache。这类似缓存 HLS 的流程，你需要先初始化一个Cache实例，再传给它一个CacheDataSource.Factory，设置flags允许读写缓存。要注意的是，RTSP 是直播性质的流，它不会像 HLS 那样天然分片，所以缓存策略上不能无脑全量缓存，否则内存和磁盘都会被拖垮。实操经验是只缓存最近 N 秒的数据，或者干脆在直播场景下只做“缓冲不落盘”，在回放场景下才开启完整文件缓存。
val cache = SimpleCache(cacheDir, LeastRecentlyUsedCacheEvictor(maxCacheSize)) val dataSourceFactory = CacheDataSource.Factory() .setCache(cache) .setUpstreamDataSourceFactory(DefaultDataSource.Factory(context)) .setFlags(CacheDataSource.FLAG_IGNORE_CACHE_ON_ERROR) val player = ExoPlayer.Builder(context) .setMediaSourceFactory(DefaultMediaSourceFactory(context) .setDataSourceFactory(dataSourceFactory)) .build()代码不复杂，但坑不少。RTSP 流的传输本身依赖 UDP/TCP 连接，弱网环境下容易丢包，如果缓存层和播放器的交互处理不好，回放的时候会有音画不同步和卡顿。我在实际调试中会特别关注两类日志：一类是 ExoPlayer 的LoadError，多次出现说明网络层是瓶颈；另一类是缓存 evict 次数，如果频繁触发淘汰，说明缓存上限设置得太小了。真遇到长视频回放需求，建议把缓存文件存到外部存储的私有目录，避免应用卸载后残留垃圾。
4.4 模块化和组件化：多人团队的协作基石
架构优化的最后一环是模块化。当应用规模超过一定阈值，单模块项目的编译时间会让人崩溃，并行开发也极易冲突。模块化的核心目标有两个：编译提速和团队解耦。
实践中推荐按“基础层、业务层、应用层”三层切分。基础层放完全通用的 Lib：网络框架、图片库、工具集、UI 组件库；业务层按业务域拆模块，比如登录模块、商城模块、消息模块，模块之间通过接口通信，不直接依赖具体实现；应用层是壳工程，负责组装依赖和启动路由。
模块之间通信，当前比较通行的方案是路由框架 + 服务注册的组合。路由负责页面跳转，URL 可以传递参数，支持跨模块调用；服务注册则解决“我需要某个能力但不想依赖提供者的实现”的问题。路由表的集中管理很重要，不然模块一多，路由 API 容易失控，我习惯用编译器注解自动生成路由表，避免手写维护。
Gradle 在多模块工程里是另一个重点。配置好按需编译、产物缓存、并行构建，大工程构建时间能快不少。这里有一个我踩过多次的坑：模块之间的依赖用了implementation还是api如果不刻意控制，很容易产生隐性循环依赖。建议在 CI 加一层依赖检查，或者定期用gradle dependencies看依赖树，确保图上的依赖方向是严格单向的。
5. 常见问题与避坑手册：我的实战排查笔记
5.1 鸿蒙适配过程中最容易踩的五个坑
我在做鸿蒙适配的时候，遇到过几次印象非常深刻的问题，列在这里供大家参考。
第一是 WebView 兼容性。HarmonyOS NEXT 的 WebView 组件在接口上不直接兼容安卓 WebView 的大量扩展能力，比如 JS Bridge 注入方式、Cookie 同步逻辑、下载监听器都不一样。如果你有大量 H5 页面，要提前梳理依赖了哪些 WebView 扩展能力，逐个适配。这个工作量比想象中大，建议预留两到三周专门做这一项。
第二是后台任务限制。鸿蒙对后台权限的管控比安卓更严格，尤其对长连接、定时任务、位置更新这类能力。如果你的应用依赖后台保活，比如消息推送或者运动记录，必须使用鸿蒙的后台任务管理接口，否则进程很容易被挂起。这个差异对 SDK 集成方影响尤其大，和厂商沟通时要先问清楚目标系统版本。
第三是文件路径差异。安卓开发习惯了/sdcard/，鸿蒙的公共目录映射规则不一样，直接用绝对路径会拿不到文件。我用fileUri相关的 API 重新封装了一遍文件读写，才解决这个问题。
第四是路由和深链。鸿蒙的路由跳转机制不像安卓那样直接在Intent里塞 Scheme 那么随意，建议统一走官方路由框架，避免在 URL 跳转上做太多 hack。
第五是多设备适配。鸿蒙生态包括手机、平板、车机、折叠屏，同一套 UI 在不同尺寸和交互方式下的表现差异很大。开发时最好一上来就按“响应式布局”思路做，不要像早年间安卓那样写死 dp 尺寸，否则后续适配返工成本极高。
5.2 KMP 集成中需要注意的兼容性问题
KMP 项目最常见的困惑是，写着写着发现某个三方库不支持 iOS 版本编译。比如一些只发布 JVM 版的 Kotlin 库，你在共享模块里引用了它，结果 iOS 编译直接报错。
这个问题在选型阶段就要规避。推荐优先选择官方支持 KMP 的库，比如 Ktor、kotlinx.serialization、kotlinx.coroutines、Room 的 KMP 版本。如果在某个功能点上实在找不到跨平台库，就用 expect/actual 自己做适配层，把平台实现放在两端的 sourceSet 里。实际项目中，我见过不少团队在这块吃闷亏，因为 Kotlin 生态更新速度非常快，可能你查文档时一个库还不支持 KMP，两个月后就支持了，所以选型时要看官方文档当前的维护状态，而不是搜索几个月前的资料。
还有一个很容易忽略的坑是序列化方案。如果共享模块要对接安卓和 iOS，JSON 解析库不要各用各的，否则同一个模型在两端解析出来的默认值会不一致，很容易产生“安卓正常，iOS 字段缺失”这种诡异 Bug。KMP 首选 kotlinx.serialization，它有一套跨平台一致的序列化策略。
5.3 架构重构期间如何保持业务迭代不停摆
架构优化最怕的不是技术难度，而是业务迭代压力。老架构代码堆在那里，新的分层体系要引入，同时这个月的业务需求还得照常发版。这个问题没有银弹，我只能分享我在实践中觉得比较有效的手法。
第一步是“旁路新写”。把新架构模块挂在老工程旁边，先不复用老逻辑，而是把新的能力按新架构写一版，通过切换开关控制走新老哪条路。这一步的核心目的是让新架构在真实业务场景里跑起来，而不是只活在独立 Demo 里。
第二步是“存量迁移”。从高内聚、低耦合的模块开始迁移，比如数据层、网络层，这些模块对界面不做强依赖，迁移后风险相对可控。界面层的迁移要放到后面，并且要用新架构先做一两个完整页面，形成范式供团队参考。
第三步是“灰度放量”。每一批迁移都跟随版本灰度发布，观察核心指标（崩溃率、卡顿率、启动时间）有没有恶化。如果指标变差，第一时间回滚开关。回滚能力比一次性迁移彻底性更重要，它决定了整个团队敢不敢放开步子改架构。这个和大版本升级的逻辑一致：稳定性优先于完美性。
写在最后：一点实战经验分享
这篇文章写到这里，其实我最想表达的观点已经自然浮现了：安卓开发进阶的本质，是视野从单端扩展到多端，能力从写逻辑扩展到设计系统。鸿蒙是新的端，KMP 是复用的工具，架构优化是让一切可持续的组织方式。三条线最后不是并列关系，而是互相交织的——没有架构意识的人做不好跨端共享，没有跨端视野的人也很难评估架构设计的合理性。
我个人在实际操作中的体会是，技术栈变新不要紧，要紧的是抽象能力。鸿蒙的 ArkTS、KMP 的 expect/actual、模块化的服务接口，本质都是在做同一件事：把稳定的、可复用的部分抽象出来，把变动的、差异化的部分隔离出去。修炼好这个能力，不管未来再冒出什么新系统、新框架，你都能快速找到自己的切入点。希望这篇拆解能帮你少走一些弯路，如果后面你也在做鸿蒙适配或者 KMP 落地，欢迎带着具体问题再来交流。
