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

時間 2019-12-07

標籤屏幕適配方式升級 smallestwidth 限定方案简体版

原文原文鏈接

原文地址: https://www.jianshu.com/p/2ad...java

如下是 騷年你的屏幕適配方式該升級了! 系列文章，歡迎轉發以及分享:git

前言

ok，根據上一篇文章騷年你的屏幕適配方式該升級了!-今日頭條適配方案的承諾，本文是這個系列的第二篇文章，這篇文章會詳細講解 smallestWidth 限定符屏幕適配方案github

瞭解個人朋友必定知道，MVPArms 一直使用的是鴻神的 AndroidAutoLayout 屏幕適配方案，得益於 AndroidAutoLayout 的便捷，因此我對屏幕適配領域研究的不是不少，AndroidAutoLayout 中止維護後，我也一直在找尋着替代方案，直到 今日頭條屏幕適配方案 刷屏，後來又無心間看到了 smallestWidth 限定符屏幕適配方案，這才慢慢的將研究方向轉向了屏幕適配領域框架

最近一個月纔開始慢慢惡補 Android 屏幕適配的相關知識，對這兩個方案也進行了更深刻的研究，能夠說從一個小白慢慢成長而來，因此我明白小白的痛，所以在上一篇文章騷年你的屏幕適配方式該升級了!-今日頭條適配方案中，把 今日頭條屏幕適配方案 講得很是的細，儘可能把每個知識點都描述清晰，深怕小白漏掉每個細節，這篇文章我也會延續上一篇文章的優良傳統，將 smallestWidth 限定符屏幕適配方案 的每個知識點都描述清晰佈局

順便說一句，感謝你們對 AndroidAutoSize 的支持，我只是在上一篇文章中提了一嘴我剛發佈的屏幕適配框架 AndroidAutoSize，還沒給出詳細的介紹和原理剖析 (原計劃在本系列的第三篇文章中發佈)，AndroidAutoSize 就被你們推上了 Github Trending，一個多星期就拿了 2k+ stars，隨着關注度的增長，我在這段時間裏也累壞了，issues 就沒斷過，不到半個月就提交了 200 屢次 commit，但累並快樂着，在這裏要再次感謝你們對 AndroidAutoSize 的承認性能

談談對百分比庫的見解

是這樣的，在上篇文章中有一些兄弟提了一些觀點，我非常認同，可是我站在執行者的角度來看待這個問題，也有一些不一樣的觀點，如下是我在上篇文章中的回覆學習

你們要注意了！這些觀點其實針對的是全部以百分比縮放佈局的庫，而不僅是今日頭條屏幕適配方案，因此這些觀點也一樣適用於 smallestWidth 限定符屏幕適配方案，這點有不少人存在誤解，因此必定要注意！優化

上圖的每個方框都表明一種 Android 設備的屏幕，Android 的 系統碎片化、機型以及屏幕尺寸碎片化、屏幕分辨率碎片化 有多嚴重你們能夠經過 友盟指數 瞭解一下，有些時候在某些事情的決斷標準上，並不能按照事情的對錯來決斷，大多數狀況仍是要分析成本，收益等多種因素，經過利弊來決斷，每一個人的利弊標準又都不同，因此每一個人的觀點也都會有差異，但也都應該獲得尊重，因此我只是說說本身的觀點，也不否定任何人的觀點spa

方案是死的人是活的，在某些大屏手機或平板電腦上，您也能夠採用其餘適配方案和百分比庫結合使用，好比針對某個屏幕區間的設備單獨出一套設計圖以顯示比小屏幕手機更多更精細的內容，來達到與百分比庫互補的效果，沒有一個方案能夠說本身是完美的，但咱們能清晰的認識到不一樣方案的優缺點，將它們的優勢相結合，才能應付更復雜的開發需求，產出最好的產品插件

友情提示: 下面要介紹的 smallestWidth 限定符屏幕適配方案，原理也一樣是按照百分比縮放佈局，理論上也會存在上面所說的 大屏手機和小屏手機顯示的內容相同 的問題，選擇與否請仔細斟酌

簡介 smallestWidth 限定符適配方案

這個方案的的使用方式和咱們平時在佈局中引用 dimens 無異，核心點在於生成 dimens.xml 文件，可是已經有大神幫咱們作了這一步

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-800x480
│   ├── ├──values-860x540
│   ├── ├──values-1024x600
│   ├── ├──values-1024x768
│   ├── ├──...
│   ├── ├──values-2560x1440

