A client logic updating method and device, electronic equipment and storage medium

Abstract

This disclosure provides a client logic update method, apparatus, electronic device, and storage medium. The method may include: in response to determining that client logic of an application needs to be updated, obtaining a program code file of a plug-in program corresponding to the client logic to be updated; wherein the shared interface between the application and the plug-in program is defined based on the Kotlin language; loading the plug-in program into the application according to the obtained program code file; and executing the plug-in program to implement the client logic corresponding to the plug-in program.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of application technology, and more specifically, the embodiments of this disclosure relate to a client logic update method, apparatus, electronic device, and storage medium. Background Technology

[0002] This section is intended to provide background or context for the embodiments of this disclosure as set forth in the claims. The description herein is not intended to be a prior art simply because it is included in this section.

[0003] Native app development refers to the development of applications for a specific platform, which utilizes the development framework, programming language, and libraries provided by that platform.

[0004] In scenarios involving updating the client logic of a released native application, it is usually necessary to re-release a new version of the application so that users can download and install the new version of the client through the app store or an older version of the already installed application client to update the application's client logic.

[0005] This shows that, due to factors such as the app store listing process and user update behavior, the client logic of natively developed applications is difficult to update in a timely manner. Summary of the Invention

[0006] In a first aspect of this disclosure, a client logic update method is provided, the method comprising:

[0007] In response to determining that the client logic of the application needs to be updated, the program code file of the plug-in program corresponding to the client logic to be updated is obtained; wherein, the shared interface between the application and the plug-in program is defined based on the Kotlin language;

[0008] Based on the obtained program code file, the plugin program is loaded into the application.

[0009] Execute the plugin program to implement the client logic corresponding to the plugin program.

[0010] In a second aspect of this disclosure, a client logic update apparatus is provided, the apparatus comprising:

[0011] The first acquisition module is used to acquire the program code file of the plug-in program corresponding to the client logic to be updated in response to determining that the client logic of the application needs to be updated; wherein, the shared interface between the application and the plug-in program is defined based on the Kotlin language.

[0012] The loading module is used to load the plugin program into the application based on the obtained program code file;

[0013] An execution module is used to execute the plug-in program to implement the client logic corresponding to the plug-in program.

[0014] In a third aspect of this disclosure, an electronic device is provided, comprising:

[0015] processor;

[0016] Memory used to store the processor's executable instructions;

[0017] The processor is configured to execute the client logic update method.

[0018] In a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the client logic update method.

[0019] The above-described embodiments of this disclosure have at least the following beneficial effects:

[0020] On the one hand, since the client logic that needs to be updated can be dynamically loaded into the natively developed application as a plugin, and the dynamically distributed plugin can be executed based on the JS engine embedded in the client, the client logic can be updated in a timely manner for the released natively developed application without the need for a new client release, while ensuring high performance after the client logic is updated.

[0021] On the other hand, since the shared interface between natively developed applications and dynamically distributed plugins is defined based on the Kotlin language, it can be shared by the JVM, JS, and Native platforms. Therefore, when developers write plugin code, they do not need to use documentation to uniformly define and use each interface on the native and JS sides, do not need to consider bridging details, and do not need to write corresponding conversion code. Thus, in scenarios where client logic is updated for released natively developed applications, both the timeliness of client logic updates and development efficiency can be guaranteed. Attached Figure Description

[0022] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which:

[0023] Figure 1This is a schematic diagram of a project structure for building a client, provided as an exemplary embodiment.

[0024] Figure 2 This is a schematic diagram of a client logic update process provided in an exemplary embodiment;

[0025] Figure 3 This is a flowchart of a client logic update method provided in an exemplary embodiment;

[0026] Figure 4 This is a schematic diagram illustrating a process for calling a shared interface, provided as an exemplary embodiment.

[0027] Figure 5 This is a block diagram of a client logic update apparatus provided in an exemplary embodiment;

[0028] Figure 6 This is a schematic diagram of a readable storage medium corresponding to a client logic update method provided in an exemplary embodiment;

[0029] Figure 7 This is a schematic diagram of an electronic device capable of implementing the above-described method, provided as an exemplary embodiment.

[0030] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0031] The principles and spirit of this disclosure will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement this disclosure, and are not intended to limit the scope of this disclosure in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0032] Those skilled in the art will recognize that embodiments of this disclosure can be implemented as a system, apparatus, device, method, or computer-readable storage medium. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0033] According to embodiments of this disclosure, a client logic update method, apparatus, electronic device, and computer-readable storage medium are proposed.

[0034] In this document, it should be understood that any number of elements in the accompanying drawings is for illustrative purposes only and not as a limitation, and any naming is for distinction only and has no limiting meaning. Furthermore, the data involved in this disclosure may be data authorized by the user or fully authorized by the parties.

[0035] The principles and spirit of this disclosure will be explained in detail below with reference to several representative embodiments.

