做网站公司平台wordpress打折插件

当前位置： 首页 > news >正文

做网站公司平台,wordpress打折插件,wordpress配置发送邮件,17做网店这个网站做起多少钱1 概述 OpenHarmony 分布式任务调度是一种基于分布式软总线、分布式数据管理、分布式 Profile 等技术特性的任务调度方式。它通过构建一种统一的分布式服务管理机制#xff0c;包括服务发现、同步、注册和调用等环节#xff0c;实现了对跨设备的应用进行远程启动、远程调用、…1 概述 OpenHarmony 分布式任务调度是一种基于分布式软总线、分布式数据管理、分布式 Profile 等技术特性的任务调度方式。它通过构建一种统一的分布式服务管理机制包括服务发现、同步、注册和调用等环节实现了对跨设备的应用进行远程启动、远程调用、绑定/解绑以及迁移等操作的支持。此外分布式任务调度还能够根据设备的能力、位置、业务运行状态、资源使用情况以及用户的习惯和意图选择最合适的设备来运行分布式任务从而提高了任务的执行效率和质量。 1.1 应用场景举例 比如在用户的日常出行中一段路程往往需要使用不同的交通工具例如从家里出发去某公园露营需要先开车到达公园到公园停车场然后骑单车进入公园最终可能还需要步行一段距离才可以到达目的地。在这个过程中用户需要分别打开车载导航 APP 和手机的导航 APP并分别输入起点和终点最后才能完成一次出行导航。但是借助于 OpenHarmony 分布式任务调度可以将这些 APP 的功能进行整合用户只需要在手机上输入起点和终点然后点击出行按钮借助于 OpenHarmony 分布式任务调度应用就会根据使用场景自动地将导航信息流转到车机手机手表等不同的设备上。 可以看到借助于 OpenHarmony 分布式任务调度在物联网应用场景中可以实现设备间的资源共享跨设备任务调度从而创造出无限的可能性提升用户的使用体验的同时也提升了设备的使用效率。 1.2 系统架构 如图所示分布式任务调度框架位于系统服务层主要包括元能力子系统中的系统服务管理safwk/samgr和分布式组件管理部件distributedsched两个模块。其中系统服务管理主要负责系统服务SystemAbility的启动、注册、发现、调用等功能。分布式组件管理主要负责分布式应用Ability调度的功能包括元能力的远程绑定与调用、绑定关系的管理、分布式权限管理元能力的远程启动与迁移等功能。 2 系统服务及其分布式特性 OpenHarmony 的系统服务通常是一个常驻内存的进程它可以通过 IPC 或 RPC 的方式向其他进程提供相关的系统能力比如分布式数据管理、设备认证等。按照启动方式大体可将系统服务分为两种原生的可执行程序如设备认证服务和 SystemAbility如分布式数据管理服务。原生的服务通常比较底层大多数使用 C 语言实现其对应的编译目标也是可执行的二进制文件。比如 deviceauth_service它是设备认证的系统服务主要负责设备的认证和鉴权。这种类型的服务通常在系统启动的时候由 init 进程根据服务的配置文件json 格式的文本文件进行启动。 SystemAbility 则是由 samgr 统一管理的 so 库一般采用 service.cfg profile.xml libservice.z.so 的方式由 init 进程根据对应的 service.cfg 文件拉起相关系统服务能力进程。cfg 配置文件为 linux 提供的 native 进程拉起策略开机启动阶段由 init 进程解析该文件调用 sa_mainprofile.xml加载服务的 so 库文件。profile.xml 是 SA 的描述文件定义了服务的名称so 文件路径等信息。 本文的分布式任务调度主要指的是 SystemAbility 类型的系统服务因此主要介绍 SA 的相关内容。SA 类型的服务主要由 safwk 和 samgr 两部分组成其中 safwk 定义了 SystemAbility 的实现方法并且提供了 SystemAbility 的注册、调用等功能接口。samgr 则是 SystemAbility 的管理者通过 IPC 通信接收到 safwk 的消息完成服务注册调用加载 so 库等功能。下面将分别从服务的启动实现等方面介绍两个模块的实现原理。 2.1 SA 启动流程 通过 samgr 管理的服务需要配置文件 service.cfg 和 profile.xml参考下图。其中 name 字段为服务的名称path 服务的启动路径。profile.xml 定义了服务的名称so 文件路径等信息。需要注意的是不同的 SA 可能会加载进同一个进程因此 process 字段指定了要加载的进程名称systemability 字段定义了 SA 相关的信息。也就是说一个 service 进程可以加载多个 SA 的 so 库。 SA 的启动流程如下 在系统开机启动阶段init 进程会解析 service.cfg 文件根据配置的 path 字段调 用 sa_main(profile.xml)启动服务。sa_main 是 safwk 中编译得到的可执行文件是 SA 的 启动入口。其首先会对参数进行预处理判断 profile.xml 路径saId 等参数是否合法。接着 sa_main 会调用 lsamgr 的 DoStartSAProcess()方法启动服务进程。lsamgrLocal SystemAbility Manager是 safwk 框架中的内部组件主要用于在 safwk 内部对服务进行管理注意与 samgr 服务区别。DoStartSAProcess()首先解析 profile 文件配置服务进程SA 实例的名称SaId 等属性然后通过 IPC 调用 samgr 服务的 AddSystemProcess()方法将服务进程本质上是一个绑定了服务相关信息的 lsamgr 实例注册到 samgr然后启动服务进程。SA 对应的系统进程启动之后便需要加载启动 SA 自身。首先samgr 调用 AddOnDemandSystemAbilityInfo()将对应的 SA 实例与服务进程进行绑定并准备启动对应的 SA。启动 SA 需要再次调用 safwk 中 lsamgr 的 StartAbility()方法该方法会加载 SA 对应的 so 库并从中调用 SA 的 Start()方法完成服务的启动。在 Start()方法中会触发钩子函数 OnStart()的调用OnStart()通常由 SA 自己实现用来完成其的初始化工作并调用 Publish()发布 SA。最后 Publish()方法会调用 samgr 的 AddSystemAbility()方法将 SA 注册到 samgr 中。 至此服务启动完成可以对外提供服务了。 2.2 SA 的实现 SA 服务通过 IPC 通信向外提供服务因此其除了需要继承 SystemAbility 外实现其 OnStart()等方法外还需要实现 IPC 通信框架。OpenHarmony 的 IPC 框架主要依赖下面几个类 IServiceSA 服务的接口类用来定义并描述服务的能力该类需要继承 IRemoteBroker 类并使用宏命令 DECLARE_INTERFACE_DESCRIPTOR 声明接口描 述符。该类是 IPC 通信双方的公共接口因此需要将其放在公共的头文件中以便于双方都可以使用。ServiceStubSA 服务中 IPC 请求的接收类该类需要同时继承 IService 和 IRemoteStub 类并实现 IRemoteStub 类的 OnRemoteRequest 方法该方法用来在接收 到 IPC 请求时处理请求。ServiceImplSA 服务的实现类继承 ServiceStub 和 SystemAbility 类实现 IService 接口中定义的方法该类用来实现服务的具体功能并且需要在 onStart 方法中调用 Publish 方法将服务发布出去。ServiceProxySA 服务的代理类继承 IService 和 IRemoteProxy 类并实现 IService 中定义的同名方法该类通过 IRemoteProxy 类的 Remote()获取远程对象并调用其 SendRequest()方法向 SA 服务的 Stub 类发送 IPC 请求。 当其他进程或应用需要调用该 SA 服务的功能时首先需要调用 samgr 的 GetSystemAbility()方法获取服务的代理实例即上述的 ServiceProxy 类的实例 proxy。然后调用 proxy 中的同名方法该方法通过 Remote()-SendRequest()方法向 SA 服务的 ServiceStub 类发送 IPC 请求。在 ServiceStub 类的 OnRemoteRequest()方法中接收到相应的 IPC 请求从中读取参数然后调用服务实现类 ServiceImpl 的具体方法去处理实际的业务逻辑完成最后将结果写回 IPC 请求。 下面我们通过实现一个简单的 HelloService 服务来说明如何向系统中添加一个 SA 服务。该服务通过 IPC 通信向外提供一个 SayHello 接口该接口接收一个 string 类型的参数 name然后生成字符串“Hello name”将其通过 hilog 输出打印并将结果返回给调用者。整体服务的类图如图。 其中 HelloService 对应上述的 ServiceImpl 类HelloServiceClient 是服务的客户端提供与服务同名的接口在其中封装了获取服务代理对象以及调用代理类的同名接口供外部程序调用。下面的流程图展示了外部进程调用该服务的流程。其中 GetProxy 方法会向 samgr 请求服务的代理实例并通过接口转换函数 iface_cast 将其转换为自己进程内的 HelloServiceProxy 类型的实例 proxy图中的虚线对应 IPC 通信其具体的实现机制在此不在展开介绍。 2.3 分布式 SA 上述 SA 的启动及调用均为本地服务下面来介绍 SA 服务的分布式特性即本地设备调用其他设备的 SA 服务。注意下文中的对端设备均指的是已经与本地设备完成组网认证的设备。分布式 SA 服务的启动与本地服务的启动类似只需要在 SA 对应的 profile 文件中设置 distributed 属性为 true 即可。然后 SA 的 Publish()方法中会检查注册阶段保存的该属性若为 true则首先通过 IPC 框架的 dbinder_service 服务的 RegisterRemoteProxy()接口对该 SA 服务的 saId 进行注册。dbinder_service 服务会维护一个 map 类型的变量 mapRemoteBinderObjects_以记录本地对外提供的分布式服务对象。在服务注册及启动阶段分布式 SA 与本地 SA 并无太多区别真正实现 SA 的分布式特性实在服务的访问调用阶段。 如果本地设备需要调用对端设备 SA 服务的功能则在获取 SA 代理时需要向 samgr 的 GetSystemAbility()方法同时传入 saId 和 deviceId。samgr 检测到客户端请求的是其他设备的 SA 服务实例时会调用 IPC 框架的 dbinder_service 服务的 MakeRemoteBinder()方法来构建远程服务实例该实例实际是一个指向 DBinderServiceStub 对象的指针。DBinderServiceStub 主要用来实现 RPC 通信这里不过多介绍。MakeRemoteBinder()方法会构造一个 DBinderServiceStub 类的实例并绑定远程 SA 服务的 saId 和 deviceId然后记录在 DBinderStubRegisted_一个 Vector 类型的变量中。接着与对端设备建立软总线会话并通过软总线发送 Entry 消息到对端设备挂起线程等待回复。若能够收到回复则证明远程服务已经启动将 DBinderServiceStub 类的对象返回给 samgrsamgr 进一步返回给远程 SA 服务的请求者。请求者收到该对象后将其作为参数构造 ServiceProxy 代理类对象 remoteProxy之后的调用与本地 SA 服务调用类似先调用 remoteProxy 中的同名接口该接口通过 Reomte()-SendRequest()方法发送 RPC 请求通过软总线。SendRequest()的跨端实现属于 RPC 框架部分此处不再赘述。 由上述分析可以看到相比于本地的 SA分布式 SA 不仅需要向 samgr 注册还需要将其注册至 IPC/RPC 框架中以供后续跨设备调用。本地 SA 主要依赖于 IPC 通信提供服务而分布式 SA 则通过 RPC依赖于软总线向其他设备提供服务。 3 分布式组件管理 系统服务 SA 的分布式特性主要供框架层使用几乎不会直接提供给上层应用。而实际应用中支持分布式调度的任务特性多是由上层应用实现。比如多设备联动用户应用程序的流转实现如邮件跨设备编辑、多设备协同健身、多屏游戏等分布式业务。上层应用的分布式调度主要由分布式组件管理服务DistributedSched服务提供。DistributedSched 服务是 OpenHarmony 系统中的一个 SA可以向其他进程提供分布式任务调度的相关接口。分布式任务调度框架是分布式任务调度的核心功能所在包括元能力的远程启动、流转等功能。 DistributedSched 服务dmsfwk 框架主要包括两个模块dtbabilitymgr 和 dtbschedmgr。dtbabilitymgr 主要负责元能力的分布式流转管理功能的实现向上层应用提供流转管理的接口也是 SA 服务的实例。dtbschedmgr 主要负责分布式任务调度的具体功能实现包括元能力的远程启动迁移绑定等具体功能的实现。 需要注意的是在 OpenHarmony3.2 版本中dtbschedmgr 作为一个独立的 so 库由 dtbabilitymgr 服务进程加载使用但是在最新的 4.0 版本中dtbschedmgr 作为一个独立的 SA 服务运行两模块间通过 IPC 通信。 3.1 远程启动 Ability Ability 的远程启动主要依赖 dtbschedmgr 模块在介绍 dtbschedmgr 模块前我们先简单了解一下 OpenHarmony 的应用启动流程。通常我们通过应用的上下文类 Context 的 StartAbility(want)方法启动新的 Ability。Want 是一种对象用于在应用组件之间传递信息。例如当 UIAbilityA 需要启动 UIAbilityB 并向 UIAbilityB 传递一些数据时可以使用 Want 作为一个载体将数据传递给 UIAbilityB。如图所示 Want 类包含字段 deviceid给字段指明了启动新的 Ability 的设备。若该字段为空则表示在本地启动反之表示在字段指定的设备上启动。当 ability_runtime 框架判断需要处理的 want 的 deviceid 为其他设备时便会调用 dtbschedmgr 的相关接口实现分布式的能力管理。 当 AbilityManager 服务需要远程启动 Ability 时调用 DistributedSched 服务dtbschedmgr 模块的 StartRemoteAbility()方法处理远程启动的请求。StartRemoteAbility()方法首先会调用 samgr 的 GetSystemAbility()方法获取对端设备上的 DistributedSched 服务的代理对象 remoteProxy这一步即是上文中提到的分布式 SA 服务的实现。然后设置 abilityInfocallerInfoaccountInfo 等信息并配置新的 want 对象。使用上述参数调用 remoteProxy对端设备服务代理的 StartAbilityFromRemote()方法。对端设备的 DistributedSched 服务收到请求后会调用其 StartAbilityFromRemote()方法通过本地的 AbilityManager 服务启动本地 Ability。具体流程参考下图。 3.2 Ability 流转 在 OpenHarmony 中流转泛指跨多设备的分布式操作。流转能力打破设备界限多设备联动使用户应用程序可分可合、可流转实现如邮件跨设备编辑、多设备协同健身、多屏游戏等分布式业务如本章引言中提到的智能家居中视频播放流转及多场景导航应用的使用。流转为开发者提供更广的使用场景和更新的产品视角强化产品优势实现体验升级。流转按照使用场景可分为跨端迁移和多端协同。 跨端迁移指在用户使用设备的过程中当使用情境发生变化时例如从客厅走到卧室或者周围有更合适的设备等之前使用的设备可能已经不适合继续当前的任务此时用户可以选择新的设备来继续当前的任务原设备退出任务这就是跨端迁移场景。常见的跨端迁移场景实例在平板上播放的视频迁移到智慧屏继续播放从而获得更佳的观看体验平板上的视频应用退出。在应用开发层面跨端迁移指在 A 端运行的 UIAbility 迁移到 B 端上完成迁移后 B 端 UIAbility 继续任务而 A 端 UIAbility 退出。 多端协同指用户拥有的多个设备可以作为一个整体为用户提供比单设备更加高效、沉浸的体验这就是多端协同场景。常见的多端协同场景实例平板侧应用 A 做答题板智慧屏侧应用 B 做直播为用户提供更优的上网课体验。在应用开发层面多端协同指多端上的不同 UIAbility/ServiceExtensionAbility 同时运行、或者交替运行实现完整的业务或者多端上的相同 UIAbility/ServiceExtensionAbility 同时运行实现完整的业务。一次多端协同的流程大体如下图所示 由于在最新的 OpenHarmony 版本中4.0跨端迁移及多端协同的能力尚未具备开发者当前只能开发具备跨端迁移能力的应用但不能发起实际迁移。虽然流转功能的 NAPI 接口尚未完全实现但其基本的流程和上述的远程启动流程类似本地设备的 DistributedSched 服务的在 ContinueRemoteMission()接口中远程调用对端设备的 DistributedSched 服务的 ContinueMission()接口从而实现流转功能。 流转功能的实现大体可分为两步首先远程启动对端设备的 Ability然后同步本地设备的 Ability 的状态及数据至对端从而实现流转。目前数据同步功能尚未完善但是在应用层可通过分布式数据管理KVDB 或 RDB的相关接口实现数据的同步。这里可以参考 OpenHarmony 官网上的应用示例 跨端迁移分布式音乐播放器多段协同分布式计算器 4 小结 本文带领读者了解分布式任务调度的基本概念和应用场景。结合 OpenHarmony3.2 源代码简要介绍了分布式任务调度的实现原理和核心代码框架。了包括 SystemAbility 的启动流程和实现原理以及如何结合 SA 与 IPC 框架以向其他进程提供服务。在此基础上介绍了分布式组件管理服务 DistributedSched 服务的实现原理包括远程启动 Ability 和流转功能的实现。通过上述介绍读者可以更深入地理解分布式任务调度的具体实现方式以及其在实际应用开发中的使用。 为了能让大家更好的学习鸿蒙HarmonyOS NEXT开发技术这边特意整理了《鸿蒙开发学习手册》共计890页希望对大家有所帮助https://qr21.cn/FV7h05 《鸿蒙开发学习手册》 如何快速入门https://qr21.cn/FV7h05 基本概念构建第一个ArkTS应用…… 开发基础知识https://qr21.cn/FV7h05 应用基础知识配置文件应用数据管理应用安全管理应用隐私保护三方应用调用管控机制资源分类与访问学习ArkTS语言…… 基于ArkTS 开发https://qr21.cn/FV7h05 Ability开发UI开发公共事件与通知窗口管理媒体安全网络与链接电话服务数据管理后台任务(Background Task)管理设备管理设备使用信息统计DFX国际化开发折叠屏系列…… 鸿蒙开发面试真题含参考答案https://qr18.cn/F781PH 鸿蒙开发面试大盘集篇共计319页https://qr18.cn/F781PH 1.项目开发必备面试题 2.性能优化方向 3.架构方向 4.鸿蒙开发系统底层方向 5.鸿蒙音视频开发方向 6.鸿蒙车载开发方向 7.鸿蒙南向开发方向