HarmonyOS Next(纯血鸿蒙)它到底像谁？

前言

24年的第1天有写过一篇关于鸿蒙的文章：不吹不黑，辩证看待开发者是否需要入坑鸿蒙
后续再也没有写关于鸿蒙的文章。
没错，我确实入坑了鸿蒙，并且成功上架了几款App和元服务，虽然当前的用户量还比较少，但鸿蒙开发的整体流程已然蹚了一遍，是时候来做一些总结了。
本篇从应用开发的角度聊聊鸿蒙它像谁？它有哪些不一样的特征？开发者怎么快速入门？
通过本篇文章，你将了解到：

1. HarmonyOS Next是否还套壳Android？
2. HarmonyOS Next 系统表现
3. HarmonyOS Next 开发语言
4. HarmonyOS Next 开发工具
5. HarmonyOS Next/Android 我们不一样
6. HarmonyOS Next 特性
7. HarmonyOS Next 未来发展

1. HarmonyOS Next是否还套壳Android？

如果要说鸿蒙受网友诟病最多的一点，那么套壳Android必然是其中之一。HarmonyOS 4.2(含) 之前是OpenHarmony+AOSP（Android Open Source Project），也即是说此时的鸿蒙是可以安装APK文件的，也就是说的兼容Android。
而HarmonyOS Next之后，鸿蒙不再支持安装APK文件，只允许安装HAP文件。同时不再搭载Linux内核，而是使用了鸿蒙内核，，传说鸿蒙内核是微内核。

1. 什么是内核？

1. 操作系统的核心称为内核，主要有几个重要的模块如：中断处理（信号）、进程管理（如何使用CPU）、内存管理（内存的分配与释放）、文件系统、网络管理、驱动管理等。
2. 内核提供了最基本的服务，应用程序（应用软件/App）使用内核提供的服务完成自己的业务逻辑。

2. 宏内核和微内核
宏内核：

内核模块放在一个进程内，各个模块之间可以直接调用，优点显而易见：快。缺点是不够灵活（新增模块需要动到内核）和稳定（某个模块有问题会影响到整个内核进程），典型代表是：Linux。

微内核：

内核进程只保留了少数核心的模块，比如中断处理、进程管理以及IPC通信，而内存管理、文件系统这些是放在单独的进程里，它们之间需要依赖IPC进行通信。优点是隔离性好，缺点是因为频繁需要IPC通信，性能没那么好。典型代表：Mach。

宏内核和微内核的优缺点并不是那么泾渭分明，随着技术的进步它们的边界并没有那么清晰，甚至出现了混合内核，比如Mac的系统。

目前看来，HarmonyOS Next是纯血的鸿蒙系统，并没有套壳Android。

2. HarmonyOS Next 系统表现

鸿蒙系统对外宣称的亮点：安全、智能、全场景。
来看看Next Beta1版本一些主要页面的展示：
主页：

右滑到底负一屏：

双指捏合：

系统设置：

开发者选项：

可以看到，操作界面和华为Android版如出一辙。
从操作体感上说，确实比较流畅，但不确定如果鸿蒙Next在低端机型上搭载是否还有类似的体验。

3. HarmonyOS Next 开发语言

ArkTS与ArkUI

鸿蒙主推开发语言：ArkTS，从命名可以看出，这是在TypeScript的基础上发展而来的，ArkTS比TS类型限制更严格，属于静态类型语言。因此，在语言这块，鸿蒙是属于前端系的。
官网介绍：

鸿蒙主推UI框架：ArkUI，声明式的UI框架，和Flutter比较像。
官网介绍：

因此，如果你有前端基础，那么你入手鸿蒙开发将会事半功倍，没有前端基础，入手也依然很快，最晚不超过一周就可以上手鸿蒙。

Stage与Ability

Stage作为HAP的入口，和Android的Application类似

import { AbilityStage} from '@kit.AbilityKit';
/**
 * HAP入口函数
 */
export default class EntryStage extends AbilityStage {
  onCreate(): void {
  }
}

而Ability绑定了Window，和Android的Activity类似

import { AbilityConstant, UIAbility, Want } from '@kit.AbilityKit';
import { hilog } from '@kit.PerformanceAnalysisKit';
import { window } from '@kit.ArkUI';

