【鸿蒙实战开发】应用启动框架AppStartup应用场景分析

代码改变世界996

于 2024-08-02 20:01:52 发布

阅读量923

点赞数 20

分类专栏：鸿蒙安卓前端文章标签： harmonyos php 华为鸿蒙安卓前端

本文链接：https://blog.csdn.net/HarmonyOS007/article/details/140878986

版权

鸿蒙同时被 3 个专栏收录

201 篇文章 2 订阅

订阅专栏

安卓

201 篇文章 0 订阅

订阅专栏

前端

201 篇文章 0 订阅

订阅专栏

启动框架应用场景

大型应用在启动过程中会加载大量的模块或SDK，各个模块或SDK还有依赖，模块或SDK加载要有一套管理机制，否则会杂乱无章，都耦合在一起，进而会影响启动性能。

AppStartup提供在应用启动时初始化组件的简单而高效的方法。

更好管理应用程序初始化过程，避免出现初始化错误、重复初始化等问题。
提高应用程序的启动速度和用户体验。

启动流程介绍（自动模式）

自动模式下启动框架的执行顺序在创建AbilityStage和执行AbilityStage onCreate回调之间。

那启动框架内的任务执行顺序是什么样子呢？基于以下配置，进行任务时序分析。

注意：

configEntry是启动框架初始化组件的全局配置入口函数。主要包括【执行所有组件初始化的超时时间】和【表示启动框架的监听器，该监听器将在所有组件初始化完成时调用】。
startupTasks配置中的 srcEntry 表示需要加载的组件实现的入口函数。

以下是startup_config.json文件中的配置。

{ 
  "startupTasks": [ 
  { 
    "name": "StartupTask_001", 
    "srcEntry": "./ets/Startup2/StartupTask_001.ets", 
    "dependencies": [] 
  }, 
  { 
    "name": "StartupTask_002", 
    "srcEntry": "./ets/Startup2/StartupTask_002.ets", 
    "dependencies": [ 
      "StartupTask_001" 
    ] 
  } 
  ], 
  "configEntry": "./ets/Startup2/StartupConfig.ets" 
}

场景以及解决方案

场景介绍

在开发应用的时候，一般都会引入SDK，而大部分SDK都要求我们在Application启动前初始化，当我们引入的SDK越来越多，就会出现Application启动时间越来越长，如果SDK的初始化任务相互依赖，还要处理很多条件判断。如果都在主线程按照顺序初始化，或者再加上异步初始化。那APP的启动性能就会非常差。

举例： xx银行应用初始化模块加载，广告模块、人脸识别模块、APM模块、配置中心模块、数据管理模块、静态配置模块、H5灰度模块、首页加载模块、启动模块、定位模块、日志模块、登录模块、网络模块、离线模块、弹屏模块、隐私模块、推送模块、路由模块、安全模块、埋点模块、音视频模块、银联支付模块、url安全校验模块、用户中心模块、设备管理模块、X5初始化模块。

优势：减少手动加载的错误率。

配置启动框架AppStartup，应用启动时初始化组件。

SDK/组件/任务依赖关系如下图所示：

最终发现组件的加载顺序为：1->2->4->3->5。

应用步骤配置以及介绍

启动框架手动配置

其他步骤同自动配置步骤一样，不同点是需要改动startup_config.json配置项excludeFromAutoStart为true。然后在EntryAbility的onCreate钩子函数手动执行任务。

修改启动框架配置文件startup_config.json添加初始化组件。

[ 
  { 
    "name": "StartupTask_00C", 
    "srcEntry": "./ets/Startup1/StartupTask_00C.ets", 
    "dependencies": [ 
      "StartupTask_00A", 
      "StartupTask_00B" 
    ], 
    "runOnThread": "mainThread", 
    "waitOnMainThread": false, 
    "excludeFromAutoStart": true 
  } 
... 
]

依赖关系如下图所示：

2.在EntryAbility的onCreate钩子函数调用startupManager.run()。

import startupManager from '@ohos.app.appstartup.startupManager'; 

export default class EntryAbility extends UIAbility { 
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void { 
    hilog.info(0x0000, 'testTag', '%{public}s', 'Ability onCreate'); 
    let startParams = ['StartupTask_00C']; 
    try { 
      startupManager.run(startParams).then(() => { 
        console.log('StartupTest startupManager run then, startParams'); 
      }).catch((error: BusinessError) => { 
        console.info("StartupTest promise catch error, error" + JSON.stringify(error)); 
        console.info("StartupTest promise catch error, startParams" 
          + JSON.stringify(startParams)); 
      }) 
    } catch (error) { 
      let errMsg = JSON.stringify(error); 
      let errCode: number = error.code; 
      console.log('Startup catch error , errCode' + errCode); 
      console.log('Startup catch error ,error' + errMsg); 
    } 
  } 
  ... 
}

加载结果。

场景二：超时场景分析

场景介绍

从启动框架配置文件StartupConfig.ets可知，启动框架配置需要在StartupConfigEntry中设置StartupConfig与StartupListener。如下图所示：

当SDK加载超时（组件实际加载时间 > 设置的超时时间）之后，就会造成APP启动异常。

实现代码

设置超时时间，如上图所示，设置500ms超时时间。
在 StartupTask_001的初始化回调函数中，等待2s。

结果分析及解决

可以看到，启动框架组件初始化异常报错，且APP也无法正常启动。

超时时间设置过短，APP启动异常；超时时间设置过长，又不符合正常APP启动组件加载逻辑，那么该如何正确设置超时时间呢？

那么就分析所有组件加载的时间，根据业务需求设置一个最合适的启动框架超时加载时间。那又如何去进行组件加载的耗时统计分析呢？请参考场景三。

场景三：耗时统计分析

场景介绍

