my’blog

有大神研究过华为 P40 上的鸿蒙 OS 2.0 吗事实它到底是个全新的自主操作系统还是个套壳安卓

有人曾说:“没有调查就没有发言权。”

最近,鸿蒙系统系统备受关注,有支持也有反对,有乐观也有衰落,“自主全场景分布式系统”和“安卓外壳”互相争论。

作为一个18流码农,为了了解行业趋势,体验鸿蒙系统的发展历程,找出鸿蒙系统的特色和不足,看看有没有新的机遇,看看喧闹的人群中谁对谁错,我特意体验了一下鸿蒙系统系统正式开通,马上升级的时候的发展。

00 HarmonyOS到底怎么实现的——扒皮HarmonyOS

为了理解一个软件是如何实现的,最好检查一下源代码。

然而,承诺在2020年开源的OpenHarmony项目,直到现在才面向嵌入式设备开源,这条路自然行不通。

不得不退而求其次,看看开放的SDK、IDE、开发示例、编译产品,看看鸿蒙系统是如何实现的。

00-00安装IDE-配置环境-编译运行。

这部分很简单,只要下载DevEco Studio,按照文档一步一步来就可以了。

仅选择两个JS模板作为模板:电话>刷新功能能力。

然后进入下一步,申请虚拟机,编译运行成功。

00-01分析编译后的产品。

运行成功后,大致分析一下编译产品,找到程序入口,看看代码是怎么运行的。

单击构建文件夹并将其打开。哇哦!!!这个目录结构和Android太像了,所以我熟练的打开outputs文件夹找到apk文件。

。哈普。??为什么不是我期待的那样?但是多年入侵Linux的经历告诉我,后缀都是浮云,所以果断改了。也许吧。apk,然后用Android Studio打开。果然:

比较官方应用程序逻辑视图:

我们发现:

1.找不到描述每个HAP属性的http://pack.info。

估计项目只定义了一个Entry,没有定义一个Feature,所以只生成了Entry的安装包,但是根据官方文档。

Entry可以独立安装和运行,当只定义了一个Entry时编译这个包是有意义的。

2.App逻辑视图中的config.json正常。

3.应用程序逻辑视图中的能力实际上被编译到。Android包的dex可执行文件,而js定义的接口、视图、逻辑其实都包含在资产中,有点棘手。

4.编译后的可执行文件实际上包含一个。apk文件。这个不速之客根本无法体现在App逻辑视图中,值得怀疑。

然后,我们将重点分析这个entry_signed_entry.apk,分析这个不速之客在App安装包中扮演了什么角色。

00-02分析entry _ signed _ entry.apk

继续用安卓工作室打开这个文件。

是一款标准的安卓App!!于是熟练地点击安卓应用描述文件:AndroidManifest.xml

根据描述文件,整个apk只做了两件事:

定义Application为ShellApplication定义MainActivity为MainAbilityShellActivity

嗯……...这个名字真的很直白。

按照Android开发的惯例,从构建文件夹中找到这两个类的相关文件。

果然,不费吹灰之力,然后分析源代码:

首先分析我的应用程序的定义文件外壳:

ShellMyApplication是从鸿蒙系统SDK的Harmony Application继承而来的,但是什么都没做。然后看一个应用程序:

嗯……...俄罗斯娃娃?仍然什么都不做,然后继续寻找它的父类:HarmonyApplication:

看这么大段的引用和变量定义,应该是正主没错了,不过HarmonyOS的HarmonyApplication竟然继承自Android的Application,这件事就得说道说道了看着这么长的引用和变量定义,应该没错,但是鸿蒙系统的HarmonyApplication实际上是继承了Android Application,所以不得不说。

HarmonyApplication的整个文件非常长,所以不会发布任何代码。这个类主要做以下工作:

1.初始化鸿蒙系统应用程序。...

2.输出鸿蒙系统应用程序初始化的日志。......

3.将鸿蒙系统的能力加载到安卓应用的哈希表中。.........

