Flutter Facebook App Events 在 Android Release 中丢失购买事件的一次排查

背景

最近在一个 Flutter 项目里接入 facebook_app_events 时，遇到了一个不太直观的问题。

购买和订阅完成以后，我们会向 Facebook App Events 上报事件。开发阶段看起来一切正常：debug 包能看到购买和订阅事件，profile 包也能看到。但换成正式的 release 包以后，后台只有安装相关事件，购买和订阅事件完全没有。

更麻烦的是，App 本身没有崩溃，购买流程也能正常走完，Facebook 相关的网络请求也不是完全消失。也就是说，用户侧功能是通的，SDK 也不是整体不可用，只有购买/订阅这类关键事件在正式包里静默缺失。

这个现象本身就很关键。因为如果是 Facebook appId、client token、后台配置、事件参数这些基础配置整体错误，安装事件通常也不应该正常出现；如果只是业务代码写错，问题也不应该稳定只出现在 release。真正可疑的是：同一份代码在不同构建类型下，最终生成的 Android 产物并不一样，而且不同事件可能走了 SDK 内部不同的代码路径。

先看现象

问题可以简化成下面这张表：

构建类型	是否开启典型 release 优化	安装事件	购买/订阅事件
debug	否	能看到	能看到
profile	通常不等同于正式 release 优化	能看到	能看到
release	是	能看到	看不到

这不是一个普通的“埋点没调用”问题。
如果只是 Dart 层没有调用，三个构建类型应该都会受影响；如果 SDK 初始化完全失败，安装事件也不应该还能出现。现在的现象更像是：Facebook SDK 的基础初始化和部分自动事件正常，但购买/订阅这条事件链路在 release 产物里被破坏了。

在 Flutter 项目里，一次 Facebook App Events 上报大致会经过这条链路：

Facebook SDK 初始化/自动事件
  -> 安装事件/启动相关事件
  -> Facebook 后台

Dart 购买/订阅成功回调
  -> facebook_app_events Flutter 插件
  -> MethodChannel
  -> Android 插件层
  -> Facebook Android SDK 的 AppEventsLogger
  -> App Events 队列/批量发送
  -> Facebook 后台

安装事件存在，说明 SDK 并不是完全没有启动，也不是完全没有网络。debug 和 profile 的购买/订阅事件能跑通，又说明 Dart 调用入口、MethodChannel、基础配置、事件参数这些环节大方向是成立的。release 只丢购买/订阅，更像是 Android 侧最终字节码被处理以后，SDK 内部某些与 AppEvents 相关的类、方法或元信息不再符合运行时预期。

排查过程

我一开始没有直接去改混淆规则，而是先把几个更常见的问题排掉。

调用时机

先检查购买和订阅成功以后的代码路径，确认事件是在交易完成以后触发，而不是在页面初始化、商品拉取、支付弹窗展示这些容易误判的阶段触发。

这一步主要是为了避免把“事件本来就没触发”误判成“SDK 没上报”。检查以后，购买和订阅回调里的事件调用都能稳定走到。

参数和环境

接着检查事件参数，包括金额、货币码、事件名、订阅相关字段，以及 Android 侧的 Facebook appId、client token、manifest 配置。

这些配置如果错，一般不会只在 release 出问题，也不太会只影响购买/订阅而完全不影响安装事件。所以当 debug/profile 都能看到后台数据，且 release 仍然有安装事件时，这些项的优先级就可以往后放。

抓包观察

中间也尝试过用抓包工具观察 release 包的网络行为。结果比较微妙：能看到 Facebook 相关域名的请求，说明 App 并不是完全没有碰到 Facebook 网络链路。

但这个观察不能继续深入到请求体和响应体。测试设备是 root 设备，并安装了自定义系统证书；开启 SSL 抓包后，相关 HTTPS 请求会失败，无法稳定看到详细 payload 和服务端响应。

所以这一步只能作为旁证，而不能作为最终结论：

1. 能看到 Facebook 域名请求，说明“完全没有网络请求”这个方向基本可以排除；
2. 看不到具体 payload，不能证明购买/订阅事件真的被发送到了服务端；
3. SSL 抓包导致请求失败，也不能直接反推出 SDK 本身有问题，因为抓包环境已经改变了 TLS 链路。

