YHDMYBY的博客

本文针对thread_adapter、memory_adapter、time_adapter部分进行解读，也是samgr/adapter下关于POSIX和CMSIS的最后一部分代码。在adapter部分对POSIX和CMSIS在队列、线程、内存、时间方面进行统一的接口声明，并进行不同环境下的具体实现，保障OpenHarmony移植性。

POSIX和CMSIS接口适配层，用于协调M核和A核API之间的差异。本文针对queue_adapter部分进行解读。统一队列操作的接口，如QUEUE_Create、QUEUE_Put、QUEUE_Pop、QUEUE_Destroy，屏蔽了底层POSIX和CMSIS的差异性。

//遍历消费者结点链表，向订阅了指定topic的所有消费者发送消息。 //若消费者绑定了身份标识则调用SAMGR_SendSharedDirectRequest()发送 //若消费者未绑定身份标识，则通过SAMGR_SendSharedRequest()发送

本文分析的相关代码实现位于distributedschedule_samgr_lite\interfaces\kits\communication\broadcast\broadcast_interface.h和distributedschedule_samgr_lite\communication\broadcast\source\pub_sub_implement.c。 在本系列中将对以下数据结构及函数进行详解。

本文相关代码实现位于distributedschedule_samgr_lite\communication\broadcast\source\目录下的broadcast_service.c和pub_sub_feature.c。 本文将对以下数据结构及函数进行详解。

在分布式调度框架中，关于轻量级服务管理的代码总体上可以分为四部分，分别是Samgr、Samgr_client、Samgr_endpoint及Samgr_server。本文是对Samgr部分的总体概述，相关代码文件位于distributedschedule_samgr_lite\samgr。对于Samgr的分析思路是采用总体代码分析+系统功能管理器(Samgr_lite)的机制分析+子主题分析+n篇代码标注的方式进行技术分享。在本文中提到的数据结构或函数的详细分析可以在文末的附录中找到，其中也包含了许多优秀代

鸿蒙操作系统的设计初衷是实现万物互联，使用同一套系统能力即可适配多种终端形态。由于平台资源有限且终端底层硬件的多样化，因此需要屏蔽不同硬件架构和资源的差异，提供统一化的系统服务开发框架。鸿蒙系统的设计将种硬件平台划分为两类，简称为M核、A核。M核：处理器架构为Cortex-M或同等处理能力的硬件平台，系统内存一般低于512KB，无文件系统或者仅提供一个可有限使用的轻量级文件系统，遵循CMSIS接口规范。A核：处理器架构为Cortex-A。