[0036] Application Scenarios Overview

[0037] Native app development refers to developing applications for a specific platform, utilizing the platform's development frameworks, languages, and libraries. Applications developed using native technologies typically feature fast response times, high compatibility, and enhanced security.

[0038] In scenarios involving updating the client logic of a released native application, it is usually necessary to re-release a new version of the application so that users can download and install the new version of the client through the app store or an older version of the already installed application client to update the application's client logic.

[0039] This shows that, due to factors such as the app store listing process and user update behavior, the client logic of natively developed applications is difficult to update in a timely manner.

[0040] To enable timely updates to client-side logic in natively developed applications, in one related embodiment, during the development of applications using native technologies, client-side logic that may change subsequently can be moved to the backend. That is, the client-side logic that may change can be developed into a functional interface provided by the application's server. This allows the client to implement the corresponding functions by calling the server-side functional interface, without needing to execute the client-side logic locally. In this way, only a new version of the functional interface corresponding to the updated client-side logic needs to be provided on the application's server, and the client only needs to call the new version of the functional interface provided by the server. This allows for client-side logic updates without requiring a new client release.

[0041] It should be noted that in the embodiments shown above, in some highly interactive business scenarios, the client may need to frequently access the backend, resulting in problems such as reduced business response speed and worsened user experience.

[0042] In another related embodiment, for a released native application, program code corresponding to the client logic to be updated can be written in JavaScript and distributed to the application's client, so that the client can execute the program code corresponding to the client logic to be updated based on the built-in JavaScript engine; in this way, dynamic updates of the client logic can be achieved without the need for a new client release.

[0043] It should be noted that in the embodiments shown above, since the program code corresponding to the dynamically distributed client logic is written in JavaScript, while the program code corresponding to other natively developed client logic is usually written in native development languages ​​such as C / C++, there is a difference in programming languages. Therefore, in the process of writing the program code corresponding to the dynamically distributed client logic, developers also need to use documentation to uniformly define and use the various interfaces on the native and JS (JavaScript) sides respectively, and also need to consider bridging details such as the encoding and decoding of function parameters and return values, and need to write corresponding conversion code, which results in problems such as low development efficiency and high technical requirements for developers.

[0044] Therefore, in scenarios involving updating client-side logic for already released native applications, it is difficult to simultaneously guarantee the timeliness of client-side logic updates, high performance, and development efficiency.

[0045] It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this disclosure, and the implementation of this disclosure is not limited in any way. On the contrary, the implementation of this disclosure can be applied to any applicable scenario. Invention Overview

[0047] In view of this, this disclosure provides a technical solution for dynamically updating the client logic of a natively developed application by using program code written in Kotlin that corresponds to the client logic to be updated.

[0048] Kotlin is a statically typed programming language used for multi-platform development. Because Kotlin code can be compiled into platform-independent Java bytecode for execution by the JVM (Java Virtual Machine), or into JavaScript for running on devices without a JVM, or into platform-specific machine code for direct execution on the machine; therefore, Kotlin code can be shared across JVM, JavaScript, and native platforms.

[0049] In some possible implementations, Kotlin Multiplatform allows for the development of cross-platform applications by first writing source code in the Kotlin language and then compiling it into code for the target platform.

[0050] The core concept of this disclosure is:

[0051] For natively developed applications, in response to determining that the client logic of the application needs to be updated, the program code file of the plugin program corresponding to the client logic to be updated can be obtained; wherein, the shared interface between the application and the plugin program is defined based on the Kotlin language; further, the plugin program can be loaded into the application according to the obtained program code file; further, the plugin program can be executed to implement the client logic corresponding to the plugin program.

[0052] It should be noted that, in the embodiments disclosed herein, the plug-in program corresponding to the client logic to be updated may also be referred to as a dynamic program, which is not specifically limited here.

[0053] For example, see Figure 1 , Figure 1 This is a schematic diagram of a project structure for building a client, provided as an exemplary embodiment. For example... Figure 1 As shown, in the `commonMain` directory, shared interfaces between the native and JS sides of the application can be defined using Kotlin Multiplatform. This means defining shared interfaces and data models between the natively developed application and dynamically deployed plugins. In the `hostMain` directory, the native client-side logic of the application can be written. And in the `jsMain` directory, dynamically deployed client-side logic based on Kotlin / JS can be written. Both the `hostMain` and `jsMain` directories depend on the `commonMain` directory to share the interfaces and data models defined therein. The `hostMain` and `jsMain` directories can be implementers and users of the shared interfaces, and can register and / or use interface instances corresponding to the shared interfaces through their respective runtime environments.

