揣摩规矩，考究方圆：把握鸿蒙设计、交互与生态规范

序言

如果你是一位独立开发者，面对日益成型的 HarmonyOS NEXT 生态，或许已经开始着手将现有的应用移植过去。如今，写出适应新平台的代码可以借助 AI 快速完成；但真正把应用打包、送审并端到用户面前，也就是完成整个上架流程，依然需要面对一套全新的规则。翻看官方文档和审核条款时，你或许会觉得无从下手。

本系列教程正是为你准备的实战手册。我们试图以同行的视角，把那些散落在官方文档各处的硬性规范、容易混淆的签名机制以及繁杂的资质要求，整理成一条连续可执行的动线。

为了让你少走弯路，我们会先从鸿蒙的设计与生态规范讲起。了解平台对图标、启动页以及隐私交互的红线，能帮你从源头避开审核中的高频驳回点。在这之后，我们将转入工程环节，一起跑通签名与打包体系，确保你能顺利产出通过预检的正式发布包。

应用上架同样离不开合规支撑。国内特有的实名认证、软件著作权与 APP 备案流程需要提前谋划。我们会帮你理清这些工序的前置条件和依赖关系，倒推出合理的时间安排。等到万事俱备，再一起走完提交审核、版本发布以及应用上线后的监控与运营流程。

在常规的上架步骤之外，我们还会探讨如何在鸿蒙开发中融入最新的 AI 工作流。不仅是辅助生成代码，甚至在起草隐私声明和备案素材等非代码环节，AI 也能替你省下不少力气。

如果你已经准备好让自己的作品进入鸿蒙生态，我们这就开始吧。

每个平台都有自己的应用设计指南。但对于鸿蒙来说，设计指南不仅是「建议」，更是审核规范的一部分。在官方的《应用审核 Checklist》中，「UX 设计」被列为明确的应检查事项，如存在影响用户体验的情况，将会直接影响审核结果。

那么，如何做到合规呢？最重要的官方资源是《设计指南》，特别是其中的《应用 UX 体验标准》部分。这里，官方从界面布局、动效、系统特性适配等角度，设定了一系列可量化的标准，并援引了相关的开发文档。本文建议开发者朋友在着手设计应用之前，先将这份文档大致浏览一遍，然后在开发初步完成之后，再对照检查。这样，不仅能保证应用充分符合「鸿蒙标准」，也能通过审核更加顺利。

当然，官方文档虽然详尽权威，但读起来确实可能有点枯燥和抽象。下面，我们将重点梳理设计标准中的一些特殊和易错部分，帮助开发者朋友建立一个系统、直观的印象。

首先值得指出，虽然《应用 UX 体验标准》有几十上百条规则，但真正要专门花时间做的事不多。因为相当多数量的条目，只要用的是 ArkUI 标准组件，直接就是符合标准的。因此，开发者朋友在设计和开发时，应当尽量优先选择使用标准组件，不仅节省精力、效果优秀，而且标准合规。

相比之下，需要专门花功夫去准备的，主要是图标、启动页、深色模式等界面元素或状态涉及的资源。因此下面，我们就先从这些部分的要求讲起。

值得关注的设计规范

必做的素材准备：图标与启动页

如果你开发过其他平台的应用，可能习惯了图标就是一张 PNG、启动页可以放半秒广告。然而，这些「方便」之处在鸿蒙这边并不适用。

首先说图标。根据鸿蒙的设计规范，应用图标必须分前景、背景两层，分别交付 1024 × 1024 分辨率的 PNG 或 SVG，放在 resources/base/media/ 目录，通过 app.json5 的 icon 字段引用。因为只有这样，系统才能给图标套用不同形状和动效，例如桌面圆角矩形、最近任务圆形、悬浮窗带缩放动画等。

正确的图片分层

除此之外，一些特别易错的技术细节是：

背景图必须用实色填满，不允许含透明像素，圆角裁切或带透明边都违规；
不要自行把资源裁成圆角（圆角由系统蒙版生成）；
不要为了「让图标看起来居中一点」就手动给资源加内间距，因为系统蒙版会再加一层 padding，叠加之后图标会缩成一小块；
单色或纯文字图标要有充足的对比度（分别在浅色和深色蒙版下检查）。

