摘要：下面來看看常見的三種比較成熟的屏幕適配方案，并分析這幾種方案的優劣。屏幕適配方案寬高限定符適配設定一個基準的分辨率，也就是設計圖對應的分辨率，其他分辨率都根據這個基準分辨率來計算，在不同的尺寸文件夾內部，根據該尺寸編寫對應的文件。

Android開發過程中我們常用的尺寸單位有px、dp，還有一種sp一般是用于字體的大小。但是由于px是像素單位，比如我們通常說的手機分辨例如1920*1080都是px的單位。現在Android屏幕分辨率碎片化720x1280、1080x1920、2280x1080，這就造成例如187px會在各個分辨率的機型上都是顯示一樣大小的，那肯定不是我們想要的效果，所以用px單位我們是難以達到適配效果的，那么為什么用dp可以呢？

使用px單位從左到右依次為 480 800、1080 1920、1440 * 2560

使用dp單位從左到右依次為 480 800、1080 1920、1440 * 2560

屏幕總寬度依次為 320dp、415dp、411dp

dp指的是設備獨立像素，以dp為尺寸單位的控件，在不同分辨率和尺寸的手機上代表了不同的真實像素，比如在分辨率較低的手機中，可能1dp=1px,而在分辨率較高的手機中，可能1dp=2px，這樣的話，一個187dp高度的控件，在不同的手機中就能表現出差不多的大小了。

android中的dp在渲染前會將dp轉為px，計算公式：

px = density * dp;

density = dpi / 160;

px = dp * (dpi / 160);

而dpi是根據屏幕真實的分辨率和尺寸來計算的，每個設備都可能不一樣的。

由于density不是固定不變的，所以每個分辨率不同的設備他們的density都肯定不相等，這樣就會造成每個設備的寬/高對應的總dp都是不同的，假設480 800分辨率的density是1.5，1080 1920分辨率的density是2.6，1440 * 2560分辨率的density是3.5。那么它們對應的寬度總dp = (寬度px) / density，分別為320dp、415dp、411dp。可以看出單位為dp的時候三個設備之間的差距就不是很大了，但是這樣肯定還是不能滿足我們對屏幕適配的要求的。下面來看看Android常見的三種比較成熟的屏幕適配方案，并分析這幾種方案的優劣。

設定一個基準的分辨率，也就是設計圖對應的分辨率，其他分辨率都根據這個基準分辨率來計算，在不同的尺寸文件夾內部，根據該尺寸編寫對應的dimens文件。

比如我們的設計圖 375 * 667為基準分辨率

寬度為375，將任何分辨率的寬度整分為375份，取值為x1-x375

高度為667，將任何分辨率的高度整分為667份，取值為y1-y667

那么對于1080*1920的分辨率的dimens文件來說，

x1=(1080/375)*1=2.88px

x2=(1080/375)*2=5.76px

y1=(1920/667)*1=2.87px

y2=(1920/667)*2=5.75px

當代碼里面引用高度為y_187，在APP運行時會根據當前設備分辨率去找對應xml文件中對應的高度，我們就可以按照設計稿上的尺寸填寫相對應的dimens引用了，這樣基本解決了我們的適配問題，而且極大的提升了我們UI開發的效率。

簡單通過計算驗證下這種方案是否能達到適配的效果，例如設計圖上有一個寬187dp的View。

480 * 800

設計圖占寬比: 187dp / 375dp = 0.498

實際在480 800占寬比 = 187 1.28px / 480 = 0.498

1080 * 1920

設計圖占寬比: 187dp / 375dp = 0.498

實際在1080 1920占寬比 = 187 2.88px / 1080 = 0.498

計算高同理

但是這個方案有一個致命的缺陷，那就是需要精準命中才能適配，比如1920x1080的手機就一定要找到1920x1080的限定符，否則就只能用統一的默認的dimens文件了。而使用默認的尺寸的話，UI就很可能變形，簡單說，就是容錯機制很差。

