上一章：优酷APP响应式布局技术之iOS篇 | 《优酷响应式布局技术全解析》第三章>>>
下一章：优酷APP响应式布局在消费场景的落地Android | 《优酷响应式布局技术全解析》第五章>>>
作者| 阿里巴巴文娱技术 十朋
一、背景介绍
近年来，移动设备一直向大屏、轻便方向发展，大屏手机、Pad、折叠屏、iPad分屏等越来越多的应用到日常生活中，今年苹果公司官宣将推出基于ARM架构的自研MacBook电脑处理器，移动端APP也将自动支持在MAC上运行。一套代码在不同尺寸设备上运行将成为一种新趋势。为了获得更好的用户体验，优酷需要适配多屏幕不同尺寸。在大屏幕下调整内容布局以最优的显示方式程现内容，是基本的适配规则。
二、业务介绍
优酷业务场景众多，其中最核心的两个业务场景是：内容消费场和内容分发场。内容消费指的是用户对视频内容产生播放行为；内容分发是指引导用户进播放的页面，有多种维度的表现形式。
优酷业务分发场景比较复杂，我们对业务进行了梳理，大致可分为几大类：
1、核心分发页面，首页、频道、大剧大综，承接了分发场景的大部分业务：
2、二级分发，搜索、各类片单合集及Feed流页面：
3、功能性页面,频道管理、各类浮层弹窗：
技术选型同时考虑性能、动态、研发成本等多方面因素。对于核心的分发场景来说，用Native原生渲染能达到最好的性能体验；对于一些实时性、动态性较强的业务来说，我们也有综合运用Weex、H5、小程序的技术栈。
三、响应式适配
移动端的设备种类繁多，保证在任何设备上都有最佳的体验，不是一件容易的事情。优酷响应式的适配工作，是按业务进行划分的。每一类业务用不同的渲染架构实现，需要有不同的处理方式。本节主要介绍原生渲染架构下的接入方式。
下图是响应式整体架构图，业务层响应式适配基于SDK基础之上，响应式SDK提供了基础响应布局能力，拉通各个业务方不同页面的适配规则，确保了适配效果的一致性。
对于Android来说，一般采用LinearLayout/RelativeLayout等布局容器，内部的元素本身具备自适应(AutoLayout)性；
对于iOS，优酷内部存在较多的Frame布局，不具备自适应能力。 View容器层面首先需要改造具备内部自适应能力：即子元素可以随着父控件的尺寸变化而变化。
目前iOS开发自适应有几种方案：官方AutoResizing、官方AutoLayout、Facebook Masonry框架（详见技术篇《优酷响应式技术实现-iOS篇》介绍）。经过技术调研，针对优酷场景选择官方AutoResizing方案适配，成本最小。
1、页面布局
当屏幕的宽度发生变化时，页面的布局相应的调整，以达到最佳的展示状态。分发场适配时不存在多容器分屏的情况，因此页面容器的接入比较简单，保证页面容器是自适应模式即可。
对于Android，无需特殊处理，iOS则需要设置页面容器为自适应模式：设置容器View的autoresizingMask的属性为UIViewAutoresizingFlexibleWidth|UIViewAutoresizingFlexibleHeight。
下图是多种屏幕状态下的页面容器变化显示效果：
1）横竖屏切换
2）分屏模式
3）折叠屏
2、组件布局
组件布局适配原则：页面容器尺寸发生变化时，动态调整组件的列数以及坑位的尺寸，以达到视觉上的最佳展示体验。
组件的种类繁多，优酷原生标准库组件大约150多个。按组件的布局类别，可以划分为几大类：网格布局组件、轮播布局组件、横滑布局组件、瀑布流布局组件。响应式SDK对这些基础布局均提供了底层适配支持。
1）轮播布局
轮播图在小设备下（手机）展示一个卡片，在大设备下（pad)展示一个卡片会特别大，我们对市面上主流的pad设备进行了采样，最终总结出一个经验值: 放大常量scale=1.2，即卡片宽度放大1.2倍体验最好。轮播图接入规则之后的展示效果如下图：
首页轮播图支持浮层视频广告，在Pad下增加一个半透明背景，广告居中展示：
2）网格布局
对于网格布局，在不同的尺寸页面下，根据页面的物理宽度动态适配，显示为不同的列数。针对优酷业务，响应式SDK扩展了网格布局的基础能力，业务方不需要接入即可实现自适应。横竖屏下网络布局展示列数有所不同：
3）横滑布局
针对横滑布局，响应式提供一了个计算公式，用于动态变换组件在屏幕中的列数(详见技术篇《优酷响应式技术实现-iOS篇》中的介绍)，公式中入参为“手机组件列数”。优酷中有十多种类型组件基于横滑布局，以下列举几例。
横滑SCG组件，手机组件列数为3，Pad适配效果如下：
明星头像组件，手机组件列数为4，Pad适配效果如下：
正在看组件，手机组件列数为2.5，Pad适配效果如下：
3、特殊区域适配
顶部导航、底bar、多TAB，是页面的特殊部分，需要业务方跟据响应式状态的变化动态调整布局。
1）顶导适配：
大屏顶导部分适配，在竖屏模式下保持和手机同样的布局，中间部分拉伸展示；
横屏模式下，由于竖向区域变小，为了透出更多的内容，搜索框和多TAB改为左右排版。下图是两种状态的适配效果：
2）多TAB区域适配:
内容固定居左，横屏&竖屏下固定布局，大小尺寸不变居左展示。
3）弹框、浮层适配：
内容固定居中，在横屏竖屏下比例不变 保证内容居中展示。
4）底导适配：
针对这种情况，采用拉伸布局，内容元素在相对宽度内均分适配。
4、特殊业务适配
使用H5、Weex、小程序架构渲染的页面，考虑到适配的复杂度，我们选择一种即能保证业务正常运转同时能快速适配的折衷方案：采用一种简单的适配原则：对于大屏宽度取屏幕的一半居中展示；设备在折叠状态、分屏状态、浮窗状态时填充容器宽度：
频道管理适配：Pad下设置最大宽度300dp，当容器宽度小于300dp时，填满容器宽度（如分屏、浮窗模式）。
有一些业务只支持一个屏幕方向，当旋转到不支持的方向时，给用户一个友好的提示，如少儿绘本页面：
5、数据加工
某些组件在iPad、折叠屏等大尺寸设备上响应式适配之后，显示存在问题（如下图），如宽度过大、屏幕留白现象。 接下来阐述分发场是如何利用数据加工手段做适配的。
数据加工是指对后端返回的数据做预处理，以达到在大尺寸设备下组件最佳展示的目的。技术文章《优酷响应式技术实现-Android篇》有更详尽的介绍。
1）数据映射
解决什么问题
存在一些带交互复杂的组件或者Pad上适配效果较差的组件，可以直接映射成其他已适配的组件。降低复杂组件的适配成本，埋点数据字段保持不变，减少对算法埋点数据的影响。
效果
部分数据映射的组件如下：
2）数据合并
解决什么问题
一些组件适配之后会填充整个屏幕宽，效果不好。这时选择把当前组件数据合并到其下方的组件内，变为下方组件的一部分数据源，以达到显示效果最佳的适配目的。
效果
3）数据补全
以带换一换的组件为例。后端下发总数量18条，每页的数据为6条，手机上展示3列2行，正好填充一页，但在pad下会空出两个位置（如下图右），这时要调整每页的数据，达到数据补全的目的。在pad下调整一页8条即可。
还有一种情况，后端下发的数量不足一页，无法铺满屏幕的宽度。解决这类问题，服务端在Phone端数据的基础上，多下发部分业务数据，客户端根据具体的屏幕尺寸，动态调整显示的个数，确保显示效果。
例如：下图中手机上显示2列3行，共6条数据，到了Pad竖屏上显示3列2行，共6条数据，到了Pad横屏上会补全2条数据，显示4列2行，共8条数据。
4）数据过滤
架构层还提供了数据过滤的能力。如果某些组件适配较复杂，可以考虑折衷的方案暂时过滤掉数据，让业务先跑起来。
分发场景中有一些非核心链路的组件适配较复杂，我们选择先过滤掉，保证APP的正常迭代发版，后续版本再逐渐适配。
四、适配效果及总结
优酷首页、频道页等核心链路分发场景，经过适配达到了比较好的效果，页面的展示会根据不同的尺寸、分屏、浮窗、折叠等设备状态，动态变换内容布局，而不是等比放大，提升了分发效率、为用户提供更佳的分发体验。
