Launcher 源码开发说明

1. 项目介绍

Launcher 作为系统人机交互的首要入口，提供应用图标的显示、点击启动、卸载应用，并提供桌面布局设置以及最近任务管理等功能。
Launcher 采用纯 JS 语言开发，开发过程中不涉及任何 Java 部分的代码。

2. 工程结构

目录结构

整体架构

Launcher 整体以 OpenHarmony 既有的 MVVM 的 App 架构设计为基础，向下扩展出一套 MVP（View, Presenter, Model）分层架构（既有的 MVVM 框架整体理解为新扩展的 MVP 框架的 View 层），用于处理 Launcher 的业务逻辑与数据管理。 应用整体采用了多模块的设计方式，每个模块都遵循上述架构原则。

各层的作用分别如下：

  • 视图层（View）：负责更新 UI 显示以及触摸与点击事件的监听。
  • 展现层（Presenter）：负责处理视图层（View）发送的业务逻辑处理请求，并连通 Model 层获取数据。
  • 模型层（Model）：负责处理展现层（Presenter） 中关于数据处理的请求以及返回数据请求结果。

应用各层中重要类及其功能如下表所示

模块 层级 类名 作用
launcher 视图层 EntryView 桌面入口画面的视图层逻辑控制类。
launcher 视图层 AppGridView 桌面网格视图画面的视图层逻辑控制类。
launcher 视图层 AppListView 桌面列表视图画面的视图层逻辑控制类。
launcher 展现层 EntryPresenter 桌面入口画面的展现层业务逻辑类，主要职责是判断桌面类型，以决定展现网格视图或者列表视图。
launcher 展现层 AppGridPresenter 桌面网格布局的展现层业务逻辑类，主要职责是接收视图层请求，处理逻辑业务，业务逻辑处理后实现功能或者向模型层发送请求。
launcher 展现层 AppListPresenter 桌面列表布局的展现层业务逻辑类，主要职责是接收视图层请求，处理逻辑业务，业务逻辑处理后实现功能或者向模型层发送请求。
launcher 模型层 AppModel 接收展现层AppGridPresenter和AppListPresenter发送过来的请求，为其提供所需要的数据或实现其请求的功能。
launcher 模型层 SettingsModel 接收展现层EntryPresenter和SettingsPresenter发送过来的请求，为其提供所需要的数据或实现其请求的功能。
recent 视图层 RecentsView 最近任务列表视图画面的视图层逻辑控制类。
recent 展现层 RecentsPresenter 最近任务列表的展现层业务逻辑类，主要职责是接收视图层请求，处理逻辑业务，业务逻辑处理后实现功能或者向模型层发送请求。
recent 模型层 RecentsModel 接收展现层RecentsPresenter发送过来的请求，为其提供所需要的数据或实现其请求的功能。
settings 视图层 SettingsView 桌面设置画面的视图层层逻辑控制类。
settings 展现层 SettingsPresenter 设置桌面画面的业务逻辑类，主要职责是处理来自视图层的请求，业务逻辑处理后实现功能或者向模型层发送请求。
settings 模型层 SettingsModel 接收展现层EntryPresenter和SettingsPresenter发送过来的请求，为其提供所需要的数据或实现其请求的功能。

3. 基础开发说明

异步回调的使用

在JS工程中，异步回调的使用是一个非常常见的编码需求，在 OpenHarmony 的开发中也不例外，这里以获取应用列表信息为例，演示如何在 OpenHarmony 的应用开发中使用回调方法。

AppPresenter.jsAppModel.jsAppView.js
import BundleMgr from ‘@ohos.bundle’;



export default class AppModel {



// 获取应用信息
   getApplicationInfos(callback) {



  // callback 为传入的异步回调方法
  BundleMgr.getAllBundleInfo().then(data => {

     // 在获取数据成功后，执行回调方法
     callback(data);
  });




}
}​
export default class AppPresenter {



constructor(AppModel) {



  this.appModel = AppModel;




}



// 获取应用信息
   getApplicationInfos(callback) {



  appModel.getApplicationInfos(callback);




}
}​
import AppPresenter from ‘./AppListPresenter.js’;



var appPresenter;



export default {
   data: {



  appList: []




},
   onInit() {



  appPresenter = new AppPresenter(this.$app.$def.data.appModel);

  // 绑定回调方法
  appPresenter.getApplicationInfos(this.applicationInfosCallback.bind(this))




},



// 定义获取数据的回调方法
   applicationInfosCallback(data) {



  this.appList = data;




}
}​
AppModel.jsgetApplicationInfosAppView.js

资源引用

定义资源文件

src/main/resources/

引用资源

this.title = this.$r(‘app.string.title’);​

4. 典型接口的使用

import FeatureAbility from ‘@ohos.ability.featureAbility’;
//参数paramAbilityname, paramBundleName 是对应应用的abilityname，bundleName
startAbility(paramAbilityname, paramBundleName) {
   FeatureAbility.startAbility({



  bundleName: paramBundleName,
  abilityName: paramAbilityname,
  requestCode: 1,
  abilityType: "PageAbility",
  want:{
        action: "action1",
        entities: ["entity1"],
        type: "PageAbility",
        flags: 2,
        elementName: {
           deviceId : "deviceId",
           bundleName : paramBundleName,

           abilityName : paramAbilityname,
        },
  },
  syncOption: 1,




}).then(data =>



  console.info("Launcher promise::then : " + JSON.stringify(data))




).catch(error =>



  console.info("Launcher promise::catch : " +JSON.stringify(error) )




);
}
  ​
import BundleMgr from ‘@ohos.bundle’;
//参数bundleName 是对应应用的bundleName
getBundleInfo(bundleName) {
   BundleMgr.getBundleInfo(bundleName).then(data => {



  console.info('Launcher getBundleInfo ' + data);




});
}​
import BundleMgr from ‘@ohos.bundle’;



