ARDK 2.3.0 performance on Android devices

  • Issue category: Real-time Mapping-Depth
  • Device type & OS version: Android 10/11/12
  • Host machine & OS version: Windows
  • Issue Environment : On Device
  • ARDK version: 2.0.1/2.3.0
  • Unity version: 2021.3.11f1


After reading this post by @Manos_Tsotros , I decided to try ARDK 2.3.0 myself. However, the test result was not satisfactory, since I am still getting around 20% FPS less with ARDK 2.3.0 vs ARDK 2.0.1.

I checked the Unity profiler with both ARDK versions in the same app. This is what I got for the same meshing scene, with an Adreno 650 device (meets ARDK’s system requirements) targeting 60FPS:

  • ARDK 2.0.1: stable 60 FPS, with the render thread spending most of its time in Gfx.PresentFrame, which, according to Unity’s doc, means that “the app is waiting for the GPU to render and present the frame, which includes waiting for VSync”. Looking at the CPU Vsync Usage, my understanding is that the app has plenty of time to render at those 60FPS.

  • ARDK 2.3.0: the app strugles with the 60FPS, and the Render Thread spents most of its time in Camera.Render/ARCore Update driver. Again, according to Unity’s documentation, spending time in the Camera.Render process means that “your application is CPU-bound and might be spending too much time sending draw calls or textures to the GPU.”

ARDK2.0.1 was using ARCore 1.14. Meanwhile, ARDK 2.2.0/2.3.0 are using ARCore 1.32. Do you think the ARCore upgrade could be the source of this problem? Any other ideas what might be causing this difference in performance?

Additionally, I am still unable to run ARDK’s contextual awareness features on theoretically capable devices, as I pointed out in this post. I mention it here just in case it also has some relation with this issue.

Thanks in advance for your help.


I will be taking a look at this performance issue and will be getting back to you once I have more information.

In the meantime, if you are running an ARDK example when you use the profiler, can you provide the example? If this isn’t an ARDK example, can you just provide the features that you were running? By the looks of the information you provided, you’re using Depth, is there anything else you’re using?

Hi Jesus,

This is not an ARDK example, but I can provide you with anything you need to test it. Just let me know what can help.

Regarding ARDK features, I am using the following components:

  • AR Session Manager
  • AR Camera Prefab (Camera + Position Helper + Rendering Manager)
  • AR Depth Manager with the following configuration:
  • AR Mesh Manager with the following configuration:

    OmigariMeshColliderChunk is different from ARDK’s MeshColliderChunk. I can provide it if you need it. PaintableMaterialExternalMaskBuffer is not used by the component when meshing is performed, so it shouldn’t affect.

There are also networking managers in the scene, but they are not initialized during the scan. Other than a couple of UI elements, nothing else is loaded in the scene either.


Hi Jesus,

I just discovered that overriding the ARCore min_apk_version that is defined in the manifest of the the arcore library bundled with ARDK:

<meta-data   android:name="" android:value="221020000" />

with the value that was configured in the arcore_client of the ARDK2.0.1 version:

<meta-data tools:replace="android:value" android:name="" android:value="191106000" />

magically solves the issue in ARDK2.3.0. This is what the profiler looks like now:

I just made the discovery totally by chance, while I was working on a different thing, but I have no idea why that value might influence ARDK’s performance so much. I thought its goal was simply to define a minimum version for the Google Play Services for AR apk installed on the phone (the last version in case of my phones, so that shouldn’t be an issue). Might this modification enforce to not use some heavy features of the last ARCore versions? To be honest, I’d really like to understand it. I hope you can find an explanation and confirm if this workaround is a valid solution.

I haven’t tested all the ARDK features with this workaround yet, but I’ll let you know if something doesn’t work as expected.

1 Like

Hi @Jesus_Hernandez ,

Have you found out anything about this issue? Do you need more info?


Sorry for the delay. The issue is still being discussed/ looked into but I will try to get you and update by Monday, there is still a bit of discussion going around about the ARCore versions.

1 Like


The next version of ARDK will be addressing some changes with ARCore which should fix these performance issues you’re experiencing. I don’t have a solid timeline for when it will be out but please keep an eye out. If the next release does not address the issue, please submit a new topic linking this one and if performance has changed in any way please detail how as well (it worsened, it improved but not as expected, etc…)

Sure, I’ll check it once the new version is out. Do you know if the issue of (theoretically capable) phones failing ARWorldTrackingConfigurationFactory.CheckDepthEstimationSupport() or ARWorldTrackingConfigurationFactory.CheckMeshingSupport() will also be addressed with this fix, or that’s not related?

Hi @Jesus_Hernandez,
I’ve just seen the new ARDK release. I didn’t test it yet, but I can anticipate that the performance is going to be OK. I observe bad performance when arcore min_apk_version is > 203000000, but the value defined in the arcore.aar included in the new ARDK release (2.3.1) is 202940000, so it should work fine if that’s the only change vs 2.3.0. Anyway, I will try to test it properly soon and let you know in case I notice any issue.

Sounds good!

We’re also still looking into your other question about phones that are theoretically capable of running ARDK failing support checks :slight_smile:

This topic was automatically closed 2 hours after the last reply. New replies are no longer allowed.