Application running method, device, electronic device and storage medium

Abstract

Embodiments of the present application disclose an application running method, apparatus, electronic device, and computer-readable storage medium. After hot updating when a script module in the engine file library of a target application changes, the target script version function in the engine file library is called to run the target application. The first version information of the target static version function corresponding to the target script version function in the engine file library is obtained. The second version information of the target script version function is obtained. If the first version information and the second version information match, the target static version function is called to run the target application. Embodiments of the present application can enable functions, variables, and classes on a script extension module to support hot updating after the static language code translated from the script module is compiled to form the script extension module.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and particularly to an application running method, apparatus, electronic device, and computer-readable storage medium. Background Art

[0002] In order to support hot updates and rapid development iterations, application logic is usually written in a scripting language (such as the Python language). However, compared with the performance of static languages (such as the C++ language), the performance of scripting languages is relatively low; as the application content becomes increasingly rich, the code volume of scripting languages will rapidly expand, and the disadvantage of the low performance of scripting languages compared with static languages will gradually be magnified, ultimately resulting in a decrease in the running efficiency of the application. In this article, the function written in a scripting language is simply referred to as the "script version function", and the function written in a static language is simply referred to as the "static version function".

[0003] In the prior art, after translating the script version function that implements the application logic into a static version function and compiling it into a script extension module for use by the application's running engine, the running engine can call the static version function to implement the application logic, thereby improving the running efficiency of the application. However, after being compiled into a script extension module, the functions, variables, and classes on the script extension module no longer support hot updates. Summary of the Invention

[0004] The embodiments of this application provide an application running method, apparatus, electronic device, and computer-readable storage medium, which can enable the functions, variables, and classes on the script extension module formed by compiling the static language code translated from the script module to support hot updates.

[0005] In a first aspect, the embodiments of this application provide an application running method, including:

[0006] After a hot update occurs when a script module in the engine file library of the target application changes, call the target script version function in the engine file library to run the target application;

[0007] Obtain the first version information of the target static version function corresponding to the target script version function in the engine file library;

[0008] Obtain the second version information of the target script version function;

[0009] If the first version information and the second version information match, call the target static version function to run the target application.

[0010] In a second aspect, the embodiments of this application further provide an application running apparatus, including:

[0011] A calling unit, configured to call a target script version function in the engine file library to run the target application after a hot update occurs to a script module in the engine file library of the target application;

[0012] A first obtaining unit, configured to obtain first version information of a target static version function corresponding to the target script version function in the engine file library;

[0013] A second obtaining unit, configured to obtain second version information of the target script version function;

[0014] The calling unit is further configured to, if the first version information and the second version information match, call the target static version function to run the target application.

[0015] In some embodiments, the calling unit is specifically configured to:

[0016] If the first version information and the second version information do not match, continue to call the target script version function to run the target application.

[0017] In some embodiments, the application running device further includes a recording unit. Before obtaining the first version information of the target static version function corresponding to the target script version function in the engine file library, the recording unit is specifically configured to:

[0018] When writing a static version function corresponding to a script version function of the target application into the engine file library, obtain version information of the script version function;

[0019] Associate and record the version information of the script version function with a function identifier of the script version function in the engine file library;

[0020] In some embodiments, the first obtaining unit is specifically configured to:

[0021] Obtain a function identifier of the target script version function;

[0022] From the engine file library, obtain version information of a script version function associated and recorded with the function identifier of the target script version function as the first version information.

[0023] In some embodiments, the second obtaining unit is specifically configured to:

[0024] When the script module is compiled, obtain the second version information of the target script version function.

[0025] In some embodiments, the application running device further includes a sinking unit. The sinking unit is specifically configured to:

[0026] Execute the sinking operation of the script module, where the sinking operation includes translating the target script version function into a static version function and compiling it into the running engine of the target application.

[0027] In some embodiments, the sinking unit is specifically configured to:

[0028] Obtain the type definition file of the script module, where the type definition file contains the static type information of the target script version function;

[0029] Generate the static language code corresponding to the script module based on the type definition file, where the static language code contains the target static version function;

[0030] Compile the static language code into the running engine to obtain the static extension module corresponding to the script module, where the static extension module is used to provide the target static version function for the running engine.

[0031] In some embodiments, the application running device further includes a preprocessing unit. Before obtaining the static type information of the target script version function, the preprocessing unit is specifically configured to:

[0032] Add a sinking identifier to the functions to be sunk in the script module;

[0033] Obtain the functions in the script module with the sinking identifier as the target script version function.

[0034] In some embodiments, the application running device further includes a preprocessing unit. The static type information includes at least one of the type identifier of the formal parameters of the target script version function and the type identifier of the return value of the target script version function. Before obtaining the static type information of the target script version function, the preprocessing unit is specifically configured to:

[0035] Add type identifiers to the formal parameters and return values of the target script version function in the script module;

[0036] In some embodiments, the sinking unit is specifically configured to:

[0037] Perform static analysis on the script module to obtain the data information of the script module, where the data information includes at least one of the type identifier of the formal parameters of the target script version function and the type identifier of the return value of the target script version function;

[0038] Obtain the type definition file based on at least one of the type identifier of the formal parameters of the target script version function and the type identifier of the return value of the target script version function.

[0039] In some embodiments, the target application includes a plurality of the script modules, and the sinking unit is specifically configured to:

[0040] Obtain the static language codes corresponding to each of the script modules, so as to obtain the static language codes corresponding to the plurality of script modules, wherein the static language codes corresponding to the plurality of script modules include the target static version function;

[0041] Extract the common code among the static language codes corresponding to the plurality of script modules;

[0042] Obtain the intra-class architecture of each of the script modules;

[0043] Generate target code files corresponding to the plurality of script modules based on the common code and the intra-class architecture;

[0044] Compile the target code files into the running engine.

[0045] In some embodiments, the calling unit is specifically configured to:

[0046] After a hot update occurs when a script module in the engine file library of the target application changes, determine whether there is a difference in the target script version function in the engine file library before and after the hot update;

[0047] If there is a difference in the target script version function before and after the hot update, call the target script version function to run the target application.

[0048] In a third aspect, an embodiment of the present application further provides an electronic device, including a memory storing multiple instructions; the processor loads the instructions from the memory to execute the steps in any one of the application running methods provided by the embodiments of the present application.

[0049] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, where the computer-readable storage medium stores multiple instructions, and the instructions are suitable for being loaded by a processor to execute the steps in any one of the application running methods provided by the embodiments of the present application.

[0050] In the embodiments of the present application, after a hot update occurs due to a change in the script module in the engine file library of the target application, the target application will be run by calling the target script version function in the engine file library. Only when the first version information of the target static version function in the engine file library matches the second version information of the target script version function in the engine file library, will the target application be run by calling the target script version function in the engine file library. Therefore, even when the target application is run during the sinking operation of the target script version function, the correctness of the application running logic can still be ensured, enabling the static version function obtained by sinking the script version function to still support hot updates. As a result, after the static language code translated from the script module is compiled into a script extension module, the functions, variables, and classes on the script extension module can still support hot updates. Brief Description of the Drawings

[0051] To more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following described drawings are only some embodiments of the present application. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0052] Figure 1 It is a schematic flowchart of an embodiment of the application running method provided by the embodiments of the present application;

[0053] Figure 2 It is a schematic framework diagram of the binding between Python objects and C++ objects in the embodiments of the present application;

[0054] Figure 3 It is a schematic flowchart of the binding between Python objects and C++ objects in the embodiments of the present application;

[0055] Figure 4 It is a schematic diagram for explaining the addition of type information in the script module in the embodiments of the present application;

[0056] Figure 5 It is a schematic diagram for explaining the generation of static language code provided in this embodiment;

[0057] Figure 6 It is a schematic flowchart of the switching process between the static version function and the dynamic version function during the hot update provided in this embodiment;

[0058] Figure 7 It is a schematic structural diagram of the application running device provided by the embodiments of the present application;

[0059] Figure 8 It is a schematic structural diagram of the electronic device provided by the embodiments of the present application. Detailed Embodiments

[0060] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of protection of the present application. At the same time, in the description of the embodiments of the present application, terms such as "first" and "second" are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of the described features. In the description of the embodiments of the present application, the meaning of "a plurality" is two or more, unless otherwise clearly and specifically defined.

[0061] The embodiments of the present application provide an application running method, device, electronic device, and computer-readable storage medium.

