网站内外链怎么做,档案网站的建设方案,鲜花商城网站模板,国外搜索引擎有哪些寄语 这几年特别火的uni-app实现了“一次开发#xff0c;多端使用”#xff0c;它这个端指的是ios、安卓、各种小程序这些#xff0c;而HarmonyOS NEXT也提出了“一次开发#xff0c;多端部署”#xff0c;而它这个端指的是终端设备#xff0c;也就是我们的手机、平板、电…寄语 这几年特别火的uni-app实现了“一次开发多端使用”它这个端指的是ios、安卓、各种小程序这些而HarmonyOS NEXT也提出了“一次开发多端部署”而它这个端指的是终端设备也就是我们的手机、平板、电脑、智能手表这些。是不是很惊奇那这也是HarmonyOS NEXT的强大之处它在创立之初就以打造一个完整生态为目的相信在不久的未来一多能结合元服务或者更加强大的体系能实现真正的“万物互联”不单单是网络的互联而是像科幻电影中那种。同时这也是最近鸿蒙被各位大佬比较看好的原因之一。 概述 简介 HarmonyOS系统面向多终端提供了“一次开发多端部署”简称为一多的能力让开发者可以基于一种设计高效构建多端可运行的应用。 目标 支撑开发者快速高效的开发支持多种终端设备形态的应用实现对不同设备兼容的同时提供跨设备的流转、迁移和协同的分布式体验。 方舟开发框架 简介 方舟开发框架简称ArkUI提供开发者进行应用UI开发时所必须的能力方舟开发框架提供了两种开发范式分别是基于JS扩展的类Web开发范式和基于ArkTS的声明式开发范式。 1.声明式开发范式 简介 采用TS语言并进行声明式UI语法扩展从组件、动效和状态管理三个维度提供了UI绘制能力。 特点 适用于移动系统应用开发人员占用内存更少更适用大型的应用开发。 2.类Web开发范式 简介 采用经典的HML、CSS、JavaScript三段式开发方式使用HML标签文件进行布局搭建使用CSS文件进行样式描述使用JavaScript文件进行逻辑处理。 存在原因 更接近Web前端开发者的使用习惯快速将已有的Web应用改造成方舟开发框架应用。 特点 适用于Web前端开发人员主要适用于界面较为简单的中小型应用开发。 应用程序包结构
简介 在进行应用开发时一个应用通常包含一个或多个Module。 Module Module是应用/服务的基本功能单元包含了源代码、资源文件、第三方库及应用/服务配置文件每一个Module都可以独立进行编译和运行Module分为Ability和Library两种类型。 Module的类型 1.Ability类型的Module编译后生成HAP包。 2.Library类型的Module编译后生成HAR包或HSP包。 HAP 应用以APP Pack形式发布其包含一个或多个HAP包HAP是应用安装的基本单位Ability类型Module编译后会生成HAP包HAP可以分为Entry和Feature两种类型。 HAP的类型 1.Entry类型的HAP应用的主模块。在同一个应用中同一设备类型只支持一个Entry类型的HAP通常用于实现应用的入口界面、入口图标、主特性功能等。 2.Feature类型的HAP应用的动态特性模块。Feature类型的HAP通常用于实现应用的特性功能一个应用程序包可以包含一个或多个Feature类型的HAP也可以不包含。 部署模型
简介 一多有两种部署模型 部署模型A不同类型的设备上按照一定的工程结构组织方式通过一次编译生成相同的HAP或HAP组合 部署模型B不同类型的设备上按照一定的工程结构组织方式通过一次编译生成不同的HAP或HAP组合 泛类是什么 从屏幕尺寸、输入方式及交互距离三个维度考虑可以将常用类型的设备分为不同泛类 如何选择部署模型 1.应用在不同泛类设备上的UX设计或功能相似时可以使用部署模型A。 2.应用在同一泛类不同类型设备上UX设计或功能差异非常大时可以使用部署模型B但同时也应审视应用的UX设计及功能规划是否合理。 3.如果目标设备类型较多往往是部署模型A和部署模型B混合使用。 4.不管采用哪种部署模型都应该采用一次编译。 代码工程结构
简介 一多推荐了一种三层工程结构 代码工程结构和部署模型的关系 部署模型不同相应的代码工程结构也有差异。部署模型A和部署模型B的主要差异点集中在products层部署模型A在products目录下同一子目录中做功能和特性集成部署模型B在products目录下不同子目录中对不同的产品做差异化的功能和特性集成。 三层工程结构 common公共能力层 用于存放公共基础能力集合如工具库、公共配置等。 common层可编译成一个或多个HAR包或HSP包HAR中的代码和资源跟随使用方编译如果有多个使用方它们的编译产物中会存在多份相同拷贝而HSP中的代码和资源可以独立编译运行时在一个进程中代码也只会存在一份其只可以被products和features依赖不可以反向依赖。 features基础特性层 用于存放基础特性集合如应用中相对独立的各个功能的UI及业务逻辑实现等。 各个feature高内聚、低耦合、可定制供产品灵活部署。不需要单独部署的feature通常编译为HAR包或HSP包供products或其它feature使用但是不能反向依赖products层。需要单独部署的feature通常编译为Feature类型的HAP包和products下Entry类型的HAP包进行组合部署。features层可以横向调用及依赖common层。 products产品定制层 用于针对不同设备形态进行功能和特性集成。 products层各个子目录各自编译为一个Entry类型的HAP包作为应用主入口。products层不可以横向调用。 工程结构抽象表示 /application ├── common # 可选。公共能力层, 编译为HAR包或HSP包 ├── features # 可选。基础特性层 │ ├── feature1 # 子功能1, 编译为HAR包或HSP包或Feature类型的HAP包 │ ├── feature2 # 子功能2, 编译为HAR包或HSP包或Feature类型的HAP包 │ └── ... └── products # 必选。产品定制层 ├── wearable # 智能穿戴泛类目录, 编译为Entry类型的HAP包 ├── default # 默认设备泛类目录, 编译为Entry类型的HAP包 开发说明 1.整个代码工程最终构建出一个APP包应用以APP包的形式发布到应用市场中 2.开发阶段应考虑不同类型设备间最大程度的复用代码以减少开发及后续维护的工作量。 开发实例
概述 通过一个天气应用介绍一多应用的整体开发过程包括UX设计、工程管理及调试、页面开发等 UX设计 简介 一多建议从设备屏幕宽度的维度将设备划分为四大类设计师只需要针对这四大类设备做设计。 开发思路 1.在不同的屏幕宽度下应用的整体风格基本保持一致 2.在相近的屏幕宽度范围内应用的布局基本不变在不同的屏幕宽度范围内应用的布局有较大差异。 3.应用在小屏幕下显示的元素是大屏幕中显示元素的子集 四大类 不同设备的效果 工程管理及调试 创建项目 注意Device Type选项要勾选所有该应用期望运行的目标设备类型 预览调试 开启预览器并打开Multi-profile preview开关还可以点击 New Profile按钮新增自定义预览器 预览器Multi-profile preview开关 页面开发 开发思路 1.划分9个基础区域 2.基础区域9仅在大设备上显示基础区域1-8虽然在各设备上始终展示但其尺寸及区域内的布局基本保持不变可以结合自适应布局能力以自定义组件的形式分别实现这9个基础区域。 3.基础区域1-8之间的布局在不同设备上有较大差异可以使用响应式布局中的栅格布局能力实现组件间的布局效果 4.展开和隐藏侧边栏的功能可以通过侧边栏组件来实现。侧边栏是大设备上独有的借助响应式布局中的媒体查询能力控制仅在大设备上展示侧边栏即可 划分区域演示 功能开发 在超小设备上考虑CPU、内存、硬盘等硬件限制往往会对系统进行裁剪。
