使用全新 Android 模擬器工具進行持續測試

做者 / Lingfeng Yang, Android Studio team

開發者在平常的開發工做中每每會先使用 Android 模擬器來快速測試修改過的應用，而後再提交代碼。此外，開發者愈來愈多地在其持續集成 (CI, Continuous Integration) 系統中使用模擬器來運行較大規模的自動化測試。爲了更好地支持這些用例，咱們開源了 Android Emulator Container Script，並圍繞如下兩個痛點改進了開發體驗:

• 可部署性: 查找並運行所需版本的 Android 模擬器。
• 可調試性: 跟蹤來自 Android 模擬器遠程實例的錯誤。

可部署性

Android 支持多種硬件和軟件配置，Android 模擬器也不例外。可是，這種多樣性可能會致使測試環境配置出現混亂。開發者該如何得到模擬器和系統鏡像文件？須要什麼驅動程序？如何打開或者關閉 CPU 或 GPU 加速？等等等等。

爲了解決這些問題，咱們推出了:

• Android Emulator 下載腳本 - 該腳本提供了模擬器鏡像的最新列表 (包括 AOSP 和包含了 Google Play 服務的版本) 以及模擬器二進制文件 (支持 Linux、Mac OS 和 Windows)。您能夠將其與現有的 CI 系統集成。展望將來，咱們準備加強這個服務，讓其能夠下載除最新版本以外的已棄用版本，從而讓開發者能夠更輕鬆地復現歷史測試結果。
• Android Emulator Docker 鏡像生成器 – 有了 Android 系統鏡像和模擬器還只是開始。運行環境、驅動程序和預安裝的系統依賴項，咱們將 Docker 鏡像生成器打包放在了一塊兒，這些內容組合在一塊兒纔是 Android 模擬器的完整運行環境。啓動 Docker 鏡像後，1) 端口轉發和 ADB 以及 2) gRPC 和 WebRTC，使與模擬器的交互成爲可能。目前，Docker 鏡像生成器被設計爲在 Linux 上運行。咱們也在想辦法支持 Mac OS 和 Windows，敬請期待！

爲了提升復現能力，底層的 Dockerfile 模板使所需的命令行標識和系統依賴性更加明確 (而且能夠經過從中構建 Docker 鏡像來重現)。對於硬件加速，請注意傳遞給 run.sh 的 --privileged 標識；咱們假設在運行模擬器時可使用 CPU 加速，而且須要 --privileged 來運行啓用了 CPU 加速 (KVM) 的容器。

有關如何建立和部署 Android 模擬器鏡像的更多詳細信息，請參閱文檔裏的 README 文件。

可調試性

當模擬器正在運行一個測試並且測試失敗時，您可能難以介入正在運行的測試環境並診斷錯誤。診斷一般須要與虛擬設備直接交互，爲此咱們提供了兩種直接互動的機制:

• ADB
• 遠程流

對於 ADB，經過將特定端口從 Docker 轉發到主機，咱們支持運行全部命令 (例如 logcat 和 shell)。當前使用的端口爲 5555，咱們須要收集更多反饋，並就如何最好地在不一樣容器間分配端口進行更深刻的研究。

遠程流

先作一個安全說明: 使用遠程流時，一旦啓動服務，任何能夠在 80/443 端口上鍊接到您的計算機的人均可以與模擬器進行交互。所以在公共服務器上運行遠程流時請務必注意這一點！

您可使用遠程流在容器中運行模擬器，其交互能力與本地運行時一致。在容器中運行模擬器，您就能夠更輕鬆地調試使用 ADB 命令難以發現的問題。您可使用支持 WebRTC 和 gRPC 的瀏覽器來訪問模擬器，WebRTC 用於串流視頻，而 gRPC 則將鼠標和鍵盤事件發送到模擬器。遠程流須要三個容器:

運行最新模擬器的容器 一個帶有 Envoy web proxy (用於 gRPC) 的容器 一個配備 nginx 的容器，用於運行 React web 應用

您可使用 docker-compose 將 Docker 容器組合在一塊兒，如 README 中所述 。容器綁定到端口 80 和 443，所以請確保您沒有運行 Web 服務器。若是將瀏覽器指向主機，咱們將提供一個自簽名證書。將瀏覽器指向主機時，您應該會看到相似下圖的內容:

再次提醒，任何能夠鏈接到主機的人均可以與模擬器進行交互。所以，在公共服務器上運行時要當心！

測試、更多的測試

測試工做彷佛會把開發時間拖得更久。可是，正如許多經驗豐富的開發者所看到的那樣，隨着項目的代碼變得更多更復雜，良好的自動化測試其實能夠提升開發速度。持續測試存在的目的，就是讓您能夠肯定每個更改都不會對應用形成負面影響。

您對 CI 和持續測試有什麼心得和疑問？歡迎在評論區和咱們分享。

點擊這裏進一步瞭解 Android 模擬器