作者 ｜ vivo 互聯(lián)網(wǎng)客戶端團(tuán)隊(duì)- Xu Jie 

日益新增的機(jī)型，給開發(fā)人員帶來(lái)了很多的適配工作。代碼能不能統(tǒng)一、apk能不能統(tǒng)一、物料如何選取、樣式怎么展示等等都是困擾開發(fā)人員的問題，本方案就是介紹不同機(jī)型的共線方案，打消開發(fā)人員的疑慮。

一、日益紛繁的機(jī)型帶來(lái)的挑戰(zhàn)

1.1  背景

科技是進(jìn)步的，人們對(duì)美的要求也是逐漸提升的，所以才有了現(xiàn)在市面上形形色色的機(jī)型

（1）比如vivo X60手機(jī)采用纖薄曲面屏設(shè)計(jì)，屬于直板機(jī)型。

（2）比如vivo 折疊屏高端手機(jī)，提供更優(yōu)質(zhì)的視覺體驗(yàn)，屬于折疊屏機(jī)型。

（3）比如vivo pad，擁有優(yōu)秀的操作手感和高級(jí)的質(zhì)感，屬于平板機(jī)型。

1.2  我們的挑戰(zhàn)

在此之前，我們主要是為直板手機(jī)去服務(wù)，我們的開發(fā)只要適配這種主流的直板機(jī)器，我們的UI主要去設(shè)計(jì)這種直板手機(jī)的效果圖，我們的產(chǎn)品和運(yùn)營(yíng)主要為這種直板機(jī)型去選擇物料。

可是隨著這種形形色色機(jī)型的出現(xiàn)，那么問題就來(lái)了：

• 開發(fā)人員的適配成本高了，是不是針對(duì)每一種機(jī)型，都要做個(gè)單獨(dú)的應(yīng)用進(jìn)行適配呢？
• UI設(shè)計(jì)師要做的效果圖要多了，是不是要針對(duì)每種機(jī)型都要設(shè)計(jì)一套效果圖呢？
• 產(chǎn)品和運(yùn)營(yíng)需要選擇的物料更受限制了，會(huì)不會(huì)這個(gè)物料在一個(gè)機(jī)器上正常。在其他機(jī)器上就不正常了呢？

為什么這么說(shuō)，下面以開發(fā)者的角度來(lái)做介紹，把我們面臨的問題，做說(shuō)明。

二、 開發(fā)者的窘境

2.1 全機(jī)型適配成本太高

日漸豐富的機(jī)型適配讓我們這些android開發(fā)人員疲于奔命，雖然可以按照要求進(jìn)行適配，但是大屏幕的機(jī)型適配成本依然比較高，因?yàn)檫@些機(jī)型不同于傳統(tǒng)的直板手機(jī)的寬高比例（9:16）。所以有的應(yīng)用干脆就直接兩邊留白，內(nèi)容區(qū)域展示在屏幕正中央，這種效果，當(dāng)然很差。

案例1：某個(gè)視頻APP頁(yè)面，未做pad上的適配，打開之后的效果如下，兩邊大量留白，是不可操作的區(qū)域。

案例2：某新聞資訊類APP，在pad上的適配效果如下，可見的范圍內(nèi)，信息流展示內(nèi)容較少，圖片有拉伸、模糊的問題。

2.2 全機(jī)型適配成本高在哪

上面的案例其實(shí)只是表面的問題之一，作為開發(fā)人員，需要考慮的因素有很多，首先要想到這些機(jī)型有什么特點(diǎn)：

然后才是需要解決的問題：

三、尋找全機(jī)型適配方案之旅

3.1 方案討論與確定

