[[345928]]

阿里妹導(dǎo)讀：傳統(tǒng)的多終端適配方案，是為大尺寸Pad開發(fā)一個(gè)特定的HD版本。但是目前支持Android系統(tǒng)的設(shè)備類型越來越豐富，不同類型的設(shè)備尺寸也越來越多樣化，特定的HD版本并不能適配所有設(shè)備尺寸。App如何在這么多尺寸的設(shè)備上，為用戶提供較為一致的瀏覽體驗(yàn)?阿里巴巴文娛技術(shù) 叮東 將分享優(yōu)酷APP響應(yīng)式的技術(shù)實(shí)現(xiàn)和落地方法，希望對(duì)所有APP的開發(fā)同學(xué)有所啟發(fā)。

Android響應(yīng)式方案

響應(yīng)式的核心是拉通多終端的適配規(guī)則，開發(fā)一套界面，一個(gè)APP兼容多尺寸終端設(shè)備的顯示，能夠根據(jù)用戶的行為以及設(shè)備的環(huán)境(屏幕尺寸、屏幕方向、是否分屏等)進(jìn)行相應(yīng)的頁(yè)面布局以及容器尺寸的調(diào)整，為用戶提供更加舒適的界面和更好的用戶體驗(yàn)。

[[345930]]

1 響應(yīng)式SDK

App的每個(gè)頁(yè)面支持響應(yīng)式，開發(fā)成本是很高的。

響應(yīng)式SDK，就是為了解決App在不同尺寸設(shè)備下的適配問題，把設(shè)備的屏幕信息、容器布局規(guī)則(列數(shù)、尺寸)、業(yè)務(wù)數(shù)據(jù)二次加工等行為進(jìn)行統(tǒng)一管理，以適應(yīng)新的屏幕尺寸。

2 加載流程設(shè)計(jì)

通用的頁(yè)面加載流程，通常都是從數(shù)據(jù)返回開始，數(shù)據(jù)解析完成后，進(jìn)行頁(yè)面布局渲染以及容器布局渲染。響應(yīng)式在通用加載流程的基礎(chǔ)上，加入了響應(yīng)式狀態(tài)變化通知、響應(yīng)式數(shù)據(jù)剪裁、響應(yīng)式頁(yè)面布局、響應(yīng)式容器布局等流程。

具體加載的流程分為兩種情況：

• 用戶請(qǐng)求數(shù)據(jù)
• 屏幕尺寸發(fā)生變化

3 架構(gòu)設(shè)計(jì)

優(yōu)酷各個(gè)業(yè)務(wù)開發(fā)團(tuán)隊(duì)，使用了統(tǒng)一的業(yè)務(wù)架構(gòu)，我們?cè)诮y(tǒng)一架構(gòu)的基礎(chǔ)上進(jìn)行響應(yīng)式適配，提供了響應(yīng)式SDK，拉通各個(gè)業(yè)務(wù)方不同頁(yè)面的適配規(guī)則，確保了適配效果的一致性，同時(shí)提供了基礎(chǔ)的響應(yīng)式控件，降低業(yè)務(wù)方的接入成本，那么響應(yīng)式架構(gòu)具體是怎么實(shí)現(xiàn)的呢?

從結(jié)構(gòu)上看，響應(yīng)式由優(yōu)酷統(tǒng)一架構(gòu)、響應(yīng)式SDK、響應(yīng)式頁(yè)面布局、響應(yīng)式容器布局四部分相互配合完成。在這些基礎(chǔ)上支撐了首頁(yè)、頻道頁(yè)、播放頁(yè)、會(huì)員頁(yè)、搜索、個(gè)人中心等眾多的業(yè)務(wù)場(chǎng)景。

優(yōu)酷統(tǒng)一架構(gòu)和響應(yīng)式SDK，提供響應(yīng)式架構(gòu)能力。

響應(yīng)式頁(yè)面布局、響應(yīng)式容器布局，提供響應(yīng)式參考實(shí)現(xiàn)。

4 數(shù)據(jù)二次加工

