設計 YouTube 行動應用程式是系統架構上的一大挑戰。每天有數十億小時的影片在各種裝置與網路環境下被串流播放，要在這種規模下提供順暢的播放體驗，需要周全的規劃。本章將逐步檢視讓 YouTube app 能夠成為頂尖行動系統的關鍵元件。

YouTube 的規模極為驚人：

  • 服務超過 25 億活躍使用者，支援超過 80 種語言。
  • 截至 2024 年初，行動裝置貢獻超過 70% 的總觀看時間。

這樣的趨勢凸顯了優化行動體驗的重要性，也是我們整個設計的核心關注點。

Figure 1: YouTube screenshot taken from the Google Play Store

Step 1：理解問題與界定設計範圍#

在動手設計之前，必須先釐清需求與邊界。想像我們正在與面試官對話，以確認系統的聚焦方向：

  • Candidate： 首先想確認範圍。我們要專注在影片消費體驗（browsing 與 playback），還是也要考慮創作者功能，例如上傳或直播？
  • Interviewer： 請專注在影片消費：瀏覽與播放。不包含內容創作與直播。
  • Candidate： 了解。對於消費端，我假設使用者需要在首頁瀏覽推薦影片並觀看它們。播放器應提供播放、暫停、拖曳等控制，以及畫質（如 360p、720p）、字幕與多音軌選項。這符合您的想像嗎？
  • Interviewer： 是的，這涵蓋了核心功能。
  • Candidate： 關於播放部分，可以假設我們使用現成的串流方案（例如 HLS 或 DASH）來做 adaptive streaming，還是要自行設計？
  • Interviewer： 可以使用現成的協定，不需從零打造。
  • Candidate： 太好了。為了提升體驗，對影片 feed 預先抓取（prefetching）推薦影片可能會有幫助。要納入這點嗎？
  • Interviewer： 是的，prefetching 是很有價值的補充。
  • Candidate： 收到。那像觀看紀錄（watch history）、播放清單管理，或是按讚、留言等社交功能呢？
  • Interviewer： 這些都不在範圍內。
  • Candidate： 最後關於規模，我們應以多少日活躍使用者（DAU）為設計目標？
  • Interviewer： 全球約 10 億 DAU。

透過這段對話，我們建立了清晰的目標與限制。

需求#

基於以上對話，我們要打造一個以影片消費為核心的 YouTube-like 行動 app，功能包括：

  • 使用者可在首頁瀏覽推薦影片。
  • 使用者可透過功能豐富的播放器觀看影片。
  • App 會預先抓取（prefetch）影片 feed 資料以提升體驗。

非功能需求（non-functional requirements）：

  • 可擴展性（Scalability）：要能服務全球 10 億 DAU，並適應從高速 Wi-Fi 到訊號不穩的行動網路等各種條件。
  • 效能（Performance）：在所有裝置上都要有順暢的捲動與播放體驗，並有效率地遞送媒體內容。
  • 可用性（Availability）：保證影片服務不中斷，並支援多語言與多地區以服務全球使用者。

UI 草圖#

思考 app 的主要畫面，如 Figure 2 所示：

  • Home screen：呈現個人化的影片推薦。
  • Video Player screen：播放所選影片並提供控制介面。

Figure 2: Basic sketch of our YouTube app

範圍確立、UI 草圖完成之後，接著探討 app 如何與後端溝通。

Step 2：API 設計#

網路協定（Network protocol）#

對大多數 client-server 的互動，我們採用 RESTful API over HTTP with JSON。原因是：

  • REST 設計直覺簡單。
  • 與行動端及既有工具高度相容。
  • 易於實作與維護。

不過在 YouTube 的規模下，效率十分關鍵。JSON payload 較大，可能在行動網路上拖慢效能。gRPC 搭配 Protocol Buffers 能提供更精簡、快速的序列化，非常適合高效能系統。

gRPC 屬於較專門的技術，並非所有開發者都熟悉。為了簡潔，本章採用 RESTful API 設計；若你熟悉 gRPC，也可以直接改用，同樣是很好的選擇。

