screen recorder 錄屏引擎深潛：從 Surface 抓到硬編碼的全鏈路原理解析

screen recorder 是什麼、能幹嘛、適合誰

screen recorder 是一款主打輕量與參數自訂的安卓錄屏軟體——安裝包只有 4.12MB、不強制登入、首次啟動三秒內就能開始錄影。它能做的事情，表面上跟市面上多數錄屏 App 差不多：抓下螢幕上的所有操作、錄進內部聲音或麥克風輸出、產出 MP4 影片。但真正讓它在同類產品裡脫穎的，是幾個少見的設計決策——它把「錄屏」這件事拆成了若干條清晰的資料流管道，每一條都允許使用者直接觸控底層參數。

我是把它當工具來用的人，同時也對它的內部結構好奇過一段時間。下面這篇不是評測，是拆解——我想回答一個問題：一個這麼小的 App，是怎麼做到「不僅能錄、還能錄得靈活、錄得穩」的？想系統學習的話，可以看看 screen recorder下載 的完整指南。

安裝

screen recorder官網 的安裝很乾淨——APK 裝好之後不需要任何額外資源，也不請求 Google Play 服務權限。首次啟動時會彈三個權限請求：懸浮窗（用來顯示錄製控制按鈕）、儲存（影片寫入本機或 SD 卡）、螢幕錄製（Android 10+ 的 MediaProjection API 權限）。這三個是硬需求，少給一個對應功能就會啞——懸浮窗權限沒給的話，只能靠通知欄快捷磁貼或主介面按鈕啟動，沒有即時可視化控制。

安卓 10 以下的使用者要注意一點：內部聲音錄製是 Android 10 才引入的 AudioPlaybackCapture API，老系統沒有這條通道，只能選麥克風或從外放揚聲器取音。另外，長時間錄影前建議先在系統設定裡把 screen recorder 加入背景保護白名單——小米、華為、Oppo 這幾家的自動清理策略比較激進，容易把錄製中的進程殺掉。

問題：錄屏看起來很簡單，實際上卡在哪裡

大多數人對錄屏的直覺是「拍張螢幕截圖，連續拍很多張拼起來」。這直覺只對了一半——搞清楚這裡面的 技術原理 才不會選錯參數。真正的錄屏要處理三個並行的資料流：

畫面流：手機上所有可見的 UI 元件——App 介面、通知欄、系統導航鍵——都是由 SurfaceFlinger 這個系統服務統一合成後輸出到顯示器的。screen recorder 要抓的就是合成後的那個畫面，而不是逐個 App 去請求截圖權限。

音訊流：這條比較麻煩。使用者的需求通常是「要遊戲原聲、又要自己的解說」，但 Android 在很長一段時間裡不允許第三方 App 抓取系統內部聲音——所有音訊輸出都是經由 AudioFlinger 送到 DAC，第三方只能從麥克風那一端取。screen recorder 在 Android 10+ 上利用 AudioPlaybackCapture API 解了這個死結。

編碼流：畫面和聲音抓到之後，必須即時編碼成 H.264 或 H.265 視訊軌和 AAC 音訊軌，再透過 MediaMuxer 封裝成 MP4。這一段硬體編碼器的調用參數（解析度、幀率、比特率）直接決定了檔案大小和畫質。

screen recorder 的設計妙在，它沒有把這三條流封裝成一個黑盒——每一條流都對使用者開了參數。這不是 UI 上多放幾個設定滑桿那麼簡單，它代表著資料流管道在架構上就是獨立串接的。

拆解：screen recorder 的資料流管道是怎麼串的

我把 screen recorder 的錄製引擎畫成下面這條鏈路，每一節都對應著它在介面上暴露出來的一個參數：

SurfaceFlinger（系統合成層）→ MediaProjection（抓取 API）→ ImageReader（幀緩衝）→ MediaCodec（硬編碼器）→ MediaMuxer（封裝器）→ MP4 檔案

畫面流從 SurfaceFlinger 出發，這是安卓圖形堆疊的最終合成層——所有 App 的 Surface 經過 Z-order 排序、變換、裁剪之後，由 SurfaceFlinger 統一輸出到螢幕。這種層級式的合成架構對做 安卓助手 類應用開發的人來說特別熟悉。screen recorder 透過 Android 5.0 引入的 MediaProjection API 訂閱這個輸出，拿到一個虛擬顯示器的 Surface，然後用 ImageReader 按指定的幀率（使用者設定的 30fps 或 60fps）從這個 Surface 取走 YUV 格式的幀資料。

