有效解決3D遊戲邊緣鋸齒現象及全面理解LayaAir引擎遊戲螢幕適配！

• 2020 年 3 月 26 日
• 筆記

有的時候看到一些3D遊戲鋸齒感特別明顯，與一些開發者溝通後發現，其實很多人並不清楚怎麼能去掉明顯的鋸齒感，而這並不是只有新開發者才遇到的問題，很多遊戲研發經驗豐富的開發者，甚至是使用LayaAir引擎開發了很多遊戲的開發者也會不清楚。另外，最近也遇到有開發者想了解劉海屏如何適配，所以通過本篇文章全面介紹一下。

為了兼顧新手開發者來理解這個事，本篇從基礎概念入手，詳細介紹LayaAir引擎的各個螢幕適配縮放模式，劉海屏適配思路，以及如何有效的抗鋸齒。

一、基礎概念

以下基礎概念非常重要，會影響到後面引擎適配原理的理解，請大家認真閱讀。

1.1 物理解析度

物理解析度簡單理解就是硬體所支援的解析度，以像素（px）為單位，所以我們稱這個硬體上的每一個像素點為物理像素，也叫設備像素。將螢幕實際存在的像素以行數 × 列數這樣的數學表達方式體現出來，就是物理解析度。比如 iPhone8 的物理解析度是1334 × 750 。而我們進行螢幕適配時，表達方式會有所不同，會以螢幕寬的像素數量 × 螢幕高的像素數量這樣來體現。例如 iPhone8在默認的豎屏狀態下，物理解析度表達為750 × 1334。橫屏狀態下，物理解析度表達為1334 × 750 。所以大家需要能理解這些區別。

1.2 縮放因子與邏輯解析度

1.2.1 縮放因子 起源

iOS繪製圖形是以 point （pt）為單位，在早期的時候1 point=1 pixel。在2010年推出的iPhone4開始採用 Retina(視網膜) 螢幕顯示技術 ，物理解析度提升了4倍，此時，如果iPhone4還是1pt=1px這個方案，將會導致如下圖一樣的顯示效果。

（圖1）

在圖1中，按 iPhone3GS的320 × 480進行全螢幕設計，那在iPhone4下的顯示效果則如圖1左側，原來的滿屏內容只佔了四分之一，其餘部分留空。而按iPhone4解析度 640 × 960進行全螢幕設計，那在iPhone3GS的螢幕下顯示效果則如圖1右側，大量內容超出可顯示區。

很顯然，apple不會讓圖1的事情發生。實際上，iPhone4的縮放因子為@2X，也就是在這個機型上1個point 用2×2的像素矩陣來表示，如圖2中效果所示，完美解決圖1中可能發生的問題。

（圖2）

隨著時代的發展，後續的機型物理解析度也越來越高，1個point佔用的物理像素也越來越多，見下圖。

（圖3）

縮放因子的概念在Android機型中也適用

1.2.2 邏輯解析度

邏輯解析度簡單理解就是軟體所使用的解析度，我們設計適配全靠他，也是用乘法數學表達方式來體現。為了更好的理解這個概念，我們先看一組數據表格。

（圖4）

通過圖4的數據，我們可以看出，隨著手機設備的更新，物理解析度已經越來越高，如果我們按物理解析度來進行螢幕適配，先不算Android，光iPhone的機型就很碎片化了，還好，在縮放因子的作用下，我們看到邏輯解析度基本上變化不大，所以我們後面講的引擎適配，主要是針對邏輯解析度進行適配。

1.3 設備像素比

我們基於瀏覽器開發時，之前介紹的縮放因子概念對應的是DPR (Device Pixel Ratio)，中文叫設備像素比 。LayaAir引擎中通過 Laya.Browser.pixelRatio 可以獲得瀏覽器的DPR值。

這裡稍展開講幾句，在瀏覽器里，默認是由用戶來控制縮放的，例如，我們在手機瀏覽器雙指擴張，發現網頁會放大，但清晰度並不減小。這就是用戶自主縮放導致，並非是由DPR值來決定縮放。如果我們想和APP開發那樣，通過邏輯解析度來適配，讓瀏覽器依據設備的DPR來決定一個CSS像素佔用幾個物理像素。那需要在入口HTML頁面的的meta標籤中用 viewport進行了相關的配置。程式碼如下：

 <meta name='viewport' content='width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no'/>   

