导语

在完成第一阶段的基础环境搭建与网络功能开发后，我们进入了第二阶段的开发工作。本阶段的主要目标是将 my_first_ohos_app 从功能验证 Demo 升级为具备完整架构、多模块协同的 App —— TechHub（技术驿站）。

本文将总结这一阶段的技术实践，重点介绍 底部导航架构的设计、页面状态保持的实现方法 以及 模块化工具箱的重构思路，并分享在 OpenHarmony 真机适配过程中的经验。

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.net

一、 框架升级

1. 底部导航与页面管理

为了承载“首页”、“资讯”、“工具”、“我的”四大核心模块，我们引入了 BottomNavigationBar 组件。

问题描述：
在初期实现中，切换 body 内容会导致页面重建。例如用户在“资讯”列表滑动浏览到第 10 页后，切换到“首页”再切回，列表会重置到顶部。

解决方案：IndexedStack
我们使用 IndexedStack 管理页面栈。它将所有页面加载并堆叠，通过改变 index 控制显示顶层页面，底层页面保持原样。

// lib/pages/main_page.dart 核心代码
Scaffold(
  body: IndexedStack( // 保持页面状态
    index: _currentIndex,
    children: _pages,
  ),
  bottomNavigationBar: NavigationBar(...),
)

技术分析：
IndexedStack 通过增加内存占用（页面常驻内存）来换取交互流畅度。对于页面数量较少（通常 3-5 个）的应用，这是一种提升体验的有效方案。

2. 目录结构的模块化调整

随着代码量增加，我们将目录结构调整为 Feature-based 模式，明确代码职责：

lib/
├── features/           // 功能模块
│   └── tools/          // 工具箱特性
│       ├── manager/    // 管理层：注册与分发
│       └── models/     // 数据层：接口定义
├── pages/              // 页面层：负责整体布局
└── providers/          // 状态层：全局状态管理

二、 实战：模块化工具箱开发

在“工具”模块开发中，我们设计了一套支持扩展的插件化架构。

1. 接口设计

我们定义了 ToolItem 接口，规范了工具的 ID、图标和构建方法。这使得后续新增工具（如“JSON 格式化”）时，只需实现该接口并注册，无需修改主界面代码。

2. 多端适配 UI

针对 OpenHarmony 生态中的平板和 PC 设备，我们采用了响应式分栏设计。

• 导航栏：使用 NavigationRail 替代顶部 Tab，适合大屏侧边操作。
• 动画过渡：引入 AnimatedSwitcher，在工具切换时提供淡入位移动画（响应时间 < 200ms），优化视觉体验。

// 响应式布局示意
Row(
  children: [
    NavigationRail(...), // 左侧侧边栏
    Expanded(child: AnimatedSwitcher(...)) // 右侧内容区
  ]
)

三、 问题排查与经验

1. 列表渲染性能

在开发“资讯”列表时，加载大量图片出现了轻微卡顿。
排查： 使用性能分析工具发现主线程进行了大量图片解码。
优化： 引入 cached_network_image 并配合 ListView.builder 懒加载机制，仅加载和渲染可视区域图片。

2. OpenHarmony 真机权限

在真机调试中，曾遇到网络请求失败的问题。
分析： 鸿蒙系统权限管理严格，除在 module.json5 中声明 ohos.permission.INTERNET 外，需确保签名配置正确。
经验： 修改权限配置文件后，建议执行 flutter clean 并重新安装应用，确保配置生效。

四、 总结

第二阶段的实践让我们从代码编写进阶到架构设计。我们成功运行了 TechHub 应用，并建立了可维护、可扩展、多端适配的代码规范。

相关资源：

• Flutter NavigationRail 组件文档
• OpenHarmony 权限管理指南

本项目代码已托管至 AtomGit：https://atomgit.com/Betelgeuse76/my_first_ohos_app