1. 程式人生 > >一種粗暴快速的Android全螢幕適配方案

一種粗暴快速的Android全螢幕適配方案

0?wx_fmt=gif&wxfrom=5&wx_lazy=1

熱文導讀 | 點選標題閱讀

作者:firedamp

來源:http://www.apkbus.com/blog-177177-76719.html

一、現狀

由於Android碎片化嚴重,螢幕適配一直是開發中較為頭疼的問題。面對市面上五花八門的螢幕大小與解析度,Android基於dp與res目錄名稱來適配的方案已無法滿足一次編寫全螢幕適配的需求,為了達到最優的視覺效果,開發過程中總是需要花費較多資源進行適配。也有開發者給出了一些自己的解決方案。首先來分析一下一些常見的解決方案的現狀:

1.官方適配方案  

  • dp。dp是Android開發中特有的一個單位。與px不同,dp是基於螢幕畫素密度的一種單位。在密度低的螢幕上或許1dp=1px,但在密度高的螢幕上可能1dp=4px。編寫佈局xml時,如果一個控制元件的長寬都使用dp來指定,那麼能確保該控制元件在各種大小與解析度的螢幕下的絕對大小都大致相當。也就是說無論在pad下還是大小屏手機下,我們實際看到的該控制元件的大小是差不多的:

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

  • 資源目錄名。上圖可見雖然使用dp確保了控制元件在不同螢幕中的絕對大小一致。這樣的好處在於,在大小相近的螢幕中,無論解析度多大都不會對佈局造成影響;但是當螢幕大小相差較大時,僅保證控制元件的絕對大小看起來就有些問題了。在res目錄下可以給各資源目錄都加上例如’-1920x1080’等字尾來適配不同的螢幕,具體規則可見官網文件。這樣可以針對不同的螢幕提供不同的佈局,甚至針對pad與手機提供兩套完全不同的佈局樣式。但是通常情況下,設計師並不會對不同螢幕提供不同的設計圖,他們的需求僅僅是不同螢幕下控制元件對螢幕的相對大小一致,所以dp並不能滿足這一點,而對各種螢幕適配一遍又顯得略為繁瑣,並且修改也較為麻煩。通常我們需要的適配是這樣的:

0?wx_fmt=png

  • 百分比佈局支援庫。沒有使用過,但是deprecated in API level 26.0.0-beta1。

  • ConstraintLayout。百分比支援庫deprecated之後推薦使用的佈局,看起來似乎略複雜。

2.玩家適配方案

        廣大玩家的適配目的很明確,目的就是要確保控制元件在不同螢幕的相對大小一致,看起來一毛一樣的。以一位大神玩家的兩種適配方案為例:

  • 擴充套件性較差。對於每一種ViewGroup都要對應編寫對應的AutoLayout進行擴充套件,對於各View的每個需要適配的屬性都要編寫程式碼進行適配擴充套件;

  • 在onMeasure階段進行數值計算。消耗效能,並且這對於非LayoutParams中的屬性存在較多不合理之處。比如在onMeasure時對TextView的textSize進行換算並setTextSize,那麼玩家在程式碼中動態設定的textSize都會失效,因為在每次onMesasure時都會重新被AutoLayout重新設定覆蓋。

  • issue較多並且作者已不再維護。

  • 方案一。編寫指令碼將長度轉換成各解析度下的長度,缺點是難以覆蓋市面上的所有解析度。

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

二、想法

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

通常的一個簡單的適配需求是:假如設計圖寬度為200,一個控制元件在設計圖上標註的長度為3,那麼該控制元件長度相當於總寬度的3/200,那麼我們希望在任何大小的螢幕上該控制元件所表現的長度都為螢幕寬度的3/200。

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

經過一番尋覓,發現系統進行長度計算的收口為TypedValue中的applyDimension函式,傳入單位與value將其計算為對應的px數值。

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的原意是長度單位磅,根據當前螢幕與設計圖尺寸將metrics.xdpi進行修改就可以實現將pt這個單位重定義成我們所需要的相對長度單位,使修改之後計算出的1pt實際對應的px/螢幕寬度px=1px/設計圖寬度px

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

  • 橫豎屏切換等Configuration的變化會導致DisplayMetrics的重新計算還原;

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

基於以上幾點,便有了以下方案。

三、方案

本適配方案的目標是:完全按照設計圖上標註的尺寸來編寫頁面,所編寫的頁面在所有大小與解析度的螢幕上都表現一致,即控制元件在所有螢幕上相對於整個螢幕的相對大小都一致(看起來只是將設計圖等比縮放至螢幕寬度大小)。

  • 核心。使用冷門的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)。預覽時選擇這個裝置即可。

0?wx_fmt=jpeg

0?wx_fmt=jpeg

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

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

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

適配前(左圖API19 400x800, 右圖API24 1440x2560):

0?wx_fmt=jpeg

適配後(左圖API19 400x800, 右圖API24 1440x2560):

0?wx_fmt=jpeg

雖然方案比較簡單,但是為了方便使用也整理成了一個library,程式碼及demo見https://github.com/Firedamp/Rudeness

歡迎大家一起討論完善,如有問題請統一提github issue方便彙總與處理。

Java和Android架構

微信掃描或者點選下方二維碼領取Android\Python\AI\Java等高階進階資源

關注後回覆“百度”、“阿里”、“騰訊”、“資源”有驚喜

640?wx_fmt=jpeg

公眾號:JANiubility

歡迎加入我們的Java和Android架構圈,已有近1000人加入學習交流,更多學習資源更新,更多交流進步

640?wx_fmt=png

更多學習資料點選下面的“閱讀原文”獲取

0?wx_fmt=gif