一、現(xiàn)狀

由于Android碎片化嚴(yán)重，屏幕適配一直是開發(fā)中較為頭疼的問題。面對市面上五花八門的屏幕大小與分辨率，Android基于dp與res目錄名稱來適配的方案已無法滿足一次編寫全屏幕適配的需求，為了達(dá)到***的視覺效果，開發(fā)過程中總是需要花費(fèi)較多資源進(jìn)行適配。也有開發(fā)者給出了一些自己的解決方案。首先來分析一下一些常見的解決方案的現(xiàn)狀：

官方適配方案

dp。dp是Android開發(fā)中特有的一個單位。與px不同，dp是基于屏幕像素密度的一種單位。在密度低的屏幕上或許1dp=1px，但在密度高的屏幕上可能1dp=4px。編寫布局xml時，如果一個控件的長寬都使用dp來指定，那么能確保該控件在各種大小與分辨率的屏幕下的絕對大小都大致相當(dāng)。也就是說無論在pad下還是大小屏手機(jī)下，我們實(shí)際看到的該控件的大小是差不多的：

資源目錄名。上圖可見雖然使用dp確保了控件在不同屏幕中的絕對大小一致。這樣的好處在于，在大小相近的屏幕中，無論分辨率多大都不會對布局造成影響;但是當(dāng)屏幕大小相差較大時，僅保證控件的絕對大小看起來就有些問題了。在res目錄下可以給各資源目錄都加上例如'-1920x1080'等后綴來適配不同的屏幕，具體規(guī)則可見官網(wǎng)文檔。這樣可以針對不同的屏幕提供不同的布局，甚至針對pad與手機(jī)提供兩套完全不同的布局樣式。但是通常情況下，設(shè)計(jì)師并不會對不同屏幕提供不同的設(shè)計(jì)圖，他們的需求僅僅是不同屏幕下控件對屏幕的相對大小一致，所以dp并不能滿足這一點(diǎn)，而對各種屏幕適配一遍又顯得略為繁瑣，并且修改也較為麻煩。通常我們需要的適配是這樣的：

百分比布局支持庫。沒有使用過，但是deprecated in API level 26.0.0-beta1。

ConstraintLayout。百分比支持庫deprecated之后推薦使用的布局，看起來似乎略復(fù)雜。

玩家適配方案。廣大玩家的適配目的很明確，目的就是要確?？丶诓煌聊坏南鄬Υ笮∫恢拢雌饋硪幻粯拥?。以一位大神玩家的兩種適配方案為例：

1. 方案一。編寫腳本將長度轉(zhuǎn)換成各分辨率下的長度，缺點(diǎn)是難以覆蓋市面上的所有分辨率。
2. 方案二。AutoLayout支持庫。該庫的想法非常好：對照設(shè)計(jì)圖，使用px編寫布局，不影響預(yù)覽;繪制階段將對應(yīng)設(shè)計(jì)圖的px數(shù)值計(jì)算轉(zhuǎn)換為當(dāng)前屏幕下適配的大小;為簡化接入，inflate時自動將各Layout轉(zhuǎn)換為對應(yīng)的AutoLayout，從而不需要在所有的xml中更改。但是同時該庫也存在以下等問題：

• 擴(kuò)展性較差。對于每一種ViewGroup都要對應(yīng)編寫對應(yīng)的AutoLayout進(jìn)行擴(kuò)展，對于各View的每個需要適配的屬性都要編寫代碼進(jìn)行適配擴(kuò)展;

在onMeasure階段進(jìn)行數(shù)值計(jì)算。消耗性能，并且這對于非LayoutParams中的屬性存在較多不合理之處。比如在onMeasure時對TextView的textSize進(jìn)行換算并setTextSize，那么玩家在代碼中動態(tài)設(shè)置的textSize都會失效，因?yàn)樵诿看蝟nMesasure時都會重新被AutoLayout重新設(shè)置覆蓋。

issue較多并且作者已不再維護(hù)。

二、想法

對于大小差異較大的屏幕，本不該使用同一套設(shè)計(jì)方案，否則大屏的優(yōu)勢沒有完全體現(xiàn)出來，從官方的適配方案也似乎是表達(dá)了這個意思。但是在實(shí)際設(shè)計(jì)與開發(fā)中，對于一個普通的App，很少有項(xiàng)目有意愿有精力來對各屏幕來分別設(shè)計(jì)與開發(fā)一套設(shè)計(jì)方案來適配。

通常的一個簡單的適配需求是：假如設(shè)計(jì)圖寬度為200，一個控件在設(shè)計(jì)圖上標(biāo)注的長度為3，那么該控件長度相當(dāng)于總寬度的3/200，那么我們希望在任何大小的屏幕上該控件所表現(xiàn)的長度都為屏幕寬度的3/200。

