HarmonyOS实战《疆域纪行》第10篇｜发布交付：构建配置、截图文案、隐私说明和上架前检查

这一篇收尾，不再只看代码，而是看一个 App 从 Demo 走向交付还缺什么。构建配置、截图、商店文案、隐私说明、免责声明、上架前检查，这些东西不写代码，但决定项目能不能像产品一样交出去。

项目落点：

• 构建配置：build-profile.json5、entry/build-profile.json5
• 模块配置：entry/src/main/module.json5
• 发布截图：doc/release/screenshots
• 商店文案：doc/release/store-listing-draft.md
• 隐私政策：doc/release/privacy-policy.md
• 预发布检查：doc/release/prelaunch-checklist.md

读完这一篇，你可以复用一套 HarmonyOS 单机 App 的交付清单：代码、资源、文案、隐私、免责声明和测试路径一起闭环。

从 Demo 到可发布，还差什么

一个 App 能跑起来，不等于能发布。

《疆域纪行》作为离线旅行攻略 App，除了页面和功能，还准备了：

很多个人项目卡在“代码写完”这一步，其实离可交付还差文案、截图、隐私和验证路径。

• 应用介绍文档
• 商店文案草稿
• 隐私政策
• 预发布检查清单
• 应用截图
• release 包输出
• 签名构建配置

这篇不展开讲具体平台提交流程，而是从工程角度复盘：一个 HarmonyOS 单机 App 要走向可发布，需要补齐哪些环节。

构建配置：先确认 Stage 模型和 SDK

entry/build-profile.json5中可以看到：

{ "apiType": "stageMode", "buildOption": { "resOptions": { "copyCodeResource": { "enable": false } } } }

这说明项目使用 Stage 模型。对于当前 HarmonyOS 应用开发，Stage 模型是主流选择，Ability、页面加载、上下文获取都围绕它展开。

根目录build-profile.json5中还有产品配置：

"products": [ { "name": "default", "targetSdkVersion": "6.1.0(23)", "compatibleSdkVersion": "6.0.2(22)", "runtimeOS": "HarmonyOS" } ]

写技术文章时可以说明目标 SDK 和兼容 SDK，但不要把本机证书路径、证书密码、profile 路径等敏感信息贴出去。

发布文章里如果要展示签名配置，建议写成：

"signingConfigs": [ { "name": "default", "type": "HarmonyOS", "material": { "storeFile": "<your-store-file>", "keyAlias": "<your-key-alias>", "profile": "<your-profile>" } } ]

技术分享要讲方法，不要泄露真实凭据。

模块配置：支持设备要和体验匹配

module.json5中声明：

"deviceTypes": [ "phone", "tablet", "2in1" ]

这意味着商店材料和测试也应该覆盖这些设备形态。

如果只在手机模拟器上看过，就不要在文章或商店文案里过度强调平板深度适配。比较稳妥的表达是：

当前版本以手机竖屏体验为主，布局已预留 tablet 和 2in1 设备支持，后续会继续增强大屏分栏体验。

技术复盘中诚实描述边界，比夸大能力更专业。

发布材料：截图和文案都要准备

项目已经有发布截图：

doc/release/screenshots/ ├── 01-home.jpeg ├── 02-explore.jpeg ├── 03-detail.jpeg ├── 04-route.jpeg └── 05-mine.jpeg

这五张图覆盖了核心路径：

• 首页推荐
• 探索筛选
• 详情页
• 路线规划
• 我的 / 设置

这也是写 CSDN 技术文章时很好的配图顺序。技术文章不是只能贴代码，适当放页面截图能帮助读者理解代码背后的产品目标。

商店文案草稿在：

doc/release/store-listing-draft.md

隐私政策在：

doc/release/privacy-policy.md

预发布检查在：

doc/release/prelaunch-checklist.md

这些文档说明项目已经从“开发完成”往“交付完成”推进了。

单机离线 App 的隐私表达

《疆域纪行》的特点是：

