跳至主要内容

課程：RN 跨平台開發基礎 第 9 堂：跨平台差異根源

系統 UI 邊界

想像一下，你花費了數週時間設計了一個精美的媒體播放 APP。在設計稿中，影片封面完美地填滿了整個螢幕，色彩繽紛。但當你第一次在實機上執行時，卻發現頂部的「返回」按鈕被 iPhone 的劉海（Notch）遮住了一半，而底部的播放進度條則尷尬地與 Android 的系統手勢列重疊，導致使用者每次想拉進度條時都會不小心滑出 APP。

這種「內容被系統侵蝕」的挫折感，是每一位 React Native 開發者在處理跨平台佈局時的必經之路。

在上一節中，我們討論了 iOS 與 Android 的設計哲學差異：iOS 傾向於讓內容「滲透」到螢幕的每一個角落，而 Android 則傾向於清晰的「實體分層」。這種哲學差異最直接的戰場，就是所謂的「系統 UI 邊界」。本節我們將深入探討如何精準控制 SafeArea（安全區域） 與 StatusBar（狀態列），確保你的內容既能擁有沉浸感的視覺效果，又不會犧牲操作的易用性。

什麼是 SafeArea？為什麼它如此麻煩？​

在智慧型手機進入「全螢幕時代」之前，開發者只需要擔心狀態列（Status Bar）。但自從 iPhone X 引入了劉海，以及隨後出現的動態島（Dynamic Island）、圓角螢幕、底部的橫條手勢列（Home Indicator），螢幕的「物理形狀」變得極其複雜。

SafeArea（安全區域） 指的是螢幕中「保證不會被硬體遮擋」且「不會與系統手勢衝突」的區域。

核心挑戰：內容滲透 vs. 功能安全​

在內容類 APP 中，我們通常面臨一個矛盾的設計需求：

  1. 視覺沉浸：背景圖片或影片應該填滿整個螢幕（延伸到劉海下方和螢幕最底部），這被稱為「邊到邊（Edge-to-Edge）」佈局。
  2. 互動安全：按鈕、標題、輸入框等可操作元件，必須嚴格留在 SafeArea 之內。

如果你的佈局只是簡單地把整個畫面塞進一個安全框裡，你會發現螢幕頂部和底部會出現醜陋的白邊（或黑邊），這完全破壞了現代 APP 的精緻感。因此，理解如何「選擇性」地套用安全邊距，是進階 RN 開發者的必修課。

工具的選用：內建 vs. 社群標準​

在 React Native 的世界裡，處理安全區域主要有兩個選擇。了解它們的差異，能幫你避免許多不必要的 Bug。

1. React Native 內建的 SafeAreaView​

這是 RN 核心庫自帶的元件。

  • 優點：簡單易用，只需將內容包裹起來。
  • 缺點：
    • 僅支援 iOS：在 Android 上它基本上就是個普通的 View，完全沒有作用。
  • 靈活性差：它會自動在四個方向都套用邊距。如果你希望背景圖滲透到底部，但文字留在上方，SafeAreaView 很難做到精準控制。
  • 封裝過度：你無法得知具體的像素值（例如劉海到底是 47 像素還是 59 像素），這讓你在做複雜動畫時綁手綁腳。

2. react-native-safe-area-context (推薦)​

這是 Expo 預裝且目前社群公認的標準方案。它不僅支援跨平台（iOS & Android），更重要的是它提供了 Hook 的方式來獲取數據。

它透過 SafeAreaProvider 在 APP 頂層監聽系統邊距的變化，並透過 useSafeAreaInsets 讓你直接拿到的數值：

const insets = useSafeAreaInsets();
// insets = { top: 47, bottom: 34, left: 0, right: 0 }

實戰：useSafeAreaInsets 的精準打擊​

假設你正在開發一個媒體 APP 的首頁，頂部有一個自定義的導覽列，背景是一張精美的海報。

預測一下：如果你直接在頂層容器使用 SafeAreaView，會發生什麼事？ 答案是：海報圖片的上方會出現一塊空白區域，因為 SafeAreaView 強行把整個容器推到了劉海下方。海報無法實現「滲透」到狀態列後方的視覺效果。

正確的作法：手動套用 Insets​

我們應該讓背景容器佔滿全螢幕，但只針對「文字內容」套用由 useSafeAreaInsets 提供的 top 數值。

import { useSafeAreaInsets } from 'react-native-safe-area-context';

const Header = () => {
  const insets = useSafeAreaInsets();

  return (
    <View style={{ 
      paddingTop: insets.top, // 精準避開劉海
      backgroundColor: 'transparent',
      height: 60 + insets.top // 動態計算高度
    }}>
      <Text>我的收藏</Text>
    </View>
  );
};

這種方式的優勢在於：你的背景圖依然可以設置為 position: 'absolute' 並覆蓋整個螢幕，而你的標題文字則會乖乖地出現在劉海下方的安全位置。這種「背景延伸、內容收縮」的策略，是讓 APP 看起來專業的關鍵。

Android 的特殊挑戰：沉浸式狀態列與 Edge-to-Edge​

很多人會誤以為 Android 沒有劉海問題，但其實 Android 的挑戰更為隱晦。Android 有兩大系統 UI 區域：頂部的 Status Bar（狀態列） 和底部的 Navigation Bar（導航列/手勢列）。

1. 預設行為的陷阱​

在許多 Android 手機上，React Native 預設是不會延伸到狀態列後方的。這意味著你的 APP 頂部會有一條生硬的黑色條狀區域。

