Sentry 的崩溃监控集成，比 Firebase 差在哪

Sentry 的崩溃监控集成，比 Firebase 差在哪

去年把公司项目的崩溃监控从 Firebase Crashlytics 迁移到 Sentry 时，我遇到过一个非常具体的坑。线上报了一个 SIGSEGV 的 native crash，Sentry 的 issue 页面里只显示了一串十六进制偏移量和一个 libapp.so 的引用，完全无法定位。同一时间段 Firebase 后台里同样的崩溃却直接还原到了具体的 C++ 行号。原因很直白：Firebase Crashlytics 和 Google Play 的符号表体系是打通的，而 Sentry 需要你自己搭建符号上传流水线，这个环节漏了，监控就只剩下一半。

这件事让我意识到，Sentry 和 Firebase 的差异不是简单的"谁功能多"，而是产品哲学和生态位的问题。Firebase 是 Google 移动生态的附属品，深度绑定了 Play 商店、Android Gradle Plugin 和 Google Cloud。Sentry 是一个独立的第三方崩溃监控厂商，它要跨平台、要自托管、要深度可定制，这些优势在 Android 平台上反而带来了额外的集成成本。接下来我想聊的，就是我在实际集成 Sentry Android SDK 7.x 系列过程中，觉得它明确比 Firebase Crashlytics 差在哪，以及它又有哪些不可替代的长板。

Sentry 的定价现实：不是免费午餐

谈论工具选型，价格绕不开。Firebase Crashlytics 在 Spark 计划里完全免费，没有明确的 event 数量上限，只对过于夸张的用量发出提醒。Sentry 的定价则直接得多：免费层每月 5000 个 error event，且只保留 30 天数据