[0054] exist Figure 1 Based on this, please refer to Figure 2 , Figure 2 This is a schematic diagram illustrating a client logic update process as provided in an exemplary embodiment. For example... Figure 2As shown, shared source code can be written using Kotlin Multiplatform, which defines the shared interface and data model between the native and JS sides of the application. Application source code corresponding to the natively developed client logic can be written on the native side, and the application client (i.e., the client before dynamic updates) can be built using client build tools. Plugin source code corresponding to the dynamically deployable client logic can be written on the JS side using Kotlin / JS. Furthermore, for a released natively developed application, in response to determining that the application's client logic needs updating, the application's client can obtain the program code file (such as source code file, bytecode file, etc.) of the plugin program corresponding to the client logic to be updated. Further, the application's client can load the plugin program into the application based on the obtained program code file and the client-embedded JavaScript engine, and execute the plugin program based on the JavaScript engine to implement the client logic corresponding to the plugin program, i.e., implement the updated client logic.

[0055] It should be noted that the specific JavaScript engine embedded in the client is not specifically limited in the embodiments disclosed herein. For example, the client may use, but is not limited to, JavaScript engines such as V8, JavaScriptCore, QuickJS, Rhino, and Hermes.

[0056] In this way, on the one hand, the client logic that needs to be updated can be dynamically loaded into the natively developed application as a plugin, and the dynamically distributed plugin can be executed based on the JS engine embedded in the client. Thus, the client logic can be updated in a timely manner for the released natively developed application without the need for a new client release, while ensuring high performance after the client logic is updated.

[0057] On the other hand, since the shared interface between natively developed applications and dynamically distributed plugins is defined based on the Kotlin language, it can be shared by the JVM, JS, and Native platforms. Therefore, when developers write plugin code, they do not need to use documentation to uniformly define and use each interface on the native and JS sides, do not need to consider bridging details, and do not need to write corresponding conversion code. Thus, in scenarios where client logic is updated for released natively developed applications, both the timeliness of client logic updates and development efficiency can be guaranteed.

[0058] Exemplary methods

[0059] The technical concept of this specification will be described in detail below through specific embodiments.

[0060] In one embodiment of this disclosure, some client logic that does not need to be updated temporarily can be developed based on Kotlin / Native, and another part of the client logic that needs to be updated later can be developed as a plugin based on Kotlin / JS. In scenarios where client logic updates are required for a released native application, there is no need to re-release the client; the plugin can be dynamically distributed, and then dynamically loaded into the native application. The plugin can be executed based on the JavaScript engine embedded in the client to implement the updated client logic.

[0061] Please see Figure 3 , Figure 3 This is a flowchart illustrating a client logic update method as provided in an exemplary embodiment. The method can be applied to the client of an application. The method may include the following steps:

[0062] Step 302: In response to determining that the client logic of the application needs to be updated, obtain the program code file of the plug-in program corresponding to the client logic to be updated; wherein, the shared interface between the application and the plug-in program is defined based on the Kotlin language.

[0063] For example, such as Figure 2 As shown, Kotlin Multiplatform can be used to define shared interfaces and data models between the native and JS sides of an application; application source code corresponding to the natively developed client logic can be written on the native side, and the application client can be built using client build tools; and plugin source code corresponding to dynamically deployable client logic can be written on the JS side based on Kotlin / JS; furthermore, in response to determining that the application's client logic needs to be updated, the application's client can obtain the program code files (such as source code files, bytecode files, etc.) of the plugin program corresponding to the client logic to be updated.

[0064] In some possible implementations, in step 302, the client can determine whether the client logic of the application needs to be updated based on the program manifest obtained from the server. Before obtaining the program code file of the plugin program corresponding to the client logic to be updated in response to determining that the application's client logic needs to be updated, the method may further include:

[0065] Step 308: Obtain the program manifest from the application's server; wherein the program manifest includes module information of at least one functional module contained in the plug-in program, and module information of other functional modules on which the at least one functional module depends;

[0066] Step 310: Determine whether the module information included in the obtained program listing is consistent with the module information included in the previously obtained program listing;

[0067] Step 312: If the module information included in the obtained program manifest is inconsistent with the module information included in the previously obtained program manifest, then it is determined that the client logic of the application needs to be updated.

[0068] For example, such as Figure 2 As shown, based on the plugin source code written in Kotlin / JS on the JS side and the runtime dependencies on the JS side, the plugin's program code file and program manifest can be generated. The program manifest can include at least the module information of at least one functional module contained in the plugin, and the module information of other functional modules that the at least one functional module depends on. The client can periodically or sequentially obtain the latest generated program manifest from the application's server, and can compare the currently obtained program manifest with the previously obtained program manifest to determine whether the module information included in the currently obtained program manifest is consistent with the module information included in the previously obtained program manifest; if they are inconsistent, it can be determined that the application's client logic needs to be updated.

[0069] In step 308, obtaining the program manifest from the application's server may specifically include downloading the program manifest from a CDN (Content Delivery Network).

[0070] For example, the client can download the manifest (e.g., manifest.json file) from the CDN to its local machine according to the URL (uniform resource locator) specified by the user, and can use the kotlinx-serialization-json library to parse the obtained manifest.json file to obtain the module information included in the manifest, and can also sort it according to the topological relationship between the dependencies between the various functional modules.

