ARCore 兩年使用心得：從閃動漂移到真正融入工作流

ARCore 是什麼

ARCore 是 Google 推出的 Android 端 AR 底層服務，正式名稱叫 Google Play Services for AR。它不是你在手機上打開就能玩的獨立 App——去 ARCore官網 可以看到完整的支援機型清單。它跑在系統底層，為其他應用提供運動追蹤、環境理解、光線估計和錨點定位這些核心 AR 能力。

簡單說，手機掃一掃就能把虛擬物體釘在桌面上、在空間裡遊走、或者跟朋友在同一個房間裡共享同一段 AR 體驗——這些背後的視覺同步和空間計算，都是 ARCore 在做的事。如果你是開發者，它是你在 Android 上做 AR 的起點；如果你只是用戶，它大概率已經在你手機上跑著了，只不過你沒意識到。

安裝

ARCore 的安裝方式跟普通 App 不太一樣。它本質上是 Google Play Services 的一個模組，絕大多數情況下透過 Google Play 商店自動更新，不需要手動下載 APK。不過在部分沒有 GMS 認證的 ROM 上，可能需要單獨去 ARCore下載 最新版本。但有幾個坑值得留意。

首先，裝置必須是 Google 官方列在支援清單裡的機型——不是所有 Android 手機都能跑，尤其是部分入門級機器或沒有 GMS 認證的國產 ROM，即使硬裝了也可能跑不起來。檢查裝置相容性是寫程式時第一個要做的事：checkAvailability() 會回傳五種狀態，從「完全就緒」到「硬體不支援」都有，不能假設每台機器都能進 AR 功能。

其次，如果裝置支援但還沒安裝，requestInstall() 會彈出 Google 官方的安裝對話框，讓用戶確認後自動下載。這個流程是異步的，要等生命周期回調確認安裝完成，才能建立 AR Session。筆者曾經在一個專案裡忘了等回調就直接初始化 Session，結果在部分機器上直接崩潰，卡了好幾天才定位到是這個時機問題。

最後，版本不能硬編碼。Google 幾乎每個月都在更 ARCore，新版本會修正 SLAM 漂移、新增 Geospatial API、改善追蹤穩定性。寫程式時永遠用 requestInstall() 讓 Google 自己處理版本要求，不要假設用戶已經裝了某個特定版本——這筆者踩過兩次坑，一次是舊版本 Depth API 行為變了，一次是 Cloud Anchors 的 TTL 管理在 1.20 之後改了。

兩年前怎麼看上 ARCore

兩年前筆者第一次碰 ARCore，是因為公司想做一個 Android 端的 AR 家具預覽 Demo，要跟 iOS 的 ARKit 對標。那時候查了一圈資料，發現 Android 上幾乎只有 ARCore 一個像樣的選項——別說跨平台 Cloud Anchors，光是基本的運動追蹤和平面檢測，其他方案要麼精準度差一截、要麼相容性窄到隻支援旗艦機。

當時的考量很實際：Google 親兒子、長期支援、API 設計也算乾淨，Unity AR Foundation 直接內建，不用自己寫殼。就這樣入坑了，沒想到一做就是兩年，前前後後參與了不下十個專案——從 AR 家具預覽、多人 AR 繪畫、到 Geospatial API 做位置打卡活動。

變化：哪些越用越順手

Cloud Anchors 跨平台。 這兩年最讓人開心的進展就是 Cloud Anchors 在 Android 和 iOS 之間的互通終於穩定了。筆者第一次寫跨平台共享的時候，Android 托管的 anchor 在 iPhone 上解析經常飄移半米以上，根本沒法用。現在同一個 anchorId 兩邊解析後的位置通常能精準到幾釐米，朋友們各拿各的手機在同一張桌子上畫 3D 塗鴉，每個人看到的內容都來自所有人的共同創作，體驗已經很接近現場 AR 了。

Geospatial API + VPS。 早期做位置綁定的 AR 內容只能用 GPS，精度大概十米級，放在室內根本是瞎蒙。後來 Google 把 VPS（Visual Positioning Service）整合進 ARCore，利用街景圖像的特徵點對位，室內精度也能到米級。筆者做過一個商場 AR 行銷活動，就是用 Geospatial API 在商場特定位置放虛擬優惠券，走到附近的用戶手機會自動觸發——這個體驗沒有 VPS 根本做不起來。

Depth API 進步很大。 早期的深度感測依賴搭載結構光或 ToF 鏡頭的旗艦機，絕大多數裝置不支援。後來 Google 推出了基於單目相機的 Depth API，用 AI 估算深度，雖然精度不如專用硬體但勝在覆蓋面廣——現在中階機器也能做出虛擬物體被手指擋住、或放在桌子上被杯子遮住的互動效果。

