簡介： 傳統的多終端适配計劃，是為大尺寸Pad開發一個特定的HD版本。然而目前反對Android零碎的設施類型越來越豐盛，不同類型的設施尺寸也越來越多樣化，特定的HD版本并不能适配所有設施尺寸。App如何在這麼多尺寸的設施上，為使用者提供較為統一的浏覽體驗？阿裡巴巴娛樂技術 叮東 将分享優酷APP響應式的技術實作和落地辦法，心願對所有APP的開發同學有所啟發。
Android響應式計劃
響應式的外圍是拉通多終端的适配規定，開發一套界面，一個APP相容多尺寸終端裝置的顯示，可能依據使用者的行為以及設施的環境(螢幕尺寸、螢幕方向、是否分屏等)進行相應的頁面布局以及容器尺寸的調整，為使用者提供更加舒服的界面和更好的使用者體驗。
1 響應式SDK
App的每個頁面反對響應式，開發成本是很高的。
響應式SDK，就是為了解決App在不同尺寸設施下的适配問題，把設施的螢幕資訊、容器布局規定(列數、尺寸)、業務資料二次加工等行為進行對立治理，以适應新的螢幕尺寸。
2 加載流程設計
通用的頁面加載流程，通常都是從資料傳回開始，資料解析實作後，進行頁面布局渲染以及容器布局渲染。響應式在通用加載流程的根底上，退出了響應式狀态變動告訴、響應式資料剪裁、響應式頁面布局、響應式容器布局等流程。
具體加載的流程分為兩種狀況：
使用者申請資料
螢幕尺寸發生變化
3 架構設計
優酷各個業務開發團隊，應用了對立的業務架構，咱們在對立架構的根底上進行響應式适配，提供了響應式SDK，拉通各個業務方不同頁面的适配規定，確定了适配成果的一緻性，同時提供了根底的響應式控件，升高業務方的接入老本，那麼響應式架構具體是怎麼實作的呢？
從構造上看，響應式由優酷對立架構、響應式SDK、響應式頁面布局、響應式容器布局四局部互相配合實作。在這些根底上撐持了首頁、頻道頁、播放頁、會員頁、搜尋、集體核心等泛濫的業務場景。
優酷對立架構和響應式SDK，提供響應式架構能力。
響應式頁面布局、響應式容器布局，提供響應式參考實作。
4 資料二次加工
響應式并不是簡略的将現有Phone端的業務資料，投放到Pad、折疊屏上，單純的進行UI頁面适配。想要在不同尺寸設施上都能取得良好的适配成果，須要對Phone端的業務資料二次加工，進行資料過濾、資料映射、資料合并、資料補全等操作，能力更好的适配Pad和折疊屏。
響應式SDK隻是負責把資料二次加工的協定規定定下來，具體的資料二次加工邏輯須要業務方本人實作。優酷的對立架構提供了資料切面的能力，在切面上減少資料二次解決的邏輯，實作了對立的資料處理。
資料過濾
大尺寸設施上，總會遇到一些簡單的，适配不了的，也不重要的元件，這部分元件能夠依據具體情況過濾解決，例如：下圖中的weex元件，在Pad上間接過濾掉，不顯示。
資料映射
存在一些帶互動的簡單元件或者Pad上适配成果較差的元件，能夠間接映射成其餘已适配的元件。例如：下圖中的帶視訊預覽的預約元件映射成一般的預約元件。
資料合并
相鄰的兩個元件，其中有一個元件無奈很好的适配大尺寸Pad，能夠嘗試将其資料合并到其餘元件内。
例如：下圖中第1個元件寬度鋪滿頁面寬度，在大尺寸上無奈适配，第2個元件通過批改列數、尺寸就能夠适配。Pad豎屏下，将第一個元件插入到第二個元件的首位，進行資料合并，依照第二個元件的進行适配，顯示為3列2行，達到很好的适配成果。
資料補全
在橫豎屏切換過程中，局部元件會遇到元件的數量，無奈鋪滿螢幕的寬度，導緻呈現留白的問題。
例如：把手機上的6條資料，間接投放到Pad橫屏下，就會呈現下圖的留白問題：
為了解決這一類資料缺失的問題，咱們抉擇的解法是服務端多下發一部分業務資料，用戶端依據具體的螢幕尺寸，動靜調整顯示的個數，確定顯示成果。
例如：下圖中手機上顯示2列3行，共6條資料，到了Pad豎屏上顯示3列2行，共6條資料，到了Pad橫屏上會補全2條資料，顯示4列2行，共8條資料。
5 頁面響應式
響應式狀态
響應式狀态是頁面響應式最根底也是最重要的一個能力，像橫豎屏切換、分屏模式、折疊屏折疊關上，都會導緻頁面的寬高發生變化，産生不同的響應式狀态，頁面内的内容會進行從新布局以及元件尺寸調整，以适應頁面尺寸的變動，鋪滿螢幕，達到更好的顯示成果。
橫豎屏切換：
分屏模式：
折疊屏：
響應式狀态治理
響應式狀态與Activity頁面的生命周期保持一緻，不同頁面響應式狀态可能不統一。響應式SDK提供了ResponsiveActivity、ResponsiveFragment兩個基類，ResponsiveActivity對立封裝了響應式的狀态變動。當螢幕尺寸産生扭轉時，ResponsiveActivity和ResponsiveFragment會回調onResponsiveLayout辦法，業務方接到onResponsiveLayout的告訴，被動周遊以後頁面内的所有容器，依據響應式狀态，動靜批改容器的布局、布局列數、尺寸等，從新渲染以後頁面。
因為優酷應用了對立架構，依據響應式狀态動靜批改頁面内所有容器的邏輯，對立在架構外部解決，防止了業務方的批改，升高了接入老本。
protectedvoidonResponsiveLayout(ConfigurationnewConfig,intresponsiveLayoutState,booleanresponsiveLayoutStateChanged) {
}
擷取響應式狀态
響應式狀态的定義，須要有一個具體計算的規定，在所有尺寸的設施上都依照對立的規定進行狀态辨識，那麼不同的響應式狀态是如何辨識的呢？
首先定義規範手機螢幕的實體寬度為400dp(通過大量手機設施調試采樣之後取得的手機規範實體尺寸經驗值)，那麼響應式狀态的變動，由兩個比例門檻值決定，一個是頁面實體寬度與規範實體寬度的比例門檻值1.67倍(實體寬度 = 像素寬度÷螢幕密度)，另一個是頁面高度與頁面寬度的比例門檻值1.25倍。那麼這兩個比例門檻值是如何得來的呢？
(1)1.67倍是怎麼來的呢？
在播放頁的适配過程中，須要适配左右分欄的顯示，咱們認為左側播放器的寬度是規範實體寬度，那麼整個頁面的寬度就是規範實體寬度的1.67倍，這樣左側播放器有足夠的空間保障視訊播放的體驗，右側的也有足夠的空間保障評論的顯示成果。
(2)1.25倍是怎麼來的呢？
上圖列舉了豎屏華為Pad上，頁面高度是頁面寬度的1.6倍，播放器下方的視訊内容操作區，顯示的視訊内容是足夠多的。如果頁面高度小于頁面寬度的1.25倍，就會擠壓視訊内容操作區的高度，導緻顯示進去的視訊内容過少，影響使用者體驗。
當頁面實體寬度大于規範實體寬度的1.67倍，同時頁面高度小于等于頁面寬度的1.25倍，即為大屏狀态，其餘狀況則為小屏狀态。
不同的響應式狀态
目前反對了小屏布局和大屏布局兩種狀态。
(1)小屏布局狀态
折疊屏折疊、折疊屏分屏、Pad豎屏：
(2)大屏布局狀态
折疊屏關上、Pad橫屏：
6 容器響應式
容器響應式，次要解決在頁面尺寸發生變化時，動靜調整容器布局的列數以及坑位的尺寸，優酷對立架構提供了罕用的響應式容器布局：輪播布局、網格布局、橫劃布局、瀑布流布局。業務方能夠疾速實作響應式的成果。
容器适配列數、尺寸的成果
列數适配
同一個容器，在不同的尺寸頁面下，會依據頁面的實體寬度動靜适配，顯示為不同的列數。
網絡布局、橫劃布局、瀑布流布局都采納這一套列數适配的規定：
響應式适配後的列數 = 以後螢幕寬度÷(規範螢幕寬度÷規範螢幕寬度下的元件列數 )
響應式适配後的列數，并不能解決Pad橫屏上局部元件列數過多，顯示過密的問題，為了解決這類問題，提供了列數二次适配的能力。
如下圖所示，左側是間接依據規定算進去的Pad橫屏下的列數8列，過于密集，顯示成果不好，右側是列數二次調整後，顯示為6列。
适配成果：
控件尺寸适配
因為不同螢幕尺寸下，容器外部會動靜調整顯示不同的列數，導緻控件的尺寸也會發生變化，那麼如何适配控件尺寸的動态變化呢，響應式根底控件可能很好的解決這一類問題。
響應式根底控件，外部封裝了響應式容器尺寸的适配規定，通過ratioType來定義不同适配規定下控件寬高的計算邏輯，業務方隻須要批改最外層的布局控件，通過設定ratioType就能夠疾速搞定寬高适配，升高業務方的适配老本。
提供了ResponsiveConstraintLayout、ResponsiveFrameLayout、ResponsiveLinearLayout、ResponsiveRelativeLayout、ResponsiveRecyclerView等根底響應式容器。
ratioType的寬度計算規定示例(頁面左右邊距和橫間距不變)：
響應式控件寬度 = (以後頁面的寬度 – 左右邊距 – 控件之間的間距總和)÷響應式适配後的列數
總結
随着折疊屏技術的進一步倒退，折疊屏手機會越來越遍及，越來越多的App須要适配到折疊屏手機上，響應式能夠很好的解決折疊屏的适配問題。心願将來更多的APP可能适配響應式，做到一套代碼，運作到不同尺寸的設施上，節約開發成本，晉升開發效力，為不同尺寸的設施帶來與手機版本統一的使用者體驗。