[0071] In one possible embodiment, in step 308, the program listing may specifically include: the entry function of the plug-in program, module information of at least one functional module included in the plug-in program, and module information of other functional modules on which the at least one functional module depends. Specifically, the module information of each functional module may include: a module identifier and module identifiers of other functional modules on which this functional module depends.

[0072] For example, please refer to Table 1, which is a format definition table for a program listing provided in an exemplary embodiment.

[0073]

[0074] Table 1

[0075] Please also refer to Table 2, which is a format definition table for module information provided in an exemplary embodiment.

[0076]

[0077] Table 2

[0078] Based on the format definitions shown in Tables 1 and 2, the manifest.json file obtained by the client can be as follows:

[0079]

[0080]

[0081] In the manifest.json file shown above, the plugin program contains functional modules identified as "kotlin-kotlin-stdlib-js-ir.js", "runtime.js", and "sample.js". The dependency order of these three functional modules is "sample.js" -> "runtime.js" -> "kotlin-kotlin-stdlib-js-ir.js". The function identifier of the entry function of the plugin program is "com.sample.main", and the module identifier of the functional module where the entry function of the plugin program is located is "sample.js".

[0082] In this case, step 302, obtaining the program code file of the plug-in program corresponding to the client logic to be updated, may specifically include: downloading the program code file corresponding to at least one functional module contained in the plug-in program based on the module information included in the obtained program list, and downloading the program code file corresponding to other functional modules that the at least one functional module depends on.

[0083] For example, continuing with the embodiments shown above, if it is determined that the client logic of the application needs to be updated, the client can download the program code files corresponding to the functional modules identified as "kotlin-kotlin-stdlib-js-ir.js", "runtime.js", and "sample.js" in the plugin program according to the manifest.json file shown above.

[0084] In one possible embodiment, the module information of each functional module may further include: the hash value of the program code file corresponding to the functional module. In this case, before loading the plug-in program into the application based on the obtained program code file, the method may further include: in response to the completion of the program code file download, calculating the hash value of the downloaded program code file; determining whether the hash value in the obtained program manifest is consistent with the calculated hash value; if the hash value in the obtained program manifest is consistent with the calculated hash value, then the integrity verification of the downloaded program code file passes.

[0085] For example, continuing with the above-described embodiment, after downloading the program code file corresponding to the functional module identified as "sample.js" according to the manifest.json file shown above, in response to the completion of the program code file download, the client can calculate the SHA256 digest of the downloaded program code file; further, it can be determined whether the SHA256 digest "aba5e1bff6b4a3c59b0e..." of the program code file corresponding to the functional module in the obtained manifest.json file is consistent with the calculated SHA256 digest; if they are consistent, the integrity verification of the downloaded program code file corresponding to the functional module identified as "sample.js" passes; through a similar process, the client can also perform integrity verification on the downloaded program code files corresponding to the functional modules identified as "kotlin-kotlin-stdlib-js-ir.js" and "runtime.js", which will not be elaborated here.

[0086] Step 304: Load the plugin program into the application based on the obtained program code file.

[0087] For example, after obtaining the program code file of the plugin program corresponding to the client logic to be updated, the client can load the obtained program code file of the plugin program based on the embedded JS engine and according to the dependency relationship between the various functional modules included in the plugin program.

[0088] Continuing with the above-described embodiment, based on the obtained plugin program's code file, since the plugin program contains functional modules identified as "kotlin-kotlin-stdlib-js-ir.js", "runtime.js", and "sample.js", and the dependency order of these three functional modules is "sample.js" -> "runtime.js" -> "kotlin-kotlin-stdlib-js-ir.js", the obtained plugin program's code file can be loaded according to the dependency order.

[0089] In some possible implementations, in step 304, loading the plugin program into the application based on the obtained program code file may specifically include: loading the plugin program into the application based on the QuickJS engine according to the obtained program code file.

[0090] In this case, the obtained program code file may specifically include: the bytecode file of the plugin program corresponding to the client logic to be updated; wherein, the bytecode file of the plugin program may include the QuickJS bytecode file of the plugin program obtained by compiling the source code file of the plugin program written in Kotlin language.

[0091] It should be noted that, in the above-described embodiments, on the one hand, since the QuickJS engine is a lightweight JavaScript engine that includes a JavaScript compiler and interpreter, it has the advantages of small size, fast startup, and fast interpretation and execution speed. Therefore, compared with other JavaScript engines, loading the plugin program into the application based on the QuickJS engine can improve the efficiency of dynamic updates of client logic.

[0092] On the other hand, based on loading and executing the plugin program using the QuickJS engine, by first compiling the source code file of the plugin program written in Kotlin into a bytecode file, and then dynamically distributing the QuickJS bytecode file to the client of the application, the client does not need to perform a compilation process after obtaining the QuickJS bytecode file, which can further improve the efficiency of dynamic updates of client logic.