至于图标的内容，要注意鸿蒙的设计规则也不允许在图标里叠加促销、节日或版本号角标。像「限时免费」「春节版」「v2.0」这些字样会被判定为误导性元素，审核中会直接打回。与系统预置应用视觉相似度过高也是违规的，「设置」「文件管理」「图库」这种通用类图标尤其要避开。

启动页是另一个看着简单实则容易反复返工的环节。

最关键的显示时长方面，设计指南建议最佳时长 0.3–0.8 秒，而 UX 标准划的硬上限分两档：有内容填充 3 秒、空白 300 毫秒。这看起来可能颇短，但是根据鸿蒙设计规范，启动页只能放品牌相关元素，例如应用图标、品牌色背景，以及必要的插画或图形；广告、促销、第三方品牌这些其他平台常见的启动页「妙用」是禁止出现的。因此，最长 3 秒的时间已经足够了。

一般建议开屏的沉浸式背景色为应用定义的主题色，且与 icon 背板色彩呼应。

相反，如果你的应用无法在 3 秒之内完成启动，可能是因为把网络请求、首页数据预加载、A/B 实验初始化都塞在了启动页阶段，应当考虑把这些逻辑挪到首屏之后异步执行，启动页本身只负责品牌展示。

其他值得专门检查的细节

首先是底部导航条适配。它的关键要求可以总结为两点：

应用内的底部固定控件、输入键盘、底部悬浮按钮都要向上抬高 28 vp，避免与系统导航条互相遮挡；
导航条要做沉浸式背景效果，底部背景色要与应用内底部背景色融合，不能出现明显的颜色切割。

在官方的上架检测 FAQ 中，导航条相关的常见驳回问题有五种（底部固定控件、输入键盘、底部悬浮控件、可滚动内容、半模态可滚动内容被遮挡），其本质都是这两件事没做好的不同表现。

其实，如果你用的 UI 框架是 ArkUI 的 Tabs 组件加系统安全区 API（expandSafeArea、getWindowAvoidArea），这一条几乎是自动满足的。但如果用了自定义的底部 Tab 容器、没接安全区 API，或者用了 Flutter、React Native 这类跨端框架，可能就要专门做一次检查和适配。

其次是点击热区，即用户点击可使交互元素或控件有响应的范围。对此，规范的推荐值是 48 × 48 vp，强制的下限值则按设备分档：

手机、平板、折叠屏：40 × 40 vp；
电脑键鼠场景：短边 ≥ 5 mm；
电脑触屏场景：短边 ≥ 7 mm；
智慧屏遥控器光标：≥ 2.5 cm；
智能穿戴：40 × 40 vp。

要注意的是，热区不等于控件本身的视觉尺寸：控件本身可以更小，只要能响应上述尺寸范围的点击即可。如上架检测 FAQ 所指出，像密码框右侧的「显示密码」眼睛图标、勾选用户协议的复选框、列表里的搜索按钮，它们视觉上小一点是可以的，但要把不可见的响应区放大到下限之上。

接下来要检查的是状态栏和挖孔区适配，两者都关系到应用的「一体化」和「沉浸」程度。

就状态栏而言，要注意该区域必须具有「沉浸式」效果，即采用导航栏的背景底色，而不能被切出来当独立色块。此外，文字颜色根据背景明暗自动选黑或白，同时背景左右半区颜色差不能过大（官方指定的对比度下限为 1.9）。深色页面叠了深色状态栏导致图标看不见。浅色页面叠了白色、文字消失在白底，都是常见的驳回情形。

挖孔区的设计重点则在于「合理避让」。一方面，工具栏、标题栏、搜索框横幅通知这一类重要元素，如果会被前置摄像头的挖孔遮挡，必须做局部避让；另一方面，与挖孔区无遮挡的元素、悬浮类控件、可滚动内容则不需要避让。如果为了避让而出现大面积不对称的留白，同样可能会被驳回。

