基于Android全屏幕的快速自適配策略

鄧春 林謝言 王再超

摘 ?要：隨著Android設備種類繁多，屏幕尺寸差別較大，加之Android、應用軟件的碎片化嚴重，屏幕適配一直是開發中較為頭疼的問題;本文采用使用門的pt作為長度單位，完全按照設計圖上標注的尺寸來編寫頁面，即控件在所有屏幕上相對于整個屏幕的相對大小都一致（看起來只是將設計圖等比縮放至屏幕寬度大小），實現了Android的屏幕自適應效果。中國

關鍵詞：Android;屏幕;自適配策略

中圖分類號：TP3 ? ?文獻標識碼：A

現狀

由于Android設備種類繁多，屏幕尺寸差別較大，加之Android碎片化嚴重，屏幕適配一直是開發中較為頭疼的問題。面對市面上五花八門的屏幕大小與分辨率，Android基于dp與res目錄名稱來適配的方案已無法滿足一次編寫全屏幕適配的需求，為了達到最優的視覺效果，開發過程中需要花費較多資源進行適配。

1、常見的解決方案----官方適配方案

1.1 ?dp方法

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

1.2 Ver方法

Ver（資源目錄名）是最常見的屏幕布局方法，Ver目錄用于存放Android應用程序使用到的所有資源，按照約定將不同的資源存放到不同的文件夾內。上圖可見雖然使用dp確保了控件在不同屏幕中的絕對大小一致。這樣的好處在于，在大小相近的屏幕中，無論分辨率多大都不會對布局造成影響;但是當屏幕大小相差較大時，僅保證控件的絕對大小看起來就有些問題了。在res目錄下可以給各資源目錄都加上例如“1920x1080”等后綴來適配不同的屏幕，具體規則可見官網文檔。這樣可以針對不同的屏幕提供不同的布局，甚至針對pad與手機提供兩套完全不同的布局樣式。但是通常情況下，設計師并不會對不同屏幕提供不同的設計圖，他們的需求僅僅是不同屏幕下控件對屏幕的相對大小一致，所以dp并不能滿足這一點，而對各種屏幕適配一遍又顯得略為繁瑣，并且修改也較為麻煩。通常需要的適配如下：

1.3 Px方法

Px（百分比布局支持庫）為deprecated推薦使用的布局，看起來似乎略復雜，但適配目的很明確，目的就是要確保控件在不同屏幕的相對大小一致，看起來一模一樣的，歸納常用的適配方案：

方案一：編寫腳本將長度轉換成各分辨率下的長度，缺點是難以覆蓋市面上的所有分辨率。

方案二：AutoLayout支持庫。該庫的想法非常好：對照設計圖，使用px編寫布局，不影響預覽;繪制階段將對應設計圖的px數值計算轉換為當前屏幕下適配的大小;為簡化接入，inflate時自動將各Layout轉換為對應的AutoLayout，從而不需要在所有的xml中更改。但是同時該庫也存在以下問題：

擴展性較差。對于每一種ViewGroup都要對應編寫對應的AutoLayout進行擴展，對于各View的每個需要適配的屬性都要編寫代碼進行適配擴展;在onMeasure階段進行數值計算。

消耗性能，并且這對于非LayoutParams中的屬性存在較多不合理之處。比如在onMeasure時對TextView的textSize進行換算并setTextSize，那么在代碼中動態設置的textSize都會失效，因為在每次onMesasure時都會重新被AutoLayout重新設置覆蓋。

issue較多并且已不再維護。

2、Android的屏幕自適應實現原理

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

通常的一個簡單的適配需求是：假如設計圖寬度為200，一個控件在設計圖上標注的長度為3，要么該控件長度相當于總寬度的3/200，要么希望在任何大小的屏幕上該控件所表現的長度都為屏幕寬度的3/200。

Android的AutoLayout設計思想非常優秀，但是將LayoutParams與屬性作為切入口，在mesure過程中進行轉換計算的方案存在效率與擴展性等方面的問題。那么Android計算長度的收口在哪里？能不能在Android計算長度時進行換算呢？如果能在Android計算長度時進行換算，那么就不需要一系列多余的計算以及適配，一切問題就都迎刃而解了。

經過研究，本文將長度計算的收口設為TypedValue中的applyDimension函數，傳入單位與value值，將其計算為對應的px數值。代碼如下：

1.public static float applyDimension（int unit，float value，

2.DisplayMetrics metrics）

3.{

4.switch（unit）{

5.case COMPLEX_UNIT_PX：

6.return value;

7.case COMPLEX_UNIT_DIP：

8.return value * metrics.density;

9.case COMPLEX_UNIT_SP：

10.return value * metrics.scaledDensity;

11.case COMPLEX_UNIT_PT：

12.return value * metrics.xdpi *（1.0f/72）;

13.case COMPLEX_UNIT_IN：

14.return value * metrics.xdpi;

15.case COMPLEX_UNIT_MM：

16.return value * metrics.xdpi *（1.0f/25.4f）;

17.}

18.return 0;

19.}

可以看見換算方法非常簡單，而DisplayMetrics的所有屬性都是public的，不用反射就能修改;pt的原意是長度單位磅，根據當前屏幕與設計圖尺寸將metrics.xdpi進行修改就可以實現將pt這個單位重定義成我們所需要的相對長度單位，使修改之后計算出的1pt實際對應的px/屏幕寬度px=1px/設計圖寬度px。mContext即為所在Activity;橫豎屏切換等Configuration的變化會導致DisplayMetrics的重新計算還原;px，dp與sp都是平時常用的單位，而pt，in與mm幾乎沒有看見過，從這些不常見的單位下手正好可以不影響其他常用的單位。

基于以上幾點，便有了以下方案。

3、Android的屏幕自適應實驗結果及分析

本適配方案的目標是：完全按照設計圖上標注的尺寸來編寫頁面，所編寫的頁面在所有大小與分辨率不同的屏幕上都表現一致，即控件在所有屏幕上相對于整個屏幕的相對大小都一致（看起來只是將設計圖等比縮放至屏幕寬度大小）。

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

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

預覽。實時預覽時繪制頁面是很重要的一個環節。以1334x750的設計圖為例，為了實現于正常繪制時一樣的預覽功能，創建一個長為1334磅，寬為750磅的設備作為預覽，經換算約為21.5英寸（（sqrt（1334^2+750^2））/72）。預覽時選擇這個設備即可。

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

1.Point size = new Point（）;

2activity.getWindowManager（）.getDefaultDisplay（）.getSize（size）;

3.context.getResources（）.getDisplayMetrics（）.xdpi = size.x / designWidth * 72f;

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

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

4、結論

本文使用冷門的pt作為長度單位，完全按照設計圖上標注的尺寸來編寫頁面，所編寫的頁面在所有大小與分辨率的屏幕上都表現一致，即控件在所有屏幕上相對于整個屏幕的相對大小都一致（看起來只是將設計圖等比縮放至屏幕寬度大小），實現了Android的屏幕自適應效果，在Android設備上的應用具有實用價值。

賽爾網絡下一代互聯網技術創新項目：NGII20160516