[0093] Step 306: Execute the plug-in program to implement the client logic corresponding to the plug-in program.

[0094] For example, after the plugin is loaded into the application, the client can execute the entry function of the plugin based on the JS engine to implement the client logic corresponding to the plugin.

[0095] Continuing with the above-described embodiments, after the plugin is loaded into the application, the client can execute the entry function identified as "com.sample.main" based on the embedded JavaScript engine.

[0096] In this embodiment of the disclosure, for a shared interface defined based on the Kotlin language, the JS side and the native side of the application can be the implementer and user of the shared interface, and can register and / or use the shared interface through their respective runtimes.

[0097] To enable those skilled in the art to better understand the embodiments in this disclosure, the following will first be combined with Figure 4 Taking the implementation of the shared interface on the JS side and its use on the native side as an example, this paper introduces the definition, implementation and usage of the shared interface through specific embodiments.

[0098] First, you can start in such Figure 1 The `commonMain` directory, as shown, defines the shared interface and data model between the native and JS sides of the application using Kotlin Multiplatform. It can also automatically generate implementation classes (i.e., bridge classes) encapsulating bridging functionality based on the Kotlin compiler plugin. These implementation classes can inherit the defined shared interface; as shown below:

[0099]

[0100]

[0101] Furthermore, it is possible to, for example Figure 1 In the jsMain directory shown, implement the shared interface (i.e., register an interface instance corresponding to the shared interface), and register a bridge class instance corresponding to the shared interface; as shown below:

[0102]

[0103] Furthermore, it is possible to, for example Figure 1 In the hostMain directory shown, obtain the bridge class instance corresponding to the shared interface; as shown below:

[0104] / / Obtain the bridge class instance corresponding to the shared interface on the native side.

[0105] val sampleService=registry.get <sampleservice>("SampleService")

[0106] Please see Figure 4 , Figure 4 This is a schematic diagram illustrating a process for calling a shared interface, provided as an exemplary embodiment. When a user requests to call the shared interface, it can obtain an automatically generated bridge class instance corresponding to the shared interface. The bridge class instance can serve as a proxy for the actual shared interface instance on the user side. By calling the methods of the bridge class instance, the user can obtain the actual capabilities on the implementation side.

[0107] For example, such as Figure 4 As shown, the JS side of the application can act as the implementer of the shared interface, and the native side of the application can act as the user of the shared interface; the native side can obtain the first type of bridge class instance registered on the JS side corresponding to the shared interface, and can call the first type of bridge class instance (the function defined in it); so that the JS side can respond to the first type of bridge class instance being called, execute the function defined in the first type of bridge class instance, and return the call result to the native side.

[0108] Specifically, please refer to Table 3, which is a data structure table for encapsulating call information provided in an exemplary embodiment.

[0109]

[0110] Table 3

[0111] The native side can encapsulate the call information for the first type of bridge class instance corresponding to the shared interface based on the data structure shown in Table 3, and can use the kotlinx-serialization-json library to encode the call information into a JSON string; further, the native side can pass the JSON string to the JS side through the call channel; further, the JS side can use the kotlinx-serialization-json library to decode the JSON string; further, the JS side can look up the corresponding first type of bridge class instance in the registry based on the "serviceName" field in the decoding result, and can call the function defined in the bridge class instance based on the "function" and "args" fields in the decoding result.

[0112] Based on a similar process, such as Figure 4 As shown, the native side of the application can act as the implementer of the shared interface, and the JS side of the application can act as the user of the shared interface. The JS side can obtain the second type of bridge class instance registered on the native side corresponding to the shared interface, and can call the functions defined in the second type of bridge class instance. This allows the native side to respond to the invocation of the second type of bridge class instance, execute the functions defined in the second type of bridge class instance, and return the call result to the JS side. The specific calling process will not be described in detail here.

[0113] In some possible implementations, the capabilities of the JS side can be used on the native side of the application. In step 306, executing the plugin program may specifically include: executing the entry function of the plugin program to obtain a first type of bridge class instance registered on the JS side corresponding to the shared interface, and calling the first type of bridge class instance; wherein, the first type of bridge class instance includes: a bridge class instance registered on the JS side corresponding to the bridge class of the shared interface in response to registering an interface instance corresponding to the shared interface on the JS side; the bridge class is generated by inheriting the shared interface in response to defining the shared interface based on the Kotlin language.

