鸿蒙生态对 Android 开发者意味着什么

「鸿蒙生态对 Android 开发者意味着什么」

2024 年 10 月 22 日，HarmonyOS NEXT 5.0 随着 Mate 70 系列一起正式发布。这个版本有个技术细节在业内传得很开：系统镜像里彻底移除了 AOSP 兼容层，Linux 内核也被替换成了鸿蒙内核。这意味着你用 Android Studio 打包出来的那个 APK 文件，在这个系统上连安装按钮都不会出现。不是提示"不兼容"，不是闪退，而是文件管理器直接不识别。对，就是这么干脆。很多 Android 开发者那天才真正意识到，华为说的"纯血鸿蒙"不是营销话术，而是一次货真价实的技术断交。

那个 APK 文件，彻底废了

要理解这件事的冲击有多大，得先回头看一眼 HarmonyOS 1.0 到 4.2 的时代。那几年里，鸿蒙系统底层其实跑着一个精简过的 AOSP 分支，你的 APK 扔进去，该装装，该跑跑，只是华为在框架层包了一层 HMS Core 和分布式软总线的 API。所以很多开发者当时的心态是：你说你的鸿蒙，我写我的 Android，反正最后都是打包成 APK 上架华为应用市场，顶多接一下 HMS 的 Push 和支付 SDK。这种"寄生式开发"持续了整整四年，直到 HarmonyOS NEXT 把桌子掀了。

NEXT 的架构文档里写得明白，应用格式从 APK 变成了 HAP（Harmony Ability Package），运行时不支持 Android 的四大组件，Dalvik/ART 虚拟机换成了鸿蒙自研的方舟编译器运行时。更狠的是，系统 API 直接断档到了 version 12，但这个"12"跟 Android API level 12 完全是两码事，它指的是鸿蒙自己的 API 版本体系。你用了十年的 Context.startActivity()、Intent、Service、BroadcastReceiver，在这里全都不存在。代替它们的是 Ability、Want、AtomicService 这一套全新的概念。虽然 Ability 在命名上让人联想到 Android 的 Activity，但生命周期回调、启动模式、任务栈管理全都不一样。比如鸿蒙的 PageAbility 并没有像 Android 那样明确的 onResume/onPause 回调矩阵，而是基于状态机的 UIAbility 生命周期，跟 ArkTS 的声明式 UI 深度绑定。你要是带着 Android 的思维去写鸿蒙应用，第一个坑就是生命周期管理，代码写出来能编译过，但切个后台再回来，状态全丢。

很多中小型团队的 Android 开发者拿到 DevEco Studio NEXT 5.0 的第一反应是懵的。IDE 的界面确实眼熟，毕竟也是基于 IntelliJ Community 改的，但新建项目向导里再也找不到 Kotlin 和 Java 的选项了。默认语言是 ArkTS，一种在 TypeScript 基础上加了装饰器和状态管理语法的语言。华为文档说你也可以用 C++ 写 NAPI，或者用仓颉（Cangjie）语言，但前者是写跨平台 so 的苦力活，后者在 2024 年底的生态基本等于零。所以现实很残酷：Android 开发者积累多年的 Kotlin 协程、Jetpack 组件、Compose UI 经验，在鸿蒙生态里几乎要清零。那些你闭着眼都能写出来的 ViewModel + LiveData + Room 架构，在 ArkTS 里找不到对应物。取而代之的是 @State、@Prop、@Provide、@Consume 一套响应式状态管理，以及 AppStorage、LocalStorage 这种看起来很像 Vue 3 和 Flutter 的混合体。

ArkTS：不是 TypeScript，也不是 Kotlin

华为官方文档在描述 ArkTS 时，喜欢强调它是"超集 TypeScript"，并且加了静态类型检查和声明式 UI 的能力。但实际写起来，Android 开发者会感到非常割裂。ArkTS 的语法确实像 TS，但类型系统比 Kotlin 松散得多，编译器报错信息又比 Android Studio 的 Kotlin 插件含糊一个数量级。你写一个 @Component 装饰的组件，忘了在 struct 里正确声明 build() 方法，错误日志可能要到运行时才能在模拟器里看到，而不是像 Jetpack Compose 那样在 IDE 里就给红波浪线。

说到 Jetpack Compose，这也是很多 Android 开发者心里的一根刺。华为在 ArkUI 的设计上明显借鉴了 Compose 的声明式思想，甚至一些 API 的命名都让你会心一笑，比如 Row、Column、Box、LazyColumn 这些容器在 ArkUI 里也是同名。但 ArkUI 的底层实现和 Compose 完全不同。Compose 依赖的是 Kotlin 编译器插件和 Slot Table 机制，而 ArkUI 是 C++ 写的框架层，通过 ArkTS 的语法糖映射到原生渲染树。这导致同样是声明式 UI，ArkUI 的重组粒度、性能特征和调试体验跟 Compose 差距不小。Compose 里你习惯了用 remember 和 derivedStateOf 做精细的状态订阅，ArkUI 里对应的 @State 触发重组的范围有时候大得莫名其妙，性能调优的手段又很少，因为 DevEco Studio 的 Profiler 到现在都还没有成熟到能看 UI 线程每一帧的重组详情。

