对使用 onMessageReceived 处理数据通知感到困惑：它是在不同的线程中调用的吗？为什么可以访问全局变量？

问题描述 投票：0回答：2

在 iOS 中，有一个名为 

NotificationService
的扩展。这完全是在不同的“目标”中，并在不同的进程中运行到主应用程序的“next”。它无法访问主应用程序的代码。在该服务中，您可以在向用户显示通知之前修改通知。 这与 Android 的方法不同，我可以扩展

FirebaseMessagingService

、覆盖 

onMessageReceived
方法并执行任何我想要的操作。我只使用 
data
消息。我对此方法有一些疑问：


我是否需要显示通知，或者我可以什么都不做而一切继续正常进行？
    

  • onMessageReceived
  • 是否像在iOS中一样在单独的进程中运行，或者在与应用程序相同的进程中运行（如果应用程序打开）？
    为什么我可以访问我的服务中的全局变量？从我的本地测试中，我看到全局变量在我的应用程序运行时设置为相同的值，并在我的应用程序关闭时重置，有这方面的任何文档吗？它们什么时候在同一个进程中运行？
    • 

  • 
    
    • 




    
    android
    
    firebase
    
    kotlin
    
    firebase-cloud-messaging
    
    android-service
    
    
2个回答

    

      
      
      

        

          

            

              
0
投票

              
            

          

        

        
title
和
body
）


    这取决于各种条件。但在典型情况下，您必须自行处理
  1. 当您的应用程序位于前台并收到 fcm 推送通知时（这是调用 
    onMessageReceived  时的情况）
    。
    


    2. 通常什么也不会发生。但当超时到达时，
  2. FirebaseMessagingService
    本身很少会进入销毁状态。
    

    

    3. 3.在FCM私有后台线程上调用。同样在典型情况下，因为它是 
Service
，所以它共享相同的进程。（但您可以在其他进程上运行它）


在典型情况下，只需使用 
    LocalBroadCastReceiver
  1.  发送所需的 Intent 或使用某种静态全局字段或方法调度事件（因为您的 Activity 和 FirebaseMessagingService 将在同一进程中运行）。
    

    2. 以下是有关 Android 的详细信息 
FirebaseMessagingService
FirebaseMessagingService 有奇怪的行为和限制。
（
FirebaseMessagingService
 应在 
com.google.firebase.iid.FirebaseInstanceIdReceiver
 运行的同一进程中运行。）
onMessageReceived
 标记为 
@WorkerThread
，这意味着它打算并将在后台线程中调用。
FirebaseMessagingService
行为取决于两个条件
A - FirebaseMessagingService 运行进程是前台
B - FCM 有效负载仅包含原始有效负载（没有 
title
 和没有 
body
）
如果 (B == true) 或 (A == true && B == false) 则始终从 FCM sdk 的私有工作线程调用 
onMessageReceived
，并且 FCM SDK 将不会执行任何处理通知的作业。
如果 (A == false && B == false) 则 
FirebaseMessagingService
 按照 FCM 有效负载文档所述自行处理 FCM 有效负载，并且 
不会调用 
onMessageReceived
。

    




      

      
      
      

      

        

          

            

              
0
投票

              
            

          

        

        




“
    Message
  • ”是通过 Firebase 发送到手机上应用程序实例的内容。它可以对用户可见或不可见。
“
    • 通知
  • ”是系统托盘中弹出的内容。它来自电话而不是某些远程服务。


    • 发送消息的一方可能会也可能不会向其
添加通知
。这是两者相关的唯一方式。
以下假设消息包含通知：


Ad1：您不需要在 
onMessageReceived
 上显示通知。在大多数情况下，您不应该这样做。
Ad2：相同进程，不同线程。


Ad3：因为是同样的过程。


我认为混乱来自于这样一个事实：仅当您的应用程序位于前台时才会调用 
onMessageReceived
，因此所有全局变量都已经存在。当您的应用程序处于后台时，根本不会调用
onMessageReceived
，系统会根据消息中的数据自行创建通知。
总结一下：




如果您想要默认处理：向消息添加通知。系统将在适当的情况下显示它（即：不是前台），并且当/如果用户单击它时，您的应用程序可以通过 
    onCreate()
  • /
    onNewIntent()
     中的意图读取消息负载。从技术上讲，您根本不需要
    onMessageReceived()
    。 （通常，您希望此代码在收件箱上显示红点或类似的东西）
    如果您希望对每个通知进行精确的客户端控制，请不要将它们附加到消息中。原始消息不由系统处理，但始终直接发送到您的
    • onMessageRecieved
  • 。您应该检测前景，然后执行逻辑来决定是否应显示通知以及它应包含什么内容。
    

    • 所有全局变量将始终存在，但在第二种情况下，应用程序的其余部分（活动）有时不会存在。

    



      

      
    

  

  

    
最新问题


  





  

    © www.soinside.com 2019 - 2024. All rights reserved.