回复
应用启动框架AppStartup应用场景分析
OwenOO
发布于 2024-8-1 16:41
浏览
0收藏
启动框架应用场景
大型应用在启动过程中会加载大量的模块或SDK，各个模块或SDK还有依赖，模块或SDK加载要有一套管理机制，否则会杂乱无章，都耦合在一起，进而会影响启动性能。
AppStartup提供在应用启动时初始化组件的简单而高效的方法。
1. 更好管理应用程序初始化过程，避免出现初始化错误、重复初始化等问题。
2. 提高应用程序的启动速度和用户体验。
启动流程介绍（自动模式）
自动模式下启动框架的执行顺序在创建AbilityStage和执行AbilityStage onCreate回调之间。
那启动框架内的任务执行顺序是什么样子呢？ 基于以下配置，进行任务时序分析。
注意：
1. configEntry是启动框架初始化组件的全局配置入口函数。主要包括 【执行所有组件初始化的超时时间】 和 【表示启动框架的监听器，该监听器将在所有组件初始化完成时调用】。
2. 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钩子函数手动执行任务。
1. 修改启动框架配置文件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);
}
}
...
}3. 加载结果。
场景二：超时场景分析
场景介绍
从启动框架配置文件StartupConfig.ets可知，启动框架配置需要在StartupConfigEntry中设置StartupConfig与StartupListener。如下图所示：
当SDK加载超时（组件实际加载时间 > 设置的超时时间）之后，就会造成APP启动异常。
实现代码
1. 设置超时时间，如上图所示，设置500ms超时时间。
2. 在 StartupTask_001的初始化回调函数中，等待2s。
结果分析及解决
可以看到，启动框架组件初始化异常报错，且APP也无法正常启动。
超时时间设置过短，APP启动异常；超时时间设置过长，又不符合正常APP启动组件加载逻辑，那么该如何正确设置超时时间呢？
那么就分析所有组件加载的时间，根据业务需求设置一个最合适的启动框架超时加载时间。那又如何去进行组件加载的耗时统计分析呢？请参考场景三。
场景三：耗时统计分析
场景介绍
对于加载大量模块（SDK）， CPU、网络、异常、音视频模块、广告模块、日志模块、推送模块等 都可能成为系统的性能瓶颈。那APP加载对于不同模块依赖做耗时统计分析，就成为性能调优的一个必要手段。
针对不同模块的加载或任务处理，利用StartupConfigEntry文件中配置的超时时间以及组件初始化的监听器，结合启动框架中支持的依赖回调指标做数据埋点，统计耗时组件加载。以统计StartupTask_001的加载时间为例，统计结果：
实现代码
1. 由于我们添加启动框架配置时，StartupConfigEntry已经配置了超时时间和组件初始化的监听器，此步骤不再重复。
2. 根据拓扑排序，我们可以知道组件间的加载顺序。
3. 分析统计耗时场景，修改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"
}4. 开始时间埋点。
在任务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
};
}
}5. 结束时间埋点。
在依赖加载结束后记录任务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));
}
}
常见问题
1. 有向无环图（拓扑排序）
有向无环图：在图论中，如果一个有向图从任意顶点出发无法经过若干条边回到该点，则这个图是一个有向无环图（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}。
1. AppStartup的作用。
AppStartup提供了一种更加简单高效的初始化组件的方式，支持异步初始化组件加速应用的启动时间。使用启动框架应用开发者只需要分别为待初始化的组件实现AppStartup提供的StartupTask接口，并在startup_config中配置AppStartup之间的依赖关系，启动框架将使用拓扑排序保证各个待初始化组件的初始化顺序。启动框架只支持在entry中使用。
参考文档：应用启动框架AppStartup。
分类
已于2024-8-1 16:41:52修改
赞
收藏
回复
相关推荐