4.接收系统生成的各种事件,并将它们转发给鸿蒙系统应用程序。............

5.初始化事件运行器。根据ohos包的代码,估计是官方文件中提到的“分布式软总线”,是鸿蒙系统所谓“分布式设计”的相关实现。这一部分将在后面分析。

代码农民确实是诚实的人,他们的名字是如此诚实和恰当:

ShellApplication的功能是安卓的Application提供了一个Shell,鸿蒙系统的Application寄生在这个Shell中。

然后我们来看看MainAbilityShellActivity,它还是一个玩偶设计,直接看具体实现:

MainAbilityShellActivity还是继承了安卓的Activity,整个文件还是很长,但是逻辑很简单,就一个功能:

安卓主活动的生命周期、意图、触摸事件、按键时间和权限申请结果通过AbilityShellActivityDelegate(代理)转发给鸿蒙系统能力。

果然,它不会辜负壳牌的名字。

本来想打开安卓…鸿蒙系统的应用布局调试界面,但是在设置中找不到,233333...

但是,根据文章@落花时节吃狗粮。

/p/338663467

学习

这篇文章写于2020年底,到现在才三个月。估计具体执行没有变化。

00-03分布式软总线。

鸿蒙系统最大的卖点是其宣称的“面向万物互联时代的全场景分布式操作系统”,这也是其最大的特色。

从官方文件来看,无论是开发层面所谓的“分布式设备虚拟化”、“分布式数据管理”、“分布式任务调度”,还是政府目前示范的“无缝流转”、“多屏协同”,通信基础都是“分布式软总线”,所以我们将重点了解一下是如何实现的。

具体到开发文档,没有找到关于“分布式软总线”的API,只找到了三个类似于其“分布式技术”中描述的功能:

它们是:

分布式任务调度分布式数据服务分布式文件服务

有了这三组API,我们就可以通过“排列组合”实现官网宣称的“分布式”的所有特性。因此,我们可以找出这三组API是如何直接在SDK中实现的,然后我们可以追溯到源头,找出如何实现“分布式软总线”。

打开ohos.jar包后,遇到了第一个问题:不会显示任何代码!!!

引发了新的运行时异常(“存根!”)发生。);大致是因为安全考虑或者担心开发者可以从源代码中找到可以修改系统行为的底层API或者其他原因,具体实现在编译时隐藏在Java开发中。这种情况比较少见,可能只会出现一些重要的底层API。但是,第一次看到这个ohos.jar包的源代码是完全隐藏的!!!鸿蒙系统有多害怕发现它的小秘密?

然而,我们只想看看鸿蒙系统的设计思想,但我们不研究它的具体实现,所以我们不需要源代码。我们只看类名、函数名和依赖关系,大胆猜测,仔细验证。

通过分析依赖关系,发现大多数与分发相关的包依赖于:

ohos.rpc.*

以及分布式任务调度所依赖的正式文档包。

以及官方文件《分布式软总线示意图》。

我们有理由相信,所谓的分布式软总线实际上是一种私有的RPC协议。

RPC 远程过程调用(Remote Procedure Call),RPC是为了解决IPC(进程间通信)所用的通讯技术,早在1981年由Nelson提出并开始发展RPC在分布式系统中的系统环境建设和应用程序设计中有着广泛的应用RPC目前有很多成熟的实现,比如阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud

结合RPC和鸿蒙系统的特点,鸿蒙系统“分布式软总线”采用RPC也就不足为奇了。

但是,阿华是一家立志模仿和超越Aguo的公司,甚至有着同样的名字:这么专业的名词居然可以做得这么通俗易懂!

00-04分布式软总线的具体设计。

上面说的再坚决,到头来也只是个猜测。

而且,作为鸿蒙系统的核心特色和杀手锏,作为一个18行码农,一个豪放的从业者,怎么能不好奇它的设计思路呢?

但是因为没有源代码,估计大部分都是在系统级实现的,ohos.jar只是一个相关的调用,所以这条路肯定行不通。