頁(yè)面拉伸、左右留白是現(xiàn)象，這也是用戶的直接體驗(yàn)。那么這就是我們要改善的地方，所以現(xiàn)在就有方向了，圍繞著 “如何在可見區(qū)域內(nèi)，展示更多的信息” 。這不是布局的簡(jiǎn)單重新排列組合，因?yàn)?nbsp; 方案絕對(duì)不是只有開發(fā)決定如何實(shí)現(xiàn)就可以怎么實(shí)現(xiàn)的，一個(gè)apk承載著功能到用戶手里涉及了多方角色的介入。產(chǎn)品經(jīng)理需要整理需求、運(yùn)營(yíng)人員需要配置物料、發(fā)布apk，測(cè)試需要測(cè)試等等，所以最終的方案不是一方定下來(lái)的，而是一個(gè)協(xié)調(diào)統(tǒng)一后的結(jié)果。

既然要去討論方案，那么就要有依據(jù)，在此省略討論、評(píng)審、定稿的過程。

先來(lái)看看直板、折疊屏、pad的外部輪廓圖，知道頁(yè)面形態(tài)如何。

3.2 方案落地示意圖

每個(gè)應(yīng)用要展示的內(nèi)容不一致，但是原理一致，此處就以下面幾個(gè)樣式為基礎(chǔ)介紹原理。原則也比較簡(jiǎn)單，盡可能展示更多內(nèi)容，不要出現(xiàn)大面積的空白區(qū)域。

下面沒有介紹分欄模式的適配，因?yàn)榉謾诘哪Ｊ揭部赡鼙挥脩絷P(guān)閉，最終成為全屏模式，所以說(shuō)，可以選擇只適配全屏模式，這樣的適配成本較低。當(dāng)然，這個(gè)也要根據(jù)自己模塊的情況來(lái)確定，比如微信，更適合左右屏的分欄模式。

3.2.1 直板機(jī)型適配方案骨骼圖

直板機(jī)型，目前主流的機(jī)型，寬高比基本是9:16，可以最大限度地展示比較多的內(nèi)容，比如下圖中的模塊1、模塊2、 模塊3的圖片。

3.2.2 折疊屏機(jī)型適配方案骨骼圖

折疊屏機(jī)型，屏幕可旋轉(zhuǎn)，但是寬高比基本是1:1，高度和直板機(jī)器基本差不多，可以達(dá)到2000px的像素，所以在縱向上，也可以最大限度地展示比較多的內(nèi)容，比如下圖中的模塊1、模塊2、 模塊3的圖片。

3.2.3 PAD機(jī)型適配方案骨骼圖

pad平板，屏幕可旋轉(zhuǎn)，并且旋轉(zhuǎn)后的寬高比差異較大，縱向時(shí)，寬高比是5 : 8，橫向時(shí)，寬高比是8 : 5。

在pad縱向時(shí)，其實(shí)高度像素是足夠展示很多內(nèi)容的，比如下圖中的模塊1、模塊2、 模塊3的圖片；

但是在pad橫向時(shí)，沒辦法展示更多的內(nèi)容（倒是有個(gè)方案，最后再說(shuō)），只能下圖中的模塊1、模塊2的圖片。

3.3 方案落地規(guī)范

3.3.1 一套代碼適配所有機(jī)型

確定一個(gè)apk能不能適配所有機(jī)型，首先要解決的是要符合不同機(jī)型的特性，比如直板手機(jī)只能縱向顯示，折疊屏和pad支持橫豎屏旋轉(zhuǎn)。

描述如下：

（1）需求

• 直板屏：強(qiáng)制固定豎屏；
• 折疊屏：外屏固定豎屏、內(nèi)屏(大屏)支持橫豎屏切換；
• PAD端：支持橫豎屏切換；

我們需要在以上三端通過一套代碼實(shí)現(xiàn)上面的需求。

（2）橫豎屏切換

有以下2種方法：

方式1）

通過在AndroidManifest.xml中設(shè)置：

android:screenOrientation屬性

a) android:screenOrientation="portrait" 

強(qiáng)制豎屏；

b) android:screenOrientation="landscape" 

強(qiáng)制橫屏；

c) android:screenOrientation="unspecified" 

默認(rèn)值，可以橫豎屏切換；

方式2）

在代碼中設(shè)置：

activity.setRequestedOrientation(****);

a) setRequestedOrientation

(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);    設(shè)置豎屏；

b)setRequestedOrientation

(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE); 設(shè)置橫屏；

