共享LiteRT執行環境，讓應用驗收多了一隻時鐘

Google在2026年10月28日的公告中，為LiteRT的Play服務共享執行環境引入CompiledModel GPU支援；執行環境可分階段更新，不必等待應用發布。對應用團隊來說，關鍵變化是多出了一隻發布時鐘。

本文討論這種交付關係，而不是提供新的效能測試。由應用之外的元件承擔維護，可以減少重複工作。但使用者安裝的應用版本，已不能獨自說明執行環境中發生過哪些相關變化。驗收依據需要回答測了什麼、在哪裡測、何時測，而不能只留下「這個組建通過了」的結論。

使用者需要的是體驗，不是一次成功呼叫

設想一款替商品照片去除背景的手機工具。使用者希望在離開編輯頁面之前拿到可用圖片，開發者的測試卻可能只檢查模型是否傳回有效張量。兩種檢查都有價值，但回答的不是同一個問題：計算成功，仍可能意味著等待過久、視覺結果不穩定，或操作流程銜接得不好。

CompiledModel指南列出17.0.0相依套件，並提供明確同時設定GPU與CPU的方式，在GPU加速不可用時回退到CPU。因此，回退路徑應作為一種產品體驗接受檢驗，而不能被當作所有裝置提供相同服務的證明。

對上述假想編輯器而言，較慢路徑處理一張靜態照片也許可以接受，持續即時預覽卻未必合適。這是用來解釋設計取捨的例子，不是LiteRT實測結論。驗收標準取決於產品承諾的互動方式。如果持續處理不合適，應用可以考慮提供靜態圖片模式，但前提是這個替代模式真的被設計、實作和測試過。傳回了結果，不能替代團隊決定使用者應該看到怎樣的體驗。

留下能夠解釋變化的證據

我們建議把應用組建、模型檔案、輸入前處理、裝置與系統資訊、設定的執行路徑、觀察日期和輸出測量聯繫起來。這是一套編輯部提出的證據思路，不是Google認證要求。執行環境資訊只能透過受支援的介面取得；介面沒有揭露的識別碼，應作為證據缺口保留，不能憑空補成一個版本號。

這樣的紀錄首先用於排除輕率歸因。同一個模型在一次應用更新後看起來變差，團隊不應立即認定共享元件出了問題。圖片縮放、後處理以及裝置條件，都可能改變比較結果。用受控樣本重複觀察，比拿兩個互不相關的使用者回報直接比較，更有助於判斷原因。反過來，只凍結應用二進位檔，也不能證明周圍所有條件都沒有變化。

證據還需要保留失敗的含義。一次測試未達到體驗要求，可能意味著某種使用方式暫時不應開放，並不自動意味著整個模型不可用。把問題定位到具體互動和裝置條件，可以避免一邊過度承諾相容，另一邊又因為局部失敗而否定所有場景。驗收的價值在於縮小不確定性，而不只是產生一個綠色標記。

涵蓋範圍不必等於窮舉所有組合。更有用的做法，是說明哪些組合已經支持產品承諾，哪些仍沒有足夠依據。團隊可以優先驗證功能不可或缺的裝置與互動，再將其餘組合明確留在尚未驗證的範圍內。這比沒有重現條件的「全面相容」標籤更誠實，也更便於後續補充測試。

恢復方案要符合實際控制權

當元件分開交付時，不應假設回退應用組建就能讓整個環境回到原狀。這是維運層面的推論，不是在聲稱Google提供或拒絕某個特定回復介面。團隊需要分清自己真正掌握的控制手段，以及哪些恢復動作依賴另一個散布方。

應用層可以考慮暫時關閉選用功能，或提供已經測試過的替代流程。但這些不是LiteRT自動附送的能力，執行環境錯誤也不會憑空生成第二套實作。提前設計這些回應，才能明確誰有權啟用、什麼證據足以恢復正常體驗。恢復於是成為有工程證據支持的產品決定，而不是一句無法兌現的「全部回復」。

這種區分也影響團隊內部的責任安排。維護模型的人未必負責手機介面的等待狀態，管理發布的人也未必能控制外部散布節奏。若各自只確認自己的局部檢查通過，最終可能沒有人驗證完整使用者旅程。把驗收紀錄交給能夠對整段體驗作決定的人，比增加一個孤立的技術指標更重要。

遷移之前還有架構選擇。目前官方概覽要求需要NPU加速、自訂運算，或必須在沒有Google Play服務的裝置上執行的應用使用獨立版LiteRT。散布要求因此應當在選型時進入討論，而不是接入完成後才發現它限制了目標使用者。

看重集中維護、又能持續驗證體驗的團隊，可能適合共享執行環境。另一些團隊的部署條件，則可能要求更自包含的交付方式。兩者都不能免除測試，只是把不同部分的工作交給不同的責任方。判斷依據應是實際部署與恢復需求，而不是抽象地認定共享或打包總有一種更先進。

這次發布最值得推動的，是把責任寫得足夠具體：Google維護共享執行元件，應用仍對客戶能否正常使用某項功能作出承諾。可靠的採用方式，需要用附有日期、可重現的證據連接這兩端，並讓恢復路徑真實存在於產品之中，而不是把一次接入成功當成相容性已經永久解決。