HarmonyOS Next(纯血鸿蒙)它到底像谁
前言
24年的第1天有写过一篇关于鸿蒙的文章:不吹不黑,辩证看待开发者是否需要入坑鸿蒙
后续再也没有写关于鸿蒙的文章。
没错,我确实入坑了鸿蒙,并且成功上架了几款App和元服务,虽然当前的用户量还比较少,但鸿蒙开发的整体流程已然蹚了一遍,是时候来做一些总结了。
本篇从应用开发的角度聊聊鸿蒙它像谁?它有哪些不一样的特征?开发者怎么快速入门?
通过本篇文章,你将了解到:
- HarmonyOS Next是否还套壳Android?
- HarmonyOS Next 系统表现
- HarmonyOS Next 开发语言
- HarmonyOS Next 开发工具
- HarmonyOS Next/Android 我们不一样
- HarmonyOS Next 特性
- HarmonyOS Next 未来发展
1. HarmonyOS Next是否还套壳Android?
如果要说鸿蒙受网友诟病最多的一点,那么套壳Android必然是其中之一。HarmonyOS 4.2(含) 之前是OpenHarmony+AOSP(Android Open Source Project),也即是说此时的鸿蒙是可以安装APK文件的,也就是说的兼容Android。
而HarmonyOS Next之后,鸿蒙不再支持安装APK文件,只允许安装HAP文件。同时不再搭载Linux内核,而是使用了鸿蒙内核,,传说鸿蒙内核是微内核。
1. 什么是内核?
- 操作系统的核心称为内核,主要有几个重要的模块如:中断处理(信号)、进程管理(如何使用CPU)、内存管理(内存的分配与释放)、文件系统、网络管理、驱动管理等。
- 内核提供了最基本的服务,应用程序(应用软件/App)使用内核提供的服务完成自己的业务逻辑。
2. 宏内核和微内核
宏内核:
内核模块放在一个进程内,各个模块之间可以直接调用,优点显而易见:快。缺点是不够灵活(新增模块需要动到内核)和稳定(某个模块有问题会影响到整个内核进程),典型代表是:Linux。
微内核:
内核进程只保留了少数核心的模块,比如中断处理、进程管理以及IPC通信,而内存管理、文件系统这些是放在单独的进程里,它们之间需要依赖IPC进行通信。优点是隔离性好,缺点是因为频繁需要IPC通信,性能没那么好。典型代表:Mach。
宏内核和微内核的优缺点并不是那么泾渭分明,随着技术的进步它们的边界并没有那么清晰,甚至出现了混合内核,比如Mac的系统。
目前看来,HarmonyOS Next是纯血的鸿蒙系统,并没有套壳Android。
2. HarmonyOS Next 系统表现
鸿蒙系统对外宣称的亮点:安全、智能、全场景。
来看看Next Beta1版本一些主要页面的展示:
主页:
image.png
右滑到底负一屏:
image.png
双指捏合:
image.png
系统设置:
image.png
开发者选项:
image.png
可以看到,操作界面和华为Android版如出一辙。
从操作体感上说,确实比较流畅,但不确定如果鸿蒙Next在低端机型上搭载是否还有类似的体验。
3. HarmonyOS Next 开发语言
ArkTS与ArkUI
鸿蒙主推开发语言:ArkTS,从命名可以看出,这是在TypeScript的基础上发展而来的,ArkTS比TS类型限制更严格,属于静态类型语言。因此,在语言这块,鸿蒙是属于前端系的。
官网介绍:
image.png
image.png
鸿蒙主推UI框架:ArkUI,声明式的UI框架,和Flutter比较像。
官网介绍:
image.png
因此,如果你有前端基础,那么你入手鸿蒙开发将会事半功倍,没有前端基础,入手也依然很快,最晚不超过一周就可以上手鸿蒙。
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方式出现的,如:
image.png image.png
因为后发的优势,鸿蒙知道开发者开发过程中的一些痛点,将开发过程中常用的库抽取形成各式的Kit,满足开发过程中大部分场景的需求,相比Android确实便利了不少,同时也大大节省了App的大小。
如Android一个空项目编译产物apk大小:
image.png
鸿蒙空项目编译产物hap大小:
image.png
一个将近8M,一个将近200K,差别还是挺大的。
在对比老项目的Android和鸿蒙重构的老项目,体积差的也比较明显,然而如果App本身大部分体积在so那部分,那差别不会那么明显。
当然Android包比较大也是因为发展了这么多年,兼容了很多功能如AndroidX等库打进了App,目前鸿蒙是新系统没有历史包袱可以轻装上阵,且看后续如何演变吧。
官网资料
华为需要快速打造鸿蒙生态,那么必须让开发者以最小的代价、最高的效率开发App。除了易用的ArkTS之外,还提供了每种场景的代码用例,方便开发者直接上手。
官网地址:
https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/application-dev-guide-V5?catalogVersion=V5
不得不说,相比Android开发官网,华为的文档分类更精细,FAQ搜索效率也更高。
缺点是:近期华为工程师估计在挑灯夜战赶进度,系统的一些设计变更比较激进,甚至有些是不兼容的设计,文档也是更新比较频繁,需要时不时看看是否有变更。
深入源码学习?
Android一直以开放、多样性著称,是基于它能够方便地看到源码,修改源码,从而实现各种黑科技、各种定制。而在鸿蒙上,难度比较大,因为看不到它的源码。
以Ability为例,想看看它和Window是怎么交互的:
image.png
仅仅只是声明文件。
有没有研究过的大佬指教一下~
看不到源码也有好处:不用关于系统的实现,调用API就完事了,主打一个省事,缺点是:只能按部就班调用API。
4. HarmonyOS Next 开发工具
DevEco Studio
鸿蒙开发IDE: DevEco Studio
官网介绍:
image.png
再看Android Studio介绍:
image.png
可以看到两者的基础都是IntelliJ IDEA 。
当然,分别打开DevEco Studio 和Android Studio的About,将会看到如下描述:
image.png image.png
看来还是得靠JetBrains公司啊。
因此可以预见DevEco Studio 和Android Studio除了长得特别相似,操作也大差不差。
工程目录结构
DevEco Studio 两层结构:project+module,一个project下可以存在多个module,如下图:
image.png
绿色部分是project,红色为具体的module。
和Android Studio类似的布局:
image.png
DevEco Studio的project和module都分别有对应的build-profile.json5文件用来描述编译构建特征。
同样的,Android Studio使用:build.gradle.kts文件来描述编译构建特征。
可以看出,两者名字和功能都比较像。
再看module内部:
DevEco Studio module:
image.png
Android Studio module:
image.png
目录结构一个是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权限规则的奔放,鸿蒙将应用权限分类,对应的规则进行了细化。
image.png对所用应用开放的权限,比如定位权限。
只需要在代码里声明需要使用该权限,并在真正要使用的时候动态向用户申请,用户同意后即可使用权限。
对于受限制开放的权限,必须在官网上进行预先申请,比如读取相册里的图片/视频,此类权限的申请需要自证App的类型是符合要求的,比如专业的相册App。
若是普通的App但又想访问相册,可以用系统提供的Picker,类似Android里的系统文件选择SAF。除了相册相关的Picker,系统还提供了其它场景的Picker。
再是更严格的权限,比如管理系统里App的安装与卸载,这类App通常是设备厂商自有的设备才能申请。
元服务
鸿蒙软件有两种形态:应用+元服务。
元服务的优点是无需安装,快速触达用户。
元服务的限制:
image.png
看到这几个限制,是不是莫名的熟悉,没错和微信小程序的限制不谋而合。
元服务可以理解为鸿蒙系统的小程序。
华为还是很看重元服务,除了推动伙伴开发元服务外,在整个系统里都对元服务进行了大量的曝光,如应用市场都给了一个单独的Tab展示。
其它的特性
一键登录、AppLinking、预加载服务、智感扫码、应用多设备间接续等,有用到的业务场景的话可以去尝试,虽然有些特性你在其它的系统上也能看到影子,但鸿蒙对此做了一些拓展。
7. HarmonyOS Next 未来发展
以下是官方通告:
image.png
评论:数据没问题,主流软件都适配了,如美团、抖音、小红书、快手、京东、淘宝、支付宝等,但是微信目前还没影。
image.png评论:传说微信9月底上架,拭目以待吧?
8. 小结
扯了那么多,那么从应用开发的角度看,HarmonyNext像谁?
我的不负责的结论是:
image.png
那么,评论区说说你的理解呢?
接下来会系统地分析鸿蒙开发的知识点以及遇到的坑,敬请关注~