这时,灵感闪现了。由于鸿蒙系统是一个“全场景分布式系统”,该协议不仅必须在Androi上实现......鸿蒙系统手机系统,也可以在其他类型的设备上使用。

这时,抵押开源的OpenHarmony又回到了我的视线。既然OpenHarmony项目已经开放了嵌入式设备的相关实现,或许还有这个协议的相关源代码。

那么,让我们来看看OpenHarmony的仓库。

OpenHarmony: OpenHarmony是开放原子开源基金会(OpenAtom Foundation)旗下开源项目,定位是一款面向全场景的开源分布式操作系统,第一个版本支持128K-128M设备上运行。

天助他人,这与分布式软总线有关:

OpenHarmony/communication_services_softbus_lite

该项目实现了软总线发现、组网、传输相关协议,这是熟悉编程的朋友应该能够想象到的。通过该项目,可以实现“全场景分布式”中列出的所有功能。

部分代码又臭又长,估计很多人对它不感兴趣,也不确定整个平台都是这样实现的,我们就不具体分析了,只谈设计思路和一般工作流程。不同平台的具体实现可能不一样,但设计思路应该差不了多少。

分布式软总线主要有以下工作模块:

1.设备发现:设备发现协议采用CoAP协议,通过在局域网中发送广播来发现设备。具体实现与本文无关,不再赘述。有兴趣的可以自己看。在此包中:

2.数据传输:基于Session提供统一的数据传输功能,但网络通信是华为的老业务。估计没什么问题,所以仔细分析了一下。代码在:

3.设备认证和管理:这部分主要是为了安全,代码在:

00-05其他。

整个OpenHarmony项目有一些有趣的实现:

OpenHarmony/ace_engine_lite

这应该就是如何编译JS开发的Ability接口,以及如何在嵌入式设备上渲染,这也是为什么鸿蒙系统可以使用多种语言开发接口的原因:

各种小程序和Flutter相关框架都是这样设计的。

OpenHarmony/appexecfwk_interfaces_innerkits_appexecfwk_liteOpenHarmony/aafwk_interfaces_innerkits_abilitymgr_liteOpenHarmony/aafwk_services_abilitymgr_liteOpenHarmony/appexecfwk_services_bundlemgr_liteOpenHarmony/aafwk_frameworks_kits_ability_lite

......,还有很多,所以我就不一一列举链接了。

都是用来实现“无缝流转”、“远程启动”、“迁移”等与能力相关的功能。

01 华为到底在HarmonyOS上做了哪些工作

从编译的产品和开源代码来看,华为对于其所谓的“全场景分布式操作系统”主要做了两件事:

1.定义了基于capability的应用开发框架,可以屏蔽不同操作系统之间的差异,使开发的代码能够在不同的操作系统中运行。

在鸿蒙系统之前,类似的技术和更成功的技术是小程序框架和Flutter。

它们之间的区别:

小程序:在运行的应用程序环境中。

Flutter:致力于移动、桌面、网络和嵌入式全覆盖。

能力:主要针对华为生态中的手机和嵌入式设备设计。

虽然他们各自的目标不同,但设计思路是相似的:自绘UI和屏蔽系统差异。

2.定义了一个名为“分布式软总线”的自有RPC协议框架。基于该RPC协议封装了一系列常用的API,屏蔽了设备间繁琐、多样、差异较大的通信方式,提供了稳定、统一、可靠的近场通信协议。

具体到鸿蒙系统要在华为手机上升级,估计有:

原创安卓系统——GMS+HMS+分布式软总线+以能力为中心的应用开发框架=鸿蒙系统。

具体到原理图,估计是:

根据分析结果,鸿蒙系统的一些地方确实夸大了宣传,比如:

随时换掉AOSP,这里的「随时」,估计在近五年内不会实现,在此之前,去掉Android虚拟机,HarmonyOS能不能正常运行,我是持怀疑的态度的「全场景分布式操作系统」,根据「分布式软总线」相关代码,这里的「全场景」,估计是同一个局域网内的「全场景」、同一个局域网内的万物互联