c)setRequestedOrientation

(ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED); 可以橫豎屏切換；

（3）不同設(shè)備支持不同的屏幕橫豎屏方式

1）直板屏：

因?yàn)槭菑?qiáng)制豎屏，所以，可以通過在AndroidManifest.xml中給Activity設(shè)置android:screenOrientation="portrait"。

2）折疊屏：

外屏與直板屏是保持一致的，暫且不討論。但是內(nèi)屏(大屏)要支持橫豎屏切換。如果是一套代碼，顯然是無(wú)法通過AndroidManifest文件來(lái)實(shí)現(xiàn)的。這里其實(shí)系統(tǒng)框架已經(jīng)幫我們實(shí)現(xiàn)了對(duì)應(yīng)內(nèi)屏?xí)r橫豎屏的邏輯?？偨Y(jié)就是，折疊屏可以與直板屏保持一致，在AndroidManifest.xml中給Activity設(shè)置android:screenOrientation="portrait"，如果切換到內(nèi)屏?xí)r，系統(tǒng)自動(dòng)忽略掉screenOrientation屬性值，強(qiáng)行支持橫豎屏切換。

3）PAD端：

當(dāng)然了，并不是所有的項(xiàng)目對(duì)應(yīng)的系統(tǒng)都會(huì)自動(dòng)幫我們忽略screenOrientation屬性值，這時(shí)候就需要我們自己來(lái)實(shí)現(xiàn)了。

我們通過在Activity的基類中設(shè)置setRequestedOrientation

(ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED)，發(fā)現(xiàn)確實(shí)能夠使當(dāng)前頁(yè)面橫豎屏自由切換了。但是在啟動(dòng)activity的時(shí)候遇到了問題。當(dāng)我們從橫屏狀態(tài)A界面啟動(dòng)一個(gè)acitivity的B界面時(shí)，發(fā)現(xiàn)B界面先是豎屏，然后切換到了橫屏（如圖1所示）。再試了多次依舊如此，肉眼可見的切換過程顯然不能滿足我們的需求。這說(shuō)明通過java代碼動(dòng)態(tài)調(diào)整橫豎屏的技術(shù)方向是行不通的。綜上所述，通過同一份代碼無(wú)法滿足PAD端和直板屏的互斥的需求。

那還有沒有其他方式呢。別忘了，我們Android打包全流程是通過gradle完成的，我們是不是可以通過切面編程的思維，針對(duì)不同的設(shè)備打出不同的包。

方案確定了，在此進(jìn)行技術(shù)驗(yàn)證。

