koobas.hobune.stream
LoadLevelAsync Crash on Android
I have a (very simple) loading screen implemented, and it works flawlessly on iOS and web builds. Unfortunately, it causes a crash 100% of the time on Android builds. On a non-Development Build, some loading takes place before the crash (about 60-70%), but if I make a Development Build, the crash occurs as soon as my loading screen is shown. If I remove the loading scene, the game runs fine on all platforms, barring a watchdog kill.
I recognize that this may not be a LoadLevelAsync crash. There may be some asset that is unable to properly async-load only on Android, but since I can't get any messaging out of LoadLevelAsync to let me know what is being loaded when the crash occurs, I'm flying blind. Any debugging tricks for this situation for a moderately-sized game would be appreciated as well.
Here's my loading code. This is placed on an object in the loading scene.
public string LevelToLoad;
AsyncOperation async;
IEnumerator Start()
{
//Debug.Log("Started Loading...");
async = Application.LoadLevelAsync(LevelToLoad);
yield return async;
}
void Update()
{
//Debug.Log("Loading Progress: " + async.progress * 100);
//ProgressSprite is an object of a custom loading sprite class,
//but contains no surprises.
ProgressSprite.fillAmount = async.progress;
}
To help us debug your issue, uncomment the Debug.Log in Update and tell us how many lines were printed before the crash.
It successfully runs until about 67%, which takes a little over 5 seconds.
Over a hundred. Is there some particular merit in knowing an exact number of which I'm not aware?
Yes if you only got one I could mean that it was some kind of NullReferenceException.
I found the following discussion to be a useful direction to search in: Dealing With Large AssetBundles
Thinking that I might just be loading too much at once for Android, like the folks in that thread, I chopped out my audio resources (which happened to bring the rest under 20MB), and the game loads fine. Now I need to see if I can bundle the audio separately and differently, or if it's somehow a problem with the audio itself.
Yep, this did it. By chopping out my audio resources and adding them to an AssetBundle that I load up at runtime, I'm able to avoid this crash. Looks to be a bug in Unity that the crash is happening at all.
I don't think that is the cause, but you should always guard any reference against NullReferenceException. Thus:
void Update()
{
if( async == null )
return;
// add a test here to check whether the ProgressSprite is ready, because if this script is executed first it can crash here
//...
ProgressSprite.fillAmount = async.progress;
}
I don't think you should always guard against null. In cases where it's impossible to get a null, it's prolly ok not to add that extra branch.
Sorry to disappoint you. But it is very probable to get a null in this case: if LevelToLoad does not match a level that has been added to the build list, then Application.LoadLevelAsync will return null.
Testing for null value is a very quick test (only one CIL instruction) and should always be done. You should never infer that "in this case it is impossible". That's when bugs occur.