[0062] Specifically, this embodiment will be described from the perspective of an application running device. The application running device can be specifically integrated in an electronic device, that is, the application running method in the embodiments of the present application can be executed by the electronic device, and the electronic device can be a device such as a terminal or a server. Among them, the terminal can be a device such as a mobile phone, a tablet computer, a smart Bluetooth device, a laptop computer, a touch screen, a game console, or a personal computer (PC); the server can be a single server or a server cluster composed of multiple servers.

[0063] For example, the electronic device can be a mobile terminal. After the script module in the engine file library of the target application is hot updated due to a change, the mobile terminal can call the target script version function in the engine file library to run the target application; obtain the first version information of the target static version function corresponding to the target script version function in the engine file library; obtain the second version information of the target script version function; if the first version information and the second version information match, then call the target static version function to run the target application.

[0064] In some embodiments, the application running device can also be integrated in multiple electronic devices. For example, the application running device can be integrated in multiple servers, and multiple servers are used to implement the application running method of the present application. Another example is that the application running device can be integrated in multiple terminals, and multiple terminals are used to implement the application running method of the present application.

[0065] In some embodiments, the server can also be implemented in the form of a terminal. For example, a personal computer can be set as a server to integrate the application running device, and the server set by the personal computer is used to implement the application running method of the present application.

[0066] Taking the execution entity of the application running method as an electronic device as an example, the following will be described in detail with reference to the accompanying drawings. For the sake of simplicity of expression, the execution entity will be omitted hereinafter. It should be noted that the description order of the following embodiments does not limit the preferred order of the embodiments. Although the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in an order different from that shown in the drawings.

[0067] As Figure 1 shown, the specific process of the application running method can be as follows: Step 101 to Step 104, where:

[0068] 101. After the script module in the engine file library of the target application is hot updated, call the target script version function in the engine file library to run the target application.

[0069] Among them, the target application is an application whose implementation logic includes static version functions, such as a game application.

[0070] Among them, the running engine is an engine used to run the target application. For example, a game engine.

[0071] Among them, the script module refers to a code file written in a script language (such as Python language, Lua language) and used to implement the logic of the target application. For example, the game logic code written in the Python language. A specific example is: in order to support the hot update and rapid development iteration of the application (such as a game application), the game logic will be written in the Python language, and the code file obtained by writing the game logic in the Python language is the script module.

[0072] Among them, the script module contains at least one function. The functions in the script module are the script version functions.

[0073] Among them, the script version function refers to a function written in a script language (such as the Python language). For example, the game logic function written in the Python language.

[0074] Among them, the target script version function refers to the script version function in the script module that is to be sunk to the running engine of the target application.

[0075] Among them, the static version function refers to a function written in a static language (such as the C++ language). For example, the game logic function written in the C++ language. A specific example is: in order to provide higher performance for the game engine, modules that are sensitive to performance and have a relatively low change frequency (such as the physics engine and the pathfinding navigation mesh, etc.) are implemented in the C++ language, and the functions written in the C++ language are the static version functions.

[0076] In this embodiment, the static version function is specifically a function obtained by translating the script version function using a static language.

[0077] Among them, the target static version function is a function obtained by translating the script version function with the same function identifier as the target script version function using a static language.

[0078] Among them, the engine file library is a database provided for the running engine to run the target application. In this embodiment, the engine file library includes a script module and a static extension module. The script module includes multiple script version functions, and the static extension module includes multiple static version functions obtained by translating the script version functions; the static extension module is obtained by compiling the static language code translated from the script module (in this article, this process is called script module sinking, and the specific process of script module sinking will be introduced in detail in step 105. For the sake of simplicity of expression, it will not be elaborated here).

[0079] Exemplarily, in step 101, when the target application is running, if the script module in the engine file library of the target application changes and is hot-updated, then the functions in the changed script module are unconditionally used to run the target application, that is, the target script version function in the file library is called to run the target reference. Since the target script version function of the historical version has been translated into a static version function and compiled into the running engine of the target application (that is, the target static version function existing in the engine file library is obtained by translating the target script version function of the historical version) and is used to run the target application; therefore, when the script module changes, in order to avoid continuing to use the target static version function obtained by translating the target script version function of the historical version to run the target application, thereby avoiding logical errors in the operation of the target application, the target script version function in the engine file library will be unconditionally switched to run the target application to ensure the correctness of the operation logic of the target application.

[0080] For example, the pathfinding navigation mesh module in a game application is written in a script language to obtain the script module of the pathfinding navigation mesh module. The script module of the pathfinding navigation mesh module includes "Function a". Suppose that at the first time, "Function a" (i.e., the script version function a) in the script module of the pathfinding navigation mesh module is version 1. The "script version function a" of version 1 is translated into a static version function a (denoted as the "static version function a" of version 1) and compiled into the running engine of the game application. That is, at this time, the "static version function a" of version 1 is recorded in the engine file library.

[0081] At a second time after the first time, in order to improve the game application logic, the script module of the pathfinding navigation mesh module was adjusted. In the script module of the adjusted pathfinding navigation mesh module, "script version function a" changed from version 1 to version 2, while the "static version function a" recorded in the engine file library is still version 1. In order to avoid continuing to call the "static version function a" of version 1 to run the game application, thereby avoiding incorrect running logic of the game application, it will unconditionally switch to the "script version function a" of version 2 to run the game application to ensure the correctness of the running logic.

[0082] Further, in order to improve the switching efficiency between calling the script version function and the static version function during hot update, after the script module in the engine file library of the target application changes and undergoes hot update, it is determined whether there is a difference in the target script version function in the engine file library before and after the hot update; if there is a difference in the target script version function before and after the hot update, then call the target script version function to run the target application. If there is no difference, then continue to call the target static version function to run the target application.

[0083] 102. Obtain the first version information of the target static version function corresponding to the target script version function in the engine file library.

[0084] Wherein, the target static version function specifically refers to the static version function in the engine file library with the same function identifier as the target script version function.

[0085] Wherein, the first version information refers to the version information of the target script version function that has been sunk into the running engine. Specifically, it is the version information of the static version function in the engine database with the same function identifier as the target script version function.

[0086] In this embodiment, function sinking refers to translating the script version function into a static version function and then compiling it into the running engine of the target application. The obtained static version function after sinking is stored in the engine file library for the running engine to call. Hereinafter, taking the sinking of the script module to achieve the sinking of the target script version function as an example, the specific process of function sinking will be described, and the specific process of function sinking can be specifically referred to the relevant description in the following text (such as step 105), and the specific process of function sinking will not be elaborated here.

[0087] It can be understood that the version information of each script version function is the same as the version information of the static version function translated from the script version function. For example, the "script version function b" of version 1 is translated into the "static version function b" of version 1, and the "script version function b" of version 2 is translated into the "static version function b" of version 2.

[0088] In step 102, there are various ways to obtain the first version information. Exemplarily, it includes:

[0089] (1) When writing the static version function corresponding to the script version function into the engine file library, associate and record the function identifier of the written static version function with the version information of the written static version function. In step 102, directly find the version information associated with the function identifier of the target script version function as the first version information. Specifically, before step 102, the following steps a1 - a2 may be included:

[0090] a1. When writing the static version function corresponding to the script version function of the target application into the engine file library, obtain the version information of the script version function.

[0091] Exemplarily, the member variable value of the script version function can be used to generate an MD5 (Message - Digest Algorithm) value as the version information of the script version function. Taking the script language as Python as an example, a specific example of "using the member variable value of the script version function to generate an MD5 value" is as follows: The logic of the Python language is to translate the script version function logic into a segment of opcodes and store them in the PyCodeObject object of the script version function. When a script version function is called, the opcodes are passed to the Python virtual machine for translation; therefore, the member variable value of the PyCodeObject object can be used to generate an MD5 value, thus realizing using the member variable value of the script version function to generate an MD5 value.

[0092] For example, each time a script version function (including the target script version function) is sunk to the running engine, that is, when writing the static version function c obtained by translating the script version function (such as script version function c) into the engine file library, an MD5 value can be generated for the member variable value of script version function c as the version information of script version function c. It can be understood that the MD5 value generated for the member variable value of script version function c is also the version information of static version function c.

[0093] a2. Associate and record the version information of the script version function with the function identifier of the script version function in the engine file library.

[0094] For example, as shown in Table 1, assume that the function identifiers of script version functions a, b, and c are: a, b, and c respectively, and the version information of script version functions a, b, and c are: version information 1, version information 2, and version information 3 respectively. Then, associate and record the function identifier "a" with version information 1, the function identifier "b" with version information 2, and the function identifier "c" with version information 3.

[0095] Table 1

[0096] Function identifier Version information a Version information 1 b Version information 2 c Version information 3