響應(yīng)式并不是簡(jiǎn)單的將現(xiàn)有Phone端的業(yè)務(wù)數(shù)據(jù)，投放到Pad、折疊屏上，單純的進(jìn)行UI頁(yè)面適配。想要在不同尺寸設(shè)備上都能獲得良好的適配效果，需要對(duì)Phone端的業(yè)務(wù)數(shù)據(jù)二次加工，進(jìn)行數(shù)據(jù)過濾、數(shù)據(jù)映射、數(shù)據(jù)合并、數(shù)據(jù)補(bǔ)全等操作，才能更好的適配Pad和折疊屏。

響應(yīng)式SDK只是負(fù)責(zé)把數(shù)據(jù)二次加工的協(xié)議規(guī)則定下來，具體的數(shù)據(jù)二次加工邏輯需要業(yè)務(wù)方自己實(shí)現(xiàn)。優(yōu)酷的統(tǒng)一架構(gòu)提供了數(shù)據(jù)切面的能力，在切面上增加數(shù)據(jù)二次處理的邏輯，實(shí)現(xiàn)了統(tǒng)一的數(shù)據(jù)處理。

數(shù)據(jù)過濾

大尺寸設(shè)備上，總會(huì)遇到一些復(fù)雜的，適配不了的，也不重要的組件，這部分組件可以根據(jù)具體情況過濾處理，例如：下圖中的weex組件，在Pad上直接過濾掉，不顯示。

數(shù)據(jù)映射

存在一些帶交互的復(fù)雜組件或者Pad上適配效果較差的組件，可以直接映射成其他已適配的組件。例如：下圖中的帶視頻預(yù)覽的預(yù)約組件映射成普通的預(yù)約組件。

數(shù)據(jù)合并

相鄰的兩個(gè)組件，其中有一個(gè)組件無法很好的適配大尺寸Pad，可以嘗試將其數(shù)據(jù)合并到其他組件內(nèi)。

例如：下圖中第1個(gè)組件寬度鋪滿頁(yè)面寬度，在大尺寸上無法適配，第2個(gè)組件通過修改列數(shù)、尺寸就可以適配。Pad豎屏下，將第一個(gè)組件插入到第二個(gè)組件的首位，進(jìn)行數(shù)據(jù)合并，按照第二個(gè)組件的進(jìn)行適配，顯示為3列2行，達(dá)到很好的適配效果。

數(shù)據(jù)補(bǔ)全

在橫豎屏切換過程中，部分組件會(huì)遇到組件的數(shù)量，無法鋪滿屏幕的寬度，導(dǎo)致出現(xiàn)留白的問題。

例如：把手機(jī)上的6條數(shù)據(jù)，直接投放到Pad橫屏下，就會(huì)出現(xiàn)下圖的留白問題：

為了解決這一類數(shù)據(jù)缺失的問題，我們選擇的解法是服務(wù)端多下發(fā)一部分業(yè)務(wù)數(shù)據(jù)，客戶端根據(jù)具體的屏幕尺寸，動(dòng)態(tài)調(diào)整顯示的個(gè)數(shù)，確保顯示效果。

例如：下圖中手機(jī)上顯示2列3行，共6條數(shù)據(jù)，到了Pad豎屏上顯示3列2行，共6條數(shù)據(jù)，到了Pad橫屏上會(huì)補(bǔ)全2條數(shù)據(jù)，顯示4列2行，共8條數(shù)據(jù)。

5 頁(yè)面響應(yīng)式

響應(yīng)式狀態(tài)

響應(yīng)式狀態(tài)是頁(yè)面響應(yīng)式最基礎(chǔ)也是最重要的一個(gè)能力，像橫豎屏切換、分屏模式、折疊屏折疊打開，都會(huì)導(dǎo)致頁(yè)面的寬高發(fā)生變化，產(chǎn)生不同的響應(yīng)式狀態(tài)，頁(yè)面內(nèi)的內(nèi)容會(huì)進(jìn)行重新布局以及組件尺寸調(diào)整，以適應(yīng)頁(yè)面尺寸的變化，鋪滿屏幕，達(dá)到更好的顯示效果。

