写在前面在崩溃治理里，有一类崩溃最让人抓狂：代码逻辑挑不出毛病，主流机型跑得好好的；崩溃栈要么在系统库（libc、libbinder、framework），要么干脆没有你的代码；但崩溃量就是下不去，而且高度集中在某个 Android 版本，或某个厂商的 ROM 上。这就是系统/ROM 兼容性崩溃。安卓生态的碎片化——十几个大版本、几十家厂商的深度定制 ROM——让"同一份包在不同系统上行为不一致"成为常态。它的排查逻辑和逻辑 bug 完全不同：不是"我的代码错在哪"，而是"哪些系统/ROM 对我的用法有特殊对待"。而破案的第一把钥匙，就是 Bugly 里的两个字段：系统版本号和厂商 ROM。这篇文章专讲怎么用好这两个信号。一、先建立认知：碎片化从哪来1.1 两条正交的碎片化维度维度一：Android 大版本（AOSP 行为差异） Android 6 → 7 → 8 → 9 → 10 → 11 → 12 → 13 → 14 每个版本都有 API 行为变更、权限收紧、后台限制加严 维度二：厂商 ROM（在 AOSP 上的深度定制） EMUI/HarmonyOS（华为）、MIUI/HyperOS（小米）、 ColorOS（OPPO）、O