[0097] In step 102, by obtaining the function identifier of the target script version function; from the engine file library, obtaining the version information of the script version function associated with the function identifier of the target script version function as the first version information.

[0098] (2) In step 102, calculating the MD5 value of the member variable values of the target static version function corresponding to the target script version function in real time as the first version information.

[0099] 103. Obtain the second version information of the target script version function.

[0100] Among them, the second version information refers to the version information of the target script version function in the engine file library.

[0101] In step 103, there are multiple ways to obtain the second version information. Exemplarily, it includes:

[0102] 1) In step 103, calculating the MD5 value of the member variable values of the target script version function in real time as the second version information.

[0103] 2) In order to reduce the running overhead of calculating the function version information, when the script module is compiled, calculate the MD5 value of the member variable values of the target script version function as the second version information of the target script version function.

[0104] 104. If the first version information and the second version information match, then call the target static version function to run the target application.

[0105] Specifically, if the first version information obtained in step 102 matches the second version information obtained in step 103, it proves that the latest version of the target script version function has sunk into the running engine, that is, there is a target static version function translated from the latest version of the target script version function in the engine file library. At this time, by calling the target static version function corresponding to the target script version function in the engine file library, the target application can be run using the target static function translated from the latest version of the target script version function, and the running logic will not go wrong.

[0106] If the first version information obtained in step 102 does not match the second version information obtained in step 103, it proves that the target script version function of the latest version has not yet been sunk into the running engine. That is, the target static version function in the engine file library is obtained by translating the target script version function of the historical version. At this time, when calling the target static version function corresponding to the target script version function in the engine file library, the target application will be run using the target static function obtained by translating the target script version function of the historical version, which will cause the running logic to go wrong. Therefore, if the first version information obtained in step 102 does not match the second version information obtained in step 103, continue to call the target script version function in the engine file library to run the target application.

[0107] It can be seen that after the script module in the engine file library of the target application changes and is hot updated, the target script version function in the engine file library will be called to run the target application. When the first version information of the target static version function in the engine file library matches the second version information of the target script version function in the engine file library, the target script version function in the engine file library will be called to run the target application; therefore, even when running the target application during the sinking operation of the target script version function, the correctness of the application running logic can still be guaranteed, so that the static version function obtained by sinking the script version function can still implement hot updates. As a result, after the static language code translated from the script module is compiled into a script extension module, the functions, variables, and classes on the script extension module can still support hot updates.

[0108] Furthermore, in this embodiment, the script version object and the static version object are corresponded one by one through a pointer pointing method (abbreviated as binding) to ensure that the switch can be made from "calling the target script version function to run the target application" to "calling the target static version function to run the target application".

[0109] Such as Figure 2 and Figure 3 shown, Figure 2 is a framework schematic diagram of the binding of python objects and C++ objects in an embodiment of the present application, Figure 3 is a process schematic diagram of the binding of python objects and C++ objects in an embodiment of the present application. Here, taking the script module as a "Python module" (i.e., a module written in the Python language), the static extension module as a "C++ extension module" (i.e., a module obtained after translation and sinking using the C++ language), the target script version function as a function at the Python layer, and the target static version function as a function at the C++ layer as examples, an example is given to introduce how to switch from "calling the target script version function to run the target application" to "calling the target static version function to run the target application".

[0110] Among them, a script module contains at least one class, and a class contains at least one script version function. An object is an instance of a class. That is, during actual operation, a class in a Python module corresponds to a class type object (abbreviated as a Python object) at the Python layer, and a class in a C++ extension module corresponds to a type object (abbreviated as a C++ object) at the C++ layer. Figure 2 and Figure 3 in:

[0111] PythonClass object: A class type object at the Python layer;

[0112] NosObjectMeta object: A type object at the C++ layer corresponding to the PythonClass object, used to manage variables at the Python layer and the C++ layer and switch functions between the C++ layer and the Python layer;

[0113] PyNosMetaManager: A global manager that manages all NosObjectMeta objects and is used to bind the corresponding NosObjectMeta object to the PythonClass object;

[0114] PythonObject instance: Multiple instances generated by the PythonClass object;

[0115] NosObject instance: Multiple instances generated by the NosObjectMeta object, which has a one-to-one correspondence with the PythonObject.

[0116] When it is necessary to switch from "calling the target script version function to run the target application" to "calling the target static version function to run the target application", the following steps 1 to 5 will be executed to achieve the switch from "calling the target script version function to run the target application" to "calling the target static version function to run the target application":

[0117] 1. Import the Python module and create a PythonClass object at the Python layer;

[0118] 2. The decorator pynosboost of the target script version function will, through the sinking identifier in the Python module, pass the PythonClass object corresponding to the current class (the class where the target script version function is located) to the C++ layer for binding to the NosObject object at the C++ layer;

[0119] 3. The PyNosMetaManager queries whether there is a corresponding NosObjectMeta object for the current class. If not, the current process ends and the original PythonClass object is directly returned. If so, it means that the actual sinking operation can be performed.

[0120] 4. After finding the corresponding NosObjectMeta object, a pointer to the corresponding PythonClass object will be recorded on the NosObjectMeta object, and the C++ version of the functions and variables will be registered.

[0121] 5. The Python functions in the PythonClass object are recorded in the NosObjectMeta, and the Python functions in the PythonClass object are replaced with the C++ functions in the NosObjectMeta. The sinking is successful, and the current PythonClass object is returned. Thus, the binding between the Python object and the C++ object is completed. When creating a corresponding PythonObject instance using the PythonClass object, its corresponding NosObjectMeta object can be found and used to create a NosObject instance. When creating, deleting, and updating variables in the PythonObject instance, it will be synchronized to the NosObject instance. Therefore, it is possible to switch from "invoking the target script version function to run the target application" to "invoking the target static version function to run the target application".

[0122] Furthermore, in order to quickly locate the functions that need to be sunk in the script module, some preprocessing will be done on the script module. For example, a sinking identifier is added to the functions to be sunk in the script module. That is, before step 101, it also includes: adding a sinking identifier to the functions to be sunk in the script module; obtaining the functions with the sinking identifier in the script module as the target script version functions.

[0123] Please refer to Figure 6 , Figure 6 which is a schematic diagram of the switching process between the static version function and the dynamic version function in the hot update provided in this embodiment. In this embodiment, during the process of running the target application, the sinking operation of the target script version function (i.e., the latest version of the target script version function) in the engine file library can also be performed to translate the latest version of the target script version function into a static version function and compile it into the running engine of the target reference to achieve the hot update of the static version function. Taking the sinking of the script module to achieve the sinking of the function as an example, the application running method further includes the following step 105:

[0124] 105. Perform the sinking operation of the script module.

[0125] Among them, the sinking operation of the script module includes translating the target script version function into a static version function and compiling it into the running engine of the target application.

[0126] For different ways of introducing the script module translation method, there are multiple ways to perform the sinking operation of the script module in step 105.

[0127] (1) Translate the corresponding static language code for each script module respectively and compile it into the corresponding static extension module. Please refer to Figure 5 , Figure 5 is an illustrative diagram of the generation of static language code provided in this embodiment. At this time, step 105 may specifically include the following steps b1 to b3, where:

[0128] b1. Obtain the type definition file of the script module.

[0129] Among them, the type definition file contains the static type information of the target script version function.

[0130] Among them, the type definition file is the static type declaration information of variables, functions, classes, etc. in the script module. For example, a pxd file written using the Cython tool (the pxd file marks the static type declaration information of variables, functions, classes, etc. in the script module), and a pyx file obtained by rewriting the script module according to the Cython syntax using the Cython tool (this pyx file marks the static type declaration information of variables, functions, classes, etc. in the script module).

[0131] Among them, the static type information is the information of the static type declaration of the target script version function. For example, the local variable type of the target script version function, the return value type of the function, etc.

[0132] One of the reasons for the relatively low performance of script languages is that variable types are checked during runtime. Therefore, when sinking the script module to the running engine, static type declarations are introduced to improve the running speed of the sunken static extension module. For example, static type declarations of functions are introduced to convert the script version function into a static version function with a faster running speed. There are multiple ways to introduce static type declarations. Exemplarily, they include: Method ①: Write a pxd file of the script module using the Cython tool as the type definition file of the script module; among them, the main content of this pxd file is: variables, functions, classes and their types included in the script module. Method ②: Rewrite the script module according to the Cython syntax using the Cython tool to obtain a pyx file of the script module as the type definition file of the script module; among them, the main content of this pyx file is: variables, functions, classes and their types included in the script module.

[0133] There are multiple ways to obtain the type definition file in step b1.

