近來出了很多關於Android適配的文章和第三方庫，可以說已經是一波潮流了，甚至上了Github Trending；它們的原理都是一樣的，即來自於今日頭條的技術分享： 一種極低成本的Android螢幕適配方式。更深入一點，其本質就是縮放，也有人叫做百分比適配，更早也有庫實現這個AutoLayout。關於這些庫，我隱隱覺得有問題，但要說為什麼又說不清楚。理了一個禮拜的思路，大概整理出以下幾個點。
首先，這種縮放式的適配替代了DP方式，但沒有解決DP要解決的問題。我們知道實際顯示大小和效果是看畫素px和ppi的，那為什麼要弄出一個dp和dpi呢？這起初就是為了可以讓同樣的控制元件在不同的裝置上物理尺寸看起來一樣，不會被“縮放；實際上這裡已經進行了縮放了（以mdpi為準，xhdpi就是mdpi的1.5倍）；所以我們用dp就不需要進行縮放了。在中文的Android guide頁面，我們還可以看到這個提示（支援多種螢幕，英文版已經修改，中文版還是舊的）：
雖然系統為使您的應用適用於不同的螢幕，會進行縮放和大小調整，但您應針對不同的螢幕尺寸和密度優化應用。這樣可以最大程度優化所有裝置上的使用者體驗，使用者會 認為您的應用實際上是專為他們的裝置而設計，而不是簡單地拉伸以適應其裝置螢幕。
值得一說的是，dp這種縮放為了相容不同螢幕，是倍數的縮放，而不是簡單的拉伸。我的理解上效果比今日頭條的拉伸適配更通用的。通過DP縮放，市面上的手機現在寬的dp值一般介於320dp到411dp中間。前面提到的文章和庫效果看起來都不錯，我理解是現在測試的例子是取了中間值360dp或375dp進行縮放，縮放比例不大的緣故。
其次，這種適配只是粗暴的縮放了，並沒有考慮圖片資源的問題。使用DP做適配的時候，我們可以通過各種drawable-xxxdpi指定圖片資源，這些圖片和指定好的控制元件大小也是剛好適配的，舉個例子，一個使用者頭像大小是40dp*40dp，設計一般會給一個預設圖，這個預設圖的不同尺寸我們可以放在drawable-mdpi(40px*40px),drawable-xhdpi(60px*60px),drawable-xxhdpi(80px*80px)幾個資料夾，這些尺寸和控制元件在不同dpi裝置上展示實際畫素大小是相同的。我並沒有看到現在這種縮放怎麼解決這個問題。
再說設計，合格的設計本身就處理了不同裝置的相容問題，這種適配方式容易走入誤區。現在設計一般出圖的時候是以720px或750px或1080px作為原型大小寬的大小，這裡已經預設用了Android的DP概念了（720px是750px是作為xhdpi，1080px是xxhdpi）。一個設計圖或者原型圖，展示的是頁面的顯示邏輯；這種邏輯不會是從1080p切換到720p或768p就不行。包括設計內在的margin或者padding，不會因為這種變化就需要進行調整。控制元件大小也是如此。如下面圖片所示，一個微信頭像在1080px設計圖上展示的是80px（40dp）, 同一個設計師就算用720px作圖匯出來的也回事40dp。因為這個40dp不是設計師憑空而來的。適配時如果安裝設計的思路還原邏輯（頭像在左側，標題和時間在頭像右側，距離頭像15dp，具體金額和總值在右側）；這樣做出來的佈局是可以同時適配320dp到411dp任意寬度的螢幕的。
理解了設計的邏輯，適配起來並不麻煩，使用DP就夠了。同樣是上面的圖片，我們看底部的tab切換（紅包明細/其他明細）。如果我們認為一整個tab控制元件的寬是308dp，就這樣寫上去了，會出現什麼問題？原設計圖的寬是360dp的，兩邊各留出了26dp。直接寫308dp在360dp上表現是沒有問題的，但是在320dp的裝置上兩邊就只會各自留出6dp，同樣地在411dp的裝置上兩邊就會留出51.5dp。這樣的適配效果和設計圖對比一定看出來一個太窄，一個太寬。但如果兩邊各自留出26dp，然後控制元件本身match_parent呢？從視覺上看應該和設計圖是差不多的這兩種適配相比沒有哪種更麻煩，適配效果好壞只看有沒有清楚的認識到設計的邏輯，是不是按照設計的思路做。
Android手機螢幕的大小基本介於320dp到411dp之間（平板不在此列）；設計圖也就那幾種規格，換算過來720p和1080p的是360dp，750*1334是375dp。按照設計的內在邏輯去適配，使用DP也並不複雜，效果也是最佳的。雖然這裡只說手機，但如果按照這樣適配，就算是在平板上，顯示效果也是可以的，而不是一個拉伸的介面。