若是有人還記得上面這種 寬高限定符屏幕適配方案 的話，就能夠把 smallestWidth 限定符屏幕適配方案 當成這種方案的升級版，smallestWidth 限定符屏幕適配方案 只是把 dimens.xml 文件中的值從 px 換成了 dp，原理和使用方式都是沒變的，這些在上面的文章中都有介紹，下面就直接開始剖析原理，smallestWidth 限定符屏幕適配方案 長這樣👇

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

原理

其實 smallestWidth 限定符屏幕適配方案 的原理也很簡單，開發者先在項目中根據主流屏幕的 最小寬度 (smallestWidth) 生成一系列 values-sw<N>dp 文件夾 (含有 dimens.xml 文件)，當把項目運行到設備上時，系統會根據當前設備屏幕的 最小寬度 (smallestWidth) 去匹配對應的 values-sw<N>dp 文件夾，而對應的 values-sw<N>dp 文件夾中的 dimens.xml 文字中的值，又是根據當前設備屏幕的 最小寬度 (smallestWidth) 而定製的，因此必定能適配當前設備

若是系統根據當前設備屏幕的 最小寬度 (smallestWidth) 沒找到對應的 values-sw<N>dp 文件夾，則會去尋找與之 最小寬度 (smallestWidth) 相近的 values-sw<N>dp 文件夾，系統只會尋找小於或等於當前設備 最小寬度 (smallestWidth) 的 values-sw<N>dp，這就是優於 寬高限定符屏幕適配方案 的容錯率，而且也能夠少生成不少 values-sw<N>dp 文件夾，減輕 App 的體積

什麼是 smallestWidth

smallestWidth 翻譯爲中文的意思就是 最小寬度，那這個 最小寬度 是什麼意思呢？

系統會根據當前設備屏幕的 最小寬度 來匹配 values-sw<N>dp，爲何不是根據寬度來匹配，而要加上最小這兩個字呢？

這就要說到，移動設備都是容許屏幕能夠旋轉的，當屏幕旋轉時，屏幕的高寬就會互換，加上最小這兩個字，是由於這個方案是不區分屏幕方向的，它只會把屏幕的高度和寬度中值最小的一方認爲是 最小寬度，這個 最小寬度 是根據屏幕來定的，是固定不變的，意思是無論您怎麼旋轉屏幕，只要這個屏幕的高度大於寬度，那系統就只會認定寬度的值爲 最小寬度，反之若是屏幕的寬度大於高度，那系統就會認定屏幕的高度的值爲 最小寬度

若是想讓屏幕寬度隨着屏幕的旋轉而作出改變該怎麼辦呢？能夠再根據 values-w<N>dp (去掉 sw 中的 s) 生成一套資源文件

若是想區分屏幕的方向來作適配該怎麼辦呢？那就只有再根據 屏幕方向限定符 生成一套資源文件咯，後綴加上 -land 或 -port 便可，像這樣，values-sw400dp-land (最小寬度 400 dp 橫向)，values-sw400dp-port (最小寬度 400 dp 縱向)

smallestWidth 的值是怎麼算的

要先算出當前設備的 smallestWidth 值咱們才能知道當前設備該匹配哪一個 values-sw<N>dp 文件夾

ok，仍是按照上一篇文章的敘述方式，如今來舉慄說明，幫助你們更好理解

咱們假設設備的屏幕信息是 1920 * 1080、480 dpi

根據上面的規則咱們要在屏幕的高度和寬度中選擇值最小的一方做爲最小寬度，1080 < 1920，明顯 1080 px 就是咱們要找的 最小寬度 的值，但 最小寬度 的單位是 dp，因此咱們要把 px 轉換爲 dp

幫助你們再鞏固下基礎，下面的公式必定不能再忘了！

px / density = dp，DPI / 160 = density，因此最終的公式是 px / (DPI / 160) = dp

因此咱們獲得的 最小寬度 的值是 360 dp (1080 / (480 / 160) = 360)

如今咱們已經算出了當前設備的最小寬度是 360 dp，咱們曉得系統會根據這個 最小寬度 幫助咱們匹配到 values-sw360dp 文件夾下的 dimens.xml 文件，若是項目中沒有 values-sw360dp 這個文件夾，系統纔會去匹配相近的 values-sw<N>dp 文件夾

