告别推送焦虑：手把手教你用uni-push 2.0搞定App在线/离线消息（附荣耀证书配置避坑指南）

每次看到用户反馈"为什么收不到通知"，作为开发者的你是否感到头皮发麻？消息推送这个看似简单的功能，在实际落地时却暗藏无数坑点。本文将带你用uni-push 2.0彻底解决这个痛点，特别针对荣耀机型的证书配置提供完整避坑方案。

1. 为什么你的推送总在"薛定谔状态"？

消息推送的不可靠性主要源于安卓生态的碎片化。当应用在前台时，我们使用在线推送（通过个推通道）；当应用退到后台或被杀死时，则需要依赖厂商通道进行离线推送。这种双通道机制本身就增加了复杂度。

更棘手的是，不同厂商对推送服务的实现各不相同：

• 华为/荣耀：需要申请推送服务并配置证书
• 小米/OPPO/VIVO：要求应用必须上架对应应用商店
• 其他安卓设备：依赖个推的自建通道

提示：测试阶段最容易忽略的是厂商通道的测试模式限制。例如华为每日仅允许500条测试消息，超过后将静默失败。

2. 从零搭建uni-push 2.0环境

2.1 服务开通与基础配置

首先在DCloud开发者中心完成以下准备工作：

1. 创建应用并开通uni-push 2.0服务
2. 关联阿里云免费版云服务空间
3. 在manifest.json中启用push模块

关键配置项检查清单：

json复制// manifest.json片段示例
"push": {
  "unipush": {
    "enable": true,
    "vendor": {
      "honor": {
        "appid": "你的荣耀应用ID",
        "appkey": "你的荣耀应用Key"
      }
    }
  }
}

2.2 客户端初始化最佳实践

在App.vue中建议采用以下健壮性更强的CID获取方案：

javascript复制let retryCount = 0;
const MAX_RETRY = 3;

function fetchClientId() {
  plus.push.getClientInfoAsync(
    info => {
      if (info.clientid) {
        console.log('成功获取CID:', info.clientid);
        uni.setStorageSync('push_cid', info.clientid);
        // 建议在此处将CID与用户账号绑定
        bindCidToUserAccount(info.clientid); 
      } else if (retryCount < MAX_RETRY) {
        retryCount++;
        setTimeout(fetchClientId, 2000 * retryCount);
      }
    },
    error => {
      console.error('获取CID失败:', error);
    }
  );
}

onLaunch(() => {
  fetchClientId();
});

3. 荣耀证书配置全流程避坑

3.1 证书申请步步为营

荣耀推送服务配置流程中的关键节点：

3.2 6003错误终极解决方案

当遇到token获取失败并返回6003错误时，按此顺序排查：

1. 证书指纹比对：

   bash复制# 获取当前APK的证书指纹
   keytool -printcert -jarfile your_app.apk
   

   确保输出的SHA256与荣耀开发者平台配置完全一致

2. 包名三重验证：

   • AndroidManifest.xml中的package属性
   • 打包时配置的应用ID
   • 荣耀平台注册的包名

3. 云端配置同步：
   在uni-app项目的cloudfunctions/common/uni-config-center/uni-push/config.json中检查厂商配置是否同步更新

4. 双通道推送实战策略

4.1 在线推送云函数示例

优化后的推送云函数支持多场景策略：

javascript复制const uniPush = uniCloud.getPushManager({ appId: "__UNI__XXXXXX" });

exports.main = async (event) => {
  const { cid, title, content, payload } = event;
  
  try {
    const res = await uniPush.sendMessage({
      push_clientid: cid,
      title,
      content,
      payload,
      force_notification: true,
      options: {
        HW: { "/message/android/target_user_type": 1 }, // 华为测试模式
        VV: { "/pushMode": 1 } // 荣耀测试模式
      }
    });
    
    // 失败重试逻辑
    if (res.errCode) {
      await new Promise(resolve => setTimeout(resolve, 1000));
      return await uniPush.sendMessage({...});
    }
    
    return res;
  } catch (err) {
    console.error('推送失败:', err);
    throw err;
  }
};

4.2 离线推送的保底方案

即使配置了厂商通道，仍建议实现以下保底策略：

1. 重要消息二次确认：对于关键通知，可通过API检查送达状态
2. 本地通知唤醒：当应用回到前台时，检查未读消息并触发本地通知
3. 智能切换策略：

   javascript复制function smartPush(message) {
     if (isAppForeground()) {
       sendOnlinePush(message);
     } else {
       if (isHonorDevice()) {
         sendOfflinePush(message);
       } else {
         scheduleRetry(message);
       }
     }
   }
   

5. 用户体系与推送的深度整合

单纯的CID绑定远远不够，成熟的推送系统需要考虑：

用户分群推送方案：

sql复制-- 示例：用户标签表结构
CREATE TABLE user_push_profiles (
  user_id VARCHAR(64) PRIMARY KEY,
  cid VARCHAR(128),
  device_brand VARCHAR(32),
  os_version VARCHAR(16),
  push_preferences JSON -- 存储用户的消息接收偏好
);

推送效果监控看板：

• 送达率分设备统计
• 点击率分消息类型分析
• 厂商通道失败原因归类

在实际项目中，我们发现荣耀机型在以下场景容易出问题：系统升级后需要重新申请推送权限、EMUI版本低于10时存在兼容性问题、省电模式会限制后台推送。针对这些情况，我们在用户首次启动时增加了专门的检测逻辑，当发现潜在问题时主动引导用户进行设置调整。