[0114] For example, since the shared interface between the plugin and the application is defined in the plugin's program code file based on the Kotlin language, and in response to the shared interface being defined in Kotlin, a bridge class corresponding to the shared interface can be automatically generated by inheriting the shared interface; in response to registering an interface instance corresponding to the shared interface on the JS side, a bridge class instance corresponding to the bridge class of the shared interface can be registered on the JS side, and the bridge class instance registered on the JS side can be determined as a first type of bridge class instance corresponding to the shared interface; therefore, in response to the client executing the entry function of the plugin, the client (i.e., the native side) can obtain the first type of bridge class instance corresponding to the shared interface, and can call the first type of bridge class instance, so that the JS side responds to the first type of bridge class instance being called, executes the function defined in the first type of bridge class instance, and returns the call result to the native side.

[0115] In other possible implementations, native capabilities can be used on the JS side of the application. The method may further include: in response to registering an interface instance corresponding to the shared interface on the native side, registering a bridge class instance corresponding to the bridge class of the shared interface on the native side, and identifying the bridge class instance registered on the native side as a second type of bridge class instance corresponding to the shared interface; in response to the second type of bridge class instance being invoked, executing a function defined in the second type of bridge class instance.

[0116] For example, in response to registering an interface instance corresponding to the shared interface on the native side, a bridge class instance corresponding to the bridge class of the shared interface can be registered on the native side, and the bridge class instance registered on the native side can be determined as a second type of bridge class instance corresponding to the shared interface; therefore, the JS side of the application can obtain the second type of bridge class instance corresponding to the shared interface, and can call the second type of bridge class instance, so that the native side responds to the second type of bridge class instance being called, executes the function defined in the second type of bridge class instance, and returns the call result to the JS side.

[0117] It should be noted that in the embodiments shown above, since a bridge class corresponding to the shared interface can be automatically generated in response to the definition of the shared interface, and subsequently, in response to registering an interface instance corresponding to the shared interface on the implementation side, a bridge class instance corresponding to the bridge class of the shared interface can be registered on the implementation side. Therefore, developers do not need to pay too much attention to bridging details when writing the program code of the plugin, thereby improving development efficiency.

[0118] In the above embodiments, on the one hand, since the client logic that needs to be updated can be dynamically loaded into the natively developed application in the form of a plug-in program, and the dynamically distributed plug-in program can be executed based on the JS engine embedded in the client, the client logic can be updated in a timely manner for the released natively developed application without the need for a new version of the client, while ensuring high performance after the client logic is updated.

[0119] On the other hand, since the shared interface between natively developed applications and dynamically distributed plugins is defined based on the Kotlin language, it can be shared by the JVM, JS, and Native platforms. Therefore, when developers write plugin code, they do not need to use documentation to uniformly define and use each interface on the native and JS sides, do not need to consider bridging details, and do not need to write corresponding conversion code. Thus, in scenarios where client logic is updated for released natively developed applications, both the timeliness of client logic updates and development efficiency can be guaranteed.

[0120] Exemplary device

[0121] In an exemplary embodiment of this disclosure, a client logic update apparatus is also provided.

[0122] Please see Figure 5 , Figure 5 This is a block diagram of a client logic update apparatus provided in an exemplary embodiment.

[0123] like Figure 5 As shown, the client logic update device 500 may include: a first acquisition module 502, a loading module 504, and an execution module 506. Wherein:

[0124] The first acquisition module 502 is used to acquire the program code file of the plug-in program corresponding to the client logic to be updated in response to determining that the client logic of the application needs to be updated; wherein, the shared interface between the application and the plug-in program is defined based on the Kotlin language.

[0125] Loading module 504 is used to load the plug-in program into the application based on the obtained program code file;

[0126] The execution module 506 is used to execute the plug-in program to implement the client logic corresponding to the plug-in program.

[0127] In one embodiment, the client logic update device 500 further includes:

[0128] The second acquisition module is used to acquire a program list from the server of the application; wherein the program list includes module information of at least one functional module contained in the plug-in program, and module information of other functional modules on which the at least one functional module depends;

[0129] The determination module is used to determine whether the module information included in the obtained program manifest is consistent with the module information included in the previously obtained program manifest; if the module information included in the obtained program manifest is inconsistent with the module information included in the previously obtained program manifest, then it is determined that the client logic of the application needs to be updated.

[0130] In one embodiment, the first acquisition module 502 is specifically used for:

[0131] Based on the module information included in the obtained program listing, download the program code file corresponding to at least one functional module contained in the plug-in program, and download the program code file corresponding to other functional modules that the at least one functional module depends on.

[0132] In one embodiment, the module information includes the hash value of the program code file corresponding to the functional module;

[0133] The client logic update device 500 also includes:

[0134] A calculation module is used to calculate the hash value of the downloaded program code file in response to the completion of the program code file download;

[0135] The verification module is used to determine whether the hash value in the obtained program listing is consistent with the calculated hash value; if the hash value in the obtained program listing is consistent with the calculated hash value, the integrity verification of the downloaded program code file passes.

[0136] In one embodiment, the loading module 504 is specifically used for:

[0137] Based on the obtained program code file, the plugin program is loaded into the application using the QuickJS engine.