dimens.xml 文件是整個方案的核心所在，因此接下來咱們再來看看 values-sw360dp 文件夾中的這個 dimens.xml 是根據什麼原理生成的

dimens.xml 生成原理

由於咱們在項目佈局中引用的 dimens 的實際值，來源於根據當前設備屏幕的 最小寬度 所匹配的 values-sw<N>dp 文件夾中的 dimens.xml，因此搞清楚 dimens.xml 的生成原理，有助於咱們理解 smallestWidth 限定符屏幕適配方案

說到 dimens.xml 的生成，就要涉及到兩個因數，第一個因素是 最小寬度基準值，第二個因素就是您的項目須要適配哪些 最小寬度，通俗理解就是須要生成多少個 values-sw<N>dp 文件夾

第一個因素

最小寬度基準值 是什麼意思呢？簡單理解就是您須要把設備的屏幕寬度分爲多少份，假設咱們如今把項目的 最小寬度基準值 定爲 360，那這個方案就會理解爲您想把全部設備的屏幕寬度都分爲 360 份，方案會幫您在 dimens.xml 文件中生成 1 到 360 的 dimens 引用，好比 values-sw360dp 中的 dimens.xml 是長這樣的

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1dp</dimen>
    <dimen name="dp_2">2dp</dimen>
    <dimen name="dp_3">3dp</dimen>
    <dimen name="dp_4">4dp</dimen>
    <dimen name="dp_5">5dp</dimen>
    <dimen name="dp_6">6dp</dimen>
    <dimen name="dp_7">7dp</dimen>
    <dimen name="dp_8">8dp</dimen>
    <dimen name="dp_9">9dp</dimen>
    <dimen name="dp_10">10dp</dimen>
    ...
    <dimen name="dp_356">356dp</dimen>
    <dimen name="dp_357">357dp</dimen>
    <dimen name="dp_358">358dp</dimen>
    <dimen name="dp_359">359dp</dimen>
    <dimen name="dp_360">360dp</dimen>
</resources>

values-sw360dp 指的是當前設備屏幕的 最小寬度 爲 360dp (該設備高度大於寬度，則最小寬度就是寬度，因此該設備寬度爲 360dp)，把屏幕寬度分爲 360 份，恰好每份等於 1dp，因此每一個引用都遞增 1dp，值最大的 dimens 引用 dp_360 值也是 360dp，恰好覆蓋屏幕寬度

下面再來看看將 最小寬度基準值 定爲 360 時，values-sw400dp 中的 dimens.xml 長什麼樣

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1.1111dp</dimen>
    <dimen name="dp_2">2.2222dp</dimen>
    <dimen name="dp_3">3.3333dp</dimen>
    <dimen name="dp_4">4.4444dp</dimen>
    <dimen name="dp_5">5.5556dp</dimen>
    <dimen name="dp_6">6.6667dp</dimen>
    <dimen name="dp_7">7.7778dp</dimen>
    <dimen name="dp_8">8.8889dp</dimen>
    <dimen name="dp_9">10.0000dp</dimen>
    <dimen name="dp_10">11.1111dp</dimen>
    ...
    <dimen name="dp_355">394.4444dp</dimen>
    <dimen name="dp_356">395.5556dp</dimen>
    <dimen name="dp_357">396.6667dp</dimen>
    <dimen name="dp_358">397.7778dp</dimen>
    <dimen name="dp_359">398.8889dp</dimen>
    <dimen name="dp_360">400.0000dp</dimen>
</resources>

values-sw400dp 指的是當前設備屏幕的 最小寬度 爲 400dp (該設備高度大於寬度，則最小寬度就是寬度，因此該設備寬度爲 400dp)，把屏幕寬度一樣分爲 360份，這時每份就等於 1.1111dp 了，每一個引用都遞增 1.1111dp，值最大的 dimens 引用 dp_360 一樣恰好覆蓋屏幕寬度，爲 400dp

經過兩個 dimens.xml 文件的比較，dimens.xml 的生成原理一目瞭然，方案會先肯定 最小寬度基準值，而後將每一個 values-sw<N>dp 中的 dimens.xml 文件都分配與 最小寬度基準值 相同的份數，再根據公式 屏幕最小寬度 / 份數 (最小寬度基準值) 求出每份佔多少 dp，保證無論在哪一個 values-sw<N>dp 中，份數 (最小寬度基準值) * 每份佔的 dp 值 的結果都是恰好覆蓋屏幕寬度，因此在份數不變的狀況下，只須要根據屏幕的寬度在不一樣的設備上動態調整 每份佔的 dp 值，就能完成適配