当然,按照目前的设计思路,鸿蒙系统的大部分宣传是完全有可能或者已经实现的,比如:

由于Ability、分布式软总线等技术屏蔽了操作系统差异,一点点挖空、取代AOSP是完全有可能实现的(虽然我认为这个时间会持续5-10年,到时候Android、HarmonyOS存不存在都不能确定)02 HarmonyOS到底是不是Android套皮

回到我们最初的问题:“鸿蒙系统是一个全新的自主操作系统还是一个外壳安卓系统?」

分析代码后,我发现我也回答不了这个问题:

假设这是一个全新的自主操作系统,它确实是从Android发展而来的。

说它不是全新的自主操作系统,但它确实与安卓有明显的区别和特点。

然而就在这个时候,我发现这个问题和2000年提出的一个哲学悖论非常相似:忒修斯的船。

特修斯之船(The Ship of Theseus)亦称为忒修斯悖论,是一种有关身份更替的悖论。假定某物体的构成要素被置换后,但它依旧是原来的物体吗?说是一艘可以在海上航行几百年的船,归功于不间断的维修和替换部件。只要一块木板腐烂了,它就会被替换掉,以此类推,直到所有的功能部件都不是最开始的那些了。问题是,最终产生的这艘船是否还是原来的那艘特修斯之船,还是一艘完全不同的船?如果不是原来的船,那么在什么时候它不再是原来的船了?

回到这个问题:

我换了一行安卓代码,那么还是安卓吗?

我换了一个安卓的模块,那么还是安卓吗?

我给安卓加了一个模块,那么还是安卓吗?

……

这个问题哲学家们争论了两千年,但我相信我们暂时无法争论,争论这个问题没有多大意义。

所以,我们不妨放弃这个问题,换一个新的问题,这也是我们比较关心的问题:“鸿蒙系统能否实现华为在华为终端上设定的目标?」

赞美诗

关于这个忒修斯悖论,评论区有很多讨论,个人最喜欢的答案是老师《矛盾论》中的量变与质变定律:

任何事物都是质与量的统一体量变是质变的必要准备质变是量变的必然结果量变与质变是相互渗透的

就鸿蒙系统而言,目前是量变还是质变,取决于你基于自己知识的判断。

至于鸿蒙系统能否以量变引起质变,只能说取决于华为自身的奋斗以及历史进程。

鸿蒙系统能达到华为的目标吗?

这一部分原本是想探讨鸿蒙系统的发展前景和能否成功。

但是,要想看清楚这一点,需要扎实的理论知识,丰富的行业经验,以及对商业活动的一些见解。拥有这种能力的人,长期以来都是行业领袖和技术大咖。

所以找了几天资料,还是没有头绪,就想把这个坑悄悄给鸽子。

但是没想到会看到这么多人,所以不知道怎么鸽子,所以只能逼着大家跟风。

一般来说,影响一个商业操作系统成败的因素有很多,但一般从系统优势、商业运营、生态建设三大方向来分析。

那么我们就从这三个方面来讨论鸿蒙系统是否有可能成功。

03-00系统优势。

目前,鸿蒙系统有两个独特的特点:

1.一个跨平台的JavaScript应用程序框架(我们稍后称之为Ace Engine,原因如下)。

2.分布式软总线。

赞美诗补充说明。

这个JavaScript应用程序框架是能力最重要的组件之一。写00-02的时候,没有仔细阅读这部分的代码和文档,写的不清楚。现在,如果你在这里写补充内容,你就不会修改上面的内容。这些补充内容也可以在评论区回答一些问题。补充内容如下:

1.虽然鸿蒙系统声称可以用Java、JavaScript和c来编写UI界面,而且这个UI界面可以跨设备,但目前在实际开发中,不同的设备支持不同的语言:

在手机设备上,只能使用Java、JavaScript写界面(相关文档 : Java UI框架、JS UI框架 两部分)在嵌入式设备上,只能使用C、JavaScript写界面(相关文档 :JS应用开发、系统基础子系统集>图形及UI子系统 两部分)只有JavaScript写的界面可以跨设备使用

只有JS UI接口可以跨设备,这是这个JavaScript跨平台框架的功劳。

2.JavaScript应用程序框架的嵌入部分是开源的,这在上面已经提到:

OpenHarmony/ace_engine_lite

框架图如下:

其中:

JS引擎(JS runtime)是三星开源的IoT JavaScript引擎:JerryScript除JS引擎外,其他应该都是华为自己写的JS应用框架只负责解析JS Bundle(我们用JS写的界面编译后的产物),渲染交给了有C写的原生框架因此C原生框架不可能跨设备,只能在LiteOS中使用手机端能不能使用这个C原生UI框架未知,但是开发文档上没有提及,应该是还没有开放或实现(是哪一个不太清楚,但是嵌入式设备与手机UI框架的实现难度不是一个数量级,LiteOS上的C语言UI框架应该满足不了手机上的复杂且苛刻的要求,所有不可能直接使用)

因为这个JS应用框架的LiteOS开源部分被命名为ace_engine_lite,所以我们暂时将这个应用框架称为Ace Engine。

3.这个JS应用框架的移动版本还没有开源,所以我们不知道具体的实现,但是我们在上面的文章中提到过:

JS Bundle由JS Framework解析后将数据交给了Android,由Android的负责将其渲染在SurfaceView上

这就是为什么我怀疑鸿蒙系统目前离不开AOSP。

这就是为什么我认为鸿蒙系统可以支付空AOSP。

4.接下来,让我们看看能力框架图:

其中:

User Native Ability在LiteOS中指的就是C语言实现的Ability;在HarmonyOS中就是Java实现的AbilityAbilityKit在LiteOS中应该是用C语言自己实现的,但在HarmonyOS中,是基于Android的Activity实现的图中的蓝色部分在LiteOS中很明确,但在HarmonyOS中怎么实现目前没有相关代码,不得而知(个人猜测,根据上面代码分析,有部分在ShellApplication(应用内)实现,有部分为系统服务,也有部分在内核中实现)

5.鸿蒙系统宣称的双核一个是AOSP,那么另一个应该是4中以能力为核心的应用框架。

不管它是否符合操作系统的定义,这个内核的独立性在现阶段是值得怀疑的,只是因为3的存在。

当然,因为“3”的存在,如果我们遵循这个设计思路,那么鸿蒙系统绘画的建筑图就可以确定了。

又是Ps。

其实这些框架中提到的一些东西已经实现了,还有一些由于时间的原因没有实现,但是技术已经被国内的工程师掌握了,实现也是时间问题,除了两个部分:

Linux Kernel(在内核层中)AOSP(大致对应图中的UI框架+用户程序框架+Ability框架)

别看这两个数字,但是很深刻。目前,这两部分是中国唯一不确定的部分。

为什么我不能替换Linux内核?中国没有人能真正修复这个(操作系统)。

为什么不取代AOSP?我们是为了兼容性;那为什么《能力》要由AOSP来演?那是因为在中国没有人能解决这个问题(计算机图形学)。

并且问为什么LiteOS中的JS Framework是自己实现的,而只有JS运行时需要使用三星开源的JerryScript(不知道移动版用什么)。因为这个国家没有人确定(编译原理)。

操作系统、计算机图形学、编译原理,这三个产品是计算机的三大天坑,其中的难点和障碍非专业人士很难理解(经过长时间的讨论,“操作系统”已经回归“操作系统”,23333……)。

鸿蒙系统专注于物联网系统。

分布式软总线技术封装了物联网通信技术(NFC、蓝牙、WIFI……)和协议(CoAP、RPC……),抽象了数据格式(鸿蒙系统IDL)和服务(PA),使得局域网内的设备可以方便地进行通信、交换数据和调用远程服务,设备之间看起来是集成的。

