图片 42

H5 游戏开发:横屏适配

H5 游戏开发:横屏适配

2017/10/31 · HTML5 · 1
评论
·
横屏,
游戏

原文出处:
凹凸实验室   

对于移动端的轻量级 HTML5 互动小游戏(简称为 H5
轻互动),如果从屏幕呈现模式来划分的话,可以归类为:竖屏式和横屏式。

 

图片 1

HTML5互动小游戏案例截图

平常我们做过的需求里,主要是以竖屏式为主,而横屏式较少。对于竖屏式场景来说,大家的经验会比较丰富,因此,此次主要式探讨下横屏式场景下的一些需要注意的点,特别是怎样去做横屏适配。

对于 H5 轻互动游戏来说,要实现横屏的话,主要是解决两点:
1.无论用户手持方向如何,都需要保证屏幕横向显示。
2.由于屏幕分辨率的多样化,因此就算是横屏下也是需要进行横屏适配,保证画面在所有分辨率下都能够合理适配。

下面,我们针对这两点分别阐述如何解决。

游戏内容适配

游戏内容可以分为两类
有效内容:游戏中一定需要显示在屏幕上的内容
实际内容:包括有效内容和为了适配、或其它目的增加的内容。

  1. 3D游戏中把要么场景做得比正常显示时更大一些;要么显示天空盒子。

  2. 2D游戏中也是把背景做得大一些,尽可能让游戏不出现黑边。
    我们的开发一般都会选择在一个固定的设计分辨率上进行,比如常用的iOS竖屏游戏设计分辨率640*960,我们就以这个设计分辨率为例。通常情况下,设计分辨率尺寸就是我们游戏有效内容的尺寸。
    orthographicSize设置为4.8,就可以让游戏内容铺满屏幕

这里有一篇文章,里面详细讲了unity
2D游戏的屏幕适配

参考资料

《如何打造一个高效适配的H5》
《Cocos2d-JS的屏幕适配方案》
《Cocos2d-JS
多分辨率适配方案》

《Cocos2d-JS
对齐策略》

《Laya引擎-自动横屏适配》
《Phaser-scaleManager对象》
《How to create mobile games for different screen sizes and
resolutions》

《Egret-屏幕适配策略》

游戏
H5
适配
横屏

Web开发