個人覺得AutoLayout的設(shè)計(jì)思想非常優(yōu)秀，但是將LayoutParams與屬性作為切入口在mesure過程中進(jìn)行轉(zhuǎn)換計(jì)算的方案存在效率與擴(kuò)展性等方面的問題。那么Android計(jì)算長度的收口在哪里，能不能在Android計(jì)算長度時進(jìn)行換算呢?如果能在Android計(jì)算長度時進(jìn)行換算，那么就不需要一系列多余的計(jì)算以及適配，一切問題就都迎刃而解了。

經(jīng)過一番尋覓，發(fā)現(xiàn)系統(tǒng)進(jìn)行長度計(jì)算的收口為TypedValue中的applyDimension函數(shù)，傳入單位與value將其計(jì)算為對應(yīng)的px數(shù)值。

public static float applyDimension(int unit, float value, 
                                       DisplayMetrics metrics) 
    { 
        switch (unit) { 
        case COMPLEX_UNIT_PX: 
            return value; 
        case COMPLEX_UNIT_DIP: 
            return value * metrics.density; 
        case COMPLEX_UNIT_SP: 
            return value * metrics.scaledDensity; 
        case COMPLEX_UNIT_PT: 
            return value * metrics.xdpi * (1.0f/72); 
        case COMPLEX_UNIT_IN: 
            return value * metrics.xdpi; 
        case COMPLEX_UNIT_MM: 
            return value * metrics.xdpi * (1.0f/25.4f); 
        } 
        return 0; 
    } 

可以看見換算方法非常簡單，而DisplayMetrics的所有屬性都是public的，不用反射就能修改;

pt的原意是長度單位磅，根據(jù)當(dāng)前屏幕與設(shè)計(jì)圖尺寸將metrics.xdpi進(jìn)行修改就可以實(shí)現(xiàn)將pt這個單位重定義成我們所需要的相對長度單位，使修改之后計(jì)算出的1pt實(shí)際對應(yīng)的px/屏幕寬度px=1px/設(shè)計(jì)圖寬度px。

而這個DisplayMetrics從哪來?從源碼中可以看出一般為mContext.getResources().getDisplayMetrics()，這個mContext即為所在Activity;

橫豎屏切換等Configuration的變化會導(dǎo)致DisplayMetrics的重新計(jì)算還原;

px,dp與sp都是平時常用的單位，而pt,in與mm幾乎沒有看見過，從這些不常見的單位下手正好可以不影響其他常用的單位。

基于以上幾點(diǎn)，便有了以下方案。

三、方案

本適配方案的目標(biāo)是：完全按照設(shè)計(jì)圖上標(biāo)注的尺寸來編寫頁面，所編寫的頁面在所有大小與分辨率的屏幕上都表現(xiàn)一致，即控件在所有屏幕上相對于整個屏幕的相對大小都一致(看起來只是將設(shè)計(jì)圖等比縮放至屏幕寬度大小)。

核心。使用冷門的pt作為長度單位，按照上述想法將其重定義為與屏幕大小相關(guān)的相對單位，不會對dp等常用單位的使用造成影響。

繪制。編寫xml時完全對照設(shè)計(jì)稿上的尺寸來編寫，只不過單位換為pt。假如設(shè)計(jì)圖寬度為200，一個控件在設(shè)計(jì)圖上標(biāo)注的長度為3，只需要在初始化時定義寬度為200，繪制該控件時長度寫為3pt，那么在任何大小的屏幕上該控件所表現(xiàn)的長度都為屏幕寬度的3/200。如果需要在代碼中動態(tài)轉(zhuǎn)換成px的話，使用TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_PT, value, metrics)。

預(yù)覽。實(shí)時預(yù)覽時繪制頁面是很重要的一個環(huán)節(jié)。以1334x750的設(shè)計(jì)圖為例，為了實(shí)現(xiàn)于正常繪制時一樣的預(yù)覽功能，創(chuàng)建一個長為1334磅，寬為750磅的設(shè)備作為預(yù)覽，經(jīng)換算約為21.5英寸((sqrt(1334^2+750^2))/72)。預(yù)覽時選擇這個設(shè)備即可。

代碼處理。在activityonCreate時修改DisplayMetrics即可，推薦寫在基類或ActivityLifecycleCallbacks中，參考github demo。

Point size = new Point(); 
activity.getWindowManager().getDefaultDisplay().getSize(size); 
context.getResources().getDisplayMetrics().xdpi = size.x / designWidth * 72f; 

這樣繪制出來的頁面就跟設(shè)計(jì)圖幾乎完全一樣，無論大小屏上看起來就只是將設(shè)計(jì)圖縮放之后的結(jié)果。

適配前(左圖API19 400x800， 右圖API24 1440x2560)：

適配后(左圖API19 400x800， 右圖API24 1440x2560)：

雖然方案比較簡單，但是為了方便使用也整理成了一個library，代碼及demo見github