歡迎光臨
每天分享高質量文章

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

作者:JessYan

鏈接:https://juejin.im/post/5ba197e46fb9a05d0b142c62

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

該系列的上一篇文章:

  • 騷年你的屏幕適配方式該升級了!-今日頭條適配方案https://juejin.im/post/5b7a29736fb9a019d53e7ee2

1、前言

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

瞭解我的朋友一定知道,MVPArms 一直使用的是 鴻神 的 AndroidAutoLayout 屏幕適配方案,得益於 AndroidAutoLayout 的便捷,所以我對屏幕適配領域研究的不是很多,AndroidAutoLayout 停止維護後,我也一直在找尋著替代方案,直到 今日頭條屏幕適配方案 刷屏,後來又無意間看到了 smallestWidth 限定符屏幕適配方案,這才慢慢的將研究方向轉向了屏幕適配領域。

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

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

2、談談對百分比庫的看法

是這樣的,在上篇文章中有一些兄弟提了一些觀點,我很是認同,但是我站在執行者的角度來看待這個問題,也有一些不同的觀點,以下是我在上篇文章中的回覆

大家要註意了!這些觀點其實針對的是所有以百分比縮放佈局的庫,而不只是今日頭條屏幕適配方案,所以這些觀點也同樣適用於 smallestWidth 限定符屏幕適配方案,這點有很多人存在誤解,所以一定要註意!

上圖的每一個方框都代表一種 Android 設備的屏幕,Android 的 系統碎片化、機型以及屏幕尺寸碎片化、屏幕解析度碎片化 有多嚴重大家可以通過 友盟指數 瞭解一下,有些時候在某些事情的決斷標準上,並不能按照事情的對錯來決斷,大多數情況還是要分析成本,收益等多種因素,通過利弊來決斷,每個人的利弊標準又都不一樣,所以每個人的觀點也都會有差別,但也都應該得到尊重,所以我只是說說自己的觀點,也不否認任何人的觀點。

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

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

3、簡介 smallestWidth 限定符適配方案

這個方案的的使用方式和我們平時在佈局中取用 dimens 無異,核心點在於生成 dimens.xml 檔案,但是已經有大神幫我們做了這 一步


  • https://www.jianshu.com/p/1302ad5a4b04

├── 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

4、原理

其實 smallestWidth 限定符屏幕適配方案 的原理也很簡單,開發者先在專案中根據主流屏幕的 最小寬度 (smallestWidth) 生成一系列 values-swdp 檔案夾 (含有 dimens.xml 檔案),當把專案運行到設備上時,系統會根據當前設備屏幕的 最小寬度 (smallestWidth) 去匹配對應的 values-swdp 檔案夾,而對應的 values-swdp 檔案夾中的 dimens.xml 文字中的值,又是根據當前設備屏幕的 最小寬度 (smallestWidth) 而定製的,所以一定能適配當前設備。

如果系統根據當前設備屏幕的 最小寬度 (smallestWidth) 沒找到對應的 values-swdp 檔案夾,則會去尋找與之 最小寬度 (smallestWidth) 相近的 values-swdp 檔案夾,系統只會尋找小於或等於當前設備 最小寬度 (smallestWidth) 的 values-swdp,這就是優於 寬高限定符屏幕適配方案 的容錯率,並且也可以少生成很多 values-swdp 檔案夾,減輕 App 的體積。


4.1 什麼是smallestWidth
smallestWidth 翻譯為中文的意思就是 最小寬度,那這個 最小寬度 是什麼意思呢?

系統會根據當前設備屏幕的 最小寬度 來匹配 values-swdp,為什麼不是根據 寬度 來匹配,而要加上 最小 這兩個字呢?

這就要說到,移動設備都是允許屏幕可以旋轉的,當屏幕旋轉時,屏幕的高寬就會互換,加上 最小 這兩個字,是因為這個方案是不區分屏幕方向的,它只會把屏幕的高度和寬度中值最小的一方認為是 最小寬度,這個 最小寬度 是根據屏幕來定的,是固定不變的,意思是不管您怎麼旋轉屏幕,只要這個屏幕的高度大於寬度,那系統就只會認定寬度的值為 最小寬度,反之如果屏幕的寬度大於高度,那系統就會認定屏幕的高度的值為 最小寬度.

