2、机型兼容测试基础：屏幕尺寸、分辨率、DPI、系统版本、厂商定制差异的核心概念
做动态化交付最头疼的是什么？不是代码写不出来，而是同一套页面在不同手机上「长」得不一样。我入行那会儿，光一个按钮在iPhone 4和三星Note 2上就完全对不齐，改了一整夜布局。说白了，你要搞定机型兼容，必须先搞清楚这几个基础概念：屏幕尺寸、分辨率、DPI、系统版本和厂商定制差异。它们就像五根支柱，支撑着整个兼容测试体系。今天我就用实际踩过的坑，给你拆开揉碎讲清楚。
屏幕尺寸：不仅仅是「几英寸」
很多人觉得屏幕尺寸就是对角线长度，知道这个就够了。我在一次交付测试中，同一个页面在5.5寸手机和7寸平板上，图片大小失比例，文字换行全乱。为什么会这样？因为屏幕尺寸直接影响物理可视区域的大小。Android碎片化严重，光「4.7寸」就有好几种比例：16:9、18:9、19.5:9……你想想看，一个按钮标注了200px宽，在不同尺寸上表现天差地别。
核心原则：不要依赖像素，尽量用相对单位（dp、sp、百分比）来做布局。
分辨率：像素总量≠显示精细度
分辨率是指屏幕的物理像素总量，比如1920×1080。我见过不少新人以为分辨率越高屏幕就越大——其实不一定。同样的分辨率在5寸屏和6寸屏上，像素密度完全不一样。我曾经用一个小米6（1920×1080，5.15寸）和一个华为P20 Pro（2240×1080，6.1寸）测试同一个页面，小字号文字在小米6上清晰，在P20 Pro上反而有点模糊——因为PPI不同。
做动态化交付时，你拿到的设计稿通常是750×1334（iPhone 6的2倍图）或者1080×1920。我建议你把分辨率作为「兜底参考」，后面结合DPI才能真正判断适配策略。
DPI / PPI：决定视觉密度的关键
DPI（Dots Per Inch）在Android生态里指的是屏幕密度等级（mdpi、hdpi、xhdpi……），而PPI（Pixels Per Inch）是精确物理密度。两者关系密切，但别搞混。在Google的官方文档里，Android用density这个参数来换算：
// 常见的density值
mdpi = 1.0 (160dpi)
hdpi = 1.5 (240dpi)
xhdpi = 2.0 (320dpi)
xxhdpi = 3.0 (480dpi)
xxxhdpi= 4.0 (640dpi)我自己的习惯是拿到一个新机型后，第一件事查它的density和ppi，然后调整UI自适应策略。比如华为Mate 30 Pro的PPI大概409（对应xxhdpi），而iPad mini 5的PPI是326（对应xhdpi）。同一个图片资源在不同密度下会显示为不同物理尺寸，这在动态化渲染时必须提前算好。
实际经验：用window.devicePixelRatio（Web端）或者context.density（原生端）获取设备像素比，然后根据这个值做降级或高清资源加载。
系统版本：API Level的「坑」比你想的多
系统版本不光是功能差，有时还影响布局。我记得有一个项目，在Android 6.0上正常显示的ConstraintLayout，到Android 4.4上直接崩溃——因为API Level不够。还有iOS UIWebView和WKWebView对CSS的解析差异，比如position:fixed在旧版WebView里直接失效。我建议你在测试时至少覆盖三个主要版本：
- Android： 覆盖API Level 19~34，重点测21、23、28、30、33。
- iOS： 覆盖iOS 12、14、16、17（当前主流）。
另外，系统版本也决定了Screen Compatible模式、分屏支持、刘海屏适配等底层行为。我建议把系统版本和厂商定制作为两个独立维度来设计测试用例。
厂商定制：MIUI、EMUI、ColorOS……你得一个一个伺候
厂商定制是兼容测试里的「玄学」。同样的Android 12，小米的MIUI会改掉StatusBar高度，华为的HarmonyOS会屏蔽某些权限，OPPO的ColorOS对WebView的UA做了魔改。我曾经被一个问题折磨了三天：用户反馈华为手机上按钮点不了。后来发现华为的「手势导航」会吃掉底部滑动事件，而我们的动态页面恰好绑定了一个onTouch事件。解决方案就是在onAttachedToWindow时检测是否处于「三键导航」或「手势导航」模式，然后微调交互区域。
避坑指南：测试前务必收集目标用户的设备信息（emui版本、MIUI版本、ColorOS版本），不要只看Android系统版本。厂商定制的webview内核也可能不一样——比如华为有些机型用自研的H5内核，对CSSbackdrop-filter支持不足。
一张表格搞定核心参数对比
我把五个维度的关键参数和测试关注点列成表格，你可以直接拿来当检查清单：
| 维度 | 核心参数 | 测试关注点 |
|---|---|---|
| 屏幕尺寸 | 对角线（英寸） | 布局缩放、可点击区域大小 |
| 分辨率 | 宽×高（px） | 资源加载、高清图降级 |
| DPI / 密度 | density、ppi | 字体大小、图标物理尺寸 |
| 系统版本 | API Level、Build.VERSION.SDK_INT | API差异、渲染引擎、权限变化 |
| 厂商定制 | ROM版本、UA、导航栏模式 | 状态栏高度、手势冲突、webview魔改 |
总结几句话
讲真，这五个概念就像五把钥匙，少一把你的兼容测试都锁死。我个人建议你在做动态化交付之前，先用工具（比如adb shell wm size）抓一下真机参数，然后建立一个「机型库」，每个机型分别记录屏幕尺寸 - 分辨率 - DPI - Android版本 - 厂商ROM版本。测试时对照着跑一遍，大部分问题都能提前暴露。
最后丢一个常用命令，帮你在Android上快速获取这些信息：
adb shell wm size # 获取分辨率
adb shell wm density # 获取density（每160ppi一个单位）
adb shell getprop ro.build.version.sdk # API Level
adb shell getprop ro.build.display.id # 厂商定制版本号嗯，这些底子打好了，我们后面讲具体的动态化适配方案才能站得住脚。记得回去把你的测试机全部收集一下，按表格整理，再做一次冒烟——你会有惊喜的。