[0134] 1) Obtained from the manually marked type information. In some embodiments, static type declarations can be introduced by manual writing to obtain the type definition file of the script module. For example, as Figure 4 shown, Figure 4 is a schematic diagram showing the addition of type information in the script module in an embodiment of the present application. Type information can be marked manually for all functions or variables that need to be sunk in the script module (such as Figure 4 shown as "#.type: float, float, float, float", "#.type: (tuple, tuple).->float") to obtain the type definition file of the script module, thereby introducing static type information for the target script version function.

[0135] 2) Automatically deduced through AST (Abstract Syntax Tree) analysis. In some embodiments, to improve the efficiency of introducing static type declarations, variable type deduction can also be automatically performed on the script module. For example, through AST analysis, the type information of functions or variables in the script module can be obtained to introduce static type declarations, thereby obtaining the type definition file of the script module, and then introducing static type information for the target script version function. Among them, through AST analysis and automatic deduction, the local variable types of functions, the return value types of functions, the types of member variables, and the types of module variables in the script module can be deduced.

[0136] 3) Obtained by combining manually marked type information and AST analysis and automatic deduction.

[0137] On the one hand, the static type information of all target script version functions in the script module needs to be deduced completely to ensure the running efficiency of the target static version function obtained after sinking. On the other hand, due to the dynamic nature of the script language, even if the actual parameters of a function call are determined, the formal parameters of the function call cannot be determined; therefore, it is difficult to deduce all variable types in the script module through AST analysis and automatic deduction of variable types, that is, it is difficult to deduce the static type information of all target script version functions in the script module completely.

[0138] For this reason, in this embodiment, type identifiers are added to the formal parameters and return values of the target script version function, and the static type information of the target script version function in the script module is automatically deduced by combining the type identifiers of the target script version function and AST analysis. Further, type identifiers can also be manually marked for all classes, functions, and variables in the script module.

[0139] That is, in some embodiments, the static type information of the target script version function includes at least one of the type identifiers of the target script version function's formal parameters and the type identifiers of the target script version function's return value. Figure 5 As shown, before step b1, it also includes: adding type identifiers for the parameters and return values of the target script version function in the script module. For example, a preprocessing stage of the script module can be added to add a sinking identifier to the function to be sunk in the script module, and adding type identifiers for the parameters and return values of the target script version function in the script module. Step b1 can specifically include: performing static analysis on the script module to obtain data information of the script module; and obtaining the type definition file based on at least one of the type identifiers of the parameters of the target script version function and the type identifier of the return value of the target script version function.

[0140] The data information may include information such as the type identifier of the formal parameter of the target script version function, the type identifier of the return value of the target script version function, and the type identifier of the target script version function.

[0141] The script module can be statically analyzed using AST analysis to generate data information for the script module. The data information generated by AST analysis can specifically include class information and function information for the script module. The generated data information for the script module can be used to subsequently generate a type definition file for the script module and generate the static language code corresponding to the script module.

[0142] Among them, class information may include: member functions (recorded as FuncCallCallInC), member variables (recorded as member_var), class variables (recorded as class_var), parent classes (recorded as parents), the path of the final generated code (recorded as path), the root node class (recorded as root_type), the type of generated code (recorded as cppgen), an indicator of whether a pxd file needs to be generated (recorded as need_gen_pxd), etc.

[0143] Among them, the function information may include: the number of default parameters (denoted as default_arg_cnt), the type of generated code (denoted as cppgen), whether there are variable arguments (denoted as has_star_args), whether there are variable default arguments (denoted as has_star_kwargs), local variables (denoted as local_var), decorators (denoted as decorators), parameter information (denoted as args), the MD5 information of the function (denoted as debug_py_digest), whether there is a closure (denoted as has_closure), whether it is a closure function (denoted as closure), the included closure function (denoted as closure_func), the return value type of the function (denoted as rtype), whether it is a class function (denoted as classmethod), whether it is a static function (denoted as staticmethod), whether it is a generator (denoted as generator), the type identifier of the function (denoted as type_hint), the type identifier of the formal parameters of the target script version function, the type identifier of the return value of the target script version function, etc.

[0144] Exemplarily, through the Pynos tool, based on the type information of classes, functions, or variables in the script module (such as the type identifier of the return value of the target script version function, the type identifier of the target script version function, etc.), a type definition file (such as a pxd file) of the script module can be automatically generated.

[0145] b2. Generate the static language code corresponding to the script module based on the type definition file.

[0146] Among them, the static language code includes the target static version function.

[0147] For example, taking the generated static language code as C++ code, the script module as a Python module, and the type definition file of the script module as a pxd file as an example, the specific way to generate the static language code corresponding to the script module in step b2 can be:

[0148] ① Create a new file named setup.py; among them, in the setup.py file, specify the file name of the Python module, the name of the output module, the search path of the pxd file, and the configuration options for the code generation process.

[0149] ② Execute the newly created setup.py file in ①, and the static language code (i.e., C++ code) corresponding to the Python module will be generated.

[0150] Since the Python module contains the functions of the target script version, by executing the setup.py file to generate the static language code corresponding to the Python module, the target static version functions translated from the target script version functions can be obtained, and the static type declarations can be introduced into the translated target static version functions. Thus, when the target static version functions are subsequently run, the problem of checking variable types during runtime can be avoided, and thereby the running efficiency of the target application can be effectively improved.

[0151] b3. Compile the static language code into the running engine to obtain the static extension module corresponding to the script module.

[0152] Among them, the static extension module is used to provide the target static version functions for the running engine.

[0153] For the convenience of understanding, continue with the example of step b2 above. Taking the static extension module as a Python extension module as an example, for instance, compile the static language code (i.e., C++ code) obtained in step b1② above into a Python extension module with the suffix.so and add it to the engine file database, so as to implement translating the target script version functions into the target static version functions and compiling them into the running engine for the running engine to call the target static version functions from the engine database.

[0154] It can be seen from the above content that by obtaining the type definition file of the script module to generate the static language code corresponding to the script module, compiling it into the running engine, and forming the static extension module corresponding to the script module for the running engine to use, when the running engine makes a call based on the static extension module, static type declarations can be introduced, thereby effectively improving the running efficiency of the target application.

[0155] (2) Integrate the static language codes corresponding to multiple script modules into an overall file library, and extract the common codes between the static language codes corresponding to the multiple script modules as the header file and source file of the overall file library.

[0156] In some embodiments, the target application includes multiple script modules. If each script module is translated into the corresponding static language code and then compiled into a static extension module in the manner of steps b1 to b3 above and provided for the running engine to use; since there will be a large amount of common codes between the static language codes corresponding to the multiple script modules, the multiple compiled static extension modules will also be too large, resulting in memory waste and thus a relatively high operating cost for the target application.

[0157] Therefore, in this embodiment, when the target application includes multiple script modules, instead of separately compiling the static language code corresponding to each script module into a static extension module as a library file for the running engine to use, the static language code corresponding to multiple script modules is integrated into an overall file library for the running engine to use. At the same time, the common code is extracted from the static language code corresponding to multiple script modules, and the extracted common code is used as a separate header file and source file to avoid the code bloat problem caused by excessive duplicate common code. At this time, step 105 may specifically include the following steps c1 to c5, where:

[0158] c1. Obtain the static language code corresponding to each of the script modules to obtain the static language code corresponding to multiple script modules.

[0159] Among them, the static language code corresponding to multiple script modules includes the target static version function.

[0160] Specifically, for each of the multiple script modules, the static language code corresponding to each script module is obtained by referring to the translation method of the above steps b1 to b2, so as to obtain the static language code corresponding to multiple script modules. For example, if the target application includes script module 1, script module 2, and script module 3, the static language code corresponding to script module 1 is obtained by referring to the translation method of the above steps b1 to b2; the static language code corresponding to script module 2 is obtained by referring to the translation method of the above steps b1 to b2; the static language code corresponding to script module 3 is obtained by referring to the translation method of the above steps b1 to b2.

[0161] c2. Extract the common code between the static language code corresponding to multiple script modules.

[0162] Among them, the static language code of each script module may specifically include the API implementation code of each script module, cacheable variables and initialization processes, function definitions within a class, specific implementations within a function, etc.

[0163] Since the ultimate purpose of translating each script module is to sink the script module to the running engine for the running engine to use, the API (Application Program Interface) implementation codes in the static language code corresponding to each script module are similar. If the static language code corresponding to each script module is separately compiled into a static extension module, a large amount of redundant API implementation codes will be caused.

[0164] Among them, the common code refers to the common part of the static language code corresponding to multiple script modules. For example, the API implementation code in the static language code corresponding to each script module.