如果想讓屏幕寬度隨著屏幕的旋轉而做出改變該怎麼辦呢?可以再根據 values-wdp (去掉 sw 中的 s) 生成一套資源檔案.

如果想區分屏幕的方向來做適配該怎麼辦呢?那就只有再根據 屏幕方向限定符 生成一套資源檔案咯,後綴加上 -land 或 -port 即可,像這樣,values-sw400dp-land (最小寬度 400 dp 橫向),values-sw400dp-port (最小寬度 400 dp 縱向)。


4.2 smallestWidth 的值是怎麼算的


要先算出當前設備的 smallestWidth 值我們才能知道當前設備該匹配哪個 values-swdp 檔案夾。

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-swdp 檔案夾。

dimens.xml 檔案是整個方案的核心所在,所以接下來我們再來看看 values-sw360dp 檔案夾中的這個 dimens.xml 是根據什麼原理生成的。


4.3 dimens.xml 生成原理


因為我們在專案佈局中取用的 dimens 的實際值,來源於根據當前設備屏幕的 最小寬度 所匹配的 values-swdp 檔案夾中的 dimens.xml,所以搞清楚 dimens.xml 的生成原理,有助於我們理解 smallestWidth 限定符屏幕適配方案。

說到 dimens.xml 的生成,就要涉及到兩個因數,第一個因素是 最小寬度基準值,第二個因素就是您的專案需要適配哪些 最小寬度,通俗理解就是需要生成多少個 values-swdp 檔案夾。


4.3.1 第一個因素

最小寬度基準值 是什麼意思呢?簡單理解就是您需要把設備的屏幕寬度分為多少份,假設我們現在把專案的 最小寬度基準值 定為 360,那這個方案就會理解為您想把所有設備的屏幕寬度都分為 360 份,方案會幫您在 dimens.xml 檔案中生成 1 到 360 的 dimens 取用,比如 values-sw360dp 中的 dimens.xml 是長這樣的:



<resources>
    <dimen name="dp_1">1dpdimen>

    <dimen name=“dp_2”>2dpdimen>
    <dimen name=“dp_3”>3dpdimen>
    <dimen name=“dp_4”>4dpdimen>
    <dimen name=“dp_5”>5dpdimen>
    <dimen name=“dp_6”>6dpdimen>
    <dimen name=“dp_7”>7dpdimen>
    <dimen name=“dp_8”>8dpdimen>
    <dimen name=“dp_9”>9dpdimen>
    <dimen name=“dp_10”>10dpdimen>
    …
    <dimen name=“dp_356”>356dpdimen>
    <dimen name=“dp_357”>357dpdimen>
    <dimen name=“dp_358”>358dpdimen>
    <dimen name=“dp_359”>359dpdimen>
    <dimen name=“dp_360”>360dpdimen>
resources>

values-sw360dp 指的是當前設備屏幕的 最小寬度 為 360dp (該設備高度大於寬度,則最小寬度就是寬度,所以該設備寬度為 360dp),把屏幕寬度分為 360 份,剛好每份等於 1dp,所以每個取用都遞增 1dp,值最大的 dimens 取用 dp_360 值也是 360dp,剛好改寫屏幕寬度.

下麵再來看看將 最小寬度基準值 定為 360 時,values-sw400dp 中的 dimens.xml 長什麼樣:



<resources>
    <dimen name="dp_1">1.1111dpdimen>

    <dimen name=“dp_2”>2.2222dpdimen>
    <dimen name=“dp_3”>3.3333dpdimen>
    <dimen name=“dp_4”>4.4444dpdimen>
    <dimen name=“dp_5”>5.5556dpdimen>
    <dimen name=“dp_6”>6.6667dpdimen>
    <dimen name=“dp_7”>7.7778dpdimen>
    <dimen name=“dp_8”>8.8889dpdimen>
    <dimen name=“dp_9”>10.0000dpdimen>
    <dimen name=“dp_10”>11.1111dpdimen>
    …
    <dimen name=“dp_355”>394.4444dpdimen>
    <dimen name=“dp_356”>395.5556dpdimen>
    <dimen name=“dp_357”>396.6667dpdimen>
    <dimen name=“dp_358”>397.7778dpdimen>
    <dimen name=“dp_359”>398.8889dpdimen>
    <dimen name=“dp_360”>400.0000dpdimen>
