About the experience of packaging to Android boot black screen for too long
Such as the title: In the project, it was found that when the project was packaged to run on an Android machine, there would always be a long wait for a black screen. Colleagues felt that this experience was very bad, so we spent a morning to basically solve this problem, and it was also true for unity. have a deeper understanding
Solution
If you are in a hurry, you can directly look here. There are many solutions on the Internet. You can refer to their methods for optimization. The solutions we found may be different from yours.
In a word, write the loading method in a coroutine, and then put it in the start method in the mono life cycle
process
We have made some attempts
1 such as optimizing the resources in resources, optimized to only a few megabytes, but the black screen time is still very long (it may be shortened by a few milliseconds, and the difference is basically indistinguishable) and the resources of this project are compared with the previous
projects After making a comparison, I found that the previous project has more than 30 megabytes, but the startup is not stuck at all, so it is basically possible to diagnose problems that are not resources
2 Then I tried to modify the code logic, because I guessed that it might be stuck due to too many coroutines, and through debugging, I found that the coroutine method was being executed when the screen was black, but the loaded interface never appeared before
loading The next scenario and obtaining user login information are executed separately through two coroutines, as shown in the figure
Later, I put the method of obtaining user login information in the method of loading the next scene, as shown in the figure
There is still a long waiting time when running discovery
3 Immediately afterwards, I tried adding the method of loading the next scene in different life cycles. At the beginning, I put it in awake, and then I tried to put it in start. I found that this method is much faster (different machines vary greatly, The gap between my Qualcomm 870 and my colleague's Kirin 970 is 4~5s, and sometimes it is very fast, sometimes there is still a waiting time)
4 Finally, I tried to put the loaded method in the coroutine, and then execute it in the Start method, as shown in the figure
After such a whole process, I found that there is basically no lagging phenomenon, and the loading interface can also be displayed and run normally. Then I checked the life cycle table of unity and guessed that the awake method takes precedence over everything else, and the script for loading the interface is
placed The first object in the scene, so the objects involved in the script have not been loaded yet, and it is necessary to wait for other objects to be loaded (including the associated dependent objects in the loading script) before executing the corresponding method. Therefore, place the method
in In start, the phenomenon of black screen will be improved to a certain extent, but the phenomenon of black screen will still appear from time to time,
and there are still some questions that are not sure when discussing with colleagues, such as why the ordinary method is called directly in the start method (the ordinary method contains the coordinator program method) to package Android, there will be a black screen, but wrapping this common
method with a coroutine and then packaging the black screen phenomenon will disappear After loading these scripts, these scripts will be loaded by a separate thread after they are wrapped by the coroutine, which will not affect the loading of the scene interface, and this problem is also found in the main scene later (the colleague’s opinion is The script is not big, so there should be no black screen, and it is a black screen of 6~7s)
Of course, there is no definite conclusion on the problem mentioned above (in order to solve the problem first, the reason is not to go into details, the question is whether the program and I can run That's fine), if someone knows, please write your answer in the comment area
I updated it in the afternoon of the same day, discussed and tried it again with my colleagues (yes, we are not paddling), and found that the key is not the problem of wrapping the coroutine outside, but in the method of loading the coroutine of the scene. Write yeild return at the beginning (here null is also ok, new waitforsconds is also ok), it gives me the feeling that I am telling the program to start the coroutine here, of course it is the same in practice, but he can return null or 0s There is no black screen for a long time, so yeild return feels more like an identifier, and the methods and codes in the previous coroutine still have to go step by step, or the coroutine when the program first starts The logic is confusing. It may be a synchronous logic at the beginning, and then there is a yield return to start the logic of the coroutine, or the scenemanager.loadsceneasync method is a fake asynchronous method, before loading the percentage of the next scene The real asynchronous start starts after the synchronous loading, which leads to a too long boot black screen time, because in addition to loading the current scene resources, it is also synchronously loading the next scene resources. I feel that there is no chance for a deeper understanding. The official documentation is about methods
and The description of the class is too simple, and the source code is not easy to delve into. This is the only way to go.