第20篇｜底部导航：地图、拍照、相册、保险箱的产品路径

第20篇｜底部导航：地图、拍照、相册、保险箱的产品路径

底部导航看起来只是四个入口，但在一个相机类应用里，它实际定义了产品路径：从「在哪里拍」进入地图，从「马上拍」进入相机，从「拍完看」进入相册，从「私密内容」进入保险箱。导航如果只做成按钮，就会漏掉状态、权限和内容边界。

本篇对应源码仍然是entry/src/main/ets/pages/Index.ets，重点看buildBottomNavigation()、buildNavItem()和buildNavIconMark()。

四个入口不是四个普通按钮

项目里的底部导航是这样组织的：

Row() { this.buildNavItem('地图', 'map') this.buildNavItem('拍照', 'camera') this.buildNavItem('相册', 'gallery') this.buildNavItem('保险箱', 'vault') }

每个入口都走同一个buildNavItem(label, tab)，这样选中态、字体、边框、光效、点击行为可以统一维护。统一并不等于行为完全一样，gallery的点击会走openFullGalleryFromNavigation()，其他入口走switchTab(tab)。这是一个很小但重要的产品判断：相册不是普通页签，它要进入完整浏览路径。

为什么导航层要透明命中

地图页底部覆盖层代码里有一段容易被忽略：

Column({ space: 14 }) { if (this.getMapPhotoDockMemories().length > 0) { this.buildMapPhotoGroupDock() } this.buildBottomNavigation() } .hitTestBehavior(HitTestMode.Transparent)

它的意思是：容器空白区域不吃掉手势，真正的卡片和按钮才响应点击。这样用户在底部附近仍然能拖动地图，不会感觉地图「死掉了一块」。这比单纯调zIndex更可靠，因为问题不在层级，而在命中区域。

选中态为什么要同时改图标、边框和光效

buildNavIconMark()使用资源命名来区分默认态和选中态：

Image(this.isActiveTab(tab) ? $r('app.media.nav_camera_active') : $r('app.media.nav_camera'))

再配合ml_selected_glass、getNavGlowColor(tab)和hdsEffect.HdsEffectBuilder().pointLight(...)，选中态会同时体现在图标、背景、边框和光效上。官方 UIDesignKit 文档提供了hdsEffect和HdsEffectBuilder，项目里用它做导航玻璃层的光照反馈，而不是只把文字变粗。

和侧边导航的关系

buildBottomNavigation()的第一句是：

if (this.shouldUseSideNavigation()) { Blank().width(0).height(0) } else { // 构建底部导航 }

这说明底部导航只服务手机形态。宽度达到平板/2in1 条件后，主入口交给侧边导航。这个判断避免了一个常见问题：大屏上同时出现底部导航和侧边导航，路径重复，空间也浪费。

自测建议

1. 在地图页拖动底图，确认底部透明区域不阻断地图手势。
2. 依次点击地图、拍照、相册、保险箱，确认选中态和页面内容一致。
3. 点击相册入口，确认走完整相册路径，而不是只切普通 Tab。
4. 把窗口宽度调到 600vp 以上，确认底部导航消失、侧边导航出现。
5. 切深色模式，确认ml_nav_glass、ml_selected_glass、文字色和图标仍然可读。

导航行为不是一个 switch 就结束

底部导航的点击分支看起来很短，但背后有清楚的产品语义：

.onClick(() => { if (tab === 'gallery') { this.openFullGalleryFromNavigation(); return; } this.switchTab(tab); })

map、camera、vault是主 Tab 切换，gallery是完整浏览路径。这样设计是因为相册页不仅展示缩略图，还承担大图查看、筛选、回看和返回逻辑。如果相册也只做switchTab('gallery')，用户从首页进入后会丢失“完整浏览”的上下文，后续文章讲相册详情时就会发现入口不一致。

视觉状态的四个来源

一个导航项的选中态由四部分组成，不是单独靠颜色：

官方hdsEffect文档提供的是效果能力，项目里没有把它当成装饰堆叠，而是只在导航容器和选中项上使用。这样做的好处是光效有明确语义：它只强调“你现在在哪个路径里”。

代码验证 1：底部导航只在手机形态出现

buildBottomNavigation()开头直接判断侧边导航：

if (this.shouldUseSideNavigation()) { Blank() .width(0) .height(0) } else { // 构建底部导航 }

这段代码可以用窗口宽度验证。把预览器或真机窗口拖到 600vp 以上，底部导航应该消失；再缩回手机宽度，它应该重新出现。这个判断比在 CSS 或样式里隐藏某个容器更可靠，因为它从构建阶段就不再输出底部导航，避免大屏上出现两个主入口。

代码验证 2：资源成对存在

第 20 篇用到的导航资源必须成对存在，否则选中态会断。可以在项目根目录运行：

Get-ChildItem entry/src/main/resources/base/media -File | Where-Object { $_.Name -like 'nav_*' } | Sort-Object Name

应该能看到nav_map.png和nav_map_active.png、nav_camera.png和nav_camera_active.png、nav_gallery.png和nav_gallery_active.png、nav_vault.png和nav_vault_active.png。这就是官方资源访问文档里“通过资源文件管理媒体资源”的落地方式：代码只写$r('app.media.nav_camera')，真正替换视觉时改资源文件，不改导航逻辑。

可复用检查清单

如果你也在做相机、地图或工具类应用，可以按下面顺序检查底部导航：

1. 先确认每个入口是否代表不同任务，而不是仅仅分页面。
2. 再确认特殊路径是否单独处理，例如本文的相册入口。
3. 然后检查命中区域，容器空白不要吞掉地图或内容手势。
4. 最后检查大屏降级，底部导航和侧边导航不要同时存在。

这套顺序比先画 UI 更稳，因为它先确定“入口要完成什么任务”，再决定“入口长什么样”。

小结

一个高质量导航，不只是能点。它要表达当前所在位置，要把不同业务路径分开，还要在地图这种强交互背景上处理好命中区域。这里的实现把「路径统一」和「行为差异」放在同一层：UI 统一由buildNavItem()承担，特殊路径由点击分支承担，设备差异由shouldUseSideNavigation()承担。

参考依据：

• 华为开发者文档《hdsEffect》：https://developer.huawei.com/consumer/cn/doc/harmonyos-references/ui-design-hdseffect
• 华为开发者文档《资源分类与访问》：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/resource-categories-and-access
• 项目源码：entry/src/main/ets/pages/Index.ets