自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

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

移動開發(fā) Android
由于Android碎片化嚴(yán)重,屏幕適配一直是開發(fā)中較為頭疼的問題。面對市面上五花八門的屏幕大小與分辨率,Android基于dp與res目錄名稱來適配的方案已無法滿足一次編寫全屏幕適配的需求,為了達到最優(yōu)的視覺效果,開發(fā)過程中總是需要花費較多資源進行適配。

一、現(xiàn)狀

由于Android碎片化嚴(yán)重,屏幕適配一直是開發(fā)中較為頭疼的問題。面對市面上五花八門的屏幕大小與分辨率,Android基于dp與res目錄名稱來適配的方案已無法滿足一次編寫全屏幕適配的需求,為了達到***的視覺效果,開發(fā)過程中總是需要花費較多資源進行適配。也有開發(fā)者給出了一些自己的解決方案。首先來分析一下一些常見的解決方案的現(xiàn)狀: 1. 官方適配方案 – dp。dp是Android開發(fā)中特有的一個單位。與px不同,dp是基于屏幕像素密度的一種單位。在密度低的屏幕上或許1dp=1px,但在密度高的屏幕上可能1dp=4px。編寫布局xml時,如果一個控件的長寬都使用dp來指定,那么能確保該控件在各種大小與分辨率的屏幕下的絕對大小都大致相當(dāng)。也就是說無論在pad下還是大小屏手機下,我們實際看到的該控件的大小是差不多的:

 

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

 

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

- ConstraintLayout。百分比支持庫deprecated之后推薦使用的布局,看起來似乎略復(fù)雜。 2. 玩家適配方案。廣大玩家的適配目的很明確,目的就是要確??丶诓煌聊坏南鄬Υ笮∫恢拢雌饋硪幻粯拥?。以一位大神玩家的兩種適配方案為例:

- 方案一。編寫腳本將長度轉(zhuǎn)換成各分辨率下的長度,缺點是難以覆蓋市面上的所有分辨率。

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

- 擴展性較差。對于每一種ViewGroup都要對應(yīng)編寫對應(yīng)的AutoLayout進行擴展,對于各View的每個需要適配的屬性都要編寫代碼進行適配擴展; – 在onMeasure階段進行數(shù)值計算。這對于非LayoutParams中的屬性存在較多不合理之處。比如在onMeasure時對TextView的textSize進行換算并setTextSize,那么玩家在代碼中動態(tài)設(shè)置的textSize都會失效,因為在每次onMesasure時都會重新被AutoLayout重新設(shè)置覆蓋。 – issue較多并且作者已不再維護。

二、想法

個人覺得AutoLayout的設(shè)計思想非常優(yōu)秀,但是將LayoutParams與屬性作為切入口在mesure過程中進行轉(zhuǎn)換計算的方案存在效率與擴展性等方面的問題。那么Android計算長度的收口在哪里,能不能在Android計算長度時進行換算呢?如果能在Android計算長度時進行換算,那么就不需要一系列多余的計算以及適配,一切問題就都迎刃而解了。 經(jīng)過一番尋覓,發(fā)現(xiàn)系統(tǒng)進行長度計算的收口為TypedValue中的applyDimension函數(shù),傳入單位與value將其計算為對應(yīng)的px數(shù)值。

  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的,不用反射就能修改;
  • 而這個DisplayMetrics從哪來?從源碼中可以看出一般為mContext.getResources().getDisplayMetrics(),這個mContext即為所在Activity;
  • Activity中所拿到的DisplayMetrics與Application中拿到的DisplayMetrics雖然不是一個實例,但是所有數(shù)值都相同,在Application中進行更改也會影響到所有Activity中;
  • 橫豎屏切換等Configuration的變化會導(dǎo)致DisplayMetrics的重新計算還原,需要重新處理;
  • px,dp與sp都是平時常用的單位,而pt,in與mm幾乎沒有看見過,從這些不常見的單位下手正好可以不影響其他常用的單位;
  • pt的原意是長度單位磅,根據(jù)當(dāng)前屏幕與設(shè)計圖尺寸將metrics.xdpi進行修改就可以實現(xiàn)將pt這個單位重定義成我們所需要的相對長度單位,使修改之后計算出的1pt實際對應(yīng)的px/屏幕寬度px=1px/設(shè)計圖寬度px。