感谢您的阅读,本文由 凹凸实验室
版权所有。如若转载,请注明出处:凹凸实验室(https://aotu.io/notes/2017/10/18/landscape_mode_in_html5_game/

1 赞 3 收藏 1
评论

图片 2

Flexible:

在该模式下,下面的UI都是以像素为基础,100像素的物体无论在多少分辨率上都是100像素,这就意味着,100像素在分辨率低的屏幕上可能显示正常,但是在高分辨率上就会显得很小。

在该模式下,UIRoot的属性如下:

图片 3

这里写图片描述

Minimum
Height:设置为725时,当屏幕高度小于725时,在该屏幕上显示的样子和开发时一致。
Maximum
Height:设置为1024时,当屏幕高度大于1024时,在该屏幕上显示的样子和开发时一致。

Shrink Portrait UI:当是竖屏状态时,按宽度来适配。
Adjust by DPI:使用dpi做适配计算。

解决 Canvas 的横屏适配问题

解决 Canvas 的横屏适配问题,目前在实际应用中有两种主流的方案:

  1. 通过做两套Canvas的方案。
  2. 采用缩放的手段进行适配的方案。

两套 Canvas 的方案的做法是,页面包含两个 Canvas
分别用于横竖屏时的相应显示,但是它们的数据是打通的。但是,该方案难免会有局限性,比较适合游戏逻辑数据处理简单、且舞台元素少且居中的场景;

而缩放适配方案做法是,采用的最为常见的缩放手段——利用 CSS3 Transform 的
scale 属性,达到“一种设计尺寸适配多种分辨率屏幕”的目的。

 

图片 4

采用了不同适配方案的案例

在市面上的一些成熟的主流 HTML5 游戏引擎,例如 Cocos2D、Laya、Egret
等等,它们本身就集成了横屏适配的方案。如果你有去了解过,可以发现它们普遍都是采用缩放的理念进行适配。

但是,对于我们常用的 CreateJS、PixiJS
框架来说,它们并没有配套的现成的横屏适配解决方案可以被采用的,尤其是我们如果采用原生
Javascript 去开发一个横屏游戏的时候。

因此,下面我们来研究下如何解决 Canvas 横屏适配问题。

注意:下面文中示例代码都是在 CreateJS 框架的基础上进行编写的。

Constrained On Mobiles

前两种模式的组合,在PC和Mac等桌面设备上用Flexible模式,
在移动设备上Constrained模式。

  1. UIAnchor or UIStretch
    作为NGUI中一个组件,但之前做的项目里面好像怎么用,可以把它看做对一个UI树中的局部进行控制。它们在处理细节上很相似,都是先计算参照对象(这个参照对象由Insprector的Container指定,如果没有选择,就是Camera)的大小Rect,然后根据参数UIAnchor(Side,relativeOffset,pixelOffset),UIStretch(Style,relativeSize,initialSize,borderPadding)进行调整,最后设置对应的属性,只不过UIAnchor设置的是transform.position,UIStretch设置的是(width,height)或clipRange等。

UIAnchor组件的视图:

图片 5

这里写图片描述

Container:指定Anchor的参照点,如果没有选择,则以Camera的pixelRect的区域为参照面

Side:锚点位置,有八个位置可选。
Relative Offset:相对于Camera,或Container的百分比偏移 。
Pixel Offset:像素的偏移。

UIStretch组件的视图:

图片 6

这里写图片描述

大致和UIAnchor差不多,Style属性有些改动如下

Horizontal:横向拉伸。
Vertical:纵向拉伸。
Both:双向拉伸,但xy方向上的拉伸比例不同。
BasedOnHeight:双向拉伸,但xy方向上的拉伸比例相同,且比例基于height。
FillKeepingRatio:双向拉伸,但xy方向上的拉伸比例相同,比例基于较大者。
FitInternalKeepingRatio:双向拉伸,但xy方向上的比例相同,比例基于较小者。

具体的可以自己研究一下,但是不建议用这个两货,折腾了一下感觉太麻烦,而且根本没必要啊,因为UIRoot已经做了大部分的适配了,那些局部细节上的调整完全可以用UIRect所管理的Anchor来实现,它不是单独的组件,比这两简单多了,下面就来聊聊它。

  1. UIRect的Anchor
    首先得了解一些UIRect,这里不详细聊它,后面会整理一篇分析NGUI底层的文章,里面有详细说它。简单介绍一下,从NGUI控件的继承结构上,UIRect是所有weight和panel的基类,管理着rect和anchor,计算、生成,是一个抽象类。

拿UISprite举例:

图片 7

这里写图片描述

Type:三种类型,使用锚点、基本控制、完全控制。
Execute:设置在什么时候执行锚点适配。
Target:参考物体。
Left、Right、Bottom、Top:该控件上下左右边。

比如,你想某个按钮在任何尺寸屏幕上都停留在屏幕上的左边,可以如下:

16:9屏幕上

图片 8

这里写图片描述

锚点设置如下:UISprite的左右边界都参考target的左边

图片 9

这里写图片描述

然后5:4屏幕上,UISprite依然在屏幕的左边了

图片 10

这里写图片描述

当然其它的weight都可以设置锚点,可以这么说,凡事继承自UIRect的组件都可以使用该锚点。

选用合适的缩放模式

横屏适配的核心是缩放,通过 scale
属性等手法将Canvas缩放至适合屏幕窗口大小
。类似于 background-size
属性的表现,缩放适配也可以有很多种模式,或有裁剪或无裁剪,或根据长边缩放或根据短边缩放等等。根据一些常见的实际应用场景,有比较常用的五种缩放模式:Contain、Cover、Fill、Fixed-Width、Fixed-Height。根据游戏的不同的实际场景需求,我们可以选其中一种缩放模式进行适配。

下面,我们逐一解释以上五种缩放模式的定义、实现与其适用的场景。

a. Contain模式

Canvas可以类比为一张图,而图片的适配,我们可以联想到经常用以适配背景图片的属性
background-size ,其属性值包括 containcover

借助 contain 的概念,我们把缩放的其中一种模式称为 Contain
模式。因为在这种模式下,舞台内容(gameArea)会保持宽高比进行缩放适配浏览器可视窗口(window),缩放至其能显示完整的舞台内容。

根据下图推导,我们可以得出在这种缩放模式下的缩放比例(scaleRadio),为浏览器可视窗口与游戏内容的宽度比或高度比之间较小者

 

图片 11

Contain 模式下的缩放比例推导图

根据推导结论,简单代码实现如下:

JavaScript

// Contain模式核心原理函数 CONTAIN: function(){ var self = this;
self.radioX = self.radioY = Math.min((self.winWidth / self.designWidth)
, (self.winHeight / self.designHeight)); self.canvasWidth =
self.designWidth; self.canvasHeight = self.designHeight; }

1
2
3
4
5
6
7
// Contain模式核心原理函数
CONTAIN: function(){
  var self = this;
  self.radioX = self.radioY = Math.min((self.winWidth / self.designWidth) , (self.winHeight / self.designHeight));
  self.canvasWidth = self.designWidth;
  self.canvasHeight = self.designHeight;
}

可以看出,在 Contain
模式下,如果舞台内容宽高比与浏览器可视窗口的宽高比不相等时,舞台内容并没有填满整个浏览器可视窗口,此时就会出现上下或左右两侧会存在留空部分。

对于这种 Contain
模式,会比较适合舞台背景为纯色或者是渐变类型的H5轻互动,舞台内容与窗口的紧邻处得以自然过渡衔接,不会突兀。

b. Cover模式

同样地,借助 cover 的概念把其中一种模式称为 Cover
模式。在这种模式下,舞台内容(gameArea)会保持宽高比进行缩放适配浏览器可视窗口(window),缩放至舞台内容填满窗口。

根据下图推导,我们可以得出在这种缩放模式下的缩放比例(scaleRadio),为浏览器可视窗口与游戏内容的宽度比或高度比之间较大者

 

图片 12

Cover 模式下的缩放比例推导图

根据推导结论,简单代码实现如下:

JavaScript

