---

1 -> 为什么需要预加载？冷启动之痛与系统级破局

对于任何一款应用，启动速度都是用户的第一道体验门槛。想象一下，你点击一个游戏图标，却要盯着黑屏等待数秒——这期间用户很可能已经失去耐心。尤其是大型应用（如游戏、复杂的办公软件），冷启动时需要完成进程创建、资源加载、框架初始化等一系列操作，耗时往往很长。

传统的优化思路大多集中在应用内部：代码瘦身、异步加载、延迟初始化……这些手段虽然有效，但终究受限于设备性能和系统调度。有没有一种方式，能让系统在用户真正打开应用之前，就提前“预热”好一部分工作？

鸿蒙给出的答案是：应用预加载机制。 这不是简单的后台保活，而是一种基于用户行为预测的智能调度。系统会学习你的使用习惯——比如每天中午12点会打开某个办公应用，或者晚上8点会启动游戏——并在设备空闲、资源充裕时，悄悄地将这些应用加载到特定阶段。等到你真正点击图标时，应用就像已经热好身的运动员，只待最后冲刺。

这种机制的好处在于：

• 对用户：感知到的启动时间极大缩短，体验更流畅。
• 对开发者：无需在应用内写大量复杂的预判逻辑，只需声明希望预加载到哪个阶段，其余交给系统。
• 对系统：充分利用闲置资源，提升整体调度效率。

2 -> 预加载的运行机制：三个阶段，层层深入

预加载并非一揽子方案，而是提供了三个可选阶段，开发者可以根据应用自身的冷启动耗时分布来选择。这三个阶段就像“预热”的三个档位：越深的档位，提前完成的工作越多，启动时剩的工作越少，但预加载本身对资源的消耗也越大。

2.1 -> processCreated：只建进程，不跑代码

这是最浅的预加载阶段。当系统决定预加载你的应用时，它会：

• 创建一个空的应用进程。
• 初始化Application对象（即加载应用级别的资源、执行Application的attachBaseContext等，但不会调用任何生命周期回调，如onCreate）。

这个阶段的意义在于，进程创建本身是有开销的——系统需要为应用分配地址空间、启动主线程、加载基础库。如果能在后台提前完成这一步，那么当用户点击图标时，应用就已经有了一个现成的进程，直接进入Ability的创建流程，省去了进程创建的时间。

适合场景：那些进程创建耗时占比较高的应用，或者你暂时不想让任何代码提前执行，仅想节省进程创建开销。

2.2 -> abilityStageCreated：让AbilityStage活起来

AbilityStage是HAP包（特别是entry模块）的容器，它会在应用进程创建后、第一个UIAbility创建之前被初始化。预加载到这一阶段时，系统会：

• 完成processCreated的所有工作。
• 触发entry模块AbilityStage的onCreate生命周期回调。

在这个回调里，你可以执行一些全局的、不依赖UI的初始化操作。例如：

• 初始化数据库连接池。
• 预加载一些通用的配置数据。
• 设置全局异常监听器。

关键点：由于此时没有界面，任何涉及UI显示或交互的操作都不能在这里做。比如弹Toast、显示对话框、甚至依赖Window的API都是危险的——因为WindowStage还没创建。开发者需要在onCreate里通过launchParam.launchReason判断是否为预加载启动（仅windowStageCreated阶段可用），但abilityStageCreated阶段无法直接判断，但你可以通过其他方式（如静态变量）来标记当前是预加载环境，避免执行UI相关代码。

2.3 -> windowStageCreated：提前拉起UIAbility

这是最深度的预加载阶段。系统会：

• 完成前两个阶段的所有工作。
• 拉起entry模块的入口UIAbility（即module.json5中mainElement指定的Ability）。
• 依次触发该UIAbility的onCreate和onWindowStageCreate生命周期回调。

这意味着，你的UIAbility对象已经创建，甚至窗口环境（WindowStage）也已就绪——但窗口不会真正显示到屏幕上。在onCreate中，你可以通过launchParam.launchReason来精确判断当前是否由预加载启动，从而执行针对性的初始化逻辑。

