<meta name="screen-orientation" content="portrait">。
1.<!-- uc强制竖屏 --><meta name="screen-orientation" content="portrait"><!-- QQ强制竖屏 --><meta name="x5-orientation"。
2."x5-orientation" content="portrait"><!-- UC强制全屏 --><meta name="full-screen" content="yes"><!-- QQ强制全屏 -->。
3.<meta name="x5-fullscreen" content="true"><!-- UC应用模式 --><meta name="browsermode" content="application">。
4.><!-- QQ应用模式 --><meta name="x5-page-mode" content="app"><!-- windows phone。
5.点击无高光 --><meta name="msapplication-tap-highlight" content="no"><!-- 适应移动端end -->设置横屏应用得在config里面设置。
对于移动端的轻量级 HTML5 互动小游戏(简称为 H5 轻互动),如果从屏幕呈现模式来划分的话,可以归类为:竖屏式和横屏式。
HTML5互动小游戏案例截图
平常我们做过的需求里,主要是以竖屏式为主,而横屏式较少。对于竖屏式场景来说,大家的经验会比较丰富,因此,此次主要式探讨下横屏式场景下的一些需要注意的点,特别是怎样去做横屏适配。
对于 H5 轻互动游戏来说,要实现横屏的话,主要是解决两点:
1.无论用户手持方向如何,都需要保证屏幕横向显示。
2.由于屏幕分辨率的多样化,因此就算是横屏下也是需要进行横屏适配,保证画面在所有分辨率下都能够合理适配。
下面,我们针对这两点分别阐述如何解决。
强制横屏显示
页面内容显示方向可分为竖排方向和横排方向,如下图所示。
页面内容显示方式:竖向排版和横向排版
对于竖屏式 H5 轻互动来说,页面会被期望保持竖排方向显示。而如果页面出现横排方向显示的情况,开发者往往会选择利用提示蒙层来进行友好提示,让用户自主保持竖屏体验,如下图所示。
提示蒙层提醒用户保持竖屏体验
同样地,在横屏式 H5 轻互动游戏中可以采取相同的措施进行简单处理,在页面内容按竖排方向显示时,开发者进行对用户提示其保持横屏体验。
但是,这对用户体验并不友好,因为这对于那些习惯于打开锁定为竖排方向功能(如下图所示)的 iOS 平台用户,或者是关闭屏幕旋转功能(如下图所示)的 Android 平台用户来说,他们需要多一个处理步骤——先关闭竖排方向锁定或是开启屏幕旋转,然后再横向手持设备。
竖排方向锁定功能(iOS)与屏幕旋转(Android)功能
因此,更好的做法是强制横屏显示,对屏幕 resize 事件进行监听,当判断为竖屏时将整个根容器进行逆时针 CSS3 旋转 90 度即可,代码如下所示。
1234567891011121314151617181920212223242526
// 利用 CSS3 旋转 对根容器逆时针旋转 90 度var detectOrient = function() {var width = document.documentElement.clientWidth,height = document.documentElement.clientHeight,$wrapper = document.getElementById("J_wrapper"),style = ""if( width >= height ){ // 横屏style += "width:" + width + "px" // 注意旋转后的宽高切换style += "height:" + height + "px"style += "-webkit-transform: rotate(0)transform: rotate(0)"style += "-webkit-transform-origin: 0 0"style += "transform-origin: 0 0"}else{ // 竖屏style += "width:" + height + "px"style += "height:" + width + "px"style += "-webkit-transform: rotate(90deg)transform: rotate(90deg)"// 注意旋转中点的处理style += "-webkit-transform-origin: " + width / 2 + "px " + width / 2 + "px"style += "transform-origin: " + width / 2 + "px " + width / 2 + "px"}$wrapper.style.cssText = style}window.onresize = detectOrientdetectOrient()
但是!这里有坑:如果你是采用 CreateJS 框架进行开发,那么就不能通过 CSS3 途径对包含 Canvas 的根容器进行旋转处理,因为旋转后会导致 Canvas 内的舞台元素的事件响应位置错乱。
解决办法是,换成利用 CreateJS 框架内的 Stage 的 rotation 属性对整个舞台旋转处理,代码如下:
12345678910
if(self.isPortrait) { // 竖屏// 舞台旋转self.stage.x = self.canvasHeight// 注意:x偏移相当于旋转中点处理,更简单self.stage.rotation = 90// more...}else { // 横屏self.stage.x = 0self.stage.rotation = 0// more...}
横屏适配处理
面对移动端多分辨率繁复冗杂的情况,我们对于一般情况下(也就是常见的竖屏式)页面适配处理可以说是烂熟于心,但是切换到横屏式场景下,同样的页面适配方法可以直接应用吗?会不会有什么问题呢?
下面笔者分别从 DOM 和 Canvas 两方面去着手阐述如何做横屏适配处理。
解决 DOM 的横屏适配问题
在移动端,常见的移动端适配方案是 REM 方案,而为了减少 JS 与 CSS 的耦合,笔者团队开发页面时采用的是 VW + REM 方案。(想要了解该方案的同学可详细阅读《利用视口单位实现适配布局》)。
因为页面适配的场景往往是竖屏式的,因此 VW + REM 方案表现得十分完美。但是遇上横屏式,它的缺点就暴露了出来。
现行的 vw 单位适配方案带来的问题
如上图所示,由于响应断点的限制最大宽度处理,会导致页面两侧留白,当然这可以通过去掉最大宽度限制来解决。而真正的缺点在于,由于 vw 单位的特性,适配换算大小是根据屏幕宽度而言的,因此屏幕宽度越大导致容器、文字会越大,还可能导致 DOM 元素超出屏幕外,且文字过大并不是我们所想要的用户体验。
那么,换成 px 单位的固定布局如何?
但 px 单位的固定布局只适合于部分场景,对于需要内容全屏覆盖的场景(如下图所示),就可能存在这样的不理想的用户体验:绝对定位的元素之间空隙过大,导致布局不美观,又或者空隙过小,导致元素叠放被遮挡。
px单位固定布局适配方案带来的问题
我们了解到,vw 单位的特点是适配换算大小时是根据屏幕宽度而定的,那么在强制横屏显示时,我们就可以同理转换为屏幕高度来而定,也就是 vw 单位替换成 vh 单位。
这样进一步改良之后就会得到满意的适配效果,如下图所示。
更好的适配解决方案—— vw、vh 单位搭配
具体实现可参考如下 SCSS 代码:
123456789101112
$vw_base: 375$vw_fontsize: 20html {font-size: 20px//不支持vw单位时,回退到px单位font-size: ($vw_fontsize / $vw_base) * 100vw}@media screen and (orientation: landscape) {html {font-size: 20pxfont-size: ($vw_fontsize / $vw_base) * 100vh}}
解决 Canvas 的横屏适配问题
解决 Canvas 的横屏适配问题,目前在实际应用中有两种主流的方案:
通过做两套Canvas的方案。
采用缩放的手段进行适配的方案。
两套 Canvas 的方案的做法是,页面包含两个 Canvas 分别用于横竖屏时的相应显示,但是它们的数据是打通的。但是,该方案难免会有局限性,比较适合游戏逻辑数据处理简单、且舞台元素少且居中的场景;
而缩放适配方案做法是,采用的最为常见的缩放手段——利用 CSS3 Transform 的 scale 属性,达到“一种设计尺寸适配多种分辨率屏幕”的目的。
采用了不同适配方案的案例
在市面上的一些成熟的主流 HTML5 游戏引擎,例如 Cocos2D、Laya、Egret 等等,它们本身就集成了横屏适配的方案。如果你有去了解过,可以发现它们普遍都是采用缩放的理念进行适配。
但是,对于我们常用的 CreateJS、PixiJS 框架来说,它们并没有配套的现成的横屏适配解决方案可以被采用的,尤其是我们如果采用原生 Javascript 去开发一个横屏游戏的时候。
因此,下面我们来研究下如何解决 Canvas 横屏适配问题。
注意:下面文中示例代码都是在 CreateJS 框架的基础上进行编写的。
选用合适的缩放模式
横屏适配的核心是缩放,通过 scale 属性等手法将Canvas缩放至适合屏幕窗口大小。类似于 background-size 属性的表现,缩放适配也可以有很多种模式,或有裁剪或无裁剪,或根据长边缩放或根据短边缩放等等。根据一些常见的实际应用场景,有比较常用的五种缩放模式:Contain、Cover、Fill、Fixed-Width、Fixed-Height。根据游戏的不同的实际场景需求,我们可以选其中一种缩放模式进行适配。
下面,我们逐一解释以上五种缩放模式的定义、实现与其适用的场景。
a. Contain模式
Canvas可以类比为一张图,而图片的适配,我们可以联想到经常用以适配背景图片的属性 background-size ,其属性值包括 contain、cover。
借助 contain 的概念,我们把缩放的其中一种模式称为 Contain 模式。因为在这种模式下,舞台内容(gameArea)会保持宽高比进行缩放适配浏览器可视窗口(window),缩放至其能显示完整的舞台内容。
根据下图推导,我们可以得出在这种缩放模式下的缩放比例(scaleRadio),为浏览器可视窗口与游戏内容的宽度比或高度比之间较小者。
Contain 模式下的缩放比例推导图
根据推导结论,简单代码实现如下:
1234567
// Contain模式核心原理函数CONTAIN: function(){var self = thisself.radioX = self.radioY = Math.min((self.winWidth / self.designWidth) , (self.winHeight / self.designHeight))self.canvasWidth = self.designWidthself.canvasHeight = self.designHeight}
可以看出,在 Contain 模式下,如果舞台内容宽高比与浏览器可视窗口的宽高比不相等时,舞台内容并没有填满整个浏览器可视窗口,此时就会出现上下或左右两侧会存在留空部分。
对于这种 Contain 模式,会比较适合舞台背景为纯色或者是渐变类型的H5轻互动,舞台内容与窗口的紧邻处得以自然过渡衔接,不会突兀。
b. Cover模式