[0138] In one embodiment, the obtained program code file includes: a bytecode file of a plugin program corresponding to the client logic to be updated; wherein, the bytecode file of the plugin program includes a QuickJS bytecode file of the plugin program obtained by compiling the source code file of the plugin program written in Kotlin language.

[0139] In one embodiment, the program listing includes the entry function of the plug-in program;

[0140] The execution module 506 is specifically used for:

[0141] The entry function of the plugin program is executed to obtain a first type of bridge class instance registered on the JS side corresponding to the shared interface, and the first type of bridge class instance is called; wherein, the first type of bridge class instance includes: a bridge class instance registered on the JS side corresponding to the bridge class of the shared interface in response to the interface instance registered on the JS side; the bridge class is generated by inheriting the shared interface in response to the shared interface defined based on the Kotlin language.

[0142] In one embodiment, the client logic update device 500 further includes:

[0143] A generation module is used to respond to registering an interface instance corresponding to the shared interface on the native side, registering a bridge class instance corresponding to the bridge class of the shared interface on the native side, and determining the bridge class instance registered on the native side as a second type of bridge class instance corresponding to the shared interface.

[0144] The execution module 506 is further configured to execute functions defined in the second type of bridge class instance in response to the second type of bridge class instance being invoked.

[0145] The specific details of each module of the aforementioned client logic update device 500 have been described in detail in the previous description of the client logic update method flow, so they will not be repeated here.

[0146] It should be noted that although several modules or units of the client logic update device 500 are mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0147] Exemplary media

[0148] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, having stored thereon a program product capable of implementing the methods described above. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0149] Please see Figure 6 , Figure 6 This is a schematic diagram of a readable storage medium corresponding to a client logic update method provided in an exemplary embodiment.

[0150] refer to Figure 6 As shown, a readable storage medium 600 for implementing the above-described method according to an embodiment of the present disclosure is described. This medium may be a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the readable storage medium of the present disclosure is not limited thereto. In this disclosure, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0151] The readable storage medium may be any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0152] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0153] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0154] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0155] Exemplary electronic devices

[0156] In an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described client logic update method is also provided.

[0157] Please see Figure 7 , Figure 7 This is a schematic diagram of an electronic device capable of implementing the above-described method, provided as an exemplary embodiment.

[0158] The following reference Figure 7 To describe an electronic device 700 according to such an embodiment of the present disclosure. Figure 7 The electronic device 700 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0159] like Figure 7 As shown, the electronic device 700 is manifested in the form of a general-purpose computing device. The components of the electronic device 700 may include, but are not limited to: at least one processing unit 701, at least one storage unit 702, and a bus 703 connecting different system components (including storage unit 702 and processing unit 701).

[0160] The storage unit stores program code, which can be executed by the processing unit 701, causing the processing unit 701 to perform the steps of the various embodiments described above.

[0161] Storage unit 702 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 7021 and / or a cache memory unit 7022, and may further include a read-only memory unit (ROM) 7023.

[0162] Storage unit 702 may also include a program / tool ​​7024 having a set (at least one) of program modules 7025, such program modules 7025 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may contain the reality of the network environment.

[0163] Bus 703 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0164] Electronic device 700 can also communicate with one or more external devices 704 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 700, and / or with any device that enables electronic device 700 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 705. Furthermore, electronic device 700 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 706. As shown, network adapter 706 communicates with other modules of electronic device 700 via bus 703. It should be understood that, although... Figure 7 As not shown in the diagram, other hardware and / or software modules may be used in conjunction with the electronic device 700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0165] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0166] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0167] It should be noted that although several units / modules or sub-units / modules of the apparatus have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0168] Furthermore, although the operations of the methods disclosed herein are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0169] While the spirit and principles of this disclosure have been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.< / sampleservice>

Claims

1. A client-side logic update method, the method comprising: In response to determining that the client logic of the application needs to be updated, the program code file of the plug-in program corresponding to the client logic to be updated is obtained; wherein, the shared interface between the application and the plug-in program is defined based on the Kotlin language; Based on the obtained program code file, the plugin program is loaded into the application; the obtained program code file includes: the bytecode file of the plugin program corresponding to the client logic to be updated; wherein, the bytecode file of the plugin program includes the QuickJS bytecode file of the plugin program obtained by compiling the source code file of the plugin program written in Kotlin language; Executing the plugin program to implement client logic corresponding to the plugin program includes: executing the entry function of the plugin program to obtain a first type of bridge class instance registered on the JS side corresponding to the shared interface, and calling the first type of bridge class instance so that the JS side responds to the invocation of the first type of bridge class instance by executing the function defined in the first type of bridge class instance, and returning the call result to the native side; wherein, the first type of bridge class instance includes: a bridge class instance registered on the JS side corresponding to the bridge class of the shared interface in response to the registration of the interface instance corresponding to the shared interface; the bridge class is generated by inheriting the shared interface in response to the definition of the shared interface based on the Kotlin language.