如果你想要實現 iOS 那種沉浸感，你需要開啟 Android 的 translucent（半透明/透明）模式。但在開啟後，你會發現一個災難：你的內容會直接鑽到狀態列下面。如果你沒有正確使用 react-native-safe-area-context，你的標題會跟系統的電量、時間圖標重疊在一起，變得完全無法閱讀。

2. Android 導航列的覆蓋​

現代 Android 系統提供了「手勢導航」或「虛擬三鍵」。如果你的 APP 沒有處理 bottom 邊距，你的底部 Tab Bar 或「提交」按鈕可能會被系統導航條擋住，導致使用者想點按鈕時卻觸發了系統的「回到首頁」手勢。

開發者心法：永遠不要假設 Android 的 bottom 是 0。即使看起來沒有實體按鍵，系統的感應區依然存在。

StatusBar：掌控系統圖標的靈魂​

除了處理空間邊距，你還需要控制系統狀態列本身的視覺表現。這就是 StatusBar 元件的職責。

barStyle：黑與白的抉擇​

這是最常被忽視的細節。

  • dark-content：深色文字（適用於淺色背景）。
  • light-content：淺色文字（適用於深色背景）。

在媒體 APP 中，這非常關鍵。當使用者在瀏覽白色的「設定」頁面時，你需要 dark-content 以確保時間和電量清晰可見；但當使用者點開一張深色的封面圖或進入播放器時，你必須立即切換為 light-content。

Android 的 translucent 屬性​

在 Android 上，如果你希望內容滲透到狀態列下方，必須設置 <StatusBar translucent backgroundColor="transparent" />。這會告訴系統：「不要幫我的 APP 留黑邊，讓我自己處理佈局。」

實戰場景：全螢幕媒體播放器​

讓我們把上述概念整合到一個真實的案例中：一個具備全螢幕切換功能的影片播放器。

當影片處於一般模式時：

  1. 我們需要 insets.top 來放置返回按鈕。
  2. StatusBar 應該是顯示的，可能是 light-content。

當使用者點擊「全螢幕」按鈕時，發生了什麼？

  • 隱藏系統 UI：我們需要調用 StatusBar.setHidden(true)。
  • 調整 SafeArea：一旦狀態列隱藏，有些系統會重新計算 SafeArea。但更重要的是，在全螢幕橫屏模式下，insets.left 或 insets.right 可能會突然變大（因為劉海現在出現在側面了！）。

如果你在寫程式碼時寫死了 paddingLeft: 20，在橫屏劉海機型上，你的控制按鈕可能會被劉海咬掉一塊。正確的作法是持續監聽 insets 的變化，並動態套用在控制列上。

// 橫屏播放時的控制列樣式
const controlsStyle = {
  paddingLeft: Math.max(insets.left, 20), // 確保至少有 20 邊距，若劉海更大則依劉海為準
  paddingRight: Math.max(insets.right, 20),
  paddingBottom: insets.bottom,
};

常見的避雷清單​

  1. 不要在同一個頁面混合使用 SafeAreaView 和 useSafeAreaInsets：這會導致邊距疊加，讓你的 UI 出現莫名其妙的巨大空白。
  2. SafeAreaProvider 的位置：確保它包裹在整個 APP 的最外層（通常在 App.tsx），否則 Hook 可能會回傳錯誤的 0 值。
  3. 異形螢幕的測試：不要只用 iPhone SE 模擬器。一定要在帶有動態島的 iPhone 和帶有打孔螢幕（Punch-hole）的 Android 實機上測試。打孔螢幕的攝像頭位置在不同 Android 機型上千變萬化，只有正確依賴 insets 數據才能萬無一失。
  4. 分屏模式 (Split Screen)：在 iPad 或大螢幕 Android 上，APP 可能只佔螢幕的一半。這時 insets 會動態更新，你的佈局必須具備響應式能力。

建立「邊界感」的心智模型​

處理跨平台邊界的核心，不在於寫出多麼複雜的 CSS，而在於建立一套 「邊界感」的心智模型。

你要意識到，你的 APP 並不是運行在一個完美的長方形容器中，而是運行在一個充滿「障礙物」的實體設備上。系統 UI（狀態列、導航列）就像是租客，而你的內容是房東。有時候房東想讓房間看起來更大（隱藏 UI 或透明化），但房東必須隨時知道租客在哪裡，才不會在擺放家具（按鈕）時撞到對方。

當你能游刃有餘地使用 useSafeAreaInsets 搭配 StatusBar 的動態控制時，你做出來的 APP 才會真正脫離「Web 包殼」的廉價感，展現出原生應用應有的精緻與穩定。

邊界處理的關鍵總結與銜接​

在本部分中，我們深入探討了如何處理螢幕的物理與系統限制。核心在於區分「背景滲透」與「互動安全」，並學會拋棄僵硬的 SafeAreaView，改用更靈活的 useSafeAreaInsets 進行精準控制。同時，我們理解了 Android 與 iOS 在狀態列處理上的本質差異，以及如何透過 StatusBar 元件來優化視覺體驗。掌握了這些，你的 APP 已經擁有了在不同形狀螢幕上完美呈現的基礎。

然而，處理好了靜態的「邊界」，接下來要挑戰的是動態的「侵入」。在行動裝置上，最常突然跳出來打亂佈局的不是劉海，而是虛擬鍵盤。同時，使用者如何透過手指與這些邊界內的元件互動，在兩個平台上也有著完全不同的觸感回饋。在下一部分中，我們將進入鍵盤行為的跨平台差異，並深入探討 Pressable 如何解決觸控互動的平台不一致問題。