• 无需登录
• 无需联网即可浏览核心内容
• 收藏、搜索历史、行程仅保存在本机

这种 App 的隐私风险相对低，但仍然应该说明清楚：

• 是否采集个人信息。
• 是否上传收藏或搜索历史。
• 是否请求定位、相机、相册等权限。
• 本地数据如何保存。
• 卸载 App 后本地数据会怎样。

技术文章里可以强调这一点：local-first 不只是技术架构，也是一种隐私友好的产品设计。

内容准确性和免责声明

旅行攻略类 App 最容易踩的坑不是代码，而是内容变化。

项目里多处加入了类似说明：

本应用内容为离线旅行参考信息，景区开放时间、门票、交通、餐厅营业状态等信息可能变化，请以当地官方公告和实际情况为准。

这非常必要。因为第一版内容是离线内置，不能保证实时更新。尤其是：

• 景区开放时间
• 门票价格
• 路况
• 餐厅营业状态
• 边境线路规定

都可能变化。

对开发者来说，免责声明不是“推卸责任”，而是明确产品边界。

上架前的功能检查

建议至少覆盖这些路径：

• 冷启动进入首页。
• 首页点击景点进入详情。
• 详情页收藏，再返回收藏页查看。
• 详情页加入行程，在路线页查看摘要。
• 探索页搜索“喀什”“赛里木湖”“大盘鸡”。
• 探索页切换景点、美食、路线、城市。
• 筛选无结果时显示空状态。
• 关闭并重启 App，确认收藏和搜索历史仍在。
• 系统返回键从详情页返回主页面。
• 所有底部按钮不遮挡内容。

这些测试不依赖后端，很适合在发布前手动跑一轮。

工程复盘：这个项目最值得借鉴的点

第一，数据建模清楚。

AtlasItem、RouteItem、CityItem、LocalAppState把内容和用户状态分开，后续扩展有基础。

第二，页面主流程简单。

activeTab控制主 Tab，detailId/detailKind控制详情页，没有过早引入复杂路由。

第三，本地持久化封装在服务层。

页面不直接写 Preferences key，而是通过LocalAppStore.ets读写状态。

第四，视觉完成度较高。

大图、渐变、卡片、时间轴、空状态、启动页都已经具备产品感。

第五，发布意识比较完整。

截图、商店文案、隐私政策、免责声明都已经准备。

还可以继续优化的方向

如果继续迭代，我会优先做这些：

• 把硬编码颜色抽成主题常量。
• 把大文件Index.ets拆成components和独立页面。
• 为路线行程设计更完整的数据结构。
• 增加内容版本号和迁移逻辑。
• 支持平板左右分栏布局。
• 搜索支持标签和拼音。
• 本地数据支持导出备份。
• 增加更多真实内容和图片来源说明。

这不是因为当前版本不好，而是从 MVP 到正式产品的自然演进。

优化顺序也有讲究：先拆主题常量和组件，让维护成本降下来；再增强搜索、路线编辑和导出，让功能变强；最后再考虑联网更新和离线包，因为那会引入内容版本、同步和审核边界。按这个顺序走，项目不会因为一次性升级过多而失控。

验证清单

常见问题和处理

本系列总结

10 篇文章从一个真实 HarmonyOS 离线 App 出发，完整覆盖了：

• 工程入口和 Stage 模型
• ArkTS 数据建模
• ArkUI 首页和底部导航
• 本地搜索与筛选
• Preferences 持久化
• 沉浸式详情页
• 路线时间轴
• 图片资源与启动体验
• 适配和稳定性
• 发布准备和项目复盘

如果你正在学习 HarmonyOS，不建议只停留在零散 API。选择一个真实小产品，把数据、页面、状态、资源、发布都走一遍，成长会快很多。

《疆域纪行》这个项目的价值就在这里：它不是最复杂的 App，但它把一个内容型 HarmonyOS 应用从 0 到 1 的关键链路都串起来了。