vivo官网APP全机型UI适配方案

1.1  背景

科技是进步的，人们对美的要求也是逐渐提升的，所以才有了现在市面上形形色色的机型

（1）比如vivo X60手机采用纤薄曲面屏设计，属于直板机型。

1.2  我们的挑战

可是随着这种形形色色机型的出现，那么问题就来了：

（1）开发人员的适配成本高了，是不是针对每一种机型，都要做个单独的应用进行适配呢？

（2）UI设计师要做的效果图要多了，是不是要针对每种机型都要设计一套效果图呢？

（3）产品和运营需要选择的物料更受限制了，会不会这个物料在一个机器上正常。在其他机器上就不正常了呢？

为什么这么说，下面以开发者的角度来做介绍，把我们面临的问题，做说明。

2.1 全机型适配成本太高

日渐丰富的机型适配让我们这些android开发人员疲于奔命，虽然可以按照要求进行适配，但是大屏幕的机型适配成本依然比较高，因为这些机型不同于传统的直板手机的宽高比例（9:16）。所以有的应用干脆就直接两边留白，内容区域展示在屏幕正中央，这种效果，当然很差。

2.2 全机型适配成本高在哪

3.1 方案讨论与确定

页面拉伸、左右留白是现象，这也是用户的直接体验。那么这就是我们要改善的地方，所以现在就有方向了，围绕着 “如何在可见区域内，展示更多的信息” 。这不是布局的简单重新排列组合，因为  方案绝对不是只有开发决定如何实现就可以怎么实现的，一个apk承载着功能到用户手里涉及了多方角色的介入。产品经理需要整理需求、运营人员需要配置物料、发布apk，测试需要测试等等，所以最终的方案不是一方定下来的，而是一个协调统一后的结果。

既然要去讨论方案，那么就要有依据，在此省略讨论、评审、定稿的过程。

3.2 方案落地示意图

每个应用要展示的内容不一致，但是原理一致，此处就以下面几个样式为基础介绍原理。原则也比较简单，尽可能展示更多内容，不要出现大面积的空白区域。

下面没有介绍分栏模式的适配，因为分栏的模式也可能被用户关闭，最终成为全屏模式，所以说，可以选择只适配全屏模式，这样的适配成本较低。当然，这个也要根据自己模块的情况来确定，比如微信，更适合左右屏的分栏模式。

pad平板，屏幕可旋转，并且旋转后的宽高比差异较大，纵向时，宽高比是5 : 8，横向时，宽高比是8 : 5。

在pad纵向时，其实高度像素是足够展示很多内容的，比如下图中的模块1、模块2、 模块3的图片；

但是在pad横向时，没办法展示更多的内容（倒是有个方案，最后再说），只能下图中的模块1、模块2的图片。

3.3 方案落地规范

确定一个apk能不能适配所有机型，首先要解决的是要符合不同机型的特性，比如直板手机只能纵向显示，折叠屏和pad支持横竖屏旋转。

描述如下：

（1）需求

• 直板屏：强制固定竖屏；

• 折叠屏：外屏固定竖屏、内屏(大屏)支持横竖屏切换；

• PAD端：支持横竖屏切换；

我们需要在以上三端通过一套代码实现上面的需求。

（2）横竖屏切换

有以下2种方法：
方式1）

1）直板屏：

因为是强制竖屏，所以，可以通过在AndroidManifest.xml中给Activity设置android:screenOrientation="portrait"。

2）折叠屏：

外屏与直板屏是保持一致的，暂且不讨论。但是内屏(大屏)要支持横竖屏切换。如果是一套代码，显然是无法通过AndroidManifest文件来实现的。这里其实系统框架已经帮我们实现了对应内屏时横竖屏的逻辑。总结就是，折叠屏可以与直板屏保持一致，在AndroidManifest.xml中给Activity设置android:screenOrientation="portrait"，如果切换到内屏时，系统自动忽略掉screenOrientation属性值，强行支持横竖屏切换。

3）PAD端：

当然了，并不是所有的项目对应的系统都会自动帮我们忽略screenOrientation属性值，这时候就需要我们自己来实现了。

我们通过在Activity的基类中设置setRequestedOrientation

(ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED)，发现确实能够使当前页面横竖屏自由切换了。但是在启动activity的时候遇到了问题。当我们从横屏状态A界面启动一个acitivity的B界面时，发现B界面先是竖屏，然后切换到了横屏（如图1所示）。再试了多次依旧如此，肉眼可见的切换过程显然不能满足我们的需求。这说明通过java代码动态调整横竖屏的技术方向是行不通的。综上所述，通过同一份代码无法满足PAD端和直板屏的互斥的需求。

那还有没有其他方式呢。别忘了，我们Android打包全流程是通过gradle完成的，我们是不是可以通过切面编程的思维，针对不同的设备打出不同的包。

方案确定了，在此进行技术验证。

gradle编译其中一个重要环节就是对依赖的aar、本地module中的AndroidManifest文件进行merge，最终输出一份临时的完整清单文件，存放在*/app/build/intermediates/merged_manifest/**Release/路径下。

因此，我们可以在AndroidManifest文件merge完成之后对该临时文件中的android:screenOrientation字段值信息进行动态修改，修改完成之后再存回去。这样针对pad端就可以单独打出一份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的数量

到这里为止，java代码是完全一致，没有区分的，关键就在于框架有没有提供出忽略screenOrientation的能力，如果提供了，我们只需要输出一个apk，就能适配所有机型，

如果没有这个能力，我们就需要使用gradle打出额外的一个apk，满足可旋转的要求。

通过上面的落地方案的要求，对于模块2的图片，展示效果是不一样的，如下图：

（1）直板手机上面，模块2的图片1在上面，图片2、3分布于左下角和右下角

（2）折叠屏或者pad上面，模块2的图片1在左边，图片2、3分布于右侧

（3）折叠屏和pad上的模块2的图片，相对于直板手机来说，做了样式的调整，上下的样式改为了左右。图片也做了对应的放大，保证横向上可以填充整个屏幕的宽度。

（4）为了形象地表示处理后的效果，看下下面的示意图即可。

2、高度不变，裁剪物料

对于模块3的图片，可以回顾3.2中的展示样式，要求是

（1）直板手机上面，模块3中图片1的高度此处为300px。

（2）折叠屏或者pad上面，模块3的图片1的高度也是300px，但是内容不能减少。

（3）解决方案就是提供一张原始大图，假如规格为2400px*300px，在直板手机上左右进行裁剪，如下图所示。折叠屏和pad上面直接进行展示。而裁剪这一步，放在服务端进行，因为客户端做裁剪，比较耗时。

（4）为了形象地表示处理后的效果，看下下面的示意图即可。

无感刷新，主要是体现在折叠屏的内外屏切换，pad的横竖屏旋转这些场景，如何保证页面不会出现切换、旋转时候的闪现呢？

（1）这就要提前准备好数据源，保证在页面变化时，立即notify。

（2）我们的页面列表最好使用recyclerview，因为recyclerview支持局部刷新。

（3）数据源驱动UI，千万不要在UI层面判断机型做UI的动态计算，页面会闪屏，体验不好。

3.4 方案落地实战

通过前面的简单介绍，对选购页的整体布局及不同设备上的UI展示有所了解，下面来看下如何在多个设备上实现一套代码的适配。

首先第一步，要如何区分不同的设备。

在区分不同的设备前，先看下能够从设备中获得哪些信息？

1）分辨率

2）机型

3）当前屏幕的横、竖状态

先说结论：

• 直板手机：通过分辨率来区分

• 折叠屏：通过机型和内外屏状态来区分

• Pad：通过机型和当前屏幕的横、竖状态来区分

（1）数据源驱动UI改变的思想

对于直板手机来说，选购页只有一种状态，保持竖屏展示

对于折叠屏来说，折叠屏可以由内屏切换到外屏，也就涉及到了两种不同状态的切换。

对于Pad来说，Pad支持横竖屏切换，所以也是两种不同状态切换。

当屏幕类型、横竖屏切换、内外屏切换时，Activity\Fragment\View 会调用onConfigurationChanged方法，因此针对直板手机、折叠屏及Pad可以将数据源的切换放在此处。

无论是哪种设备，最多是只有两种不同的状态，因此，数据源这里可以准备两套：一种是Normal、一种是Width，对直板手机而言：因为只有一种竖屏状态，因此只需要一套数据源即可；对折叠屏而言：Normal存放的是折叠屏外屏数据源，Width存放的是折叠屏内屏数据源；对Pad而言：Normal存放的是Pad竖屏状态数据源，Width存放的是Pad横屏状态数据源。

（2）内容区域

右侧的内容区域是一个Fragment，在这个Fragment里面包含了一个RecyclerView。

（3）数据源

以折叠屏为例：针对每个子楼层的数据，在解析时，就先准备两套数据源：一种是Normal、一种是Width。

在请求网络数据回来后，在解析数据完成后，存放两套数据源。这两套数据源要根据UI设计的规则来组装，例如以折叠屏的楼层4为例：

折叠屏-外屏-楼层4：一行展示2个商品信息。

折叠屏-内屏-楼层4：一行展示3个商品信息。

注意：这里的2、3数字是UI设计之初就定下来的，每行商品都是一个RecyclerView，并且使用GridLayoutManager来控制其列数，因此这个2、3也是传入到GridLayoutManager的列数值，这里要保持一致。

（4）屏幕类型切换

还是以折叠屏为例，折叠屏外屏切换到内屏，此时Fragment会走onConfigurationChanged方法。

大道至简，遵循规范和原则，就可以想到如何对多机型进行适配，别陷入细节。

以这个作为指导思想，可以做很多其他的适配。下面做些列举，但不讲解实现方式了。

1、文字显示区域放大

如下图所示，标题的长度，在整个容器显示宽度变宽的同时，也跟着一起变化，保证内容的长度可以自适应的变化。

2、弹框样式的兼容

如下图所示，蓝色区域是键盘的高度，在屏幕进行旋转的时候，键盘的高度也是变化的，此时可能会出现遮挡住原本展示的内容，此处的处理方式是：让内容区域可以上下滑动。

3、摄像头位置的处理

如下图所示，在屏幕旋转之后，摄像头可以出现在右下角，此时如果不对页面进行设置，那么就可能出现内容区域无法占据整个屏幕区域的问题，体验比较差，此处的处理方式是：设置页面沉浸式，摄像头可以合理地覆盖一部分内容。

5.1 解决原先的问题

通过前面的介绍，我们知道了，vivo官网的团队针对折叠屏和pad这种大屏，采取了全屏展示的方案，一开始的时候，我们遇到的问题也得到了解决：

（1）开发人员的适配成本高了，是不是针对每一种机型，都要做个单独的应用进行适配呢？

（2）UI设计师要做的效果图要多了，是不是要针对每种机型都要设计一套效果图呢？

（3）产品和运营需要选择的物料更受限制了，会不会这个物料在一个机器上正常。在其他机器上就不正常了呢？

5.2 我们还可以做什么

折叠屏和pad两款机器，已经在市面上使用较长时间，各家厂商也纷纷采取了不同的适配方案来提升交互体验，但是往往存在下面几个问题：

1、针对不同机型，采用了不同的安装包。

这种方案，其实会增加维护成本，后期的开发要基于多个安装包去开发，更加耗时。

2、适配了不同的机型，但是在一些场景下的样式不理想。

比如有些APP做了分栏的适配，但是没有做全屏的适配，效果就比较差，这里可能也是考虑到了投入产出比。

3、目前的适配指导文档对于开发人员来说指导性较弱。

各种适配指导文档，还是比较偏向于官方，对于开发人员来说，还是无法提前识别问题，遇到问题还是要实际去解决，

https://developer.huawei.com/consumer/cn/doc/90101 

1、我们只有一个安装包。

我们是一个安装包适配所有机型，每种机型的APP展示的样式虽然不同，对于开发者来说，就是增加了一个样式，思路比较清晰。

2、全场景适配。

不同机型的纵向、横竖屏切换，都做到了完美适配，一套物料适配所有机型也是我们的一个特色。

3、有针对性地提供适配方案。

本方案是基于实际开发遇到的问题，进行的梳理，可以帮忙开发人员解决实际可能遇到的问题，具备更好的参考性。