FCM：onNewToken vs Firebase InstanceId
Firebase已经弃用了com中的一些消息传递调用。谷歌。firebase:firebase messaging:17.1.0版本。这篇文章很好地介绍了这些变化。
问：有人能告诉我，如果不实现onNewToken，而只是在每次应用发布时调用下面的块，这是否被视为不好的做法？这对Android用户来说可能太过分了，但从iOS的角度来看，这感觉像是在家。
FirebaseInstanceId.getInstance().instanceId.addOnSuccessListener(this) { instanceIdResult ->
// Just use this call
val newToken = instanceIdResult.token
Log.i("newToken", newToken)
}
@Override
public void onNewToken(String s) {
super.onNewToken(s);
// Leave this unimplemented
}
我更熟悉iOS，它在每次发布应用程序时都会称之为onNewToken。所以对于iOS，我把逻辑放在那里，以确定我的后端是否需要更新。
getInstanceId（）文档说这会生成一个实例ID，如果它还不存在，它会开始定期向Firebase后端发送信息。这让我假设我可以在每次启动时调用Firebase InstanceId.getInstance（）. instanceId.addOnSynessListener。
共有3个答案
尽管文档中说在第一个应用程序启动时调用了onNewToken，但事实并非如此。这就是为什么当我需要Id时，我分别使用FirebaseInstanceId，而之前没有调用过onNewToken，尽管应用程序已经运行了一段时间。（所以我们在项目中两者都做）
我观察到的是，在我通过FirebaseInstanceId获取令牌后不久，Firebase将调用onNewToken。以这种方式获取令牌似乎会启动Firebase服务中的某些内容。
然而，它是这样工作的，这对于我们当前的项目来说已经足够好了。
编辑：由于Firebase InstanceId的getToken（）最近被弃用，请参阅Arthur Thompson的回答。
首先，我对任何逻辑都持高度怀疑态度，即如果iOS中的某些功能正常，那么Android上也可以！
Android和iOS之间推送消息的实现方式截然不同。在Android上，它依赖于在另一个进程中运行的Play服务。在iOS上，这是完全不同的。交战规则根本不一样。
注意，建议的令牌检索方法是通过回调。这表明令牌生成本质上是异步的。换言之，在应用程序启动时（无论你以何种方式定义），管理令牌的后台工作可能还没有完成。当你要求时，可能根本没有任何代币可用。谁知道这需要多长时间？你最好在系统告诉你它准备好了的时候接受令牌，而不是猜测它什么时候准备好。遵循推荐的实施路径。
有一件非常重要的事情，但还没有人提到：
如果仅在应用程序启动后才检查当前设备令牌，则当应用程序处于后台时（当然），您可能会丢失令牌被更新的事件，并且在用户再次启动应用程序并将新令牌发送到服务器之前，您将无法从服务器接收远程推送消息。
在您的应用程序在后台时也可以调用该回调的全部目的是防止丢失后端消息（如果您的应用程序或其某些重要功能非常依赖推送通知，这一点很重要）。重要的是要注意，此回调不仅会在您第一次注册设备时为您提供令牌，而且：如果更新了InstanceID令牌，则会调用。如果上一个令牌的安全性受到损害，可能会发生这种情况。
所以：
有人能告诉我，如果不实现onNewToken，而只是在每次应用发布时调用下面的块，这是否被视为不好的做法？这对Android用户来说可能太过分了，但从iOS的角度来看，这感觉像是在家。
是的，不实现onNewToken（）实际上是一种不好的做法。