以上程式碼LayaAir引擎中默認添加，並強制添加不得刪除。

通過上面這段viewpot的配置，那頁面在禁止用戶手動縮放的同時，也會按設備的DPR進行自動縮放。

1.4 邏輯寬高

邏輯寬高是指邏輯解析度的寬高。瀏覽器里，可以縮放的邏輯解析度像素是CSS像素，在設置了viewport的情況下，瀏覽器會根據DPR的值決定一個CSS佔用多少個像素，例如DPR為3時，1個CSS像素就佔用3×3個物理像素。

LayaAir引擎里可以通過Laya.Browser.clientWidth獲取邏輯解析度的寬，通過Laya.Browser.clientHeight獲取邏輯解析度的高。

在手機等移動設備的豎屏狀態下，窄面為寬，長面為高。如果發生了螢幕翻轉的橫屏狀態，則長的一面為寬，窄面為高。

在PC瀏覽器中，則是獲取的瀏覽器窗口可視寬高。

1.5 物理寬高

物理寬高對應的是之前介紹的物理解析度概念，也可以稱為設備寬高，在LayaAir引擎的一些API注釋里會寫作螢幕寬高，其實都是一回事。開發者可以通過引擎封裝的介面獲得寬高值，通過Laya.Browser.width可以得到設備寬上有多少物理像素，通過Laya.Browser.height可以得到設備高上有多少物理像素。

不過，需要特別說明的是，LayaAir引擎中的物理寬高是通過邏輯寬高*DPR計算而來。而奇葩的iPhone6/7/8各Plus機型，邏輯解析度是736×414，DPR的值是3，相乘得到的結果顯然與真實的各Plus機型物理解析度1920×1080不符合。

講到這裡，開發者了解到有這回事即可，不用擔心適配錯誤，由於LayaAir引擎在入口網頁的meta標籤中用 viewport進行了相關的配置，所以會按DPR自動進行縮放，最終會自動縮放到對應到實際的物理解析度。

至於Plus機型為什麼要這樣奇葩的設置，這裡就不展開講了，有興趣的同學可以自行百度搜索答案。 或前往影片課了解：https://ke.qq.com/course/168375

1.6 設計寬高

設計寬高是開發者在設計產品時採用的寬高，面對眾多機型，選擇哪個作為設計寬高，也是一些新手開發者有點迷茫的，這裡簡單多說幾句。

（圖5）

設計寬高，首先要考慮的是優先兼容多數的常用螢幕比例。通過上面圖5的表格，我們看到去掉過時的機型，基本上手機螢幕就分兩類，一類是寬高比約為1:1.78的非全螢幕手機，另一類是寬高比約為1:2.17全螢幕手機。各品牌的Android機型螢幕比例，大多也是這兩種或者接近這兩種。

基於性能優先的原則，通常開發者都會選擇解析度小一些的作為主效果來設計，然後向其它比例螢幕進行適配。比如：常見的寬750高1334或寬720高1280。

以上寬高描述是指豎屏模式設計，橫屏需反過來。

在LayaAir引擎里，初始化引擎的init(寬，高)值對應的就是設計寬高。如Laya.init(750, 1334);。

打開LayaAirIDE，通過F9快捷鍵調出的面板里，可以直接設置，效果如圖6所示。

（圖6）

1.7 畫布寬高

眾所周知，<canvas>是HTML5中的畫布，其 width、heigth 屬性就是畫布寬高。

畫布寬高在noscale、exactfit、noborder這幾個LayaAir引擎適配模式下會直接採用設計寬高值，其它適配模式下，會根據適配規則產生變化。畫布寬高的值對畫面最終的清晰度以及性能都會產生影響，甚至邊緣鋸齒或畫面模糊也與此處畫布寬高值有關。

我們在IDE里任意發布運行一個頁面， 在打開的chrome里用F12進入調試模式後，入口頁面中找到id為 layaCanvas的canvas標籤。記住這個位置，圖7中紅圈標記的，就是畫布的初始寬高，後面理解螢幕適配模式的時候，大家可以多關注這裡。

