本来是没有这篇文章的计划的，因为之前新项目直接就用上了Flutter2.0空安全，所有的第三方库也升级空安全了，所以之前项目中做消息推送使用的firebase_messaging第三方库也得升级空安全，结果升级完后，各种以前的方法都没了。一脸懵逼，两脸懵逼~
(这就是flutter第三方库的坑，兼容是不存在的，看着不爽直接干掉O(∩_∩)O哈哈~)

  本篇文章就直接聊聊在flutter端firebase_messaging的更新使用，想其他的原生端配置呀，推送环境的区分呀以前的文章都有，这里就不一一细说了。

  以前的文章参见：
1、推送文章链接，基于firebase_messaging 7.0.3
《Flutter中如何使用Firebase 做消息推送(Notification)》

2、Firebase环境分离链接
《Flutter 中为Firebase提供多个构建环境分离配置》

注：基于firebase_messaging 9.0.0以上版本，因为这个版本后就支持空安全了。

一、Android原生端修改

  在7.0.3以前，Android原生端需要注册和配置FirebaseMessagingService，现在都不需要了，全部干掉。

//import io.flutter.plugins.firebasemessaging.FirebaseMessagingPlugin
//import io.flutter.plugins.firebasemessaging.FlutterFirebaseMessagingService

class MaintenanceApplication : FlutterApplication(),  PluginRegistry.PluginRegistrantCallback{

    override fun onCreate() {
        super.onCreate()
        Embrace.getInstance().start(this);
//        FlutterFirebaseMessagingService.setPluginRegistrant(this)
    }

    override fun registerWith(registry: PluginRegistry?) {
//        GeneratedPluginRegistrant.registerWith(registry)
//        FirebaseMessagingPlugin.registerWith(registry?.registrarFor("io.flutter.plugins.firebasemessaging.FirebaseMessagingPlugin"))
    }
}

二、Flutter端的变化

大家可以参看pub.dev，不过那个Example确实有点恶心。绕的很~

可以看看这篇文章https://firebase.flutter.dev/docs/messaging/notifications/#foreground-notifications

2.1 在7.0.3以前的话，在Flutter端接收数据有四种方法：

    firebaseMessaging.configure(
      onMessage: (message) => handleMessage(message),
      onLaunch: (message) => startToRedirectByNotification(message, source: 'onLaunch'),
      onResume: (message) => startToRedirectByNotification(message, source: 'onResume'),
      onBackgroundMessage: backgroundMessageHandler
    );

onMessage: 对应应用在前台，不会发出系统Notification，只发送消息，如需系统Notification。则需要手动通过flutter_local_notifications第三方库发送。

onLaunch：系统在被杀掉，既从历史中划掉时，点击Notification后，跳转调用的方法。

onResume：系统在后台时，点击Notification后，跳转调用的方法。

2.2 在9.0.0以后的话，在Flutter端接收数据全部改掉，全部！！！

2.2.1 应用在前台

当应用在前台时，收到消息需要通过FirebaseMessaging中的onMessage，它是一个Stream，我们通过listen监听，它返回的是RemoteMessage对象。同时应用在前台时，也不会发出系统Notification，业务需要的话，需手动发出。(该方法同7.0.3 onMessage)

FirebaseMessaging.onMessage.listen((RemoteMessage message) {
  RemoteNotification notification = message.notification;
  AndroidNotification android = message.notification?.android;

  // If `onMessage` is triggered with a notification, construct our own
  // local notification to show to users using the created channel.
  if (notification != null && android != null) {
    flutterLocalNotificationsPlugin.show(
        notification.hashCode,
        notification.title,
        notification.body,
        NotificationDetails(
          android: AndroidNotificationDetails(
            channel.id,
            channel.name,
            channel.description,
            icon: android?.smallIcon,
            // other properties...
          ),
        ));
  }
});

2.2.2 应用在后台或被杀掉

这时候在9.0.0中就没有onLaunch或者onResume方法了，对应的是onMessageOpenedApp，看这货的名字也知道，应该是点击了Notification，打开App的数据流了。它是一个Stream，也是通过listen监听它，获取相应的数据，并跳转到对应页面。(这一般是应用在后台，并没有没杀掉时调用)

   // Also handle any interaction when the app is in the background via a
    // Stream listener
    FirebaseMessaging.onMessageOpenedApp.listen((RemoteMessage message) {
      if (message.data['type'] == 'chat') {
        Navigator.pushNamed(context, '/chat',
          arguments: ChatArguments(message));
      }
    });