這樣就能保證無論將項目運行到哪一個設備上，只要當前設備能匹配到對應的 values-sw<N>dp 文件夾，那佈局中的 dimens 引用就能根據當前屏幕的狀況進行縮放，保證能完美適配，若是沒有匹配到對應的 values-sw<N>dp 文件夾，也不要緊，它會去尋找與之相近的 values-sw<N>dp 文件夾，雖然在這種狀況下，佈局中的 dimens 引用的值可能有些許偏差，可是也能保證最大程度的完成適配

說到這裏，那你們就應該就會明白我爲何會說 smallestWidth 限定符屏幕適配方案 的原理也一樣是按百分比進行佈局，若是在佈局中，一個 View 的寬度引用 dp_100，那無論運行到哪一個設備上，這個 View 的寬度都是當前設備屏幕總寬度的 360分之100，前提是項目提供有當前設備屏幕對應的 values-sw<N>dp，若是沒有對應的 values-sw<N>dp，就會去尋找相近的 values-sw<N>dp，這時就會存在偏差了，至於偏差是大是小，這就要看您的第二個因數怎麼分配了

其實 smallestWidth 限定符屏幕適配方案 的原理和 今日頭條屏幕適配方案 挺像的，今日頭條屏幕適配方案 是根據屏幕的寬度或高度動態調整每一個設備的 density (每 dp 佔當前設備屏幕多少像素)，而 smallestWidth 限定符屏幕適配方案 一樣是根據屏幕的寬度動態調整每一個設備 每份佔的 dp 值

第二個因素

第二個因數是須要適配哪些 最小寬度？好比您想適配的 最小寬度 有 320dp、360dp、400dp、411dp、480dp，那方案就會爲您的項目生成 values-sw320dp、values-sw360dp、values-sw400dp、values-sw411dp、values-sw480dp 這幾個資源文件夾，像這樣👇

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

方案會爲您須要適配的 最小寬度，在項目中生成一系列對應的 values-sw<N>dp，在前面也說了，若是某個設備沒有爲它提供對應的 values-sw<N>dp，那它就會去尋找相近的 values-sw<N>dp，但若是這個相近的 values-sw<N>dp 與指望的 values-sw<N>dp 差距太大，那適配效果也就會大打折扣

那是否是 values-sw<N>dp 文件夾生成的越多，覆蓋越多市面上的設備，就越好呢？

也不是，由於每一個 values-sw<N>dp 文件夾其實都會佔用必定的 App 體積，values-sw<N>dp 文件夾越多，App 的體積也就會越大

因此必定要合理分配 values-sw<N>dp，以越少的 values-sw<N>dp 文件夾，覆蓋越多的機型

驗證方案可行性

原理講完了，咱們仍是按照老規矩，來驗證一下這個方案是否可行？

假設設計圖總寬度爲 375 dp，一個 View 在這個設計圖上的尺寸是 50dp * 50dp，這個 View 的寬度佔整個設計圖寬度的 13.3% (50 / 375 = 0.133)

在使用 smallestWidth 限定符屏幕適配方案 時，須要提供 最小寬度基準值 和須要適配哪些 最小寬度，咱們就把 最小寬度基準值 設置爲 375 (和 設計圖 一致)，這時方案就會爲咱們須要適配的 最小寬度 生成對應的 values-sw<N>dp 文件夾，文件夾中的 dimens.xml 文件是由從 1 到 375 組成的 dimens 引用，把全部設備的屏幕寬度都分爲 375 份，因此在佈局文件中咱們應該把這個 View 的高寬都引用 dp_50

下面就來驗證下在使用 smallestWidth 限定符屏幕適配方案 的狀況下，這個 View 與屏幕寬度的比例在分辨率不一樣的設備上是否還能保持和設計圖中的比例一致

驗證設備 1

設備 1 的屏幕總寬度爲 1080 px，屏幕總高度爲 1920 px，DPI 爲 480

設備 1 的屏幕高度大於屏幕寬度，因此 設備 1 的 最小寬度 爲屏幕寬度，再根據公式 px / (DPI / 160) = dp，求出 設備 1 的 最小寬度 的值爲 360 dp (1080 / (480 / 160) = 360)