2. The method according to claim 1, before obtaining the program code file of the plug-in program corresponding to the client logic to be updated in response to determining that the client logic of the application needs to be updated, the method further includes: Obtain the program manifest from the application's server; wherein the program manifest includes module information of at least one functional module contained in the plug-in program, and module information of other functional modules on which the at least one functional module depends; Determine whether the module information included in the obtained program listing is consistent with the module information included in the previously obtained program listing; If the module information included in the obtained program manifest is inconsistent with the module information included in the previously obtained program manifest, then it is determined that the client logic of the application needs to be updated.

3. The method according to claim 2, wherein obtaining the program code file of the plugin program corresponding to the client logic to be updated includes: Based on the module information included in the obtained program listing, download the program code file corresponding to at least one functional module contained in the plug-in program, and download the program code file corresponding to other functional modules that the at least one functional module depends on.

4. The method according to claim 3, wherein the module information includes the hash value of the program code file corresponding to the functional module; The method further includes: In response to the completion of the download of the program code file, calculate the hash value of the downloaded program code file; Determine whether the hash value in the obtained program listing matches the calculated hash value; If the hash value in the obtained program manifest matches the calculated hash value, then the integrity verification of the downloaded program code file passes.

5. The method according to claim 1, wherein loading the plug-in program into the application based on the obtained program code file comprises: Based on the obtained program code file, the plugin program is loaded into the application using the QuickJS engine.

6. The method according to claim 1, further comprising: In response to registering an interface instance corresponding to the shared interface on the native side, registering a bridge class instance corresponding to the bridge class of the shared interface on the native side, and determining the bridge class instance registered on the native side as a second type of bridge class instance corresponding to the shared interface; In response to the invocation of the second type of bridge class instance, the function defined in the second type of bridge class instance is executed.

7. A client logic update apparatus, the apparatus comprising: The first acquisition module is used to acquire the program code file of the plug-in program corresponding to the client logic to be updated in response to determining that the client logic of the application needs to be updated; wherein, the shared interface between the application and the plug-in program is defined based on the Kotlin language. A loading module is used to load the plugin program into the application based on the obtained program code file; the obtained program code file includes: the bytecode file of the plugin program corresponding to the client logic to be updated; wherein, the bytecode file of the plugin program includes the QuickJS bytecode file of the plugin program obtained by compiling the source code file of the plugin program written in Kotlin language; An execution module is used to execute the plugin program to implement client logic corresponding to the plugin program; including: executing the entry function of the plugin program to obtain a first type of bridge class instance registered on the JS side corresponding to the shared interface, and calling the first type of bridge class instance so that the JS side responds to the invocation of the first type of bridge class instance, executes the function defined in the first type of bridge class instance, and returns the call result to the native side; wherein, the first type of bridge class instance includes: a bridge class instance registered on the JS side corresponding to the bridge class of the shared interface in response to the registration of the interface instance corresponding to the shared interface; the bridge class is generated by inheriting the shared interface in response to the definition of the shared interface based on the Kotlin language.

8. The apparatus according to claim 7, further comprising: The second acquisition module is used to acquire a program list from the server of the application; wherein the program list includes module information of at least one functional module contained in the plug-in program, and module information of other functional modules on which the at least one functional module depends; The determination module is used to determine whether the module information included in the obtained program manifest is consistent with the module information included in the previously obtained program manifest; if the module information included in the obtained program manifest is inconsistent with the module information included in the previously obtained program manifest, then it is determined that the client logic of the application needs to be updated.

9. The apparatus according to claim 8, wherein the first acquisition module is specifically used for: Based on the module information included in the obtained program listing, download the program code file corresponding to at least one functional module contained in the plug-in program, and download the program code file corresponding to other functional modules that the at least one functional module depends on.

10. The apparatus according to claim 9, wherein the module information includes the hash value of the program code file corresponding to the functional module; The device further includes: A calculation module is used to calculate the hash value of the downloaded program code file in response to the completion of the program code file download; The verification module is used to determine whether the hash value in the obtained program listing is consistent with the calculated hash value; If the hash value in the obtained program manifest matches the calculated hash value, then the integrity verification of the downloaded program code file passes.

11. The apparatus according to claim 7, wherein the loading module is specifically used for: Based on the obtained program code file, the plugin program is loaded into the application using the QuickJS engine.

12. The apparatus according to claim 7, further comprising: A generation module is used to respond to registering an interface instance corresponding to the shared interface on the native side, registering a bridge class instance corresponding to the bridge class of the shared interface on the native side, and determining the bridge class instance registered on the native side as a second type of bridge class instance corresponding to the shared interface. The execution module is further configured to execute functions defined in the second type of bridge class instance in response to the second type of bridge class instance being invoked.

13. An electronic device, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to perform the method described in any one of claims 1-6.

14. A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described in any one of claims 1-6.

Images