因为要验证我的几个应用能否移植到鸿蒙，仔细看了下鸿蒙，当然作为开发者，肯定要从开发环境看起。

开发环境

鸿蒙OS的开发工具叫做DevEco Studio，和Android Studio一样，也是基于IDEA。

• 安装时设置好sdk目录，即开始自动下载安装sdk和tools。下载完成后在向导页面中可以看到当前下载的sdk版本为2.1.18，version 5，下文都是基于这个版本。
• 创建一个hellohm项目，选择一个手机项目模板。
• 打开项目，稍等一下gradle配置，很快项目就完整展现了，整个还是很流畅。

编译

因为构建工具是gradle，所以自然在命令行用gradlew assembleDebug试了一下，果然开始编译了：

• 默认用gradle 6.3，下载依赖的时候，服务器自动设为国内的服务器，比安卓环境下的gradle要快多了。
• 不到一分钟，依赖下载和编译完成。

看下输出文件：

39k的hap文件，这就是一个纯粹的鸿蒙应用，对应安卓的apk，这是没有签名的debug版本，用7zip打开这个hap文件看看：

这几个文件都能理解，安卓的manifest文件变成了config.json。但让我没想到的是，这里居然包了一个apk文件。试着把这个apk解出来，再用7zip打开，还真是个标准apk

既然是apk，自然放到普通安卓手机上试一下咯，安装没有问题，图标也看到了，点开…闪退，用adb看一下日志：

04-09 15:12:53.334  7450  7450 E AndroidRuntime:        Caused by: java.lang.ClassNotFoundException: Didn't find class "ohos.abilityshell.HarmonyApplication" on path: DexPathList[[zip file "/data/app/com.example.hello_hm-THrK3d5xftGaJlBnx92w_A==/base.apk"],nativeLibraryDirectories=[/data/app/com.example.hello_hm-THrK3d5xftGaJlBnx92w_A==/lib/arm64, /system/lib64, /product/lib64]]
04-09 15:12:53.334  7450  7450 E AndroidRuntime:                at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:230)
04-09 15:12:53.334  7450  7450 E AndroidRuntime:                at java.lang.ClassLoader.loadClass(ClassLoader.java:379)
04-09 15:12:53.334  7450  7450 E AndroidRuntime:                at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
04-09 15:12:53.334  7450  7450 E AndroidRuntime:                ... 16 more

ClassNotFound，看来这个apk是不能跑在纯安卓上的，只能跑在鸿蒙上，那这个apk是什么意思? 也许是为了鸿蒙的底层是安卓时，可以跑这个apk达到让底层安卓管理鸿蒙应用的目的吧，反过来也就是说，如果哪一天鸿蒙完全脱离安卓，自然就不需要这个apk了，这只是我的想法，用adb验证一下。

可以看到，通过adb shell可以看到这个鸿蒙应用，用dumpsys可以看到当前的Activity叫做MainAbilityShellActivity，但这是我们代码里没有的东西，从哪里来的？应该就是上面这个自动生成的apk跑出来的。

鸿蒙应用

引用一下官方文档，鸿蒙应用是由一个或多个HAP（HarmonyOS Ability Package）包以及属性文件pack.info文件组成。这点和安卓不同，安卓一个应用是一个apk。

HAP是Ability的部署包，HarmonyOS应用代码围绕Ability组件展开，它是由一个或多个Ability组成。Ability分为两种类型：FA（Feature Ability，中文名称：元程序）和PA（Particle Ability，中文名称：元服务）。FA/PA是应用的基本组成单元，能够实现特定的业务功能。FA有UI界面，而PA无UI界面。

官方语言挺绕口，我的理解，Ability就是组件，FA对应安卓的Activity，PA对应安卓Service。Ability加上资源文件打包起来就是hap，对应安卓的apk。

模拟器

我没有运行鸿蒙的真机，只能选择模拟器运行，这个模拟器是云加载的，需要先验证华为开发者账号，然后就可以看到了：

四种模拟器，代表四种设备类型，我要验证我的手机应用，自然就选了P40，启动很快，也不占用本地内存，很好。点击IDE里的调试，就可以运行到模拟器中了。模拟器上有个倒计时，应该是云端模拟器不能占用太长的时间，超时会被释放。

尝试了一下调试，怎么也设置不了断点，按照文档做了各种设置都不行，只好去华为开发者网站提交一个问题，很快第二天收到了回复，问题修复并提供了升级包下载。升级后问题解决，但远程调试的体验确实不佳，很慢，所以实际开发鸿蒙应用，还是需要一个真机，同时看了一下华为的文档，如果要真机调试，需要先申请调试证书，并配置签名信息，也就是说，估计华为的签名策略会收紧，向苹果看齐，未来鸿蒙的应用市场可能只有官方一家。

安卓兼容性

我的几个应用虽然是普通安卓应用，但由于都用到了比较多的安卓服务和硬件特性，应该能比较能说明鸿蒙的兼容性，在看我的App之前，先看下这个模拟器的版本，后面兼容性测试都是基于这个版本。