IUnknown是鸿蒙系统中非常重要的一个概念，作为服务或功能间交互的对外接口。当创建一个服务或功能时，需要为其绑定一个对外接口。其他的服务可以通过这个接口和它交互。下面给出IUnknown的基本结构，在开发新的对外接口时都必须继承这个基类，它包含三个基本的函数指针，分别是查询接口()、增加引用(AddRef)、减少引用(Release//查询IUnknown接口//添加引用计数//释放对IUnknown接口的引用通过调用。

IUnknown是鸿蒙系统中非常重要的一个概念，作为服务或功能间交互的对外接口。当创建一个服务或功能时，需要为其绑定一个对外接口。其他的服务可以通过这个接口和它交互。下面给出IUnknown的基本结构，在开发新的对外接口时都必须继承这个基类，它包含三个基本的函数指针，分别是查询接口()、增加引用(AddRef)、减少引用(Release//查询IUnknown接口//添加引用计数//释放对IUnknown接口的引用通过调用。

在针对鸿蒙模块二的源代码分析中，发现它业务逻辑的实现围绕着三大概念展开，分别是服务()、功能()和功能接口API(所以理解并掌握这三个概念对于我们深入学习鸿蒙底层代码的业务逻辑有极大的帮助。下面我将结合前期分析鸿蒙代码的经验，通过图文并茂的方式为读者讲解它们的基类和实例对象以及相应的作用。

单个UIAbility组件可以实现多个页面，并在多个页面之间跳转，这种UIAbility组件内部的页面跳转关系称为“页面栈”，由ArkUI框架统一管理，如下图中的UIAbility1的Page1->Page2->Page3和UIAbility2的PageA->PageB->PageC。

如前文所述，一个UIAbility实例对应一个任务。UIAbility实例个数与UIAbility配置的启动模式有关。在FA模型下，通过config.json配置文件中的“launchType”属性配置；在Stage模型下，通过 module.json5配置文件 中的“launchType”属性配置。任务与singleton模式任务与multiton模式任务与specified模式每个UIAbility实例都对应了一个最近任务列表中看到的Mission（任务）。

任务的管理由系统应用（如桌面应用）负责，三方应用无法管理任务。用户通过最近任务列表进行任务的相关交互。当创建任务后，用户可以对最近任务列表进行如下操作

Stage模型下的线程主要有如下三类：EventHub 提供了线程内发送和处理事件的能力，包括对事件订阅、取消订阅、触发事件等。以UIAbility组件与UI之间的数据同步为例，具体使用方法可以参考 UIAbility组件与UI的数据同步。总是有很多小伙伴反馈说：鸿蒙开发不知道学习哪些技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？ 为了解决大家这些学习烦恼。在这准备了一份很实用的鸿蒙（HarmonyOS NEXT）学习路线与学习文档给大家用来跟着学习。针对一些列因素，整理了一套纯血版鸿蒙（HarmonyO

系统的进程模型如下图所示。进程模型示意图hdc shellps -ef在上述模型基础上，对于系统应用可以通过申请多进程权限（如下图所示），为指定HAP配置一个自定义进程名，该HAP中的UIAbility、DataShareExtensionAbility、ServiceExtensionAbility就会运行在自定义进程中。不同的HAP可以通过配置不同的进程名运行在不同进程中。多进程示意图：多用于一对多的通信场景，公共事件发布者可能存在多个订阅者同时接收事件。为了解决大家这些学习烦恼。

通过这次鸿蒙开发岗位的面试，我深刻体会到了鸿蒙操作系统的发展潜力和对人才的需求。

系统环境变量是指：在应用程序运行期间，终端设备的系统设置（例如系统的语言环境、屏幕方向等）发生变化。

在发起端设置目标组件参数，调用startAbilityForResult()接口启动目标端UIAbility，异步回调中的data用于接收目标端UIAbility停止自身后返回给调用方UIAbility的信息。在设备A上通过应用提供的启动按钮，启动设备B上指定的UIAbility，当设备B上的UIAbility退出后，会将返回值发回设备A上的发起端应用。在设备A上通过发起端应用提供的启动按钮，启动设备B上指定的UIAbility与ServiceExtensionAbility。

在用户使用设备的过程中，当使用情境发生变化时（例如从室内走到户外或者周围有更适合的设备等），之前使用的设备可能已经不适合继续当前的任务，此时，用户可以选择新的设备来继续当前的任务，原设备可按需决定是否退出任务，这个就是跨端迁移的场景。常见的跨端迁移场景实例：在平板上播放的视频，迁移到智慧屏继续播放，从而获得更佳的观看体验；平板上的视频应用退出。在应用开发层面，跨端迁移指在A端运行的UIAbility迁移到B端上，完成迁移后，B端UIAbility继续任务，而A端UIAbility可按需决定是否退出。

随着全场景多设备的生活方式不断深入，用户拥有的设备越来越多，不同设备都能在适合的场景下提供良好的体验，例如手表可以提供及时的信息查看能力，电视可以带来沉浸的观影体验。但是，每个设备也有使用场景的局限，例如在电视上输入文本相对移动设备来说是非常糟糕的体验。当多个设备通过分布式操作系统能够相互感知、进而整合成一个超级终端时，设备与设备之间就可以取长补短、相互帮助，为用户提供更加自然流畅的分布式体验。跨多设备的分布式操作可以统称为流转；根据使用场景的不同，流转又分为 跨端迁移 两种具体场景。

启动组件是指一切启动或连接应用组件的行为：启动UIAbility、ServiceExtensionAbility、DataShareExtensionAbility，如使用startAbility()、startServiceExtensionAbility()、startAbilityByCall()等相关接口。

以打开浏览器为例，假设设备上安装了一个或多个浏览器应用。为了使浏览器应用能够正常工作，需要在 module.json5配置文件 进行配置，具体配置如下：

在启动目标应用组件时，会通过显式 Want 或者隐式 Want 进行目标应用组件的匹配，这里说的匹配规则就是调用方传入的 want 参数中设置的参数如何与目标应用组件声明的配置文件进行匹配。

Want 是一种对象，用于在应用组件之间传递信息。

Context 是应用中对象的上下文，其提供了应用的一些基础信息，例如resourceManager（资源管理）、applicationInfo（当前应用信息）、dir（应用文件路径）、area（文件分区）等，以及应用的一些基本方法，例如createBundleContext()、getApplicationContext()等。UIAbility组件和各种ExtensionAbility派生类组件都有各自不同的Context类。

AbilityStage是一个 Module 级别的组件容器，应用的HAP在首次加载时会创建一个AbilityStage实例，可以对该Module进行初始化等操作。

ExtensionAbility组件是基于特定场景（例如服务卡片、输入法等）提供的应用组件，以便满足更多的使用场景。

一个UIAbility可以对应多个页面，在不同的场景下启动该UIAbility时需要展示不同的页面，例如从一个UIAbility的页面中跳转到另外一个UIAbility时，希望启动目标UIAbility的指定页面。UIAbility的启动分为两种情况：UIAbility冷启动和UIAbility热启动。UIAbility冷启动：指的是UIAbility实例处于完全关闭状态下被启动，这需要完整地加载和初始化UIAbility实例的代码、资源等。

在基类Context中，提供了EventHub对象，可用于在UIAbility组件实例内通信。使用EventHub实现UIAbility与UI之间的数据通信需要先获取EventHub对象，本章节将以此为例进行说明。

应用中的UIAbility在启动过程中，需要指定启动页面，否则应用启动后会因为没有默认加载页面而导致白屏。可以在UIAbility的onWindowStageCreate()生命周期回调中，通过 WindowStage 对象的loadContent()方法设置启动页面。

UIAbility的启动模式是指UIAbility实例在启动时的不同呈现状态。针对不同的业务场景，系统提供了三种启动模式：

当用户打开、切换和返回到对应应用时，应用中的UIAbility实例会在其生命周期的不同状态之间转换。UIAbility类提供了一系列回调，通过这些回调可以知道当前UIAbility实例的某个状态发生改变，会经过UIAbility实例的创建和销毁，或者UIAbility实例发生了前后台的状态切换。UIAbility的生命周期包括Create、Foreground、Background、Destroy四个状态，如下图所示。图1UIAbility生命周期状态。

OpenHarmony系统支持丰富的设备形态，支持多种架构指令集，支持多种操作系统内核；为了应用在各种OpenHarmony设备上的兼容性，本文定义了"OHOS" ABI（Application Binary Interface）的基础标准，包含如下方面。

LLDB（Low Lever Debugger）是新一代高性能调试器。详细说明参考 LLDB官方文档 。当前OpenHarmony中的LLDB工具是在 llvm15.0.4 基础上适配演进出来的工具，是HUAWEI DevEco Studio工具中默认的调试器，支持调试C和C++应用。

## 场景介绍NetConnection模块提供了常用网络信息查询的能力。## 接口说明NetConnection常用接口如下表所示，| 接口名 | 描述 || --- | --- || OH_NetConn_HasDefaultNet(int32_t *hasDefaultNet) | 检查默认数据网络是否被激活，判断设备是否有网络连接，以便在应用程序中采取相应的措施。 || OH_NetConn_GetDefaultNet(NetConn_NetHandle *netHandle)

开发者可以通过本指导了解在OpenHarmony应用中，如何使用Native Bundle接口获取应用自身相关信息。

USB DDK（USB Driver Develop Kit）是为开发者提供的USB驱动程序开发套件，支持开发者基于用户态，在应用层开发USB设备驱动。提供了一系列主机侧访问设备的接口，包括主机侧打开和关闭接口、管道同步异步读写通信、控制传输、中断传输等。

OpenHarmony提供Purgeable Memory内存管理机制，开发者可以使用相关接口创建PurgeableMemory对象，从而管理purgeable内存。开发者可以通过本指导了解在OpenHarmony应用中，如何使用Native层相关接口操作purgeable内存。功能包括purgeable内存的申请、释放等。通过该机制提供的NAPI接口申请管理PurgeableMemory对象，并将数据内容写入该对象。使用完毕后释放。

Function Flow编程模型是一种基于任务和数据驱动的并发编程模型，允许开发者通过任务及其依赖关系描述的方式进行应用开发。FFRT（Function Flow运行时）是支持Function Flow编程模型的软件运行时库，用于调度执行开发者基于Function Flow编程模型开发的应用。通过Function Flow编程模型和FFRT，开发者可专注于应用功能开发，由FFRT在运行时根据任务依赖状态和可用执行资源自动并发调度和执行任务。

开发者可以通过本指导了解在OpenHarmony应用中，如何使用Native Rawfile接口操作Rawfile目录和文件。功能包括文件列表遍历、文件打开、搜索、读取和关闭Rawfile。