更头疼的是异步编程模型。Android 开发者这几年被 Kotlin 协程惯坏了，withContext(Dispatchers.IO)、Flow、suspend 函数写起来行云流水。ArkTS 里你用的是什么？Promise 和 async/await，跟前端 JavaScript 那套一样。这本身没问题，但鸿蒙系统提供的 IO 接口，比如文件读写、网络请求、数据库操作，它们的异步 API 设计得相当粗糙。比如你想在后台线程跑一个耗时计算，ArkTS 里没有类似 Dispatchers.Default 的概念，你得用 worker 线程或者 taskpool，但线程间传递的数据必须能被序列化，而且跟主线程的通信机制远没有 Handler/LiveData 那么成熟。很多从 Android 转过来的开发者第一次用鸿蒙的并发 API 时都会骂娘：这不就是 HTML5 Web Worker 的翻版吗？而且限制还更多。

工具链的降维打击

DevEco Studio 从 3.1 版本进化到现在的 NEXT 5.0.x，进步是有的，但跟 Android Studio 比起来，工具链的鸿沟依然大得让人绝望。Android Studio 背靠的是 Gradle 生态二十年的积累，插件市场、依赖管理、构建缓存、增量编译，每一条都经过了千万级项目的打磨。DevEco Studio 用的是 hvigor，一个基于 Node.js 和 TypeScript 的构建工具。hvigor 的设计理念有点像 Gradle 的 Kotlin DSL，但实际体验像是把前端 npm 脚本和 Java 构建强行缝合在一起。

你 import 一个第三方库，在 Android 里是 implementation("xxx")，在鸿蒙里是 ohpm install（OpenHarmony Package Manager）。ohpm 的仓库生态目前荒凉到什么地步？你在里面搜一个图片加载库，能找到的官方维护库只有 ImageKnife，功能大概相当于 Android 世界里 Glide 的一个零头。想用 OkHttp？没有。Retrofit？没有。Room？没有。你得自己基于鸿蒙的网络 API 去封装，或者用那些大厂临时适配出来的半成品 SDK。更离谱的是构建速度。一个中等规模的鸿蒙项目，hvigor 的 clean build 时间经常能跑到 Android 项目的两三倍，而且构建缓存机制很不稳定，有时候改了一行 UI 颜色，触发全量编译，开发者只能干瞪眼。

模拟器的问题更让人崩溃。Android Emulator 虽然历来被吐槽吃内存，但至少 API 完整、快照功能稳定、能模拟各种传感器和网络状态。DevEco Studio 的鸿蒙模拟器基于 QEMU，但系统镜像的完整性一直有问题，API 12 的很多特性在模拟器上跑出来的行为跟真机不一致。比如蓝牙扫描、NFC、甚至后台任务调度，模拟器上能过，真机 Mate 60/Mate 70 上直接挂。Android 开发者习惯了在模拟器上做 80% 的开发和调试，再留 20% 给真机收尾；但在鸿蒙开发里，这个比例可能要倒过来，真机调试才是主战场。而真机调试需要签名、需要华为开发者账号、需要设备在 IDE 里识别，DevEco Studio 的设备连接稳定性，实话实说，跟 Android Studio 的 ADB 比还差了至少两个大版本。

大厂适配：一场被迫的军备竞赛

鸿蒙生态能不能成，从来不取决于华为说了什么，而取决于微信、支付宝、抖音、美团这些超级 App 愿不愿意真金白银地投入人力去重写。2024 年下半年，科技圈最魔幻现实主义的一幕出现了：各大厂疯狂招聘鸿蒙开发工程师，薪资普遍比 Android 岗高出 30% 到 50%，但招进去的人干的活，说白了就是把 Android 端积累了十年的功能，用 ArkTS 在鸿蒙上重新实现一遍。而且因为鸿蒙 API 12 的残缺，很多功能根本做不到对等。

微信鸿蒙原生版的难产最能说明问题。张小龙团队一向以克制和慢工出细活著称，但微信鸿蒙版的进度慢得让外界一度怀疑腾讯是不是在消极抵抗。直到 2024 年 10 月之后，微信鸿蒙版才开启小规模内测，而且初版功能被阉割到令人发指：没有小程序，没有视频号，没有朋友圈的部分交互，甚至连基本的群管理功能都缺。这不是腾讯不想做，而是鸿蒙的底层能力在早期版本里根本支撑不了微信这种量级的架构。比如微信极度依赖的多进程架构、长连接保活、海量本地数据库、复杂的自定义渲染，在鸿蒙的 Ability 框架和受限的后台策略下，全都要重新设计。一个冷知识：微信 Android 端的安装包现在已经膨胀到接近 300MB，里面塞满了自研的 UI 框架、音视频编解码库、X5 内核；而微信鸿蒙版在 NEXT 上只能走 ArkTS + C++ NAPI 的路线，很多底层库要重新适配方舟运行时，这个工程量想想都让人头皮发麻。

支付宝和美团相对积极，但适配过程也是一地鸡毛。支付宝的扫码、支付、小程序容器，美团的外卖、酒店、地图导航，每一个模块在 Android 端都有深厚的技术债务和自研中间件。迁移到鸿蒙意味着这些中间件要么等华为 HMS 出官方替代方案，要么自己用 C++