惱人：哪些一直沒解決的問題

SLAM 跟踪丟失。 這是筆者兩年來吐槽最多的點。ARCore 用的是純本地 SLAM，沒有回環檢測，也沒有全局定位修正——用戶在一個區域待久了、或者走出了當初掃描的範圍，跟蹤就會慢慢飄。素材包裡提到的「累積漂移」不是極端情況，是每個專案都要面對的日常問題。筆者曾經做過一個 20 分鐘的長時 AR 體驗，結束時虛擬物體居然飄了兩米多，用戶以為應用壞了。

解決辦法？坦白說沒有根治方案。回環檢測 Google 遲遲沒在 ARCore 裡加，Geospatial VPS 雖然能定期重定位但需要網路且只在有街景覆蓋的區域好用。現在筆者只能靠寫程式時在 TrackingState 切換到 PAUSED 時淡化虛擬物體引導用戶慢慢掃描，STOPPED 時乾脆隱藏所有 AR 內容讓用戶重置 Session——算是被動補鍋。

純白牆面和光滑桌面。 這個問題 SLAM 天生的——沒有特徵點的地方 SLAM 根本建不了地圖。纯白牆、玻璃桌面、漆黑房間，這三種場景下 ARCore 幾乎必然丟失。筆者現在做任何 AR 應用都會在首次進入時強制引導用戶掃描整個房間，並在畫面角落放一個小指示器告訴用戶當前跟蹤品質是綠色、黃色還是紅色——這是兩年來從無數次用戶反饋裡磨出來的教訓。

快速運動。 用戶快速揮手機、或者裝在快速移動的設備上，畫面模糊導致特徵點無法跨幀匹配，跟蹤秒掛。筆者做過一個 AR 騎行導航的 Demo，結果發現裝在自行車把手上跟蹤根本穩不住——後來不得不棄坑，改成靜態 AR 體驗。

每個專案都會複製貼上的防呆代碼

兩年下來筆者積累了一套 ARCore 專案的標準防呆，納入 工作流 每次開新專案都直接貼過來：

首先是裝置檢查。checkAvailability() 可能回傳 UNKNOWN_CHECKING——Google 會在後台拉裝置相容性列表，首次呼叫需要幾百毫秒。筆者加了一個 100ms 延遲重試，最多三次，確保檢查結果穩定再往下走。

然後是跟蹤狀態監聽。每 30 秒檢查一次 Geospatial VPS 精度，如果 altitudeAccuracy > 5f 就提示用戶走到視野開闊處。TrackingState 切換到 PAUSED 時把虛擬物體 alpha 降到 0.5，STOPPED 時直接隱藏——這套邏輯寫成一個 TrackingRecovery 類，每個專案都 include。

最後是 App Store 審核要點。如果是跨平台發布，iOS 端的 Cloud Anchors 會上傳相機畫面到 Google Cloud，Info.plist 的權限描述必須寫清楚「為什麼需要」，App Privacy 標籤也要如實填寫。筆者第一次提交 App Store 時因為 Info.plist 寫了模糊的「需要用相機」被打回，改成「使用相機來建立增強現實體驗：掃描周圍環境、識別物體、放置虛擬內容」才過審。

觀感修正：當初高估和低估了什麼

剛入坑時筆者以為 ARCore 的跨平台能力會讓 Android 上的 AR 應用和 iOS 一樣好用，後來才發現兩邊裝置硬體的差異不可忽視——iPhone 的 IMU 精度統一校準，SLAM 通常更穩定；Android 各廠商的感應器參差不齊，低端機的跟蹤體驗真的差一截。這不是 ARCore 的鍋，是 Android 生態的硬傷。

同時筆者也低估了 AI工具 驅動的 Geospatial API 的價值。剛開始覺得 VPS 只是個「能定位」的附加功能，後來做了商場 AR 行銷才意識到——沒有 VPS，位置綁定的 AR 內容根本做不起來。室內 GPS 精準度不夠，室外又會受信號干擾，VPS 是目前唯一可行的方案。

結論

兩年用下來，ARCore 沒有讓我失望也沒有讓我驚喜。Google 在穩定性和新功能上持續投入，Cloud Anchors 和 Geospatial API 是最亮眼的兩個；但 SLAM 沒有回環檢測、跟蹤丟失的根本問題遲遲沒解、低端 Android 裝置支援依舊參差——這些是每次開發都要面對的煩惱。

筆者不會卸載它——它已經是 Android 上做 AR 的事實標準，沒有替代品。但如果哪天公司要做一個需要長時間穩定跟蹤、或對精度要求特別高的專案，筆者會認真考慮要不要繞開 ARCore，找找更專業的工業級方案。畢竟兩年下來，那些每次都要重複踩的坑，真的有點膩了。

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