// Cover模式核心原理函数 COVER: function(){ var self = this; self.radioX
= self.radioY = Math.max((self.winWidth / self.designWidth) ,
(self.winHeight / self.designHeight)); self.canvasWidth =
self.designWidth; self.canvasHeight = self.designHeight; }

1
2
3
4
5
6
7
// Cover模式核心原理函数
COVER: function(){
  var self = this;
  self.radioX = self.radioY = Math.max((self.winWidth / self.designWidth) , (self.winHeight / self.designHeight));
  self.canvasWidth = self.designWidth;
  self.canvasHeight = self.designHeight;
}

在 Cover
模式下,如果舞台内容宽高比与浏览器可视窗口的宽高比不相等时,由于舞台内容需要填满整个浏览器可视窗口,此时就会出现上下或者左右两侧被裁剪的情况。

那么,如果能保证游戏场景内的重点显示内容全部显示,被裁剪内容无关紧要时,那么这种
H5 轻互动类型就可以考虑采用 Cover 模式。

怎么做到保证想要重点显示的内容可以不被裁剪呢?这时要谈到一个“安全区域”的概念,指的是绝对不会被裁剪的内容区域,它应该是由最小的屏幕可视窗口(目前应该是
iPhone 4 )与最大的屏幕可视窗口(目前应该是 iPhone 7
Plus)叠加后得出的重叠区域,如下图所示。

 

图片 13

“安全区域”即为红色虚线框内部分

开发者应该在设计阶段与设计师、产品等相关人员进行沟通,告知其不想被裁剪的内容都应该在“安全区域”进行设计布局。

c. Fill模式

Fill 模式,可以类比为 backgrouns-size: 100% 100%
的表现,在这种模式下,不会保持宽高比,舞台内容(gameArea)的宽高分别按照舞台内容与浏览器可视窗口(window)的宽度比与高度比进行缩放,缩放至舞台内容拉伸铺满窗口。

根据下图推导,我们可以得出在这种缩放模式下的缩放比例(scaleRadio),为对于游戏内容的宽应用其与可视窗口的宽度比,而游戏内容的高应用其与可视窗口的高度比

 

图片 14

Fill 模式下的缩放比例推导图

根据推导结论,简单代码实现如下:

JavaScript

// Fill模式核心原理函数 FILL: function(){ var self = this; self.radioX =
(self.winWidth / self.stageWidth); self.radioY = (self.winHeight /
self.stageHeight); self.canvasWidth = self.designWidth;
self.canvasHeight = self.designHeight; }

1
2
3
4
5
6
7
8
// Fill模式核心原理函数
FILL: function(){
  var self = this;
  self.radioX = (self.winWidth / self.stageWidth);
  self.radioY = (self.winHeight / self.stageHeight);
  self.canvasWidth = self.designWidth;
  self.canvasHeight = self.designHeight;
}

这种模式下既不会留空,也不会被裁剪,但是在舞台内容宽高比与浏览器可视窗口的宽高比不相等时,显示的内容会有一定程度的拉伸形变。

这种暴力的处理方式虽然免去了留空和裁剪的烦恼,但是会存在拉伸形变,这就得看是否能够被接受了。

d. Fixed-Width模式

区别于图像,Canvas
是可以进行动态绘制大小的。所以,我们可以考虑根据屏幕窗口大小变化来动态绘制
Canvas。
从保持舞台横向内容不变的角度考虑,我们提出这样的模式:舞台内容(gameArea)等比进行缩放至与浏览器可视窗口的一致的宽度大小,而舞台的高度(Canvas高度)进行重新绘制其高度为浏览器可视窗口的高度,称之为
Fixed-Width 模式。

根据下图推导,我们可以得出在这种缩放模式下的缩放比例(scaleRadio),为浏览器可视窗口与游戏内容的宽度比

 

图片 15

Fixed-Width 模式下的缩放比例推导图

根据推导结论,简单代码实现如下:

JavaScript

// Fixed-Width模式核心原理函数 FIXED_WIDTH: function(){ var self =
this; self.radioX = self.radioY = self.winWidth / self.designWidth;
self.canvasWidth = self.designWidth; self.canvasHeight = self.winHeight
/ self.radioY; }

1
2
3
4
5
6
7
// Fixed-Width模式核心原理函数
FIXED_WIDTH: function(){
  var self = this;
  self.radioX = self.radioY = self.winWidth / self.designWidth;
  self.canvasWidth = self.designWidth;
  self.canvasHeight =  self.winHeight / self.radioY;
}

在 Fixed-Width
模式下,无论在什么分辨率下,舞台横向内容保持不变,而纵向高度则会动态裁补,这就会比较适用于那些场戏场景可以纵向拓展的
H5 轻互动类型。

e. Fixed-Height模式

说完 Fixed-Width 模式,换个角度考虑便得出 Fixed-Height
模式,舞台内容(gameArea)等比进行缩放至与浏览器可视窗口的一致的高度大小,而舞台的宽度(Canvas宽度)进行重新绘制其宽度为浏览器可视窗口的宽度。

根据下图推导,我们可以得出在这种缩放模式下的缩放比例(scaleRadio),为浏览器可视窗口与游戏内容的高度比

 

图片 16

Fixed-Height 模式下的缩放比例推导图

根据推导结论,简单代码实现如下:

JavaScript

