导语
在完成第一阶段的基础环境搭建与网络功能开发后,我们进入了第二阶段的开发工作。本阶段的主要目标是将 my_first_ohos_app 从功能验证 Demo 升级为具备完整架构、多模块协同的 App ------ TechHub(技术驿站)。
本文将总结这一阶段的技术实践,重点介绍 底部导航架构的设计 、页面状态保持的实现方法 以及 模块化工具箱的重构思路,并分享在 OpenHarmony 真机适配过程中的经验。
欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.csdn.net
一、 框架升级
1. 底部导航与页面管理
为了承载"首页"、"资讯"、"工具"、"我的"四大核心模块,我们引入了 BottomNavigationBar 组件。
问题描述:
在初期实现中,切换 body 内容会导致页面重建。例如用户在"资讯"列表滑动浏览到第 10 页后,切换到"首页"再切回,列表会重置到顶部。
解决方案:IndexedStack
我们使用 IndexedStack 管理页面栈。它将所有页面加载并堆叠,通过改变 index 控制显示顶层页面,底层页面保持原样。
dart
// lib/pages/main_page.dart 核心代码
Scaffold(
body: IndexedStack( // 保持页面状态
index: _currentIndex,
children: _pages,
),
bottomNavigationBar: NavigationBar(...),
)
技术分析:
IndexedStack 通过增加内存占用(页面常驻内存)来换取交互流畅度。对于页面数量较少(通常 3-5 个)的应用,这是一种提升体验的有效方案。
2. 目录结构的模块化调整
随着代码量增加,我们将目录结构调整为 Feature-based 模式,明确代码职责:
text
lib/
├── features/ // 功能模块
│ └── tools/ // 工具箱特性
│ ├── manager/ // 管理层:注册与分发
│ └── models/ // 数据层:接口定义
├── pages/ // 页面层:负责整体布局
└── providers/ // 状态层:全局状态管理
二、 实战:模块化工具箱开发
在"工具"模块开发中,我们设计了一套支持扩展的插件化架构。
1. 接口设计
我们定义了 ToolItem 接口,规范了工具的 ID、图标和构建方法。这使得后续新增工具(如"JSON 格式化")时,只需实现该接口并注册,无需修改主界面代码。
2. 多端适配 UI
针对 OpenHarmony 生态中的平板和 PC 设备,我们采用了响应式分栏设计。
- 导航栏 :使用
NavigationRail替代顶部 Tab,适合大屏侧边操作。 - 动画过渡 :引入
AnimatedSwitcher,在工具切换时提供淡入位移动画(响应时间 < 200ms),优化视觉体验。
dart
// 响应式布局示意
Row(
children: [
NavigationRail(...), // 左侧侧边栏
Expanded(child: AnimatedSwitcher(...)) // 右侧内容区
]
)

三、 问题排查与经验
1. 列表渲染性能
在开发"资讯"列表时,加载大量图片出现了轻微卡顿。
排查: 使用性能分析工具发现主线程进行了大量图片解码。
优化: 引入 cached_network_image 并配合 ListView.builder 懒加载机制,仅加载和渲染可视区域图片。
2. OpenHarmony 真机权限
在真机调试中,曾遇到网络请求失败的问题。
分析: 鸿蒙系统权限管理严格,除在 module.json5 中声明 ohos.permission.INTERNET 外,需确保签名配置正确。
经验: 修改权限配置文件后,建议执行 flutter clean 并重新安装应用,确保配置生效。
四、 总结
第二阶段的实践让我们从代码编写进阶到架构设计。我们成功运行了 TechHub 应用,并建立了可维护、可扩展、多端适配的代码规范。
相关资源:
本项目代码已托管至 AtomGit:https://atomgit.com/Betelgeuse76/my_first_ohos_app