In essence, the idea of hot update needs to consider some problems. For example, what percentage of resources can a complete game load over the network? Can as many resources as possible be loaded over the network?
Loading through the network has many advantages, not only can greatly reduce the size of the installation package, but also help the promotion and dissemination of the game. More importantly, there is no need to reinstall the game for future updates. As long as there is a network, the new version of resources will be automatically loaded after opening the game.
So which resources need to be loaded over the network? First of all, theoretically almost all resources can be loaded through the network; second, Unity script itself does not support dynamic loading . For these two points, the predecessors came up with various solutions.
1. Transition scene
The easiest thing to think of is that if you want to reduce the size of the installation package, you should make the simplest and most basic transition scene in the game. The transitional scene itself requires very little material (for example, there is only one loading progress bar), and its function is only one - to download all the necessary resource packs online, switch the scene after the download is complete, and officially start the game. If this design is adopted, the game installation package only needs to contain the resources of the Unity engine itself, the resources of the loader and the resources of the transition scene, so that the capacity of the installation package can be made very small.
2. Dynamic loading of scripts
Example to understand the dynamic loading of scripts
A common analogy when it comes to dynamic loading of scripts is the plugin system.
Imagine you are developing an image editing application where users can choose different effects to edit pictures. And these special effects (or plug-ins) can exist in the form of scripts, and can be dynamically loaded and used when the application is running, without the need to directly include them in the application when compiling.
In this analogy, the application is like a host system, and the effect script is the plug-in. Through script dynamic loading, your application can load specific special effect scripts at runtime according to the user's selection or dynamic configuration, and interact with them to achieve different editing effects on images.
This dynamically loaded plug-in system allows you to flexibly add, remove or update special effects without recompiling the entire application. Users can customize and extend the functions of the application according to their needs without modifying the application itself.
Preferably, script resources can also be loaded and updated through the network. If the script cannot be updated, only art resources and data files can be updated, and most of the game logic cannot be changed, and program bugs in the old version cannot be fixed.
The problem of dynamic script loading design dynamic compilation and execution is a very deep technical problem. The idea of dynamic loading of modern scripts is divided into the following two categories.
The first type of thinking
Compile the script into a dynamic link library (DLL), and then put the DLL into the asset package as a resource. When using the script, use the reflection mechanism of C# to let the program in the DLL be executed dynamically.
The advantage of this idea is that there is no need to change the original script editing method, only some additional processing is required when packaging and loading. In other words, there is almost no additional burden on developers. But it also has fatal shortcomings. On the iOS platform, for security reasons, it is not allowed to use reflection to load network codes, so this method cannot be used in operating systems with high security requirements such as iOS.
Loading network code using reflection can be a security risk for several reasons:
1. Security vulnerabilities: Code loaded over the network may contain malicious code or have security vulnerabilities. This code may perform unauthorized actions, access sensitive information, destabilize the system, or even attack other computer or network resources.
2. No authentication: Reflection provides the ability to dynamically load types, but it does not have a built-in authentication mechanism to verify the origin and integrity of these types. Therefore, failure to carefully verify the source and content of loaded code could result in untrusted code being loaded and executed.
3. Code Injection: Code loaded via reflection may be executed as injected, which means that their relationship to other parts of the application may not be clear or predictable. In this case, code may access and modify the application's internal state in an uncontrolled manner, causing security issues and instability.
4. Privilege Escalation: Loaded code may attempt to elevate privileges upon execution, gain system administrator privileges, or perform privileged operations, which may lead to security breaches and unauthorized access.
The second type of thinking
Change to a brand new scripting framework, or even change to a scripting development language. Among the popular hot update frameworks, it is common to use Lua as the development language. In addition, there is also a hot update framework using the C# language. The advantage is that there is no need to learn and use another new programming language.
This idea is to create a new virtual machine in the running environment, and the virtual machine is responsible for running the hot update script. Because these scripts can only call limited program interfaces without having too many permissions, they are relatively safe.
3. Version resource list
In the hot update technology, there is a technology worth learning - the version resource list.
The reason why the version resource list is required is that each version update needs to compare the versions of the local resources and the resources of the remote server. Moreover, if some of the user's local resources are new and some are old, some mechanism is needed to ensure that the old resources are updated quickly and accurately.
The version update must first be based on the version number. The client has a version number, such as version 1.0. If the server-side version number is found to be version 1.1, the client will download the resources of version 1.1 to the local. The simplest idea is to store a list of files that have changed from version 1.0 to version 1.1 on the server, and the client can update resources one by one according to the list. After the update is completed, the version number becomes 1.1.
This way of thinking can achieve results, but it is not flexible enough. A better idea is as follows:
- Each resource file on the server side calculates the MD5 code once, and saves the result in the resource list.
- Each local file also needs to calculate the MD5 code once. In order to avoid repeated calculation, it can be calculated once and then saved in the local list file.
- The upgraded version is to compare the MD5 code of each file on the server side with the MD5 code of the local file, and only download files with inconsistent MD5 codes
- After the download is complete, the MD5 code can be recalculated, so that you can check whether the data transmission is wrong during the download process
- After ensuring that the resources are consistent, the local version number can be modified to avoid repeated checks
MD5 code
MD5 code is a data encryption algorithm, it will record all the data in the file, and combine all the data with a special algorithm to form a 128-bit (16) byte number.
The MD5 code calculated from the same data is also the same, if any bit changes in the file, the generated MD5 code will be completely different. In reality, a file can be modified at will, but the probability that the MD5 code remains unchanged is close to 0. This property of the official MD5 code is borrowed here.
Although the MD5 code is an encryption algorithm, its collision algorithm has been cracked, so it is no longer used as an encryption algorithm. However, due to its advantages of simple algorithm and fast calculation, it is very suitable as a file consistency comparison algorithm.
This article explains the reasons for the hot update technology and its design ideas from the perspective of ideas. It can be seen that hot update is based on dynamic resource management technology, including other programming technologies. Hot update technology contains many details, so there are many full-featured hot update frameworks on the market.
These frameworks mainly have the following functions:
- Provide a virtual machine environment for executing hot update code
- Export the types, methods and properties provided by the engine, so that developers can access engine functions in hot update code
- Export the Unity script interface written by the developer, so that the hot update code can call the types, methods and properties in C#
- Provide some methods so that Unity scripts can use the types, functions and properties in the hot update code, and serve as a bridge between the two sets of code
Generally speaking, due to different operating principles, the execution efficiency of dynamically loaded code will be lower than that of native scripts. If you do find performance hotspots due to dynamic script code, you can write the part with high computational pressure in native script and encapsulate it into a function, and then let the dynamically loaded code call the function