04 Stage 模型、系统能力与数据架构

一、详细知识点

1. UIAbility

UIAbility是带 UI 的应用组件，负责生命周期入口。常见回调包括创建、窗口创建、前台、后台和销毁。

exportdefaultclassEntryAbilityextendsUIAbility{onWindowStageCreate(windowStage:window.WindowStage):void{windowStage.loadContent('pages/Index')}}

2. WindowStage

WindowStage负责窗口管理和页面加载。首页路径错、资源错或页面构建异常，都可能表现为启动失败或白屏。

3. Context

Context是访问资源、文件、系统能力和运行环境的重要入口。工程化开发要明确 Context 生命周期，不要把短生命周期对象长期持有。

4. 页面导航

简单 demo 可用页面状态切换；生产项目应使用官方推荐导航能力组织页面栈、参数和返回行为。无论哪种方式，都要处理参数缺失和数据不存在。

5. 权限与系统能力

调用网络、位置、媒体、通知等能力时，要先声明权限，再按场景申请或检查。用户拒绝权限是正常路径，必须给替代方案。

6. 数据架构

工程要求：

• Page 只做展示和交互。
• Service 负责业务编排。
• Store 负责本地状态和持久化。
• Remote API 负责网络请求。
• Model 做边界转换，避免脏数据进入 UI。

二、本章 demo

Demo 1：生命周期日志

EntryAbility.ets中记录生命周期：

onForeground():void{hilog.info(0x0000,'HarmonyNews','onForeground')}onBackground():void{hilog.info(0x0000,'HarmonyNews','onBackground')}

Demo 2：收藏状态封装

FavoriteStore.ets：

statictoggle(articleId:string):void{if(FavoriteStore.favoriteIds.has(articleId)){FavoriteStore.favoriteIds.delete(articleId)}else{FavoriteStore.favoriteIds.add(articleId)}}

Demo 3：页面只调用服务

Index.ets不直接维护收藏集合，而是调用FavoriteStore.toggle()和NewsService.markFavorites()，保持页面薄。

三、面试题与详细答案

1.UIAbility和页面是什么关系？

UIAbility是应用组件入口，负责生命周期和窗口创建；页面是 ArkUI 渲染内容。UIAbility通过WindowStage.loadContent()加载页面。页面不应该承担应用生命周期管理职责。

2. 为什么不能在生命周期里做重任务？

生命周期回调影响启动和前后台切换，如果做长时间同步任务会造成首屏慢、卡顿甚至 ANR 风险。重任务应拆到异步流程，首屏只做必要初始化。

3. 权限拒绝时应该怎么处理？

权限拒绝是用户选择，不是程序异常。应用应解释原因、提供降级能力、允许稍后再开启，而不是直接崩溃或强制退出。

4. Repository / Service 分层解决什么问题？

它把页面和数据源解耦。页面不关心数据来自网络、缓存还是 mock；测试时可以替换 Service；接口变更时集中修改转换逻辑。这是从 demo 走向生产工程的关键。

四、五倍扩展知识点矩阵

1. Stage 模型对象关系

2. 生命周期实践

生产实践理解：生命周期不是业务万能入口。它是应用运行状态变化的边界，业务初始化要分级：首屏必要、首屏后、用户触发、后台可延迟。

3. 权限治理

4. 数据架构扩展

分层解释：

• Page 只关心展示状态。
• View State 组合 loading、error、data。
• Service 表达业务动作，如刷新、收藏、保存设置。
• Repository 屏蔽远程和本地数据源。
• Mapper 处理 DTO 到领域模型。
• Error Mapping 把底层错误变成用户可理解状态。

5. 缓存策略

五、系统能力 demo 扩展任务

扩展示例：Repository 接口

exportinterfaceNewsRepository{queryArticles():Promise<NewsArticle[]>queryArticleById(id:string):Promise<NewsArticle|undefined>toggleFavorite(id:string):Promise<void>}

接口化后，页面可以依赖抽象，测试时使用 FakeRepository，生产时使用 RemoteRepository + LocalStore。

六、数据流检查

七、扩展面试题

5. Stage 模型里为什么要区分 Ability 生命周期和页面生命周期？

Ability 生命周期描述应用组件的运行状态，页面生命周期描述 UI 组件的出现和消失。二者粒度不同。把页面数据加载都塞进 Ability 会让入口过重；把应用级资源管理放进页面又会导致重复初始化。

6. 权限最小化如何落地？

先从业务需求反推权限，能不用就不用，能低敏就不用高敏。配置文件只声明真实需要的权限，运行时在用户触发相关功能时申请，并提供拒绝后的降级路径。上线前检查权限说明和实际使用是否一致。

7. Repository 和 Store 的区别是什么？

Repository 负责统一数据访问，可以组合远程、本地和转换逻辑；Store 更偏本地状态或持久化状态管理。Repository 可以使用 Store，但页面最好通过 Service 或 Repository 获取业务数据。

8. 如何设计弱网体验？

首屏尽量展示缓存；请求要有超时；失败要有重试；关键操作要有明确状态；不要无限转圈。对于写操作，要说明是否成功、是否可重试、是否会重复提交。

9. Context 为什么不能随意长期持有？

Context 和运行环境、Ability 生命周期有关。随意长期持有可能造成生命周期错乱或资源无法释放。需要系统能力时应在合适作用域获取，并避免把短生命周期对象保存到全局单例中。

10. 如何从 demo 架构演进到生产架构？

