1. 先说结论

“都是 Android，为什么还要适配？” 因为你面对的不是一个统一运行时，而是：

1. Android 官方版本差异（API 行为随版本变化）。
2. 厂商 ROM 差异（系统策略和默认行为不同）。
3. 硬件差异（相机、传感器、SOC、屏幕形态不同）。
4. 服务生态差异（GMS/HMS、推送通道、应用市场规则不同）。

所以适配不是“前端框架问题”，而是 Android 生态碎片化带来的工程问题。

———

2. ROM 专章：ROM 到底是什么，为什么会影响 App

2.1 ROM 在 Android 语境里的真实含义

在手机行业里，大家说的 ROM 通常不是硬件课里“只读存储器”那个概念。 在 Android 语境下，ROM 更接近 系统固件/系统镜像，可以理解为“手机出厂预装的操作系统发行版”。

例如：

1. 小米手机上的系统发行版（HyperOS/历史 MIUI）。
2. 华为手机上的系统发行版（HarmonyOS/历史 EMUI）。
3. OPPO 的 ColorOS，vivo 的 OriginOS。

这些都属于“厂商 ROM”。

2.2 ROM 和 Android 版本是什么关系

二者不是一回事：

1. Android 版本：Google 定义的基础平台版本，例如 Android 13、14。
2. ROM 版本：厂商在该 Android 基础上做的定制系统版本。

可能出现这种组合： “同样是 Android 14，不同品牌 ROM 行为不同”。

2.3 ROM 里通常被厂商改了什么

ROM 不是只换主题，通常会改很多系统策略：

1. 权限管理中心（弹窗策略、权限分组、默认值）。
2. 省电与进程管理（后台杀进程、自启动限制、白名单）。
3. 通知与推送策略（通知展示、角标、锁屏显示规则）。
4. 系统组件行为（Activity 启动限制、广播限制、后台任务调度）。
5. 预装服务生态（是否有 GMS、是否优先厂商服务）。

这就是“同一份代码，不同品牌表现不一致”的核心原因。

2.4 一个直观例子（Java 工程师视角）

你写了定时同步任务，逻辑完全正确：

1. 在 A 机型上每 15 分钟稳定执行。
2. 在 B 机型上被省电策略延后或冻结。
3. 在 C 机型上用户没开自启动导致任务长期不触发。

业务代码没变，运行环境策略变了。 这和“同 SQL 在不同数据库方言/驱动上的行为差异”非常像。

———

3. App 需要适配的主要方面

3.1 权限与隐私适配

1. 动态权限申请流程差异。
2. 后台定位、通知权限、文件访问权限在不同版本和 ROM 下规则不同。
3. 权限被拒绝后的回退路径要清晰。

3.2 后台保活与任务调度适配

1. 自启动管理差异。
2. 电池优化策略差异。
3. 前台服务、WorkManager、Alarm 在不同设备上的实际触发行为差异。

3.3 推送与通知适配

1. 厂商通道与通用通道并存。
2. 通知渠道、角标、锁屏展示、点击跳转行为差异。
3. 消息“到达率”与“可见率”需要按机型监控。

3.4 UI 与终端形态适配

1. 刘海屏/挖孔屏/全面屏手势的安全区处理。
2. 折叠屏、多窗口、横竖屏切换。
3. 字体缩放、显示大小变化导致布局溢出。

3.5 WebView / Hybrid 适配（你提到 React 的关键点）

1. React/H5 页面在 App 内最终跑在 WebView 容器中。
2. WebView 内核版本差异会影响 JS 能力、渲染表现和性能。
3. JSBridge 调用、回调时序、序列化行为在不同机型上可能不一致。

3.6 硬件能力适配

1. 相机、定位、NFC、蓝牙、指纹、人脸的支持度不同。
2. 必须做“能力探测 + 功能降级”，不能只按品牌写死逻辑。

3.7 性能稳定性适配

1. 中低端机更容易卡顿、OOM、ANR。
2. 厂商系统对后台线程和资源调度策略不同。
3. 需要按机型看崩溃率、启动时长、页面白屏率。

3.8 渠道与合规适配

1. 各应用市场对权限、隐私声明、SDK 合规要求不同。
2. 某些动态能力在不同渠道规则下限制不同。

———

4. 工程上怎么做才可维护

4.1 建适配层，不让业务层到处写品牌判断

1. 业务层只依赖接口。
2. ROM/版本差异收敛到 compat 模块。
3. 品牌判断作为兜底，优先能力探测。

4.2 建设备矩阵与可观测体系

1. 测试矩阵至少覆盖：主流品牌 + 主流 Android 版本 + 高中低端机型。
2. 关键链路埋点：启动、登录、推送到达、权限授权、支付、页面打开。
3. 看板按品牌/机型切片，快速定位“只在某厂商出现”的问题。

4.3 统一降级策略

1. 功能不可用时给用户明确提示和替代路径。
2. 后台能力受限时引导用户到正确设置页。
3. 关键功能失败要可重试、可回滚、可观测。

———

5. 给 Java 工程师的一句话模型

把 Android 厂商适配理解成：

1. Android API 是“标准接口”。
2. 厂商 ROM 是“不同实现 + 不同策略”。
3. 你的 App 要做的是“接口抽象 + 差异隔离 + 失败降级”。

这不是“额外工作”，而是移动端稳定性工程的主体工作之一。

———

6. 总结

Android 厂商适配的本质，是在碎片化系统环境中保证一致业务体验。 ROM 差异是核心变量：它直接决定权限、后台、通知、WebView、性能与合规行为。 真正可长期维护的做法，不是堆 if (brand)，而是建立系统化的适配层与观测能力。