基于以上幾點,遍有了以下方案。

三、方案

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

  • 核心。使用冷門的pt作為長度單位。
  • 繪制。編寫xml時完全對照設(shè)計稿上的尺寸來編寫,只不過單位換為pt。 如果需要在代碼中動態(tài)轉(zhuǎn)換成px的話,使用TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_PT, value, metrics)。
  • 預(yù)覽。實時預(yù)覽時繪制頁面是很重要的一個環(huán)節(jié)。以1334×750的設(shè)計圖為例,為了實現(xiàn)于正常繪制時一樣的預(yù)覽功能,創(chuàng)建一個長為1334磅,寬為750磅的設(shè)備作為預(yù)覽,經(jīng)換算約為21.5英寸((sqrt(1334^2+750^2))/72)。預(yù)覽時選擇這個設(shè)備即可。

 

 

  • 代碼處理。代碼處理有兩種方案:如果所有頁面的設(shè)計圖尺寸都一樣,則在Applicalition中的onCreate中與onConfigurationChanged中處理即可;如果每個頁面的設(shè)計圖尺寸不一樣,則需要在每個activity的onCreate中處理(Activity中不需要處理onConfigurationChanged,因為配置變化頁面會重新生成)。
    • 全局處理方案。在Application的onCreate中與onConfigurationChanged中更改DisplayMetrics(其中DESIGN_WIDTH是繪制頁面時參照的設(shè)計圖寬度): 
  1. public class MyApplication extends Application{ 
  2.  
  3. public final static float DESIGN_WIDTH = 750; //繪制頁面時參照的設(shè)計圖寬度 
  4.  
  5. @Override 
  6. public void onCreate() { 
  7.     super.onCreate(); 
  8.  
  9.     resetDensity(); 
  10.  
  11. @Override 
  12. public void onConfigurationChanged(Configuration newConfig) { 
  13.     super.onConfigurationChanged(newConfig); 
  14.     resetDensity(); 
  15.  
  16. public void resetDensity(){ 
  17.     Point size = new Point(); 
  18.     ((WindowManager)getSystemService(WINDOW_SERVICE)).getDefaultDisplay().getSize(size); 
  19.  
  20.     getResources().getDisplayMetrics().xdpi = size.x/DESIGN_WIDTH*72f; 
  21.  

這樣繪制出來的頁面就跟設(shè)計圖幾乎完全一樣,無論大小屏上看起來就只是將設(shè)計圖縮放之后的結(jié)果。 適配前(左圖API19 400×800, 右圖API24 1440×2560):

 

適配后(左圖API19 400×800, 右圖API24 1440×2560):  

責(zé)任編輯:龐桂玉 來源: Android開發(fā)中文站
相關(guān)推薦

2018-05-04 15:26:10

Android開發(fā)全屏幕

2009-07-16 16:09:51

Swing全屏幕模式

2009-12-24 14:38:52

WPF全屏幕窗口

2013-07-03 13:54:26

jQuery

2022-05-12 10:36:10

移動方案

2011-07-04 17:53:48

快速測試

2013-05-22 09:49:36

2022-07-13 11:49:18

接口遷移方案

2024-04-16 13:56:09

移動端安全區(qū)域iOS

2023-07-18 07:23:11

方案payloadrequest

2016-03-21 13:24:22

apk安卓開發(fā)

2009-11-10 14:52:13

VB.NET實現(xiàn)

2022-07-14 10:02:00

vivoUI適配開發(fā)人員

2017-02-14 17:29:42

Android毛玻璃虛化效果

2020-12-09 10:15:34

Pythonweb代碼

2014-12-01 09:54:40

JavaScript

2020-12-23 10:10:23

Pythonweb代碼

2022-06-22 09:44:41

Python文件代碼

2022-07-07 10:33:27

Python姿勢代碼

2018-01-31 09:23:57

惡意軟件代碼方法
點贊
收藏

51CTO技術(shù)棧公眾號