export default class EntryAbility extends UIAbility {
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    hilog.info(0x0000, 'testTag', '%{public}s', 'Ability onCreate');
  }
  
  //类似Android的onNewIntent
  onNewWant(want: Want, launchParam: AbilityConstant.LaunchParam): void {
  }

  onDestroy(): void {
    hilog.info(0x0000, 'testTag', '%{public}s', 'Ability onDestroy');
  }

  onWindowStageCreate(windowStage: window.WindowStage): void {
    // Main window is created, set main page for this ability
    hilog.info(0x0000, 'testTag', '%{public}s', 'Ability onWindowStageCreate');
    // 类似Android的setContentView
    windowStage.loadContent('pages/Index', (err) => {
      if (err.code) {
        hilog.error(0x0000, 'testTag', 'Failed to load the content. Cause: %{public}s', JSON.stringify(err) ?? '');
        return;
      }
      hilog.info(0x0000, 'testTag', 'Succeeded in loading the content.');
    });
  }

  onWindowStageDestroy(): void {
    // Main window is destroyed, release UI related resources
    hilog.info(0x0000, 'testTag', '%{public}s', 'Ability onWindowStageDestroy');
  }

  onForeground(): void {
    // Ability has brought to foreground
    hilog.info(0x0000, 'testTag', '%{public}s', 'Ability onForeground');
  }

  onBackground(): void {
    // Ability has back to background
    hilog.info(0x0000, 'testTag', '%{public}s', 'Ability onBackground');
  }
}

相信开发过Android的小伙伴一定能从中找到和Android相似的地方。

各式各样的Kit

与Android不同的是，鸿蒙大部分应用层的库都是以Kit方式出现的，如：

因为后发的优势，鸿蒙知道开发者开发过程中的一些痛点，将开发过程中常用的库抽取形成各式的Kit，满足开发过程中大部分场景的需求，相比Android确实便利了不少，同时也大大节省了App的大小。

如Android一个空项目编译产物apk大小：

鸿蒙空项目编译产物hap大小：

一个将近8M，一个将近200K，差别还是挺大的。
在对比老项目的Android和鸿蒙重构的老项目，体积差的也比较明显，然而如果App本身大部分体积在so那部分，那差别不会那么明显。
当然Android包比较大也是因为发展了这么多年，兼容了很多功能如AndroidX等库打进了App，目前鸿蒙是新系统没有历史包袱可以轻装上阵，且看后续如何演变吧。

官网资料

华为需要快速打造鸿蒙生态，那么必须让开发者以最小的代价、最高的效率开发App。除了易用的ArkTS之外，还提供了每种场景的代码用例，方便开发者直接上手。
官网地址：
developer.huawei.com/consumer/cn…

不得不说，相比Android开发官网，华为的文档分类更精细，FAQ搜索效率也更高。
缺点是：近期华为工程师估计在挑灯夜战赶进度，系统的一些设计变更比较激进，甚至有些是不兼容的设计，文档也是更新比较频繁，需要时不时看看是否有变更。

深入源码学习？

Android一直以开放、多样性著称，是基于它能够方便地看到源码，修改源码，从而实现各种黑科技、各种定制。而在鸿蒙上，难度比较大，因为看不到它的源码。
以Ability为例，想看看它和Window是怎么交互的：

仅仅只是声明文件。
有没有研究过的大佬指教一下~

看不到源码也有好处：不用关于系统的实现，调用API就完事了，主打一个省事，缺点是：只能按部就班调用API。

4. HarmonyOS Next 开发工具

DevEco Studio

鸿蒙开发IDE: DevEco Studio
官网介绍：

再看Android Studio介绍：

可以看到两者的基础都是IntelliJ IDEA 。

当然，分别打开DevEco Studio 和Android Studio的About，将会看到如下描述：

看来还是得靠JetBrains公司啊。
因此可以预见DevEco Studio 和Android Studio除了长得特别相似，操作也大差不差。

工程目录结构

DevEco Studio 两层结构：project+module，一个project下可以存在多个module，如下图：

绿色部分是project，红色为具体的module。
和Android Studio类似的布局：

DevEco Studio的project和module都分别有对应的build-profile.json5文件用来描述编译构建特征。
同样的，Android Studio使用：build.gradle.kts文件来描述编译构建特征。
可以看出，两者名字和功能都比较像。