对于加载大量模块（SDK）， CPU、网络、异常、音视频模块、广告模块、日志模块、推送模块等都可能成为系统的性能瓶颈。那APP加载对于不同模块依赖做耗时统计分析，就成为性能调优的一个必要手段。

针对不同模块的加载或任务处理，利用StartupConfigEntry文件中配置的超时时间以及组件初始化的监听器，结合启动框架中支持的依赖回调指标做数据埋点，统计耗时组件加载。以统计StartupTask_001的加载时间为例，统计结果：

实现代码

由于我们添加启动框架配置时，StartupConfigEntry已经配置了超时时间和组件初始化的监听器，此步骤不再重复。
根据拓扑排序，我们可以知道组件间的加载顺序。
分析统计耗时场景，修改startup_config：

{ 
  "startupTasks": [ 
  { 
    "name": "StartupTask_002", 
    "srcEntry": "./ets/Startup2/StartupTask_002.ets", 
    "dependencies": [ 
      "StartupTask_001" 
    ], 
    "runOnThread": "mainThread", 
    "waitOnMainThread": false 
  }, 
  { 
    "name": "StartupTask_001", 
    "srcEntry": "./ets/Startup2/StartupTask_001.ets", 
    "dependencies": [], 
    "runOnThread": "mainThread", 
    "waitOnMainThread": false 
  } 
  ], 
  "configEntry": "./ets/Startup2/StartupConfig.ets" 
}

开始时间埋点。

在任务1开始时记录开始时间。

import StartupTask from '@ohos.app.appstartup.StartupTask'; 
import common from '@ohos.app.ability.common'; 
import hilog from '@ohos.hilog'; 

interface TaskResult { 
  taskName: string 
  startRunTime?: number 
} 

export default class StartupTask_001 extends StartupTask { 
    async init(context: common.AbilityStageContext): Promise<TaskResult> { 
    this.startTime = new Date().getTime() 
    hilog.info(0x0000, 'testTag', `StartupTask_001 init.  runtime_start: ${new Date().getTime()}`); 
    await this.delay(2000) 
    return { 
      taskName:  'StartupTask_001', 
      startRunTime:this.startTime 
    }; 
  } 
}

结束时间埋点。

在依赖加载结束后记录任务1的结束时间。此时 onDependencyCompleted参数result是任务1执行结束后返回的结果。

import StartupTask from '@ohos.app.appstartup.StartupTask'; 
import common from '@ohos.app.ability.common'; 
import hilog from '@ohos.hilog'; 

interface TaskResult { 
  taskName: string 
  startRunTime: number 
} 

export default class StartupTask_002 extends StartupTask { 

  async init(context: common.AbilityStageContext) { 
    hilog.info(0x0000, 'testTag', 'StartupTask_002 init.'); 
    return 'StartupTask_002'; 
  } 

  onDependencyCompleted(dependence: string, result: TaskResult): void { 
    const endRunTime = new Date().getTime() 
    hilog.info(0x0000, 'ResultTag', `startRunTime: ${result.startRunTime} endRunTime: ${endRunTime}  total-time: ${endRunTime-result.startRunTime}`); 
    hilog.info(0x0000, 'testTag', 'StartupTask_002 onDependencyCompleted, dependence: %{public}s, result: %{public}s', 
      dependence, JSON.stringify(result)); 
  } 
}

常见问题

有向无环图（拓扑排序）

有向无环图：在图论中，如果一个有向图从任意顶点出发无法经过若干条边回到该点，则这个图是一个有向无环图（DAG, Directed Acyclic Graph）。拓扑排序（Topological Sorting）是一个有向无环图（DAG, Directed Acyclic Graph）的所有顶点的线性序列。且该序列必须满足下面两个条件：

− 每个顶点出现且只出现一次。

若存在一条从顶点 A 到顶点 B 的路径，那么在序列中顶点 A 出现在顶点 B 的前面。

它是一个DAG图，那么如何写出它的拓扑排序呢？

这里说一种比较常用的方法：从DAG图中选择一个没有前驱（即入度为 0）的顶点并输出。从图中删除该顶点和所有以它为起点的有向边，重复1和2直到当前的DAG图为空或当前图中不存在无前驱的顶点为止，后一种情况说明有向图中必然存在环。

于是，得到拓扑排序后的结果是 {1, 2, 4, 3, 5}。

AppStartup的作用。

AppStartup提供了一种更加简单高效的初始化组件的方式，支持异步初始化组件加速应用的启动时间。使用启动框架应用开发者只需要分别为待初始化的组件实现AppStartup提供的StartupTask接口，并在startup_config中配置AppStartup之间的依赖关系，启动框架将使用拓扑排序保证各个待初始化组件的初始化顺序。启动框架只支持在entry中使用。

写在最后

●如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：
●点赞，转发，有你们的『点赞和评论』，才是我创造的动力。
●关注小编，同时可以期待后续文章ing🚀，不定期分享原创知识。
●更多鸿蒙最新技术知识点，请移步前往小编：https://gitee.com/

在这里插入图片描述

代码改变世界996

关注

20
点赞
踩
16

收藏

觉得还不错? 一键收藏
0
评论
【鸿蒙实战开发】应用启动框架AppStartup应用场景分析

自动模式下启动框架的执行顺序在创建AbilityStage和执行AbilityStage onCreate回调之间。那启动框架内的任务执行顺序是什么样子呢？基于以下配置，进行任务时序分析。注意：configEntry是启动框架初始化组件的全局配置入口函数。主要包括【执行所有组件初始化的超时时间】和【表示启动框架的监听器，该监听器将在所有组件初始化完成时调用】。startupTasks配置中的 srcEntry 表示需要加载的组件实现的入口函数。
复制链接

扫一扫

专栏目录