Ace存在于不同设备之间,可以抽象出用户界面(UI)(抽象为fa),实现一次开发,多终端部署。

分布式软总线+Ace Engine是的核心设计思想,在王的采访中也有提及。

那么这两种技术有“技术壁垒”吗?可以作为鸿蒙系统的护城河吗?个人认为答案是否定的。

先从技术层面来看。

我就不说鸿蒙系统的嵌入式操作系统了。玩过物联网的人都知道,市场上有很多竞争产品,包括腾讯的tiny、AliOS Things、小米的Vela、RTOS……...

与其他设备相比,LiteOS最大的特点是功能封装更友好、更统一,但最大的缺点也来自于此:需要的硬件资源太多,硬件成本对于大多数IoT设备来说是难以承受的。

如果把这部分去掉,和其他Iot系统没有太大区别。

再看看王牌发动机。

熟悉编程的朋友一定知道,Ace Engine和小程序以及Flutter的设计思路和架构是完全一样的。Flutter做不到,因为Dart虚拟机无法在资源有限的嵌入式设备中运行。小程序的对比呢?

以生态最大的微信小程序为例。自诞生以来就支持安卓、IOS、鸿蒙系统(因为兼容安卓),也因为有WMPF(微信小程序框架)的存在。

目前微信小程序还可以在Windows、Mac和嵌入式设备上运行,基本覆盖了Ace Engine的所有设备(鸿蒙系统和嵌入式设备)以及Ace Engine不支持的设备(IOS、Mac和Windows)。

CoAP+RPC(分布式软总线)怎么样?且不说开源方案很多,就是从零开始实现的。目前国内能实现的公司数都数不过来,恐怕手脚都不够用。

那么,依靠这些,华为能否为鸿蒙系统培育自己的物联网生态呢?我个人的看法是悲观的。

鸿蒙系统在接受采访时说:

个人认为,作为一个提出概念20多年、孵化10多年的行业,与“分布式软总线”相关的技术和协议或多或少在不同的产品中得到了应用,但物联网并没有在这个时间点爆发。通信开发成本高确实是不爆炸的原因之一,但绝对不是根本原因。

退一步说,即使这个模型有效?这项技术不存在垄断性的技术壁垒。以各种手机厂商和移动互联网厂商的能力,鸿蒙系统最多只能拿到半年到一年的第一笔红利。

不谈手机厂商,就拿微信来说:

除了应用程序内置的RPC协议不如系统内置的RPC协议:

在微信小程序中做物联网应用,可以支持更多的平台(HarmonyOS vs Android+IOS)在微信小程序中做物联网应用,开发成本更低(小程序 vs App)在微信小程序中做物联网应用,推广成本更低(微信小程序生态 vs 华为App生态)在微信小程序中做物联网应用,获客成本更低(即开即用 vs 下载、安装App)……

如果你是一个产品经理,在想法验证阶段,面对这么多需要考虑的指标,你更喜欢哪一个?到时候,恐怕应用响应慢、通讯速度慢会成为最后考虑的因素。

一旦想法得到验证,有多少服务不会得到整个平台的支持,而是会主动绑定到一个平台?

这是鸿蒙系统想要成功需要解决的第一个问题:

如果“分布式软公交”这条路不值钱,那么作为鸿蒙系统最大的卖点,鸿蒙系统所做的一切努力都是徒劳,鸿蒙系统终将失败;

但是,如果“分布式软公交”之路行得通,其他厂商很容易借鉴和学习,但鸿蒙系统却无法筑起足够宽的“护城河”,培育自己的生态。

03-01商业运营。

商业操作系统存在两个基本条件:

足够多的用户可以平衡厂家、用户、开发者利益的政策

因为操作系统太多,用户不够,就不说了;死于第二个因素的最著名的操作系统是Windows Phone,它一意孤行,反复跳跃,导致微软错过了整个移动互联网时代。

