赞
踩
目录
鸿蒙系统个人理解,他就是一个大杂烩,但也自成体系,核心的理念是“分布式总线”,将任何外设看成一个独立的组件,虚拟独立设备,即假设在华为手机上自带的Lcd,Camera,NFC,Sensor,也都用软总线来构建,虚拟化,实际上并不是;这样才能实现他理想化的IOT外物互联,每一个小设备都是一个原子单元设备,可以远程操控,连接。然而所谓的"软总线”本质却是一个 局域网协议,只是提的概念名称而已,而且是套娃DLNA协议,大家可以去查下。
鸿蒙的LiteOS才是用来对标Linux的,值得注意的是LiteOS和Linux是一样的,都是宏内核而不是之前宣传的微内核,鸿蒙的微内核可能要到过段时间才会发布。经过一年的实战,这个提法是错误的,liteos是个冒牌货,根本没法用,实际上内核用的最多的是一个lite-m,类似freeos,一个就是linux;所以网上很多软文并不可信。那么鸿蒙对标的产品是什么呢?是安卓和Windows。这也让安卓特别的难受,因为与它正在开发的Funchsia系统在地位上有较大的吻合,都是面向IOT设备的操作系统。我们可以看看这张图,在鸿蒙的整个框架中内核只是占比较小的一部分,而内核这部分里还分了两个内核子系统:Linux和LiteOS。所以内核位于鸿蒙就像心脏位于人体,非常重要但占比很小。如果把内核类比成系统就好像把心脏类比成人一样,不合适。
在官网上看到鸿蒙 OS 的简介是,分布式能力造就新硬件、新交互、新服务,打开焕然一新的全场景世界。以及发布会提及最多是他的万物互连,全场景,分布式,微内核,软总线。换句话说,鸿蒙OS 是为全场景,分布式设计的,微内核,软总线是他重要的实现。
硬件互助,资源共享
1,分布式软总线 是个半成品
分布式软总线是多种终端设备的统一基座,为设备之间的互联互通提供了统一的分布式通信能力,能够快速发现并连接设备,高效地分发任务和传输数据,分布式软总线示意图如下图所示。
基于网络互联、交互的系统,开发者往往需要适配不同网络协议和标准规范;鸿蒙系统设定的分布式开发模式中,无需关心网络协议的差异及组网方式,业务开发与设备组网解耦,仅需监听设备上下线;
分布式软总线提出了异构网络组网,自动构建一个逻辑全连接网络,以解决设备间不同协议交互的问题。设备上线后会向网络层注册,同时网络层会与设备建立通道连接,实时检测设备的变换。
网络层负责管理设备的上线、下线变换,设备间可以监听自己感兴趣的设备,设备上线后可以立即与其建立连接,实现零等待体验
分为以下4个单元(代码结构如下图所示):
1,discover:提供基于COAP协议的设备发现机制;
2,authmanager:提供设备认证机制和知识库管理功能;
3,trans_service:提供身份验证和数据传输通道,
4,os_adapter:检测运行设备性能,决定部分功能是否执行。
discovery的实现前提是确保发现端设备与接收端设备在同一个局域网内且能互相收到对方的报文。流程为以下三步:
1,发现端设备,使用coap协议在局域网内发送广播;
2,接收端设备使用PublishService接口发布服务,接收端收到广播后,发送coap协议单播给发现端;
3,发现端设备收到回复单播报文,更新设备信息。
各个设备以服务的形态推送、发布,发布后周边的设备可以发现、连接并与之通讯交互,源代码位于discovery\discovery_service\source目录中。
源码为软总线模块部分,如需获取软总线源码,请访问网址: https://gitee.com/openharmony/communication_dsoftbus
分布式设备虚拟化平台可以实现不同设备的资源融合、设备管理、数据处理,多种设备共同形成一个超级虚拟终端。针对不同类型的任务,为用户匹配并选择能力合适的执行硬件,让业务连续地在不同设备间流转,充分发挥不同设备的资源优势,分布式设备虚拟化示意图如下图所示。
分布式数据管理基于分布式软总线的能力,实现应用程序数据和用户数据的分布式管理。用户数据不再与单一物理设备绑定,业务逻辑与数据存储分离,应用跨设备运行时数据无缝衔接,为打造一致、流畅的用户体验创造了基础条件。分布式数据管理示意图如下图所示。
分布式任务调度基于分布式软总线、分布式数据管理、分布式Profile等技术特性,构建统一的分布式服务管理(发现、同步、注册、调用)机制,支持对跨设备的应用进行远程启动、远程调用、远程连接以及迁移等操作,能够根据不同设备的能力、位置、业务运行状态、资源使用情况,以及用户的习惯和意图,选择合适的设备运行分布式任务。以下图的应用迁移为例,简要地展示了分布式任务调度能力。
HarmonyOS提供了用户程序框架、Ability框架以及UI框架,支持应用开发过程中多终端的业务逻辑和界面逻辑进行复用,能够实现应用的一次开发、多端部署,提升了跨设备应用的开发效率。一次开发、多端部署示意图如下图所示。
统一OS,弹性部署
HarmonyOS通过组件化和小型化等设计方法,支持多种终端设备按需弹性部署,能够适配不同类别的硬件资源和功能需求。支撑通过编译链关系去自动生成组件化的依赖关系,形成组件树依赖图,支撑产品系统的便捷开发,降低硬件设备的开发门槛。
支持各组件的选择(组件可有可无):根据硬件的形态和需求,可以选择所需的组件。
支持组件内功能集的配置(组件可大可小):根据硬件的资源情况和功能需求,可以选择配置组件中的功能集。例如,选择配置图形框架组件中的部分控件。
支持组件间依赖的关联(平台可大可小):根据编译链关系,可以自动生成组件化的依赖关系。例如,选择图形框架组件,将会自动选择依赖的图形引擎组件等。
HarmonyOS整体遵从分层设计,从下向上依次为:内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 功能/模块”逐级展开,在多设备部署场景下,支持根据实际需求裁剪某些非必要的子系统或功能/模块。HarmonyOS技术架构如下图所示。
内核层
HarmonyOS系统分为内核子系统和驱动子系统。
内核子系统:HarmonyOS采用多内核设计,支持针对不同资源受限设备选用适合的OS内核。内核抽象层(KAL,KernelAbstract Layer)通过屏蔽多内核差异,对上层提供基础的内核能力,包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。
驱动子系统:HarmonyOS驱动框架(HDF)是HarmonyOS硬件生态开放的基础,提供统一外设访问能力和驱动开发、管理框架。
系统服务层
系统服务层是HarmonyOS的核心能力集合,通过框架层对应用程序提供服务。该层包含以下几个部分:
系统基本能力子系统集:为分布式应用在HarmonyOS多设备上的运行、调度、迁移等操作提供了基础能力,由分布式软总线、分布式数据管理、分布式任务调度、方舟多语言运行时、公共基础库、多模输入、图形、安全、AI等子系统组成。其中,方舟运行时提供了C/C++/JS多语言运行时和基础的系统类库,也为使用方舟编译器静态化的Java程序(即应用程序或框架层中使用Java语言开发的部分)提供运行时。
基础软件服务子系统集:为HarmonyOS提供公共的、通用的软件服务,由事件通知、电话、多媒体、DFX、MSDP&DV等子系统组成。
增强软件服务子系统集:为HarmonyOS提供针对不同设备的、差异化的能力增强型软件服务,由智慧屏专有业务、穿戴专有业务、IoT专有业务等子系统组成。
硬件服务子系统集:为HarmonyOS提供硬件服务,由位置服务、生物特征识别、穿戴专有硬件服务、IoT专有硬件服务等子系统组成。
根据不同设备形态的部署环境,基础软件服务子系统集、增强软件服务子系统集、硬件服务子系统集内部可以按子系统粒度裁剪,每个子系统内部又可以按功能粒度裁剪
框架层
框架层为HarmonyOS的应用程序提供了Java/C/C++/JS等多语言的用户程序框架和Ability框架,以及各种软硬件服务对外开放的多语言框架API;同时为采用HarmonyOS的设备提供了C/C++/JS等多语言的框架API,不同设备支持的API与系统的组件化裁剪程度相关。
应用层
应用层包括系统应用和第三方非系统应用。HarmonyOS的应用由一个或多个FA(Feature Ability)或PA(Particle Ability)组成。其中,FA有UI界面,提供与用户交互的能力;而PA无UI界面,提供后台运行任务的能力以及统一的数据访问抽象。基于FA/PA开发的应用,能够实现特定的业务功能,支持跨设备调度与分发,为用户提供一致、高效的应用体验。
系统安全
在搭载HarmonyOS的分布式终端上,可以保证“正确的人,通过正确的设备,正确地使用数据”。
通过“分布式多端协同身份认证”来保证“正确的人”。
通过“在分布式终端上构筑可信运行环境”来保证“正确的设备”。tpm
通过“分布式数据在跨终端流动的过程中,对数据进行分类分级管理”来保证“正确地使用数据”。
正确的设备 Avb
华为鸿蒙OS的四大技术特性
鸿蒙OS的设计初衷是为满足全场景智慧体验的高标准的连接要求,为此华为提出了4大特性的系统解决方案。
鸿蒙OS凭借多终端开发IDE,多语言统一编译,分布式架构Kit提供屏幕布局控件以及交互的自动适配,支持控件拖拽,面向预览的可视化编程,从而使开发者可以基于同一工程高效构建多端自动运行App,实现真正的一次开发,多端部署,在跨设备之间实现共享生态。华为方舟编译器是首个取代Android虚拟机模式的静态编译器,可供开发者在开发环境中一次性将高级语言编译为机器码。此外,方舟编译器未来将支持多语言统一编译,可大幅提高开发效率。
各类设备(手机/平板、智能穿戴、智慧屏等)通用的用户应用程序开发历程如下表所示。
开发业务功能 |
|
针对重点功能或场景的开发者教程如下表所示。
HarmonyOS设备开发官网 - 华为HarmonyOS打造全场景智能设备
HarmonyOS应用开发官网 - 华为HarmonyOS打造全场景新服务
HarmonyOS应用开发官网 - 华为HarmonyOS打造全场景新服务
畅连能力 - 音视频通话能力 - 实时音视频 - 华为开发者联盟
鸿蒙支持多种内核:Linux、Liteos(又分为Liteos-a、Liteos-m)
移植最小系统要做的几件事
串口相关
打印(只是打印调试信息)
串口驱动(可发可收,APP执行printf时可以从串口打印,所以需要驱动)
MMU(Memory Management Unit,内存管理单元)的设置:虚拟地址与物理地址
完善中断子系统
提供系统tick时钟
为串口驱动实现基于中断的读取字符函数
实现存储设备驱动程序,在存储设备上烧录文件系统
MMU有2大功能:
3.4 存储设备的驱动程序
板子上一般都有EMMC、SD/TF卡、Nor Flash、Nand Flash等存储设备。
Nor Flash、Nand Flash的驱动程序相对简单,但是这些设备比较少见了。
而EMMC、SD/TF卡的驱动程序又太复杂,足够出一个专题了。
我们聚焦在最小系统的移植,先把流程走通:用内存来模拟Flash。
光有存储设备还不行,上面需要有文件:这就是根文件系统。
一个程序要能运行,出了你写出的程序本身,还需要其他库,比如printf
就不是你写的,它在库文件里。
根文件系统里会有这些内容:
为 OpenHarmony 增加子系统定义
鸿蒙系统支持各种形态的设备,从 IoT 设备到手机,其硬件资源千差万别,功能需求也各不一样,所以系统要求可定制、可裁剪,系统被划分为各种模块和子系统。
华为的架构称之为“1+8+N”——1是智能手机,8包括PC、平板、车机、运动健康、穿戴、AR、VR、智慧大屏、智能音响等, N是大量的IoT设备。
1.分布架构
分布式架构首次用于终端OS,实现跨终端无缝协同体验。鸿蒙OS的“分布式OS架构”和“分布式软总线技术”通过公共通信平台,分布式数据管理,分布式能力调度和虚拟外设四大能力,将相应分布式应用的底层技术实现难度对应用开发者屏蔽,使开发者能够聚焦自身业务逻辑,像开发同一终端一样开发跨终端分布式应用,也使最终消费者享受到强大的跨终端业务协同能力为各使用场景带来的无缝体验。
都是Kit CameraKit, UIKit
按需加载
HDF框架支持驱动在系统启动过程中默认加载,或者在系统启动之后动态加载
调用HarmonyOS的NDK接口
系统服务层
系统服务层是 HarmonyOS 的核心能力集合,通过框架层对应用程序提供服
务。该层包含以下几个部分:
系统基本能力子系统集:为分布式应用在 HarmonyOS 多设备上的运行、调
度、迁移等操作提供了基础能力,由分布式软总线、分布式数据管理、分布式
任务调度、方舟多语言运行时、公共基础库、多模输入、图形、安全、AI 等子
系统组成。其中,方舟运行时提供了 C/C++/JS 多语言运行时和基础的系统类
库,也为使用方舟编译器静态化的 Java 程序(即应用程序或框架层中使用
Java 语言开发的部分)提供运行时。
根据不同设备形态的部署环境,基础软件服务子系统集、增强软件服务子系统
集、硬件服务子系统集内部可以按子系统粒度裁剪,每个子系统内部又可以按
功能粒度裁剪。
微内核架构包含两类组件:核心系统和插件系统。核心系统的功能稳定,很少变更,其只拥有能使应用运行的最小功能逻辑,这些通用逻辑(例如插件模块的注册、加载、卸载,以及插件模块之间的相互通信等)不涉及任何特定业务;插件系统则具备良好的扩展性,其负责实现特定的业务逻辑,可根据特定业务需求而变更。
显而易见,微内核架构本质上其实是将一个软件系统中的变化部分封装在插件中,从而实现不同业务之间的隔离性,达到系统快速灵活扩展的目的,同时所有特定业务相关逻辑的变更不会影响整体系统的稳定性。
设计要点
微内核架构设计有以下三个关键点:插件管理、插件链接和插件通信。
插件管理
核心系统需要知道当前系统中共有多少个插件,哪些插件处于可用状态,什么时候加载一个插件,如何加载一个插件等。
实现上述功能的一个常用机制是插件注册表:核心系统提供一个服务来响应插件的注册请求,最终将当前系统的所有插件信息(插件标识,类别,启动方式等)保存起来。存储方式可以选择配置文件存储或者数据表存储等。
插件链接
插件链接制定了一个插件与核心系统的通信方式,也就是链接规范,故任何一个可用插件都务必遵从核心系统中该类别插件所制定的链接规范。
常见的链接规范有OSGI(Eclipse),消息队列,依赖注入(Spring),RPC等
鸿蒙LITEOS-A与LITEOS-M
用于ARM Cortex A平台的,后者用于Cortex M平台的,主要是是否支持MMU
原文链接:https://blog.csdn.net/thisway_diy/article/details/110919525
原文链接:https://blog.csdn.net/qq_31765191/article/details/108948348
原文链接:https://blog.csdn.net/qq_31765191/article/details/108948348
原文链接:https://blog.csdn.net/miaozenn/article/details/110133719
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。