Android適配: 拉伸適配的缺點

近來出了不少關於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也並不複雜，效果也是最佳的。雖然這裏只說手機，但若是按照這樣適配，就算是在平板上，顯示效果也是能夠的，而不是一個拉伸的界面。