（圖7）

1.8 適配寬高

由於Canvas是基於點陣圖像素繪圖的，畫布寬高對畫面品質及性能有影響，又或者諸如plus特殊的解析度等問題。所以不能通過直接改變畫布寬高來適配，否則會出來一些適配問題。在LayaAir引擎中會根據不同的適配模式規則，計算出適配寬高需要縮放的比例，然後通過transform的matrix（矩陣）來對畫布縮放至邏輯解析度範圍內，再通過viewport與DPR機制縮放還原。

基於以上種種，我們需要了解適配寬高這個概念，適配寬高才是適配規則處理後的畫布最終效果寬高，會直接影響通過DPR還原後的最終效果。

大家在理解各個適配模式的時候，可以在HTML入口頁面中觀察畫布寬高與transform的matrix（矩陣）縮放效果來對比不同模式之間的差異。例如圖8中紅圈標記所示，適配寬高分別為249.99975和444.666222。還原至物理解析度大小後，雖然有精度上的細微損失，但已經很難看出。

（圖8）

1.9 舞台寬高

舞台寬高是指LayaAir引擎的stage寬高，stage寬高的變化並不會影響到畫面的大小，但stage範圍內，可以控制顯示，可以進行事件監聽，碰撞檢測等，所以對stage寬高的適配還是非常重要的。

在不同的螢幕解析度比例下，總會無法通過引擎的適配模式一次到位的情況，難以做到既想等比縮放，又想在各種螢幕下都做到遊戲內容滿屏顯示。但實際上，只要舞台（stage）寬高可以佔滿全螢幕，那就一定可以通過相對布局，做到各螢幕全螢幕顯示。因為，遊戲的顯示與控制就是基於舞台的，舞台全螢幕就有了在適配模式的基礎上調整顯示的空間，畢竟不可能超出舞台來顯示遊戲內容。

默認情況下，stage寬高直接等於設計寬高。在full、fixedwidth、fixedheight、fixedauto的適配模式下，stage寬高會根據適配規則產生變化。

二、抗鋸齒相關介紹

2.1 鋸齒產生的原因

我們螢幕的像素點，是由行與列的矩陣序列組成。也就是說螢幕中是不存在斜線的。基於像素繪圖的畫布，要是畫橫豎的直線，那絕對是相當的平滑。可是畫曲線和斜線怎麼辦。只能是由兩個相鄰的像素點不斷重複延伸組成，如果這句話不好理解，我們想像一下樓梯，從側面去看，大概就是這個樣子。示意效果如圖9所示。

（圖9）

另外，3D模型的基礎構成是三角面組成的多邊形網格，繪製3D多邊形構成的模型，這和我們矢量畫斜線、畫曲線、畫圓，是一樣的道理。所以非矩形的矢量圖形和3D模型，產生鋸齒這是正常的。

2.2 引擎內置的抗鋸齒

LayaAir引擎內置了抗鋸齒方法，並且在3D庫中默認開啟了，2D想開啟的話可以在init()之前加入Config.isAntialias =true;。

開啟抗鋸齒後，邊緣鋸齒會變得平滑模糊，示意效果如圖9-1所示。

（圖10-1）

模糊後的鋸齒相對會平滑一些，在像素密度比較高的螢幕上，肉眼很難看出。從而達到消滅鋸齒感的目標。

2.3 抗鋸齒失效的原因

由於3D抗鋸齒默認是開啟的，但有的開發者發現鋸齒感還是很明顯，那就需要檢查是否使用了HDR和後期處理。webGL 1.0不支援renderTarget有抗鋸齒，使用相機HDR和後期處理管線的BloomEffect泛光效果就會引起抗鋸齒無效。

解決辦法就是不要使用這兩塊功能，後期處理一般來說，開發者用的不多。HDR是要特別注意的，在Unity里導出資源時，不要勾選HDR相關選項。如果不小心勾了，不想重新導出的。也可以在項目程式碼里強制HDR效果。示例程式碼如下：

this.camera = new Laya.Camera(0, 0.1, 100);    this.camera.enableHDR = false; //關閉HDR   

關閉HDR後，抗鋸齒生效對比效果如圖9-2所示。

