性能考虑因素
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
要打造引人入胜的 AR 用户体验,您的支持 AR 功能
性能。
确保您的应用:
- 感觉可响应用户输入,包括触摸手势和设备
。
- 以合理且一致的帧速率渲染。一般用户
建议采用一致的帧速率
变量和更高值。
- 最大限度地节省电池电量,让用户能够将设备用于其他用途
或延长 AR 体验的用时。
- 在呈现 AR 生成内容时打造引人入胜的 AR 体验
能够与自然环境融为一体
环境
若要打造更具吸引力的 AR 体验,请在设计时遵循以下最佳
做法。
尽管可以使用世界空间坐标放置 3D 内容,
始终尽可能使用锚点。
ARCore 可确保锚点相对于现实世界保持稳定,即使
底层世界空间坐标在 ARCore 触发时,
更新自身对世界的理解。
没有连接到锚点的虚拟对象偶尔看起来
跳跃,并且相对于环境而言不会显得稳定。这样一来,
AR 体验对用户的吸引力会降低。
支持 ARCore 的设备涵盖广泛
硬件和性能特征设备性能可能会因以下因素而发生变化:
- 设备 CPU/GPU、时钟速度
- 可用内存和带宽
- 摄像头/IMU 传感器质量
- 其他硬件差异
- 操作系统和设备驱动程序
我们建议您在
代表了您的用户将会使用的设备
在不使用时停用 CPU 密集型功能
某些 ARCore 功能在启用时会增加 CPU 利用率。考虑
当您的 AR 体验不需要时停用这些功能
。这将为您的应用提供更多 CPU 周期,并改进
散热性能和电池续航时间。
目前,当 Instant Placement 和/或
已为当前会话启用Augmented Images。关注这些活动
提高 CPU 利用率效率的准则:
监控设备热
在开发和质量检查测试期间,您可以使用 Android 的 Thermal API 来监控
并跟踪应用在设备上的表现
确保使用应用的正式版正式版(而不是开发版或
应用的 qa build 可能会具有不同的运行时性能
特征。
识别 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 资源竞争
动作跟踪的必需参数。
预先创建增强图像数据库
如果可能,请在开发时预先创建您的增强图像数据库。
如果需要在运行时或以动态方式创建增强图像数据库
向现有数据库添加图片时,请确保将图片添加到背景中
以免阻塞主界面线程
限制请求的摄像头视频流数量
使用 Java 共享相机时,应用可以执行以下操作:
请求额外的 CPU 或 GPU 图像流。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-26。
[null,null,["最后更新时间 (UTC):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."]]