共计 4846 个字符,预计需要花费 13 分钟才能阅读完成。
简介: 随着挪动互联网设施和技术的倒退,各种挪动设施屏幕尺寸层出不穷,折叠屏、分屏、悬浮窗等等,面对越来越多样的屏幕,如果为每种尺寸独自进行适配,不仅费时费力,还会减少端侧代码的开发与保护压力。如何让一套代码适配所有尺寸变动,加强 App 的通用能力?阿里巴巴娱乐技术 氚雨 将分享优酷 APP 在 iOS 响应式布局技术上的实际和落地。
响应式是基于同一套代码,开发一个 APP 可能兼容多尺寸、多终端设备的显示,可能动静调整页面的布局以及容器的布局,充分利用以后屏幕的尺寸,为用户提供更好的浏览体验,晋升 APP 开发效率和迭代效率。
一 iOS 布局尺寸预研
当下,iOS 端的次要尺寸类型有五种:iPhone、iPad 竖屏、iPad 横屏、iPad 浮窗、iPad 分屏。通常,App 是按 iPhone 尺寸开发的,须要适配残余的四种 iPad 尺寸。
iPad 横、竖屏比拟常见,旋转设施即可,比拟非凡的是浮窗和分屏模式。自苹果 iPad iOS 9 开始,用户在关上一个利用时,从最底部上滑关上 Dock,即可拖拽另一个 App 进入浮窗模式:
在反对分屏的 iPad 上拖拽到更边缘的中央即可开启分屏模式:
其中浮窗模式所有降级 iOS 9 的设施都反对,分屏模式只有最新版的硬件设施 iPad mini 4、iPad Air 2 及 iPad Pro 反对:
二 优酷 iOS 响应式计划
响应式布局的外围是设计对立的适配规定,并在屏幕尺寸发生变化时按布局规定从新布局,以适配不同屏幕尺寸,而大多数 App 在开发时个别只有适配 iPhone 的版本,在通过响应式适配更多机型时次要要解决三个方面的问题,即如何获取、更新响应式状态以进行对应的适配,如何计算在不同屏幕宽度下 App 内容的宽度、列数等布局参数,如何进行响应式下的数据处理以解决较难适配的组件、缩小页面留白等,基于此咱们开发了响应式布局 SDK,负责对立治理响应式状态、解决布局逻辑、裁剪映射数据等。
1 响应式 App 配置
App 除了配置为 universal 版之外,要反对浮窗或分屏模式还须要进行一些配置:
(1)须要提供 LaunchScreen.storyboard 作为启动图,因为 App 反对的运行尺寸太多,不再适宜用图片作为启动图。
(2)须要在 info.plist 中配置反对所有屏幕方向:
(3)留神不能勾选 Requires full screen 配置项或配置 UIRequiresFullScreen 为 YES,如此会申明 App 要求全屏运行,天然示意不反对浮窗或分屏:
(4)反对分屏要求 App 的主 Window 须要应用零碎 UIWindow,不能继承,并且要通过 init 办法或 initWithFrame:[UIScreen mainScreen].bounds 形式初始化。
通过以上步骤开启浮窗、分屏能力后,在 App 内就无奈再通过相干代码管制设施方向,以往通过如下代码可管制 ViewController 为竖屏,而反对分屏后如下办法零碎不再调用,默认所有 ViewController 反对所有屏幕方向:
如下强制设置屏幕方向的黑办法也已生效:
这种设计的次要起因是,当一个 App 反对分屏后,就不再独自占用整个屏幕,当另一个 App 同时运行时,同一块屏幕不可能呈现一个横屏、另一个竖屏。此类问题没有完满的解决方案,为了保障用户体验,反对分屏的 App 必须所有页面适配所有屏幕方向,这也体现了苹果对用户体验的极致谋求,参见 DeveloperForums 中开发人员的探讨:
https://developer.apple.com/forums/thread/19578
2 响应式 SDK
响应式状态治理
响应式状态提供了以后是否开启响应式、响应式布局尺寸类型、以后布局 window 尺寸等相干状态量,响应式 SDK 会在屏幕尺寸变动后更新响应式状态,并通过零碎告诉和自定义告诉机制,告诉相干业务方。
// 响应式开启敞开状态
typedefNS_ENUM(NSInteger, YKRLLayoutStyle) {
YKRLLayoutStyleNormal =0, // 响应式状态敞开
YKRLLayoutStyleResponsive =1, // 响应式状态开启};
// 响应式屏幕尺寸类型,页面可根据此类型辨别是否分屏等
typedefNS_ENUM(NSInteger, YKRLLayoutSizeType) {
YKRLLayoutSizeTypeS =0, // eg. phone pad 浮窗
YKRLLayoutSizeTypeL =1, // pad
YKRLLayoutSizeTypeXL =2, // 预留
};
// 响应式屏幕状态类型(一共有十种类型)typedefNS_OPTIONS(NSUInteger, YKRLLayoutScreenType) {YKRLLayoutScreenTypeUnknown = (1<<0), // 未知
YKRLLayoutScreenTypePortrait = (1<<1), // 竖屏全屏
YKRLLayoutScreenTypeLandscapeLeft = (1<<2), // 横屏全屏左
… …
};
响应式 SDK 申明了 YKRLLayoutStyle、YKRLLayoutSizeType、YKRLLayoutScreenType 三种枚举状态标记以后的响应式状态,别离示意响应式开启敞开状态,以后尺寸类型及具体屏幕类型,个别业务方只须要获取是否是响应式设施状态,对于在不同宽度下页面布局不统一的业务方能够通过尺寸类型状态进行辨别适配,而对于须要具体晓得以后屏幕状态的业务方能够通过屏幕类型获取,屏幕类型只蕴含以后 iOS 设施已反对的屏幕状态,随着设施类型的丰盛,如呈现折叠屏等,屏幕类型会作相应扩大。每当设施旋转或用户开启分屏时,响应式 SDK 都会在零碎回调中更新以后响应式状态,并告诉业务方响应式状态的扭转。
响应式布局规定
优酷响应式布局规定次要蕴含列数适配规定、宽度适配规定等,比方多列均分组件的列数在不同屏幕宽度下是可变的,响应式 SDK 会依据以后的响应式状态输入适合的布局列数等,对于每一个布局规定,响应式 SDK 中都有相应的布局适配逻辑,响应式布局规定满足优酷 App 整体 UI 标准,业务方间接指定本人所须要的规定即可,除少数非凡规定之外,大部分布局规定都用于组件列数和组件宽度布局,此类响应式布局规定中会指定一个规范宽度,并依据组件原始布局列数和规范宽度计算出组件规范宽度,进而依据以后屏幕宽度计算出适配后的组件列数,可用如下公式表白:
响应式适配列数(规范屏幕宽度下组件列数) = (以后屏幕宽度÷(规范屏幕宽度÷规范屏幕宽度下组件列数×scale))
其中,scale 为组件放大参数,规范屏幕宽度下组件原宽度投放到 iPad 上会过小,能够通过 scale 参数进行适当放大。
对于组件宽度适配,响应式规定会先计算规范屏幕宽度下的组件列数并进行列数适配,再通过适配后的列数计算适配宽度:
响应式适配宽度(规范屏幕宽度下组件宽度) = (以后屏幕宽度 – 边距间距)÷响应式适配列数(规范屏幕宽度÷规范屏幕宽度下组件宽度)
在以上公式中调整规范屏幕宽度及组件放大 scale 即可失去适配成果较好的通用布局规定,通过设计同学在各种设施尺寸下的调整总结,以后优酷中应用的规范屏幕宽度为 440dp,scale 为 1.2 倍,适配成果最佳。组件适配逻辑已在响应式 SDK 布局规定中对立实现,业务方间接调用即可,也不便设计同学对整个 App 的组件适配进行对立调整。
响应式 SDK 中 YKRLCompLayoutManager 类封装了相干布局逻辑,业务方也可通过 YKRLCompLayoutAdapterProtocol 协定二次解决,以定制响应式布局逻辑,在 App 对立架构中间接调用 YKRLCompLayoutManager 的相干接口即可获取依照响应式规定计算后的布局参数,如列数、宽度等,当监听响应式状态发生变化时从新布局即可实现响应式布局。
响应式数据处理
响应式数据处理包含数据映射、数据过滤、数据合并、数据补齐,数据处理逻辑两端统一,具体介绍能够参见:一个 APP 如何适配多个 Android 终端?,上面简略介绍一下 iOS 响应式数据映射的实现。
有些组件无奈通过规定适配不同的屏幕尺寸,比方在手机上占整个屏幕宽度的组件(下图左侧带视频播放预约组件),如果采纳等比放大的适配规定,在 iPad 端会显得过大,此类组件能够映射成绝对简略的组件,以适配不同的屏幕尺寸。
优酷采纳了对立形象的数据结构,在组件映射方面比拟容易实现,只需批改对应的组件标记即可。得益于对立架构的普遍推广和应用,咱们在对立架构内增加了组件映射能力,不便各业务方调用,响应式 SDK 中提供了数据裁剪映射规定,业务方能够查问、减少相应的裁剪映射规定。对于未接入对立架构的业务方则须要业务方实现相干数据处理。
3 响应式业务流程
优酷响应式业务流程两端统一,响应式布局须要进行数据处理、响应式状态治理、触发布局等工作,优酷响应式 SDK 会在接口返回后处理相干数据,为对立架构提供相应布局接口,监控屏幕尺寸变动并触发布局等。
4 优酷响应式计划落地
iOS 开发中常常采纳相对布局,而实现响应式的次要工作是将“相对布局”批改为“绝对布局”,接入工作较安卓更为繁琐。
iOS 响应式能够按 Window->ViewController-> 容器 -> 组件的层级实现接入。
Window 在配置反对分屏后会由零碎主动布局,在 RootViewController 树中的子 ViewController 也会随 Window 主动布局,而非凡 ViewController,如多 tab 页面的子 ViewController 等,未退出 RootViewController 树,须要手动批改为绝对布局,页面可通过 Autoresizing 或监听响应式状态实现绝对布局。
接入对立架构的页面容器由对立架构提供,对立架构容器的布局列数治理、布局宽度治理等都已接入响应式 SDK,为业务方接入缩小了大量工作,业务方只需指定本身所采纳的布局规定即可,ViewController 和容器实现绝对布局后,每当屏幕尺寸变动时响应式 SDK 会告诉容器从新布局,变换组件列数或宽度等,组件卡片只须要按容器提供的尺寸进行布局即可。
组件卡片内个别应用 Frame 相对布局,须要批改为绝对布局,简略的布局逻辑能够应用 Autoresizing 实现,方便快捷,简单的布局能够应用 AutoLayout 或 Masonry 等主动布局框架(性能较差)实现,也能够在 layoutSubviews 办法中从新计算布局,业务方能够抉择适合的形式实现主动布局,以缩小接入老本。
对于未接入对立架构的页面则须要在本页面布局逻辑中手动接入响应式 SDK 相干布局接口。
落地过程中发现许多组件卡片布局时依赖了屏幕宽度,不合乎响应式开发标准,导致适配响应式时工作量较大。每一层 View 只应依赖父层 View 布局,各层 View 实现绝对布局后,每当屏幕尺寸扭转时各层 View 会主动适配,同时容器的组件列数和尺寸会按响应式规定进行适配,一套代码即可适配所有屏幕尺寸,实现响应式布局。
三 优酷响应式成绩
目前优酷全端已具备响应式布局的能力,八月份已上线 universal 版本,一套代码反对 iPhone、iPad 竖屏、iPad 横屏、浮窗、各种比例分屏,为用户提供了更好更丰盛的用户体验。
四 总结
响应式能力是多端投放能力的第一步,优酷实现响应式布局后对开发、设计和产品都提出了更高的要求,同时鉴于 iPad 低端设施占比拟高,业务开发过程中不仅要思考通投能力,更要求 App 始终保持更高的性能和稳定性,这是咱们继续在致力的。
苹果 2020 年底将推出基于 ARM 架构的 MacBook,也有媒体曝光,苹果正在申请折叠屏相干的专利,置信将来苹果设施的尺寸会越来越丰盛,App 适配提效是绕不开的话题,而优酷响应式的开发极大扩大了 iPhone 版 App 的实用场景,是解决多种设施反对的更好路径,为适应将来更简单的设施场景打下坚实基础。
原文链接
本文为阿里云原创内容,未经容许不得转载。