(圖10-2)

2.4 抗鋸齒有效，為什麼還有鋸齒感

如果沒有使用與抗鋸齒生效衝突的功能，經檢查，抗鋸齒功能也是開啟的，為什麼還會感覺到鋸齒感呢？

那一定就是像素顆粒的原因了。

要知道。我們的抗鋸齒只是通過一些演算法，讓邊緣過渡的更平滑。從而減輕鋸齒現象。在一些像素密度比較大的螢幕上，讓肉眼難以識別，並非真的讓鋸齒消失。

而開發者在設計的遊戲的時候，遊戲設計寬高不可能面向所有的機型，無論是選擇哪一個機型的解析度，在面向其它機型解析度，要麼小了，要麼大了。無論大還是小，要想全螢幕適配不被裁切，那就需要拉伸縮放，都會導致鋸齒感的加劇，使得抗鋸齒功能也無法完全抵消。

所以，要解決這個問題，那我們就要讓遊戲畫布一直處於物理解析度的大小。

2.5 讓畫布處於最佳高清狀態

讓遊戲畫布處於物理解析度模式有兩種方案。

第一，使用LayaAir引擎的full適配模式，該模式會無視設計寬高的配置，直接採用物理解析度作為畫布寬高。

第二，使用視網膜畫布模式，視網膜畫布模式開啟後，無論採用什麼適配模式，都會強制將畫布設置為當前機型的物理解析度大小。

2.5.1 開啟視網膜畫布模式

開啟視網膜畫布模式的方式有兩種，一種是在初始化舞台之前，也就是init()之前添加一行配置程式碼。程式碼如下：

//使用視網膜畫布模式，在init之前使用    Config.useRetinalCanvas = true;   

如果想動態控制視網膜畫布模式的開和關，也可以用另一種設置模式，在init()之後添加配置程式碼。程式碼如下：

//使用視網膜畫布模式，在init之後使用    Laya.stage.useRetinalCanvas = true;   

這裡需要提醒一下的是，如果不是在init()的同一幀內使用useRetinalCanvas模式配置的，那我們設置之後，需要同步設置Stage的scaleMode、width、height、alignH、alignV中的任意一個，激活引擎設置螢幕大小方法setScreenSizeStage，這樣修改才會生效。只是設置Laya.stage.useRetinalCanvas並不會生效。

例如：

if(條件){     Laya.stage.useRetinalCanvas = false;    }else{     Laya.stage.useRetinalCanvas = true;    }    Laya.stage.alignH = "left";   

2.5.1 開啟視網膜畫布模式的利弊

理論上講，開啟視網膜畫布模式，在超出設計寬高的機型上，會產生更多的性能消耗。因為畫布上的像素越多，性能消耗越大。所以很多2D遊戲，都會採用相對小一些的解析度作為遊戲設計寬高。

但從實際應用來講，物理寬高所帶來的性能壓力也並沒有那麼多風險。要知道，一些小遊戲平台是強制要求必須物理解析度的。因此，LayaAirIDE在導出QQ，vivo、OPPO、支付寶小遊戲平台版本的時候，會強行開啟視網膜畫布模式（useRetinalCanvas）。在微信小遊戲中，有的適配模式，如果不採用視網膜畫布模式，那遊戲畫面布局效果將會與瀏覽器中表現不一樣。

另外，開啟視網膜畫布模式，除了能解決一些小遊戲平台中的問題，以及可以減輕鋸齒現象外，其實還可以讓適配變的更簡單。因為不使用視網膜畫布模式，還想避免鋸齒現象，移動端只能使用full模式，而full模式除了讓畫布和舞台採用了物理解析度之外，並沒有作任何適配，所以對於2D UI，全部需要開發者手工適配。

所以，建議開啟視網膜畫布模式，尤其是3D遊戲。如果考慮某些機型的性能壓力，開發者可以在存在壓力的機型，或者有性能壓力的功能上，通過邏輯控制，動態開啟或關閉視網膜畫布模式。

三、LayaAir螢幕適配模式詳解

