聊聊 HarmonyOS 上的应用内通知授权弹窗

做过 C 端 App 的同学应该都踩过类似的坑:消息推送能力明明接好了,后台数据却一直上不去,扒了一圈发现------原来相当一部分用户根本没开通知权限。尤其在求职招聘这类对消息触达极度敏感的场景里,一条面试邀约、一次 HR 回复,如果因为通知没开就被吞了,那体验就有点说不过去了。

所以"什么时候弹、怎么弹、被拒之后怎么办"这件事,看似是个小细节,其实挺值得认真对待。下面按华为开发者文档里给出的"应用内授权通知弹窗"这个例子,顺着它的思路讲一遍。

场景长什么样

文档里把它定位成 求职招聘类应用的高频场景 :用户首次进入应用时,应用通过一个弹窗提示,引导用户开启消息通知授权。

实现本身并不复杂,核心就一个模块------NotificationManager。所有动作都围绕它展开。

整体思路

拆开来看,其实就三件事:

先查一下有没有授权 :用 notificationManager.isNotificationEnabledSync() 判断当前应用是不是已经拿到了通知权限。
没授权就请求一次 :调 notificationManager.requestEnableNotification(context) 拉起系统的通知授权弹窗,让用户当场做选择。
被拒了还有兜底 :如果用户这一次拒绝了,就用 notificationManager.openNotificationSettings(context) 把用户直接带到该应用的通知设置页,做一次"二次请求"。

一次系统弹窗、一次设置页兜底,两步走,基本就把"该争取的都争取到了"。

看代码更直观

文档里给的示例代码其实特别好读,一个 aboutToAppear 钩子里就把主流程串完了:

ts 复制代码

async aboutToAppear() {
  if (!notificationManager.isNotificationEnabledSync()) {
    // 一次授权
    await this.requestPermissions();
    if (this.isDialogShown !== true) {
      // 二次授权
      await this.requestPermissionsOnSetting();
    }
  }
}

async requestPermissions(): Promise<void> {
  try {
    await notificationManager.requestEnableNotification(this.context);
    this.isDialogShown = true;
  } catch (err) {
    // ...
  }
}

async requestPermissionsOnSetting(): Promise<void> {
  try {
    await notificationManager.openNotificationSettings(this.context);
  } catch (err) {
    // ...
  }
}

几个细节值得拎出来讲:

入口放在 aboutToAppear。这是组件将要出现时的生命周期钩子,意味着"一进来就查、一查没权限就请求",对用户来说是最自然的时机。
用 isNotificationEnabledSync() 做前置判断。这是个同步方法,直接拿到布尔值就能走分支,不用 await 一圈。已经有权限的用户,后面两步根本不会触发,避免无谓打扰。
isDialogShown 这个标志位别忽略 。它在 requestPermissions 成功走完之后被置为 true,然后主流程里会再判一次------只有在一次授权没真正弹出(或者没走完)的情况下,才继续去拉设置页。很多同学做兜底容易写成"不管三七二十一,再跳一次设置",那体验就非常糟糕了,用户点完系统弹窗立刻又被踹到设置页,大概率直接退出应用。
两个接口都需要 this.context。这是 UIAbility 的上下文,系统级弹窗和设置页跳转都依赖它,别传错。

一次授权 vs 二次授权,区别在哪

这两步虽然都是"让用户开通知",但背后的机制完全不一样,容易被混为一谈:

步骤	调用接口	行为表现
一次授权	`requestEnableNotification`	拉起系统通知授权弹窗,用户当场点允许/拒绝
二次授权	`openNotificationSettings`	拉起应用自己的通知设置页,用户手动开启

文档里强调的顺序是:先走一次授权,只有在一次没成功的情况下,才走二次。这个顺序不能反------上来就把人甩到设置页,对用户来说完全没有上下文,开什么、为什么开都一头雾水。

实战里几个容易踩的坑

把这段代码看完,结合平时做业务的经验,有几个点挺值得提一句:

别每次冷启动都弹 。示例里用 isDialogShown 挡了一下重复弹窗,如果业务上还想做得更细,可以结合本地存储记一下用户的历史选择,这样即便多次启动也不会反复骚扰。不过文档本身没展开讲这块,照着它的写法起码保证了"同一次生命周期里不重复弹"。
被拒之后别追着问。二次授权的入口是设置页,但如果用户在设置页还是没开,就不要再接着弹第三次、第四次。文档给出的思路只到"二次请求"为止,再往后其实已经属于产品策略问题,不该在这段代码里加码。
异常分支留好日志 。示例里 catch 块只给了 // ... 占位,真实项目里这里建议把错误打出来,排查"为什么弹窗没起来"的时候会省很多事。

约束条件

文档里有两条硬性要求,顺手贴一下,免得照搬代码的老兄们跑不起来:

需要 HarmonyOS 6.0.0 Release SDK 及以上版本;
需要 DevEco Studio 6.0.0 Release 及以上版本编译运行。

工程目录也很标准,就两块:entry/src/main/ets 放代码,entry/src/main/resources 放资源,没什么花活。

写在最后

通知授权弹窗这件事,归根到底是在用户体验和触达率之间找一个平衡点。文档给的方案其实很克制------一次系统弹窗加一次设置页兜底,用一个标志位防重复,仅此而已。

在求职招聘这种"一条消息可能改变一次机会"的场景下,这一点点克制其实反而更重要:你不打扰用户,用户才愿意把通知权限留给你。照着 NotificationManager 这几个接口把流程跑顺,基本就能把通知授权这块底子打得比较稳了。