gradle編譯其中一個(gè)重要環(huán)節(jié)就是對(duì)依賴的aar、本地module中的AndroidManifest文件進(jìn)行merge，最終輸出一份臨時(shí)的完整清單文件，存放在*/app/build/intermediates/merged_manifest/**Release/路徑下。

因此，我們可以在AndroidManifest文件merge完成之后對(duì)該臨時(shí)文件中的android:screenOrientation字段值信息進(jìn)行動(dòng)態(tài)修改，修改完成之后再存回去。這樣針對(duì)pad端就可以單獨(dú)打出一份apk文件。

核心代碼如下：

//pad支持橫豎屏
def processManifestTask = project.tasks.getByName("processDefaultNewSignPadReleaseManifest");
if (processManifestTask != null) {
    processManifestTask.doLast { pmt ->
        def manifestPath = pmt.getMultiApkManifestOutputDirectory().get().toString() + "/AndroidManifest.xml"
        if (new File(manifestPath).exists()) {
            String manifest = file(manifestPath).getText()
            manifest = manifest.replaceAll("android:screenOrientation=\"portrait\"", "android:screenOrientation=\"unspecified\"");
            file(manifestPath).write(manifest)
            println(" =============================================================== manifestPath: " + manifestPath)
        }
    }
}

（4）apk的數(shù)量

到這里為止，java代碼是完全一致，沒有區(qū)分的，關(guān)鍵就在于框架有沒有提供出忽略screenOrientation的能力，如果提供了，我們只需要輸出一個(gè)apk，就能適配所有機(jī)型，

如果沒有這個(gè)能力，我們就需要使用gradle打出額外的一個(gè)apk，滿足可旋轉(zhuǎn)的要求。

3.3.2 一套物料配所有機(jī)型

1、等比放大物料

通過上面的落地方案的要求，對(duì)于模塊2的圖片，展示效果是不一樣的，如下圖：

• 直板手機(jī)上面，模塊2的圖片1在上面，圖片2、3分布于左下角和右下角
• 折疊屏或者pad上面，模塊2的圖片1在左邊，圖片2、3分布于右側(cè)
• 折疊屏和pad上的模塊2的圖片，相對(duì)于直板手機(jī)來(lái)說(shuō)，做了樣式的調(diào)整，上下的樣式改為了左右。圖片也做了對(duì)應(yīng)的放大，保證橫向上可以填充整個(gè)屏幕的寬度。

• 為了形象地表示處理后的效果，看下下面的示意圖即可。

2、高度不變，裁剪物料

對(duì)于模塊3的圖片，可以回顧3.2中的展示樣式，要求是

• 直板手機(jī)上面，模塊3中圖片1的高度此處為300px。
• 折疊屏或者pad上面，模塊3的圖片1的高度也是300px，但是內(nèi)容不能減少。
• 解決方案就是提供一張?jiān)即髨D，假如規(guī)格為2400px*300px，在直板手機(jī)上左右進(jìn)行裁剪，如下圖所示。折疊屏和pad上面直接進(jìn)行展示。而裁剪這一步，放在服務(wù)端進(jìn)行，因?yàn)榭蛻舳俗霾眉簦容^耗時(shí)。

• 為了形象地表示處理后的效果，看下下面的示意圖即可。

3.3.4 無(wú)感刷新

無(wú)感刷新，主要是體現(xiàn)在折疊屏的內(nèi)外屏切換，pad的橫豎屏旋轉(zhuǎn)這些場(chǎng)景，如何保證頁(yè)面不會(huì)出現(xiàn)切換、旋轉(zhuǎn)時(shí)候的閃現(xiàn)呢？

• 這就要提前準(zhǔn)備好數(shù)據(jù)源，保證在頁(yè)面變化時(shí)，立即notify。
• 我們的頁(yè)面列表最好使用recyclerview，因?yàn)閞ecyclerview支持局部刷新。
• 數(shù)據(jù)源驅(qū)動(dòng)UI，千萬(wàn)不要在UI層面判斷機(jī)型做UI的動(dòng)態(tài)計(jì)算，頁(yè)面會(huì)閃屏，體驗(yàn)不好。

3.4 方案落地實(shí)戰(zhàn)

上面介紹了不同機(jī)型的適配規(guī)范，這個(gè)沒有疑問之后，直接通過案例來(lái)看下具體如何實(shí)施。

如上圖所示，選購(gòu)頁(yè)可以大致分為 分類導(dǎo)航欄區(qū)域 和 內(nèi)容區(qū)域，其中內(nèi)容區(qū)域是由多個(gè)樓層組成。

3.4.1 UI如何設(shè)計(jì)的

如圖所示，能夠直觀地感受到，從直板手機(jī)到折疊屏內(nèi)屏再到Pad橫屏，當(dāng)設(shè)備的可顯示面積增大時(shí)，頁(yè)面充分利用空間展示更多的商品信息。

3.4.2 不同設(shè)備的區(qū)分方式

通過前面的簡(jiǎn)單介紹，對(duì)選購(gòu)頁(yè)的整體布局及不同設(shè)備上的UI展示有所了解，下面來(lái)看下如何在多個(gè)設(shè)備上實(shí)現(xiàn)一套代碼的適配。

首先第一步，要如何區(qū)分不同的設(shè)備。

在區(qū)分不同的設(shè)備前，先看下能夠從設(shè)備中獲得哪些信息？

• 分辨率
• 機(jī)型
• 當(dāng)前屏幕的橫、豎狀態(tài)

先說(shuō)結(jié)論：

• 直板手機(jī)：通過分辨率來(lái)區(qū)分
• 折疊屏：通過機(jī)型和內(nèi)外屏狀態(tài)來(lái)區(qū)分
• Pad：通過機(jī)型和當(dāng)前屏幕的橫、豎狀態(tài)來(lái)區(qū)分

所以這里根據(jù)這幾個(gè)特點(diǎn)，提供一個(gè)工具。

不同設(shè)備的區(qū)分方式。

/**
 * @function 判斷當(dāng)前手機(jī)的屏幕是處于哪個(gè)屏幕類型：目前三個(gè)屏幕范圍：分別為 <= 528dp、528 ~ 696dp、> 696dp,對(duì)應(yīng)的分別是正常直板手機(jī)、折疊屏手機(jī)內(nèi)屏和Pad豎屏、和Pad橫屏
 */
