詳解LayaAir引擎遊戲屏幕適配，及有效抗鋸齒

• 2020 年 3 月 6 日
• 筆記

有的時候看到一些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 pixcel。在2010年推出的iPhone4開始採用 Retina(視網膜) 屏幕顯示技術 ，物理分辨率提升了4倍，此時，如果iPhone4還是1pt=1px這個方案，將會導致如下圖一樣的顯示效果。

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

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

隨着時代的發展，後續的機型物理分辨率也越來越高，1個point佔用的物理像素也越來越多，見下圖。

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

1.2.2 邏輯分辨率

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

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

1.3 DPR

我們基於瀏覽器開發時，之前介紹的縮放因子概念對應的是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機型為什麼要這樣奇葩的設置，這裡就不展開講了，有興趣的同學可以自行百度搜索答案。

1.6 設計寬高

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

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

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

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

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

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

1.7 畫布寬高

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

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

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

1.8 適配寬高

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

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

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

1.9 舞台寬高

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

在不同的屏幕分辨率比例下，總會有適配規則不能覆蓋到，難以做到既想等比縮放，又想在各種屏幕下都做到遊戲內容滿屏顯示。但其實上，只要舞台寬高可以佔滿全屏，那就一定可以做到各屏幕全屏顯示。因為，遊戲的顯示與控制就是基於舞台的，舞台全屏就有了在適配的基礎上調整顯示的空間，畢竟不可能超出舞台來顯示遊戲內容。

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

二、抗鋸齒相關介紹

由於講layaAir引擎的適配模式會涉及到useRetinalCanvas屬性設置，所以我們先了解一下抗鋸齒相關。

2.1 開啟視網膜畫布模式

在微信安卓7.0.3版本前，微信安卓小遊戲會將畫布強制設置為物理分辨率，後在7.0.3取消了強制更改畫布，但會將畫布拉伸至物理屏幕的全屏顯示，所以當時還導致很多適配模式沒有使用正確的開發者，紛紛出現畫面模糊的表現。這就是因為畫布達到物理分辨率大小才是真高清，拉伸會變模糊，比例不是相差太大的圖片還好些，尤其是文字更為明顯。

另外，由於微信小遊戲與瀏覽器的繪製差異問題，在某些適配模式下，可能會出現適配問題，比如頂部出現留底問題等。而在OPPO和vivo等小遊戲平台，如果畫布不採用物理分辨率模式一定會出現適配問題，所以對於小遊戲平台，我們建議開啟引擎的視網膜畫布模式。

一旦開啟後，引擎將無視設計寬高大小，強制把畫布寬高設置為物理分辨率的大小。這樣就保障了畫布的最佳顯示效果。

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

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

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

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

2.2 對性能的影響與取捨

一旦開啟視網膜畫布模式後，有的開發者會比較擔心性能問題，畢竟採用物理分辨率作為畫布寬高後，代表着畫布上的像素可能會比原有設計寬高要多，這的確會對性能產生影響。但絕對沒有想像中差距那麼大，尤其是越高分辨率的機型，通常硬件條件也會更好一些。根據我的推薦，一些開發者調整之後，事實上也沒有太大的影響。

更何況，可以通過判斷機型或分辨率，進行動態控制視網膜畫布模式的開關。也有的開發者，在一些壓力比較大的頁面上關閉視網膜畫布模式，其它頁面開啟視網膜畫布模式。

2.3 如何消滅鋸齒

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

另外，3D模型的基礎構成是三角面組成的多邊形網格，繪製3D多邊形構成的模型，這和我們矢量畫斜線、畫曲線、畫圓，是一樣的道理。所以非矩形的矢量圖形和3D模型，產生鋸齒這是正常的。當然LayaAir引擎內置了抗鋸齒方法，並且在3D庫中默認開啟了，2D想開啟的話可以在init()之前加入Config.isAntialias =true;。

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

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

如果抗鋸齒在開啟狀態下，發現仍然是無效的。那就需要檢查是不是使用了相機的HDR或者後期處理。webGL 1.0不支持renderTarget有抗鋸齒，所以想避免鋸齒感的，要在Unity里導出資源時，不要勾選HDR相關選項。或者直接在引擎里，創建相機後關閉HDR。示例代碼如下：

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

開發者對於後期處理使用的不多，想避免鋸齒感的，那後期處理也不要使用了。通常導致抗鋸齒失效的原因就是HDR。

如果說抗鋸齒有效的情況下，還是有鋸齒感，那就是和畫布大小有關了，我們先看圖10中的效果。

在圖10左側，是畫布物理寬高一致的情況下，畫布像素與物理像素是重合的。圖10右側，當畫布寬高小於物理寬高時，被適配規則將畫布拉伸至全屏後，導致的畫布像素與物理像素產生偏差錯位。這就是加重邊緣鋸齒的根本原因，導致引擎抗鋸齒功能也很難完全消除過於明顯的鋸齒現象。

所以解決辦法就是使用物理分辨率的適配模式，或者在當前適配模式的基礎上，開啟視網膜畫布模式，將畫布強行按物理分辨率進行設置。

這樣一來，在有效的扛鋸齒開啟以及物理寬高的畫布雙重保障下，鋸齒感就很難在手機屏幕上察覺了。

三、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中所示。

3.1.2 物理分辨率畫布模式full

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

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

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

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

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

3.1.3 強行拉伸全屏模式exactfit

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

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

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

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

3.2 移動端推薦的適配模式

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

3.2.1 保寬適配模式fixedwidth

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

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

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

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

3.2.2 保高適配模式fixedheight

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

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

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

3.2.3 自動保寬高模式fixedauto

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

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

3.3 其它適配模式

3.3.1 顯示全部的高清模式showall

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

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

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

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

3.3.2 肯定不留底邊的模式noboder

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

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

noboder模式，不同機型對比效果，如圖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;//迴避底部線示例代碼      }  }

2.4.3 如何調試

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

2.5 其它適配相關學習

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

2.5.1 自動橫豎屏

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

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

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

2.5.2 畫布對齊模式

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

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

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