[0165] c3. Obtain the in-class architecture of each of the script modules.

[0166] Among them, the in-class architecture of each script module is a file used to indicate the structure of the classes within each script module.

[0167] Exemplarily, based on the data information of each script module, a static syntax tree of each script module can be generated as the in-class architecture of each script module.

[0168] c4. Based on the common code and the in-class architecture, generate target code files corresponding to the multiple script modules.

[0169] Among them, the target code file refers to an overall file library that includes source files or header files formed by common code (i.e., the common code between the static language codes corresponding to multiple script modules), cacheable variables and initialization processes of multiple script modules, class architecture and function definitions within the class, and specific implementations within the functions.

[0170] Exemplarily, target code files can be generated based on the Pynos tool and the Cython tool. Specifically: First, through the Pynos tool, perform static analysis on each script module to obtain the data information of each script module and generate the in-class architecture of each script module.

[0171] Then, through the Cython tool, translate based on the data information of each script module to obtain the static language code of each script module (at this time, the static language code of each script module obtained by translation includes API implementation code, cacheable variables and initialization processes, function definitions within the class, specific implementations within the functions, etc.). And combine the static language code and in-class architecture of each script module to obtain four files: 1. Fill the function definitions within the class obtained by translating with the Cython tool into the in-class architecture of each script module, and export an architecture file containing the in-class architectures of multiple script modules; 2. Export the common code (such as API implementation code) between the static language codes corresponding to multiple script modules as a source file or a header file; 3. Export an initialization file containing the cacheable variables and initialization processes within each script module; 4. Export a function implementation file containing the specific implementations within each function.

[0172] Finally, integrate the four files (architecture file, source file or header file, initialization file, function implementation file) into an overall file library to serve as the target code file.

[0173] c5. Compile the target code file into the running engine.

[0174] Exemplarily, the target code file can be compiled into a Python extension module with the suffix.so and added to the engine file database, so that the target script version function can be translated into the target static version function and compiled into the running engine, for the running engine to call the target static version function from the engine database.

[0175] The above takes the translation of the script module based on the Cython tool and the Pynos tool as an example to illustrate the method of generating the target code file in steps c1 to c4.

[0176] Among them, the Cython tool is a tool for automatically translating script language code (such as Python code) into static language code (such as C++ code). However, if the Cython tool is directly used to translate the script module, there will be the following three problems:

[0177] ① The Cython tool realizes static language translation in units of modules, so it is not conducive to the function-level sinking in the static language translation by the Cython tool;

[0178] ② The Cython tool translates each script module into a library file, and there is a large amount of API implementation code in each generated library file. There is a large amount of common code (such as API implementation code) between multiple library files corresponding to multiple script modules.

[0179] ③ The Cython tool does not consider the situation of extracting some code for use in other external projects, so there is no way to conveniently intercept its common code (in fact, it cannot be done either, because if the interception is performed, the entire code generation process of the Cython tool will be disrupted, resulting in the inability to generate normal code).

[0180] Therefore, in this embodiment, while using the Cython tool to implement the translation of the script module, the Pynos tool is also introduced to implement the translation of the script module to effectively solve the above three problems. In this embodiment, the Pynos tool is a tool for automatically translating script language code (such as Python code) into static language code (such as C++ code). Specifically, the idea of the Pynos tool to solve the above three problems is mainly:

[0181] ① Generate a complete class system structure for the script module through the Pynos tool, extract the static language code generated by the Cython tool, and write the static language code finally corresponding to the script module according to the in-class system structure, which is conducive to the function-level sinking.

[0182] Specifically, in steps c1 to c4, first, data information of the script module is obtained through static analysis of the script module, and the in-class architecture of the script module is generated by the Pynos tool. Then, the data information of the script module is read by the Cython tool, and in combination with the in-class architecture of the script module, a corresponding static class (i.e., a C++ class) is generated for each script class (such as a Python class) in the script module and filled into the in-class architecture of the script module to obtain a system file containing the in-class architectures of multiple script modules.

[0183] ② Modify the source code of the Cython tool from the following three aspects to avoid a large amount of common code between multiple script modules corresponding to multiple library files and redundant code in script module translation:

[0184] First, for the Cython tool, the API is only provided for use within the module. Therefore, each API is a static function and consists of both a definition and an implementation part. In this embodiment, on the one hand, the part that processes the API as a static function is removed, and a large number of unnecessary API definition parts are also removed, only the implementation part is retained. On the other hand, for the Cython tool, _module_ and _dict_ within the module are both static variables. Therefore, the API can directly operate on these two variables by default. To extract the API implementation code of multiple script modules into a common part, the APIs that use _module_ and _dict_ are processed by passing in parameters.

[0185] Second, remove the processing in the Cython tool for dealing with Python multithreading. Since for the client and the server, the main logic of processing does not use multithreading, the code inserted to deal with multithreading not only increases the difficulty of understanding and the complexity of the generated code for single-threaded code, but also consumes some optimization performance. Therefore, to reduce redundant code in script module translation, the processing in the Cython tool for dealing with Python multithreading can be removed. "Removing the processing in the Cython tool for dealing with Python multithreading" is a reversible operation and can be added back again if necessary.

[0186] Furthermore, through code embedding, create four files (system file, source file or header file, initialization file, function implementation file) and place them respectively: the class architecture and function definitions within the class, the common code between the static language codes corresponding to multiple script modules, the cacheable variables and initialization process of multiple script modules, and the specific implementation within the function.

[0187] ③The hook method is used to process the code that needs to be exported from the Cython tool (referred to as the hook operation), such as the cacheable variables of the script module and the specific implementation within the function. Specifically, a hooker is injected into the code of the Cython tool. When the code of the Cython tool performs a write operation, the exported code will be synchronized through the hooker, thereby realizing the export of code from the Cython tool. In this embodiment, the hooker is divided into three major categories:

[0188] The first is the module-level hooker, which is used to export the module hooker of the global file of the script module. Exemplarily, the module-level hooker may include the following parts:

[0189] root_writer, which is used to embed some common code of the module, such as including part of the pynos module, determining the naming scope of the module, etc.;

[0190] init_declare_writer, which is used to embed the initialization code of all cacheable variables used within the module;

[0191] init_end_writer, which processes the end work of the above initialization code. This part and the above part are separately processed in Cython, so separate hook operations are required;

[0192] init_subfunc_writer, which processes the initialization code of internal functions. For internal functions, the processing method of Cython is independent of ordinary functions, so separate hook operations are required;

[0193] lambda_writer, which is used to process the initialization of lambda functions.

[0194] The second is the function-level hooker, which is used to export the code within the function body and the surrounding code. Exemplarily, the function-level hooker may include the following parts:

[0195] definition_handle, which processes the hook operation of the definition part of the parameter conversion function;

[0196] definition_handle, which processes the hook operation of the parameters of the parameter conversion function itself;

[0197] body_handle, which processes the hook operation of the content part of the actual function body;

[0198] body_arg_handle, which processes the hook operation of the parameter part of the actual function body;

[0199] body_return_handle, a hook operation for processing the return value part of the actual function body.

[0200] body_handle_NosTmp, processes some class system codes that Pynos needs to insert into Cython to prepare for subsequent direct access to sinking attributes;

[0201] method_decorator_handle, processes the code embedding of functions with sinking identifiers. This part of the code is outside the function body and is generally initialized at the module level.

[0202] The third is the special structure hooker, which is used to export the code of special structures used to further optimize performance. Exemplarily, the special structure hooker may include the following parts:

[0203] opt_arg_struct_handle, a hook operation for processing the definition part of the special structure;

[0204] body_helper_handle, in the case of using a special structure, an additional helper function is required to convert ordinary pyobjects into the required structure. Therefore, a hook operation is also performed on it and embedded into Pynos;

[0205] body_helper_arg_handle, a hook operation for the parameter part of the helper function.

[0206] It can be seen that in steps c1 to c5, on the one hand, by combining the in-class system structures of each script module to generate target code files corresponding to multiple script modules and compiling them into the running engine, the generated target code files conform to the class system structures of the script modules, improving the readability of the generated code; on the other hand, by extracting common code as source files to generate target code files, a large amount of redundant common code can be removed from the generated target code files, reducing the file size compiled into the running engine.

[0207] To better understand the embodiments of the present application, as Figure 6 shown, taking the target application as a game application, the script language as the Python language, the static language as the C++ language, the script version function as the Python version function, the static version function as the C++ version function, and using the member variable value of the script version function to generate the MD5 value as the version information of the script version function as an example, the switching between the static version function and the dynamic version function during the hot update process (i.e., during the application running process) is described. At this time, the application running method specifically includes the following steps (1) to (5):