// Fixed-Height模式核心原理函数 FIXED_HEIGHT: function(){ var self =
this; self.radioX = self.radioY= self.winHeight / self.designHeight;
self.canvasWidth = self.winWidth / self.radioX; self.canvasHeight =
self.designHeight; }

1
2
3
4
5
6
7
// Fixed-Height模式核心原理函数
FIXED_HEIGHT: function(){
  var self = this;
  self.radioX = self.radioY= self.winHeight / self.designHeight;
  self.canvasWidth = self.winWidth / self.radioX;
  self.canvasHeight = self.designHeight;
}

与 Fixed-Width 模式相反,Fixed-Height
模式下,舞台纵向内容保持不变,而横向宽度则会动态裁补。对于这种模式的应用场景应该会比较广泛,譬如常见的跑酷游戏类型H5轻互动。

补充一下一些关于屏幕的基本概念

dip:设备无关像素
dp:就是dip
px:像素
dpi:像素密度,单位面积上有多少个像素点
分辨率:宽高两个方向上的像素点数,如800*600
屏幕尺寸:屏幕对角线长度
屏幕比例:宽高比

详细的转换关系,去这里看看。

开发时的布局:

图片 17

这里写图片描述

改变Game视图大小:

图片 18

这里写图片描述

改变Game视图大小,高度大于725,小于1024,(按刚刚的截图中设置的值测试的):

图片 19

这里写图片描述

在高度在Minimum和Maximum之间时,UIRoot就不会对下面的UI缩放了,开发时有多少像素在高分辨下也只有那么点像素,所以看起来就变小了。

这个Minimum和Maximum
Height用于你对实际的屏幕尺寸进行限制,如果实际的屏幕尺寸小于Minimum,那么就相当于设置了“Constrained”模式、Manual
Height值设为Minimum的时候一样,同理,如果屏幕尺寸超过了Maximum,那也相当于设置了“Constrained”模式、Manual
Height值设为Maximum的时候一样。

以上是在Flexible模式的关于分辨率的适配,还有一个是宽高比适配,分两种情况:

当高大于宽的是,也就是竖屏状态时

图片 20

这里写图片描述

两边被截了

图片 21

这里写图片描述

只需要勾上Shrink Portrait
UI,就能按照宽度来适配了(因为默认横屏状态,并且默认按高度适配,所以在看这段源码的时候,它里面的计算是宽高颠倒的):

图片 22

这里写图片描述

解决 DOM 的横屏适配问题

在移动端,常见的移动端适配方案是 REM 方案,而为了减少 JS 与 CSS
的耦合,笔者团队开发页面时采用的是 VW + REM
方案。(想要了解该方案的同学可详细阅读《利用视口单位实现适配布局》)。

因为页面适配的场景往往是竖屏式的,因此 VW + REM
方案表现得十分完美。但是遇上横屏式,它的缺点就暴露了出来。

 

图片 23

现行的 vw 单位适配方案带来的问题

如上图所示,由于响应断点的限制最大宽度处理,会导致页面两侧留白,当然这可以通过去掉最大宽度限制来解决。而真正的缺点在于,由于
vw
单位的特性,适配换算大小是根据屏幕宽度而言的,因此屏幕宽度越大导致容器、文字会越大,还可能导致
DOM 元素超出屏幕外,且文字过大并不是我们所想要的用户体验。

那么,换成 px 单位的固定布局如何?

但 px
单位的固定布局只适合于部分场景,对于需要内容全屏覆盖的场景(如下图所示),就可能存在这样的不理想的用户体验:绝对定位的元素之间空隙过大,导致布局不美观,又或者空隙过小,导致元素叠放被遮挡。

 

图片 24

px单位固定布局适配方案带来的问题

我们了解到,vw
单位的特点是适配换算大小时是根据屏幕宽度而定的,那么在强制横屏显示时,我们就可以同理转换为屏幕高度来而定,也就是
vw 单位替换成 vh 单位

这样进一步改良之后就会得到满意的适配效果,如下图所示。

 

图片 25

更好的适配解决方案—— vw、vh 单位搭配

具体实现可参考如下 SCSS 代码:

JavaScript

$vw_base: 375; $vw_fontsize: 20; html { font-size: 20px;
//不支持vw单位时,回退到px单位 font-size: ($vw_fontsize / $vw_base) *
100vw; } @media screen and (orientation: landscape) { html { font-size:
20px; font-size: ($vw_fontsize / $vw_base) * 100vh; } }

1
2
3
4
5
6
7
8
9
10
11
12
$vw_base: 375;
$vw_fontsize: 20;
html {
  font-size: 20px; //不支持vw单位时,回退到px单位
  font-size: ($vw_fontsize / $vw_base) * 100vw;
}
@media screen and (orientation: landscape) {
  html {
    font-size: 20px;
    font-size: ($vw_fontsize / $vw_base) * 100vh;
  }
}

Orthographic为平行投影

图片 26

这里写图片描述

与透视投影不同的是size属性,它用来调整摄像机的大小
orthographicSize:等于相机高度的一半

注意一下,unity中的单位和像素之间有一个转换关系,叫做Pixels To Units

图片 27

这里写图片描述

默认为100,unity中一个单位表示图片的100个像素。如果游戏屏幕高为800像素,那么换算后高度为
800 / 100 / 2 = 4。

