前言
系列文章目录:
HarmonyOS开发第一步,熟知开发工具DevEco Studio
当我们熟练的掌握了DevEco Studio之后,就可以创建项目进行练习了,和市场上大多数IDE一样,DevEco Studio也给我们提供了很多的实例模板,当然了,对于大多数移动端开发者而言,这些模板和我们的UI设计有着很大的出入,一般都会选择一个空的视图作为项目,方便我们从0到1进行开发。
点击下一步,就进入到了项目信息编辑页面,作为一名Android开发者,对这个页面简直不要太熟悉,无非就是项目的名字,包名,SDK版本的选择等等。
有两项是我们需要注意的,第一项,Model的选择,也就是应用模型,目前随着HarmonyOS的发展,提供了两种应用模型,一种是Stage模型,一种是FA模型,目前,官方主推的是Stage模型,我们在创建项目的时候,也是默认的这种模型,它是在,HarmonyOS 3.1 Develper Preview版本开始新增的模型,是目前主推且会长期演进的模型,在该模型中,由于提供了AbilityStage、WindowStage等类作为应用组件和Window窗口的“舞台”,因此称这种应用模型为Stage模型。
关于Stage模型,官方有着很详细的介绍,这里就不多说了。
还有一项需要注意的,Enable Super Visual选项,也就是是否要启动低代码作为模板,选择之后,你就可以在项目中拖拽实现想要的页面,类似Android Studio中的Xml中的Design选项。
以上的部分只是前言,阐述了项目创建前的一些注意事项,在讲述工程结构之前,我们需要对HarmonyOS的UI开发框架ArkUI做一个简单的了解。
今天的文章内容,大致如下:
1、ArkUI框架的简单阐述
2、Stage模型下的ArkTS工程目录结构
3、与Android项目结构对比
4、相关总结
一、ArkUI框架的简单阐述
为什么要在工程结构之前阐述ArkUI这个UI框架?主要原因只有一个,就是为以后的项目创建做好铺垫,首先我们来搞清楚前因后果。
ArkUI框架,既是方舟开发框架,它是HarmonyOS提供了一套UI开发框架,和Flutter与SwiftUI有着异曲同工的角色,你可以使用Flutter语言开发出Android、iOS等平台的应用,也可以使用SwiftUI开发出iOS端的应用,同理,HarmonyOS端的应用,如何开发呢,可以使用ArkUI。
针对不同目的和技术背景,ArkUI提供了两种开发方式,一种是基于ArkTS的声明式开发方式,这个方式和Flutter与SwiftUI很相似,也就是说,如果你之前了解过Flutter与SwiftUI,那么使用这种方式,再方便不过;还有一种是兼容JS的类Web开发方式,言外之意,这种方式允许你用前端语言,也就是经典的HML、CSS、JavaScript来开发应用。
开发方式名称 | 语言生态 | UI更新方式 | 适用场景 | 适用人群 |
声明式开发范式 | ArkTS语言 | 数据驱动更新 | 复杂度较大、团队合作度较高的程序 | 移动系统应用开发人员、系统应用开发人员 |
类Web开发范式 | JS语言 | 数据驱动更新 | 界面较为简单的程序应用和卡片 | Web前端开发人员 |
作为移动端应用的开发者,考虑到性能,复杂度高,开发效率和发展趋势而言,声明式开发方式,绝对是我们的首选方式,当然了,官方也是主推这种方式,官方推荐的原因如下:
开发效率:声明式开发范式更接近自然语义的编程方式,开发者可以直观地描述UI,无需关心如何实现UI绘制和渲染,开发高效简洁。
应用性能:如下图所示,两种开发范式的UI后端引擎和语言运行时是共用的,但是相比类Web开发范式,声明式开发范式无需JS框架进行页面DOM管理,渲染更新链路更为精简,占用内存更少,应用性能更佳。
发展趋势:声明式开发范式后续会作为主推的开发范式持续演进,为开发者提供更丰富、更强大的能力。
所以在以后的项目开发中,第一,基于ArkTS的声明式开发方式,第二,采用Stage模型,原因只有一个,基于性能和未来的发展趋势,如果这个原因还不够,那就拿官方推荐作为原因,绝对好使!
至于ArkTS,后续的文章慢慢讲述吧,一步一步来,循序渐进。
二、Stage模型下的ArkTS工程目录结构
不要被一些名词给唬住了,我们默认创建的就是基于Stage模型下的ArkTS工程目录结构,创建完毕之后,窗口如下:
和AndroidStudio不能说一模一样,但也是十分有九分的雷同,具体的各个功能就不多赘述,我们直接看左侧的目录结构:
我们从上往下一一进行解析:
.hvigor:存储构建配置文件信息。
.idea:存储项目的配置信息。
AppScope:全局的共有资源存放目录。
resources:用于存放应用/服务所用到的资源文件,如图形、多媒体、字符串、布局文件等。
base>element:包括字符串、整型数、颜色、样式等资源的json文件。每个资源均由json格式进行定义
boolean.json:布尔型
color.json:颜色
float.json:浮点型
intarray.json:整型数组
integer.json:整型
pattern.json:样式
plural.json:复数形式
strarray.json:字符串数组
string.json:字符串值
base>media:多媒体文件,如图形、视频、音频等文件,支持的文件格式包括:.png、.gif、.mp3、.mp4等。
rawfile
:用于存储任意格式的原始资源文件。rawfile不会根据设备的状态去匹配不同的资源,需要指定文件路径和文件名进行引用。
app.json5:应用的全局配置信息。
entry:HarmonyOS工程模块,编译构建生成一个HAP包。
src > main > ets:用于存放ArkTS源码。
entryability:应用/服务的入口。
pages:应用/服务包含的页面。
src > main > resources:用于存放应用/服务所用到的资源文件,如图形、多媒体、字符串、布局文件等,和上面的共享目录是一致的。
src > main > module.json5:Stage模型模块配置文件。主要包含HAP包的配置信息、应用/服务在具体设备上的配置信息以及应用/服务的全局配置信息。
build-profile.json5:当前的模块信息、编译信息配置项,包括buildOption、targets配置等。其中targets中可配置当前运行环境,默认为HarmonyOS。
hvigorfile.ts:模块级编译构建任务脚本,开发者可以自定义相关任务和代码实现。
hvigor:构建配置文件信息,是一款全新基于TS实现的前端构建任务编排工具,结合npm包管理机制,主要提供任务管理机制,任务注册编排、工程模型管理、配置管理等关键能力,更符合ArkTS/JS开发者的开发习惯。
oh_modules:用于存放三方库依赖信息。
.gitignore:git过滤配置。
build-profile.json5:应用级配置信息,包括签名、产品配置等。
hvigorfile.ts:应用级编译构建任务脚本。
hvigorw和hvigorw.bat:ohpm编译构建工具。
local.properties:存储本地属性的文件。
oh-package.json5:依赖配置,可以设置三方包依赖。
可以说,以上的目录结构介绍,全网甚至是官网,也没有这么的详细,为什么要对目录结构过多的进行阐述,目的只有一个,更好的了解项目,可以针对性且快速的进入到开发之中。
三、与Android项目结构对比
或许,第一次直接的查看这样的一个工程目录,确实需要一段时间的了解,才能知道各个文件的作用,为了更加直观明了的让一名Android开发者快速的知道每个文件对应的含义,接下来将会按照Android工程的目录结构和Stage模型下的ArkTS工程目录结构,进行一一对应,希望可以有所帮助,当然了,如果你不是一名Android开发者,这个步骤可以掠过,仔细的查看第二步的介绍即可。
整体的对照
左侧是HarmonyOS项目,右侧是Android项目,具体的对照图如下所示:
主要文件对应
Android文件 | HarmonyOS文件 |
清单文件AndroidManifest.xml | module.json5 |
Activity/Fragment | entryability下的ts文件 |
XML布局 | pages下的ets文件 |
res | resources |
Module下的build.gradle | Module下的build-profile.json5 |
gradle | hvigor |
根目录下的build.gradle | 根目录下的build-profile.json5 |
colors.xml dimens.xml strings.xml …… | color.json:颜色 float.json:浮点型 string.json:字符串值 …… |
四、相关总结
通过对工程结构的了解,对于我们步入HarmonyOS的开发,有着指引的作用,能够清晰的知道各个文件及文件夹的作用,在哪里书写代码,又是在哪里添加资源,能够有一个直观的定位,特别是,不是从Android开发者转过来的同学,对于工程结构更应该及时的了解。