在我们注意到我们的一些用户缺少应用程序打开归因数据后，我们更深入地查看了cordova-plugin-appsflyer-sdk的来源以寻找原因 - 我们找到了它：
我们在初始化 SDK 时设置onInstallConversionDataListener为true接收适当的回调。然而，onSuccess并非在所有情况下都使用属性数据调用回调。原因是原生回调（onConversionDataReceived& onAppOpenAttribution）的处理方式AppsFlyerPlugin.m。当使用 AppsFlyer 深层链接启动应用程序时，我们应该同时收到转化数据（原生：）onConversionDataReceived和深层链接信息（原生：） onAppOpenAttribution。插件实现中的问题是，这两个回调中只有第一个被转发到代码的 Java 脚本部分，而第二个被忽略，因为在第一次调用conversionListeners后将被设置为 null （第 386、394 行）和 375
onSuccessAppsFlyerPlugin.mhttps://github.com/AppsFlyerSDK/cordova-plugin-appsflyer-sdk/blob/master/src/ios/AppsFlyerPlugin.m）
我们的观察表明，当我们从深层链接打开应用程序时，原生回调onConversionDataReceived&onAppOpenAttribution都被正确调用，但它们的调用顺序不同，具体取决于应用程序是否在后台。这导致如果您使用深度链接打开应用程序，则在应用程序根本没有运行的情况下仅将转换数据发送到带有onSuccess回调的 JavaScript，而在应用程序未运行的情况下仅发送应用程序打开属性数据。应用程序在后台（应用程序恢复）。正确的行为是，在这两种情况下都应该转发onConversionDataReceived& 。onAppOpenAttribution
保持conversionListeners(=not 在第 386、394 行以及可能还有 375 行中设置为 null) 似乎可以解决问题，但我们不知道这些侦听器在第一次调用后当前被删除的原因。
是否有理由将此回调重置为空？