unity没有直接设置摄像机宽度的属性,也没有获取摄像机宽度的接口,但可以通过高度和宽高比计算出来。那么计算宽度如下:

cameraWidth = camera.orthographicSize * 2 * camera.aspect

换算成像素:cameraWidth * 100

cameraHeight = camera.orthographicSize * 2

换算成像素:cameraHeight * 100

相机的宽高比是unity自动设置为当前屏幕宽高比的,所以camera.aspect不需要自己设置。

  1. 缩放
    在Transform组件上,可以设置控制物体每个方向上的缩放比例。
![](https://upload-images.jianshu.io/upload_images/1479565-cc8589a9b37d7ec2)

这里写图片描述
  1. 锚点(相对位置)
    目前NGUI,UGUI都有类似的功能,稍后再讨论。

加入重定位和重绘制策略

综合以上五种缩放模式,我们可以看到对于 Cover、Fixed-Width、Fixed-Height
模式而言,有存在被裁剪的可能性。特别是 Fixed-Height
模式,对于横屏游戏来说这是比较常用的模式,但是在屏幕较小的时候难免会被裁剪,而且我们是不希望贴边元素被裁剪掉的,譬如位于右上角的音乐图标。而对于
Fixed-Width、Fixed—Height
模式,它们还存在舞台区域需要补充绘制的情况,因此对某些舞台元素来说需要重新设定其渲染大小。

所以,除了基本的缩放适配模式实现之外,为了解决贴边元素不被裁剪以及对一些舞台元素重绘制的需求,我们还需要加入两个策略:重定位和重绘制。

a. 重定位

贴边元素重定位策略的实现原理很简单,对需要重新定位的元素对象额外设置
topleftrightbottom
的自定义属性(当然你可以命名为其他属性名),这样我们就可以在适配的时候根据这些自定义属性以及实际显示的
Canvas 大小进行重新计算位置。

为了保证性能,下面是策略里需要注意的地方:

  1. 在舞台里,并不是所有游戏元素都是需要被重定位的,因此我们只需要创建一个数组记录需要被重定位的元素。
  2. 适当控制重定位次数,我们不需要在每一帧 tick
    绘制的时候都进行重定位,只需要在 Canvas 大小改变的时候进行处理。

以下是重定位策略相关的代码:

JavaScript

//
halfCutHeight、halfCutWidth是根据适配后的实际Canvas大小计算出来的相对距离
_setSize: function(){ // … if(self.isPortrait) { // …
self.halfCutWidth = (self.canvasWidth * self.radioY – this.winWidth ) /
2 / self.radioY; self.halfCutHeight = (self.canvasHeight * self.radioX

  • this.winHeight) / 2 / self.radioX; }else { // … self.halfCutWidth =
    (self.canvasWidth * self.radioX – this.winWidth ) / 2 / self.radioX;
    self.halfCutHeight = (self.canvasHeight * self.radioY – this.winHeight)
    / 2 / self.radioY; } // … }, // 贴边元素重定位核心处理函数
    _adjustPosition: function(item){ var self = this; item &&
    self.adjustPositionArr.push(item);
    self.adjustPositionArr.map(function(item, index, arr){ (typeof item.top
    == “number”) && (item.y = item.top + self.halfCutHeight >= 0 ?
    self.halfCutHeight : 0); (typeof item.left == “number”) && (item.x =
    item.left + self.halfCutWidth >= 0 ? self.halfCutWidth : 0); (typeof
    item.bottom == “number”) && (item.y = self.canvasHeight –
    item.getBounds().height – item.bottom + self.halfCutHeight >= 0 ?
    self.halfCutHeight : 0); (typeof item.right == “number”) && (item.x =
    self.canvasWidth – item.getBounds().width – item.right –
    self.halfCutWidth); }); }, //
    暴露方法:提供给开发者记录需要重定位的贴边元素 adjustPosition:
    function(item){ var self = this; self._adjustPosition(item); }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// halfCutHeight、halfCutWidth是根据适配后的实际Canvas大小计算出来的相对距离
_setSize: function(){
  // …
  if(self.isPortrait) {
    // …
    self.halfCutWidth =  (self.canvasWidth * self.radioY – this.winWidth ) / 2 / self.radioY;
    self.halfCutHeight = (self.canvasHeight * self.radioX – this.winHeight) / 2 / self.radioX;
  }else {
    // …
    self.halfCutWidth = (self.canvasWidth * self.radioX – this.winWidth ) / 2 / self.radioX;
    self.halfCutHeight = (self.canvasHeight * self.radioY – this.winHeight) / 2 / self.radioY;
  }
  // …
},
// 贴边元素重定位核心处理函数
_adjustPosition: function(item){
  var self = this;
  item && self.adjustPositionArr.push(item);
  self.adjustPositionArr.map(function(item, index, arr){
    (typeof item.top == "number") && (item.y = item.top + self.halfCutHeight >= 0 ? self.halfCutHeight : 0);
    (typeof item.left == "number") && (item.x =  item.left + self.halfCutWidth >= 0 ? self.halfCutWidth : 0);
    (typeof item.bottom == "number") && (item.y = self.canvasHeight – item.getBounds().height – item.bottom + self.halfCutHeight >= 0 ? self.halfCutHeight : 0);
    (typeof item.right == "number") && (item.x = self.canvasWidth – item.getBounds().width – item.right  – self.halfCutWidth);
  });
},
// 暴露方法:提供给开发者记录需要重定位的贴边元素
adjustPosition: function(item){
  var self = this;
  self._adjustPosition(item);        
}

b. 重绘制

对于一些以舞台区域(gameArea)作为其大小设置的参考标准的元素,在适配时遇到需要补全绘制区域时,舞台区域大小发生变化,相应地,该元素就需要进行重新绘制,这就是重绘制策略的存在意义。

同样地,为了保证性能,重绘制策略也是同样需要保证:

  1. 创建对应的数组记录全显图形对象。
  2. 不在每一帧 tick 时进行重绘制,只在适配的时候重绘制。

以下是重绘制策略的相关代码:

JavaScript

// 全显图形重绘制核心处理函数 _adjustFullSize: function(item){ var self
= this; item && self.adjustFullSizeArr.push(item);
self.adjustFullSizeArr.map(function(item, index, arr){ item.drawRect(0,
0, self.canvasWidth, self.canvasHeight); }); }, //
暴露方法:提供给开发者记录需要重绘制的全显图形 adjustPosition:
function(item){ var self = this; self._adjustPosition(item); }