先说用户问题。目前可以肯定的是,在鸿蒙系统没有成功趋势之前,绝大多数搭载鸿蒙系统的手机和使用鸿蒙系统的用户都是华为和荣耀用户。

让我们以两年的更换周期为例。目前,华为手机存量约为4亿部。

在这个时间点,鸿蒙系统生态与GMS生态竞争的可能性很小,所以首批升级的鸿蒙系统绝大部分应该是国内用户,而这部分手机的存量大概在2.2亿左右。

由于GMS被禁,华为海外市场预计将继续快速萎缩。

2020年9月15日5nm麒麟芯片停产后,华为终端产品持续缺货,预计华为国内市场份额将快速萎缩。

根据以往安卓手机系统升级比例的经验,的装机量永远达不到王提到的生存线。

这也是鸿蒙系统要想成功需要解决的第二个问题。

在商业政策上,华为的整体态度是开放的(老板的态度)。

但在管理层,这成为华为的首要任务(于宗的态度)。

可以预见,未来一段时间,鸿蒙系统将主要服务于华为的1+8+N战略。

然后,在鸿蒙系统证明这是大势所趋之前,其他手机厂商估计也玩不过华为。

所以如何为关键的“1”即移动终端获取新用户,也是华为手机产能有限时需要解决的问题。

在第三方应用方面,一方面意味着每一个开发者都是华为想要聚集的火花。

另一方面,在实施的时候,只和大厂合作。

在2021年的这个时间点,作为一个不到一个月就要发布并宣称开源的新系统,它依然像宝藏一样隐藏着,对非核心开发者来说就像是一个贼卫队。技术实现细节模糊,虚拟机在云端运行。开发文档只有UI和分布式软总线两部分,其他部分还是安卓上的HMS SDK。

这对于很多开发者来说是不合理的。

将于8月发布的Android 12已经在3月发布了开发者预览版。

不说别的,就对比一下两者的开发文档。

Android 12 Developer Preview | Android Developers产品文档-华为鸿蒙HarmonyOS应用开发

不难发现为什么很多开发商对鸿蒙系统不看好。

这是鸿蒙系统面临的第四个问题:对开发商的政策。

03-02生态建设。

操作系统生态基本上是基于操作系统的,比如MacOS、Windows、iOS。

但由于安卓的碎片化、用户的海量化、谷歌服务在中国的封禁、国内安卓厂商的强势崛起等等,将其分为了国内和国外的生态系统。

在海外,GMS占据垄断地位,HMS+华为硬件暂时无法与之抗衡。

在对比GMS和HMS时,很多人通常会从技术角度进行争论,认为HMS在某些技术指标上领先于GMS,而华为在应用商店事业部的盈利证明了HMS在海外可以替代GMS。我认为这种观点不符合实际情况。

其实GMS框架在技术上并不难,但GMS替代不了的不是框架本身,而是GMS连接到Youtube、Gmail、Gmap、Google Pay、Google Search以及海外安卓应用的账号系统。

HMS和GMS之间的竞争不是这两个框架的竞争,而是HMS和GMS所承载的专属服务的竞争。HMS要想干掉GMS,前提是干掉这些总用户20亿+的谷歌服务。

在这方面,华为连同国内的一票互联网厂商可能都没有必胜的把握,HMS短期内基本不可能在海外取代GMS。

另一方面,HMS取代GMS也不是不可能。Tik Tok出海成功后,越来越多的中国互联网服务被海外用户接受。中国互联网服务取代美国互联网服务并非不可能。

但到那时,英国皇家海军仍将面临两个问题来取代通用汽车。

1.华为终端能否活到那个时候。这要看华为芯片问题能否解决,在HMS缺乏关键应用的情况下,是否还有人选择华为。

2.华为是如何说服中国互联网厂商放弃GMS,拥抱HMS的?因为两个生态系统都支持它,所以HMS仍然没有发言权,也没有权利与GMS竞争。

