上一章:优酷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的正常迭代发版,后续版本再逐渐适配。
四、适配效果及总结
优酷首页、频道页等核心链路分发场景,经过适配达到了比较好的效果,页面的展示会根据不同的尺寸、分屏、浮窗、折叠等设备状态,动态变换内容布局,而不是等比放大,提升了分发效率、为用户提供更佳的分发体验。