smallestWidth適配，或者叫sw限定符適配。指的是Android會識別屏幕可用高度和寬度的最小尺寸的dp值（其實就是手機的寬度值），然后根據識別到的結果去資源文件中尋找對應限定符的文件夾下的資源文件。

這種機制和上文提到的寬高限定符適配原理上是一樣的，都是系統通過特定的規則來選擇對應的文件。

可以把 smallestWidth 限定符屏幕適配方案 當成這種方案的升級版，smallestWidth 限定符屏幕適配方案 只是把 dimens.xml 文件中的值從 px 換成了 dp，原理和使用方式都是沒變的

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-sw320dp
│   ├── ├──values-sw360dp
│   ├── ├──values-sw400dp
│   ├── ├──values-sw411dp
│   ├── ├──values-sw480dp
│   ├── ├──...
│   ├── ├──values-sw600dp
│   ├── ├──values-sw640dp

1920 * 1080分辨率的手機，dpi為420，我們同樣設置一個View為187dp寬

density = (dpi = 420) / 160 = 2.6

屏幕總寬度dp = 1080 / density = 415

找到文件夾values-sw410dp下的187dp = 204.45dp

通過公式px = density * dp,計算出px = 531.57

算出占屏幕寬度的比例，56.86 / 1080 = 0.492

1440 * 2560分辨率的手機，dpi為560，我們同樣設置一個View為187dp寬

density = (dpi = 420) / 160 = 3.5

屏幕總寬度dp = 1440 / density = 411

找到文件夾values-sw410dp下的187dp = 204.45dp

通過公式px = density * dp,計算出px = 715.57

算出占屏幕寬度的比例，715.57 / 1440 = 0.496

因為識別的文件夾是values-sw410dp的文件夾，但是屏幕寬度為415dp和411dp，所以最后計算出的占比會有一點點誤差，基本可以忽略不計，可以達到相對比較準確的適配效果

非常穩定，極低概率出現意外

不會有任何性能的損耗

適配范圍可自由控制，不會影響其他三方庫

在插件的配合下，學習成本低

侵入性高，在所有地方都需要引用。

還是沒有辦法覆蓋所有的機型分辨率，部分機型可能適配效果還是不佳

不能以高度為基準進行適配

生成很多文件，增大APP體積1~2M

今日頭條屏幕適配方案的核心原理在于，根據以下公式算出 density

默認px = density * dp，也就是屏幕總寬度dp = 屏幕寬度px / density，這個時候我們假設所有設備上的屏幕總寬度dp會等于我們設計圖375dp，那么可以得出一個公式：

density = 屏幕寬度px / 設計圖寬度（375dp）

然后我們通過系統api，將density賦值給系統，拋棄掉系統默認計算density的計算公式。

這樣可以很巧妙的實現屏幕適配，而且侵入性極低，甚至可以忽略不計。

1920 * 1080分辨率的手機，我們同樣設置一個View為187dp寬，設計圖寬度為375dp

density = (屏幕寬度px = 1080) / 375 = 2.88

View寬度 = density * 187dp = 538.56

算出占屏幕寬度的比例，57.6 / 1080 = 0.498

1440 * 2560分辨率的手機，我們同樣設置一個View為187dp寬，設計圖寬度為375dp

density = (屏幕寬度px = 1440) / 375 =3.84

View寬度 = density * 187dp = 718.08

算出占屏幕寬度的比例，718.08 / 1440 = 0.498

可以看出，這種方案是完全沒有誤差的，而且侵入性極低，只需要修改系統的density。雖然修改系統的density屬性會產生一小部分影響，但是基本都是很好解決的。

使用成本非常低，操作非常簡單

侵入性非常低

可適配三方庫的控件和系統的控件

會全局影響APP的控件大小，例如一些第三方庫控件，他們設計的時候可能設計圖尺寸并不是像我們一樣是375dp，這樣就會導致控件大小變形等一些問題。

騷年你的屏幕適配方式該升級了!-SmallestWidth 限定符適配方案

Android 屏幕適配終結者

Android 目前最穩定和高效的UI適配方案

本文發布于薄荷前端周刊，歡迎Watch & Star ★，轉載請注明出處。