resources>

values-sw400dp 指的是當前設備屏幕的 最小寬度 為 400dp (該設備高度大於寬度,則最小寬度就是寬度,所以該設備寬度為 400dp),把屏幕寬度同樣分為 360份,這時每份就等於 1.1111dp 了,每個取用都遞增 1.1111dp,值最大的 dimens 取用 dp_360 同樣剛好改寫屏幕寬度,為 400dp.

通過兩個 dimens.xml 檔案的比較,dimens.xml 的生成原理一目瞭然,方案會先確定 最小寬度基準值,然後將每個 values-swdp 中的 dimens.xml 檔案都分配與 最小寬度基準值 相同的份數,再根據公式 屏幕最小寬度 / 份數 (最小寬度基準值) 求出每份占多少 dp,保證不管在哪個 values-swdp 中,份數 (最小寬度基準值) * 每份占的 dp 值 的結果都是剛好改寫屏幕寬度,所以在 份數 不變的情況下,只需要根據屏幕的寬度在不同的設備上動態調整 每份占的 dp 值,就能完成適配。

這樣就能保證不管將專案運行到哪個設備上,只要當前設備能匹配到對應的 values-swdp 檔案夾,那佈局中的 dimens 取用就能根據當前屏幕的情況進行縮放,保證能完美適配,如果沒有匹配到對應的 values-swdp 檔案夾,也沒關係,它會去尋找與之相近的 values-swdp 檔案夾,雖然在這種情況下,佈局中的 dimens 取用的值可能有些許誤差,但是也能保證最大程度的完成適配。

說到這裡,那大家就應該就會明白我為什麼會說 smallestWidth 限定符屏幕適配方案 的原理也同樣是按百分比進行佈局,如果在佈局中,一個 View 的寬度取用 dp_100,那不管運行到哪個設備上,這個 View 的寬度都是當前設備屏幕總寬度的 360分之100,前提是專案提供有當前設備屏幕對應的 values-swdp,如果沒有對應的 values-swdp,就會去尋找相近的 values-swdp,這時就會存在誤差了,至於誤差是大是小,這就要看您的第二個因數怎麼分配了。

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

4.3.2 第二個因素

第二個因數是需要適配哪些 最小寬度?

比如您想適配的 最小寬度 有 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-swdp,在前面也說了,如果某個設備沒有為它提供對應的 values-swdp,那它就會去尋找相近的 values-swdp,但如果這個相近的 values-swdp 與期望的 values-swdp 差距太大,那適配效果也就會大打折扣。

那是不是 values-swdp 檔案夾生成的越多,改寫越多市面上的設備,就越好呢?

也不是,因為每個 values-swdp 檔案夾其實都會占用一定的 App 體積,values-swdp 檔案夾越多,App 的體積也就會越大。

所以一定要合理分配 values-swdp,以越少的 values-swdp 檔案夾,改寫越多的機型。

5、驗證方案可行性

原理講完了,我們還是按照老規矩,來驗證一下這個方案是否可行?

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

在使用 smallestWidth 限定符屏幕適配方案 時,需要提供 最小寬度基準值 和需要適配哪些 最小寬度,我們就把 最小寬度基準值 設置為 375 (和 設計圖 一致),這時方案就會為我們需要適配的 最小寬度 生成對應的 values-swdp 檔案夾,檔案夾中的 dimens.xml 檔案是由從 1 到 375 組成的 dimens 取用,把所有設備的屏幕寬度都分為 375 份,所以在佈局檔案中我們應該把這個 View 的高寬都取用 dp_50