Endpoints#

我們以實際的 YouTube Data API 為基礎設計核心 endpoints。它採用類 REST 架構，並有一些值得學習的設計巧思。

影片瀏覽（Video browsing）#

YouTube 的 Video 資源 data model 包含非常豐富的 metadata：從基本資訊到觀看次數、內容限制一應俱全。然而並非每個 client 都需要一次取得所有欄位。

YouTube API 透過彈性的 part 參數解決過度抓取（over-fetching）問題：

GET https://youtube.googleapis.com/youtube/v3/videos?
    part=snippet,statistics,contentDetails&
    id=VIDEO_ID&
    maxResults={results}&pageToken={cursor}

part 參數讓 client 指定要取得哪些欄位集合，例如 snippet（標題、縮圖）或 statistics（觀看數）。好處包括：

  • 縮減 payload，降低網路頻寬使用。
  • 伺服器只需抓取所需欄位，提升效率。
  • 提供 client 細緻的資料控制能力。
  • 保留 REST 的簡潔性，同時加入欄位選擇能力。

與 GraphQL 的逐欄位選擇不同，part 允許在「預先定義的欄位集合」中做選擇。雖不如 GraphQL 細緻，但在彈性與複雜度之間取得良好平衡。

熱門影片 endpoint#

使用者未登入時，我們需要在主 feed 顯示熱門內容：

GET /youtube/v3/videos?part=snippet&chart=mostPopular&
    maxResults=20&regionCode=US
影片詳情 endpoint#

使用者點擊某個影片後，取得其完整資訊：

GET /youtube/v3/videos?id=VIDEO_ID&
    part=snippet,player,contentDetails,statistics

此請求一次取回：metadata（title、description）、播放資訊（player）以及互動指標（statistics）。

影片播放（Video playback）#

由於我們設計的是 YouTube 內部 client，可以直接把 streaming manifest 餵給平台原生的播放器 API，而不必像第三方 app 那樣透過 YouTube IFrame Player API。

我們可以設計如下的播放 endpoint：

GET https://my-internal.googleapis.com/youtube/v3/videos/playback?
    codecs=supportedCodecs&
    protocols=supportedStreamingVideoProtocols&
    language=preferredLanguage&
    subtitles=preferredSubtitles

回應會依裝置能力回傳對應的 streaming manifest（如 DASH 或 HLS），並附帶字幕等 metadata。串流協定細節會在後續章節深入討論。

Step 3：高階 Client 架構#

API 定好後，把目光轉向 client 端的架構。Figure 3 勾勒出整體架構。

Figure 3: High-level architecture diagram of our YouTube app

後端元件#

系統依賴數個外部服務：

  • Backend：管理影片資料、使用者互動，並透過 HTTP 提供 API。
  • CDNs：將影片、縮圖、metadata 等靜態資源快取在靠近使用者的節點，加速遞送。
  • API Gateway：作為請求的大門，處理路由、驗證與存取控制。

CDN 在影片串流中扮演關鍵角色：

  • 使用者體驗：從就近節點取得內容，大幅降低載入時間與緩衝。
  • 可擴展性：數百萬使用者同時觀看熱門影片時，負載分散在多個 CDN 節點。
  • 成本效益：降低對原始伺服器的壓力，節省頻寬與延遲成本。

CDN 成本在大規模下會非常可觀，促使主要串流平台尋求替代方案：

  • Netflix 自建 Open Connect CDN：獲得更大的遞送控制權並為影片內容做最佳化。
  • 其他公司則與 ISP 合作，把伺服器放進 ISP 網路中，降低遞送成本並提升品質。

Client 架構#

UI Layer 由兩個主要畫面組成：

  • Home Screen：瀏覽推薦影片。
  • Video Player screen：查看影片詳情，並透過 Video Player UI component 播放。

每個畫面都有對應的 state holder 來暴露 UI state 並處理業務邏輯。