先把 mock 数据移入 Service，再抽 Repository，再增加 LocalStore 和 RemoteAPI，再统一错误处理和日志，最后补测试和发布检查。每一步都保持页面调用方式稳定，避免 UI 随数据源变化大改。

八、Stage 与数据架构详解库

1. 生命周期是资源管理边界

前后台切换、窗口创建和销毁决定了资源何时创建、暂停、恢复和释放。网络轮询、动画、定位、监听器等都要和生命周期绑定，否则会带来耗电、内存和状态问题。

2. 首屏初始化要分级

首屏必要任务包括加载首页、读取最低限度设置、准备关键 UI。非必要任务如预加载推荐、同步历史、上传日志应延后。启动阶段越重，用户感知越差。

3. Want 参数必须校验

跨 Ability 或页面传参时，参数可能缺失、类型不对或来自旧版本。详情页根据 id 加载数据时，必须处理 id 为空和文章不存在。

4. 权限申请要绑定用户动作

应用启动就申请大量权限体验很差。更好的方式是在用户触发相关功能时说明原因并申请。拒绝后提供降级路径。

5. Repository 是数据源防火墙

页面不应该知道数据来自 mock、HTTP、缓存还是数据库。Repository 隐藏这些细节，让页面只处理业务状态。

6. 本地缓存要有失效策略

缓存不是永久保存。新闻列表可以设置时间失效，用户设置可以长期保存，登录态和敏感信息要按安全策略管理。

7. 弱网不是异常边角

移动应用大量场景都可能弱网。架构要内置超时、重试、缓存、错误提示和重复提交保护。

8. 日志要串联链路

一次用户操作可能经过 Page、Service、Repository、Remote 和 Store。日志如果没有 traceId 或上下文，很难定位问题发生在哪一层。

9. 多设备能力要先抽象

不同设备能力不同，页面不应直接假设所有系统能力都可用。要有能力检测、降级和设备差异策略。

10. 架构演进要小步保持可运行

不要一次性把 demo 重构成复杂架构。每次只引入一个边界：先 Service，再 Store，再 Repository，再 Remote。每一步都保持项目可运行。

九、Stage 与系统能力场景库

十、扩展面试题库

11. 为什么首屏不应该等待所有接口？

用户首先需要看到可交互界面。等待所有接口会放大最慢接口的影响。应优先加载首屏必要数据，非关键数据延后或并发加载。

12. 如何设计缓存失效？

根据数据性质决定。新闻列表可以短时间缓存并允许手动刷新；用户设置长期有效；敏感数据要有安全和清理策略。缓存要记录版本和时间，避免旧结构解析失败。

13. 弱网下如何避免重复提交？

按钮点击后进入提交中状态，禁用重复点击；请求带业务幂等标识；失败时明确是否可重试；重试不能造成重复业务结果。

14. 为什么权限弹窗要延后到具体场景？

用户在具体场景下更容易理解权限用途。启动即申请会让用户困惑，也可能导致拒绝率上升。延后申请还能减少不必要权限。

15. 如何判断架构是否过度设计？

如果抽象没有减少重复、没有隔离变化、没有提升测试性，只是增加文件和跳转，就是过度设计。架构应服务当前复杂度，并允许未来平滑扩展。

十一、系统能力知识体系补全

十二、数据架构分层方案

职责说明：

• ViewState描述页面状态，不直接描述网络细节。
• UseCase表达业务动作，如刷新新闻、收藏文章、保存设置。
• Repository屏蔽数据源，页面不关心远程还是本地。
• RemoteDataSource只负责请求和响应 DTO。
• LocalDataSource负责 Preferences、文件或数据库。
• Mapper把 DTO 转成领域模型。
• ErrorMapper把系统错误转成业务错误。

十三、持久化选型

十四、并发与后台任务

并发设计要先保证正确性，再考虑速度。所有后台结果回到 UI 前都要校验页面是否仍需要该结果。

十五、架构设计文档模板

1. 业务目标 2. 页面范围 3. 模块划分 4. 数据模型 5. 状态流 6. 网络和缓存策略 7. 权限和系统能力 8. 错误处理 9. 性能风险 10. 安全和隐私 11. 测试方案 12. 发布和回滚

项目达到一定规模后，每个核心功能都应有轻量设计文档。没有设计文档，后续维护只能靠读代码猜意图。

十六、架构练习套件

十七、补充面试题

16. 如何给鸿蒙应用设计数据层？

先定义领域模型，再定义 Repository 接口，然后实现 RemoteDataSource、LocalDataSource 和 Mapper。页面只依赖业务服务，不直接接触 HTTP、Preferences 或数据库。

17. Preferences 和数据库如何选择？

Preferences 适合少量 key-value 数据，如设置和轻量状态；数据库适合结构化、可查询、可分页的数据，如阅读历史、离线列表。选择时看数据量、查询方式、更新频率和迁移成本。

18. 系统能力为什么要统一封装？

权限、通知、媒体、文件等系统能力都有失败路径和设备差异。统一封装可以集中处理权限、日志、错误映射和降级，避免页面到处散落系统 API。

19. 如何设计模块依赖方向？

业务 feature 可以依赖 common-ui、common-model、common-data，但 common 不能反向依赖 feature。数据层不能依赖 UI。依赖方向越单向，项目越容易扩展和测试。

20. 架构设计如何避免空谈？

每个架构结论都要落到文件结构、接口定义、数据流、错误处理和测试方式。只画图不落代码约束，就不能指导开发。