public class ScreenTypeUtil {
    public static final int NORMAL_SCREEN_MAX_WIDTH_RESOLUTION = 1584; // 正常直板手機(jī)：屏幕最大寬度分辨率；Pad的分辨率（1600*2560）， 1584 = 528 * 3， 528dp是UI在精選頁(yè)標(biāo)注的直板手機(jī)范圍
    public static final int MIDDLE_SCREEN_MAX_WIDTH_RESOLUTION = 2088; // 折疊屏手機(jī)：屏幕最大寬度分辨率（1916*1964， 旋轉(zhuǎn)：1808*2072），2088 = 696 * 3， 2088dp是UI在精選頁(yè)標(biāo)注的折疊屏展開范圍
    public static final int LARGE_SCREEN_MAX_WIDTH_RESOLUTION = 2560; // 大屏幕設(shè)備：屏幕寬度暫定為 Pad的高度
    public static final int NORMAL_SCREEN = 0; // 正常直版手機(jī)屏幕
    public static final int MIDDLE_SCREEN = 1; // 折疊屏手機(jī)內(nèi)屏展開、Pad豎屏
    public static final int LARGE_SCREEN = 2;  // Pad橫屏
    public static int getScreenType() {
        Configuration configuration = BaseApplication.getApplication().getResources().getConfiguration();
        return getScreenType(configuration);
    }
    // 注意這里的newConfig 在Activity、Fragment、View 中的onConfigurationChanged中獲得的newConfig傳入，如果獲得不了該值，可以使用getScreenType（）方法
    public static int getScreenType(@NonNull Configuration newConfig) {
        // Pad 通過機(jī)型標(biāo)志位及當(dāng)前處于橫豎屏狀態(tài) 來(lái)判斷當(dāng)前屏幕類型
        if (SystemInfoUtils.isPadDevice()) {
            return newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE ? LARGE_SCREEN : MIDDLE_SCREEN;
        }
        // Fold折疊屏 通過機(jī)型標(biāo)志及內(nèi)外屏狀態(tài) 來(lái)判斷當(dāng)前屏幕類型
        if (SystemInfoUtils.isFoldableDevice()) {
            return SystemInfoUtils.isInnerScreen(newConfig) ? MIDDLE_SCREEN : NORMAL_SCREEN;
        }
        // 普通手機(jī) 通過分辨率判斷
        return AppInfoUtils.getScreenWidth() <= NORMAL_SCREEN_MAX_WIDTH_RESOLUTION ? NORMAL_SCREEN : (AppInfoUtils.getScreenWidth() <= MIDDLE_SCREEN_MAX_WIDTH_RESOLUTION ? MIDDLE_SCREEN : LARGE_SCREEN);
    }
}

3.4.3 實(shí)現(xiàn)方案

（1）數(shù)據(jù)源驅(qū)動(dòng)UI改變的思想

• 對(duì)于直板手機(jī)來(lái)說(shuō)，選購(gòu)頁(yè)只有一種狀態(tài)，保持豎屏展示
• 對(duì)于折疊屏來(lái)說(shuō)，折疊屏可以由內(nèi)屏切換到外屏，也就涉及到了兩種不同狀態(tài)的切換。
• 對(duì)于Pad來(lái)說(shuō)，Pad支持橫豎屏切換，所以也是兩種不同狀態(tài)切換。

