当前位置: 首页 > article >正文

鸿蒙 元服务摘要

元服务(原名原子化服务),是HarmonyOS提供的一种面向未来的服务提供方式,是有独立入口的(用户可通过点击方式直接触发)、免安装的(无需显式安装,由系统程序框架后台安装后即可使用)、可为用户提供一个或多个便捷服务的用户应用程序形态。例如:某传统方式的需要安装的购物应用A,在按照元服务理念调整设计后,成为由“商品浏览”“购物车”“支付”等多个便捷服务组成的、可以免安装的购物元服务A*

元服务基于HarmonyOS SDK(只能使用“元服务API集”)开发,支持运行在1+8+N设备上,供用户在合适的场景、合适的设备上便捷使用。

注意

从HarmonyOS NEXT Developer Preview1(对应API 11)版本开始:

  • HarmonyOS元服务只能采用“元服务API集”进行开发,且只支持Stage模型、只支持ArkTS接口;开发者在DevEco Studio中选择开发元服务时,工具将自动过滤“元服务API集”。
  • 使用配套的HarmonyOS SDK开发的元服务,只能运行在系统软件版本为HarmonyOS NEXT Developer Preview1及以上版本的设备上。

 

表1 元服务与传统应用对比

区别

特征

载体

API范围

经营

传统应用

  • 手动下载安装
  • 包大小无限制
  • 按需使用
  • 应用内或应用市场更新
  • 功能齐全,开发成本高,周期长

跟随设备

全量API

  • 自主运营
  • 人找应用成本高

元服务

  • 免安装
  • 包大小有限制
  • 即用即走
  • 自动更新
  • 轻量化完整功能,开发成本较低

跟随华为账号

只能使用“元服务API集”

  • 支付、地图、广告等经营履约能力辅助经营
  • 负一屏等系统分发入口帮助人找服务、服务找人

元服务特征

元服务区别于传统应用,具备如下特征,并适用于如下典型场景。

  • 秒开直达,纯净清爽
    • 元服务能够即点即用,实现秒开启动,丝滑流畅。
    • 元服务默认隐匿登录直达使用,无弹窗干扰,给予用户纯净体验。
    • 基于HarmonyOS,有多个分发入口,能够更高效地触达用户。
  • 服务相伴,恰合适宜
    • 服务面板在负一屏、锁屏界面等常伴跟随,服务履约过程中提供的信息由官方保障。
    • 服务通知和状态恰和适宜的提醒,将提供更便捷、高效的服务闭环。
  • 用完即走,帐号相随
    • 用户使用完元服务后,退出无二次弹窗。
    • 用户资产跟随账号,多设备安全同步。用户可随时找回自己的元服务。
  • 一体两面,嵌入运行
    • 元服务和应用是鸿蒙生态下的两种程序形态,元服务免安装,更为轻量。
    • 两者可独立部署,也可以嵌入运行,助力商户私域运营。
  • AI智能,全域流转
    • 通过意图识别和AI智能实现服务精准触达和丝滑自然体验。
    • 在全域搜索中,任何的服务都能触达用户。
  • 高效开发,生而可信

    提供元服务标准UX组件集、场景化模板及API集,同时构建元服务生态规则,开发者在规则之上高效开发,实现生而可信。

基于上述特征,元服务的典型使用场景如下。

  1. 常用服务卡片添加到桌面,体验快捷服务

    例如:将常用的天气、备忘录及热点新闻列表等服务卡片添加到桌面上,解锁手机即可在桌面上查看即时信息。

    同时,通过负一屏发现服务卡片,无需安装即可使用热点服务卡片。

  2. 释放手机,让用户在更合适的设备上享受服务

    例如:打车是人们日常生活中经常使用的服务,通常人们在手机上打车,需要一直停留在手机界面才能准确获取司机的状态信息。

    有了元服务的分布式能力,在手机打车后,将司机状态实时同步到手表,无需查看手机,抬腕即可获取司机状态。
     

元服务程序包基础知识

但元服务相对于需要安装的应用形态更加轻量、便捷,其程序包也具备一些独有特征,如免安装、分包、预加载、老化。

分包

HarmonyOS每个应用程序包(.app)可以包含多个包文件(以.hap为后缀的HAP或以.hsp为后缀的HSP)。元服务在此基础上,进一步限制每个HAP或HSP(含其依赖的所有共享包)的大小,以实现快速启动体验,元服务的这种多包开发方案称为“分包”。具体可参考分包开发指导。

预加载

开发者可以通过配置预加载,由系统自动下载和安装可能需要的分包模块,从而提升进入后续模块的速度。

对于配置了预加载的分包模块,当点击进入该模块并完成页面加载后,将触发关联模块的预加载。具体可参考预加载开发指导。

老化

系统会按照一定策略清理不活跃的元服务,释放空间,这个过程称为老化。具体老化机制如下。

  • 老化时机:由系统定时器触发老化,当系统中所有元服务占用总空间大于既定阈值时,将启动老化,同时要求设备处于熄屏状态,且剩余电量不低于10%。
  • 老化顺序:优先老化长时间未使用及使用频率较低且未添加桌面卡片的元服务。
  • 分级老化:根据数据重要性排序,分级老化。当系统满足老化时机的要求时,按照老化顺序优先清理元服务的Cache目录数据,再按照老化顺序清理元服务的其他目录数据,直到系统中所有元服务占用总空间小于既定阈值的80%。因此,开发者应合理规划数据存放目录,仅将非重要数据(例如网络缓存图片等)存放到Cache目录,避免重要数据被频繁老化清理。


http://www.kler.cn/a/597350.html

相关文章:

  • pip install jupyter 报错
  • 【嵌入式狂刷100题】- 1基础知识部分
  • Go语言的基础类型
  • Linux上位机开发实战(camera视频读取)
  • 大语言模型的“细胞“:拆解语言模型的DNA——Token
  • STM32G070CBT6采用定时器实现1秒内发送N次数据
  • 【leetcode hot 100 22】括号生成
  • 使用Pycharm一键将.ui文件生成.py文件配置教程
  • 工业物联网的范式革命:从“云边“ 到“边边” 协的技术跃迁
  • 游戏引擎学习第177天
  • 应用权限组列表
  • LeetCode HOT100系列题解之岛屿数量(10/100)
  • 并发编程 面试速记
  • 图像多分类的人工智能
  • 自由学习记录(46)
  • 使用Gitee Go流水线部署个人项目到服务器指南
  • LeetCode hot 100 每日一题(13)——73. 矩阵置零
  • CMS网站模板设计与用户定制化实战评测
  • 风尚云网|前端|前后端分离架构深度剖析:技术革新还是过度设计?
  • Day20-前端Web案例——部门管理