例如，在大型游戏中，你可以在onCreate里提前加载游戏引擎的核心模块、解析场景数据，但不要执行与渲染相关的代码（因为窗口虽已创建，但尚未可见）。在onWindowStageCreate中，可以设置窗口属性、加载首屏资源，但要避免调用windowStage.setUIContent（设置布局）——因为一旦设置内容，可能会导致一些不必要的视图创建，且预加载期间视图不会显示，可能带来资源浪费。

注意：此阶段要求入口UIAbility的launchType必须为singleton或specified，因为系统需要确保Ability实例是可复用的，预加载创建的实例能直接用于后续的用户启动。

3 -> 开发实践：三步配置，一行判断

实现预加载的代码非常简单，核心在于配置文件的声明和启动原因的判断。下面以最深的windowStageCreated阶段为例，演示完整步骤。

3.1 -> 在app.json5中声明预加载阶段

{
  "app": {
    "bundleName": "com.example.hugegame",
    "vendor": "example",
    "versionCode": 1000000,
    "versionName": "1.0.0",
    "icon": "$media:app_icon",
    "label": "$string:app_name",
    "appPreloadPhase": "windowStageCreated" // 声明预加载到窗口创建阶段
  }
}

这个配置告诉系统：我的应用支持预加载，并且希望预加载到windowStageCreated阶段。系统会根据实际情况决定是否真的进行预加载，以及何时进行。你无法强制触发。

3.2 -> 配置入口UIAbility的module.json5

确保entry模块的配置正确：

{
  "module": {
    "name": "entry",
    "type": "entry",
    "mainElement": "EntryAbility",
    "abilities": [
      {
        "name": "EntryAbility",
        "srcEntry": "./ets/entryability/EntryAbility.ets",
        "launchType": "singleton", // 必须为singleton或specified
        "skills": [
          {
            "entities": ["entity.system.home"],
            "actions": ["ohos.want.action.home"]
          }
        ]
      }
    ]
  }
}

其中skills标签定义了Ability能够响应的意图。预加载机制正是通过这个隐式意图找到入口UIAbility的，所以不能省略。

3.3 -> 在UIAbility中判断启动原因

在EntryAbility.ets中，我们可以通过onCreate的参数获取启动原因：

import { AbilityConstant, UIAbility, Want } from '@kit.AbilityKit';
import { hilog } from '@kit.PerformanceAnalysisKit';

export default class EntryAbility extends UIAbility {
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    hilog.info(0x0000, 'testTag', 'onCreate called, launchReason: %{public}s', launchParam.launchReason);

    if (launchParam.launchReason === AbilityConstant.LaunchReason.PRELOAD) {
      // 预加载启动：只执行非UI相关的初始化
      hilog.info(0x0000, 'testTag', 'Preload started, do lightweight init.');
      // 例如：解析配置、预连接网络、初始化数据库
      this.preloadInit();
    } else {
      // 正常启动：执行完整初始化
      this.normalInit();
    }
  }

  onWindowStageCreate(windowStage: window.WindowStage): void {
    if (this.launchReason === AbilityConstant.LaunchReason.PRELOAD) {
      // 预加载模式下，只设置窗口属性，不加载具体内容
      windowStage.setWindowSystemBarProperties(...);
      // 注意：不要调用 windowStage.loadContent，以免创建不必要的视图
    } else {
      // 正常模式下，加载主界面
      windowStage.loadContent('pages/Index', (err, data) => { ... });
    }
  }

  private preloadInit() {
    // 预加载初始化逻辑
  }

  private normalInit() {
    // 正常初始化逻辑
  }
}

这里的关键是，在预加载路径中，我们只执行那些“即使不显示界面也能安全完成”的操作。比如提前建立网络连接、加载核心数据到内存、初始化音频引擎等。而涉及视图创建、资源加载到UI的操作，则放到正常启动路径中。