當(dāng)屏幕類型、橫豎屏切換、內(nèi)外屏切換時(shí)，Activity\Fragment\View 會(huì)調(diào)用onConfigurationChanged方法，因此針對(duì)直板手機(jī)、折疊屏及Pad可以將數(shù)據(jù)源的切換放在此處。

無(wú)論是哪種設(shè)備，最多是只有兩種不同的狀態(tài)，因此，數(shù)據(jù)源這里可以準(zhǔn)備兩套：一種是Normal、一種是Width，對(duì)直板手機(jī)而言：因?yàn)橹挥幸环N豎屏狀態(tài)，因此只需要一套數(shù)據(jù)源即可；對(duì)折疊屏而言：Normal存放的是折疊屏外屏數(shù)據(jù)源，Width存放的是折疊屏內(nèi)屏數(shù)據(jù)源；對(duì)Pad而言：Normal存放的是Pad豎屏狀態(tài)數(shù)據(jù)源，Width存放的是Pad橫屏狀態(tài)數(shù)據(jù)源。

（2）內(nèi)容區(qū)域

右側(cè)的內(nèi)容區(qū)域是一個(gè)Fragment，在這個(gè)Fragment里面包含了一個(gè)RecyclerView。

每個(gè)子樓層

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/root_classify_horizontal"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="vertical">
    <xxx.widget.HeaderAndFooterRecyclerView
        android:id="@+id/shop_product_multi_rv"
        android:layout_width="match_parent"
        android:layout_height="wrap_content" />
</LinearLayout>

每個(gè)樓層也是一個(gè)單獨(dú)的RecyclerView，以樓層4為例，樓層4的每一行商品都是一個(gè)RecyclerView，每個(gè)RecyclerView使用GridLayoutManager來(lái)控制布局的展現(xiàn)列數(shù)。

（3）數(shù)據(jù)源

以折疊屏為例：針對(duì)每個(gè)子樓層的數(shù)據(jù)，在解析時(shí)，就先準(zhǔn)備兩套數(shù)據(jù)源：一種是Normal、一種是Width。

在請(qǐng)求網(wǎng)絡(luò)數(shù)據(jù)回來(lái)后，在解析數(shù)據(jù)完成后，存放兩套數(shù)據(jù)源。這兩套數(shù)據(jù)源要根據(jù)UI設(shè)計(jì)的規(guī)則來(lái)組裝，例如以折疊屏的樓層4為例：

• 折疊屏-外屏-樓層4：一行展示2個(gè)商品信息。
• 折疊屏-內(nèi)屏-樓層4：一行展示3個(gè)商品信息。

注意：這里的2、3數(shù)字是UI設(shè)計(jì)之初就定下來(lái)的，每行商品都是一個(gè)RecyclerView，并且使用GridLayoutManager來(lái)控制其列數(shù)，因此這個(gè)2、3也是傳入到GridLayoutManager的列數(shù)值，這里要保持一致。

子樓層的數(shù)據(jù)源解析

//這里的normalProductMultiClassifyUiBeanList集合中存放了2個(gè)商品信息
for (ProductMultiClassifyUiBean productMultiClassifyUiBean : normalProductMultiClassifyUiBeanList) {
    productMultiClassifyUiBean.setFirstFloor(isFirstFloor);
    shopListDataWrapper.addNormalBaseUiBeans(productMultiClassifyUiBean);
}
//這里的normalProductMultiClassifyUiBeanList集合中存放了3個(gè)商品信息
for (ProductMultiClassifyUiBean productMultiClassifyUiBean : widthProductMultiClassifyUiBeanList) {
    productMultiClassifyUiBean.setFirstFloor(isFirstFloor);
    shopListDataWrapper.addWidthBaseUiBeans(productMultiClassifyUiBean);
}

因此，到這里就已經(jīng)獲取了所需的數(shù)據(jù)源部分

（4）屏幕類型切換