下麵就來驗證下在使用 smallestWidth 限定符屏幕適配方案 的情況下,這個 View 與屏幕寬度的比例在解析度不同的設備上是否還能保持和設計圖中的比例一致


5.1 驗證設備 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 裡面的內容是長下麵這樣的



<resources>
    <dimen name="dp_1">0.96dpdimen>

    <dimen name=“dp_2”>1.92dpdimen>
    <dimen name=“dp_3”>2.88dpdimen>
    <dimen name=“dp_4”>3.84dpdimen>
    <dimen name=“dp_5”>4.8dpdimen>
    …
    <dimen name=“dp_50”>48dpdimen>
    …
    <dimen name=“dp_371”>356.16dpdimen>
    <dimen name=“dp_372”>357.12dpdimen>
    <dimen name=“dp_373”>358.08dpdimen>
    <dimen name=“dp_374”>359.04dpdimen>
    <dimen name=“dp_375”>360dpdimen>
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 限定符屏幕適配方案 是否也能完成適配。


5.2 驗證設備 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 裡面的內容是長下麵這樣的



<resources>
    <dimen name="dp_1">1.096dpdimen>

    <dimen name=“dp_2”>2.192dpdimen>
    <dimen name=“dp_3”>3.288dpdimen>
    <dimen name=“dp_4”>4.384dpdimen>
    <dimen name=“dp_5”>5.48dpdimen>
    …
    <dimen name=“dp_50”>54.8dpdimen>
    …
    <dimen name=“dp_371”>406.616dpdimen>
    <dimen name=“dp_372”>407.712dpdimen>
    <dimen name=“dp_373”>408.808dpdimen>
    <dimen name=“dp_374”>409.904dpdimen>
    <dimen name=“dp_375”>411dpdimen>
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-swdp,所以 values-sw412dp 這個檔案夾,設備 2 是匹配不了的),所以才存在了一定的誤差,因此上面介紹的第二個因數是非常重要的,這直接決定誤差是大還是小

可以看到即使在高寬一樣但 DPI 不一樣的設備上,smallestWidth 限定符屏幕適配方案 也能完成等比例適配,證明這個方案是可行的,如果大家還心存疑慮,也可以再試試其他解析度的設備,其實到最後得出的比例都是在 0.133 左右,唯一的變數就是第二個因數,如果您生成的 values-swdp 與設備實際的 最小寬度 差別不大,那誤差也就在能接受的範圍內,如果差別很大,那就直接 GG。


優點


1、非常穩定,極低概率出現意外

2、不會有任何性能的損耗

3、適配範圍可自由控制,不會影響其他三方庫

4、在插件的配合下,學習成本低


缺點

1、在佈局中取用 dimens 的方式,雖然學習成本低,但是在日常維護修改時較麻煩

2、侵入性高,如果專案想切換為其他屏幕適配方案,因為每個 Layout 檔案中都存在有大量 dimens 的取用,這時修改起來工作量非常巨大,切換成本非常高昂

3、無法改寫全部機型,想改寫更多機型的做法就是生成更多的資源檔案,但這樣會增加 App 體積,在沒有改寫的機型上還會出現一定的誤差,所以有時需要在適配效果和占用空間上做一些抉擇

4、如果想使用 sp,也需要生成一系列的 dimens,導致再次增加 App 的體積

、5不能自動支持橫豎屏切換時的適配,如上文所說,如果想自動支持橫豎屏切換時的適配,需要使用 values-wdp 或 屏幕方向限定符 再生成一套資源檔案,這樣又會再次增加 App 的體積

6、不能以高度為基準進行適配,考慮到這個方案的名字本身就叫 最小寬度限定符適配方案,所以在使用這個方案之前就應該要知道這個方案只能以寬度為基準進行適配,為什麼現在的屏幕適配方案只能以高度或寬度其中的一個作為基準進行適配,請看 這裡 https://github.com/JessYanCoding/AndroidAutoSize/issues/8 

使用中的問題


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

其實也可以不用換算的,那這是什麼騷操作呢?

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