在中国,因为谷歌服务在中国被禁止,又因为GMS没有任何技术壁垒,又因为HMOV的四家手机厂商除了华为独有的芯片设计能力外,在手机设计方面的技术实力相差不大,都实现了类似GMS的框架。

华为开发者联盟 - 智能终端能力开放小米开放平台OPPO开放平台vivo开放平台

HMOV总是提供类似的移动服务。如果你点击它,你会发现他们提供的服务没有太大的不同。

因此,在中国,HMS、MMS、OMS、VMS的市场份额大致相当于他们手机的市场份额,所以腾讯、阿里接入HMS不会给HMS提供任何额外的竞争力,因为他们在华为接入HMS时,自然会通过小米接入MMS,OPPO接入OMS,Vivo接入VMS。

而且,基本上他们只接入推送服务,比如更重要的账户系统和支付系统,这些都会牢牢掌握在自己手里。即使对于推送服务,为了保证自己的业务和消息投递率,他们在访问官方推送服务后,仍然在后台维护自己独有的推送服务。推送服务背景下的应用相互启动和功耗问题仍未解决。

所以腾讯和阿里接入HMS是肯定的。在鸿蒙系统问世之前,他们的许多应用程序已经被访问过了。但是,如果腾讯、阿里接入HMS就能提高HMS的竞争力,恐怕是很多人的一厢情愿。

最后说说鸿蒙系统的物联网生态。

很多人认为软件没有实物,没有规则,想要就可以做。

这也是很多人的一厢情愿。计算机科学是一门科学,是逻辑的产物,也受相应规则的制约。

对于鸿蒙系统来说,它封装了物联网通信协议,使得通信更加方便。提供跨平台JS运行时,使得UI界面可以一次开发运行,确实让相关开发更加方便。

但是有利也有弊。一般来说,软件封装水平越高,其通用性越差。

鸿蒙系统对一些物联网场景做了针对性的优化,确实意味着可以在这些物联网场景中更方便的开发,但也意味着如果你的物联网设备不适合这些场景,在鸿蒙系统开发会比采用其他平台产生更高的成本。

例如:

1.对于绝大多数IOT设备来说,运行鸿蒙系统的IOT系统没有这么奢侈的硬件,通过接口实现的交互也没有那么多,所以采用LiteOS就意味着对他们没有帮助,增加成本(其他IOT系统有更通用的解决方案,成本更低)。

2.鸿蒙系统更加私有化的包装也意味着更难与其他物联网系统打通。华为估计自己做不到的所有物联网设备都采用鸿蒙系统系统,所以鸿蒙系统和非鸿蒙系统物联网设备的交互也比较困难。

3.个人认为,物联网设备的互联互控并不是解决当前物联网行业困境的关键。目前物联网产品的解决方案大部分都是关于给手机App或者语音控制权的,但是这些对于我们的生活来说都不是很方便,有点无味,令人遗憾。

例如:

我的手机和扬声器可以控制我的烤箱,而我的烤箱仍然不能烤出美味的面包和蛋挞o (╥ ╥) o。

我的手机和音箱可以控制我的炒菜锅,还在我的炒菜锅里炒的菜都要糊了,那有多糟糕,o (╥ ﹏ ╥) o。

我的手机和扬声器可以控制我的空键,但室内温度仍然无法自动调节到让我感到舒适的温度。

……

我认为这些问题是目前物联网行业遇到的问题的关键。

这也是我不喜欢鸿蒙系统物联网生态布局的原因。确实将原有物联网设备的开发成本降低了一个数量级,但仍然没有解决上述问题。毕竟就算所有的物联网设备都可以畅通无阻的进行通信,又有什么用呢?是我买给他们说悄悄话的吗!!!

……

(这个问题太大,要考虑的问题太多,能力有限。考虑不完全,表达不清楚,不要写下来。)

 


posted @ 21-10-30 11:36  作者:admin  阅读量:

Powered by 91国产精品 mp4 @2018 RSS地图 HTML地图

2013-2021 版权所有