還是以折疊屏為例，折疊屏外屏切換到內(nèi)屏，此時(shí)Fragment會(huì)走onConfigurationChanged方法。

屏幕類型切換-數(shù)據(jù)源切換-更新RecyclerView。

public void onConfigurationChanged(@NonNull Configuration newConfig) {
    super.onConfigurationChanged(newConfig);
    //1、 首先進(jìn)行內(nèi)容區(qū)域中的RecyclerViewAdapter、數(shù)據(jù)源判空
    if (mRecyclerViewAdapter == null || mPageBeanAll == null) {
        return;
    }
    //2、判斷當(dāng)前的屏幕類型，注意：這個(gè)地方是調(diào)用3提供的方法：ScreenTypeUtil.getScreenType(newConfig)
    // 直板手機(jī)、折疊屏外屏
    if (ScreenTypeUtil.NORMAL_SCREEN == ScreenTypeUtil.getScreenType(newConfig)) {
        mPageBeanAll.setBaseUiBeans(mPageBeanAll.getNormalBaseUiBeans());
    } else if (ScreenTypeUtil.MIDDLE_SCREEN == ScreenTypeUtil.getScreenType(newConfig)) {
        if (SystemInfoUtils.isPadDevice()) {
            // Pad的豎屏
            mPageBeanAll.setBaseUiBeans(mPageBeanAll.getNormalBaseUiBeans());
        } else {
            // 折疊屏的內(nèi)屏
            mPageBeanAll.setBaseUiBeans(mPageBeanAll.getWidthBaseUiBeans());
        }
    } else {
        // Pad的橫屏、大分辨率屏幕
        mPageBeanAll.setBaseUiBeans(mPageBeanAll.getWidthBaseUiBeans());
    }
    //獲取當(dāng)前屏幕類型的最新數(shù)據(jù)源
    mRecyclerViewAdapter.setDataSource(mPageBeanAll.getBaseUiBeans());
    //數(shù)據(jù)源驅(qū)動(dòng)樓層UI改變
    mRecyclerViewAdapter.notifyDataSetChanged();
}

通過onConfigurationChanged方法，能夠看到數(shù)據(jù)源是如何根據(jù)不同屏幕類型進(jìn)行切換的，當(dāng)數(shù)據(jù)源切換后，會(huì)通過notifyDataSetChanged方法來(lái)改變UI。

四、至簡(jiǎn)之路的鑄就

大道至簡(jiǎn)，遵循規(guī)范和原則，就可以想到如何對(duì)多機(jī)型進(jìn)行適配，別陷入細(xì)節(jié)。

以這個(gè)作為指導(dǎo)思想，可以做很多其他的適配。下面做些列舉，但不講解實(shí)現(xiàn)方式了。

1、文字顯示區(qū)域放大

如下圖所示，標(biāo)題的長(zhǎng)度，在整個(gè)容器顯示寬度變寬的同時(shí)，也跟著一起變化，保證內(nèi)容的長(zhǎng)度可以自適應(yīng)的變化。

2、彈框樣式的兼容

如下圖所示，藍(lán)色區(qū)域是鍵盤的高度，在屏幕進(jìn)行旋轉(zhuǎn)的時(shí)候，鍵盤的高度也是變化的，此時(shí)可能會(huì)出現(xiàn)遮擋住原本展示的內(nèi)容，此處的處理方式是：讓內(nèi)容區(qū)域可以上下滑動(dòng)。

3、攝像頭位置的處理

如下圖所示，在屏幕旋轉(zhuǎn)之后，攝像頭可以出現(xiàn)在右下角，此時(shí)如果不對(duì)頁(yè)面進(jìn)行設(shè)置，那么就可能出現(xiàn)內(nèi)容區(qū)域無(wú)法占據(jù)整個(gè)屏幕區(qū)域的問題，體驗(yàn)比較差，此處的處理方式是：設(shè)置頁(yè)面沉浸式，攝像頭可以合理地覆蓋一部分內(nèi)容。

五、我們擺脫困擾了嗎

5.1 解決原先的問題

