H5在全屏Webview中双端适配刘海屏

2019-12-10 15:45:26

背景:
最近遇到一个看似常规的H5需求,是App内嵌的一个功能模块,看样子跟往常一样重复造轮子就OK了,客户端开个Webview加载页面即可。

正常我们遇到最多的是下面这种类型:

这种的话一般是封装一个Webview包含返回+标题+分享功能,然后加载H5即可,返回即关闭Webview,标题是读取网页的Title属性,分享是调起客户端的分享弹窗。

然是这次的H5有点不寻常的东西:

  1. 导航栏除了返回键、title、右侧的操作菜单(进入另一个H5页),在title还有一个操作项❔,用于点击弹出说明框。
  2. 有一个穿透状态栏和导航栏的背景
    大概长下面这样:

向上面的这种复杂页面一般是客户端做的,但是!!!

IMG_1345_Origina

因为种种原因,最后商量用H5做。那看到这样的设计图,机智的攻城狮们一般会跟产品争论一番讨论说你这背景图做不了,只能到导航栏以下,并且你这个问号得移到其他地方bulabulabula。。。

然而作为一名专业的攻城狮,我们当然是奔着最佳的视觉感官+用户体验去的,遇到问题要克服之!

那么确定100%还原设计图后,首先想到的一个方法是和双端定义一系列协议,包括设置全屏背景图、在title后面加操作按钮(及隐藏方法,因为到其他页面就没了),在右侧加自定义的菜单,点击后可跳转其他页面。这个看着就很麻烦,涉及到一系列的交互想想就头疼,还不如直接原生写的痛快一点。和客户端你同学讨论后他们果然面露难色,在我说完第二秒就否决的这种做法,原因很简单:

1、交互太复杂
2、扩展性太差,下次H5的设计换个样子又得加新交互

最终决定采用全屏Webview的形式,整个页面交给H5控制,这样不管页面设计成什么样都能实现,什么全屏背景,设么导航啦加各种东西通通不在话下。于是愉快的开发开始了。

然鹅在打码到一半的时候我意识到一个问题:双端的状态栏高度不一致,并且现在还有刘海屏存在🌚 这可肿么办?

一、IOS适配

首先对于IOS来说,乔帮主整的还是比较规范的,毕竟IOS闭源系统只能跑在Apple硬件上,设备型号有限,已知各机型尺寸如下:

注: 这里获取到的px值跟web中的px虽然单位一样,但并不是我们需要的值!!!Web所需的px实际为IOS中的pt值...,px转pt需要根据设备的ppi(Pixels Per Inch: 像素密度)进行转换:

px: pixel 像素,是屏幕上的显示的基本点,他并不是长度单位,这个点可以很大,也可以很小。点小的话就很清晰,我们称之为“分辨率高”,反之就是“分辨率低”。所以像素是一个相对单位。

pt: point 准确的说法是一个专用印刷单位“镑”,大小为1/72英寸,是一个长度单位。也是绝对长度。

可以看到ios中的px转pt根据设备的ppi大概是3:1/2:1/1:1转换。
转换完可以看到:

  • 4.7寸6、6s、7、8,状态栏高度为20pt,导航栏高度为44pt.
  • 5.5寸的6p、6sp、7p、8p,状态栏高度为18pt,导航栏高度为44pt.
  • 拥有刘海屏的X、XR、XS、XS MAX、11等一系列刘海屏,状态栏高度为44pt,导航栏高度为44pt.

不难发现:

  • 导航栏 高度所有机型都为44pt;
  • 状态栏 高度大致可以根据是否为刘海屏分为两类。没有刘海屏的大小机型分别为18和20pt,可以近似的看成都是20pt来处理,问题不大,有刘海屏的则统一为44pt高,跟导航栏高度相同。

适配方案:

iOS端的适配方案有两种:Apple官方适配方案、机型区分适配、jsBridge方案

Apple官方适配方案:

1、在粪叉之后引入了一个新概念:“safe area(安全区域)”,安全区域指屏幕内不受圆角、齐刘海、底部小黑条等元素影响的可视窗口。如下图:

2、同时,从iOS11开始,为了适配刘海屏,Apple公司对HTML的viewport meta标签做了扩展

<meta name="viewport" content="viewport-fit=cover">

viewport-fit=cover可设置为auto, contain, cover三种状态,这里我们重点使用cover值,指页面完全充满屏幕。

3、iOS11同时新增了一个特性,constant(safe-area-inset-*),这是Webkit的一个CSS函数,用于获取安全区域与边界的距离,有四个预定义的变量(单位px):

  • safe-area-inset-left:安全区域距离左边界距离,横屏时适配
  • safe-area-inset-right:安全区域距离右边界距离,横屏时适配
  • safe-area-inset-top:安全区域距离顶部边界距离,竖屏下刘海屏为44px,iphone6系列20px,竖屏刘海适配关键
  • safe-area-inset-bottom:安全区域距离底部边界距离,竖屏下为34px,竖屏小黑条适配关键

这样适配方案就比较明确了:

  1. 首先通过设置<meta name="viewport" content="viewport-fit=cover">让页面充满全屏
  2. 通过Webkit内置的CSS函数,获取安全区域与各边之间的间距,然后通过padding/margin/绝对定位等方式,让页面元素展示在安全区域内。