也就是说，抓包给出的信息是：SDK 不是完全断网，但购买/订阅事件是否进入了正确的上报队列仍然未知。这个结果反而进一步支持继续看 release 产物差异，而不是把问题简单归因到网络。

构建差异

最后看 release 独有的东西。Android 正式包通常会打开代码压缩、混淆、优化和资源裁剪。于是做了一个很直接的验证：临时关闭 release 的压缩和资源清理。

minifyEnabled false
shrinkResources false

重新打包以后，Facebook 后台恢复了购买和订阅事件。

这一步不能严格证明“唯一原因就是某一个类被删了”，但它已经足够把问题范围收窄到 release 构建优化阶段。因为业务代码没变，服务端配置没变，网络侧也并非完全没有 Facebook 请求，唯一显著变化是 R8 不再介入处理最终字节码。

R8 到底改了什么

很多时候我们说“混淆”，实际把几个不同概念混在了一起。Android 现在默认使用的是 R8，它做的不只是把类名改短。

R8 常见会做几类事情：

阶段	作用	可能带来的影响
Code shrinking	移除静态分析认为不可达的代码	反射、动态注册、运行时查找的类可能被误删
Obfuscation	缩短类名、方法名、字段名	依赖类名或成员名的逻辑可能失效
Optimization	内联、类合并、方法合并等优化	某些依赖固定结构的 SDK 可能出现行为差异
Resource shrinking	移除未被引用的资源	通过字符串或动态方式引用的资源可能被裁掉

R8 的核心思路是“可达性分析”。它会从应用入口开始，比如 manifest 里的 Activity、Service、Receiver，再沿着代码调用关系构建一张引用图。能走到的保留，走不到的就有机会被删掉或重写。

问题出在第三方 SDK 经常不完全依赖静态调用。比如：

• 通过反射按类名查找实现；
• 通过注解、配置、manifest metadata 做动态初始化；
• 通过事件名、常量、内部注册表组织能力；
• 插件层只暴露一个很薄的入口，真正逻辑藏在原生 SDK 内部。

这些关系对运行时是有效的，但对静态分析不一定足够明显。于是 R8 可能认为某些类“没有被使用”，然后把它们删除、改名或合并。最后表现出来的结果就是：App 没崩，SDK 初始化也还在，安装事件甚至还能看到，但某些更深的事件链路断了。

这也是这次问题最容易误导人的地方。它不是编译错误，也不是启动崩溃，甚至不是 Facebook SDK 完全不可用，而是一个分析 SDK 在 release 包里丢了部分关键事件。

为什么 debug/profile 正常

debug 构建的目标是开发调试，通常不会开启 release 级别的压缩和混淆。类名、方法名、调用结构都尽量保持原样，方便调试和热重载。

profile 更接近性能测试场景，但它也不等同于最终商店发布的 release 产物。它可以暴露一部分性能问题，却不能完全替代 release 验证。

所以这类问题的判断逻辑是：

debug 正常
profile 正常
release 安装事件正常，但购买/订阅异常
  -> 优先比较 release 独有配置
  -> 重点看 minifyEnabled / shrinkResources / proguardFiles
  -> 再检查第三方 SDK 是否需要额外 keep 规则

如果只在模拟器或 debug 包上验证埋点，很容易以为功能已经闭环。实际发布相关的 SDK，尤其是广告、归因、支付、统计、登录这几类，最好都用 release 签名包单独验证一次。

最终修复

临时关闭 minifyEnabled 可以证明方向，但不能作为长期方案。release 包完全关闭 R8，会损失包体、启动和一定程度的反编译干扰收益。

更合理的做法是给 Facebook SDK 相关类加保留规则。也就是告诉 R8：这些类可能会被 SDK 通过动态方式使用，不要删，不要改名，也不要重写它们的结构。

在 android/app/proguard-rules.pro 里加入：

# Facebook SDK 相关类保留。
# 这里范围偏宽，适合先恢复生产行为，再根据实际依赖逐步收窄。
-keep class com.facebook.** { *; }
-keep interface com.facebook.** { *; }
-keep enum com.facebook.** { *; }

# 如果项目接入了 Google Ads 的 Facebook mediation，再保留这个 adapter。
-keep class com.google.ads.mediation.facebook.FacebookAdapter { *; }