LayaAir引擎的適配模式有8種，為了讓大家真正理解各適配模式的適配策略，以便更好的進行螢幕適配。本節以LayaAirIDE創建的2D示例項目為例，將設計寬高調整為750×1334的豎屏介面，分別就各個適配模式對比不同機型進行講解。

在適配對比的機型選擇方面，iPhone4的640 × 960代表老舊機型，寬高比為1.5，只是為了對比適配效果。iPhone8的750 × 1334是我們為設計寬高選定的機型，寬高比約為1.78，無論哪個模式都是完美的1：1適配。iPhone8 Plus代表著同樣約為1.78寬高比，但物理解析度和DPR都與iPhone8不同的同比例機型。iPhoneX代表著寬高比大於2的各種全螢幕機型。

3.1 最容易理解的適配模式

3.1.1 默認的不縮放模式noscale

noscale模式是引擎默認的模式。該模式下，在任何螢幕都會始終保持設計時的物理解析度原樣效果，相當於將不縮放的設計寬高畫布直接貼在螢幕上。物理寬高和設計寬高相等的螢幕會全螢幕顯示，物理寬高低於設計寬高的會顯示不全，物理寬高超過設計寬高的會留出螢幕背景（白屏）。

該模式通常不被使用，僅有少數不使用引擎適配方案，有著自定義適配規則的開發者來使用。

noscale模式，不同機型對比效果如圖11-1中所示。

（圖11-1）

3.1.2 物理解析度畫布模式full

full模式表示著畫布寬高和舞台寬高一定是完整的全螢幕狀態，但和noscale模式一樣，並沒有對設計寬高做縮放處理。在full模式下，畫布大小直接取值物理解析度，物理寬高是多少，畫布就有多大，該模式下設計寬高參數的設置無意義，直接設置0,0即可。

該模式仍需要自己定義適配規則，多用於3D遊戲。如果有UI介面，不想自己定義適配規則的，後面還會介紹更優的3D適配方案。

full模式，不同機型對比效果如圖11-2中所示。

（圖11-2）

特別說明一下，背景螢幕顏色為黑色的是畫布默認背景色，不是stage背景色。通過Laya.stage.bgColor可以改變默認的畫布背景色。在noscale模式下的白屏背景那是瀏覽器默認的，說明畫布就那麼大，畫布沒覆蓋到的地方就是白屏背景。

假如在noscale模式下，開啟了視網膜畫布模式，那顯示效果將會與圖11-2的full模式效果相同，但區別是，full模式舞台（stage）寬高也是物理寬高，所以在遊戲畫面覆蓋到的地方仍然可以有點擊等事件響應。而noscale開啟視網膜畫布模式，只是強行將畫布改為物理寬高，並沒有改變舞台寬高，所以遊戲畫面（設計寬高）外的部分並不會對點擊等事件產生響應。

3.1.3 強行拉伸全螢幕模式exactfit

exactfit是一種不等比的全螢幕拉伸適配模式，畫布寬高與舞台寬高會等於遊戲設計寬高 。然後完全不考慮比例強行縮放至邏輯寬高全螢幕。所以除非是設計寬高與物理寬高相等，否則就會有一些因拉伸產生的變形。螢幕解析度寬高比與設計寬高比差距越大的，變形的越明顯。

拉伸至物理寬高全螢幕，所以除非是設計寬高與物理寬高相等，否則就會有一些因拉伸產業的變形。不同機型的寬高比例差距越大，變形的越明顯。

該模式是所有適配模式中，唯一不需要開發者作額外的適配調整，就能保障在任何機型下都可以全螢幕顯示、不留空白、不被裁切的適配模式，缺點也很明顯，就是當物理寬高比例與設計寬高比例不同時，會產生拉伸變形，適用於對介面產生形變沒有嚴格要求的開發者。

exactfit模式，不同機型對比效果如圖11-3中所示。

（圖11-3）

3.2 移動端推薦的適配模式

在移動端，我們通常會需要保持設計寬高等比縮放的全螢幕適配方案。而以下幾種模式正是我們推薦開發者優先採用的適配模式。如果是3D遊戲，建議開啟視網膜畫布（useRetinalCanvas）模式。

3.2.1 保寬適配模式fixedwidth

fixedwidth保寬模式就是在保障設計寬的內容一定全螢幕顯示的等比縮放模式。這種模式推薦應用於豎屏遊戲。