注: Webkit在iOS11中新增CSS Functions: env( )替代constant( ),文档中推荐使用env( ),而 constant( ) 从Safari Techology Preview 41 和iOS11.2 Beta开始会被弃用。在不支持env( )的浏览器中,会自动忽略这一样式规则,不影响网页正常的渲染。为了达到最大兼容目的,我们可以 constant( ) 和 env( ) 同时使用。

padding-top: constant(safe-area-inset-top); /* iOS 11.0 */
padding-top: env(safe-area-inset-top); /* iOS 11.2 */

最终适配代码如下:

使用@supports查询机型是否支持constant() / env()实现兼容代码隔离,个别安卓也会成功进入这个判断,因此加上-webkit-overflow-scrolling: touch的判断可以有效规避安卓机。

@supports ((height: constant(safe-area-inset-top)) or (height: env(safe-area-inset-top))) and (-webkit-overflow-scrolling: touch) {
  .fullscreen {
    /* 适配齐刘海 */
    padding-top: 20;
    padding-top: constant(safe-area-inset-top);
    padding-top: env(safe-area-inset-top);
    
    /* 适配底部小黑条 */
    padding-bottom: 0;
    padding-bottom: costant(safe-area-inset-bottom);
    padding-bottom: env(safe-area-inset-bottom);
  }
}
机型区分适配

这个就比较简单粗暴无脑了。因为目前市面上已有的Apple手机尺寸我们都是已知的,那剩下的就是css中的media适配了:

/* iphone x / xs / 11 pro*/
@media only screen and (device-width: 375px) and (device-height: 812px) and (-webkit-device-pixel-ratio: 3) {
  ...
}
/* iphone xr / 11 */
@media only screen and (device-width: 414px) and (device-height: 896px) and (-webkit-device-pixel-ratio: 2) {
  ...
}
/* iphone xs max / 11 pro max */
@media only screen and (device-width: 414px) and (device-height: 896px) and (-webkit-device-pixel-ratio: 3) {
  ...
}
.....

emmmmmm... 工作量大了点,另外每年9月份发布会后要及时更新代码🙈

jsBridge方案

如果你跟客户端小哥哥的关系比较好的话,就用这种方案吧😳,让客户端写个方法获取状态栏高度,然后在页面加载的时候通过jsbridge调用获取到状态栏高度,然后设置页面样式即可。

好了,鄙人想到的iOS适配方案到此为止。

二、Android适配方案

整完相对规范的iOS,开源的Android就相当眼花缭乱了,机器厂商百花齐放,各厂商的机型也是眼花缭乱。Android机型成百上千,适配方案反而变的简单了!!!why? 因为只有一种方案:JSBridge

像上述iOS的适配方案中,官方适配方案Android肯定是么得了,毕竟机型太多,搞不了官方规范。其次就是CSS media 查询精准适配,如果你的应用只针对于少数机型,那这种方案还是可以用用的,倘若不是那就拜拜了您嘞。

jsBridge方案

同iOS,客户端获取状态栏高度后,H5通过JSBridge交互拿到状态栏高度,设置页面样式避开齐刘海区域。

参考:

vue 项目在低配机器上线及优化

背景 功能:最近帮朋友的忙,抽空用vue-cli3脚手架,开发一个网站,适配pc和mobile,两端分别有约10个页面,也就是十个路由,网站中的图片比较多,且使用了几个自定义字体,ttf文件都在2m左右。 服务器环境:本着能抠一点就抠一点的原则,购买的是阿里云ECS的入门配置,1核1G,40G硬盘,1M带宽,基本上是最低配了。(本来想用搬瓦工来着,但最近搬瓦工被封的厉害,风险比较大,可能买来用一两周就GG了。) 由于是空闲时间搞得,时间也比较急,前期没进过任何优化,直接编译完上线,发现首次全部加载完成耗时32s !分析发现原因如下: 每页加载的图片都在10~25张左右,所有的图片全部没有压缩,尺寸较大,尤其顶部banner达1~2M左右,其余大图在700~800kb之间,每页的图片加起来在5M~10M之间。 引入的自定义平方字体,使用了regular,medium,thin等几种,每种ttf字体都在2M左右,加起来字体有7、8M。 首屏加载所有路由,加载耗时。 由于服务器是1M带宽,那么每秒下行的最高速度约在120k左右,加载以上超过10M的资源,

微屁恩使用指南之 —— V2Ray

经历下架整改后重新上架,替换关键词为“微屁恩” 🌚 ====================== 分割线 ================ 2020.02.06 廊坊,大雪;陕南,雨 ;平凉,大晴。 新冠,正嚣张;强食自爱,正当时。 弱小和无知不是生存的障碍,傲慢才是。 —— 刘慈溪,《三体》 正值立春,雨雪飘零,又时下革命形式严峻,当即抄写《卜算子·咏梅》。吾辈当继承毛泽东同志坚贞不屈的革命意志,面对疫情,严阵以待,做好防护。 下文,非刁民勿入! 这些墙很有意思,刚开始你恨它,慢慢的你习惯于其中,时间久了,你发现离不开它了,这就是“体制化”。 —— 《肖生克的救赎》(The Shawshank Redemption) 一、前言 本文旨在介绍新的科学上网方式——V2Ray的使用。 从最开始GFW(Great