取到的幀直接送進 MediaCodec——這是 Android 提供的硬體編碼器介面，底層對應高通、聯發科或三星的視訊編碼硬體。screen recorder 把使用者設定的解析度（720p / 1080p / 與螢幕一致）、比特率（4Mbps ~ 16Mbps）、編碼格式（H.264 或 H.265）全部透傳給 MediaCodec，沒有做任何二次處理。這意味著如果使用者設定了超過硬體能力的參數，編碼器會直接報錯——screen recorder 不會幫你自動降配，這是它的設計取向之一：參數直連底層，不做「保護性」改寫。

音訊流在 Android 10+ 上有兩條並行來源：AudioPlaybackCapture 抓內部聲音，Microphone 抓使用者語音。screen recorder 用兩個獨立的 AudioRecord 實例分別採樣，然後在 MediaCodec 之前做一次混音——把兩路 PCM 樣本等量疊加成一條音訊軌，送進另一個 MediaCodec 實例做 AAC 編碼。這裡沒有混音比例滑桿，是刻意的簡化：大多數使用者要的就是「原聲 + 解說」同時存在，真正需要精細混音的人會把影片導進剪映或 DaVinci Resolve 再處理。

編碼完成的 H.264 視訊包和 AAC 音訊包，最後交給 MediaMuxer 按 MP4 容器規格封裝，寫入使用者指定的儲存路徑——內部儲存或 SD 卡。整條鏈路是同步串接的，任何一節延遲都會往後傳遞：如果硬體編碼器撐不住高解析度高幀率，ImageReader 的緩衝區會爆掉，表現在使用者面前就是錄影丟幀。

取捨：這套設計的代價與邊界

參數直連底層的代價是「不做保護」。手機上的硬體編碼器能力参差不齐——同一個 1080p@60fps 設定，在高通驍龍 8 Gen 2 上穩如老狗，在聯發科 Helio P35 上可能直接崩。screen recorder 的態度是：參數是你選的，後果也是你的。這種設計對懂技術的使用者是解放，對新手是個坑——有趣的是，同樣是參數直連的取向，我還在一款熱門 掃碼工具 身上見過類似的工程取捨。

第二個取捨是「背景保活交給系統」。screen recorder 自己不做進程守護、不開前景服務（錄製過程中的計時器顯示是透過通知欄實現的，不是前景服務）。這意味著在小米、華為這類有激進背景清理策略的裝置上，錄製進程很容易被殺掉——解決方案完全在使用者那邊：手動把它加入背景保護白名單、給自啟動權限、任務卡片加鎖。這不是 Bug，是設計哲學的一部分：一個 4MB 的 App 不該自己扛整個 Android 廠商生態的清理策略。

第三個取捨是「不做後處理」。錄影完成後，screen recorder 只提供最基本的修剪（trim）功能，沒有濾鏡、沒有後期混音、沒有浮水印編輯。它的定位很清楚：我負責把畫面和聲音忠實地抓下來、編碼好、存進檔案，後面的事交給專門的剪輯軟體。

判斷：這套原理意味著什麼

把整條鏈路看一遍，其實就能回答開頭那個問題：screen recorder 為什麼小、為什麼靈活、為什麼在 Android 10+ 上錄聲音特別穩。

它小，因為它只做抓取、編碼、封裝三件事，所有 UI 裝飾和後處理全部砍掉，APK 體積自然壓得下來。它靈活，因為三條資料流（畫面、內部聲音、麥克風）從頭到尾沒有耦合——每一條都可以單獨調參數、單獨開關。它穩，因為它不碰系統合成層以下的任何東西，完全依賴 Android 提供的標準 API（MediaProjection、AudioPlaybackCapture、MediaCodec），這些 API 是 Google 自己在維護的，兼容性比那些繞路抓 SurfaceControl 的方案好得多。

適合什麼人？我自己把它分成兩類。一類是做遊戲解說、應用教學的內容創作者——他們需要可控的參數、乾淨的音訊源、穩定的長時間錄影，screen recorder 剛好踩在這些點上。另一類是對 Android 圖形堆疊好奇的開發者——把參數拉滿、看著編碼器的行為隨之變化，是理解 MediaCodec 和 SurfaceFlinger 互動關係的好辦法。

不適合什麼人？純新手、想要「裝好就能完美錄影、什麼都不用調」的人——screen recorder 會把一堆參數直接丟在你面前，不做任何預設引導；還有需要即時浮水印、畫中畫多視訊軌的進階創作者——這些功能它完全沒有，得換成更重的方案。

最後說一句：我花時間拆解這款錄屏工具，不是因為它功能最全，而是因為它的架構表現出一種少見的克制——每一條參數暴露、每一個 API 選擇，都有清晰的取捨邏輯。4MB 的安裝包裝下了一條完整的即時資料流管道，這種乾淨的工程思維本身就值得記錄。

本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。