# AppEvents 场景下显式保留日志入口。
# 这条在 com.facebook.** 已经存在时有一定重复，但可以表达规则意图。
-keep public class com.facebook.appevents.AppEventsLogger { *; }

同时确认 release 构建确实加载了这个规则文件：

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

如果项目使用的是 Kotlin DSL，大致对应为：

android {
    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro",
            )
        }
    }
}

修改以后再打 release 包验证，Facebook 后台重新出现购买和订阅事件。

keep 规则的取舍

这里有一个需要注意的点：-keep class com.facebook.** { *; } 是一个偏宽的规则。

它的好处是直接、稳定，适合在问题已经影响业务数据时快速恢复。它的代价是 R8 对 com.facebook 包下代码的优化空间会变小。对大多数 App 来说，这个代价通常比丢购买/订阅事件更可接受，但它依然是一个工程取舍。

更理想的路径是分两步：

1. 先用较宽的 keep 规则恢复行为，确认问题确实来自 R8；
2. 后续如果对包体极其敏感，再结合实际 SDK 版本、mapping、R8 配置分析，把规则收窄到真正需要保留的类。

也就是说，不要因为一个 SDK 出问题就长期关掉整个 release 优化；也不要一开始就追求极窄规则，导致验证周期被拉长。先恢复数据正确性，再优化规则边界。

这次排查里真正有用的判断

我觉得这次最有价值的不是最后那几行 ProGuard 规则，而是排查顺序。

先不要把“后台没有购买/订阅数据”直接等同于“埋点代码没执行”。事件上报链路很长，中间任何一层都可能吞掉结果。Flutter 层、插件桥、Android 原生 SDK、网络队列、后台展示延迟都可能制造类似现象。

但这次 debug/profile 正常、release 有安装事件却没有购买/订阅事件，已经给了一个很强的信号：SDK 基础链路存在，问题更可能出在 release 产物里的特定事件路径。于是临时关闭 minifyEnabled 和 shrinkResources 就成了一个很有效的实验。

这个实验的价值不是“直接修复”，而是把问题域从一整条业务链路缩小到 R8。问题域一旦缩小，解决方案就清晰了：不要改业务调用，不要绕 SDK，而是补 keep 规则。

可复用的检查清单

以后遇到类似“只在 release 包失效”的 SDK 问题，可以按这个顺序排：

1. 确认同一份业务代码在 debug/profile 是否稳定正常；
2. 用 release 签名包复现，不要只依赖 debug 包；
3. 区分 SDK 是整体不可用，还是只有某些事件类型缺失；
4. 抓包时先看是否有目标域名请求，但不要在 SSL 拦截失败时过度解读 payload；
5. 检查 minifyEnabled、shrinkResources、proguardFiles；
6. 临时关闭 release 优化，确认问题是否消失；
7. 如果消失，给相关 SDK 增加 keep 规则；
8. 恢复 release 优化，再用正式包验证后台数据；
9. 必要时再收窄 keep 规则，避免过宽规则影响优化收益。

这套方法不只适用于 Facebook App Events。Firebase、AppsFlyer、Adjust、广告 mediation、支付 SDK、登录 SDK，只要内部有反射、动态注册或原生桥接，都可能遇到类似问题。

总结

这次问题表面看是 facebook_app_events 在 Android release 包里不上报购买/订阅事件，更准确地说，是 SDK 仍然能产生安装相关事件和 Facebook 域名请求，但购买/订阅这条 AppEvents 链路失效。本质上，还是 release 构建优化改变了 SDK 运行时依赖的代码结构。

最终处理思路是：

1. 先证明不是业务调用和后台基础配置问题；
2. 再通过安装事件和抓包观察排除“SDK 完全不可用”；
3. 然后用关闭 release 优化的方式定位到 R8；
4. 最后用 Facebook SDK 的 keep 规则修复，而不是长期关闭 minifyEnabled。

对线上埋点来说，release 验证本身就是发布流程的一部分。尤其是购买、订阅、归因这类会影响投放和收入判断的数据，不能只看 debug 包是否正常。只要现象呈现出明显的 release-only 特征，就应该尽早把 R8 和 keep 规则纳入排查范围。

延伸阅读

• Enable app optimization with R8
• About keep rules
• Optimization for library authors