最后是深色模式。这方面的主要易错点是适配不全面（例如部分文字、图标未适配）和对比度不足（正文文字与背景对比度须大于 4.5:1）。

应用内图标未适配深色模式案例

特别值得关注的是应用内嵌了 H5 页面时，不能忽略嵌入页面的深色模式适配：一般来说，设置 WebDarkMode.On，或设置 WebDarkMode.Auto 并启用系统深色模式时，Web 将进入深色模式。在深色模式下，Web 会应用媒体查询 @media(prefers-color-scheme: dark) 中定义的深色样式。如果网页未定义深色样式，则保持原有样式。

（虽然 ArkWeb 框架支持「强制深色模式」，即使用 Chromium 色值转换算法自动调整元素颜色样式，但不同网页的布局和样式写法各异，算法无法确保所有转换均符合预期。因此，我们建议开发者朋友始终自定义深色样式。）

此外，Web 组件发生旋转或大小改变等事件时，Web 网页尺寸改变，变化过程中可能会漏出 Web 组件的背景色。因此，深色模式下，建议将 Web 组件背景色置为黑色，与网页背景保持一致，以提升用户体验。

使用官方组件即可自动满足的规定

除了上面这些需要专门检查或准备的事项之外，《应用 UX 体验标准》里还有相当大一批「必须」条目，只要你用的是 ArkUI 标准组件加系统默认值，就是自动合规的。如果你的工程是纯 ArkTS 或 ArkUI 编写的，这些条目了解一下即可，出现问题再排查不迟；如果涉及跨端框架混用，则可能需要特别关注。

转场动效：相邻界面切换或较大元素进出场必须有转场动效（不可以是单帧切换），时长按屏幕尺寸分档 200/250/300 毫秒，曲线优先弹簧，不同类型的转场（同级、搜索、新建、编辑、共享元素）要对应不同的运动方式。只要用官方的 Navigation 组件走系统默认转场，一般即可满足。

字体大小：下限按设备分档，手机系 8 vp、电脑 10 vp、智慧屏 14 vp、智能穿戴 10 vp。系统主题的默认字号都在这个区间之上。

手势时长：长按 500 毫秒（可调范围 400–650）、双击间隔 70–400 毫秒，LongPressGesture 和 TapGesture 的默认值都满足。

滑动反馈：要求跟手、过界、离手减速三种反馈，ArkUI 的 List、Scroll、Swiper 默认实现即可满足。

折叠屏与大屏的额外要求

通用标准之外，鸿蒙还有《折叠屏应用 UX 体验标准》和《大屏应用 UX 体验标准》两份专门的规范，只对相应形态的设备生效。

其中，如果应用属于六类指定场景（长视频、短视频、直播、通话、会议、拍摄），那么折叠屏的悬停适配是必做的；其他类型的应用，把开合连续性做好就行。同理，如果面向平板和 PC 发版，必须把大屏标准也走一遍；如果暂时只有手机版计划，可以暂缓适配。

折叠屏适配的主要注意点包括：

开合连续性，是指当设备在折叠和展开状态切换时，应用要能保留当前页面、滚动位置、输入框内容、图片清晰度、视频播放进度等状态。例如，ListView 切换后滚动归零、视频从头开始播，就属于不满足开合连续性的情况。
开合过渡动画。这是一个推荐等级的要求，系统会自动做基础的窗口尺寸响应，一般不用自己覆写，以防与系统动画发生冲突。
悬停适配和折痕避让。这两项要求只对前面提到的六类场景是强制的。在这些场景下，悬停态要把屏幕拆成上下两个区域：上半屏放视频画面、远端画面等信息，下半屏放控件、键盘、操作菜单；上半屏内容由折痕向上避让 16 vp（约 3 mm），下半屏由折痕向下避让 40 vp（约 7 mm）。

大屏适配的主要注意点则包括：

