轉(zhuǎn)載請(qǐng)聯(lián)系作者并注明出處 http://www.reibang.com/p/b6b9bd1fba4d

目前發(fā)現(xiàn)有少量情況沒有hold住，具體可能出現(xiàn)問題的場(chǎng)景與解決方案見github
有空會(huì)看看上述問題能否集成到sdk中來處理
?github

一、現(xiàn)狀

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

1. 官方適配方案
   • dp。dp是Android開發(fā)中特有的一個(gè)單位蜘渣。與px不同淌铐，dp是基于屏幕像素密度的一種單位。在?密度低的屏幕上或許1dp=1px宋梧，但在密度高的屏幕上可能1dp=4px匣沼。編寫布局xml時(shí)，如果一個(gè)控件的長(zhǎng)寬都使用dp來指定捂龄，那么能確保該控件在各種大小與分辨率的屏幕下的絕對(duì)大小都大致相當(dāng)。也就是說無論在pad下還是大小屏手機(jī)下加叁，我們實(shí)際看到的該控件的大小是差不多的：
     
     圖一.png
   • 資源目錄名倦沧。上圖可見雖然使用dp確保了控件在不同屏幕中的絕對(duì)大小一致。這樣的好處在于它匕，在大小相近的屏幕中展融，?無論分辨率多大都不會(huì)對(duì)布局造成影響；但是當(dāng)屏幕大小相差較大時(shí)豫柬，僅保證控件的?絕對(duì)大小看起來就有些問題了告希。在res目錄下可以給?各資源目錄都加上例如'-1920x1080'等后綴來適配不同的?屏幕，具體規(guī)則可見官網(wǎng)文檔烧给。這樣可以針對(duì)不同的屏幕提供不同的布局燕偶，甚至針對(duì)pad與手機(jī)提供兩套完全不同的布局樣式。但是通常情況下础嫡，設(shè)計(jì)師并不會(huì)對(duì)不同屏幕提供不同的設(shè)計(jì)圖指么，他們的需求僅僅是不同屏幕下控件對(duì)屏幕的相對(duì)大小一致酝惧，所以dp并不能滿足這一點(diǎn)，而對(duì)各種屏幕適配一遍又顯得略為繁瑣伯诬，并且修改也較為麻煩晚唇。通常我們需要的適配是這樣的：
     
     圖二.png
   • 百分比布局支持庫。沒有使用過盗似，但是deprecated in API level 26.0.0-beta1哩陕。
   • ConstraintLayout。百分比支持庫deprecated之后推薦使用的布局赫舒，看起來似乎略復(fù)雜悍及。
2. 玩家適配方案。廣大玩家的適配目的很明確号阿，目的就是要確辈⑼遥控件在不同屏幕的相對(duì)大小一致，看起來一毛一樣的扔涧。?以一位大神玩家的兩種適配方案為例：
   • ?方案一园担。?編寫腳本將長(zhǎng)度轉(zhuǎn)換成各分辨率下的長(zhǎng)度，缺點(diǎn)是難以覆蓋市面上的所有分辨率枯夜。
   • 方案二弯汰。AutoLayout支持庫。該庫的想法非常好：對(duì)照設(shè)計(jì)圖湖雹，使用px編寫布局咏闪，不影響預(yù)覽；繪制階段將對(duì)應(yīng)設(shè)計(jì)圖的px數(shù)值計(jì)算轉(zhuǎn)換為當(dāng)前屏幕下適配的大兴だ簟鸽嫂；為簡(jiǎn)化接入，inflate時(shí)自動(dòng)將?各Layout轉(zhuǎn)換為對(duì)應(yīng)的AutoLayout征讲，從而不需要在所有的xml中更改据某。但是同時(shí)該庫也存在以下等問題：
     • ?擴(kuò)展性較差。對(duì)于每一種ViewGroup都要對(duì)應(yīng)編寫對(duì)應(yīng)的AutoLayout進(jìn)行擴(kuò)展诗箍，對(duì)于各View的每個(gè)需要適配的屬性都要編寫代碼進(jìn)行適配擴(kuò)展癣籽；
     • 在onMeasure階段進(jìn)行數(shù)值計(jì)算。消耗性能滤祖，并且這對(duì)于非LayoutParams中的屬性存在較多不合理之處筷狼。比如在onMeasure時(shí)對(duì)TextView的?textSize進(jìn)行換算并setTextSize，那么??玩家在代碼中動(dòng)態(tài)設(shè)置的textSize都會(huì)失效匠童，因?yàn)樵诿看蝟nMesasure時(shí)都會(huì)重新被?AutoLayout重新設(shè)置覆蓋埂材。
     • issue較多并且作者已不再維護(hù)。

二俏让、想法

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

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

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

經(jīng)過一番尋覓挠日，發(fā)現(xiàn)系統(tǒng)進(jìn)行長(zhǎng)度計(jì)算的收口為?TypedValue中的applyDimension函數(shù)疮绷，傳入單位與value將其計(jì)算為對(duì)應(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;
    }

• 可以看見換算方法非常簡(jiǎn)單嚣潜，而DisplayMetrics的?所有屬性都是public的冬骚，不用反射就能修改；
• pt的原意是長(zhǎng)度單位磅懂算，根據(jù)當(dāng)前屏幕與設(shè)計(jì)圖尺寸將metrics.xdpi?進(jìn)行修改就可以實(shí)現(xiàn)將pt這個(gè)單位重定義成我們所需要的相對(duì)長(zhǎng)度單位只冻，使修改之后計(jì)算出的1pt實(shí)際對(duì)應(yīng)的px/屏幕寬度px=1px/設(shè)計(jì)圖寬度px。
• 而這個(gè)DisplayMetrics從哪來计技？從源碼中可以看出一般為mContext.getResources().getDisplayMetrics()属愤，這個(gè)mContext即為所在Activity；
• ?橫豎屏切換等Configuration的變化會(huì)導(dǎo)致DisplayMetrics?的?重新計(jì)算還原酸役；
• px,dp與sp都是平時(shí)常用的單位，而pt,in與mm幾乎沒有看見過驾胆，從這些不常見的單位下手正好可以不影響其他常用的單位涣澡。

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

三入桂、方案

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

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

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

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

  圖三.png
  
  
  圖四.png

• 代碼處理惩妇。在activityonCreate時(shí)修改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）：

圖五.png

適配后（左圖API19 400x800路召， 右圖API24 1440x2560）：

圖六.png

?雖然方案比較簡(jiǎn)單，但是為了方便使用也整理成了一個(gè)library波材，代碼及demo見github

歡迎大家一起討論完善股淡，如有問題請(qǐng)統(tǒng)一提github issue方便匯總與處理