1
2
3
4
5
6
7
8
9
10
11
12
13
// 全显图形重绘制核心处理函数
_adjustFullSize: function(item){
  var self = this;
  item && self.adjustFullSizeArr.push(item);
  self.adjustFullSizeArr.map(function(item, index, arr){
    item.drawRect(0, 0, self.canvasWidth, self.canvasHeight);
  });
},
// 暴露方法:提供给开发者记录需要重绘制的全显图形
adjustPosition: function(item){
  var self = this;
  self._adjustPosition(item);        
}

至此,Canvas 横屏适配问题才得以完全解决。

这部分内容篇幅较长,笔者简单总结下,一个简单的解决 Canvas
横屏适配问题的方案至少需要包括两点实现:

  • 选用合适的缩放模式
    方案内置五种缩放模式,在实际应用中根据场景不同而采用不同的缩放进行适配。
  • 加入重定位和重绘制策略
    为了保证贴边元素不被裁剪以及舞台元素动态渲染大小以适应舞台区域的动态变化。

最终的整体效果可前往体验地址进行体验,体验时可点击文本元素进行切换模式。另外,整体的实现方案是基于
CreateJS
框架进行实现的,文中的实现方案的代码会托管笔者github上。

写在前面

屏幕适配是每个手机应用和游戏都会解决的问题,当然在开发的过程中会遇到各种各样的坑,这次,我们就来讨论一下unity项目中的屏幕适配吧!

强制横屏显示

页面内容显示方向可分为竖排方向和横排方向,如下图所示。

 

图片 28

页面内容显示方式:竖向排版和横向排版

对于竖屏式 H5
轻互动来说,页面会被期望保持竖排方向显示。而如果页面出现横排方向显示的情况,开发者往往会选择利用提示蒙层来进行友好提示,让用户自主保持竖屏体验,如下图所示。

 

图片 29

提示蒙层提醒用户保持竖屏体验

同样地,在横屏式 H5
轻互动游戏中可以采取相同的措施进行简单处理,在页面内容按竖排方向显示时,开发者进行对用户提示其保持横屏体验。

但是,这对用户体验并不友好,因为这对于那些习惯于打开锁定为竖排方向功能(如下图所示)的
iOS 平台用户,或者是关闭屏幕旋转功能(如下图所示)的 Android
平台用户来说,他们需要多一个处理步骤——先关闭竖排方向锁定或是开启屏幕旋转,然后再横向手持设备。

 

图片 30

竖排方向锁定功能(iOS)与屏幕旋转(Android)功能

因此,更好的做法是强制横屏显示,对屏幕 resize
事件进行监听,当判断为竖屏时将整个根容器进行逆时针 CSS3 旋转 90
度即可,代码如下所示。

JavaScript

// 利用 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 = detectOrient;
detectOrient();

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// 利用 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 = detectOrient;
detectOrient();

但是!这里有:如果你是采用
CreateJS 框架进行开发,那么就不能通过 CSS3 途径对包含 Canvas
的根容器进行旋转处理,因为旋转后会导致 Canvas
内的舞台元素的事件响应位置错乱。
解决办法是,换成利用 CreateJS 框架内的 Stage 的 rotation
属性对整个舞台旋转处理,代码如下:

JavaScript