当App被杀掉后，onMessageOpenedApp方法就凉凉了，这时候该getInitialMessage方法登场了(对应onLaunch方法)。它会获取最近一次的Remote消息。

   // Get any messages which caused the application to open from
    // a terminated state.
    RemoteMessage initialMessage =
        await FirebaseMessaging.instance.getInitialMessage();

    // If the message also contains a data property with a "type" of "chat",
    // navigate to a chat screen
    if (initialMessage != null && initialMessage.data['type'] == 'chat') {
      Navigator.pushNamed(context, '/chat',
          arguments: ChatArguments(initialMessage));
    }

2.3 给ios加点权限

await FirebaseMessaging.instance.setForegroundNotificationPresentationOptions(
  alert: true, // Required to display a heads up notification
  badge: true,
  sound: true,
);

三、遇到的坑儿

以前的标题

现在的标题，还是太年轻了😂

3.1 onMessage和onMessageOpenedApp

坑儿一:

  上面说了在监听onMessage，它是一个流。当应用在前台时，Firebase原生端就会通过MethodChannel，发送notification数据，不再发送系统Notification了。然而，实际测试在iOS端，App在前端也会发送系统Notification，如果iOS在监听onMessage流时再次发送本地Notification的话，就会有两条Notification消息，这里我们就得区分对待了，只在Android平台监听onMessage流。

    if (Platform.isAndroid) {
      FirebaseMessaging.onMessage.listen((event) {
        handleMessage(event);
      });
    }

坑儿二：

  因为上面也聊过，onMessage和onMessageOpenedApp实际上是流数据，如果我们需要做操作就需要监听它们。
  那么问题来了，比如说在设置页面，我们有控制Notification打开关闭的开关，一般做法无非是打开时，获取firebase token，与后台进行绑定；关闭时删除Firebase token，与后台进行解绑，这样就能收到或者不能收到后台的推送消息了。
  但是，我们多开关几次后，也许再次打开时，我们收到后台推送，但是在onMessage里会多次发送本地Notificition。开始很诧异，后来想明白了。

因为之前监听onMessage和onMessageOpenedApp流时，关闭推送没有关闭，造成了会同时有多个监听器在监听流，所以在我们关闭或者解绑fireabse_messaging时，我们需要将监听流的监听器也关闭。

  static  StreamSubscription? streamSubscription;
  static  StreamSubscription? onAppOpenStreamSubscription;

  static clearStreamSubscription() {
    streamSubscription?.cancel();
    onAppOpenStreamSubscription?.cancel();
    streamSubscription = null;
    onAppOpenStreamSubscription = null;

  }

initFirebase(){
    if (Platform.isAndroid) {
      streamSubscription = FirebaseMessaging.onMessage.listen((event) {
        handleMessage(event);
      });
    }

    onAppOpenStreamSubscription = FirebaseMessaging.onMessageOpenedApp.listen((RemoteMessage message) {
      startToRedirectByNotification(message.data);
    });
}

3.2 onMessage手动发本地Notification库的问题

  这里用的发送本地Notification的第三方库为：flutter_local_notifications: 5.0.0+4。这次不是已经升级了版本吗，我认为应该没啥问题。可是测试发现心塞。

坑儿三：

  这里有什么问题呢，这个问题主要发生在Android端，iOS没啥问题。
问题描述：App在前台，监听onMessage收到firebase发来的消息后，通过flutter_local_notifications发出本地Notificaiton。这里并没有什么问题。当你退出App，并在历史中kill掉App。在点击通知栏的Notification时，只会打开App，并不会执行onSelectNotification参数配置的跳转方法。

  这就尴尬了，我以前没问题的呀，后面就对比了下以前改过的flutter_local_notifications: 2.0.0+1版本。发现了为什么不调用onSelectNotification的问题了。也是需要修改flutter_local_notifications: 5.0.0+4库的Android端源码。

  这也是需要改完后，发布到私有的pub.dev上，要不就提issue。

修改路径：flutter_local_notifications-5.0.0+4/android/src/main/java/com/dexterous/flutterlocalnotifications/FlutterLocalNotificationPlugin.java

在initilalize方法中添加如下代码可以解决该问题。

    private void initialize(MethodCall call, Result result) {
        ...
        //Add  for when app kill can not receive notification Data
        if (mainActivity != null && !launchedActivityFromHistory(mainActivity.getIntent())) {
            sendNotificationPayloadMessage(mainActivity.getIntent());
        }
        //end
        ...
        result.success(true);
    }

3.3 事实证明使用firebase库如升级打怪

这里碰到的问题是firebase_messaging: 10.0.4的问题，这里要区分iOS和Android端的修改，两边都有问题。