再看module内部：
DevEco Studio module:

Android Studio module:

目录结构一个是src/main/ets，另一个是src/main/java，都是固定生成的作为默认的父级目录。
而Ability的描述文件module.json5对应Activity的清单文件Androidmanifest.xml。

看到这想必你也发现了另一个重点。
DevEco Studio 采用的编译构建工具是：hvigor
Android Studio 采用的编译构建工具是：gradle

经历过Android开发的小伙伴可能苦gradle久矣，毕竟gradle不开代理不好下载，开了代理还不一定快，下载了可能还有版本兼容问题。然而在DevEco Studio里几乎不会遇到这类问题，毕竟服务器在国内，现在也没有迭代几个版本，问题不凸显。

目前DevEco Studio迭代速度很快，几乎是每两周一个小版本，截止目前已经更新到next beta1版本。

以上可以看出，在IDE操作方面，DevEco Studio 和Android Studio基本没有差异。

5. HarmonyOS Next/Android 我们不一样

应用分发

前面几章都在描述有多像Android，而在这章节里和Android分道扬镳了。
总所周知Android app是可以随意分发的，比如开发一个app，只要最低版本兼容那么apk文件就可以安装在任何Android设备上，这一特性大大促进了Android的普及。
而在鸿蒙里，只有测试签名的HAP包才能通过IDE/HDC命令行安装在设备上并且这个设备得加入到测试白名单里，而用户的手机只能从应用市场下载安装正式签名的app(禁止侧载)，这一要求限制了想要像Android一样新版本整灰度升级的想法。
这虽然和Android不一样了，但和iOS的表现如出一辙了，后续是否有越狱？不得而知。

应用推送

Android的厂商推送五花八本，每次接入推送功能Android的小伙伴都很羡慕iOS的小伙伴，因为他们只需要接APNs就可以了。
而在鸿蒙上，推送也不区分在线、离线，都当做了离线推送，这设计上也很iOS。

应用抽水

很多网友戏称华为税、”爱国”税，鸿蒙也设计了一套应用内购(IAP)的规则，只是目前没有公布太多细则，大概率也是参照iOS做法，估计是想先搭建生态，生态繁荣后再举起镰刀。

还有其它不一样的地方，欢迎补充~

6. HarmonyOS Next 特性

权限安全

鸿蒙的一大宣传亮点就是安全，相比Android权限规则的奔放，鸿蒙将应用权限分类，对应的规则进行了细化。

对所用应用开放的权限，比如定位权限。
只需要在代码里声明需要使用该权限，并在真正要使用的时候动态向用户申请，用户同意后即可使用权限。

对于受限制开放的权限，必须在官网上进行预先申请，比如读取相册里的图片/视频，此类权限的申请需要自证App的类型是符合要求的，比如专业的相册App。
若是普通的App但又想访问相册，可以用系统提供的Picker，类似Android里的系统文件选择SAF。除了相册相关的Picker，系统还提供了其它场景的Picker。

再是更严格的权限，比如管理系统里App的安装与卸载，这类App通常是设备厂商自有的设备才能申请。

元服务

鸿蒙软件有两种形态：应用+元服务。
元服务的优点是无需安装，快速触达用户。

元服务的限制：

看到这几个限制，是不是莫名的熟悉，没错和微信小程序的限制不谋而合。
元服务可以理解为鸿蒙系统的小程序。

华为还是很看重元服务，除了推动伙伴开发元服务外，在整个系统里都对元服务进行了大量的曝光，如应用市场都给了一个单独的Tab展示。

其它的特性

一键登录、AppLinking、预加载服务、智感扫码、应用多设备间接续等，有用到的业务场景的话可以去尝试，虽然有些特性你在其它的系统上也能看到影子，但鸿蒙对此做了一些拓展。

7. HarmonyOS Next 未来发展

以下是官方通告：

评论：数据没问题，主流软件都适配了，如美团、抖音、小红书、快手、京东、淘宝、支付宝等，但是微信目前还没影。

评论：传说微信9月底上架，拭目以待吧？

8. 小结

扯了那么多，那么从应用开发的角度看，HarmonyNext像谁？
我的不负责的结论是：

那么，评论区说说你的理解呢？

接下来会系统地分析鸿蒙开发的知识点以及遇到的坑，敬请关注~