鸿蒙面试必备：Stage 模型、Ability 与 ArkTS 高频题

鸿蒙岗位的面试，几乎一定会从 Stage 模型与 Ability 开问。因为它决定了你对应用生命周期、进程结构与组件边界的理解深度——这是”会不会写”和”懂不懂”的分界线。

本文按高频真题组织，覆盖 Stage 模型、Ability 类型、生命周期、进程通信与 ArkTS 语言特性。

一、先讲清：什么是 Stage 模型

Q1：鸿蒙有哪几种应用模型？现在该用哪个？
早期有 FA（Feature Ability）模型，当前主流是 Stage 模型。Stage 模型以 AbilityStage 作为应用进程的入口与容器，向下管理各类 Ability 组件。新项目一律使用 Stage 模型。

Q2：Stage 模型相比 FA 模型的核心改进是什么？

• 组件与进程解耦更清晰：Ability 不再直接承载窗口，窗口概念被独立出来；
• 生命周期更细、更可控：区分了 UIAbility 的生命周期与窗口生命周期；
• 更利于多设备与多窗口形态：同一 Ability 可对应不同窗口形态，适配折叠屏、平板、多窗口更自然；
• 内存回收更合理：后台 Ability 可被回收而保留应用进程状态。

Q3：AbilityStage、UIAbility、ExtensionAbility 分别是什么？

二、生命周期：最常考的连线题

Q4：UIAbility 的生命周期有哪些回调？
核心链路：onCreate → onWindowStageCreate → onForeground → onBackground → onWindowStageDestroy → onDestroy。

要点：onWindowStageCreate 里加载页面内容（windowStage.loadContent()），onForeground/onBackground 处理前后台切换时的资源申请与释放。

export default class EntryAbility extends UIAbility {
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) {
    // 应用级初始化
  }
  onWindowStageCreate(windowStage: window.WindowStage) {
    windowStage.loadContent('pages/Index', (err) => {
      if (err.code) { /* 处理错误 */ }
    })
  }
  onForeground() { /* 回到前台：恢复定位、传感器 */ }
  onBackground() { /* 退到后台：释放资源、保存状态 */ }
}

Q5：UIAbility 生命周期和页面（Page）生命周期的区别？
两者是不同层级：UIAbility 的生命周期由系统调度（前后台、销毁），页面生命周期则是组件内部的（onPageShow、onPageHide、aboutToAppear、aboutToDisappear）。一个 UIAbility 可以包含多个页面，页面跳转不会触发 UIAbility 的生命周期变化。

Q6：Want 是什么？
Want 是组件间信息传递的载体，用于启动 Ability 时指定目标（bundleName、abilityName）以及携带参数。它类似于 Android 的 Intent，是面试中常被要求解释的概念。

三、ArkTS 语言特性：TS 背景也要小心

Q7：ArkTS 和 TypeScript 是什么关系？
ArkTS 是 TypeScript 的超集，在 TS 基础上强化了静态类型约束，通过方舟编译器编译为字节码运行。它不是”增强版 TS”，而是”受限并静态化的 TS”——这个措辞在面试里很加分。

Q8：ArkTS 对 TS 做了哪些限制？为什么？

• 限制动态特性：不支持运行时动态增删对象属性、限制 any 与 unknown 的滥用、弱化结构类型的动态性；
• 要求更明确的类型标注：部分场景需要显式类型；
• 目的：让编译器能在编译期完成更多检查与优化，从而提升运行时性能、减少运行时类型判断，同时降低移动端上的不可预期行为。

Q9：struct 和 class 在 ArkUI 里怎么用？
自定义组件用 @Component 装饰的 struct；普通业务逻辑、数据模型用 class。struct 用于描述 UI 结构，不能随意当成普通对象使用，这是新手常犯的错。

四、状态与通信：进阶考点

Q10：组件间通信有哪些方式？

• 装饰器传递：@Prop（单向）、@Link（双向）、@Provide/@Consume（跨层级）；
• 应用级状态：AppStorage（应用级）、LocalStorage（页面级）；
• 持久化：PersistentStorage；
• 跨 Ability：通过 Want 传参，或使用公共事件机制。

Q11：@State 的刷新机制是什么？
@State 装饰的变量变化时，驱动依赖它的组件重新渲染。注意其观测能力有边界：嵌套对象的深层属性变化、数组元素内部字段的变化，未必能被感知——需要配合 @Observed/@ObjectLink 等装饰器处理复杂数据结构。这是高频追问点。

Q12：鸿蒙的后台任务与长时任务怎么处理？
系统对后台行为有严格约束。长时间运行的任务需要申请对应的后台任务类型（如数据传输、音频播放、定位），并遵守系统配额；不应试图用隐式手段常驻后台。

五、常见追问与加分点

追问 A：“纯血鸿蒙（HarmonyOS NEXT）和之前有什么区别？”
答：NEXT 版本不再兼容安卓 APK，移除 AOSP 兼容层，应用必须使用鸿蒙原生方式（ArkTS + ArkUI）开发。“能不能直接跑安卓应用”的答案是不能，这是理解当前生态的前提。

追问 B：“怎么看待鸿蒙的分布式能力？”
答：跨设备流转、多端协同是其差异化优势，但需要按设备能力做降级设计——不是所有设备都具备全部能力，调用前需做能力判断。

六、小结

鸿蒙面试的答题主线：AbilityStage → UIAbility 生命周期 → Want 与启动 → 状态装饰器 → ArkTS 静态化特性。把这五块串起来，再准备一个自己做过的功能模块（哪怕是练手项目），基本能覆盖八成考点。

版本方面，请务必说明自己熟悉的 API 版本与 DevEco Studio 版本，并强调SDK、IDE 与目标设备的配套关系——这本身就是专业度的体现。

参考：HarmonyOS 官方开发指南、HarmonyOS 版本概览。API 与模型细节请以华为官方文档为准。