Data Layer 則透過三個 repository 提供核心功能：

  • Browsing repository
  • Video repository
  • History repository

每個 repository 都有對應的 Remote Data Source，並透過 Network Dispatcher 與後端通訊。

Step 4：深入設計#

我們挑選三個關鍵主題深入討論：

  • 影片串流（Video streaming）。
  • 影片 feed 的 prefetching。
  • 增強使用者體驗（Enhanced user experiences）。

影片串流#

打造 YouTube 這類影片 app，提供順暢的觀看體驗是關鍵，使用者期望影片能快速啟動且播放不卡頓。

現代影片串流與傳統下載不同，會把影片切成小片段（segment）漸進載入：

  1. 下載前幾個 segment 後即可開始播放。
  2. 後續 segment 在背景持續載入。
  3. 畫質會依連線速度動態調整。
  4. 已播放的 segment 會被釋放以節省記憶體。

這種方式非常適合行動環境：只載入當下需要的內容，節省記憶體且能處理任意長度的影片；當網路變化時也能切換畫質以維持最佳體驗。

影片串流協定#

現代影片串流仰賴多種協定，各有其適用情境：

  • HTTP Live Streaming (HLS)：Apple 推出的主流協定，透過標準 HTTPS 將影片切成小塊遞送，適應網路變化。在 Apple 裝置上表現最佳，但跨平台相容性也很好。
  • DASH (Dynamic Adaptive Streaming over HTTP)：原則與 HLS 類似，但為開放標準且不綁定特定 codec，開發彈性更高，在非 Apple 生態系中廣泛採用。
  • Common Media Application Format (CMAF)：統一 HLS 與 DASH 的容器格式，避免為同一內容維護多份版本，簡化部署與降低儲存成本。
  • 其他協定包括：WebRTC、SRT (Secure Reliable Transport)、以及較舊的 RTSP 與 RTMP。

選擇協定時需考量：

  • 延遲（latency）：影片多快能開始播放。
  • 平台相容性：Android 與 iOS 及其生態系的支援度。
  • 安全性：傳輸過程中的內容保護。

這些協定涉及許多底層技術細節，系統設計面試通常不需要深入掌握。重點是了解不同協定支援不同格式與播放器，會影響你的架構選擇。

對於 YouTube、Twitch、Netflix 這類影片串流 app，HLS 與 DASH 是兩大主流協定。它們都支援 adaptive bitrate streaming (ABR)，會依網路與裝置能力自動調整畫質。若需要低延遲場景，也有 LL-HLS 與 LL-DASH 版本。

HLS 與 DASH 這類 adaptive streaming 協定，通常會使用 adaptive bitrate streaming (ABR) 根據網路條件調整畫質。

大多數主流平台會同時實作多種協定以擴大裝置相容性並因應不同情境。例如 YouTube 就同時支援 HLS、DASH、RTMP 與 RTMPS。

Adaptive bitrate streaming#

使用者會在 WiFi 與行動網路間切換、進入不同網路環境，video app 必須能應對這些變化。ABR 透過以下機制解決問題：

  1. 多畫質版本
    • 影片以不同畫質編碼（480p、720p、1080p）。
    • 每個版本在品質與頻寬間取得不同平衡。
  2. Video segmentation
    • 內容切成小片段（通常 2–10 秒）。
    • 每個片段都有所有畫質版本。
    • 片段越短，切換越快，但請求數也越多。
  3. 即時畫質切換
    • 播放器持續監控網速與裝置效能。
    • 為下一個片段挑選最佳畫質。
    • 畫質可隨時往上或往下調整。

播放器會追蹤下載速度、buffer 水位、CPU/GPU 使用率與裝置能力來做決策。連線改善時畫質逐漸提升；變差時畫質會快速下降以避免緩衝。實務上行動播放器多採 buffer-based 或 hybrid（buffer + throughput）演算法，由於每次決策只影響下一個片段，系統可即時回應網路變化。

Android 與 iOS 的影片串流#

