兼容测试基础概念：设备四维空间
做Android SDK兼容测试，说白了就是和一台台真实的设备打交道。我常跟团队说一句话：不要相信模拟器，更不要相信你的开发机。
Android生态有多碎？你想想看，屏幕尺寸从3寸跨越到7寸，系统版本从5.0到14并存，芯片有ARM有x86还有64位混血，内存从1GB到16GB不等。这么多变量，SDK要是全凭想象去适配，早晚出事。
这一章，我把最关键的几个维度拆开讲清楚。
屏幕尺寸、系统版本、芯片架构、内存限制——这四大因素就是兼容测试的根基。
一、屏幕尺寸与分辨率适配
第一个要面对的，是屏幕。Android设备的分辨率五花八门，从480×800的入门机到3200×1440的旗舰，dpi从mdpi到xxxhdpi都有。
我个人习惯在测试卡片上标注三个关键参数：物理尺寸（寸）、分辨率（px）、密度（dpi）。少了哪个都不行。举个例子，1080×1920在5寸屏上是FHD，在6.5寸屏上还是FHD，但ppi差了快100，你的UI元素视觉大小完全不同。
SDK层最需要注意的地方：单位转换和数据采样。
- dp/sp转px别用系统常量硬算，低端机上
TypedValue.applyDimension()偶尔会返回不稳定的值 - 图片采样根据
inTargetDensity做，不要直接BitmapFactory.Options.inSampleSize一刀切 - 数据可视化类SDK（图表的点线、热力图）一定要测极小屏——3.5寸设备上文字会挤成一团
我踩过的坑：曾经接手一个定位SDK，地图标注在1080P上显示正常，换到1440×2560的设备上标注偏移了十几个像素。原因就是密度换算时库内部使用了float截断。后来我们统一改成double运算。
二、系统版本与API级别
第二个大坎儿是系统版本。我记得Android 10刚出时，Google强行限制非SDK接口的反射调用，好多第三方SDK直接崩溃。Google Play Console前几年给出过一个数据：全球还有大约6%的设备运行Android 6.0以下。
测试时别只看你工程minSdkVersion写的多少。有的SDK在旧系统上功能降级没问题，但资源文件、权限模型不一样——比如READ_EXTERNAL_STORAGE在Android 10以上要加maxSdkVersion限制。
| API Level | 版本代号 | 核心变更（影响SDK） |
|---|---|---|
| 23 | Android 6.0 | 运行时权限模型引入；ContextCompat.checkSelfPermission成为必需 |
| 26 | Android 8.0 | 后台执行限制；隐式广播限制；NotificationChannel |
| 29 | Android 10 | 非SDK接口灰名单；分区存储；后台定位权限拆分 |
| 30 | Android 11 | 包可见性弹窗；前台服务类型声明；MediaStore写权限收紧 |
| 33 | Android 13 | 通知运行时权限；READ_MEDIA_IMAGES 等细化媒体权限 |
注意：很多SDK在Android 14上遇到SCHEDULE_EXACT_ALARM限制问题。如果你的SDK需要精确定时任务——比如推送心跳、数据上报——系统版本兼容测试必须覆盖这个场景。我曾经见过一个统计SDK一上Android 14就停止上报，排查了两天才发现是闹钟权限没声明。
三、芯片架构与ABI兼容
接下来是芯片架构。这件事在原生代码不多的时候容易被人忽略。但我们的数据分类SDK涉及加密、压缩、本地模型推理——每个都依赖so文件。
Android支持的ABI现在主流的就四种：armeabi-v7a、arm64-v8a、x86、x86_64。模拟器用的几乎都是x86，真机基本都是ARM。你如果把arm64的so扔到模拟器上跑，UnsatisfiedLinkError砸脸上。
我自己的做法：build.gradle里明确指定abiFilters，不搞通配。同时辅助线上crash监控，多盯盯native崩溃。
android {
defaultConfig {
ndk {
// 只保留主流ABI，x86留在debug包用就行
abiFilters 'armeabi-v7a', 'arm64-v8a'
}
}
// 为x86保留debug包（用模拟器调试时有用）
debug {
ndk.abiFilters 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64'
}
}架构兼容测试清单（每次发版前自检）
- arm64-v8a真机跑一遍所有涉及native的功能路径
- x86模拟器上再跑一遍——很多so没编译x86版本，直接报错
- 低端armeabi-v7a设备（比如联发科老芯片）注意浮点性能问题
- 验证
Build.SUPPORTED_ABIS日志输出，确保系统优先选了正确ABI
曾经有个教训：我们SDK里用了一个第三方的图像处理库，只提供了arm64-v8a版本。结果一台华为麒麟970的平板（armeabi-v7a）上直接闪退。从那以后，我在CI里加了ABI扫描脚本——只要发现某个so缺失某个ABI版本，立刻发告警。
四、内存与性能限制
最后聊内存。这一点经常被忽视，但它实际上最致命。低端机系统可用内存可能只有1GB，你的SDK如果缓存个几十MB的加密查表数据，GC分分钟把主线程冻住。
Android系统给每个App的dalvik heap上限其实不一致，我拿一些机器测过——
| 设备类型 | 典型RAM | Dalvik Heap上限 (近似) | 风险点 |
|---|---|---|---|
| 入门机 | 1~2 GB | 64 MB | 频繁GC、OutOfMemory |
| 中端机 | 3~4 GB | 128 MB | 后台杀进程 |
| 旗舰机 | 6~12 GB | 256 MB+ | 系统不杀进程，但用户换机频率低 |
数据分类SDK对内存敏感在哪？
我列几个高频场景：
- 大文件解析：比如一次读几MB的加密数据到byte[]，内存瞬间飙升。必须流式处理，分块读
- 模型加载：TensorFlow Lite模型有的超过10MB，加载完记得释放临时buffer
- 缓存膨胀：多个应用实例同时使用SDK时（比如宿主App用了多进程），每个进程都有一份缓存，内存翻倍
- 线程池：别忘了每个线程都有一块栈内存。默认栈大小1MB，开32个线程就是32MB——低端机扛不住的
特别注意：如果你的SDK在onCreate或初始化阶段大量分配内存，App很可能因为冷启动时间过长被系统或用户标记为“坏应用”。我的经验是：所有大内存分配后移到后台线程去做，并在初始化回调里把进度抛回给宿主。这样既安全，也方便宿主做 loading 界面。
总结一下屏幕尺寸、系统版本、芯片架构、内存限制这四个维度，它们不是相互独立的问题，更像一张织好的网。你单测一个点可能没事，但A × B × C × D的组合一碰撞——崩溃、ANR、数据丢失，什么都有可能来。所以我才说：兼容测试不是挑一台低端机跑一遍就完事的。每一块都得覆盖到。