橫豎屏切換：

分屏模式：

折疊屏：

響應(yīng)式狀態(tài)管理

響應(yīng)式狀態(tài)與Activity頁(yè)面的生命周期保持一致，不同頁(yè)面響應(yīng)式狀態(tài)可能不一致。響應(yīng)式SDK提供了ResponsiveActivity、ResponsiveFragment兩個(gè)基類，ResponsiveActivity統(tǒng)一封裝了響應(yīng)式的狀態(tài)變化。當(dāng)屏幕尺寸發(fā)生改變時(shí)，ResponsiveActivity和ResponsiveFragment會(huì)回調(diào)onResponsiveLayout方法，業(yè)務(wù)方接到onResponsiveLayout的通知，主動(dòng)遍歷當(dāng)前頁(yè)面內(nèi)的所有容器，根據(jù)響應(yīng)式狀態(tài)，動(dòng)態(tài)修改容器的布局、布局列數(shù)、尺寸等，重新渲染當(dāng)前頁(yè)面。

由于優(yōu)酷使用了統(tǒng)一框架，根據(jù)響應(yīng)式狀態(tài)動(dòng)態(tài)修改頁(yè)面內(nèi)所有容器的邏輯，統(tǒng)一在框架內(nèi)部處理，避免了業(yè)務(wù)方的修改，降低了接入成本。

/**   
 *響應(yīng)式狀態(tài)回調(diào)   
 *   
 * @param newConfig                   配置信息   
 * @param responsiveLayoutState       當(dāng)前響應(yīng)式狀態(tài)   
 * @param responsiveLayoutStateChanged響應(yīng)式狀態(tài)是否已發(fā)生改變  
 */ 
protectedvoidonResponsiveLayout(ConfigurationnewConfig,intresponsiveLayoutState,booleanresponsiveLayoutStateChanged) { 
 
} 

獲取響應(yīng)式狀態(tài)

響應(yīng)式狀態(tài)的定義，需要有一個(gè)具體計(jì)算的規(guī)則，在所有尺寸的設(shè)備上都按照統(tǒng)一的規(guī)則進(jìn)行狀態(tài)區(qū)分，那么不同的響應(yīng)式狀態(tài)是如何區(qū)分的呢?

首先定義標(biāo)準(zhǔn)手機(jī)屏幕的物理寬度為400dp(經(jīng)過大量手機(jī)設(shè)備調(diào)試采樣之后獲得的手機(jī)標(biāo)準(zhǔn)物理尺寸經(jīng)驗(yàn)值)，那么響應(yīng)式狀態(tài)的變化，由兩個(gè)比例閾值決定，一個(gè)是頁(yè)面物理寬度與標(biāo)準(zhǔn)物理寬度的比例閾值1.67倍(物理寬度 = 像素寬度÷屏幕密度)，另一個(gè)是頁(yè)面高度與頁(yè)面寬度的比例閾值1.25倍。那么這兩個(gè)比例閾值是如何得來的呢?

(1)1.67倍是怎么來的呢?

在播放頁(yè)的適配過程中，需要適配左右分欄的顯示，我們認(rèn)為左側(cè)播放器的寬度是標(biāo)準(zhǔn)物理寬度，那么整個(gè)頁(yè)面的寬度就是標(biāo)準(zhǔn)物理寬度的1.67倍，這樣左側(cè)播放器有足夠的空間保障視頻播放的體驗(yàn)，右側(cè)的也有足夠的空間保障評(píng)論的顯示效果。 (2)1.25倍是怎么來的呢?

上圖列舉了豎屏華為Pad上，頁(yè)面高度是頁(yè)面寬度的1.6倍，播放器下方的視頻內(nèi)容操作區(qū)，顯示的視頻內(nèi)容是足夠多的。如果頁(yè)面高度小于頁(yè)面寬度的1.25倍，就會(huì)擠壓視頻內(nèi)容操作區(qū)的高度，導(dǎo)致顯示出來的視頻內(nèi)容過少，影響用戶體驗(yàn)。

