『壹』 android app界面設計規范(dpi,dp,px等)
PPI(Pixels per inch)：每英寸所擁有的像素數，即像素密度。
DPI(dots per inch)：即每英寸上，所能印刷的網點數，一般稱為像素密度。ppi計算公式：ppi = 屏幕對角線像素數/屏幕對角線英寸數，通過勾股定理計算屏幕對角線像素數。
Screen Size(屏幕尺寸)：手機屏幕尺寸大小，如3英寸、4英寸、4.3英寸、5.7英寸，指的是對角線的長度。
DIP（device independent pixel）：即dip/dp，設備獨立像素。 1px = 1dp density(由dpi決定)
Resolution(解析度)：指手機屏幕垂直和水平方向上的像素個數。eg解析度480 800，指該設備垂直方向有800個像素點，水平方向有480個像素點。
px(Pixel像素)：相同像素的ui，在不同解析度的設備上效果不同。在小解析度設備上會放大導致失真，大解析度上被縮小。
Android Design里把主流設備的 dpi 歸成了四個檔次： 120 dpi、160 dpi、240 dpi、320 dpi ，具體見如下表格。
實際開發當中，我們經常需要對這幾個尺寸進行相互轉換（比如先在某個解析度下完成設計，然後縮放到其他尺寸微調後輸出），一般按照 dpi 之間的比例即 2:1.5:1:0.75 來給界面中的元素來進行尺寸定義。
也就是說如果以 160 dpi 作為基準的話，只要尺寸的 DP 是 4 的公倍數，XHDPI 下乘以 2，HDPI 下乘以 1.5，LDPI 下乘以 0.75 即可滿足所有尺寸下都是整數 pixel 。但假設以 240 dpi 作為標准，那需要 DP 是 3 的公倍數，XHDPI 下乘以 1.333，MDPI 下乘以 0.666 ，LDPI 下除以 2。而以 LDPI 和 XHDPI 為基準就更復雜了。同時第一款Android設備（HTC的T-Mobile G1）是屬於160dpi的。鑒於以上各種原因， 標准dpi=160
谷歌官方對dp的解釋如下：
A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way.
The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.
簡單來說，以160dpi的設備為准，該設備上1dp = 1px；如果屏幕密度大，1dip代表的px就多，比如在320dpi的屏幕上，1dip=2px(即1dp代表2個像素)。在app開發時，最好用dp來做界面的布局，以保證適配不同屏幕密度的手機。
dp和px的換算公式：
我的理解，該公式表示px的數值等於dp的數值*（設備dpi/160）
注意，px、dp是單位，但density沒單位。
applyDimension的源碼如下，可參考：
android的尺寸眾多，建議使用解析度為 720x1280 的尺寸設計。這個尺寸 720x1280中顯示完美，在 1080x1920 中看起來也比較清晰；切圖後的圖片文件大小也適中，應用的內存消耗也不會過高。
app啟動圖標為48*48dp，對應各dpi設備，圖像資源像素如下：
| mdpi | hdpi | xhdpi | xxhdpi |
| ---:| ---: | ---:| ---:| ---:|
|48 48px|72 72px|94 96px|144px 144px|
操作欄圖標為32*32dp，對應各dpi設備，圖像資源像素如下：其中圖形區域尺寸是24*24dp，可參考平時ui切圖會有部分留白。
| mdpi | hdpi | xhdpi | xxhdpi |
| ---:| ---: | ---:| ---:| ---:|
|32 32px|48 48px|64 64px|96px 96px|
通知欄圖標為24*24dp，對應各dpi設備，圖標像素如下：
| mdpi | hdpi | xhdpi | xxhdpi |
| ---:| ---: | ---:| ---:| ---:|
|24 24px|36 36px|48 48px|72px 72px|
某些場景需要用到小圖標，大小應當是16*16dp，其中圖形區域尺寸12*12dp。
| mdpi | hdpi | xhdpi | xxhdpi |
| ---:| ---: | ---:| ---:| ---:|
|16 16px|24 24px|32 32px|48px 48px|
『貳』 android dp和dip的區別
dp: Density-independent Pixels
一個抽象的單元，基於屏幕的物理密度。
（dp和dip的意義相同，所以不用區別對待）。
這些單元是相對於160dpi（dots per inch）的屏幕說的，在160dpi的屏幕上，1dp粗略地等於1px。
當運行在更高密度的屏幕上的時候，要繪制1dp的像素數量會放大一個比例，這個比例就是和屏幕密度（dpi）相關。
類似的，在一個低密度的屏幕上，像素數目會縮小一個比例。
dp到px的這個比例將會隨著屏幕的密度變化，而不是直接的比例關系。
用dp單位，而不是px，是一種簡單的屏幕密度適配解決方式。
換句話說，它提供了一種方式，可以在多種設備上維持真實尺寸一致性。
sp：Scale-independent Pixels
這個有點像dp單位，但是它也根據用戶的字體設置（font preference）縮放尺寸。
建議用這種尺寸單位來標注字體尺寸，這樣它們將會因為屏幕密度和用戶設定而調整。
pt：Points 1/72 inch（英寸），根據屏幕的物理尺寸。
px: Pixels
相應於真實的像素。
這種單位不被建議，因為真實的表達會根據設備的不同相差很遠。
每個設備上每英寸的像素數不同（密度不同），並且屏幕上總的像素數也不同（整體大小不同）。
『叄』 Android屏幕適配-應用篇
Android屏幕適配-基礎篇
Android屏幕適配-應用篇
從兩個大方面闡述一下Android的屏幕適配：
Android推薦使用dp作為尺寸單位來適配UI ，通過dp加上自適應布局和weight比例布局可以基本解決不同手機上適配的問題，這基本是最原始的Android適配方案。
缺點 ：
（1）這種方案只能保證我們寫出來的界面適配絕大部分手機，部分手機仍然需要單獨適配，但dpi的不同，還是會存在差異。
（2）一般的設計稿都是以px為單位的，所以我們在寫layout文件的時候需要將px轉為dp，影響開發效率。
為了高效的實現UI開發，出現了新的適配方案，我把它稱作寬高限定符適配。簡單說，就是窮舉市面上所有的Android手機的寬高像素值，設定一個基準的解析度，其他解析度都根據這個基準解析度來計算，在不同的尺寸文件夾內部，根據該尺寸編寫對應的dimens文件:
鴻洋大神的作品 ，使用也超級簡單，核心功能就是在繪制的時候在onMeasure裡面做變換，重新計算px。
缺點 ：我們自定義的控制項可能會被影響或限制，可能有些特定的控制項（框架沒有做適配的控制項），需要單獨適配。
小結：上述幾種適配方案都是實際開發中用過的方案，但隨著技術不斷的更新，出現了更好的適配方案。
實現原理 ：Android會識別屏幕可用高度和寬度的最小尺寸的dp值（ 其實就是手機的寬度值 ），然後根據識別到的結果去資源文件中尋找對應限定符的文件夾下的資源文件。
sw限定符適配 和 寬高限定符適配 類似，區別在於，前者有很好的容錯機制，如果沒有value-sw360dp文件夾，系統會向下尋找，比如離360dp最近的只有value-sw350dp，那麼Android就會選擇value-sw350dp文件夾下面的資源文件。這個特性就完美的解決了上文提到的寬高限定符的容錯問題。
優點: 1.非常穩定，極低概率出現意外
2.不會有任何性能的損耗
3.適配范圍可自由控制，不會影響其他三方庫
缺點 ：就是多個dimens文件可能導致apk變大，幾百k。
附件： 生成sw文件的工具
實現原理 ： 修改系統的density值 （核心）
今日頭條適配是以設計圖的寬或高進行適配的，適配最終是改變系統density實現的。
過程：
AndroidAutoSize 是基於今日頭條適配方案，該開源庫已經很大程度上解決了今日頭條適配方案的兩個缺點，可以對activity，fragment進行取消適配。也是目前我的項目中所使用的適配方案。
使用也非常簡單只需兩步：
（1）引入：
（2）在 AndroidManifest 中填寫全局設計圖尺寸 (單位 dp)，如果使用副單位，則可以直接填寫像素尺寸，不需要再將像素轉化為 dp，詳情請查看 demo-subunits
『肆』 Android中常見的單位ppi,dp,dpi,sp,px
在android 開發過程中，我們使用的單位比較少，一般情況下在描述字體大小的時候我們通常用sp，而在設置間距的時候我們用dp，除此之外很少再用到其他單位，而且很多時候我們用著用著就習慣了，也不去探究為什麼這么寫，可不可以用其他單位，每個單位到底代表著什麼意思，所以說，習慣真的很可怕呀。今天，我們就來一探究竟，看看這些單位背後的含義。
像素即是屏幕上顯示數據的最基本的點，在PS裡面也是其最根本的單位，所有的圖形都是在此基礎上生成的，平時我們經常講的手機屏幕解析度就是以像素作為單位的，比如在android中我們經常說的手機像素是1080X1920，其實它所表達的意思是在該手機上面在橫向上面有1080個像素點，在縱向上有1920個像素點。
在android中用來形式字體大小的單位，正常情況下會按照手機系統設置的文本大小來顯示文字，但是同時也會與系統設置的文本保持一致，比如在有些老年機上面為了更好的操作手機有些人會將字體設置為較大字體，這個時候使用sp作為單位的字體也會隨之變大，但是如果將字體大小的單位設置為dp，則不會隨著系統字體的變化而變化。
在每次的手機廠商新品發布會上，我們都會聽到關於手機的介紹，比如手機的屏幕解析度，多大尺寸等等。而當我們知曉一個手機的屏幕分辯率和手機尺寸的時候，就可以計算出手機的物理像素密度，其計算公式為：
需要注意的是，PPI是Android手機物理像素密度，而非在Android開發過程中我們經常說到的像素密度。
屏幕密度與dpi密切相關，dpi是每英寸的點數。也就是說，密度越大，每英寸內容納的點數就越多。
在android.util包下有個DisplayMetrics類可以獲得密度相關的信息。最重要的是densityDpi這個成員，它有如下幾個常用值：
DENSITY_LOW = 120
DENSITY_MEDIUM = 160 //默認值
DENSITY_TV = 213 //TV專用
DENSITY_HIGH = 240
DENSITY_XHIGH = 320
DENSITY_400 = 400
DENSITY_XXHIGH = 480
DENSITY_XXXHIGH = 640
dpi的值主要是通過displayMetrics獲取的，獲取方式為：
val densityDpi = resources.displayMetrics.densityDpi。
dp和dip是一樣的，設備獨立像素，這個和設備硬體有關，不同設備有不同的顯示效果。而通常在做android項目的時候，為了適配市場上面眾多的手機屏幕分辯率，我們一般都會採用dp。dp是Android基於物理設備的PPI抽象出來的一個單位。它是以160dpi的屏幕為基準定義的，在160dpi的屏幕上1dp=1px，那麼由此我們就可以得出其計算公式：
換算公式：1dp = （屏幕ppi/160）px或者是px = （屏幕ppi/160）*1dp。舉個例子：假設ppi = 320，那麼1dp = 2px。
下面我們來演練一下：
如圖所示，手機的屏幕分辯率為1080X1920，尺寸為5寸，從而計算得出PPI的值為440，再通過PPI計算出1dp 約等於3px。假設現在美工給的圖上面有一個a圖標，距離頂部的距離為30px，那麼根據最終我們的換算結果可知，我們設置為10dp就可以達到完美的顯示效果。
『伍』 Android 關於"尺寸"的那些事(dp,dip,sp,pt,px...)
屏幕大小：屏幕大小是手機對角線的物理尺寸，以英寸inch為單位。比如我的Mix 2手機屏幕大小為5.99 inches，意味著我的屏幕對角線長度為5.99inches = 5.99 * 2.54 = 15.2146cm
解析度：屏幕的像素點數，一般表示為a*b。例如某手機解析度為21601080，意味著手機屏幕的豎直方向（長）有2160個像素點，水平方向（寬）有1080個像素點。
px ：Pixels ，像素；對應屏幕上的實際像素，是畫面中最小的點（單位色塊），像素大小沒有固定長度值，不同設備上1個單位像素色塊大小不同。
這么說可能有點陌生，用屏幕解析度來說，今年流行起來的「全面屏」解析度是 2160*1080，但是你也可以發現，雖然很多全面屏手機解析度一樣，但是明顯看得出來屏幕大小不一樣，這也解釋了「不同設備像素色塊大小是不同的」。
pt ：1pt＝1/72 inch，用於印刷業，非常簡單易用；
dpi ：Dots Per Inch，每英寸點數；詳見ppi
ppi ：Pixels Per Inch，每英寸像素數；數值越大顯示越細膩。計算式：ppi = 屏幕對角線像素數 / 屏幕對角線長度。
還是舉全面屏的例子，解析度2160*1080，屏幕大小是5.9inches，勾股定理可以得到對角線像素數大約是2415，那麼ppi = 2415 / 5.99 = 403.
事實上dpi 和 ppi 一定程度上可以劃等號，都表示像素密度，計算方式完全一致，只不過使用場景不一樣。dpi中的dots點屬於列印或印刷等領域，例如drawable 文件對應的就是dpi，而ppi中的pixel屬於屏幕顯示等領域
dp/dip : Density-independent Pixels，密度無關像素 - 基於屏幕物理密度的抽象單位。1dp等於 160 dpi 屏幕上的dpx，這是 系統為「中」密度屏幕假設的基線密度。在運行時，系統 根據使用中屏幕的實際密度按需要以透明方式處理 dp 單位的任何縮放 。dp 單位轉換為屏幕像素很簡單：px = dp * (dpi / 160)。 例如，在 240 dpi 屏幕上，1 dp 等於 1.5 物理像素。在定義應用的 UI 時應始終使用 dp 單位 ，以確保在不同密度的屏幕上正常顯示 UI。
如果看完文章還是覺得很懵，那麼可以直接記住： 1dp單位在設備屏幕上總是等於1/160 inch。
sp ：Scale-independent Pixels ，與 dp 單位相似，也會根據用戶的字體大小偏好進行縮放。
首先我們放上源碼中對尺寸單位的轉換
可以看到，輸入值類型為dp時，返回 value * DisplayMetrics.density，到這里我們可能會發懵：嗯？不對啊，前面我們不是通過px 和 dp 的換算公式來計算的么，怎麼這里就簡簡單單乘了一個DisplayMetrics.density？不要慌，我們先看看源碼中對DisplayMetrics.density的介紹。
源碼注釋中說到「在160dpi的屏幕下，density的值為1，而在120dpi的屏幕下，density的值為0.75」，我們可以大膽的猜測一下，120dpi下的density=0.75的原因是120dpi * 1 /160dpi=0.75。實際上，也就是這么回事。我們下面會仔細的分析。
需要補充一下，通常意義上Android 屏幕的密度，指的是像素密度dpi/ppi，對應於源碼中的DisplayMetrics.densityDpi。
為什麼引入dp？
Android 引入了dp這一單位，使得不論多大屏幕，多大dpi，顯示的效果始終保持一致。
但是根據前面我們提到的px與dp的換算公式px = dp * (dpi / 160)，很顯然，由於相同解析度但不同屏幕大小的設備dpi是不同的，導致px和dp的基本不存在一個固定的換算關系，為了方便屏幕適配，Android設置了6個通用的密度，換算px與dp時採取通用密度計算，而非設備實際的密度。
以下為6種通用密度，以及其最小的解析度
得到上面通用密度之後，我們換算dp與px多了一種簡便方式。前面我們提到Android將mdpi作為基準，此時1px = 1dp，又有px = dp * (dpi / 160)，所以我們可以很容易的得到以下換算：
還記不記得前面源碼中的density屬性，實際上DisplayMetrics.density = dpi / 160 ，表示的就是在某個通用密度下dp與px的換算比（1dp/1px的值）
這部分其實和程序員自身已經關系不大了，畢竟參與工作之後這些都是UI人員的活兒了。不過鑒於現在我還只是一枚在校生，還是記下來以免自己遺漏吧。
建議在xhdpi中作圖
原因嘛，首先現在主流解析度是1080p，以及最近流行起來的全面屏18:9，而xhdpi對應720p，向低dpi兼容自然沒問題，即便在xxhdpi中顯示，也會有個不錯的效果。而如果以1920*1080作圖，顯然圖片素材佔用的內存很大，而且也會增大應用安裝包的大小。
只有一個原則：資源放入對應dpi的文件夾中，Android會機智的載入合適的資源。
以drawable資源為例：
我們平時開發小項目&對UI要求不高時，只使用一套xhdpi的資源就足夠了，雖然這可能會導致在hdpi及以下的手機中有些卡頓，因為xhdpi的圖片運行在hdpi及以下的手機上會比較吃內存，不過無傷大雅。
而如果不為圖片資源犯愁時（有UI人員的支持，就是任性），就可以添加所有dpi的資源。當然，重點還是要滿足ldpi:mdpi:hdpi:xhdpi:xxhdpi=3:4:6:8:12的規律。
好像說了不少廢話，哈哈，大概就這么多吧。
『陸』 一種非常好用的Android屏幕適配
網上關於屏幕適配的文章已經鋪天蓋地了，為什麼我還要講？因為網上現在基本都是使用 屏幕解析度限定符 進行適配，即每種屏幕解析度的設備需要定義一套 dimens.xml 文件。由於不同解析度的設備太多了，而且有些設備還有虛擬按鍵（例如華為手機），這樣就還需要每個有虛擬按鍵的設備加多一套 dimens.xml 文件，再加上平板那些你會發現 dimens.xml 文件所佔的體積已經超過 2M 了！這絕對不是我們想要的。
我這里要講的是使用 sw<N>dp 限定符，即 smallestWidth（最小寬度） 限定符 來進行適配，使用這種方式只需要少量 dimens.xml 文件即可達到適配，而且根本不用考慮虛擬按鍵的問題。如果只適配手機，dimens.xml 文件所佔的體積只有 100 多 KB，即使加上平板和 TV，也就 500 多 KB，完全可以接收。這種方案已經在自己多個項目中應用過了，經過幾十台手機測試過，基本不會出現適配有問題的情況。製作生成對應 dimens.xml 文件插件（後面會講）的作者也說過他在待過的兩家大公司實踐過，所以請放心使用。
關於為什麼要進行屏幕適配，什麼是 dp、dpi 這些概念我就不去一一講解了，網上很多文章。這里我推薦幾篇講的比較好的：
屏幕解析度限定符適配需要在 res 文件夾下創建各種屏幕解析度對應的 values-xxx 文件夾，如下圖：
然後根據一個基準解析度，例如基準解析度為 1280x720，將寬度分成 720 份，取值為 1px~720px，將高度分成 1280 份，取值為 1px~1280px，生成各種解析度對應的 dimens.xml 文件。如下分別為解析度 1280x720 與 1920x1080 所對應的橫向 dimens.xml 文件：
假設設計圖上的一個控制項的寬度為 720px，那麼布局中就寫 android:layout_width="@dimen/x720" ，當運行程序的時候，系統會根據設備的解析度去尋找對應的 dimens.xml 文件。例如運行在解析度為 1280x720 的設備上，系統會自動找到對應的 values-1280x720 文件夾下的 lay_x.xml 文件，由上圖可知 x720 對應的值為
720.px，可鋪滿該屏幕寬度。運行在解析度為 1920x1080 的設備上，系統會自動找到對應的 values-1920x1080 文件夾下的 lay_x.xml 文件，由上圖可知 x720 對應的值為 1080.0px，可鋪滿該屏幕寬度。這樣就達到了屏幕適配的要求！
smallestWidth 限定符適配原理與屏幕解析度限定符適配原理一樣，系統都是根據限定符去尋找對應的 dimens.xml 文件。例如程序運行在最小寬度為 360dp 的設備上，系統會自動找到對應的 values-sw360dp 文件夾下的 dimens.xml 文件。區別就在於屏幕解析度限定符適配是拿 px 值等比例縮放，而 smallestWidth 限定符適配是拿 dp 值來等比縮放而已。需要注意的是「最小寬度」是不區分方向的，即無論是寬度還是高度，哪一邊小就認為哪一邊是「最小寬度」。如下分別為最小寬度為 360dp 與最小寬度為 640dp 所對應的 dimens.xml 文件：
ScreenUtils——> ScreenUtils
既然原理都一樣，都需要多套 dimens.xml 文件，那為什麼要選擇 smallestWidth 限定符適配呢？
大多數 UI 設計師提供的設計圖無非就幾種，它們對應的獲取方式如下：
這些文件當然不會手動去寫，網上已經有大神提供了自動生成這些文件的插件 ScreenMatch 。但是這個插件還是有點問題的：
基於以上問題，我在該插件的源碼上優化生成了新的插件 ScreenMatch ，由於插件庫已經有原作者的插件了，所以我就不重復造輪子上傳到插件庫了，你直接用本地安裝的方式安裝即可。
工具使用步驟：
然後選擇在哪個 mole 下執行適配。即基於哪個 mole 下的 res/values/dimens.xml 文件作為基準 dimens.xml 文件，生成的其他尺寸 dimens.xml 文件放在哪個 mole 下。例如選擇 app，然後點擊 OK ，出現如下界面表示生成文件成功。如下圖：
然後再看看 res 目錄下會自動生成一堆 dimens.xml 文件，如下圖：
通過上面的步驟就已經生成了所有設備對應的 dimens.xml 文件。
步驟 3 是以插件默認的最小寬度基準值為 360dp，適配的設備最小寬度為
320,360,384,392.7272,400,410,411.4285,432,480,533,592,600,640,662,720,768,800,811,820,960,961,1024,1280,1365（包含了平板和 TV ）生成的文件，但實際情況要根據設計圖和需求設置。
例如設計圖的最小寬度為 375dp，則需要更改最小寬度基準值為 375dp。如果項目只需要適配手機的話，適配的設備最小寬度保留 320,360,384,392.7272,400,410,411.4285,432,480 即可，若發現手機還有其他最小寬度自行加上即可，也麻煩把該最小寬度提供給我，我們一起來完善該份適配。
以上修改需要在配置文件里修改，即 screenMatch.properties 文件，該配置文件是執行完上面第 3 步後自動生成在項目的跟目錄下的。如下圖：
打開配置文件，修改下圖中 1、3、4 的值即可。(圖中單位均為 dp)
1：最小寬度基準值，填寫設計圖的最小寬度值即可。
2：插件默認適配的最小寬度值，即默認情況下會生成如下值的 dimens.xml 文件。
3：需要適配的最小寬度值（如果是小數，則保留 4 位小數。例如 392.727272...，則取 392.7272），即你想生成哪些 dimens.xml 文件。
4：忽略不需要適配的最小寬度值，即忽略掉插件默認生成的 dimens.xml 文件。
配置文件修改完成後，重新執行第 3 步，生成新的 dimens.xml 文件。
當然！如果你的設計圖也是標準的 360dp，那麼上面的步驟你可以忽略。直接復制我 github 上你需要的 dimens.xml 文件到你的項目即可， 默認的 values 文件夾下也需要一份 。
設計圖標注多少 dp，布局中就寫多少 dp ，非常方便！
大多數 UI 設計師提供的設計圖無非就幾種，它們對應的使用方式如下：
說了這么多，其實只需要簡單的 2 步：
很多人肯定會有疑問，難道我用了這套適配方案就可以全部直接寫死寬高了？那肯定不是的，如果一些好用的適配技巧能實現的，那就不要用直接寫死寬高的方式。這套適配方案搭配下面這些適配技巧可以讓你的屏幕適配更完美。
絕對布局（AbsoluteLayout）直接使用 X、Y 坐標來控制控制項的位置，對於屏幕碎片化這么嚴重的今天，使用絕對布局對於屏幕適配來說就是災難性的，所以 Google 已經廢棄了該控制項。
相對布局（RelativeLayout）或者約束布局（ConstraintLayout）就不一樣了，相對布局的子控制項之間使用 相對位置 的方式排列，即使屏幕的大小改變，控制項的相對位置也不會變化，與屏幕大小無關，靈活性很強。約束布局也是類似的，通過對某些控制項進行約束來確定它們之間的位置。
Nine-Patch 圖片是一種被特殊處理過的 PNG 圖片，你可以指定哪些區域可以拉伸而哪些區域不可以。例如聊天界面中的聊天氣泡背景圖就需要做成 Nine-Patch 圖片，因為每條消息的字數不是固定的，如果背景圖片不能隨著字數的長短進行縮放，那麼就會導致背景圖片變形。
因為各種屏幕高寬比並不是固定的，有 16:9、4:3，還有全面屏的 19.5:9 等等，如果強行將寬高都適配那隻會導致布局變形。
例如一個控制項的寬高為 360dp 和 640dp，如果將它顯示在寬高為 360dp 和 640dp 的設備上是正常鋪滿整個屏幕的，但是顯示在寬高為 360dp 和 780dp 的設備上高度則不能鋪滿，如果你讓高度鋪滿，而寬度又保持不變，那就會出現變形的情況。所以這也就是為什麼目前市面上的屏幕適配方案只能以寬或高一個維度去適配，另一個方向用滑動或權重的方式去適配的原因。
那你為什麼說高度也能適配呢？
這里說的高度也能適配指的是在不同解析度和密度的手機上能達到等比縮放的適配，其他屏幕適配方案也是一樣的。
注意：smallestWidth 限定符適配的效果是讓不同解析度和密度的設備上能達到以設計圖等比縮放的適配，如果設備與設計圖相差太大時並不能達到很好的適配效果，需要單獨出圖，其他屏幕適配方案也是一樣的。
同橫屏道理一樣，平板、TV 與手機的寬高差距太大，想要平板、TV 也能完全適配，那就只能讓設計師出一套平板、TV 的設計圖，然後單獨寫一套平板、TV 的布局文件。
注意：再說一遍，smallestWidth 限定符適配的效果是讓不同解析度和密度的設備上能達到以設計圖等比縮放的適配，如果設備與設計圖相差太大時並不能達到很好的適配效果，需要單獨出圖，其他屏幕適配方案也是一樣的。
github 地址： ScreenAdaptation
參考資料：