Closed RVerhoef closed 4 years ago
tdmowrer
commented
4 years ago This sounds to me like you might be hitting the JIT compiler (which wouldn't apply on iOS since it's all IL2CPP).
Could you attach a profiler capture to see where the time is going? Also, try building for Android with the IL2CPP backend to see if it makes a difference (since that would all be AOT compiled).
RVerhoef
commented
4 years ago This sounds to me like you might be hitting the JIT compiler (which wouldn't apply on iOS since it's all IL2CPP).
Could you attach a profiler capture to see where the time is going? Also, try building for Android with the IL2CPP backend to see if it makes a difference (since that would all be AOT compiled).
Hey tdmowrer, thanks for giving me some directions! I'll give it a look, so far I haven't been able to discern a clear cause. However I'm already building the Unity3D Application for Android with the IL2CPP as my scripting backend, so I assume it wouldn't be the JIT compiler then?
tdmowrer
commented
4 years ago Correct, il2cpp is ahead of time (AOT) complied. That was just a guess, however. If you want to know where the time is being spent, it should be obvious from the profiler.
Sightwalker
commented
3 years ago This is the exact same problem I was having.
At first it was happening only once in a while, but as I went on upgrading my code the freezing happened almost all the time. I don't know what you were doing in your project at all but after reading this thread and going through some trial and error, I found out that disabling some coding (that was checking if TrackingState.None was true and then setting the spawned object SetActive to false) did the trick. It didn't freeze on detecting a target image anymore.
I think it's valuable to add that on the period of trial and error, I removed the ARTrackedImageManager component from the GameObject and instead of using GetComponent once playing the scene to get it, I decided to add at it during the Awake method. Doing only this somehow decreased the rate of the freezing from almost always to a range of 2/3 - 50% of the time.
The builds were tested on a Samsung Galaxy Tab S4, made with ARFoundation 4.0.8 and Unity 2020.1.3f1. I'm still researching the bug and working on the development of the project, maybe I'll find something more about it in the future but that's what I got for now. I hope it helps
Sightwalker
commented
3 years ago Okay. After meddling with the code I found out that my problem was related with using Coroutines.
If you change the TrackingState of an image target while using it in a coroutine function the app will freeze.
In my case I am downloding an AssetBundle when I detect an Image Target. In my tests the app would freeze instantly if I disabled the GameObject when it was downloading if detecting the trackingState of the target was None. It became more clear when I changed the condition to detect if trackingState was Limited. In this case, the app would only freeze if it lost the reference of the Image Target was lost. I worked around it making a bool that checked if the download was over, and now the object can only be disabled if the download is over. Now the app doesn't freeze anymore.
Specs are the same as before (Samsung Galaxy Tab S4, ARFoundation 4.0.8 and Unity 2020.1.3f1). I later updated ARFoundation to 4.0.9 and it also worked fine.
tdmowrer
commented
3 years ago If you change the TrackingState of an image target while using it in a coroutine function the app will freeze.
How are you changing the tracking state? That is a read-only property.
Can you explain what you mean by "freeze"? Is that a temporary stall or a permanent freeze? This (closed) issue was assumed to be about a performance spike. What you describe sounds different; if so, please open a new issue.
Sightwalker
commented
3 years ago If you change the TrackingState of an image target while using it in a coroutine function the app will freeze.
How are you changing the tracking state? That is a read-only property.
Can you explain what you mean by "freeze"? Is that a temporary stall or a permanent freeze? This (closed) issue was assumed to be about a performance spike. What you describe sounds different; if so, please open a new issue.
Sorry for the confusion. What I meant is when the tracking state changes by recognizing an image target.
The "freezing" is permanent. The odd part about it is that when it freezes the screen/app, a square with "glitched bits of color" appears at the bottom right of the screen. Those glitched bits change colors as if it was still trying to show up the contents of the camera and it's the only thing that doesn't freeze.
The original poster didn't mention anything about this square, but other than that their description of the problem was exactly what happened with me:
The camera feed will freeze and all code running on the main thread will stop executing. The app itself doesn't seem to crash however.
The app didn't crash at all with me as well. It just showed a frozen screen except for that new square that appeared. Unfortunately the app is only at my worksite's device, so I'll only be able to post a screenshot tomorrow. If you think those two things are unrelated, I can open a new issue.
Description When running a Unity3D application on Android, using AR Foundation, the application experiences randomly freezes when detecting a tracking image. The camera feed will freeze and all code running on the main thread will stop executing. The app itself doesn't seem to crash however.
The issues occurs both when using a mutable image library, or when a predefined library is set up in the editor and used in the build. The issue doesn't seem to have a very clear cause, it could happen after detecting 10 tracking images or when you're detecting the first one. Trying to debug the application through the monitor application of Android Studio or through Visual Studio's debug function doesn't seem to give any results of warnings or errors.
This issue doesn't occur when running the application on iOS devices, probably because under the hood it's AR Kit running the show, not AR Core.
Additional information Builds were tested on these devices:
Motorola One Macro, Android Version 9 One Plus 5, Android Version 10
Builds were made with AR Foundation version 4.1.0 on Unity version 2019.4.6f1. The issue seems less persistent on the Motorola then on the One Plus.