行動端影片串流的最佳選擇是平台原生方案：

  • Android：ExoPlayer
  • iOS：AVPlayer

這些框架同時支援 HLS 與 MPEG-DASH，提供順暢可靠的播放。優勢包括：

  • 深度平台整合：例如硬體解碼以達最佳效能。
  • 完整控制播放功能：adaptive bitrate、字幕等。

第三方播放器（VLC、JWPlayer、Brightcove）雖提供跨平台一致的 API，但原生方案通常有更佳的客製化彈性。

管理影片內容：字幕與音軌#

現代串流服務會將影片、音訊、文字元件分離。這種模組化設計（MPEG-DASH 與 HLS 都採用）讓體驗更彈性、更有效率。

字幕與字幕軌支援#

MPEG-DASH 與 HLS 都透過獨立的 text track 實作字幕與 closed caption：

  • HLS：使用 WebVTT 格式，在 .m3u8 主播放清單中引用。
  • MPEG-DASH：支援 WebVTT 與 TTML（Timed Text Markup Language），在 .mpd manifest 中定義。

所謂「獨立 track」指的是與主影片並行播放的獨立內容流（音訊、字幕、closed caption）。每條 track 有自己的資料與時間資訊，可與影片保持同步。這種分離設計讓不同類型內容易於管理且保持同步。

YouTube 採用此作法的原因：

  • 文字佔用空間極少，降低整體頻寬。
  • 支援多語言時無需複製影片流。
  • 便於滿足 accessibility 需求，字幕可輕易更新。
  • 即時字幕更新無需重新處理影片。

縮圖實作#

使用者在拖曳進度條時看到的預覽圖（如 Figure 4），並非 HLS 或 MPEG-DASH 標準協定的一部分，必須另外實作。

Figure 4: Precise seeking thumbnails on the YouTube Android app

Sprite sheets#

一種常見做法是 sprite sheets（亦稱 texture atlas），把多張縮圖合併成單一檔案，減少伺服器請求次數。此法在網頁串流表現良好，但需維護預先產生的影像檔。

Figure 5: Example of a sprite sheet for thumbnails

利用 adaptive streaming#

第二種作法是利用既有的 adaptive streaming 技術，抓取低解析度的影片 frame 作為預覽。YouTube 行動 app 採用此方式：

  1. 使用者拖曳時，app 向伺服器請求該時間點的內容，但以較低解析度（通常 144p 或 240p）。
  2. 伺服器快速遞送低 bitrate 片段，讓拖曳時的預覽更順暢。
  3. 使用者放開後，app 切回全解析度進行正常播放。

此方式在行動 app 上的優點：

  • 顯示實際動態畫面，比靜態圖像提供更佳的上下文。
  • 複用既有串流基礎建設，無需額外系統。
  • 無需儲存額外縮圖資產，節省空間。
  • 低延遲且精準的預覽，貼近實際內容。

常見挑戰#

記憶體管理（Memory management）#

影片播放對記憶體需求極高，而行動裝置資源有限。OS 會終止佔用過多記憶體的 app，妥善的記憶體管理是串流穩定的關鍵。

策略：

  • Adaptive buffer sizing：低階裝置用較小 buffer，高階裝置用較大 buffer 換取順暢度。
  • Frame recycling：重用 video frame buffer 而非持續配置新記憶體。
  • 優雅降級（Degrade gracefully）：記憶體壓力升高時降低畫質，避免播放失敗。
  • 妥善處理 app 狀態轉換：進入背景時釋放資源。

此外，應實作監控機制追蹤不同裝置與情境下的記憶體模式，以便提前發現問題。

電池壽命最佳化#

影片播放是最耗電的操作之一，同時消耗處理器與網路資源。節能技巧：

  • Adaptive quality selection：電量低或未充電時降低解析度與 bitrate。
  • Hardware acceleration：可用時優先使用，降低 CPU 負擔。
  • 暫停播放並停止網路：app 不在前景時應暫停。

