优酷APP响应式布局在分发场景的落地 | 《优酷响应式布局技术全解析》第四章

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介: 本章介绍 优酷APP响应式布局在分发场景的落地

上一章:优酷APP响应式布局技术之iOS篇 | 《优酷响应式布局技术全解析》第三章>>>
下一章:优酷APP响应式布局在消费场景的落地Android | 《优酷响应式布局技术全解析》第五章>>>

作者| 阿里巴巴文娱技术 十朋

一、背景介绍

近年来,移动设备一直向大屏、轻便方向发展,大屏手机、Pad、折叠屏、iPad分屏等越来越多的应用到日常生活中,今年苹果公司官宣将推出基于ARM架构的自研MacBook电脑处理器,移动端APP也将自动支持在MAC上运行。一套代码在不同尺寸设备上运行将成为一种新趋势。为了获得更好的用户体验,优酷需要适配多屏幕不同尺寸。在大屏幕下调整内容布局以最优的显示方式程现内容,是基本的适配规则。

image.png

二、业务介绍

优酷业务场景众多,其中最核心的两个业务场景是:内容消费场和内容分发场。内容消费指的是用户对视频内容产生播放行为;内容分发是指引导用户进播放的页面,有多种维度的表现形式。
优酷业务分发场景比较复杂,我们对业务进行了梳理,大致可分为几大类:
1、核心分发页面,首页、频道、大剧大综,承接了分发场景的大部分业务:

image.png

2、二级分发,搜索、各类片单合集及Feed流页面:

image.png

3、功能性页面,频道管理、各类浮层弹窗:

image.png

技术选型同时考虑性能、动态、研发成本等多方面因素。对于核心的分发场景来说,用Native原生渲染能达到最好的性能体验;对于一些实时性、动态性较强的业务来说,我们也有综合运用Weex、H5、小程序的技术栈。

三、响应式适配

移动端的设备种类繁多,保证在任何设备上都有最佳的体验,不是一件容易的事情。优酷响应式的适配工作,是按业务进行划分的。每一类业务用不同的渲染架构实现,需要有不同的处理方式。本节主要介绍原生渲染架构下的接入方式。

下图是响应式整体架构图,业务层响应式适配基于SDK基础之上,响应式SDK提供了基础响应布局能力,拉通各个业务方不同页面的适配规则,确保了适配效果的一致性。

image.png

对于Android来说,一般采用LinearLayout/RelativeLayout等布局容器,内部的元素本身具备自适应(AutoLayout)性;

对于iOS,优酷内部存在较多的Frame布局,不具备自适应能力。 View容器层面首先需要改造具备内部自适应能力:即子元素可以随着父控件的尺寸变化而变化。

目前iOS开发自适应有几种方案:官方AutoResizing、官方AutoLayout、Facebook Masonry框架(详见技术篇《优酷响应式技术实现-iOS篇》介绍)。经过技术调研,针对优酷场景选择官方AutoResizing方案适配,成本最小。

1、页面布局

当屏幕的宽度发生变化时,页面的布局相应的调整,以达到最佳的展示状态。分发场适配时不存在多容器分屏的情况,因此页面容器的接入比较简单,保证页面容器是自适应模式即可。

对于Android,无需特殊处理,iOS则需要设置页面容器为自适应模式:设置容器View的autoresizingMask的属性为UIViewAutoresizingFlexibleWidth|UIViewAutoresizingFlexibleHeight。
下图是多种屏幕状态下的页面容器变化显示效果:

1)横竖屏切换
image.png

2)分屏模式
image.png

3)折叠屏
image.png

2、组件布局

组件布局适配原则:页面容器尺寸发生变化时,动态调整组件的列数以及坑位的尺寸,以达到视觉上的最佳展示体验。

组件的种类繁多,优酷原生标准库组件大约150多个。按组件的布局类别,可以划分为几大类:网格布局组件、轮播布局组件、横滑布局组件、瀑布流布局组件。响应式SDK对这些基础布局均提供了底层适配支持。

1)轮播布局
轮播图在小设备下(手机)展示一个卡片,在大设备下(pad)展示一个卡片会特别大,我们对市面上主流的pad设备进行了采样,最终总结出一个经验值: 放大常量scale=1.2,即卡片宽度放大1.2倍体验最好。轮播图接入规则之后的展示效果如下图:

image.png

首页轮播图支持浮层视频广告,在Pad下增加一个半透明背景,广告居中展示:

image.png

2)网格布局
对于网格布局,在不同的尺寸页面下,根据页面的物理宽度动态适配,显示为不同的列数。针对优酷业务,响应式SDK扩展了网格布局的基础能力,业务方不需要接入即可实现自适应。横竖屏下网络布局展示列数有所不同:

image.png

3)横滑布局
针对横滑布局,响应式提供一了个计算公式,用于动态变换组件在屏幕中的列数(详见技术篇《优酷响应式技术实现-iOS篇》中的介绍),公式中入参为“手机组件列数”。优酷中有十多种类型组件基于横滑布局,以下列举几例。

横滑SCG组件,手机组件列数为3,Pad适配效果如下:

image.png

明星头像组件,手机组件列数为4,Pad适配效果如下:

image.png

正在看组件,手机组件列数为2.5,Pad适配效果如下:
image.png

3、特殊区域适配

顶部导航、底bar、多TAB,是页面的特殊部分,需要业务方跟据响应式状态的变化动态调整布局。
1)顶导适配:
大屏顶导部分适配,在竖屏模式下保持和手机同样的布局,中间部分拉伸展示;
横屏模式下,由于竖向区域变小,为了透出更多的内容,搜索框和多TAB改为左右排版。下图是两种状态的适配效果:

image.png

2)多TAB区域适配:
内容固定居左,横屏&竖屏下固定布局,大小尺寸不变居左展示。

image.png

3)弹框、浮层适配:
内容固定居中,在横屏竖屏下比例不变 保证内容居中展示。

image.png

4)底导适配:
针对这种情况,采用拉伸布局,内容元素在相对宽度内均分适配。

image.png

4、特殊业务适配

使用H5、Weex、小程序架构渲染的页面,考虑到适配的复杂度,我们选择一种即能保证业务正常运转同时能快速适配的折衷方案:采用一种简单的适配原则:对于大屏宽度取屏幕的一半居中展示;设备在折叠状态、分屏状态、浮窗状态时填充容器宽度:

image.png

频道管理适配:Pad下设置最大宽度300dp,当容器宽度小于300dp时,填满容器宽度(如分屏、浮窗模式)。

image.png

有一些业务只支持一个屏幕方向,当旋转到不支持的方向时,给用户一个友好的提示,如少儿绘本页面:

image.png

5、数据加工

某些组件在iPad、折叠屏等大尺寸设备上响应式适配之后,显示存在问题(如下图),如宽度过大、屏幕留白现象。 接下来阐述分发场是如何利用数据加工手段做适配的。

image.png

数据加工是指对后端返回的数据做预处理,以达到在大尺寸设备下组件最佳展示的目的。技术文章《优酷响应式技术实现-Android篇》有更详尽的介绍。

1)数据映射
解决什么问题
存在一些带交互复杂的组件或者Pad上适配效果较差的组件,可以直接映射成其他已适配的组件。降低复杂组件的适配成本,埋点数据字段保持不变,减少对算法埋点数据的影响。

效果
部分数据映射的组件如下:

image.png

2)数据合并
解决什么问题
一些组件适配之后会填充整个屏幕宽,效果不好。这时选择把当前组件数据合并到其下方的组件内,变为下方组件的一部分数据源,以达到显示效果最佳的适配目的。
效果
image.png

3)数据补全
以带换一换的组件为例。后端下发总数量18条,每页的数据为6条,手机上展示3列2行,正好填充一页,但在pad下会空出两个位置(如下图右),这时要调整每页的数据,达到数据补全的目的。在pad下调整一页8条即可。

image.png

还有一种情况,后端下发的数量不足一页,无法铺满屏幕的宽度。解决这类问题,服务端在Phone端数据的基础上,多下发部分业务数据,客户端根据具体的屏幕尺寸,动态调整显示的个数,确保显示效果。
例如:下图中手机上显示2列3行,共6条数据,到了Pad竖屏上显示3列2行,共6条数据,到了Pad横屏上会补全2条数据,显示4列2行,共8条数据。

image.png

4)数据过滤
架构层还提供了数据过滤的能力。如果某些组件适配较复杂,可以考虑折衷的方案暂时过滤掉数据,让业务先跑起来。
分发场景中有一些非核心链路的组件适配较复杂,我们选择先过滤掉,保证APP的正常迭代发版,后续版本再逐渐适配。

四、适配效果及总结

image.png

优酷首页、频道页等核心链路分发场景,经过适配达到了比较好的效果,页面的展示会根据不同的尺寸、分屏、浮窗、折叠等设备状态,动态变换内容布局,而不是等比放大,提升了分发效率、为用户提供更佳的分发体验。