根據 設備 1 的 最小寬度 應該匹配的是 values-sw360dp 這個文件夾，假設 values-sw360dp 文件夾及裏面的 dimens.xml 已經生成，且是按 最小寬度基準值 爲 375 生成的，360 / 375 = 0.96，因此每份佔的 dp 值爲 0.96，dimens.xml 裏面的內容是長下面這樣的👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">0.96dp</dimen>
    <dimen name="dp_2">1.92dp</dimen>
    <dimen name="dp_3">2.88dp</dimen>
    <dimen name="dp_4">3.84dp</dimen>
    <dimen name="dp_5">4.8dp</dimen>
    ...
    <dimen name="dp_50">48dp</dimen>
    ...
    <dimen name="dp_371">356.16dp</dimen>
    <dimen name="dp_372">357.12dp</dimen>
    <dimen name="dp_373">358.08dp</dimen>
    <dimen name="dp_374">359.04dp</dimen>
    <dimen name="dp_375">360dp</dimen>
</resources>

能夠看到這個 View 在佈局中引用的 dp_50，最終在 values-sw360dp 中定格在了 48 dp，因此這個 View 在 設備 1 上的高寬都爲 48 dp，系統最後會將高寬都換算成 px，根據公式 dp (DPI / 160) = px，因此這個 View 的高寬換算爲 px 後等於 144 px (48 (480 / 160) = 144)

144 / 1080 = 0.133，View 的實際寬度與 屏幕總寬度 的比例和 View 在設計圖中的比例一致 (50 / 375 = 0.133)，因此完成了等比例縮放

某些設備的高寬是和 設備 1 相同的，可是 DPI 可能不一樣，而因爲 smallestWidth 限定符屏幕適配方案 並無像 今日頭條屏幕適配方案 同樣去自行修改 density，因此係統就會使用默認的公式 DPI / 160 求出 density，density 又會影響到 dp 和 px 的換算，所以 DPI 的變化，是有可能會影響到 smallestWidth 限定符屏幕適配方案 的

因此咱們再來試試在這種特殊狀況下 smallestWidth 限定符屏幕適配方案 是否也能完成適配

驗證設備 2

設備 2 的屏幕總寬度爲 1080 px，屏幕總高度爲 1920 px，DPI 爲 420

設備 2 的屏幕高度大於屏幕寬度，因此 設備 2 的 最小寬度 爲屏幕寬度，再根據公式 px / (DPI / 160) = dp，求出 設備 2 的 最小寬度 的值爲 411.429 dp (1080 / (420 / 160) = 411.429)

根據 設備 2 的 最小寬度 應該匹配的是 values-sw411dp 這個文件夾，假設 values-sw411dp 文件夾及裏面的 dimens.xml 已經生成，且是按 最小寬度基準值 爲 375 生成的，411 / 375 = 1.096，因此每份佔的 dp 值爲 1.096，dimens.xml 裏面的內容是長下面這樣的👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1.096dp</dimen>
    <dimen name="dp_2">2.192dp</dimen>
    <dimen name="dp_3">3.288dp</dimen>
    <dimen name="dp_4">4.384dp</dimen>
    <dimen name="dp_5">5.48dp</dimen>
    ...
    <dimen name="dp_50">54.8dp</dimen>
    ...
    <dimen name="dp_371">406.616dp</dimen>
    <dimen name="dp_372">407.712dp</dimen>
    <dimen name="dp_373">408.808dp</dimen>
    <dimen name="dp_374">409.904dp</dimen>
    <dimen name="dp_375">411dp</dimen>
</resources>

能夠看到這個 View 在佈局中引用的 dp_50，最終在 values-sw411dp 中定格在了 54.8dp，因此這個 View 在 設備 2 上的高寬都爲 54.8 dp，系統最後會將高寬都換算成 px，根據公式 dp (DPI / 160) = px，因此這個 View 的高寬換算爲 px 後等於 143.85 px (54.8 (420 / 160) = 143.85)

143.85 / 1080 = 0.133，View 的實際寬度與 屏幕總寬度 的比例和 View 在設計圖中的比例一致 (50 / 375 = 0.133)，因此完成了等比例縮放

雖然 View 在 設備 2 上的高寬是 143.85 px，比 設備 1 的 144 px 少了 0.15 px，可是偏差很是小，總體的比例並無發生太大的變化，是徹底能夠接受的

