今天接著上一次沒分享完的內容繼續向后推進，也就是移動端的其它適配場景的講解。

上期回顧：

一、不同像素密度的適配方式

屏幕規格除了前面提到的大小規格外，還有個非常重要且基礎的概念 —— 像素密度。

常規情況下，分辨率指的是屏幕的像素組成數量，比如分辨率 1920*1080，指的是屏幕的長寬分別包含 1920 和 1080 個像素點。但一個 5 寸的屏幕可以使用這個分辨率，一個 24 寸的屏幕也可以使用這個分辨率，這就衍生除了像素密度這個屬性，即單位面積內包含像素點的數量。

在相同分辨率下，屏幕越小，像素密度越大畫面清晰度越高，屏幕越大，則像素密度越小畫面清晰度越低。

這個參數之所以重要，是因為不同手機屏幕之間的規格差異巨大，在屏幕都差不多的情況下，有的還在用 720P，有的已經用 4K 了，比如下面的示例。

從這些示例中，可以直觀的發現屏幕分辨率之間的差異巨大，也意味著不同屏幕規格之間的屏幕密度差異也很大。

這就延伸到另一個問題，我們在軟件里創建的畫布和真實屏幕分辨率參數怎么完全不一樣？原因就是畫布分辨率和顯示器分辨率是兩碼事，畫布分辨率可以理解成是邏輯分辨率，而屏幕分辨率是物理分辨率。

畫布分辨率即在 UI 設計軟件里的一個基礎畫布屬性值，它是矢量數值，即通過數學方式記錄和渲染的一種數據。所以它是沒有單位的，換個角度講也可以是任意單位，因為矢量可以無損放大和縮小。

但物理分辨率不一樣，物理分辨率是屏幕的物理屬性，在屏幕生產后就被固定，不管你讓屏幕顯示什么內容給你，它最終都以這個物理分辨率呈現出來。

邏輯分辨率和物理分辨率兩者并不對等，所以中間有個渲染的過程，即把矢量畫布渲染成屏幕圖像的過程（光柵化），在渲染過程中會對原有的分辨率進行換算，以滿足屏幕顯示的需要。

這個渲染過程主要由系統主導，我們無需深究背后的計算機圖形原理。只需要知道在渲染過程中，邏輯分辨率要轉化成屏幕分辨率，通常是按整數倍率放大的。比如以原來的 2 倍、3 倍、4 倍放大，簡寫也就是 2x、3x、4x。

這個放大的倍率通常是由像素密度決定的，而放大倍率的計算公式為 —— 屏幕密度 / 160，即屏幕密度大約是160的幾倍，則放大幾倍。比如 iPhoneSE 密度是326 所以是 2x，iPhone15 密度則是460，所以用 3x，以此類推。

計算公式知道個大概就行，實際項目不需要我們自己去做計算，移動端系統會自動根據設備的類型進行換算和渲染。

我們只需按著原有畫布尺寸設計即可，但是交付過程就會受到倍率的影響，因為設計稿中不是所有設計元素都是 —— 矢量的，還有相當一部分是位圖。比如目前越來越平面化、運營化的界面設計，有相當多的元素無法用 UI 軟件設計，它們只能以位圖的形式置入畫布中。

所以這類設計元素的置入和切圖就要考慮適配的問題，常規圖標切圖使用位圖格式就要使用 1x、2x、3x 不同倍率的 PNG，但是非圖標類素材的導出往往不需要這么麻煩，只需要導出一個 2x 的即可。

3x、4x 或更大的切圖，雖然能保證清晰度，在高分辨率下獲得更好的效果，但文件的占用空間也被成倍放大，這會導致兩種后果，一個是作為軟件內容安裝包體積大增，另一個是作為下載數據則下載時間會大增，而它們帶來的清晰度加成并不明顯，無法彌補造成的損失。

而導入到設計畫布內的位圖，不管放大還是縮小質量是一致的，導出它們可以縮小但是沒辦法導出成更大的圖片（畫質損失），要一開始就按切圖的要求導入位圖進設計畫布中。

所以假設你在畫布中要放置的一個 200*200 的插畫形象，那么再 PS 中創建創建畫布就不能小于 400*400（2x），才能保證最終的切圖可用性。

再拓展開，在我們使用 PS 進行復雜頁面設計，或者干脆是設計 H5 時，使用的分辨率也是 2x 的倍率，因為導出 2x 的切圖就夠用，也不用創建一個過大的畫布，導致設計過程操作非常的卡頓和不流程。

二、安卓和蘋果的適配做法

做移動端項目，多數情況下是要適配蘋果和安卓兩套系統的。但是，兩套系統各自設計各自開發，顯然是不能接受的，因為做起來太麻煩開發和維護成本過高。

所以行業普遍的做法，是先以一套系統為標準進行設計，再適配到另一套系統中去。當然，主流的設計是以 iOS 作為標準開展的，這里有多方面因素的影響，感興趣的同學可以自己去查查相關的歷史。