[0208] (1) The script module in the engine file library of the game application changes for hot update.

[0209] (2) Switch the function used to run the game application from the C++ version to the Python version. For the specific switching process, please refer to the previous text and Figure 2 and Figure 3 the descriptions in the relevant parts. For simplicity of expression, they will not be elaborated here.

[0210] (3) Perform the sinking operation of the script module. For the specific process, please refer to the descriptions in the relevant parts of step 105 in the previous text. For simplicity of expression, they will not be elaborated here.

[0211] (4) Try to switch the function from the Python version to the C++ version. Specifically, calculate the MD5 value of the updated Python version function as the version information of the updated Python version function, and obtain the MD5 value of the record associated with the function identifier of the Python version function in the engine file library as the version information of the C++ version function in the engine file library.

[0212] (5) If the version information of the updated Python version function is the same as that of the C++ version function, it proves that the script module has been successfully sunk and the C++ version function in the engine file library has been updated. Therefore, the function used to run the game application can be switched back from the Python version to the C++ version. If the version information of the updated Python version function is different from that of the C++ version function, it proves that the script module has not been successfully sunk and the C++ version function in the engine file library has not been updated. Therefore, continue to use the Python version function to run the game application to ensure the correctness of the operation logic of the game application. Further, if the script module has not been successfully sunk, it can also re-enter step (4) until the script module has been successfully sunk, and then switch the function used to run the game application from the Python version back to the C++ version.

[0213] To better implement the above method, the embodiment of the present application also provides an application running device. The application running device can be specifically integrated in an electronic device, such as a computer device, and the computer device can be a device such as a terminal or a server.

[0214] Among them, the terminal can be a device such as a mobile phone, a tablet computer, a smart Bluetooth device, a laptop computer, or a personal computer; the server can be a single server or a server cluster composed of multiple servers.

[0215] For example, in this embodiment, taking the application running device specifically integrated in a computer as an example, the method of the embodiment of the present application will be described in detail.

[0216] For example, asFigure 7 As shown, the application running device 700 may include:

[0217] A calling unit 701, configured to call a target script version function in the engine file library to run the target application after a hot update occurs when a script module in the engine file library of the target application changes;

[0218] A first obtaining unit 702, configured to obtain first version information of a target static version function corresponding to the target script version function in the engine file library;

[0219] A second obtaining unit 703, configured to obtain second version information of the target script version function;

[0220] The calling unit 701 is further configured to call the target static version function to run the target application if the first version information and the second version information match.

[0221] In some embodiments, the calling unit 701 is specifically configured to:

[0222] If the first version information and the second version information do not match, continue to call the target script version function to run the target application.

[0223] In some embodiments, the application running device 700 further includes a recording unit (not shown in the figure). Before obtaining the first version information of the target static version function corresponding to the target script version function in the engine file library, the recording unit is specifically configured to:

[0224] When writing the static version function corresponding to the script version function of the target application into the engine file library, obtain the version information of the script version function;

[0225] Associate and record the version information of the script version function with the function identifier of the script version function in the engine file library;

[0226] In some embodiments, the first obtaining unit 702 is specifically configured to:

[0227] Obtain the function identifier of the target script version function;

[0228] Obtain, from the engine file library, the version information of the script version function associated and recorded with the function identifier of the target script version function as the first version information.

[0229] In some embodiments, the second obtaining unit 703 is specifically configured to:

[0230] When the script module is compiled, obtain the second version information of the target script version function.

[0231] In some embodiments, the application running device 700 further includes a sinking unit (not shown in the figure), and the sinking unit is specifically configured to:

[0232] Execute the sinking operation of the script module, where the sinking operation includes translating the target script version function into a static version function and compiling it into the running engine of the target application.

[0233] In some embodiments, the sinking unit is specifically configured to:

[0234] Obtain the type definition file of the script module, where the type definition file contains the static type information of the target script version function;

[0235] Generate the static language code corresponding to the script module based on the type definition file, where the static language code contains the target static version function;

[0236] Compile the static language code into the running engine to obtain a static extension module corresponding to the script module, where the static extension module is used to provide the target static version function for the running engine.

[0237] In some embodiments, the application running device 700 further includes a preprocessing unit (not shown in the figure). Before obtaining the static type information of the target script version function, the preprocessing unit is specifically configured to:

[0238] Add a sinking identifier to the functions to be sunk in the script module;

[0239] Obtain the functions in the script module with the sinking identifier as the target script version function.

[0240] In some embodiments, the application running device 700 further includes a preprocessing unit (not shown in the figure). The static type information includes at least one of the type identifier of the formal parameters of the target script version function and the type identifier of the return value of the target script version function. Before obtaining the static type information of the target script version function, the preprocessing unit is specifically configured to:

[0241] Add type identifiers to the formal parameters and return values of the target script version function in the script module;

[0242] In some embodiments, the sinking unit is specifically configured to:

[0243] Perform static analysis on the script module to obtain the data information of the script module, where the data information includes at least one of the type identifier of the formal parameters of the target script version function and the type identifier of the return value of the target script version function;

[0244] Obtain the type definition file based on at least one of the type identifier of the formal parameter of the target script version function and the type identifier of the return value of the target script version function.

[0245] In some embodiments, the target application includes a plurality of the script modules, and the sinking unit is specifically configured to:

[0246] Obtain the static language codes corresponding to each of the script modules, and obtain the static language codes corresponding to the plurality of script modules, wherein the static language codes corresponding to the plurality of script modules include the target static version function;

[0247] Extract the common code among the static language codes corresponding to the plurality of script modules;

[0248] Obtain the intra-class architecture of each of the script modules;

[0249] Generate target code files corresponding to the plurality of script modules based on the common code and the intra-class architecture;

[0250] Compile the target code files into the running engine.

[0251] In some embodiments, the calling unit 701 is specifically configured to:

[0252] After a hot update occurs when a script module in the engine file library of the target application changes, determine whether there is a difference in the target script version function in the engine file library before and after the hot update;

[0253] If there is a difference in the target script version function before and after the hot update, then call the target script version function to run the target application.

[0254] As can be seen from the above, after the script module in the engine file library of the target application is hot updated by the calling unit 701 of the application running device 700 in this embodiment, the target script version function in the engine file library is called to run the target application; the first acquisition unit 702 acquires the first version information of the target static version function corresponding to the target script version function in the engine file library; the second acquisition unit 703 acquires the second version information of the target script version function; if the first version information and the second version information match, the calling unit 701 calls the target static version function to run the target application. Thus, after the script module in the engine file library of the target application is hot updated, the application running device 700 in the embodiment of the present application will call the target script version function in the engine file library to run the target application. When the first version information of the target static version function in the engine file library matches the second version information of the target script version function in the engine file library, the target script version function in the engine file library will be called to run the target application; therefore, even when the target application is run during the sinking operation of the target script version function, the correctness of the application running logic can still be ensured, so that the static version function obtained by sinking the script version function can still implement hot updates.

[0255] Correspondingly, the embodiment of the present application further provides an electronic device. The electronic device may be a terminal, and the terminal may be a smart phone, a tablet computer, a notebook computer, a touch screen, a game console, a personal computer (PC, Personal Computer), a personal digital assistant (Personal Digital Assistant, PDA), and other terminal devices. As Figure 8 shown, Figure 8 is a schematic structural diagram of the electronic device provided by the embodiment of the present application. The electronic device 800 includes a processor 801 with one or more processing cores, a memory 802 with one or more computer-readable storage media, and a computer program stored in the memory 802 and executable on the processor. Among them, the processor 801 is electrically connected to the memory 802. Those skilled in the art can understand that the structural diagram of the electronic device shown in the figure does not constitute a limitation on the electronic device, and it may include more or fewer components than shown in the figure, or combine some components, or have different component arrangements.

[0256] The processor 801 is the control center of the electronic device 800, connects various parts of the entire electronic device 800 through various interfaces and lines, executes various functions of the electronic device 800 and processes data by running or loading software programs and / or modules stored in the memory 802, and calling data stored in the memory 802, thereby monitoring the entire electronic device 800.

[0257] In an embodiment of the present application, the processor 801 in the electronic device 800 loads instructions corresponding to the processes of one or more application programs into the memory 802 according to the following steps, and the processor 801 runs the application programs stored in the memory 802, thereby implementing various functions:

[0258] After the script module in the engine file library of the target application is hot updated when it changes, call the target script version function in the engine file library to run the target application;