這個偏差是怎麼引發的呢，由於 設備 2 的 最小寬度 的實際值是 411.429 dp，可是匹配的 values-sw411dp 捨去了小數點後面的位數 (切記！系統會去尋找小於或等於 411.429 dp 的 values-sw<N>dp，因此 values-sw412dp 這個文件夾，設備 2 是匹配不了的)，因此才存在了必定的偏差，所以上面介紹的第二個因數是很是重要的，這直接決定偏差是大仍是小

能夠看到即便在高寬同樣但 DPI 不同的設備上，smallestWidth 限定符屏幕適配方案 也能完成等比例適配，證實這個方案是可行的，若是你們還心存疑慮，也能夠再試試其餘分辨率的設備，其實到最後得出的比例都是在 0.133 左右，惟一的變數就是第二個因數，若是您生成的 values-sw<N>dp 與設備實際的 最小寬度 差異不大，那偏差也就在能接受的範圍內，若是差異很大，那就直接 GG

優勢

很是穩定，極低機率出現意外
不會有任何性能的損耗
適配範圍可自由控制，不會影響其餘三方庫
在插件的配合下，學習成本低

缺點

在佈局中引用 dimens 的方式，雖然學習成本低，可是在平常維護修改時較麻煩
侵入性高，若是項目想切換爲其餘屏幕適配方案，由於每一個 Layout 文件中都存在有大量 dimens 的引用，這時修改起來工做量很是巨大，切換成本很是高昂
沒法覆蓋所有機型，想覆蓋更多機型的作法就是生成更多的資源文件，但這樣會增長 App 體積，在沒有覆蓋的機型上還會出現必定的偏差，因此有時須要在適配效果和佔用空間上作一些抉擇
若是想使用 sp，也須要生成一系列的 dimens，致使再次增長 App 的體積
不能自動支持橫豎屏切換時的適配，如上文所說，若是想自動支持橫豎屏切換時的適配，須要使用 values-w<N>dp 或 屏幕方向限定符 再生成一套資源文件，這樣又會再次增長 App 的體積
不能以高度爲基準進行適配，考慮到這個方案的名字自己就叫 最小寬度限定符適配方案，因此在使用這個方案以前就應該要知道這個方案只能以寬度爲基準進行適配，爲何如今的屏幕適配方案只能以高度或寬度其中的一個做爲基準進行適配，請看這裏

使用中的問題

這時有人就會問了，設計師給的設計圖只標註了 px，使用這個方案時，那不是還要先將 px 換算成 dp？

其實也能夠不用換算的，那這是什麼騷操做呢？

很簡單，你把設計圖的 px 總寬度設置成 最小寬度基準值 就能夠了，仍是之前面驗證可行性的例子

咱們在前面驗證可行性時把 最小寬度基準值 設置成了 375，爲何是 375 呢？由於設計圖的總寬度爲 375 dp，若是換算成 px，總寬度就是 750 px，咱們這時把 最小寬度基準值 設置成 750，而後看看 values-sw360dp 中的 dimens.xml 長什麼樣👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="px_1">0.48dp</dimen>
    <dimen name="px_2">0.96dp</dimen>
    <dimen name="px_3">1.44dp</dimen>
    <dimen name="px_4">1.92dp</dimen>
    <dimen name="px_5">2.4dp</dimen>
    ...
    <dimen name="px_50">24dp</dimen>
    ...
    <dimen name="px_100">48dp</dimen>
    ...
    <dimen name="px_746">358.08dp</dimen>
    <dimen name="px_747">358.56dp</dimen>
    <dimen name="px_748">359.04dp</dimen>
    <dimen name="px_749">359.52dp</dimen>
    <dimen name="px_750">360dp</dimen>
</resources>

360 dp 被分紅了 750 份，相比以前的 375 份，如今 每份佔的 dp 值 正好減小了一半，還記得在驗證可行性的例子中那個 View 的尺寸是多少嗎？50dp 50dp，若是設計圖只標註 px，那這個 View 在設計圖上的的尺寸應該是 100px 100px，那咱們直接根據設計圖上標註的 px，想都不用想直接在佈局中引用 px_100 就能夠了，由於在 375 份時的 dp_50 恰好等於 750 份時的 px_100 (值都是 48 dp)，因此這時的適配效果和以前驗證可行性時的適配效果沒有任何區別