if(self.isPortrait) { // 竖屏 // 舞台旋转 self.stage.x =
self.canvasHeight; // 注意:x偏移相当于旋转中点处理,更简单
self.stage.rotation = 90; // more… }else { // 横屏 self.stage.x = 0;
self.stage.rotation = 0; // more… }

1
2
3
4
5
6
7
8
9
10
if(self.isPortrait) { // 竖屏
  // 舞台旋转
  self.stage.x = self.canvasHeight; // 注意:x偏移相当于旋转中点处理,更简单
  self.stage.rotation = 90;
  // more…
}else { // 横屏
  self.stage.x = 0;
  self.stage.rotation = 0;
  // more…
}

NGUI适配方案

  1. UIRoot
    NGUI中每一个UI都是以UIRoot作为根节点,该组件完成了NGUI大体上的适配功能。
    UIRoot的几种缩放方式:
![](https://upload-images.jianshu.io/upload_images/1479565-14c69edb102bc7ad)

这里写图片描述

横屏适配处理

面对移动端多分辨率繁复冗杂的情况,我们对于一般情况下(也就是常见的竖屏式)页面适配处理可以说是烂熟于心,但是切换到横屏式场景下,同样的页面适配方法可以直接应用吗?会不会有什么问题呢?

下面笔者分别从 DOM 和 Canvas 两方面去着手阐述如何做横屏适配处理。

前段时间整理的一篇关于unity
ui开发的文章
,被推荐上了csdn首页,对于刚刚写文字的我来说,是莫大的鼓励,让我干劲十足,写出更多有质量的文字。

后话

本文主要的核心在于探讨横屏游戏中的处理点与解决方案,因此如果实现代码方面有任何错漏之处,请大胆地提出纠正吧!又或者读者们有更好的见解之处,也欢迎留言分享噢。

写在最后

以上就是屏幕适配的所有内容,主要介绍了屏幕适配的分类:分辨率适配和宽高比适配,按内容又分为游戏UI适配和游戏内容适配,并给出一些适配方法。然后重点讲了NGUI的适配方法,简单介绍了UGUI,总的来说UGUI和NGUI适配的方案有很多相似的地方,适配的大致方向就是按像素、按比例缩放对全局适配,用锚点来做精细的控制。对UGUI现在不是很熟,所以写的很简单,以后找时间在详细研究一下,再整理出来。

UGUI适配方案

终于把NGUI适配说完了,对于UGUI目前没有深入了解,在场景视图中可以拖拽锚点,设置锚点区域,感觉挺简单的,粗略做个笔记。

  1. Canvas
    Scaler:画布比例缩放,从整体上对UI进行适配控制,和UIRoot有异曲同工之妙,很多参数名字不一样,但意思一样。

ConstantPixelSize:按像素适配

图片 31

这里写图片描述

Constant Pixel
Size:保持UI元素大小不变,无论屏幕尺寸如何变化,所占像素不变。
Scale Factor:保持大小的比例 。原图100×100 原始大小1=100×100 原来的2倍大
2=200×200
Reference Pixels Per Unity: 100 Unity里的1单位大小代表100像素

ScaleWithScreenSize:按比例适配

图片 32

这里写图片描述

Scale With Screen Size:UI元素大小跟随屏幕分辨率的大小变化而变化。
Reference Resolution:参考分辨率。
Screen Match Mode:
Match Width Or Height:根据参考分辨率的高或宽,来缩放UI元素。
Expland:分辨率设置不会小于Canvas设置的分辨率。
Shrink:分辨率不会大于Canvas设置的分辨率。

Constant Physical Size:按屏幕物理大小适配

图片 33

这里写图片描述

根据屏幕的PPI信息和ConstantPhysicalSize本身的配置信息,得出一个“合适”的scaleFactor,以达到UI在不同PPI设备上的最终大小都是一致的。

  1. 锚点
    UGUI中锚点有多种“形态”,当锚点是一个点时,表示该UI大小不变,位置会随参考点改变。当锚点是一个矩形区域时,UI的大小就会随该参考区域改变,当然非常灵活,锚点矩形的大小可以随意设置,甚至可以在某个方向长度为0。

哪些内容需要适配

  1. User Interface
    游戏UI需要适配,这是无所质疑的,包括一般的手机应用程序,都需要这个步骤。如果再细分一下,还分为位置适配和大小适配

位置适配:分辨率会影响UI在屏幕中显示的位置,比如在800 *
600分辨率的屏幕上,button1在正中央位置,坐标为(400,
300),但是如果放在1366 *
768分辨率屏幕上位置就会靠左边一些,这样会严重影响UI布局的美观。

大小适配:同样的例子,在800 *
600分辨率的屏幕上,button1的大小为50*20像素,但是到了分辨率高的屏幕上,button1就变得很小了,影响美观,影响用户正常使用。

图片 34

这里写图片描述

  1. 游戏内容
    一般的应用开发,用户看到的只有UI,但在游戏中,除了UI,还有游戏内容。而游戏内容是什么呢?

举个例子:
比如在2D游戏中,除了那些可以交互的按钮滚动,在二维场景中的背景、物件、NPC等,都属于游戏内容。在进行宽高比适配的时候,难免会按照宽度或高度做一些裁剪,如果不进行处理,有些游戏内容就会看不到。
在3D游戏中,场景的大小是固定的,当相机照射的宽高比因为适配屏幕宽高比变化时,就可能“穿帮”,很有可能看到黑边。

在unity中不管2D游戏还是3D游戏,分辨率大小不会影响游戏内容显示,屏幕宽高比会影响游戏内容显示。

注意:在unity编辑器中,game视图是默认的视口,并且编辑器下改变游戏宽高比,unity会自动把相机宽高比调整到适配的宽高比。

目录

  1. 屏幕适配的分类
  2. 哪些内容需要适配
  3. unity中常见的适配方式
  4. 游戏内容适配
  5. NGUI的适配方案
  6. UGUI的适配方案

当宽大于高时,也就是横屏状态时:就需要自己来根据宽度来调整缩放。

  • 动态的改变适配的高度

public class NewBehaviourScript : MonoBehaviour {

    public int ManualWidth = 1280;
    public int ManualHeight = 720;

 void Awake () {
       UIRoot uiRoot = gameObject.GetComponent<UIRoot>();

        if (uiRoot != null)
       {
           if (System.Convert.ToSingle(Screen.height) / Screen.width > System.Convert.ToSingle(ManualHeight) / ManualWidth)
               uiRoot.minimumHeight = Mathf.RoundToInt(System.Convert.ToSingle(ManualWidth) / Screen.width * Screen.height);
           else
               uiRoot.minimumHeight = ManualHeight;
       }
 }
}
  • 利用相机的camera.orthographicSize
    需要知道orthographicSize表示的是相机高度的一半,前面已经讲清楚了。我在16
    :
    9屏幕下开发,并且设置camera.orthographicSize为1,把Minimum和Maximum设置为相同
![](https://upload-images.jianshu.io/upload_images/1479565-7f9caaee245edd8e)

这里写图片描述

,然后把下面脚本挂在UI相机上:

public class NewBehaviourScript : MonoBehaviour {

 void Awake ()
    {
        camera.orthographicSize *= 16.0f / 9 / ((float)Screen.width / Screen.height);
  }
}

16:9屏幕上正常:

图片 35

这里写图片描述

不加上述脚本,在5:4屏幕上,两边被裁剪了:

图片 36

这里写图片描述

加上上述脚本,在5:4屏幕上就正常了,按照宽度适配:

图片 37

这里写图片描述

屏幕适配的分类

说到屏幕适配的分类啊,也许会有所疑问,屏幕适配还能分类?细致分析一下,可以分为两大类:分辨率适配和宽高比适配。

  1. 分辨率适配
    首先得知道分辨率是什么?分辨率是屏幕显示图像的紧密度,是指显示器能显示的像素有多少。屏幕上的点、线、面都是由像素组成的,分辨率越高,同样大小的屏幕能显示的像素越多,画面就越精细。现在PC上分辨率大多是
    1920 * 1080,我们看的视频很多高清版本就是 1080p 的。
    既然分辨率是屏幕的一项指标,那么手机上当然也会用到,现在智能手机市场有那么多产品,有多个厂家生产,并且有多个价位,所以手机屏幕分辨率肯定各不相同(虽然屏幕分辨率一般比较固定的几个)。那么分辨率适配是每个应用、游戏都应该做的。

  2. 宽高比适配
    这个很好理解,每个手机大小各不相同,宽高比也会有多种啦,适配宽高比当然也是必须要做的喽。

当下移动设备主流分辨率及宽高比:
iOS设备的分辨率主要有:

图片 38

这里写图片描述

Android设备的分辨率则相对纷杂,主流的分辨率有:

图片 39

这里写图片描述

Constrained:

该模式下,屏幕按照尺寸比例来适配,不管实际屏幕有多大,NGUI都会通过合适的缩放来适配屏幕。这样在高分辨率上显示的UI就会被放大,有可能会模糊。

图片 40

这里写图片描述

Content Width:按照该宽度值适配屏幕
Content Height:按照该高度值适配屏幕

Fit选项表示已哪个值做适配。这两个值可以认为是事先设定好的屏幕初始大小和比例。源码中Fit选项的枚举值:

public enum Constraint
{
 Fit,
 Fill,
 FitWidth,
 FitHeight,
}
  • 如果Fit都没勾选(Constraint.Fill)
    当适配宽高比小于实际宽高比时,就会按照宽度适配,反之按照高度适配。该情况下可以保证显示结果永远没有黑边,但上下或者左右两边可能会被裁剪。

  • 如果勾选了Width(Constraint.FitWidth)
    那么就会在屏幕比例发生变化时,按照宽度来适配。例如开发时用16:9屏幕,运行在5:4屏幕上,宽度适配,计算公式为
    activeHeight = manualWidth / (screen.x / screen.y),16 / ( 5 / 4 )
    = 12.8 >
    9,这样显示宽度就全部显示进来了,但是高度上就会出现黑边,所以这种情况下要想办法解决黑边问题。

  • 如果勾选了Height(Constraint.FitHeight)
    那么就会在屏幕比例发生变化时,按照宽度来适配。activeWidth =
    manualHeight * (screen.x / screen.y),9 * ( 5 / 4 ) = 11.25 <
    16,这样高度全部显示进来,但在宽度上两边被裁剪掉了,显然这样更不合适了。

  • 如果两个都勾选了(Constraint.Fit)
    当适配宽高比大于实际宽高比时,就会按照宽度适配,反之按照高度适配。该情况下可以保证显示开发时能见到的所有内容,但是可能上下或左右会出现黑边。

下面是UIRoot.cs源码:

图片 41

这里写图片描述

可以清楚的看到NGUI是怎么利用这些值进行计算高度的。

unity中常见的适配方式

  1. Camera组件
    Projection:投影类型
    Prespective为透视投影

图片 42

这里写图片描述

Field of View:相机的张角,它决定相机照射的范围。
Clipping Planes:近裁剪面和远裁剪面
Viewport Rect:视口大小,取值为0 ~ 1之间