问题重现描述：当App置于后台或者被kill下的情况，后台发出推送，前台收到了系统Notification，点击会响应onMessageOpenedApp或者getInitialMessage方法，并处理应用层设置的逻辑，当我们退出登录也就是Sign out后，在登录结果，发现有重新调用了 onMessageOpenedApp或者getInitialMessage方法。懵逼了~

没得办法，还是得去两端源码中看看是为什么，

坑儿四：(Android端)

修改路径：firebase_messaging-10.0.4/android/src/main/java/io/flutter/plugins/firebase/messaging/FlutterFirebaseMessagingPlugin.java

首先，我这里稍稍聊聊，firebase_messaging库Android端如何缓存Notification的，

它有三级缓存：

1、在FlutterFirebaseMessagingPlugin.java中用全局变量initialMessage缓存；
2、在FlutterFirebaseMessagingReceiver.java中收到推送消息后，使用一个Map -> HashMap<String, RemoteMessage> notifications = new HashMap<>()缓存；
3、在FlutterFirebaseMessagingStore.java中使用SharedPreferences缓存；
每次在onNewIntent和getInitialMessage中都会进行三级缓存取数据，因为缓存问题，会导致重复调用。

解决方案：

因为在Sign Out时，我们会调用firebase_messaging的deleteToken方法，那我们就可以在deleteToken时，将三级缓存清理一波：(在FlutterFirebaseMessagingPlugin.java中修改)

 private Task<Void> deleteToken() {
    return Tasks.call(
        cachedThreadPool,
        () -> {
            //Add for clear cache
            clearFirebaseNotification();
            //end
          Tasks.await(FirebaseMessaging.getInstance().deleteToken());
          return null;
        });
  }

  //clear Cache Notification when deleteToken
  private void clearFirebaseNotification(){
    //reset initialMessage
    initialMessage = null;
    //Clear FlutterFirebaseMessagingStore cache
    FlutterFirebaseMessagingStore.getInstance().removeAllFirebaseMessage();
    //Clear FlutterFirebaseMessagingReceiver.notifications cache
    FlutterFirebaseMessagingReceiver.notifications.clear();
  }

在onNewIntent方法中，因为另一个问题：App在后台没被干掉，收到推送后打开，然后在kill掉App，再次进入App，依然会重新调用getInitialMessage方法，后面查了下，发现在getInitialMessage方法中，会查找三级缓存，前两个都是null，而SharedPreferences中的缓存还在，没有被清理。
(也是在FlutterFirebaseMessagingPlugin.java中修改)

@Override
  public boolean onNewIntent(Intent intent) {
    ....
    //Add 20210729 for Teminated status will open twice getInitMessage()
    FlutterFirebaseMessagingStore.getInstance().removeFirebaseMessage(messageId);
//end
...

    // Store this message for later use by getInitialMessage.
    initialMessage = remoteMessage;
    ...
  }

官方注释是说不要删除SharedPreferences中的缓存，我的业务需求是需要删，大家具体看看自己的业务需求吧。

iOS端修改

问题也就和上面Android是一样的。

修改路径：firebase_messaging-10.0.4/ios/Classes/FLTFirebaseMessagingPlugin.m

在iOS端就没有像Android那样有三级缓存了，它直接接受iOS系统的NotificationCenter打开时发来的消息，
1、直接赋值给了变量NSDictionary *_initialNotification。然后通过onMessageOpenedApp向Flutter端发出消息。
2、如果应用调用了getInitialMessage方法，则会通过copyInitialNotification方法拷贝一份_initialNotification，并将其发出，并将_initialNotification置为空。

if ([@"Messaging#getInitialMessage"isEqualToString:call.method]) {
  NSLog(@"Messaging#getInitialMessage");
    methodCallResult.success([self copyInitialNotification]);
  }

- (nullable NSDictionary *)copyInitialNotification { @synchronized(self) {
    if (_initialNotification != nil) {
      NSDictionary *initialNotificationCopy = [_initialNotification copy];
      _initialNotification = nil;
      return initialNotificationCopy;
    }
  }
  return nil;
}

在所以这里的原因也是因为退出登录调用deleteToken，但是_initialNotification变量并不为空，所以在重新登录并绑定Firebase时候调用getInitialMessage方法时候就会得到_initialNotification，并发出Notification。

所以修改就变得很简单了，在deleteToken方法中修改：

else if ([@"Messaging#deleteToken" isEqualToString:call.method]) {
    //将_initialNotification置为空
     _initialNotification = nil;
    [self messagingDeleteToken:call.arguments withMethodCallResult:methodCallResult];
  } 

四、总结

好了，到此坑坑总算填完，至于还有什么坑，源码已看，还有啥不能填的，尽管来，还有谁~~~~😓