通過前面的介紹，我們知道了，vivo官網(wǎng)的團(tuán)隊(duì)針對(duì)折疊屏和pad這種大屏，采取了全屏展示的方案，一開始的時(shí)候，我們遇到的問題也得到了解決：

（1）開發(fā)人員的適配成本高了，是不是針對(duì)每一種機(jī)型，都要做個(gè)單獨(dú)的應(yīng)用進(jìn)行適配呢？

Answer：按照全屏模式的設(shè)計(jì)方案，折疊屏和pad也就是一種大尺寸的機(jī)器，開發(fā)人員判斷機(jī)型的分辨率和尺寸，選擇一種對(duì)應(yīng)的布局展示就好了，只用一個(gè)應(yīng)用就能搞定。

（2）UI設(shè)計(jì)師要做的效果圖要多了，是不是要針對(duì)每種機(jī)型都要設(shè)計(jì)一套效果圖呢？

Answer：制定一套規(guī)范，大于某個(gè)尺寸時(shí)，展示其他樣式，所有信息內(nèi)容都按照這種規(guī)范來(lái)，不會(huì)出現(xiàn)設(shè)計(jì)混亂的情況。

（3）產(chǎn)品和運(yùn)營(yíng)需要選擇的物料更受限制了，會(huì)不會(huì)這個(gè)物料在一個(gè)機(jī)器上正常。在其他機(jī)器上就不正常了呢？

Answer：以不變應(yīng)萬(wàn)變，使用一套物料，適配不同的機(jī)型已經(jīng)可以落地了，不用再擔(dān)心在不同的機(jī)器上展示不統(tǒng)一的問題。

5.2 我們還可以做什么

5.2.1 我們的優(yōu)點(diǎn)

折疊屏和pad兩款機(jī)器，已經(jīng)在市面上使用較長(zhǎng)時(shí)間，各家廠商也紛紛采取了不同的適配方案來(lái)提升交互體驗(yàn)，但是往往存在下面幾個(gè)問題：

1、針對(duì)不同機(jī)型，采用了不同的安裝包。

這種方案，其實(shí)會(huì)增加維護(hù)成本，后期的開發(fā)要基于多個(gè)安裝包去開發(fā)，更加耗時(shí)。

2、適配了不同的機(jī)型，但是在一些場(chǎng)景下的樣式不理想。

比如有些APP做了分欄的適配，但是沒有做全屏的適配，效果就比較差，這里可能也是考慮到了投入產(chǎn)出比。

3、目前的適配指導(dǎo)文檔對(duì)于開發(fā)人員來(lái)說(shuō)指導(dǎo)性較弱。

各種適配指導(dǎo)文檔，還是比較偏向于官方，對(duì)于開發(fā)人員來(lái)說(shuō)，還是無(wú)法提前識(shí)別問題，遇到問題還是要實(shí)際去解決。

基于此，我們的優(yōu)點(diǎn)如下：

1、我們只有一個(gè)安裝包。

我們是一個(gè)安裝包適配所有機(jī)型，每種機(jī)型的APP展示的樣式雖然不同，對(duì)于開發(fā)者來(lái)說(shuō)，就是增加了一個(gè)樣式，思路比較清晰。

2、全場(chǎng)景適配。

不同機(jī)型的縱向、橫豎屏切換，都做到了完美適配，一套物料適配所有機(jī)型也是我們的一個(gè)特色。

3、有針對(duì)性地提供適配方案。

本方案是基于實(shí)際開發(fā)遇到的問題，進(jìn)行的梳理，可以幫忙開發(fā)人員解決實(shí)際可能遇到的問題，具備更好的參考性。

5.2.2 我們還有什么要改進(jìn)

回首方案，我們這里做到的是使用全屏模式去適配不同機(jī)型，更多的適用于像京東、淘寶、商城等電商類APP上，實(shí)際上，現(xiàn)在有些非APP會(huì)采用分欄的形式做適配，這也是一種跟用戶交互的方式，本方案沒有提到分欄，后續(xù)分欄落地后，對(duì)這部分會(huì)再進(jìn)行補(bǔ)充。