平台實作細節：

  • Android：使用 Battery Saver API 偵測省電模式並相應調整畫質。
  • iOS：回應低電量模式（Low Power Mode）通知，降低播放品質。
網路處理#

行動網路難以預測，需要周全策略：

  • Bandwidth adaptation：透過 ABR 依可用頻寬切換畫質。
  • Efficient retry logic：使用 exponential backoff with jitter，避免重試造成網路壅塞。
  • 預下載（Pre-downloading）：在網路良好時允許離線觀看下載。
  • 依連線類型調整 buffering 策略（cellular vs. Wi-Fi）。
進階串流最佳化#

除了基本處理，以下進階技巧能明顯改善體驗：

  • 音訊優先於影片：網路受限時優先維持音訊連續性，因為使用者對聲音中斷更敏感。
  • Predictive buffering：分析觀看行為，預先 buffer 使用者可能觀看的內容。
  • 字幕最佳化：在行動 app 上快取 text track，以支援離線或不穩定網路。

打造高效影片串流需要在順暢播放、電池壽命、網路韌性之間取得平衡，視 app 特性與使用者需求而定。

產業案例：

  • Reddit 為短影片客製化 ExoPlayer：選擇高效格式（MP4），優化快取、buffering 策略與頻寬估算，顯著降低載入時間、播放錯誤與 rebuffering。
  • Netflix 使用 shot-based encoding 與動態最佳化技術強化 4K 串流，提升畫質並降低 bitrate。
  • Netflix 建立以 Unicode 為基礎的管線，有效率地處理多語言字幕與 closed caption。
  • Netflix 推出高品質音訊功能，追求工作室等級、感知透明的音訊體驗。

Prefetching 影片 feed 資料#

使用者一打開 YouTube 就期待看到相關內容。為了滿足此期待，行動 app 會預先抓取 feed，讓使用者開啟時就能立刻看到內容。

接下來探討如何在體驗與資源消耗之間取得平衡。

設計選項#

Table 1 比較幾種 feed prefetching 策略。

選項描述優點缺點
Time-based不論使用者活動，定期抓取推薦實作簡單、網路用量可預測、內容保持新鮮可能造成不必要的流量、無法反映真實行為、可能錯過重要更新
Event-based依特定事件（如 app 進入前景/背景）觸發貼近實際行為、減少不必要請求、資源運用更有效率可能錯失最佳時機、內容新鮮度不穩定、實作邏輯複雜
Intelligent結合多種訊號（裝置狀態、使用模式等）決定最佳時機同時最佳化 UX 與資源、適應個別習慣、優雅處理不同網路最難實作、需仔細調參、需完善監控

Table 1：不同 prefetching 策略的取捨

由於我們操作在極大的規模，且擁有豐富的使用者資訊，因此採用 intelligent prefetching。我們可以在 app 端依下列訊號決定何時預抓內容：

  • 裝置狀態：是否充電、網路類型。
  • 使用模式：使用者通常何時打開 app。
  • 內容相關性分數。
  • 資源可用性：例如電量。

此資料驅動的方法能在最佳時機 prefetch 內容，兼顧體驗與資源效率。

實作細節#

訊號收集與分析#

智慧 prefetching 的核心是理解使用者行為。Client 負責收集裝置狀態與使用者互動訊號，讓後端能做出更個人化的推薦。

我們可採用 remote configuration 系統讓後端指導 client 行為，設定項目包括：

  • 每次 prefetch 的 feed 資料數量。
  • Prefetch 間隔。
  • 是否允許在行動網路上 prefetch。
  • 電池與充電狀態考量。
推薦評分#

後端透過評分系統為使用者排序推薦，同時考量觀看歷史與內容時效性。每筆推薦定義兩個關鍵欄位：

  • relevanceScore：內容與使用者興趣的相符程度，通常 0–100。
  • ttl（time-to-live）：該推薦的有效期限。

內容相關性並非靜態；當使用者偏好變化時，後端會更新分數，client 也會刷新快取以確保看到最新內容。