响应式布局。应用至少要能在窄屏（手机）、中屏（折叠展开或平板竖屏）、宽屏（平板横屏或 PC）三档之间切换。对此，常用实现是 ArkUI 的 GridRow + GridCol，配合 BreakpointSystem 监听断点变化。
多窗协同。应用要能进入分屏、悬浮窗模式，并支持窗口比例无极调节。要满足这点，特别注意不能在代码里硬编码「窗口宽度等于屏幕宽度」的假设，否则分屏时会直接错位。
键鼠操作。包括鼠标光标的 hover 反馈、框选/连选/点选、全键盘焦点导航等。

不可忽略的生态规范

如果说前面所说的视觉层面规则关心的是「你的应用怎么呈现」，那么接下来要说的规则就是「你的应用怎么对待用户」，包括隐私合规、鸿蒙生态整合等。这些规则不像设计标准那样容易量化，但只要根据官方文档做好相应的步骤，就能顺利通过审核。

首启弹窗和权限请求中的隐私保护细节

鸿蒙的隐私保护原则对齐中国的《个人信息保护法》，其原则可以归纳为三条：

透明。采集了什么数据、用来做什么、提供给谁，都要在隐私政策里写清楚；除应用内的隐私政策之外，还要维护「已收集个人信息清单」和「向第三方共享清单」这套「双清单」（第 3 章会详细说明）。
最小化。只收必要的数据，能本地处理的不上云，能用模糊数据的不用精确数据。
可控。用户必须能拒绝，「不同意就不能用」「默认勾选」属于强制授权，是审核指南明确禁止的。

这些原则落到审核标准上，可以拿首启的隐私声明弹窗当例子。它：

首次启动时必须出现，且隐私政策有重大变更时必须重新征得同意（透明原则）；
必须有「不同意」选项，且选了「不同意」之后，应用要么以访客模式或受限功能继续运行，要么礼貌退出；不能反复弹，也不能强行退出后再弹出「请同意以继续」之类的提示（最小化和可控原则）；
弹窗里指向的隐私政策和用户协议要能完整打开，并且这两份文档要同时上传到 AGC 后台供审核员检索（透明原则）。

再以权限申请为例，由于透明原则，声明权限时必须填理由（reason 字段）。这条文案会原样展示在弹窗里，也是审核员重点检查的对象。要注意的是，「为了功能正常使用」「为了更好的体验」之类的空话是不符合要求的；正确的写法是把场景、动作、用途都讲清楚，比如「为了在你拍照分享时调用相机拍摄食物图片」「为了在你打开地图时定位你所在城市的天气」。一个简单的自查思路是：如果一句话连为什么要这个权限都讲不清楚，那这个权限大概率就是没必要的。

而根据最小化和可控原则，业务功能真正用到的那一刻才弹窗，不要在 EntryAbility.onCreate 里一次性把所有敏感权限请求完。此外，用户拒绝某项权限只能影响对应功能，其他无关功能要照常能用。

例如，开发一个「扫一扫」功能，相机权限应当在用户点「扫码」按钮的回调里申请，而不是首次启动时一股脑全要。如果用户拒绝，也不能影响相机扫码之外其他功能的正常使用，例如应当允许用户从相册照片中识别扫码。

随着用户隐私意识不断提高，只有在功能相关的上下文里请求权限时，用户才更容易理解「为什么」，并且接受请求。如果冷启动一进来就用权限弹窗轮番轰炸，多半会全被拒，反而影响使用体验和用户印象。

此外，由于鸿蒙的完善隐私框架，许多权限申请其实并不是必要的。例如，鸿蒙提供了一组 Picker 控件，可以在不申请高危权限的前提下让用户选取本地资源：照片用 PhotoAccessHelper、文件用 @ohos.file.picker、联系人用 contact.selectContacts。这些 Picker 的设计思路是「用户选什么，应用拿什么」，授权颗粒度落到「这一张」「这一个」，而不是「整本相册」「整个通讯录」。除非应用确实在做相册管理、扫描批处理这类需要持续访问的场景，否则 Picker 是更稳妥的选择。

最后还有两件容易被忽视的隐私相关设计细节：