在這個模式下，畫布寬和舞台寬會等於設計寬。但畫布高和舞台高會按物理寬與設計寬的比例進行縮放後改變，不採用我們配置的設計高。所以，當改變後的畫布和舞台高大於原來的設計高，底部就會露出畫布背景色。如果改變後的畫布和舞台高小於原來的設計高，那就會被裁剪掉多出的部分。

fixedwidth模式，不同機型對比效果，如圖12-1所示。

（圖12-1）

看到圖12-1的黑色背景色，或者有開發者看到這裡會想，我需要的是全螢幕適配，這個不適合。其實不用擔心，這是為了讓大家理解fixedwidth的適配規則，故意沒有處理。由於在這個模式下，舞台的寬高已經被縮放拉滿全螢幕，所以。開發者完全可以通過相對布局屬性（top和bottom），把背景拉到全螢幕以及按鈕拉到螢幕相對位置顯示。實現各個螢幕下都做到完美的全螢幕適配。

3.2.2 保高適配模式fixedheight

fixedheight保高模式就是在保障設計高的內容一定全螢幕顯示的等比縮放模式。這種模式推薦應用於橫屏遊戲。

在這個模式下，畫布高和舞台高會等於設計高。但畫布寬和舞台寬會按物理高與設計高的比例進行縮放後改變，不採用我們配置的設計寬。所以，當改變後的畫布和舞台寬小於原來的設計寬，那就會被裁剪掉多出的部分，如圖12-2所示。如果改變後的畫布和舞台寬大於原來的設計寬，底部就會露出畫布背景色，如圖12-3所示。

(圖12-2)

(圖12-3)

圖12-2和圖12-3仍然是故意沒有處理。通過相對布局屬性（left和right），把背景拉到全螢幕以及按鈕拉到螢幕相對位置顯示。實現各個螢幕下都做到完美的全螢幕適配。

3.2.3 自動保寬高模式fixedauto

fixedauto自動保寬高模式就是在保障設計寬高的內容，在任意機型的解析度下一定都在全螢幕內顯示。這是一種設計寬高永遠不會被裁剪的等比縮放全螢幕適配模式，但有可能會留出畫布的背景色，如圖12-4所示。所以還是需要通過相對布局屬性，進行全螢幕適配。該模式橫屏遊戲和豎屏遊戲都適合。

（圖12-4）

這種模式，其實最終採用的是fixedwidth或者fixedheight，是通過物理寬高比和設計寬高比進行對比判斷。物理寬高比小於設計寬高比的採用fixedwidth模式，否則就採用fixedheight。

3.3 其它適配模式

3.3.1 顯示全部的高清模式showall

showall模式的適配結果與fixedauto非常像，也是保障設計寬高一定會在螢幕內全部顯示，但區別和問題是，showall模式的畫布和舞台並未做到所有解析度下的全螢幕適配，而是取（物理寬/設計寬）與（物理高/設計高）的最小比值，進行等比縮放，並且改變了舞台和畫布大小。因此，留下的空白部分，就是舞台無法控制的部分，導致在與設計寬高比例不同的手機上，就真正的無法全螢幕適配了。

但也並非沒有好處，好處就是都不需要用相對布局二次適配了，設計效果什麼樣就一定是什麼樣，肯定是全部顯示，不變形，不被裁切。而且由於改變了畫布的大小，在物理解析度差異比較大的螢幕上，也不會因為設計解析度小了而導致模糊，仍然是高清的。壞處就是做不到手機全螢幕適配，所以該模式，通常不會被用到手機適配上， 在PC瀏覽器運行的橫屏頁游，推薦使用該模式。

showall模式，不同機型對比效果，如圖13-1所示。

（圖13-1）

showall模式由於畫布寬高已經進行了縮放改變，本身就是高清的適配模式，所以這種模式無需使用視網膜畫布模式（useRetinalCanvas），用了之後，畫布採用了物理解析度，反而不好。

3.3.2 肯定不留底邊的模式noboder

