導語: iPhone X的出現,一方面對於整個手機行業的發展極具創新領頭羊的做用,另外一方面也對現有業務的頁面適配帶來了新的挑戰。 對於手Q中的各業務來講,受iPhone X影響的H5頁面挺多,應該採起什麼快速有效的辦法來應對呢?css
目前的H5頁面能夠分爲通欄頁面和非通欄頁面兩種,每種頁面均可能有底部操做欄,具體以下:html
通欄頁面ios
頂部通欄web
某些業務的一級頁面多數使用了頂部通欄banner的效果,因爲iPhone X在狀態欄增長了24px的高度,對於如今通欄banner規範的內容區域會有遮擋狀況。api
解決方案:對於通欄頁面在頁面頂部增長一層高度44px的黑色適配層,整個頁面往下挪44px。安全
這種作法雖然不符合蘋果要求的設計規範,但因爲短期內更新所有banner的成本過高,能夠先這樣簡單處理,後續再優化banner的設計展示。app
有些頁面使用了底部Tab欄/操做欄,因爲iPhone X去掉了底部Home鍵,取而代之是34px高度的Home Indicator ,對於目前的底部Tab欄/操做欄會形成必定的阻礙。dom
解決方案:在頁面底部增長一層高度34px的適配層,將操做欄上移34px,顏色能夠自定義。iphone
非通欄頁面佈局
底部Tab欄/操做欄
緣由同上,在底部有34px高度的Home Indicator ,對於目前的底部Tab欄/操做欄會形成必定的阻礙操做。
解決方案:在頁面底部增長一層高度34px的顏色塊,將操做欄上移34px,顏色能夠自定義。
關於安全區域
這裏可能有人會有疑問,爲何非通欄下的頁面內容是通到底部的,而按鈕倒是在安全區域上方呢?
這個問題涉及到安全區域,iOS11 和先前版本的不一樣之處在於,webview 比較重視安全區域了。這意味着,若是給頁面元素設置 top: 0, 它會渲染在屏幕頂部的44px之下,也就是狀態欄下面。若是給頁面元素設置 bottom: 0, 它會渲染在屏幕底部的34px之上,也就是底部安全區域上面。
爲了解決這個尷尬的狀況,蘋果公司給咱們提供了一個設置viewport的meta標籤的解決方案。
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">
viewport 能夠設置的選項就是 viewport-fit,它有三個可選值:
contain: The viewport should fully contain the web content. 可視窗口徹底包含網頁內容
cover: The web content should fully cover the viewport. 網頁內容徹底覆蓋可視窗口
auto: The default value, 同contain的做用
經過給頁面設置viewport-fit=cover,能夠將頁面的佈局區域延伸到頁面頂部和底部。
對於通欄頁面,設置了viewport-fit的屬性,發現會不生效,通過跟同事查看手Q源碼後發現,終端對於WebView通欄的狀況設置了UIScrollViewContentInsetAdjustmentNever屬性,去除了上下安全區域的邊距,使得安全區域的上下邊距失效了。
另外提一點,通過2個版本的webview測試,發現WKWebView在渲染頁面的時候,底部按鈕在位置表現上不一致,多是一個還未解決的bug:
使用web方案:
根據以上的設計方案,能夠這樣處理:
修改頁面viewport-fit屬性
在H5頁面連接一個iphonex.css來給iPhone X訪問的頁面增長對應的適配層
在H5頁面上給對應的dom結構加上適配的類名
iphonex.css
@media only screen and (device-width: 375px) and (device-height: 812px) and
(-webkit-device-pixel-ratio: 3) {
/*增長頭部適配層*/
.has-topbar {
height: 100%;
box-sizing: border-box;
padding-top: 44px;
&:before {
content: '';
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 44px;
background-color: #000000;
z-index: 9998;
}
}
/*增長底部適配層*/
.has-bottombar {
height: 100%;
box-sizing: border-box;
padding-bottom: 34px;
&:after {
content: '';
z-index: 9998;
position: fixed;
left: 0;
bottom: 0;
width: 100%;
height: 34px;
background: #f7f7f8;
}
}
/*導航操做欄上移*/
.bottom-menu-fixed {
bottom: 34px;
}
}
<!DOCTYPE HTML>
<html class="has-topbar has-bottombar">
<head>
<meta charset="utf-8">
<meta name="format-detection" content="telephone=no" />
<meta http-equiv="x-dns-prefetch-control" content="on">
<meta name="viewport" content="width=device-width,initial-scale=1.0,user-scalable=no" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />
<link rel="stylesheet" type="text/css" href="../../css/index.v6/index.css">
<link rel="stylesheet" href="../../css/index.v6/iphonex.css">
<title>遊戲中心</title>
</head>
<body class="body-index " ontouchstart="">
<ul class="ui-tiled bottom-menu bottom-menu-fixed" >
<li class="">
<i class="gc-icon-normal gc-icon-find" ></i>
<div class="txt">遊戲</div>
</li>
<li class="">
<i class="gc-icon-normal gc-icon-live" ></i>
<div class="txt">直播</div>
</li>
<li class="">
<i class="gc-icon-normal gc-icon-compete" ></i>
<div class="txt">賽事</div>
</li>
<li class="">
<i class="gc-icon-normal gc-icon-original" ></i>
<div class="txt">電競圈</div>
</li>
<li class="marker"></li>
</ul>
</body>
</html>
如上,這樣作的問題是,要修改的頁面很是多,並且給頁面帶來了額外的類名,對之後的樣式移除也有必定的工做量。
既然使用web的方式來解決這個問題不是很完美,是否能夠經過終端的方式給webview增長適配層,從而解決這個問題呢?
使用終端方案:
通過跟終端同窗的溝通,肯定是能夠經過終端的方式,針對iPhone X機型,在原生界面初始化的時候可選擇是否要增長適配層,這樣頁面就不須要樣式處理了。
具體是經過連接中增長參數來進行適配:
對於頂部通欄的頁面,經過加URL參數來增長頂部黑色適配層。http://m.gamecenter.qq.com/directout/index?_bid=278&_wvx=1
對於有底部操做欄(包括通欄和非通欄),經過加URL參數來增長底部適配層以及設置顏色。
http://m.gamecenter.qq.com/directout/index?_bid=278&_wvx=10&_wvxBclr=0xf7f7f8
(這裏的wvx=10爲2和8兩個特性數字相加)
這樣,無需寫一行代碼,只須要給頁面連接增長適配參數,就能夠完美適配iPhone X了~
之後的頭部優化以後,也能夠經過參數配置去掉目前的頂部黑色適配層
更多具體技術實現能夠查看這裏:
https://ayogo.com/blog/ios11-viewport/