I’m making a 2D Android game and when I test my game on a physical device, it takes a pretty long time to start.
I can’t seem to track down the exact cause because when I click on the app icon, a black screen appears for about 15 seconds then the unity logo appears. After the unity logo fades out, it waits another 5 seconds, then the first scene appears.
This is odd behavior that I’ve never experienced before.
What could be causing this?
How can I speed up the loading time?
Here are seven optimizations you can take a look at:
1.) Have one simple unity loading scene, with which you handle the loading of all other scenes. There you can easily add custom animations/progress bars or other logic and you can be sure, that loading the first scne does not take forever
2.) Switch your build target from Mono to IL2CPP if you haven’t done that already. I have a strong loading time boost for IL2CPP on android. Oftentimes I still use mono for development, since it just is quicker in building the app.
3.) Check your Preloaded Assets Array in Project Settings->Player ->Other Settings. All those assets will be loaded before anything else happens. Especially shaders can take a long time there. I would recommend not to use that feature (or just for small or really essential assets), but rather handle the loading in your simple first scene.
4.) Shader compile times can be really high on mobile. I do know this from iOS, but I assume it is the same for android. Avoid using too many shaders and shader variants. You can track the shaders you use by Going to Project Settings->Graphics. Just hit clear once, and then run your game. You can sace the tracked shaders to a ShaderVariantCollection to analyze the shaders that are used.
5.) You can track your improvements in loading times with Time.realtimeSinceStartup, this gives you the time from the very first second you hit the app icon. Another solution would be to make screen captures to measure the startup time.
6.) Also profile on device with the unity profiler to see what takes time to load and make sure to reboot your device every once in a while, since there might still be stuff in GPU memory, even if the app was killed (At least that’s the case for iOS).
7.) (Added later for future readers) Test your build with a normal build (No development Build) to see if the problem occurs tehre as well. Connecting to the profiler and enabling all debugging features can take quite some time.
[Update]: This is important for anyone having similar problems!
Just found out that the main reason for the black screen lasting a long time when the game was launched is because in my build settings I had ‘Autoconnected Profiler’ turned on. Turns out, this feature allows you to profile your game wirelessly from a physical device as long as your computer and test device were connected to the same network.
If the internet connection between the two devices was poor, or if they were not connected to the same network, the game took extra long to load because the Android device could not establish a connection to the profiler, or it took longer than normal to establish the connection.
To fix this, make sure the two devices are connected to the same network with a strong connection, or turn off ‘Autoconnected Profiler’ in the build settings. The only difference is that turning off ‘Autoconnected Profiler’ will give you more accurate loading time.
I won’t dive too much into detail, just a few ideas. For more indepth discussion I recommend opening a thread for your problems in the fitting subforums.
1.) Hadn’t had the problem so far, but you could try enable multithreading for your Physics2D. Other than that, if it’s just a 10ms spike that happens every time you load a level, you could easily hide that through UI, or whatever seems fitting, right?
2.) I think I saw that problem for others, that used more than one camera. Maybe experiment with the clear flags of your camera. Seems like something is blocking the clear somehow.
Hey if someone happens to still have a long loading time before the game launches and you already tested all the solutions above then maybe you have many audio files in your project, you should select all your Audio Files and uncheck Preload. Or uncheck it for some of them at least
Can’t agree more with the last 2 posts. I reduced my game loading time by around 4 just doing that.
As a side not, for me what worked was to leave the “Preload Audio Data” ticked, but to ALSO tick the “Load in background” (important to leave them both ticked).
This post explains quite well the difference between all options in case you are curious about it :
Summary :
If our Load Type settings determine how our audio assets will be loaded, then the Preload Audio Data and Load in Background settings determine when they will be loaded.
Selecting only Preload Audio Data means the scene will not be playable until the audio data is completely loaded. This is important for audio that needs to be ready as soon as the scene is, such as footsteps, UI, and any audio that might be synced to visual elements that occur early in the scene.
Selecting both Preload Audio Data and Load in Background means the audio data will begin loading during the scene loading process, but the scene’s playability won’t be delayed by it. With this setting, the scene will be ready faster because it isn’t waiting unnecessarily on audio assets that aren’t needed right away. This is great for audio assets linked to enemies or items that appear at a further point in the scene, victory and loss sound effects that come only after combat situations, or audio synced to visual elements triggered at a later point in the gameplay.
When only Load in Background is selected, the audio file will load once it is called and play as soon as it is ready. Depending on the file size, this could cause a noticeable delay between the play call and the actual sound. The file will remain loaded so this problem will only be there for the first call. Sounds that have no relationship to visual elements can benefit the most from the setting, the best example being random ambient sounds. Since they are just there to add a dynamic ambience to the scene and are not connected to any specific gameplay elements, it doesn’t matter if loading them results in delay.
Deselecting both Preload Audio Data and Load in Background leaves us with the final option. When audio assets with this setting are called, they will use the main thread to load themselves. If they are too big, they could stall the main thread, resulting in a frame hitch, something we definitely don’t want. We’d recommend this option only for very small files and only in the case that you’re certain they will be triggered one at a time and not all at once.
In my case, it was too many HD mesh colliders has to be generated on the phone when the game start, once I converted them to box collider, loading become instance.