Prefetch scheduler#

Client 使用背景排程器管理 prefetch。它依後端設定執行，同時考量系統資源。

平台實作細節：

Android 與 iOS 各有背景任務框架，但核心邏輯相同。

  • Android：使用 WorkManager API 排程背景任務，內建 Wi-Fi、充電等約束條件。若需特定時間觸發，可整合進排程邏輯。
  • iOS：使用 Background Tasks framework，可透過 earliestBeginDate 設定偏好執行時間，但網路與電池檢查需自行實作。

兩個平台都可能延遲或批次執行背景任務，實作時應優雅地處理這些排程差異。

持續最佳化#

真正的威力來自持續最佳化：client 監控使用者互動並回報給後端，形成 feedback loop，動態調整 prefetch 行為：

  • 高互動時段提升頻率。
  • 低使用時段減少或暫停。

Prefetching 的挑戰#

裝置資源管理#

Prefetch 會耗用資源並可能增加流量（尤其在按量付費網路上）。策略：

  • 預設僅在 Wi-Fi 下 prefetch，行動網路需 opt-in。
  • 電量過低時（例如低於 20%）暫停 prefetch。
  • 在低階裝置上降低頻率與份量。
  • 依內容類型與使用者互動模式調整刷新間隔。
記憶體限制#

快取縮圖尤其佔用記憶體：

  • 依裝置能力限制 prefetch 快取大小。
  • 使用支援 downsampling 與記憶體友善的圖片載入函式庫。
  • 收到 OS 記憶體警告時清理舊快取。
  • 使用者偏好大幅改變時移除過時推薦。
衡量 prefetch 成效#

要確認 prefetch 策略真的改善體驗，應追蹤：

  • 使用者開啟 app 時看到推薦的速度。
  • Prefetch 內容與非 prefetch 內容的互動率比較。
  • Prefetch 影片的實際觀看比例。
  • 資料效率（預抓但未觀看的位元組數），了解資源浪費。
  • 電池消耗模式，以平衡效益與電力成本。

這些資料能形成持續改進 prefetch 演算法的回饋迴路。

架構更新：支援影片推薦 prefetching#

為支援影片推薦 prefetching，我們在架構上新增幾個關鍵元件（見 Figure 6）：

  • Recommendations Repository：新增的 repository，透過本地與遠端資料來源為現有的 Browsing Repository 提供推薦內容。
  • Recommendations Prefetching Service：由作業系統觸發，負責定期刷新推薦。
  • Device Monitor：檢查電量、網路狀態等條件；條件允許時才透過 remote data source 與後端同步。

Figure 6: Intelligent prefetching related updates to the data layer

產業案例：

  • Facebook 的行動 app 在使用者捲動時監控記憶體中的影片池；當池內數量低於閾值，就帶著使用者訊號發送請求，取得並排序新的個人化影片候選，快取後供順暢播放。
  • Facebook Feed 的推薦引擎使用 AI 個人化內容，分析使用者互動、預測 engagement，並依多種訊號計算的相關性分數來排序貼文。

增強使用者體驗#

面試官有時會追加需求，例如討論如何針對行動使用者做專屬體驗優化。本節聚焦三個領域：

  • 手勢影片控制（gesture-based controls）。
  • 背景音訊播放。
  • 子母畫面（Picture-in-Picture）。

手勢影片控制#

傳統的按鈕與滑桿在行動小螢幕上容易顯得笨重。手勢控制讓使用者直接與影片互動，提供更沉浸的體驗。常見手勢包括左右滑動拖曳進度、點擊調整音量與亮度等。

技術上需實作以下元件：

  1. GestureDetector：捕捉並解析觸控輸入，辨識 swipe、tap、pinch 等模式。
  2. VideoControlHandler：接收辨識後的手勢，轉換成播放器命令。
  3. 視覺回饋機制：辨識成功時提供螢幕上的細膩提示，讓使用者理解操作結果。