getApplicationInfos() {
   BundleMgr.getAllBundleInfo().then((data) => {



  console.info('Launcher getAllBundleInfo '+JSON.stringify(data));




});
}​
import BundleMgr from ‘@ohos.bundle’;
//参数bundleName 是对应应用的bundleName
uninstallApp(bundleName) {
   var result = BundleMgr.getBundleInstaller().then((data) =>{



  data.uninstall(bundleName,{
     param: {
        userId: 0,
        installFlag: 0,
        isKeepData: false
     }
  })
  console.info("Launcher uninstall data [" + JSON.stringfy(data) + "]");




}).catch(error => console.info(“Launcher uninstall err ” + error));
}​
import storage from ‘@ohos.data.storage’;
//保存数据的落盘位置
const PREFERENCES_PATH = ‘/data/accounts/account_0/appdata/com.ohos.launcher/sharedPreference/LauncherPreference’;
//键值对标识key，类似localStorage用法
const PREFERENCES_KEY = ‘PREFERENCES_KEY’;



save(data) {
   mPreferences.putSync(PREFERENCES_KEY, data);
   mPreferences.flushSync();
}



get() {
   var data = mPreferences.getSync(PREFERENCES_KEY, “defaultValue”);
   return data;
}​
import NapiAbilityManager from ‘@ohos.app.abilityManager’;



getRecentMissions() {
   NapiAbilityManager.queryRunningAbilityMissionInfos().then((data) => {



   console.info("Launcher getRecentMissions data [" + data + "]");




});
}​
import NapiAbilityManager from ‘@ohos.app.abilityManager’;
//参数missionId是所选择的最近任务的missionId
removeMission() {
   NapiAbilityManager.removeMission(missionId).then((data) => {



  console.info('Launcher removeMission data [' + data + ']');




});
}​

5. 签名打包

签名

签名文件的获取

  1. 拷贝 OpenHarmony 标准版的 prebuilts\signcenter 目录到操作目录。
  2. 拷贝Launcher工程的 signature\launcher.p7b 到该目录下。

签名文件的配置

打开项目工程，选择 File → Project Structure

选择 Modules → Signing Configs，将对应的签名文件配置如下，完成后点击Apply，再点击OK。 密码为生成签名文件时的密码，如果使用默认的签名文件，则使用默认密码123456。

配置完成后，对应的build.gradle文件中会出现如下内容

打包

DevEco Studio 支持 debug 与 release 两种打包类型。可以在 OhosBuild Variants 窗口中进行切换。

release打包

  1. 代码准备完成后，在 OhosBuild Variants 窗口的 Selected Variant 中选择 release

  2. 选择Build → Build Haps(s)/APP(s) → Build Hap(s)
  3. 编译完成后，hap包会生成在工程目录下的 \build\outputs\hap\release\路径下（如果没有配置签名，则只会生成未签名的hap包）

6. 安装、运行、调试

应用安装

配置 hdc： 进入SDK目录中的toolchains文件夹下，获取文件路径：

并将此路径配置到环境变量中：

hdc list targets

等待一段时间后，窗口出现如下打印，可回到输入 hdc list targets 的命令窗口继续操作:

再次输入hdc list targets，出现如下结果，说明hdc连接成功

获取 root 权限与读写权限：

hdc target mount

T.B.D smode 不执行的情况下，hdc target mount 能否正常执行？

/system/app
hdc file send 本地路径 /system/app/hap包名称
Launcher.hapsystem/app/Launcher.hap
hdc file send Launcher.hap /system/app/Launcher.hap

 

/system/app
hdc shell
cd system
mkdir app
chmod 777 app

/system/app

但hap包需要在该目录下手动设置权限

chmod 666 hap包名

此目录应用不用手动安装，系统自动拉起。

 

应用运行

/system/app
hdc shell
reboot
（不可以直接执行hdc reboot，命令是无效的)

 

reboothdc shell reboot

注意，如果设备之前安装过系统应用，则需要执行如下两条命令清除设备中存储的应用信息才能够在设备重启的时候将我们装入设备的新 hap 包正常拉起。

hdc shell rm -rf /data/accounts/
hdc shell rm -rf /data/misc_de/0/mdds/0/default/bundle_manager_service

 

应用调试

log打印

console.info(“Launcher log info”);​

可以在DevEco Studio中查看log

log获取及过滤

  • log获取

将log输出至文件

hdc shell hilog > 输出文件名称

 

例： 在真实环境查看log，将全log输出到当前目录的hilog.log文件中

hdc shell hilog > hilog.log

 

  • log过滤

在命令行窗口中过滤log

hilog | grep 过滤信息

 

例：过滤包含信息 Label 的 hilog

hilog | grep Label

 

7. 贡献代码

Fork 代码仓库

  1. 在码云上打开 Launcher 代码仓库（仓库地址）。
  2. 点击仓库右上角的 Forked 按钮
  3. 在弹出的画面中，选择将仓库 fork 到哪里，点击确认。
  4. Fork 成功之后，会在自己的账号下看见 fork 的代码仓库。

提交代码

git clone 步骤1中复制的地址​
git addgit commitgit push

发起 Pull Request (PR)

在将代码提交到 fork 仓之后，我们可以通过发起 Pull Request（PR）的方式来为 OpenHarmony 的相关项目贡献代码。

Pull Requests新建 Pull Request在 新建 Pull Request 画面填入标题与说明，点击 创建 按钮。新建 Pull Request创建创建 Pull Request 完成。 PR 创建完成后，会有专门的代码审查人员对代码进行评审，评审通过之后会合入相应的代码库。