雖然 iOS 和 Android 官方設計規范和樣式有很大差異，但一定要記得那是 “官方設計規范”，而國內手機廠商有自己的 OS 和設計語言，和安卓官方的做法是高度脫節的。

同時，國內系統的設計高度靠攏 iOS 的設計，有很大一部分原因也是為了兼容跨系統適配，讓開發者可以更輕松、高效地適配安卓端。

所以，在常規項目設計中，我們以 iOS 界面為準即可，無需單獨提供整套的安卓端設計，安卓前端工程師會自己根據當前的設計開發和適配。而安卓設備畫布和蘋果畫布大小不一，同樣適用于前面所說的頁面元素適配邏輯。

雖然多數頁面可以直接遷移，但總是有特殊情況，畢竟安卓系統和 iOS 系統還是有不少差異，會直接影響產品需求或樣式。比如安卓的權限請求窗口、桌面組件設置、系統相關設置等，都是在 iOS 端設計沒有的界面。

所以 iOS 端適配安卓端的設計，就要創建一個新的文件，將安卓端不同或者特有的頁面單獨設計出來。在設計時，使用的畫布可以使用傳統的 360*720，也可以使用安卓官方應用的 412*892，然后置入安卓的頭部狀態欄和底部指示器示意。

三、手機端和平板的適配規范

除了跨系統外，移動端應用面對的另一個挑戰就是適配平板。

首先要了解一個基礎知識，即平板雖然本質上和手機是同一個系統，但開發者可以針對平板開發一個獨立的應用，這種應用會加上一個 HD 的后綴。比如網易云音樂，有手機端也有平板端，這是兩個不同的應用，所以開發 HD 版本的應用不叫平板適配。

平板適配指的是將一個手機應用直接適配到平板上的做法，可以在平板中完整展開、顯示、使用。與之相對的沒有適配的應用，在平板端則只會以手機端的界面展示，比例和平板不一致。

平板適配的基本做法，和手機適配基本一致，即對元素的對齊、縮放、響應方式進行制定，以應對畫布放大后的要求。所以有了相關知識，再看下面的案例，就應該輕易分辨出手機應用適配到平板中的邏輯。

如果只有這些內容，那么平板適配就不需要單獨做解釋，問題在于平板還包含其它的顯示特征，在設計過程都需要考慮是否需要支持它們，以 iPad 端舉例，包括：

1. 橫/豎屏切換
2. 分屏瀏覽
3. 懸浮窗口

手機多為豎屏使用，一個正常的 APP 不用考慮橫屏模式也沒關系，但是平板橫屏豎屏的使用比例都不容忽視，我們往往要考慮是否要在平板中支持橫屏模式。

雖然橫屏理論上就是讓畫布變得更寬高度變得更窄的讓界面進行適配，但是這種比例的變更往往會導致界面的可視區域變得非常小且不合理，比如下面案例。所以很多應用干脆在平板端禁止了橫屏模式，只允許豎屏使用（也可以反過來）。

第二個就是分屏瀏覽，iPad 包含多種分屏模式，橫屏模式支持 APP 以屏幕 2/3、1/2、1/3 的窗口顯示，豎屏模式則支持以 2/3、1/3 的窗口進行顯示。

這里就和上一個問題相關聯，如果不支持橫豎屏切換的話，那么往往就不會支持分屏模式，而要支持分辨率模式的話，元素的適配邏輯沒變，理論上支持平板的適配都可以比較輕松的支持這些分辨的顯示。

但一些特殊的頁面，如只有一兩個按鈕但是全屏顯示，或是復雜的表格、數據展示頁面，就要提前考慮不同方向和比例的適配結果，如果效果不佳且難以做出優化，那么同樣建議放棄針對專業比例的使用，不允許應用進入分屏模式。

最后的懸浮窗口即使用一個更細的窗口懸浮在系統界面內，界面適配的邏輯和分屏差異不大，只要支持 1/3 比例顯示的話，就基本可以支持分屏的模式。

在實際項目中，要兼顧以上所有模式的顯示是非常困難的，但它們還不是最大的難題。平板端適配最大的難題是平板的交互和手機不同，手機往往可以單手握持并使用拇指觸控，而平板的使用則會大量應用食指。

這導致平板的主要操作熱區和手機有很大差異，直接套用手機布局和交互在平板上操作就會顯得各種別扭。并且平板的適配不像網頁響應式包含了斷點的應用，且 CSS 樣式更輕量、靈活，可以在一套代碼內切換多種布局形式，所以這種交互的差異就成為平板適配中難以逾越的鴻溝。

也正是如此，平板適配往往只是開發團隊“偷懶”的做法，雖然知道體驗不好，但不會投入更多的人力成本去開發一個新 APP，先做適配能用就行。

所以，平板適配只是一個兼容平板端的妥協產物，設計師優先考慮的是在一個方向內能正常顯示，無需去覆蓋所有的平板的應用場景即可。

結尾

時間關系寫不完，還有最后一部分怎么進行適配的標注，會在下周再更新。