应用退出/被杀状态下Firebase FCM通知声音延迟5-10秒问题求助

你遇到的延迟是两个错误实现共同导致的：

1. 你发送的FCM载荷带notification字段，属于通知类消息：应用被杀状态下这类消息会优先被系统通知托盘接管直接展示通知，之后才会唤醒应用进程触发你注册的setBackgroundMessageHandler，你在回调里手动播放声音的逻辑自然会比通知展示晚5-10秒。
2. 你每次收到通知都重新初始化Sound实例加载音频资源，冷启动状态下的资源加载也会增加额外耗时。

按优先级选择以下方案即可解决延迟问题：

• 优先使用系统通知渠道原生播放声音
  安卓端提前创建自定义通知渠道，将notfi.mp3设置为该渠道的默认通知音，发送FCM时指定对应渠道ID即可，完全不需要在JS层手动播放声音，系统收到通知会直接触发渠道配置的铃声，无延迟。
  对应FCM载荷修改参考：

  const notification_body = {
    notification: {
      title: notification.title,
      body: notification.description,
      android_channel_id: "你的自定义通知渠道ID" // 新增字段
    },
    registration_ids: tokens,
  };
  

• 必须走JS层自定义播放逻辑的话，改用数据类FCM消息
  把载荷里的notification字段删除，所有通知内容放到data字段下，此时无论应用处于什么状态，收到消息都会优先触发setBackgroundMessageHandler，你可以在回调里先播放声音，再手动调用本地通知API弹出通知。
  对应FCM载荷修改参考：

  const notification_body = {
    data: { // 替换原来的notification字段
      title: notification.title,
      body: notification.description,
    },
    registration_ids: tokens,
  };
  

• 优化音频加载逻辑
  不要每次调用播放都新建Sound实例，全局提前初始化音频实例，收到通知直接调用播放方法，省去每次加载资源的耗时：

  // 全局提前初始化，仅加载一次
  const whoosh = new Sound('notfi.mp3', Sound.MAIN_BUNDLE, (error) => {
    if (error) {
      console.log('failed to load the sound', error);
    }
  });
  
  const play = () => {
    whoosh.play((success) => {
      if (!success) {
        console.log('playback failed due to audio decoding errors');
      }
    });
  };
  

• 额外排查项
  检查应用是否被系统加入了电量优化限制名单，被杀状态下系统会延迟唤醒高耗电限制的应用，将应用加入电量白名单可避免进程唤醒延迟。

内容的提问来源于stack exchange，提问作者Manthan Shukla