[0259] Obtain the first version information of the target static version function corresponding to the target script version function in the engine file library;

[0260] Obtain the second version information of the target script version function;

[0261] If the first version information and the second version information match, call the target static version function to run the target application.

[0262] In some embodiments, the method further includes:

[0263] If the first version information and the second version information do not match, continue to call the target script version function to run the target application.

[0264] Before obtaining the first version information of the target static version function corresponding to the target script version function in the engine file library, in some embodiments, it further includes:

[0265] When writing the static version function corresponding to the script version function of the target application into the engine file library, obtain the version information of the script version function;

[0266] Associate and record the version information of the script version function with the function identifier of the script version function in the engine file library;

[0267] The obtaining of the first version information of the target static version function corresponding to the target script version function in the engine file library includes:

[0268] Obtain the function identifier of the target script version function;

[0269] Obtain the version information of the script version function associated and recorded with the function identifier of the target script version function from the engine file library as the first version information.

[0270] In some embodiments, the obtaining of the second version information of the target script version function includes:

[0271] When the script module is compiled, obtain the second version information of the target script version function.

[0272] In some embodiments, the method further includes:

[0273] Performing a sinking operation on the script module, where the sinking operation includes translating the target script version function into a static version function and compiling it into the running engine of the target application.

[0274] In some embodiments, performing the sinking operation on the script module includes:

[0275] Obtaining a type definition file of the script module, where the type definition file contains static type information of the target script version function;

[0276] Generating static language code corresponding to the script module based on the type definition file, where the static language code contains the target static version function;

[0277] Compiling the static language code into the running engine to obtain a static extension module corresponding to the script module, where the static extension module is used to provide the target static version function for the running engine.

[0278] In some embodiments, before obtaining the static type information of the target script version function, it further includes:

[0279] Adding a sinking identifier to the functions to be sunk in the script module;

[0280] Obtaining the functions with sinking identifiers in the script module as the target script version functions.

[0281] In some embodiments, the static type information includes at least one of a type identifier of a formal parameter of the target script version function and a type identifier of a return value of the target script version function. Before obtaining the static type information of the target script version function, it further includes:

[0282] Adding type identifiers to the formal parameters and return values of the target script version functions in the script module;

[0283] Obtaining the static type information of the target script version function includes:

[0284] Performing static analysis on the script module to obtain data information of the script module, where the data information includes at least one of a type identifier of a formal parameter of the target script version function and a type identifier of a return value of the target script version function;

[0285] Obtaining the type definition file based on at least one of a type identifier of a formal parameter of the target script version function and a type identifier of a return value of the target script version function.

[0286] In some embodiments, the target application includes a plurality of the script modules, and the performing the sinking operation of the script module includes:

[0287] Obtain the static language code corresponding to each of the script modules, to obtain the static language codes corresponding to the plurality of script modules, wherein the static language codes corresponding to the plurality of script modules include the target static version function;

[0288] Extract the common code between the static language codes corresponding to the plurality of script modules;

[0289] Obtain the intra-class architecture of each of the script modules;

[0290] Generate target code files corresponding to the plurality of script modules based on the common code and the intra-class architecture;

[0291] Compile the target code files into the running engine.

[0292] In some embodiments, after a hot update is performed when a script module in the engine file library of the target application changes, calling the target script version function in the engine file library to run the target application includes:

[0293] After a hot update is performed when a script module in the engine file library of the target application changes, determine whether there is a difference in the target script version function in the engine file library before and after the hot update;

[0294] If there is a difference in the target script version function before and after the hot update, then call the target script version function to run the target application.

[0295] For the specific implementation of each of the above operations, reference may be made to the previous embodiments, and details are not described herein again.

[0296] Optionally, as Figure 8 shown, the electronic device 800 further includes: a touch display screen 803, a radio frequency circuit 804, an audio circuit 805, an input unit 806, and a power supply 807. Among them, the processor 801 is electrically connected to the touch display screen 803, the radio frequency circuit 804, the audio circuit 805, the input unit 806, and the power supply 807 respectively. Those skilled in the art can understand that Figure 8 the structure of the electronic device shown in

[0297] The touch display screen 803 can be used to display a graphical user interface and receive operation instructions generated by a user acting on the graphical user interface. The touch display screen 803 may include a display panel and a touch panel. Among them, the display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, videos, and any combination thereof. Optionally, the display panel can be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like. The touch panel can be used to collect touch operations of the user on or near it (such as operations of the user using a finger, a stylus, or any suitable object or accessory on or near the touch panel), and generate corresponding operation instructions, and the operation instructions execute the corresponding program. Optionally, the touch panel can include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the touch position of the user and detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact coordinates, and then sends it to the processor 801, and can receive and execute the commands sent by the processor 801. The touch panel can cover the display panel. After the touch panel detects a touch operation on or near it, it is transmitted to the processor 801 to determine the type of touch event. Subsequently, the processor 801 provides a corresponding visual output on the display panel according to the type of touch event. In the embodiments of the present application, the touch panel and the display panel can be integrated into the touch display screen 803 to implement input and output functions. However, in some embodiments, the touch panel and the touch panel can be implemented as two independent components to implement input and output functions. That is, the touch display screen 803 can also be used as part of the input unit 806 to implement the input function.

[0298] The radio frequency circuit 804 can be used to transmit and receive radio frequency signals to establish wireless communication with a network device or other electronic devices through wireless communication, and transmit and receive signals with the network device or other electronic devices.

[0299] The audio circuit 805 can be used to provide an audio interface between the user and the electronic device through a speaker and a microphone. The audio circuit 805 can transmit the electrical signal after converting the received audio data to the speaker, and the speaker converts it into a sound signal for output; on the other hand, the microphone converts the collected sound signal into an electrical signal, which is received by the audio circuit 805 and then converted into audio data. After the audio data is output to the processor 801 for processing, it is transmitted through the radio frequency circuit 804 to, for example, another electronic device, or the audio data is output to the memory 802 for further processing. The audio circuit 805 may also include an earphone jack to provide communication between a peripheral earphone and the electronic device.

[0300] The input unit 806 can be used to receive input digital, character information or user feature information (such as fingerprint, iris, face information, etc.), and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function controls.

[0301] The power supply 807 is used to supply power to each component of the electronic device 800. Optionally, the power supply 807 can be logically connected to the processor 801 through a power management system, so as to realize functions such as management of charging, discharging, and power consumption management through the power management system. The power supply 807 can also include any components such as one or more DC or AC power supplies, a recharge system, a power failure detection circuit, a power converter or inverter, and a power status indicator.

[0302] Although Figure 8 not shown in the figure, the electronic device 800 may also include a camera, a sensor, a Wi-Fi module, a Bluetooth module, etc., which will not be elaborated here.

[0303] In the above embodiments, the descriptions of each embodiment have their own emphases. For parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0304] As can be seen from the above, for the electronic device provided in this embodiment, after the script module in the engine file library of the target application changes and is hot updated, the target script version function in the engine file library is called to run the target application; the first version information of the target static version function corresponding to the target script version function in the engine file library is obtained; the second version information of the target script version function is obtained; if the first version information and the second version information match, the target static version function is called to run the target application. Since after the script module in the engine file library of the target application changes and is hot updated, the electronic device provided in this embodiment will call the target script version function in the engine file library to run the target application, and when the first version information of the target static version function in the engine file library matches the second version information of the target script version function in the engine file library, the target script version function in the engine file library will be called to run the target application; therefore, even when running the target application during the sinking operation of the target script version function, the correctness of the application running logic can still be ensured, so that the static version function obtained by sinking the script version function can still implement hot update.

[0305] Those of ordinary skill in the art can understand that all or part of the steps in the above various methods can be completed by instructions, or by controlling relevant hardware through instructions. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0306] To this end, an embodiment of the present application provides a computer-readable storage medium, which stores multiple computer programs that can be loaded by a processor to execute the steps in any of the application running methods provided by the embodiments of the present application. For example, the computer program can execute the following steps:

[0307] After the script module in the engine file library of the target application is hot updated due to a change, call the target script version function in the engine file library to run the target application;

[0308] Obtain the first version information of the target static version function corresponding to the target script version function in the engine file library;

[0309] Obtain the second version information of the target script version function;

[0310] If the first version information and the second version information match, call the target static version function to run the target application.

[0311] In some embodiments, the method further includes:

[0312] If the first version information and the second version information do not match, continue to call the target script version function to run the target application.

[0313] Before obtaining the first version information of the target static version function corresponding to the target script version function in the engine file library, it further includes:

[0314] When writing the static version function corresponding to the script version function of the target application into the engine file library, obtain the version information of the script version function;

[0315] Associate and record the version information of the script version function with the function identifier of the script version function in the engine file library;

[0316] The obtaining of the first version information of the target static version function corresponding to the target script version function in the engine file library includes:

[0317] Obtain the function identifier of the target script version function;

[0318] From the engine file library, obtain the version information of the script version function associated and recorded with the function identifier of the target script version function as the first version information.

[0319] In some embodiments, the obtaining of the second version information of the target script version function includes:

[0320] When the script module is compiled, obtain the second version information of the target script version function.

[0321] In some embodiments, the method further includes:

[0322] Performing a sinking operation on the script module, where the sinking operation includes translating the target script version function into a static version function and compiling it into the running engine of the target application.

[0323] In some embodiments, performing the sinking operation on the script module includes:

[0324] Obtaining the type definition file of the script module, where the type definition file contains the static type information of the target script version function;

[0325] Generating static language code corresponding to the script module based on the type definition file, where the static language code contains the target static version function;

[0326] Compiling the static language code into the running engine to obtain a static extension module corresponding to the script module, where the static extension module is used to provide the target static version function for the running engine.

[0327] In some embodiments, before obtaining the static type information of the target script version function, it further includes:

[0328] Adding a sinking identifier to the functions to be sunk in the script module;

[0329] Obtaining the functions with the sinking identifier in the script module as the target script version functions.

[0330] In some embodiments, the static type information includes at least one of the type identifier of the formal parameters of the target script version function and the type identifier of the return value of the target script version function. Before obtaining the static type information of the target script version function, it further includes:

[0331] Adding type identifiers to the formal parameters and return values of the target script version function in the script module;

[0332] The obtaining of the static type information of the target script version function includes:

[0333] Performing static analysis on the script module to obtain data information of the script module, where the data information includes at least one of the type identifier of the formal parameters of the target script version function and the type identifier of the return value of the target script version function;

[0334] Obtaining the type definition file based on at least one of the type identifier of the formal parameters of the target script version function and the type identifier of the return value of the target script version function.

[0335] In some embodiments, the target application includes a plurality of the script modules, and performing the sinking operation of the script modules includes:

[0336] Obtain the static language code corresponding to each of the script modules, to obtain the static language codes corresponding to the plurality of script modules, wherein the static language codes corresponding to the plurality of script modules include the target static version function;

[0337] Extract the common code among the static language codes corresponding to the plurality of script modules;

[0338] Obtain the in-class architecture of each of the script modules;

[0339] Generate target code files corresponding to the plurality of script modules based on the common code and the in-class architecture;

[0340] Compile the target code files into the running engine.

[0341] In some embodiments, after a hot update is performed when a script module in the engine file library of the target application changes, calling the target script version function in the engine file library to run the target application includes:

[0342] After a hot update is performed when a script module in the engine file library of the target application changes, determine whether there is a difference in the target script version function in the engine file library before and after the hot update;

[0343] If there is a difference in the target script version function before and after the hot update, then call the target script version function to run the target application.

[0344] It can be seen that the computer program can be loaded by the processor to execute the steps in any of the application running methods provided in the embodiments of the present application, thereby bringing the following technical effects: Even when running the target application during the sinking operation of the target script version function, the correctness of the application running logic can still be ensured, so that the static version function obtained by sinking the script version function can still implement hot update.

[0345] For the specific implementation of each of the above operations, reference can be made to the previous embodiments, and details are not described herein again.

[0346] Wherein, the computer-readable storage medium may include: read-only memory (ROM, Read Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disc, etc.

[0347] Since the computer program stored in the computer-readable storage medium can execute the steps in any of the application running methods provided in the embodiments of the present application, the beneficial effects achievable by any of the application running methods provided in the embodiments of the present application can be realized. For details, refer to the previous embodiments and will not be elaborated herein.

[0348] The above has introduced in detail an application running method, device, electronic device, and computer-readable storage medium provided by the embodiments of the present application. Specific examples are used in this article to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application; at the same time, for those skilled in the art, according to the idea of the present application, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation to the present application.

Claims

1. A method for application running, characterized in that, Including: After a hot update occurs to a script module in the engine file library of a target application, call a target script version function in the engine file library to run the target application; Obtain first version information of a target static version function corresponding to the target script version function in the engine file library, where the first version information refers to the version information of the target script version function that has been sunk into the running engine, that is, the first version information refers to the version information of the static version function in the engine file library that has the same function identifier as the target script version function. Function sinking means translating a script version function into a static version function and then compiling it into the running engine of the target application, and the obtained static version function is stored in the engine file library for the running engine to call; Obtain second version information of the target script version function, where the second version information refers to the version information of the target script version function in the engine file library; If the first version information and the second version information match, call the target static version function to run the target application.

2. The application running method according to claim 1, wherein The method further includes: If the first version information and the second version information do not match, continue to call the target script version function to run the target application.

3. The application running method according to claim 1, characterized in that, Before obtaining the first version information of the target static version function corresponding to the target script version function in the engine file library, it further includes: When writing the static version function corresponding to the script version function of the target application into the engine file library, obtain the version information of the script version function; Associate and record the version information of the script version function with the function identifier of the script version function in the engine file library; The obtaining of the first version information of the target static version function corresponding to the target script version function in the engine file library includes: Obtain the function identifier of the target script version function; From the engine file library, obtain the version information of the script version function associated and recorded with the function identifier of the target script version function as the first version information.

4. The application running method according to claim 1, wherein The obtaining of the second version information of the target script version function includes: When the script module is compiled, obtain the second version information of the target script version function.

5. The application running method according to claim 1, characterized in that, The method further includes: Perform the sinking operation of the script module, where the sinking operation includes translating the target script version function into a static version function and compiling it into the running engine of the target application.

6. The application running method according to claim 5, characterized in that, ​ ​ ​ ​ 7. The application running method according to claim 6, wherein ​ Add a sinking identifier to the function to be sunk in the script module; Obtain the function with the sinking identifier in the script module as the target script version function.

8. The application running method according to claim 6, wherein, The static type information includes at least one of the type identifiers of the formal parameters of the target script version function and the type identifier of the return value of the target script version function. Before obtaining the static type information of the target script version function, it further includes: Add type identifiers to the formal parameters and return values of the target script version function in the script module; The obtaining of the static type information of the target script version function includes: Perform static analysis on the script module to obtain the data information of the script module, where the data information includes at least one of the type identifiers of the formal parameters of the target script version function and the type identifier of the return value of the target script version function; Based on at least one of the type identifier of the formal parameter of the target script version function and the type identifier of the return value of the target script version function, obtain the type definition file.

9. The application running method according to claim 5, wherein The target application includes multiple script modules. The execution of the sinking operation of the script module includes: Obtain the static language code corresponding to each script module to obtain the static language codes corresponding to multiple script modules, where the static language codes corresponding to multiple script modules include the target static version function; Extract the common code between the static language codes corresponding to multiple script modules; Obtain the in-class architecture of each script module; Generate the target code files corresponding to multiple script modules based on the common code and the in-class architecture; Compile the target code files into the running engine.

10. The application running method according to any one of claims 1-9, characterized in that, After a hot update occurs when the script module in the engine file library of the target application changes, call the target script version function in the engine file library to run the target application, including: After a hot update occurs when the script module in the engine file library of the target application changes, determine whether there is a difference in the target script version function in the engine file library before and after the hot update; If there is a difference in the target script version function before and after the hot update, call the target script version function to run the target application.

11. An application running device, characterized in that, Includes: A calling unit for calling the target script version function in the engine file library to run the target application after a hot update occurs when the script module in the engine file library of the target application changes; A first obtaining unit for obtaining the first version information of the target static version function corresponding to the target script version function in the engine file library, where the first version information refers to the version information of the target script version function that has been sunk into the running engine, that is, the first version information refers to the version information of the static version function with the same function identifier as the target script version function in the engine file library. Function sinking means translating the script version function into a static version function and then compiling it into the running engine of the target application, and the obtained static version function is stored in the engine file library for the running engine to call; A second acquisition unit, configured to acquire second version information of the target script version function, where the second version information refers to the version information of the target script version function in the engine file library; The calling unit is further configured to, if the first version information matches the second version information, call the target static version function to run the target application.

12. An electronic device, characterized in that, It includes a processor and a memory, and the memory stores multiple instructions; the processor loads the instructions from the memory to execute the steps in the application running method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores multiple instructions, and the instructions are suitable for being loaded by a processor to execute the steps in the application running method according to any one of claims 1 to 10.

Images