noboder的適配規則與showall，恰恰相反，是取（物理寬/設計寬）與（物理高/設計高）的最大比值進行縮放。會導致當解析度寬高比與設計寬高比不同的螢幕上，設計效果一定會超出螢幕，被裁切掉一部分。所以也就無法留出畫布或者舞台的底邊了。

另外，該模式畫布與舞台寬高會保持與設計寬高相同，所以全螢幕適配全靠對畫布的縮放，沒有使用視網膜模式的情況下，物理解析度遠超設計解析度的時候，會因拉伸產生模糊。

noboder模式，不同機型對比效果，如圖13-2所示。

（圖13-2）

雖然說該模式，通過相對布局二次適配，也可以讓被裁剪的按鈕等回歸到螢幕內容之中，但二次適配的方式要更加複雜。所以不推薦使用該模式。

3.4 劉海屏適配思路

自從推出iPhoneX全螢幕手機以來，全螢幕手機越來越多，但實際上絕大多數機型做不到真正的全面，所以就有了凹凸屏，劉海屏，水滴屏等叫法，這就給我們適配帶來了麻煩。但找到規律之後，其實也並不是太複雜。下面分享一種常見的處理思路，大家根據這種適配思路來具體調節適配。

3.4.1 如何識別劉海屏

目前市面上的機型，雖然解析度碎片化嚴重，但是仔細總結一下，可以發現一個規律，那就是解析度的寬高比就那麼幾個。至少，全螢幕的機型，寬高比肯定是大於2。所以，我們可以獲取螢幕解析度的寬高，然後計算出寬高比。大於2的，就當成劉海屏進行適配處理。

至於分的更細的，大家可以繼續仔細研究。本節只是介紹一種思路。

3.4.2 相對布局

LayaAirIDE的UI組件中提供了基於父容器的相對布局屬性，如top、bottom、left、right。我們可以把需要特別處理的按鈕都統一放到一個容器組件中，例如box。然後，我們在場景Runtime類的onAwake生命周期中，控制這個容器的相對布局屬性，就可以實現在劉海螢幕下進行特殊的位置處理了。

示例程式碼如下：

onAwake():void{     //寬高比大於2為劉海屏     if((Browser.clientHeight/Browser.clientWidth)>2){           this.scaleGroup.top = 25; //迴避頂部劉海示例程式碼     this.scaleGroup.bottom = 50;//迴避底部線示例程式碼     }    }   

3.4.3 如何調試

由於Chrome的調試中沒有提供劉海遮擋的虛擬機，除了真機調試外，可以在微信小遊戲開發工具中進行模擬調試。

3.5 其它適配相關學習

除了適配模式外，還有一些其它適配相關的內容，但不屬於適配基礎必須了解的範圍，所以提供學習相關的指引，大家有興趣可以點擊鏈接進入。

3.5.1 畫布對齊模式

關於畫布在螢幕中的水平對齊與垂直對齊介紹，文檔地址為：

https://ldc2.layabox.com/doc/?nav=zh-ts-1-8-1

需要注意的是，引擎中很多適配模式，都是畫布全螢幕適配。這個時候，設置畫布的對齊沒有意義。只有畫布不能全螢幕的時候，例如showall和noscale模式才有這個需求。

3.5.2 自動橫豎屏

關於自動橫屏和自動豎屏，可以前往官網文檔中查看。文檔地址為：

https://ldc2.layabox.com/doc/?nav=zh-ts-1-8-2

需要注意的是，瀏覽器中運行的時候，引擎的自動橫屏和自動豎屏，只能對畫布進行旋轉，如果用戶的手機鎖屏了，雖然遊戲自動旋轉過來了，但是瀏覽器沒有旋轉過來，會導致輸入法依然按瀏覽器的方向彈出，此時，可能會導致輸入法與瀏覽器的顯示呈90度。如果在小遊戲平台中運行，由於有橫屏還是豎屏的配置，不會出現這個問題。

3.5.3 適配模式原理及全螢幕相對布局

關於引擎各個適配模式的原理和更詳細的適配介紹，以及fixedwidth、fixedheight、fixedauto這幾個模式如何通過相對布局進行全螢幕顯示的二次適配。會在Layabox的影片課中進行詳細講解，有興趣可以進入影片鏈接查看影片教學。

鏈接：https://ke.qq.com/course/168375