这篇我们来了解一下harmonyOS的项目结构，包括目录结构及其作用，配置文件的基础配置信息

1. 项目整体结构

之前我们创建过一个项目，有一个文本展示和一个按钮，每点击一次数字加1并显示在文本框中。本篇我们基于这个基础项目了解一下项目的整体结构和其中的配置，项目的整体结构如图：

horzion架构 harmonyos架构_配置信息

 

 

　　首先有一个entry目录，结合上篇的内容，我们知道一个应用是由一个或多个Hap包所组成的，Hap包又可以分为entry类型和feature类型，每个Hap包由：代码、资源、第三方库及应用配置文件组成。所以我们代码中的entry目录其实就一个应用的Hap包，它的类型的entry类型的Hap包。一个Hap包由代码、资源、第三方库及应用配置文件组成，接着我们来看这些资源，代码等都分布在entry包的哪里

　　在src/main/java下以包名命名的文件夹内分布着Java代码。这里的代码可以用来创建布局，动态调整布局以及为交互提供支撑服务。

　　和java文件夹同级的resources目录下分布应用资源，该目录的base目录下，按资源用途又分为多个文件夹资源：

  • element：表示元素资源，该文件夹下主要存放json格式的文件，主要用来表示 字符串、颜色值、布尔值等，可以在其他地方被引用
  • graphic：表示可绘制资源。用xml文件来表示，比如我们项目中设置的  圆角按钮、按钮颜色等都是通过引用这里的资源来统一管理的
  • layout：表示布局资源，用xml文件来表示，比如页面的布局资源，都放在这里
  • media：表示媒体资源，包括图片、音频、视频等非文本格式的文件。

　　除了上述的这四类，还有其他类型的资源，因为我们项目暂时用不到，先不做考虑。resources目录存储的内容截图如下：

horzion架构 harmonyos架构_horzion架构_02

 

 

　　和main目录平级的test目录是测试目录，可以用于对自己写的功能添加单元测试，确保代码的正确性

　　和src平级的libs目录用来存储引用三方一些包，例如jar包，so包等。

　　而和entry目录平级的build目录，则用来存放最终编译完成后的包，也就是hap包。编译后该包的内容如下：

horzion架构 harmonyos架构_HarmonyOS_03

 

 

最终在该目录下会生成一个hap包。这个hap包中包含了我们项目中用到的图片，布局，代码和各种资源。

2. 项目的配置文件：

　　每一个hap包下都包含了该hap包的配置信息，这个配置文件位于：entry/src/main/目录下，由工具帮我们生成，命名为config.json，harmonyOS应用配置采用json格式的形式。下面我们来看一下这个配置文件中的内容，并简要介绍一下配置的作用。该配置文件中，主要有三个模块，如下图：

horzion架构 harmonyos架构_配置文件_04

 

 

  • “app”配置必须保持一致。
  • deviceConfig：表示应用在具体设备上的配置信息。
  • module：表示HAP包的配置信息。该标签下的配置只对当前HAP包生效。

配置文件采用json格式，其中的属性不分先后顺序，每个属性只允许出现一次。

下面具体看一下我们项目中出现的配置项都有哪些，以及它的作用：

2.1 app下的属性

horzion架构 harmonyos架构_鸿蒙_05

 bundleName：表示应用的包名，用于标识应用的唯一性。通常采用反转的域名

vendor：表示开发应用的厂商

version：code表示内部版本号，用于系统管理版本使用，对用户不可见，name表示应用的版本号，用于向用户呈现

apiVersion：包含三个选项。

　　compatible：表示应用运行需要的API最小版本。

　　target：表示应用运行需要的API目标版本。

　　releaseType：表示应用运行需要的API目标版本的类型，取值为“CanaryN”、“BetaN”或者“Release”，其中，N代表大于零的整数。

  • Canary：受限发布的版本。
  • Beta：公开发布的Beta版本。
  • Release：公开发布的正式版本。

deviceConfig：表示应用在具体设备上的配置信息。我们这里暂时没用到

2.2 module下的配置：

"module": {
    "package": "com.example.demo",  //表示HAP的包结构名称，在应用内应保证唯一性。采用反向域名格式
    "name": ".MyApplication",  //表示HAP的类名。采用反向域名方式表示，因为我们指定了package，所以可以直接以.加类名的形式指定
    "deviceType": [   //表示允许Ability运行的设备类型。phone表示手机
      "phone"
    ],
    "distro": {　　//表示HAP发布的具体描述
      "deliveryWithInstall": true,  //表示当前HAP是否支持随应用安装。true为支持随应用安装
      "moduleName": "entry",  //表示当前HAP的名称。
      "moduleType": "entry"  //表示当前HAP的类型，包括两种类型entry和feature
    },
    "abilities": [　　//表示当前模块内的所有Ability
      {
        "skills": [  //表示Ability能够接收的Intent的特征
          {
            "entities": [
              "entity.system.home"  //表示能够接收的Intent的Ability的类别（如视频、桌面应用等），可以包含一个或多个entity。
            ],
            "actions": [
              "action.system.home"  //表示能够接收的Intent的action值，可以包含一个或多个action
            ]
          }
        ],
        "orientation": "unspecified",  //表示该Ability的显示模式，这里表示由系统自动判断方向
        "name": "com.example.demo.MainAbility",  //表示Ability名称。取值可采用反向域名方式表示，由包名和类名组成，也可以才用.开头的形式表示
        "icon": "$media:icon",  //表示Ability图标资源文件的索引，$media表示引用media目录下的icon资源
        "description": "$string:mainability_description",  //表示对Ability的描述
        "label": "first_demo",  //表示Ability对用户显示的名称，也就是你的应用安装用户设备后显示的名称
        "type": "page",  //表示Ability的Type类型，可以为page,service或data
        "launchType": "standard"  //表示Ability的启动模式，支持“standard”和“singleton”两种模式, standard表示可以有多个实例，single则是一个实例。
      }
    ]
  }

由于module下的配置较多，截图无法截全，把配置贴出来，同时采用注释的形式对每个配置进行说明

 本篇了解了基本的项目结构，以及各个资源目录的情况，还有config配置文件中的基本配置项。

下一篇会介绍Ability的生命周期，生命周期很重要，如果想合理的使用应用资源，给用户良好的体验，生命周期至关重要。