我們在前面驗證可行性時把 最小寬度基準值 設置成了 375,為什麼是 375 呢?因為設計圖的總寬度為 375 dp,如果換算成 px,總寬度就是 750 px,我們這時把 最小寬度基準值 設置成 750,然後看看 values-sw360dp 中的 dimens.xml 長什麼樣



<resources>
    <dimen name="px_1">0.48dpdimen>

    <dimen name=“px_2”>0.96dpdimen>
    <dimen name=“px_3”>1.44dpdimen>
    <dimen name=“px_4”>1.92dpdimen>
    <dimen name=“px_5”>2.4dpdimen>
    …
    <dimen name=“px_50”>24dpdimen>
    …
    <dimen name=“px_100”>48dpdimen>
    …
    <dimen name=“px_746”>358.08dpdimen>
    <dimen name=“px_747”>358.56dpdimen>
    <dimen name=“px_748”>359.04dpdimen>
    <dimen name=“px_749”>359.52dpdimen>
    <dimen name=“px_750”>360dpdimen>
resources>

360 dp 被分成了 750 份,相比之前的 375 份,現在 每份占的 dp 值 正好減少了一半,還記得在驗證可行性的例子中那個 View 的尺寸是多少嗎?50dp * 50dp,如果設計圖只標註 px,那這個 View 在設計圖上的的尺寸應該是 100px * 100px,那我們直接根據設計圖上標註的 px,想都不用想直接在佈局中取用 px_100 就可以了,因為在 375 份時的 dp_50 剛好等於 750 份時的 px_100 (值都是 48 dp),所以這時的適配效果和之前驗證可行性時的適配效果沒有任何區別

看懂了嗎?直接將 最小寬度基準值 和佈局中的取用都以 px 作為單位就可以直接填寫設計圖上標註的 px!

6、總結

關於文中所列出的優缺點,列出的缺點數量確實比列出的優點數量多,但 缺點 3,缺點 4,缺點 5 其實都可以歸納於 占用 App 體積 這一個缺點,因為他們都可以通過增加資源檔案來解決問題,而 缺點 6 則是這個方案的特色,只能以寬度為基準進行適配,這個從這個方案的名字就能看出。

請大家千萬不要曲解文章的意思,不要只是單純的對比優缺點的數量,缺點的數量大於優點的數量就一定是這個方案不行?沒有一個方案是完美的,每個人的需求也都不一樣,作為一篇科普類文章我只可能把這個方案描述得盡可能的全面。

這個方案能給你帶來什麼,不能給你帶來什麼,我必須客觀的描述清楚,這樣才有助你做出決定,你應該註重的是在這些優缺點里什麼是我能接受的,什麼是我不能接受的,是否能為了某些優點做出某些妥協,而不只是單純的去看數量,這樣毫無意義,有些人就是覺得穩定性最重要,其他的都可以做出妥協,那其他缺點對於他來說都是無所謂的。

好了,這個系列的第二篇文章講完了,這篇文章也是按照上篇文章的優良傳統,寫的非常詳細,哪怕是新手我相信也應該能看懂,為什麼這麼多人都不知道自己該選擇什麼樣的方案,就是因為自己都沒搞懂這些方案的原理,懂了原理過後才知道這些方案是否是自己想要的。

接下來的第三篇文章會詳細講解兩個方案的深入對比以及該如何選擇,並剖析我根據 今日頭條屏幕適配方案 優化的屏幕適配框架 AndroidAutoSize 的原理,敬請期待

  • https://github.com/JessYanCoding/AndroidAutoSize

如果大家想使用 smallestWidth 限定符屏幕適配方案,可以參考 這篇文章 https://www.jianshu.com/p/1302ad5a4b04,裡面提供有自動生成資源檔案的插件和 Demo,由於我並沒有在專案中使用 smallestWidth 限定符屏幕適配方案,所以如果在文章中有遺漏的知識點請諒解以及補充,感謝!


●編號372,輸入編號直達本文

●輸入m獲取到文章目錄

推薦↓↓↓

Java編程

更多推薦18個技術類公眾微信

涵蓋:程式人生、演算法與資料結構、黑客技術與網絡安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

赞(0)

分享創造快樂