账号注销通道必须真实有效，且 15 个工作日内完成处理。「联系客服注销」不算通道，必须在应用内有清晰可达的入口（一般可以放在类似「我的」>「设置」>「账号与安全」的路径下），注销后服务器侧的数据清理也要落实，不能只做「假删」。
对面向未成年人或可能被未成年人使用的应用，要做防沉迷设计、家长控制，并限制广告类型；收集未成年人数据前还要征得监护人同意。社交、内容、游戏类应用要特别注意。（具体的材料和后台配置，第 3 章会再展开。）

融入生态：华为账号与 IAP 支付规范

隐私之外，鸿蒙生态还有两个比较独特的整合点需要开发者朋友留意：用户怎么登录，以及怎么在应用里付费。这两件事可自定义的空间都比一般想象的要小，而且最好在写代码之前就定下来。因为它们牵涉到登录页排版和支付流程的整体设计，如果做到一半才发现要改，往往比调整界面细节还麻烦。

首先是华为账号登录。按官方要求，同时满足以下三点时，必须支持华为登录：

应用接入了第三方账号登录（例如微信、QQ、微博、Apple、Google 等）；
应用和那个第三方账号服务商不属于同一家企业或关联企业；
登录场景不涉及核验公民真实身份信息（身份证、护照、港澳台居民证件、军人证件等）。

例如，你的应用支持微信登录、不需要实名核验，由于显然不属于腾讯的关联企业，因此必须再加一个华为账号登录。并且，这个华为账号登录必须是登录页的首个选项，不能折叠在「更多登录方式」里，也不能放在屏幕外要滑动才能看到。

对于这项要求，许多独立开发者第一反应是「又多了一道接入麻烦」。但推荐首选的「华为账号一键登录」按钮跳过了自定义登录页，直接拉起华为账号的快捷登录浮层，配合「华为账号绑定号码」字样展示用户的匿名手机号，用下来比独立做手机号登录省事得多。

在设计华为登录的界面时，要注意登录按钮的尺寸和颜色都有官方约束：整体高度 28–60 vp、宽度不小于 150 vp，文字字号在 12–30 fp 区间，带标志的样式颜色组合只能用华为提供的方案。

另一个涉及生态整合的问题是支付。在鸿蒙应用中，只要卖的是数字商品（虚拟商品），包括会员、订阅、虚拟道具、付费下载、解锁功能，就必须走 IAP Kit，不能独立调起微信支付、支付宝等。常见的数字商品类型包括：

商品类型	用户权益	典型场景
可消耗	一次性，可重复购买	游戏货币、抽卡道具
非消耗	永久	解锁高级功能、买断版本
自动续期订阅	周期续费	包月会员、视频订阅
非续期订阅	一个周期	单次月卡、季度卡

实物商品（外卖、电商、票务）不在此列，可以继续用三方支付。

在设计商品购买页时，应当注意以下鸿蒙比其他一些平台更为严格的规定：

不要在购买页展示支付方式。也就是不要出现「华为支付」「鸿蒙支付」「应用内支付」之类的字样，也不要出现支付方式的 Logo。正确的做法是用「购买」「订阅」「立即开通」之类的中性按钮，用户点击后由应用直接拉起 IAP 收银台，由收银台负责后续支付方式的选择。

对于自动续期订阅，要明示扣费金额和周期；要同时提供「单次开通」和「非自动续费」的等价选项，否则会被判为「诱导续费」；退订路径不允许只能联系客服取消，也不允许埋在三级以上的菜单里；续订前 5 日要做扣费提醒。

至于接入流程、商品配置、回调验签等具体操作，会在第 3 章「数字商品服务」一节里详细讲解。

总结

鸿蒙的设计与生态规范看似繁多，但梳理下来，真正要专门花心思的事并不算多：设计上，把图标分层、启动页和深色模式的素材准备到位，再对照检查导航条、点击热区、状态栏这几个容易踩坑的细节；生态上，把首启弹窗和权限请求按隐私三原则做对，该接华为账号登录和 IAP 的按规范接入。其余大量条目，只要老老实实用 ArkUI 标准组件，基本就是自动合规的。

这些规则虽然分散在好几份文档里，但每一条都写得足够具体，配合云测试和上架预检，你完全可以做完一项查一项，并不需要全背下来。

下一章，我们将介绍签名、打包和上架预检的具体流程。