一、問題背景

最近在做項目適配時，我遇到了一個非常詭異的問題：
我的應用需要適配不同尺寸的手表屏幕，因此我在 res/ 目錄下為不同設備準備了多份 dimens.xml 文件，例如：

res/
 ├── values/
 ├── values-w320dp-h374dp/
 ├── values-w360dp-h390dp/
 ├── values-w388dp-h450dp/

大多數設備都能正確匹配各自的 dimens 文件，唯獨一臺 120dpi、分辨率為 240×280 px 的設備始終無法命中對應的 values-w320dp-h374dp。
安裝后應用總是加載默認的 values/ 文件，看似 Android 完全忽略了那一份適配資源。

二、我一開始的誤區

起初我以為問題出在 DPI 與分辨率不匹配，
但因為我在文件夾名里已經用的是 dp，而不是 px，理論上系統應該能自動計算出相應的邏輯尺寸。
可事實證明：Android 的資源匹配邏輯并不是簡單地用公式換算出來的 dp 值。

三、真正的原因：screenWidthDp 與 screenHeightDp

Android 在匹配諸如 values-wXXXdp-hXXXdp 的目錄時，并不是用分辨率直接換算，而是用系統內部維護的兩個配置字段：

Configuration.screenWidthDp
Configuration.screenHeightDp

這兩個值代表當前屏幕在 邏輯 dp 下的“可用區域”，
是系統根據 densityDpi、方向、系統欄、可用窗口等綜合計算出來的整數值。
——注意，是 整數值！

四、計算過程舉例（關鍵）

我們那臺 120dpi 的設備分辨率為 240×280 px。

Android 的換算公式為：

dp = px × 160 / densityDpi

計算得：

寬度：240 × (160 / 120) = 320.0 dp
高度：280 × (160 / 120) = 373.3 dp

? 寬度是 320dp，剛好對上；
? 高度是 373.3dp，不到 374dp。

而 Configuration.screenHeightDp 在系統中是取整后的整數（通常向下取整），
所以系統認為該設備的可用高度是 373dp，而不是 374dp。

因此：

values-w320dp-h374dp   ? 不匹配
values-w320dp-h373dp   ? 完美匹配

五、驗證方法

可以在任意 Activity 中打印出系統真實使用的邏輯尺寸：

Configuration c = getResources().getConfiguration();
Log.i("ScreenDP", "screenWidthDp=" + c.screenWidthDp + ", screenHeightDp=" + c.screenHeightDp);

輸出結果類似：

screenWidthDp=320, screenHeightDp=373

這兩個值才是 Android 資源選擇系統真正參考的指標。

六、如何正確適配

? 方法一：根據實際 screenWidthDp / screenHeightDp 創建目錄

在每個目標設備上打印這兩個值，然后根據結果命名目錄：

values-w320dp-h373dp/
values-w360dp-h390dp/
values-w388dp-h450dp/

? 方法二：使用 swNNNdp（最小寬度）適配

swNNNdp（smallest width）基于設備最小邊的 dp 尺寸，不受方向和系統欄影響，更穩妥：

values-sw320dp/
values-sw360dp/
values-sw388dp/

? 方法三：只按寬度區分

如果不同設備只是比例略有差異，可以僅根據寬度劃分目錄，簡化適配。

七、延伸思考：為什么要“向下取整”

Android 在比較匹配條件時，為了避免資源抖動（例如狀態欄隱藏/顯示導致高度輕微變化），會將 dp 尺寸以整數形式存儲。
也就是說即使設備計算出的高度是 373.9dp，系統仍然認為是 373dp。

這也是為什么即便你寫了 374dp，看起來只差 0.1dp，卻完全不會命中的原因。

八、總結

?? 寫在最后

這次經歷讓我重新理解了 Android 的資源匹配邏輯：

“Android 匹配的不是你以為的分辨率，而是系統眼中的邏輯 dp 尺寸?！?/strong>