相关文章
|
6天前
|
JavaScript API 开发工具
<大厂实战场景> ~ Flutter&鸿蒙next 解析后端返回的 HTML 数据详解
本文介绍了如何在 Flutter 中解析后端返回的 HTML 数据。首先解释了 HTML 解析的概念,然后详细介绍了使用 `http` 和 `html` 库的步骤,包括添加依赖、获取 HTML 数据、解析 HTML 内容和在 Flutter UI 中显示解析结果。通过具体的代码示例,展示了如何从 URL 获取 HTML 并提取特定信息,如链接列表。希望本文能帮助你在 Flutter 应用中更好地处理 HTML 数据。
91 1
|
22天前
|
存储
让星星⭐月亮告诉你,HashMap的put方法源码解析及其中两种会触发扩容的场景(足够详尽,有问题欢迎指正~)
`HashMap`的`put`方法通过调用`putVal`实现,主要涉及两个场景下的扩容操作:1. 初始化时,链表数组的初始容量设为16,阈值设为12;2. 当存储的元素个数超过阈值时,链表数组的容量和阈值均翻倍。`putVal`方法处理键值对的插入,包括链表和红黑树的转换,确保高效的数据存取。
48 5
|
2月前
|
移动开发 Android开发 数据安全/隐私保护
移动应用与系统的技术演进:从开发到操作系统的全景解析随着智能手机和平板电脑的普及,移动应用(App)已成为人们日常生活中不可或缺的一部分。无论是社交、娱乐、购物还是办公,移动应用都扮演着重要的角色。而支撑这些应用运行的,正是功能强大且复杂的移动操作系统。本文将深入探讨移动应用的开发过程及其背后的操作系统机制,揭示这一领域的技术演进。
本文旨在提供关于移动应用与系统技术的全面概述,涵盖移动应用的开发生命周期、主要移动操作系统的特点以及它们之间的竞争关系。我们将探讨如何高效地开发移动应用,并分析iOS和Android两大主流操作系统的技术优势与局限。同时,本文还将讨论跨平台解决方案的兴起及其对移动开发领域的影响。通过这篇技术性文章,读者将获得对移动应用开发及操作系统深层理解的钥匙。
|
11天前
|
NoSQL PHP Redis
布谷语音app源码服务器环境配置及技术开发语言
布谷语音app源码服务器环境配置及技术语言研发。。
|
29天前
|
安全 网络安全 Android开发
深度解析:利用Universal Links与Android App Links实现无缝网页至应用跳转的安全考量
【10月更文挑战第2天】在移动互联网时代,用户经常需要从网页无缝跳转到移动应用中。这种跳转不仅需要提供流畅的用户体验,还要确保安全性。本文将深入探讨如何利用Universal Links(仅限于iOS)和Android App Links技术实现这一目标,并分析其安全性。
155 0
|
3月前
|
运维 监控 数据可视化
Elasticsearch全观测技术解析问题之面对客户不同的场景化如何解决
Elasticsearch全观测技术解析问题之面对客户不同的场景化如何解决
|
3月前
|
存储 数据挖掘 大数据
深度解析Hologres计算资源配置:如何根据业务场景选择合适的计算类型?
【8月更文挑战第22天】Hologres是一款由阿里云提供的分布式分析型数据库,支持高效的大数据处理与分析。本文通过电商优化商品推荐策略的案例,介绍了Hologres中的计算组型与通用型配置。计算组型提供弹性扩展资源,适合大规模数据及高并发查询;通用型则适用于多数数据分析场景,具备良好计算性能。通过实例创建、数据加载、计算任务建立及结果查询的步骤展示,读者可理解两种配置的差异并根据业务需求灵活选择。
47 2
|
3月前
|
存储 数据库 C++
"深入剖析Python元组(tuple):与列表的对比、特性解析及高效应用场景展示"
【8月更文挑战第9天】Python元组与列表虽均用于存储元素集合,但有本质差异。元组不可变,创建后无法修改,适合保护数据不被意外更改的场景,如作字典键或传递固定值。列表则可变,支持动态增删改,适用于需频繁调整的数据集。元组因不可变性而在性能上有优势,可用于快速查找。两者各有千秋,根据具体需求选择使用。例如,元组可用于表示坐标点或日期,而列表更适合管理用户列表或库存。
96 1
|
3月前
|
JSON 数据格式 索引
【Azure Developer】Azure Logic App 示例: 解析 Request Body 的 JSON 的表达式? triggerBody()?
【Azure Developer】Azure Logic App 示例: 解析 Request Body 的 JSON 的表达式? triggerBody()?
|
3月前
【Azure 应用服务】App Service 配置 Application Settings 访问Storage Account得到 could not be resolved: '*.file.core.windows.net'的报错。没有解析成对应中国区 Storage Account地址 *.file.core.chinacloudapi.cn
【Azure 应用服务】App Service 配置 Application Settings 访问Storage Account得到 could not be resolved: '*.file.core.windows.net'的报错。没有解析成对应中国区 Storage Account地址 *.file.core.chinacloudapi.cn

热门文章

最新文章

推荐镜像

更多