實作時需謹慎處理：

  • 區分相似手勢（如水平滑動 vs. 斜向滑動）。
  • 多種手勢重疊時的衝突解決。
  • Accessibility：無法做某些手勢的使用者。

技術挑戰在於打造反應迅速、感覺自然，且能與播放器核心功能良好整合的系統。

背景音訊播放#

許多 YouTube 影片的價值在於聲音，例如音樂、podcast、新聞。背景音訊播放讓使用者在使用其他 app 或鎖定螢幕時繼續聆聽。

模式切換邏輯#

當使用者離開 app 或鎖定螢幕時，需要在影片與純音訊模式間無縫切換：

  1. 監聽 app lifecycle 事件，判斷何時進入背景。
  2. 進入純音訊模式時釋放影片渲染資源，但維持音訊播放。
  3. 背景模式下切換至 audio-only stream 以節省流量。

平台實作細節：

  • Android：使用 foreground service 搭配媒體通知維持播放優先順序，建議透過 Jetpack Media3 API。
  • iOS：使用 AVAudioSession 設定適當的 category 與選項，使背景下仍可播放。
使用者控制與偏好#

應尊重使用者的偏好設定：

  • 讓使用者開啟或關閉自動背景播放。
  • 在行動網路上提供 audio-only 選項以省流量。
  • 針對 premium 與 free 使用者提供不同行為（背景播放常作為 premium 功能）。

Picture-in-Picture 模式#

Picture-in-Picture (PiP) 讓使用者在使用其他 app 時以小視窗繼續觀看影片，強化多工能力並讓使用者即使切換情境也保持參與。Figure 7 展示了此功能。

Figure 7: Example of Picture-in-Picture mode

平台實作細節：

  • iOS：iPad 從 iOS 9、iPhone 從 iOS 14 開始原生支援 PiP。透過 AVPictureInPictureController 搭配 AVPlayerLayer 或 AVPlayerViewController 即可啟用。
  • Android：從 Android 8.0 (API level 26) 開始，只要在 Activity 上呼叫 enterPictureInPictureMode 並設定 PictureInPictureParams 即可進入 PiP（需裝置與系統設定支援）。
最佳化 PiP 體驗#

除了基本實作，以下最佳化能讓 PiP 更好用：

  • 使用者按下 home 鍵或切換 app 時自動進入 PiP。
  • PiP 模式下僅保留必要控制（play/pause、close），讓小介面更易操作。
  • 降低 PiP 模式的畫質以省頻寬與運算資源。
  • 暫停非必要的動畫與背景任務。
  • 使用者點擊 PiP 視窗返回 app 時，完整還原離開前的狀態。

協調各項增強體驗#

手勢控制、背景音訊播放、PiP 的價值在於整合為統一系統。例如：

  • 手勢功能在全螢幕與 PiP 模式下應一致。
  • 切換到背景播放時必須保留播放位置，讓使用者無縫恢復。

確保這些功能和諧運作，才能提供符合行動設計原則的連貫體驗。

Step 5：總結#

本章設計了一個聚焦於高品質影片內容且保持順暢體驗的 YouTube 行動 client。系統圍繞 REST API with JSON 建構，能同時支援多種 client。

深入章節中，我們探討：

  • 使用 DASH 與 HLS 實作 adaptive streaming，自動依頻寬與裝置能力調整畫質。
  • 開發 intelligent prefetching 系統，分析使用者行為與裝置資源以抓取 feed 資料。
  • 透過手勢控制、背景音訊播放、Picture-in-Picture 強化行動使用體驗。

若時間允許或想展現更進階的能力，可探討以下功能：

  • 直播平台：設計低延遲直播系統，整合聊天、訊息處理與內容審核。
  • 智慧內容管理：打造可離線使用、跨平台深度連結分享的播放清單系統。
  • 跨裝置整合體驗：跨裝置同步觀看進度與播放佇列，無縫切換平台。
  • 貨幣化整合：整合廣告服務，支援影片預載與廣告插播。
Backward Google Drive app Mobile System Design Building Blocks Forward