4 -> 技术深度：预加载的“能与不能”

4.1 -> 预加载过程中哪些事绝对不能做？

文档明确指出：预加载过程中不会显示任何界面，因此任何与界面显示、交互或依赖用户可见的操作都应避免。具体包括但不限于：

• 调用windowStage.loadContent加载布局（会导致视图树创建，但不会渲染，浪费内存）。
• 弹窗、对话框、Toast（需要窗口焦点，且用户看不见）。
• 依赖用户输入的代码逻辑。
• 执行高耗时的计算或I/O操作（因为预加载本身就是在系统空闲时进行，如果消耗太多资源，反而影响前台应用）。

4.2 -> 预加载的资源开销

预加载并非零成本。创建一个进程、初始化Application、甚至创建UIAbility，都会占用一定的内存和CPU。系统会根据资源充足程度、用户习惯的置信度来决定是否预加载。例如，如果你每天固定时间打开某个应用，系统可能会提前几分钟开始预加载；如果你只是偶尔打开，系统可能就不会预加载，以免浪费资源。

4.3 -> 如何选择合适的预加载阶段？

• 如果应用的冷启动瓶颈主要在进程创建（比如使用了大量so库，加载耗时），可以选择processCreated。
• 如果应用在AbilityStage中有一些重要的全局初始化，且这些初始化不耗太多资源，可以选择abilityStageCreated。
• 如果应用在UIAbility的onCreate和onWindowStageCreate中有很多耗时操作（比如游戏引擎初始化、复杂场景预构建），且这些操作可以在无UI的情况下安全执行，那么windowStageCreated是理想选择。

需要权衡的是：越深的预加载，提前完成的工作越多，启动速度提升越明显，但对系统资源的占用也越大，且可能增加预加载失败的概率（比如资源不足时无法完成预加载）。开发者可以通过反复测试冷启动各阶段的耗时，找到瓶颈，再决定预加载到哪个阶段。

4.4 -> 预加载对生命周期的影响

当预加载创建的UIAbility最终被用户启动时，它不会重新走onCreate，而是直接从onWindowStageCreate继续（如果之前已经执行到该阶段）。但注意，预加载期间可能没有执行loadContent，所以用户启动时，需要补充调用loadContent来显示界面。此外，如果预加载期间已经执行了一些初始化，要确保这些初始化不会在正常启动时重复执行（可以用标志位控制）。

5 -> 约束与展望：当前限制与未来可能

目前，应用预加载机制有明确的约束：

• 仅支持2in1设备（如平板、折叠屏等）。手机暂不支持，这可能与资源调度策略有关。
• 仅支持entry模块的AbilityStage和UIAbility。即只有主模块可以预加载，其他模块（如feature）暂时不行。
• 预加载时机由系统全权决定，开发者无法干预。这是为了保证系统整体流畅度。

随着鸿蒙的演进，未来很可能将这一能力扩展到更多设备类型和更多模块。对于开发者而言，现在就可以在2in1设备上尝试，提前积累经验。

6 -> 总结：从“被动优化”到“主动协同”

应用预加载机制，本质上是一种系统与应用协同的优化策略。它不再是开发者单方面在应用内部“死磕”启动速度，而是将一部分工作交给更懂全局的系统，让系统在恰当的时机、以恰当的深度，帮应用提前“热身”。

这种思路对于未来操作系统的发展有着启示意义：随着设备算力增强和AI普及，系统将越来越智能，能够预测用户行为并主动优化。开发者需要做的，就是遵循规范，拥抱这些系统级能力，让应用成为智慧生态的一部分。

对于用户而言，这种机制带来的体验提升是润物细无声的——你只是感觉应用打开变快了，甚至没有察觉背后的技术。而这，正是好的技术该有的样子。

如果你正在开发大型应用，不妨在鸿蒙6.0的2in1设备上试试预加载功能。只需简单配置，或许就能让你的启动速度迈上一个新台阶。

---

感谢各位大佬支持！！！
互三啦！！！