效能注意事項
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
如要打造引人入勝的 AR 使用者體驗,請務必支援 AR 技術
表現優異。
確保應用程式符合以下條件:
- 對使用者輸入內容 (包括觸控手勢和裝置) 做出回應
動作
- 以合理且一致的影格速率轉譯。一般使用者
偏好一致且較低的畫面更新率
變數以上。
- 盡可能降低電池耗電量,讓使用者將裝置用於其他用途
或長時間與 AR 互動。
- 在 AR 生成內容顯示位置,打造引人入勝的 AR 體驗
以相對於環境的方式穩定,
環境。
想要打造更引人入勝的 AR 體驗,設計時請採用以下最佳做法
遵循最佳做法
雖然您可以使用世界空間座標放置 3D 內容,
一律盡可能使用錨點。
ARCore 可確保錨點與世界相對應
基礎世界空間座標發生變化,且 ARCore 有時可能會隨著時間的推移而逐漸停止
讓更多人對這個世界更加瞭解。
未附加至錨點的虛擬物件有時會出現
跳躍,而且不會與環境相對保持穩定。這樣一來
AR 體驗對使用者來說較不吸引人,
ARCore 支援的裝置涵蓋各式各樣的裝置
硬體和效能特性裝置效能可能出於下列原因:
- 裝置 CPU/GPU、時脈速度
- 可用記憶體和頻寬
- 相機/IMU 感應器品質
- 其他硬體差異
- 作業系統和裝置驅動程式
建議您使用不同類型的裝置來測試應用程式
代表使用者要使用的裝置
在不使用時停用會耗用大量 CPU 的功能
某些 ARCore 功能在啟用時可提高 CPU 使用率。您可以考慮使用
當你的 AR 體驗不需要時,停用這些功能
具體做法是指示 Kubernetes 建立並維護
一或多個代表這些 Pod 的物件這麼做可為應用程式提供額外的 CPU 週期,並改善
溫度和電池續航力
目前,當 Instant Placement 和/或
目前的工作階段已啟用「Augmented Images」。請按照這些
提升 CPU 使用率效率的指南:
監控裝置溫度
在開發和品質確保測試期間,您可以使用 Android 的熱力 API 監控
並在裝置上追蹤應用程式的效能
請務必使用「正式版」建構應用程式 (而非開發或
qa 版本可能具有不同的執行階段效能
瞭解 ARCore CPU 飢餓
啟用 ARCore 工作階段時,應用程式必須共用有限的行動裝置 CPU 和 GPU
使用 ARCore。受到 CPU 限制的應用程式可能會與 CPU 資源競爭
必須使用動作追蹤功能。
為了驗證 ARCore 的
同時本地化和製圖
(SLAM) 正常執行,請確認「VIO 頻率較低」訊息
不會顯示在 Android 裝置記錄中:
adb logcat | grep 'VIO frequency low'
避免 ARCore CPU 飢餓
啟用 ARCore 工作階段時,應用程式必須共用有限的行動裝置 CPU 和 GPU
使用 ARCore。受到 CPU 限制的應用程式可能會與 CPU 資源競爭
必須使用動作追蹤功能。
預先建立擴增圖片資料庫
請盡可能在開發期間預先建立擴增圖片資料庫。
是否需要在執行階段或動態
將圖片新增至現有資料庫,且務必在背景新增圖片
避免阻斷主 UI 執行緒。
限制要求的攝影機串流數量
使用 Java 共用相機時,應用程式可以
要求額外的 CPU 或 GPU 映像檔串流。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-07-26 (世界標準時間)。
[null,null,["上次更新時間:2025-07-26 (世界標準時間)。"],[[["\u003cp\u003eAR-enabled apps need to be responsive, maintain consistent frame rates, minimize battery drain, and ensure AR content is stable and realistic within the environment for a compelling user experience.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers should utilize anchors for stable AR content placement, consider device-specific performance variations, and disable CPU-intensive AR features when not in use to optimize app performance.\u003c/p\u003e\n"],["\u003cp\u003eMonitoring device thermals, addressing potential ARCore CPU starvation by minimizing resource competition, and pre-creating Augmented Images databases can help ensure smooth AR experiences.\u003c/p\u003e\n"],["\u003cp\u003eLimiting the number of requested camera streams and disabling CPU-intensive features like Instant Placement and Augmented Images when not needed can further enhance app performance.\u003c/p\u003e\n"]]],[],null,["# Performance considerations\n\nTo create compelling AR user experiences, it's important that your AR-enabled\napp performs well.\n\nEnsure that your app:\n\n- Feels responsive to user input, which includes touch gestures and device motion.\n- Renders at a reasonable and consistent frame rate. Users generally prefer frame rates that are consistent and lower over frame rates that are variable and higher.\n- Minimizes battery drain, enabling your user to use their device for other tasks throughout the day, or engage longer with your AR experience.\n- Constructs a compelling AR experience where AR-generated content appears stable relative to the environment, and realistically blends in with the environment.\n\nPerformance best practices\n--------------------------\n\nTo create more compelling AR experiences, design with the following best\npractices in mind.\n\n### Use anchors to improve tracking performance\n\nAlthough it's possible to place your 3D content using world-space coordinates,\nalways [use an anchor whenever possible](/ar/develop/anchors).\nARCore ensures that anchors appear stable relative to the world, even though the\nunderlying world-space coordinates change and may jump over time whenever ARCore\nupdates its understanding of the world.\n\nVirtual objects that aren't attached to an anchor will occasionally appear to\njump and will not appear stable relative to the environment. This can make the\nAR experience less compelling for users.\n\n### Consider device-specific performance characteristics\n\n[ARCore supported devices](/ar/discover/supported-devices) cover a wide range\nof hardware and performance characteristics. Device performance can vary due to:\n\n- Device CPU/GPU, clock speed\n- Available memory and bandwidth\n- Camera/IMU sensor quality\n- Other hardware differences\n- Operating system and devices drivers\n\nWe recommend testing your app on different classes of devices that are\nrepresentative of the devices your users will use.\n\n### Disable CPU intensive features when not in use\n\nCertain ARCore features increase CPU utilization while enabled. Consider\ndisabling these features during times when your AR experience doesn't require\nthem. This will make additional CPU cycles available to your app, and improve\nthermal performance and battery life.\n\nCurrently, ARCore CPU utilization increases when **Instant Placement** and/or\n**Augmented Images** is enabled for the current session. Follow these\nguidelines to increase CPU utilization efficiency:\n\n- **Instant Placement** should be disabled once full tracking has been\n established. The feature can be disabled in the session config.\n\n- **Augmented Images** should be disabled whenever the feature is not required\n for your AR experience. To disable Augmented Images, configure a `null` or\n empty Augmented Images database in the session config.\n\n### Monitor device thermals\n\nDuring development and QA testing, you can use Android's thermal APIs to monitor\nand track performance of your app on device.\n\nMake sure to use a *production* build of your app (and not a *development* or\n*qa* build of your app that might have different runtime performance\ncharacteristics.\n\n- [`PowerManager#getCurrentThermalStatus()`](https://developer.android.com/reference/android/os/PowerManager#getCurrentThermalStatus())\n (API level 29)\n\n- [`PowerManager#getThermalHeadroom(int)`](https://developer.android.com/reference/android/os/PowerManager#getThermalHeadroom(int))\n (API level 30)\n\n### Identify ARCore CPU starvation\n\nWhen an ARCore session is active, your app must share limited mobile CPU and GPU\nresources with ARCore. CPU bound apps can compete with the CPU resources\nrequired for [motion tracking](/ar/discover/concepts#motion_tracking).\n\nTo verify that ARCore's\n[simultaneous localization and mapping](https://en.wikipedia.org/wiki/Simultaneous_localization_and_mapping)\n(SLAM) is able to run normally, verify that the \"**VIO frequency low** \" message\ndoes *not* appear in the Android device logs: \n\n adb logcat | grep 'VIO frequency low'\n\n### Avoid ARCore CPU starvation\n\nWhen an ARCore session is active, your app must share limited mobile CPU and GPU\nresources device with ARCore. CPU bound apps can compete with the CPU resources\nrequired for [motion tracking](/ar/discover/concepts#motion_tracking).\n\n### Pre-create the Augmented Images databases\n\nWhen possible, pre-create your Augmented Image databases at development time.\nIf it's necessary to create Augmented Image databases at runtime or dynamically\nadd images to an existing database, make sure to add images in a background\nthread to avoid blocking the main UI thread.\n\n### Limit the number of requested camera streams\n\nWhen using [Java Shared Camera](/ar/develop/java/camera-sharing), apps can\nrequest additional CPU or GPU image streams."]]