692
技術社區[雲棲]
一種粗暴快速的Android全屏幕適配方案
一、現狀
由於Android碎片化嚴重，屏幕適配一直是開發中較為頭疼的問題。麵對市麵上五花八門的屏幕大小與分辨率，Android基於dp與res目錄名稱來適配的方案已無法滿足一次編寫全屏幕適配的需求，為了達到最優的視覺效果，開發過程中總是需要花費較多資源進行適配。也有開發者給出了一些自己的解決方案。首先來分析一下一些常見的解決方案的現狀：
1. 官方適配方案
- dp。dp是Android開發中特有的一個單位。與px不同，dp是基於屏幕像素密度的一種單位。在密度低的屏幕上或許1dp=1px，但在密度高的屏幕上可能1dp=4px。編寫布局xml時，如果一個控件的長寬都使用dp來指定，那麼能確保該控件在各種大小與分辨率的屏幕下的絕對大小都大致相當。也就是說無論在pad下還是大小屏手機下，我們實際看到的該控件的大小是差不多的：
- 資源目錄名。上圖可見雖然使用dp確保了控件在不同屏幕中的絕對大小一致。這樣的好處在於，在大小相近的屏幕中，無論分辨率多大都不會對布局造成影響；但是當屏幕大小相差較大時，僅保證控件的絕對大小看起來就有些問題了。在res目錄下可以給各資源目錄都加上例如'-1920x1080'等後綴來適配不同的屏幕，具體規則可見官網文檔。這樣可以針對不同的屏幕提供不同的布局，甚至針對pad與手機提供兩套完全不同的布局樣式。但是通常情況下，設計師並不會對不同屏幕提供不同的設計圖，他們的需求僅僅是不同屏幕下控件對屏幕的相對大小一致，所以dp並不能滿足這一點，而對各種屏幕適配一遍又顯得略為繁瑣，並且修改也較為麻煩。
通常我們需要的適配是這樣的：
- 百分比布局支持庫。沒有使用過，但是deprecated in API level 26.0.0-beta1。
- ConstraintLayout。百分比支持庫deprecated之後推薦使用的布局，看起來似乎略複雜。
2. 玩家適配方案。廣大玩家的適配目的很明確，目的就是要確保控件在不同屏幕的相對大小一致，看起來一毛一樣的。以一位大神玩家的兩種適配方案為例：
- 方案一。編寫腳本將長度轉換成各分辨率下的長度，缺點是難以覆蓋市麵上的所有分辨率。
- 方案二。AutoLayout支持庫。該庫的想法非常好：對照設計圖，使用px編寫布局，不影響預覽；繪製階段將對應設計圖的px數值計算轉換為當前屏幕下適配的大小；為簡化接入，inflate時自動將各Layout轉換為對應的AutoLayout，從而不需要在所有的xml中更改。但是同時該庫也存在以下等問題：
- 擴展性較差。對於每一種ViewGroup都要對應編寫對應的AutoLayout進行擴展，對於各View的每個需要適配的屬性都要編寫代碼進行適配擴展；
- 在onMeasure階段進行數值計算。這對於非LayoutParams中的屬性存在較多不合理之處。比如在onMeasure時對TextView的textSize進行換算並setTextSize，那麼玩家在代碼中動態設置的textSize都會失效，因為在每次onMesasure時都會重新被AutoLayout重新設置覆蓋。
- issue較多並且作者已不再維護。
二、想法
個人覺得AutoLayout的設計思想非常優秀，但是將LayoutParams與屬性作為切入口在mesure過程中進行轉換計算的方案存在效率與擴展性等方麵的問題。那麼Android計算長度的收口在哪裏，能不能在Android計算長度時進行換算呢？如果能在Android計算長度時進行換算，那麼就不需要一係列多餘的計算以及適配，一切問題就都迎刃而解了。
經過一番尋覓，發現係統進行長度計算的收口為TypedValue中的applyDimension函數。
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的，不用反射就能修改； - 而這個DisplayMetrics從哪來？從源碼中可以看出一般為
mContext.getResources().getDisplayMetrics()，這個mContext即為所在Activity； - Activity中所拿到的DisplayMetrics雖然與Application中拿到的DisplayMetrics雖然不是一個示例，但是所有數值都相同，在Application中進行更改也會影響到所有Activity中；
- Configuration的變化會導致DisplayMetrics的重新計算還原，需要handle；
- px,dp與sp都是平時常用的單位，而pt,in與mm幾乎沒有看見過，從這些不常見的單位下手正好可以不影響其他常用的單位。
基於以上幾點，遍有了以下方案。
三、方案
使用冷門的pt作為長度單位。
編寫xml時完全對照設計稿上的尺寸來編寫，隻不過單位換為pt。
需要在代碼中動態轉換成px時使用TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_PT, value, metrics)。
預覽。以1334x750位為例，創建一個長為1334磅，寬為750磅的設備作為預覽，經換算約為21.5英寸((sqrt(1334^2+750^2))/72)。預覽時選擇這個設備即可。
在Application的onCreate中與onConfigurationChanged中更改DisplayMetrics：
public class MyApplication extends Application{
public final static float DESIGN_WIDTH = 750;
@Override
public void onCreate() {
super.onCreate();
resetDensity();
}
@Override
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
resetDensity();
}
public void resetDensity(){
Point size = new Point();
((WindowManager)getSystemService(WINDOW_SERVICE)).getDefaultDisplay().getSize(size);
getResources().getDisplayMetrics().xdpi = size.x/DESIGN_WIDTH*72f;
}
其中DESIGN_WIDTH是設計圖的寬度。
這樣繪製出來的頁麵就跟設計圖幾乎完全一樣，無論大小屏上看起來就隻是將設計圖縮放之後的結果。
適配前：
適配後：
最後更新：2017-07-26 17:32:36