1. Android SDK适配概述：为何需要适配、适配的基本原则、Android碎片化现状、适配范围
各位同学，欢迎来到这门课。我是你们在Android适配路上的同行者。说实话，我入行那会儿，还是Android 2.3和4.0混战的时代。那时候适配，主要就盯着屏幕尺寸和分辨率。现在呢？情况复杂了太多。这第一章，咱们先把最基本的问题讲清楚——适配到底是什么？我们为什么要干这件事？
1.1 为何需要适配
你写一个App，在自己的测试机上跑得飞起。换一部手机，可能就闪退、布局乱掉、按钮点不到。为什么会这样？因为Android生态太开放了。开放带来自由，也带来碎片化。
适配，说白了就是让你的App在千奇百怪的设备上，都能正常跑起来，并且体验不差。这不是加分项，而是及格线。
我见过最惨的例子：一个金融类App，只适配了主流屏幕比例。结果在18:9的全面屏手机上，底部“确认支付”按钮被虚拟导航栏挡住了一半。用户点不到，直接打客服投诉。上线一周，差评如潮。适配没做好，损失的不光是用户体验，还有真金白银。
总结了几个核心原因：
- 设备多样性：屏幕尺寸、分辨率、DPI，千差万别
- 系统版本割裂：从Android 4.4到Android 14，共存于市面
- 厂商定制ROM：小米、华为、OPPO、vivo…每家都有自己的行为逻辑
- API行为变更：高版本废弃旧API，甚至改变运行行为
- 硬件差异：CPU架构、内存大小、GPU能力都不一样
1.2 适配的基本原则
我个人习惯把适配原则归成三条。你记住了，后面所有的具体操作，都在往这三条上靠。
- 向前兼容，向后兼容
- 新写的代码不能在旧系统上崩溃
- 旧版本的API不能被粗暴删除，要优雅废弃
- 体验一致，但不强求完全一致
- 核心功能、核心流程在所有设备上保持一致
- 边缘交互、视觉效果，允许合理差异（比如折叠屏和直板机）
- 灰度验证，逐步放量
- 不要一次性覆盖所有设备，先挑小众机型/系统版本测试
- 收集用户反馈，修复问题，再扩大适配范围
一点经验：别想在开发阶段就把所有设备适配完。你做不到，也不需要。重点是一开始就建立好适配的框架，让后续迭代的成本可控。我在早期项目里，把兼容代码和各种机型判断到处乱写，后期想改都找不到地方。后来才学会用策略模式和接口抽象来隔离变化。
1.3 Android碎片化现状
你想想看，一个操作系统在成千上万种硬件上跑，系统版本从4.x到14.x都有活跃用户。这就是碎片化。它直接影响你的开发和测试成本。
我直接给几个数据，这些都是2024年年初的真实统计：
| 维度 | 现状 | 对适配的影响 |
|---|---|---|
| 系统版本 | Android 11/12/13/14共存，Android 10及以下仍有10%+存量 | 需要处理动态权限、存储分区、后台限制等行为差异 |
| 屏幕尺寸 | 4.7英寸到7.6英寸（折叠屏），横竖屏切换 | 布局要支持多屏、多方向、多分辨率密度 |
| 屏幕比例 | 16:9、18:9、19.5:9、21:9、折叠屏内屏展开接近1:1 | 必须处理刘海、挖孔、安全区域、状态栏重叠 |
| CPU架构 | arm64-v8a一枝独秀，但armeabi-v7a仍有老旧设备 | so库打包策略，要么全包，要么版本检测降级 |
| 厂商ROM | 小米MIUI、华为HarmonyOS/EMUI、OPPO ColorOS 等 | 推送通道、权限弹窗、后台保活行为各不同 |
为什么会这样？Android开源，厂商可以自由定制。硬件更是百花齐放。这局面短期内不会改变。我们做适配的，只能接受它，然后找办法应对。
一个事实：你在Google Play Console上，可能看到的系统版本分布还算集中。但在国内，因为各种原因，用户升级意愿低，老版本留存率明显更高。所以，国内的适配任务，通常比海外要重。
1.4 适配范围：屏幕、系统、API等
适配不是一件事，是一整套事。我习惯把适配范围分成三个层面：
1.4.1 屏幕适配
这是最直观的，也是最早遇到的问题。
- 分辨率：从ldpi到xxxhdpi，每种密度下图片资源要准备几套？怎么裁剪最省空间？
- 尺寸：dp和sp的使用规则；ConstraintLayout和百分比布局怎么用
- 刘海屏/挖孔屏/全面屏：安全区域、状态栏沉浸、窗口化布局
- 折叠屏：连续性适配、屏幕折叠状态监听、不同姿态下的交互优化
1.4.2 系统版本适配
这个是头疼的事。每个大版本都可能引入破坏性变更。
- Android 6.0 (API 23)：运行时权限，以前不需要的现在要弹窗请求
- Android 7.0 (API 24)：文件访问限制，FileProvider闪亮登场
- Android 8.0 (API 26)：通知渠道、后台服务限制
- Android 9.0 (API 28)：非SDK接口限制、明文HTTP限制
- Android 10 (API 29)：分区存储、后台Activity启动限制
- Android 11 (API 30)：软件包可见性、一次性权限、后台位置权限更严格
- Android 12 (API 31)：更精确的剪贴板访问提示、启动画面SplashScreen
- Android 13 (API 33)：通知运行时权限、主题图标
- Android 14 (API 34)：更严格的隐式Intent、前台服务类型要求
避坑指南：不要直接拿targetSdkVersion往最新版本跳。我曾经在某个项目里，为了图省事，直接targetSdkVersion=34，结果分区存储的适配没做全，文件上传功能直接崩了。建议做法是：先小范围灰度，确定没问题了再全量覆盖。
1.4.3 API适配
这块更细，涉及到SDK本身和系统API的变化。
- SDK版本平滑升级：compileSdkVersion、targetSdkVersion、minSdkVersion三个值怎么搭配
- API废弃与替代：比如AsyncTask废了，要迁移到协程或ThreadPool；SharedPreferences不推荐大规模使用，Room才是正确的方向
- 第三方SDK兼容：接入的广告、推送、分享等SDK，也要跟着系统版本升级，否则会互相打架
为了让你对这章的知识结构有个整体印象，我画了一张图。你看看，一目了然。
一个小提醒：
minSdkVersion不是越低越好。定得太低，意味着你要处理很多老旧API的兼容代码，反而增加维护成本。我个人建议，2025年的新项目，minSdkVersion至少设在API 24（Android 7.0）以上。理由？API 24以下，系统安全性、分区存储、权限模型都差很多，而且用户占比已经很低了。
好了，这一章的内容就这么多。我们把“为什么要做适配”、“适配的基本原则”、“碎片化现状”和“适配范围”都理清楚了。后面的章节，咱们就拿着这些概念，深入到具体的适配技术里去。每一条都是实战经验，你可别走神啊。