前几天，鸿蒙正式发布会刚结束，瞬间就冲上了热搜，看好的很多，反对的也不少，什么安卓套皮，什么自主的全场景分布式系统。虽然是个菜鸡码农，但是本着不入流的程序员的习惯还是先体验下才能真正了解。（其实鸿蒙1.0那会就注册了鸿蒙开发者，但是苦于没有官方指定的开发板加上官方IDE始终下载不了就一直没有上手体验。）
最好的了解方式肯定是看源码，但是找了很久，OpenHarmony只开源到嵌入式设备，如果有资源的大佬也请
分享一下，因此退了求其次，根据官方IDE，sdk及demo来初步体验下鸿蒙软件的开发流程。
1.注册开发者
首先就是在开发者联盟也就是官网https://developer.huawei.com/ 注册认证开发者，这个我很早就注册了，那会官网还不像现在这么精致，记忆中还是开发者联盟，网页就一张图片加上一个按钮，很简洁，现在是HiLink，各种功能都已经完善了很多。具体注册很简单就不多说了。
2.下载官方IDE配置安装
傻瓜式安装就好，闭着眼下一步下一步即可。下载链接是：https://developer.harmonyos.com/cn/develop/deveco-studio#download
3.根据官方文档运行demo
这一步跟着开发文档来就好，申请远程模拟器运行（如果有本地设备的话可以按照文档中的指引在本地设备上运行），下面就是获得远程模拟器后，是不是和AVD很像？？但实话说明显比AVD流畅了，毕竟是远程的模拟器，不是AVD那样。而且整个界面，工程目录和窗口布局都有莫名的熟悉感，emem......这不就是AndroidStdio吗？？？谷歌用JetBrains的IDEA开发了AndroidStdio，难道DS也是基于AS开发的？猜测一下，毕竟IDEA在主流IDE中已经算是巅峰之作了，个人认为，仅次于VS。
空的工程默认写好了demo,一个Hello World!算是正规标配了，不得不说，作为菜鸡，看着文档确实又有种莫名的熟悉感，resources对比res, graphic对比drawable，感觉标签属性变化都不大，所以对于我这种菜鸡还是挺友好的学习起来不会太过复杂，毕竟从事Android开发很长一段时间了。运行后的结果：
4.分析编译运行结果
运行完我们大致看下产物，打开build目录，emem......确实是太友好了，和Android非常像，那肯定在outputs文件夹下了，熟悉的目录，熟练的点击。。。啊来，怎么是.hap，网上不是说apk文件正常安装使用的吗？？？难道是huaweiapplication的简写......
不管了，反正都是基于Linux的，后缀神马的不重要，说不定未来就有.adh了哈哈，白日先做个梦。回到正题，直接暴力一点，把.hap改成.apk用AndroidStdio打开瞅瞅看啥情况。。。。
熟悉的dex文件，对着官方文档我们瞅瞅看，首先我们看下官方的介绍：
图一就是官方的app原理图
对照着编译结果我们瞅瞅看，工程定义了一个entry，对于pack.info和config.json正常，resource文件居然都编译放在了assets文件夹下...abilities编译成.dex的Android执行文件，同时编译后还包含有一个entry_debug_signed_entry.apk文件......
打开这个apk，第一步肯定是看AndroidManifest文件了，emem...标准的app, android app。查看整个描述文件，可以看到就两个作用，定义了一个ShellMyApplication和一个MainAbilityShellActivity
那就一层一层的看下这两个类的实现，首先是ShellMyApplication：
package com.dyh.demo;
import ohos.abilityshell.HarmonyApplication;
public class ShellMyApplication extends HarmonyApplication {
@Override
public void onCreate() {
super.onCreate();
}
}继承自HarmonyApplication，直接创建没有做任何操作，然后看看HarmonyApplication：
emem...直接继承android.app.Application啊，那看看有什么额外的操作吧。代码很长，简单梳理如下：
(1) 静态单例返回HarmonyApplication，然后使用sdk中的ohos.appexecfwk.utils.AppLog更改了初始化日志的输出，使用统一的HiLogLabel。
(2) 提供获取加载ability的hashmap和注册task的方法以及其他的初始化application之前的工作
(3) 来看onCreate的过程： 首先就是EventRunner可以创建新的线程，来处理一些耗时的操作，这里就是鸿蒙的EventHandler的概念了，EventHandler是HarmonyOS用于处理线程间通信的一种机制，可以通过EventRunner创建新线程，将耗时的操作放到新线程上执行。这样既不阻塞原来的线程，任务又可以得到合理的处理。详细的介绍可能很多安卓开发者都会自然而然想起Handler的概念，具体差异之后菜鸡表示之后先了解了解再看看有什么区别。
public void onCreate() {
super.onCreate();
AppLog.d(SHELL_LABEL, "harmonyApplication onCreate call", new Object[0]);
EventRunner.setMainEventRunner();
try {
if (this.applicationHandleThread != null) {
ActivityManager.getService().setHmThreadToRtg("mode:set;tids:" + this.applicationHandleThread.getThreadId());
}
} catch (RemoteException var2) {
AppLog.e(SHELL_LABEL, "setHmThreadToRtg %{public}d failed", new Object[]{this.applicationHandleThread.getThreadId()});
}
AbilityDelegator.getInstance().setClassLoader(this.getClassLoader());
this.sendApplicationHandleMessage(4, (Object)null, 0L);
}后面就是通过ActivityManager获取类似AMS的功能进行类加载等操作了，和传统的Android application类似。
（4）然后后面除了熟悉的config更改，获取设置UserApplication外，加入了Handler Message的操作，估计就是使用EventHandler来处理进程间通信实现分布式的功能吧。
总而言之，看下来ShellMyApplication主要的工作就是对android application进行了二次封装，额外的操作不多，可以说是自定义了一个android applcation了感觉，可能是我还没有明白分布式软总线的具体实现来吧。下面我瞅瞅MainAbilityShellActivity的实现：
package com.dyh.demo;
import android.os.Bundle;
import ohos.abilityshell.AbilityShellActivity;
public class MainAbilityShellActivity extends AbilityShellActivity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
}老规矩继续看下AbilityShellActivity:代码太多只截开头
emem.......7个点，多一个不亏。依旧继承了android.app.Activity，不过实现了IAbilityShell的接口（只是这个接口并没有什么特别的操作）。一样的生命周期，权限申请，事件，window等等，可能多了一个AbilityShellActivityDelegate的封装，再生命周期调用时先使delegate生命周期先执行......
所以还是看看layout的布局吧，说不定有惊喜：
<?xml version="1.0" encoding="utf-8"?>
<DirectionalLayout
xmlns:ohos="http://schemas.huawei.com/res/ohos"
ohos:height="match_parent"
ohos:width="match_parent"
ohos:alignment="center"
ohos:orientation="vertical">
<Text
ohos:id="$+id:text_helloworld"
ohos:height="match_content"
ohos:width="match_content"
ohos:background_element="$graphic:background_ability_main"
ohos:layout_alignment="horizontal_center"
ohos:text="$string:mainability_HelloWorld"
ohos:text_size="40vp"
/>
</DirectionalLayout>很常规的布局，DirectionalLayout和Text作为经常使用的控件，官网也有详细的说明：
更换组件查看debug信息，也都是通过Surface注册绘制contentView。
简单理解为确实是一套新的UI但是对应的工作流程和加载绘制机制可能依旧依靠Android虚拟机，最大的区别可能就是官方说的分布式软总线了。但是一直没有找到相关资料，后来看到了程序IT圈的博客大致了解了一下。
5.分布式软总线
详细的分布式软总线设计可以参考OpenHarmony的仓库，与分布式软总线相关的就是https://gitee.com/openharmony/communication_dsoftbus 详细实现了发现链接，设备组网，数据传输的能力，业务方通过使用分布式软总线提供的API实现设备间高速通信，不用关心通信细节，进而实现业务平台部署与运行能力。
README中详细介绍了对应的分布式软总线组件架构，代码所在目录：
/foundation/communication/dsoftbus ├── interfaces # 接口代码 ├── core # 核心代码 │ ├── common # 通用代码 │ ├── adapter # 适配层代码 │ ├── authentication # 认证代码 │ ├── bus_center # 组网代码 │ ├── connection # 连接代码 │ ├── discovery # 发现代码 │ ├── transmission # 传输代码 │ └── frame # 框架代码 ├── sdk # 运行业务进程代码 │ ├── bus_center # 组网代码 │ ├── discovery # 发现代码 │ ├── transmission # 传输代码 │ └── frame # 框架代码 └── components # 依赖组件代码
以及相应的使用说明和使用流程，感兴趣的可以好好研究一下，这里就不再多说了。。先看下分布式软总线的架构：
整个全场景1+8+N的概念相信很多人都非常了解了，提供高可用的设备发现，设备组网和数据传输，具体代码的实现也都迁移到https://gitee.com/openharmony/communication_dsoftbus/tree/master/interfaces/kits 这里了，相信很多人也有学习过
首先就是discovery，一种基于COAP协议的设备发现机制，通过发送在一个局域网内发送广播来发现设备。所以README中就有约束：组网设备需在同一局域网中。同时COAP是支持可靠传输的轻量化协议，主要就是用于物联网设备（资源受限）。然后就是transport,源码很简单，基于session的数据传输。通讯对于华为来说永远都是最强的存在，所以高效的极简传输在物联设备间鸿蒙os占据极大的优势。最后一些设备认证与管理等代码都可以详细研究下具体的代码实现。
总结
整个demo运行下来可以发现，鸿蒙os对比Android而言不同点就是：使用Ability和AbilitySlice两个基础类作为应用UI开发框架，实现了代码可以在手机，watch，平板以及嵌入式智慧屏等不同的设备上都可以运行。emem，有点像Flutter......;然后就是分布式软总线架构，加上独特的rpc机制，实现了设备发现，设备组网和数据传输，提供了稳定高效的近场设备的连接与通讯。具体在手机上运行的话，看起来还有很多基于Android的地方，可能使用HMS，分布式软总线和Ability代替了谷歌的GMS服务。因此后面取消AOSP可能还需要一定的时间。
菜鸟的我勉强体验过物联网设备应用的开发，就个人感觉，鸿蒙os具备一定的优势但是短时间无法达到一定地步，首先HMS代替GMS很多时候都是有一定的可能但是依旧需要不少的时间来发展整个生态，因此更多的物联网设备厂商在大规模应用之前肯定优先考虑GMS的使用占比的。其次，最重要的一点，物联网设备很难愿意使用更高的成本去让设备搭载鸿蒙os,而liteOS的可替代的成熟方案也有很多，像RTOS那种，在资源受限的物联网设备上具有更高的欢迎度。 因此鸿蒙os可能需要更多成熟成功的案例来推动更多的物联网设备厂商搭载。
以上是菜鸡程序员在运行完hello world后的感觉，可能有不少错误的地方，欢迎评论指正。还有很多鸿蒙的优势因为没有更加仔细的了解过就不在这里提出了。相信很多人都和菜鸡我一样对鸿蒙抱有很高的期待，希望正式取代碎片化的物联网设备系统，虽然这可能需要不少的时间。
京公网安备 11010502036488号