當(dāng)頁(yè)面物理寬度大于標(biāo)準(zhǔn)物理寬度的1.67倍，同時(shí)頁(yè)面高度小于等于頁(yè)面寬度的1.25倍，即為大屏狀態(tài)，其他情況則為小屏狀態(tài)。 不同的響應(yīng)式狀態(tài)

目前支持了小屏布局和大屏布局兩種狀態(tài)。 (1)小屏布局狀態(tài)

折疊屏折疊、折疊屏分屏、Pad豎屏：

(2)大屏布局狀態(tài)

折疊屏打開、Pad橫屏：

6 容器響應(yīng)式

容器響應(yīng)式，主要解決在頁(yè)面尺寸發(fā)生變化時(shí)，動(dòng)態(tài)調(diào)整容器布局的列數(shù)以及坑位的尺寸，優(yōu)酷統(tǒng)一架構(gòu)提供了常用的響應(yīng)式容器布局：輪播布局、網(wǎng)格布局、橫劃布局、瀑布流布局。業(yè)務(wù)方可以快速實(shí)現(xiàn)響應(yīng)式的效果。

容器適配列數(shù)、尺寸的效果

列數(shù)適配

同一個(gè)容器，在不同的尺寸頁(yè)面下，會(huì)根據(jù)頁(yè)面的物理寬度動(dòng)態(tài)適配，顯示為不同的列數(shù)。

網(wǎng)絡(luò)布局、橫劃布局、瀑布流布局都采用這一套列數(shù)適配的規(guī)則：

響應(yīng)式適配后的列數(shù) = 當(dāng)前屏幕寬度÷(標(biāo)準(zhǔn)屏幕寬度÷標(biāo)準(zhǔn)屏幕寬度下的組件列數(shù) )

響應(yīng)式適配后的列數(shù)，并不能解決Pad橫屏上部分組件列數(shù)過多，顯示過密的問題，為了解決這類問題，提供了列數(shù)二次適配的能力。

如下圖所示，左側(cè)是直接根據(jù)規(guī)則算出來的Pad橫屏下的列數(shù)8列，過于密集，顯示效果不好，右側(cè)是列數(shù)二次調(diào)整后，顯示為6列。

適配效果：

控件尺寸適配

由于不同屏幕尺寸下，容器內(nèi)部會(huì)動(dòng)態(tài)調(diào)整顯示不同的列數(shù)，導(dǎo)致控件的尺寸也會(huì)發(fā)生變化，那么如何適配控件尺寸的動(dòng)態(tài)變化呢，響應(yīng)式基礎(chǔ)控件能夠很好的解決這一類問題。

響應(yīng)式基礎(chǔ)控件，內(nèi)部封裝了響應(yīng)式容器尺寸的適配規(guī)則，通過ratioType來定義不同適配規(guī)則下控件寬高的計(jì)算邏輯，業(yè)務(wù)方只需要修改最外層的布局控件，通過設(shè)置ratioType就可以快速搞定寬高適配，降低業(yè)務(wù)方的適配成本。

提供了ResponsiveConstraintLayout、ResponsiveFrameLayout、ResponsiveLinearLayout、ResponsiveRelativeLayout、ResponsiveRecyclerView等基礎(chǔ)響應(yīng)式容器。 ratioType的寬度計(jì)算規(guī)則示例(頁(yè)面左右邊距和橫間距不變)：

響應(yīng)式控件寬度 = (當(dāng)前頁(yè)面的寬度 - 左右邊距 - 控件之間的間距總和)÷響應(yīng)式適配后的列數(shù)

總結(jié)

隨著折疊屏技術(shù)的進(jìn)一步發(fā)展，折疊屏手機(jī)會(huì)越來越普及，越來越多的App需要適配到折疊屏手機(jī)上，響應(yīng)式可以很好的解決折疊屏的適配問題。希望未來更多的APP能夠適配響應(yīng)式，做到一套代碼，運(yùn)行到不同尺寸的設(shè)備上，節(jié)約開發(fā)成本，提升開發(fā)效能，為不同尺寸的設(shè)備帶來與手機(jī)版本一致的用戶體驗(yàn)。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文