前言：
不管你在佈局文件中填寫的是什麼單位，最後都會被轉化爲 px，系統就是通過上面的方法，將你在項目中任何地方填寫的單位都轉換爲 px 的。px 轉 dp 的公式 dp = px / density，就是根據上面的方法得來的，density 在公式的運算中扮演着至關重要的一步。
要看懂下面的內容，還得明白，今日頭條的適配方式，今日頭條適配方案默認項目中只能以高或寬中的一個作爲基準，進行適配，爲什麼不像 AndroidAutoLayout 一樣，高以高爲基準，寬以寬爲基準，同時進行適配呢？
這就引出了一個現在比較棘手的問題，大部分市面上的 Android 設備的屏幕高寬比都不一致，特別是現在大量全面屏的問世，這個問題更加嚴重，不同廠商推出的全面屏手機的屏幕高寬比都可能不一致。
這時我們只以高或寬其中的一個作爲基準進行適配，就會有效的避免佈局在高寬比不一致的屏幕上出現變形的問題。
明白這個後，我再來說說 density，density 在每個設備上都是固定的，DPI / 160 = density，屏幕的總 px 寬度 / density = 屏幕的總 dp 寬度
-
設備 1，屏幕寬度爲 1080px，480DPI，屏幕總 dp 寬度爲 1080 / (480 / 160) = 360dp
-
設備 2，屏幕寬度爲 1440，560DPI，屏幕總 dp 寬度爲 1440 / (560 / 160) = 411dp
可以看到屏幕的總 dp 寬度在不同的設備上是會變化的，但是我們在佈局中填寫的 dp 值卻是固定不變的
這會導致什麼呢？假設我們佈局中有一個 View 的寬度爲 100dp，在設備 1 中 該 View 的寬度佔整個屏幕寬度的 27.8% (100 / 360 = 0.278)
但在設備 2 中該 View 的寬度就只能佔整個屏幕寬度的 24.3% (100 / 411 = 0.243)，可以看到這個 View 在像素越高的屏幕上，dp 值雖然沒變，但是與屏幕的實際比例卻發生了較大的變化，所以肉眼的觀看效果，會越來越小，這就導致了傳統的填寫 dp 的屏幕適配方式產生了較大的誤差
這時我們要想完美適配，那就必須保證這個 View 在任何分辨率的屏幕上，與屏幕的比例都是相同的
這時我們該怎麼做呢？改變每個 View 的 dp 值？不現實，在每個設備上都要通過代碼動態計算 View 的 dp 值，工作量太大
如果每個 View 的 dp 值是固定不變的，那我們只要保證每個設備的屏幕總 dp 寬度不變，就能保證每個 View 在所有分辨率的屏幕上與屏幕的比例都保持不變，從而完成等比例適配，並且這個屏幕總 dp 寬度如果還能保證和設計圖的寬度一致的話，那我們在佈局時就可以直接按照設計圖上的尺寸填寫 dp 值
屏幕的總 px 寬度 / density = 屏幕的總 dp 寬度
在這個公式中我們要保證 屏幕的總 dp 寬度 和 設計圖總寬度 一致，並且在所有分辨率的屏幕上都保持不變，我們需要怎麼做呢？屏幕的總 px 寬度 每個設備都不一致，這個值是肯定會變化的，這時今日頭條的公式就派上用場了
當前設備屏幕總寬度（單位爲像素）/ 設計圖總寬度（單位爲 dp) = density
這個公式就是把上面公式中的 屏幕的總 dp 寬度 換成 設計圖總寬度，原理都是一樣的，只要 density 根據不同的設備進行實時計算並作出改變，就能保證 設計圖總寬度 不變，也就完成了適配
今日頭條屏幕適配：
通過修改density值，強行把所有不同尺寸分辨率的手機的寬度dp值改成一個統一的值（在清單文件中定義），這樣就解決了所有的適配問題。
其適配方案的核心原理在於，根據以下公式算出 density (density 的意思就是 1 dp 佔當前設備多少像素)；
Density的計算：
Density = 當前設備屏幕總寬度（單位爲像素）/ 設計圖總寬度（單位爲 dp) ；
今日頭條的AutoSize屏幕適配框架:
今日頭條的AutoSize屏幕適配框架，是一個極低成本的 Android 屏幕適配方案
https://github.com/JessYanCoding/AndroidAutoSize
使用:
implementation 'me.jessyan:autosize:1.1.2'
AndroidManifest.xml清單文件：
<manifest>
<application>
<meta-data android:name="design_width_in_dp" android:value="360"/>
<meta-data android:name="design_height_in_dp" android:value="640"/>
</application>
</manifest>
優點
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
以上兩種方案我個人感覺 AndroidAutoSize 框架所以用的今日頭條適配技術 侵入性比 SmallestWidth要低些,以後如果要更改適配方式比較方便, 使用 SmallestWidth 方案的話以後更該維護起來比較費勁(這純屬與個人看法,如有得罪的地方請海涵,畢竟偶還是個小白)
參考:https://blog.csdn.net/suyimin2010/article/details/82047649
參考:https://blog.csdn.net/wa172126691/article/details/83189169
今日頭條屏幕適配方案終極版:https://github.com/JessYanCoding/AndroidAutoSize