先来看碎片记忆，这个应用使用了悬浮窗和桌面小部件，用adb安装一下，没有问题，运行并导入词库，碎片记忆的悬浮窗已经跑起来了。

再想试试桌面小部件，可是云端模拟器不支持长按桌面加小部件，只支持双指捏合，这应该是EMUI11的一个改动，在云端模拟器，没办法触发双指，所以暂时还看不到小部件的支持情况。

再试试隐秘参数，这是一个硬件检测和性能测试工具，使用了很多安卓底层的API，在安装之前我是有点怀疑它能否正常运行的，但实际情况是：

不仅正常运行，还居然测出了显示屏和触控厂商，这在纯安卓版的P40上都测不出的，兼容性看起来没什么问题。性能部分就有意思了，SOC跑分急剧降低，显示刷新率20hz，内存、存储性能全部下降的厉害，按道理，如果只是远程真机，不应该降低性能，只是有网络延迟，所以估计是模拟器导致的，似乎是一个跑在P40物理机上的虚拟机。

最后看下微动手势，这个一个需要无障碍服务和陀螺仪传感器才能工作的的手势工具。

配置无障碍服务没有问题，但可惜因为在云端，没办法触发陀螺仪手势，看来这个只能通过真机才能验证了。但从几个应用整体来看，当前鸿蒙在兼容apk方面没什么问题。

鸿蒙工程

回头再来看下鸿蒙工程文件，整个工程有些部分和安卓还是相似的，这对于安卓程序员来说比较友好，可以快速上手，有一些概念也可以相互对照：

模块划分

因为鸿蒙分布式的特性，鸿蒙的模块分的更细（方便流转和快速加载），官方文档中有一句重要的描述：HarmonyOS支持应用以Ability为单位进行部署。

可以这样来分解：

• 一个应用包括多个Ablity，需要在config.json中一一声明。
• Ablity有多种，比如ui类的Page，还有无ui的Data和Service。
• ‘Page’不是一个页面，而是多个页面AbilitySlice的汇总，这个术语不太好。
• 多个Slice中，有一个为主，其他slice则需要通过addActionRoute和一个字符串action来绑定，如果slice需要被外部调用，action还要在config.json里声明。

setMainRoute(MainSlice.class.getName());
addActionRoute("action.pay", PaySlice.class.getName());
addActionRoute("action.scan", ScanSlice.class.getName());

...config.json...
"skills":[{"actions":["action.pay","action.scan"]}]

• Page间可以通过Intent跳转，跳转可以直接指定Bundle和Ability(显式跳转)，也可以通过Action匹配到AbilitySlice(隐式跳转)，这个和安卓比较接近，举例如下：

Intent intent = new Intent();
intent.setOperation(new Intent.OperationBuilder()
        .withDeviceId("")
        .withBundleName("com.demoapp")
        .withAbilityName("com.demoapp.FooAbility")
        .build());
startAbility(intent);

intent.setOperation(new Intent.OperationBuilder()
        .withAction(Intent.ACTION_QUERY_WEATHER)
        .build());
startAbilityForResult(intent, REQ_CODE_QUERY_WEATHER);

UI和布局

看一下项目的布局文件和源码，UI部分代码需要完全重写了，不可能兼容安卓的Layout和控件了，大部分的API都不一致了，只是有些在安卓中可以找到一个依稀的影子，但接口都是不一样的。

这说明了一个问题，如果不是以安卓兼容模式运行，现有的安卓应用要想移植到鸿蒙，工作量还是很大的，基本上需要完全重写。

鸿蒙除了支持Java，还支持JS UI，这时鸿蒙比较有特色的一个地方。

Page和AbilitySlice

这是鸿蒙比安卓复杂的地方，Page包括多个Slice，page本身的生命周期是这样的：

每个slice也是这个状态机，但是两个slice间跳转的时候，每个slice的状态的迁移是有顺序的，比如从A迁移到B:

A.onInactive() -> B.onStart() -> B.onActive() -> A.onBackground()

slice之间可以通过present或presentForResult跳转

button.setClickedListener(listener -> present(new TargetSlice(), new Intent()));

上面这个new Intent似乎只是用来传递参数，这时不需要action，也就是说如果slice不需要被外部调用，可以随便起一个action名，也不用在config.json里注册，但可惜不能留空，留空会报错。

一个小测试发现，如果两个slice使用同一个layout，则slice页面内容会互相修改。

总结

整个上手的感觉还是不错，IDE、文档、模拟器都挺顺畅的，hello-world对原安卓开发人员也保持了恰好的“熟悉”，这已经非常不错了，作为经常评估各种奇奇怪怪系统的开发者，一半以上的系统都是因为不成熟的hello-world把我吓退的，这一点鸿蒙已经有一个好的起点。

在兼容性方面，看起来不用太担心，现在的鸿蒙因为自带安卓，可以运行apk，起码从我的几个App来看，除了无法验证的几个地方，都没有问题，当然未来如果鸿蒙剥离安卓，那就要考验第三方的跟进度了，目前看，应用需要重写才能兼容鸿蒙。