Information processing method and device, terminal equipment, storage medium and program product

Abstract

The invention relates to an information processing method and device, terminal equipment, a storage medium and a program product. The information processing method comprises the steps that a host application program, a runtime environment corresponding to the host application program and a target plug-in corresponding to the host application program are determined; storing the target plug-in in a plug-in package; wherein the host application program, the runtime environment and the plug-in package are stored independently from one another; and the host application program loads the target plug-in based on the runtime environment. Due to the fact that the host application program, the runtime environment and the plug-in package are stored independently, decoupling of the host application program, the runtime environment and the plug-in package is achieved, complexity of the system is reduced, and light weight of the plug-in package is achieved.

Description

Technical Field

[0001] This disclosure relates to the field of information processing technology, and in particular to an information processing method, apparatus, terminal equipment, storage medium, and computer program product. Background Technology

[0002] With the development of software and computer technology, more and more applications have emerged. Terminal devices typically have an operating system and applications installed, and different applications have different functions. Each application requires some related information to run, and plugins, as one type of application, can perform related tasks. Summary of the Invention

[0003] This disclosure provides an information processing method, apparatus, terminal equipment, storage medium, and computer program product.

[0004] A first aspect of this disclosure provides an information processing method, the method comprising: determining a host application, a runtime environment corresponding to the host application, and a target plugin corresponding to the host application; storing the target plugin in a plugin package; wherein the host application, the runtime environment, and the plugin package are stored independently of each other; and the host application loads the target plugin based on the runtime environment.

[0005] In one embodiment, the number of target plugins is multiple; storing the target plugins in a plugin package includes storing the target plugins into multiple plugin packages.

[0006] In one embodiment, storing the target plugin into multiple plugin packages includes: in response to the number of target plugins being greater than a preset number of plugins that a single plugin package can store, storing the target plugins into multiple plugin packages respectively.

[0007] In one embodiment, storing the target plugin into multiple plugin packages includes: in response to the fact that at least some of the plugin packages correspond to different preset quantities, storing the target plugin into multiple plugin packages according to the size of the preset quantity; wherein the number of target plugins stored in the plugin package is positively correlated with the preset quantity corresponding to the plugin package.

[0008] In one embodiment, storing the target plugin into multiple plugin packages includes: storing the target plugin in each plugin package in response to the fact that the preset number corresponding to each plugin package is the same; wherein the number of target plugins stored in each plugin package is the same, or the number of target plugins stored in at least some of the plugin packages is different.

[0009] In one embodiment, storing the target plugin into multiple plugin packages includes: in response to the number of target plugins being less than a preset number of plugins that a single plugin package can store, storing the target plugin into multiple plugin packages, wherein each plugin package stores one target plugin.

[0010] In one embodiment, storing the target plugin in a plugin package includes: determining whether the target plugin is already stored in the plugin package; and storing the target plugin in the plugin package in response to the fact that the target plugin is not stored in the plugin package.

[0011] In one embodiment, the host application loads the target plugin based on the runtime environment, including: registering a proxy component of the target component in the host application; wherein the proxy component is used to call the target component of the target plugin; generating a plugin class corresponding to the target component within the target plugin; finding and loading the plugin class by calling the proxy component; and loading the target component of the target plugin by calling the plugin class.

[0012] In one embodiment, the target component includes at least one of the following: an activity component; a service component; a broadcast receiver; and a content provider.

[0013] In one embodiment, after loading the target plugin, the method further includes: in response to detecting update information of the target plugin, obtaining the latest version of the target plugin; wherein the latest version has its own call path; creating a first loader; according to the call path, finding and loading the latest version of the target plugin through the first loader; after loading the latest version of the target plugin, updating the target plugin in the plugin package to the latest version.

[0014] In one embodiment, the host application loads the target plugin based on the runtime environment, comprising: the host application loading a first target class of the target plugin through a second loader to implement the function corresponding to the first target class in the host application; the target plugin loading a second target class of other plugins through a third loader to implement the target plugin running according to the second target class; wherein the second loader and the third loader are in a parent delegation model, the second loader is used for the host application to load the class of the target plugin, and the third loader is used for loading the classes of plugins among plugins.

[0015] In one embodiment, the method further includes: the target plugin loading a third target class of the host application through the second loader and the third loader, so as to run the target plugin according to the third target class.

[0016] In one embodiment, the host application contains backup information of the target plugin; the host application loads the target plugin based on the runtime environment, including: when directly loading the target plugin fails, searching for and loading the target plugin using the backup information contained in the host application.

[0017] In one embodiment, the method further includes: expanding the memory space for storing the target file; wherein the target file includes files required to start the host application; storing the target file according to the expanded memory space; wherein the size of the memory space is positively correlated with the startup speed of the host application.

[0018] In one embodiment, the host application loads the target plugin based on the runtime environment, including: determining a whitelist of preloaded classes; and, according to the whitelist, the host application preloads the classes in the target plugin that are on the whitelist via a class loader before starting the target plugin.

[0019] In one embodiment, before loading the target plugin, the method further includes: disabling validation of classes in the target plugin; and loading the target plugin after the class to be loaded is found.

[0020] A second aspect of this disclosure provides an information processing apparatus, comprising: a determining module for determining a host application, a runtime environment corresponding to the host application, and a target plugin corresponding to the host application; a storage module for storing the target plugin in a plugin package; wherein the host application, the runtime environment, and the plugin package are stored independently of each other; and a loading module for the host application to load the target plugin based on the runtime environment.

[0021] A third aspect of this disclosure provides a terminal device, including: a processor and a memory for storing executable instructions capable of running on the processor, wherein: when the processor runs the executable instructions, the executable instructions perform the method described in any of the above embodiments.

[0022] A fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the method described in any of the above embodiments.

[0023] A fifth aspect of this disclosure provides a computer program product, including a computer program or executable instructions, which, when executed by a processor, implement the method described in any of the above embodiments.

[0024] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects:

[0025] The solution in this embodiment determines the host application, the runtime environment corresponding to the host application, and the target plugin corresponding to the host application. The target plugin is stored in a plugin package, with the host application, runtime environment, and plugin package stored independently. The host application loads the target plugin based on the runtime environment. Because the host application, runtime environment, and plugin package are stored independently, they are decoupled, reducing system complexity. The target plugin is stored separately in the plugin package, and the runtime environment is located outside the plugin, thus reducing the size of the plugin package and achieving lightweighting. Furthermore, due to this decoupling, when one component is updated, it is not necessary to bundle the version update information of the other two components together for version updates, thereby achieving independent version updates for each component and enabling dynamic and flexible version updates.

[0026] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0027] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0028] Figure 1 This is a schematic diagram illustrating an information processing method according to an exemplary embodiment;

[0029] Figure 2 This is a schematic diagram illustrating an information processing result according to an exemplary embodiment;

[0030] Figure 3 This is another schematic diagram illustrating a relationship according to an exemplary embodiment;

[0031] Figure 4 This is a schematic diagram illustrating a loading of a target plugin according to an exemplary embodiment;

[0032] Figure 5 This is a schematic diagram illustrating a loading of a target component according to an exemplary embodiment;

[0033] Figure 6 This is a schematic diagram illustrating another information processing method according to an exemplary embodiment;

[0034] Figure 7 This is a schematic diagram illustrating another calling relationship according to an exemplary embodiment;

[0035] Figure 8 This is a schematic diagram illustrating another method for loading a target plugin according to an exemplary embodiment;

[0036] Figure 9 This is a schematic diagram illustrating another information processing method according to an exemplary embodiment;

[0037] Figure 10 This is a schematic diagram illustrating an information processing apparatus according to an exemplary embodiment;

[0038] Figure 11 This is a schematic diagram illustrating a target plugin update according to an exemplary embodiment;

[0039] Figure 12 This is a schematic diagram illustrating another target plugin update according to an exemplary embodiment;

[0040] Figure 13 This is a schematic diagram illustrating an extended memory space according to an exemplary embodiment;

[0041] Figure 14 This is a schematic diagram illustrating the launching of a host application according to an exemplary embodiment;

[0042] Figure 15 This is a schematic diagram illustrating a storage target plugin according to an exemplary embodiment;

[0043] Figure 16 This is a block diagram illustrating a terminal device according to an exemplary embodiment. Detailed Implementation

[0044] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses consistent with some aspects of this disclosure as detailed in the appended claims.

[0045] refer to Figure 1 This is a schematic diagram of an information processing method, which includes:

[0046] S100 determines the host application, the runtime environment corresponding to the host application, and the target plugin corresponding to the host application.

[0047] S200 stores the target plugin in a plugin package; the host application, runtime environment, and plugin package are stored independently of each other.

[0048] S300: The host application loads the target plugin based on the runtime environment.

[0049] The solution in this embodiment can be applied to terminal devices, and the executing entity can be a terminal device, which may include mobile terminal devices and fixed terminal devices. Mobile terminal devices may include mobile phones, tablets, in-vehicle central control devices, wearable devices, smart devices, and aircraft, etc. Smart devices may include smart office equipment, smart home equipment, and robots, etc. Smart home equipment may include smart TVs.

[0050] For the S100, the terminal device has an operating system and installed applications. The operating system and applications can be determined according to business needs and are not limited.

[0051] For example, the operating system may include Android, Microsoft, Apple, and HarmonyOS, and the application may include various types of applications, such as browsers, video players, file processing, instant messaging, and other types of applications.

[0052] The host application can be determined based on application requirements, or the terminal device can determine the host application based on user input to open the application. For example, if the device detects that a user input is applied to an application and opens the application, then that application is identified as the host application.

[0053] For example, an application running in the foreground can be used as a host application.

[0054] For example, any application installed on a terminal device can serve as the host application.

[0055] After determining the host application, you can also determine the runtime environment of the host application.

[0056] The runtime environment refers to the dependencies that a program relies on during its execution (or running). It includes the software layers that support program execution, providing necessary services and resources. The operating system provides an abstraction of the underlying hardware and essential system services, such as file handling and network communication. The runtime environment utilizes these services to support program execution and ensure that the program can run on different hardware and operating systems.

[0057] Each host application has its own matching runtime environment, which can also be used as a plugin to interact with the host application through an interface.

[0058] For example, both the host application and the runtime environment have version information, and the determined version of the host application matches the version of the runtime environment of the host application, and the two are compatible.

[0059] The runtime environment can also provide runtime services and resources for the host application and its related target plugins. The loading and running of target plugins also require the runtime environment.

[0060] The target plugin can be determined based on business needs. The target plugin is a plugin related to the host application. The host application is relative to the target plugin. The target plugin can run on the basis of the host application. The host application can call the target plugin corresponding to the host application, run the target plugin, and implement the function of the target plugin.

[0061] Different target plugins are used when performing different tasks, and for the same host application, different target plugins have different functionalities. After the host application loads a target plugin, the functionality of that target plugin can be implemented on top of the host application.

[0062] For example, the target plugin can be configured online and updated dynamically. The target plugin in the plugin package can be determined according to the task to be executed. After the task to be executed is determined, a plugin call request is sent according to the task to be executed, and the target plugin is called according to the request. The target plugin is then stored in the plugin package.

[0063] For example, different tasks will result in different plugins being invoked by the plugin invocation request, and the target plugins stored in the plugin package will also be different.

[0064] For example, different host applications may have different runtime environments and target plugins. Each host application has matching target plugins and runtime environments.

[0065] For S200, plugin packages are used to store target plugins. Target plugins are located within plugin packages, and the number of plugin packages is not limited and can be determined based on business needs. Each plugin package can store a maximum of a preset number of target plugins, which can also be determined based on business needs and / or the plugin package's configuration parameters.

[0066] For example, the number of target plugins stored in different plugin packages can be the same or different.

[0067] For example, different plugin packages may store different target plugins.

[0068] For example, when there are multiple plugin packages, the target plugins within each plugin package share the same runtime environment, which can provide runtime services and resources for each different target plugin.

[0069] For example, the versions of each target plugin, the runtime environment, and the host application are compatible and matched. This ensures that the host application runs successfully based on the runtime environment, and that each target plugin is successfully loaded and invoked, as well as that each target plugin runs successfully.

[0070] The host application, runtime environment, and plugin packages are stored independently of each other. There is no inclusion or containment relationship between the three in terms of storage, which reduces the size of each part and achieves lightweighting of each part.

[0071] For S300, the host application provides various services that enable the target plugin to be used, including providing loading methods so that the target plugin can be loaded into the host application and network transport protocol, thereby facilitating data exchange between the host application and the target plugin. The host application provides an interface for connecting to the target plugin, enabling the target plugin to exchange data with the host application according to certain rules, thereby realizing the functionality of the target plugin.

[0072] Target plugins are components with independent functions. The functionality of the host application can be adjusted by adding, removing, or modifying the internal functions of plugins. Target plugins depend on the host application to run and achieve their own functionality.

[0073] Once the host application, runtime environment, and target plugin are determined, the host application can load the target plugin based on the runtime environment, thereby facilitating the implementation of the target plugin's functions and processing the corresponding tasks.

[0074] For example, the host application can load multiple target plugins simultaneously. When loading multiple different target plugins, the loading of each different target plugin is independent and does not affect each other.

[0075] refer to Figure 2 This is a schematic diagram illustrating the information processing result obtained through the above embodiments.

[0076] The host application loads and invokes the target plugin through the runtime environment. For example, the host application can interact with the runtime environment by calling an interface, and the runtime environment can also interact with the target plugin by calling an interface, thereby enabling the host application to load and invoke the target plugin.

[0077] Because the host application, runtime environment, and plugin package are stored independently, they are decoupled, reducing system complexity. The plugin package stores the target plugin separately, and the runtime environment resides outside the plugins, thus reducing the plugin package size and achieving lightweight functionality. Furthermore, due to this decoupling, when one component is updated, there's no need to bundle the version updates of the other two components together, enabling independent version updates for each and achieving dynamic and flexible version updates.

[0078] In one embodiment, reference Figure 3 This is a diagram illustrating another type of relationship. Figure 3 This illustrates another relationship between the host application, the runtime environment, and the target plugin. The host application loads the target plugin through the runtime environment. The host application's operation depends on a first library file, the runtime environment's operation depends on both the first and second library files, and the target plugin's operation depends on the second library file.

[0079] The first library file here refers to the file that the host application needs to call during runtime. The first library file ensures the normal operation of the host application. Different host applications have different first library files; each host application has its own unique first library file. Because the host application can change, this first library file also changes dynamically with the host application; it can also be referred to as a dynamic library file.

[0080] The second library file refers to the files required by the target plugin during loading and execution. It ensures the normal operation of the target plugin. The host application does not require the information in the second library file, therefore the host application does not depend on it.

[0081] For example, different target plugins share the same second library file, that is, the second library file is a common file for all target plugins.

[0082] For example, each target plugin has its own second library file. For instance, target plugin 1, target plugin 2, and target plugin 3 each correspond to a different second library file.

[0083] The runtime environment can include Figure 3 The plugins shown, such as the Poros plugin framework, depend on a first library file and a second library file in the runtime environment. The second library file and the first library file can also be used to run the runtime environment. The second library file can include files that the runtime environment needs to call, and the first library file can include files that the runtime environment needs to call.

[0084] Because the host application and runtime environment are stored independently, and the runtime environment is matched with the host application (the host application runs based on the runtime environment), the runtime environment needs to call the relevant files required by the host application to provide it with relevant resources or other information. The first library file includes the files required by both the host application and the runtime environment, so the runtime environment depends on the first library file. This ensures the normal loading and operation of the runtime environment, thereby ensuring the normal operation of the host application.

[0085] Similarly, since the target plugin and the runtime environment are stored independently, and the target plugin runs based on the runtime environment, the runtime environment needs to call the relevant files required by the target plugin to provide it with relevant resources or other information. The second library file includes the files required by both the target plugin and the runtime environment, so the runtime environment depends on the second library file. This ensures the normal loading and operation of the target plugin.

[0086] When the target plugin is updated or when switching between different target plugins, the target plugin can be adjusted by both the runtime environment calling the second library file and the target plugin calling the second library file.

[0087] When the host application changes, the runtime environment may also change. Therefore, after the host application changes, the runtime environment will call the information in the first library file of the changed host application to update and adjust the runtime environment.

[0088] pass Figure 3 The content shown is combined Figure 1 The diagram illustrates the relationships between the host application, runtime environment, and target plugins in more detail. The host application, runtime environment, and target plugins are stored independently; the runtime environment is not released along with the host application, thus reducing the size of the host application. The runtime environment and plugins can also be updated separately, enabling hot updates. Furthermore, this approach reduces reflection and the need to modify the host application during runtime (i.e., no hooks), improving system compatibility.

[0089] In one embodiment, the target plugins in the plugin package can be dynamically updated and adjusted, and the target plugins in the plugin package can also be switched.

[0090] For example, it can include:

[0091] Update the target plugin to a new version; and / or update the target plugin stored in the plugin package according to the business request, wherein different business requests correspond to different target plugins, and different target plugins are used to handle different business.

[0092] If the target plugin already exists in the plugin package, and an update to the target plugin version is detected, or a latest version of the target plugin is detected, then the target plugin in the plugin package can be updated according to the version update request.

[0093] This method allows the target plugin to be updated to the latest version. The latest version includes updates to some functions or patches to vulnerabilities compared to the old version, making it easier to handle the corresponding business through the target plugin and improving the user experience.

[0094] For example, since different business operations may be performed through plugins during the operation of the host application, and different target plugins have different functions, it is necessary to call different target plugins.

[0095] It also allows switching between existing target plugins in the plugin package. The target plugins stored in the plugin package can be adjusted according to business requests. When a target plugin stored in the plugin package matches the current business request, that is, when the target plugin stored in the plugin package is used to handle the business corresponding to the current business request, then the target plugin is kept in the plugin package.

[0096] If a target plugin stored in the plugin package has finished processing the business logic corresponding to that target plugin, and the target plugin stored in the plugin package does not match the current business request, it means that the current business request is the latest business request and the target plugin in the plugin package cannot process the business logic corresponding to that business request. In this case, the target plugin currently stored in the plugin package is deleted, and the target plugin corresponding to the current business request is stored in the plugin package, so that the host application can load and call the target plugin.

[0097] This method allows for the updating of target plugins within the plugin package, while also reducing redundant plugins stored in the package. Only the necessary target plugins are retained, thereby reducing the size of the stored information and the overall size of the plugin package.

[0098] In one embodiment, the number of target plugins is multiple. The number of target plugins can be determined based on business needs and is not limited here.

[0099] S200 stores the target plugin in a plugin package, including:

[0100] Store the target plugin in multiple plugin packages.

[0101] When there are multiple target plugins, storing them in multiple plugin packages can help reduce the number of plugins in a single plugin package and also reduce the possibility of storing all target plugins in the same plugin package. This reduces the possibility of some plugin packages becoming too large, helps to reduce the size of the plugin packages, and achieves lightweighting of each plugin package.

[0102] In one embodiment, when there are multiple target plugins, storing the target plugins in multiple plugin packages includes:

[0103] The target plugins can be evenly distributed across plugin packages based on their quantity. This ensures that each package contains the same number of target plugins, reducing the likelihood of some packages containing too many plugins and thus decreasing package size. It also minimizes uneven distribution of target plugins across packages, resulting in a more balanced distribution.

[0104] In another embodiment, when there are multiple target plugins, the target plugins are stored in multiple plugin packages, including:

[0105] Based on the storage capacity of each plugin package, the target plugin is stored in multiple plugins.

[0106] The larger the storage capacity of the plugin package, the more target plugins it can store; the smaller the storage capacity of the plugin package, the fewer target plugins it can store.

[0107] This method can reduce the occurrence of situations where there are too many target plugins or the storage is full when the storage capacity of a plugin package is small.

[0108] In one embodiment, when there are multiple target plugins, storing the target plugins in multiple plugin packages includes:

[0109] Based on the proportion of information currently stored in the plugin package to the total storage volume of the plugin package, the target plugin is stored in multiple plugins.

[0110] The size of this percentage is negatively correlated with the number of target plugins stored in the plugin package. For example, a larger percentage indicates that the plugin package has less storage space available for information storage, and therefore fewer target plugins can be stored. Conversely, a smaller percentage indicates that the plugin package has more storage space available for information storage, and therefore more target plugins can be stored.

[0111] By storing the target plugin in multiple plugin packages in this way, the proportion of stored content in each plugin package is balanced. This can reduce the situation where the proportion of stored content in some plugin packages is too large, and balance the amount of stored information occupied by each plugin package. This helps to achieve lightweighting of each plugin package and reduce the situation where the amount of stored information occupied by each plugin package is too different.

[0112] In one embodiment, storing the target plugin into multiple plugin packages includes:

[0113] If the number of target plugins exceeds the preset number of plugins that a single plugin package can store, the target plugins are stored in multiple plugin packages.

[0114] Each plugin package may have a size limit, and the number of plugins it can store or the total amount of information it can store may be limited.

[0115] For example, the preset quantity may include the maximum number of plugins that can be stored.

[0116] When the number of target plugins to be loaded exceeds the preset number of plugins that a single plugin package can store, the target plugins can be stored in multiple plugin packages. Each plugin package can store a portion of the target plugins separately. This allows for the storage of target plugins in multiple plugin packages, which helps reduce the number of target plugins stored in each plugin package and thus reduces the possibility of plugin packages becoming too large.

[0117] For example, the target plugins are stored in multiple plugin packages, and the number of target plugins stored in each plugin package is less than the preset number corresponding to each plugin package.

[0118] This method can reduce the number of target plugins stored in the plugin package or reduce the situation where the plugin package becomes too large due to being full, thereby reducing the size of the plugin package.

[0119] In one embodiment, the target plugin is stored in multiple plugin packages, including:

[0120] In response to the fact that at least some plugin packages correspond to different preset quantities, the target plugins are stored in multiple plugin packages according to the size of the preset quantities.

[0121] The number of target plugins stored in the plugin package is positively correlated with the preset number of plugin packages.

[0122] If different plugin packages have different preset numbers of target plugins they can store, then the number of target plugins stored can be based on that preset number. Plugin packages with a larger preset number of target plugins will store more target plugins, while plugin packages with a smaller preset number of target plugins will store fewer target plugins.

[0123] By combining the storage parameters of each plugin package to store target plugins, the problem of excessive plugin package storage ratio caused by storing too many target plugins in a plugin package with a smaller preset number is reduced. It also reduces the situation where the number of target plugins stored in a plugin package with a smaller preset number is greater than the number of target plugins stored in a plugin package with a larger preset number. This can also balance the storage ratio of each plugin package. By storing multiple plugin packages, it helps to achieve lightweight plugin packages.

[0124] In one embodiment, the target plugin is stored in multiple plugin packages, including:

[0125] In response to the condition that the preset number of target plugins is the same for each plugin package, the target plugins are stored in each plugin package. Specifically, the number of target plugins stored in each plugin package is the same, or at least some plugin packages store different numbers of target plugins.

[0126] If the preset quantity of each plugin package is the same, the target plugin can be stored in each plugin package. The number of target plugins stored in each plugin package can be the same, that is, the number of target plugins is evenly distributed among the plugin packages.

[0127] In this case, the number of target plugins stored in each plugin package can be kept consistent, which improves the balance of the number of targets stored in each plugin package. Taking all plugin packages into account, it helps to achieve the overall lightweighting of each plugin package.

[0128] The number of target plugins may differ in at least some plugin packages, and the difference in the number of target plugins stored in a plugin package is not limited.

[0129] For example, each plugin package stores at least a portion of the target plugins.

[0130] This allows target plugins to be randomly stored in multiple plugin packages. Storing target plugins in multiple plugin packages reduces the need to store all plugins in a single plugin package, which helps reduce the number of target plugins stored in a single plugin package and also improves the convenience of target plugin storage.

[0131] For example, the number of target plugins stored in each plugin package is different.

[0132] In one embodiment, storing the target plugin into multiple plugin packages includes:

[0133] If the number of target plugins is less than the preset number of plugins that a single plugin package can hold, the target plugins are stored in multiple plugin packages, with each plugin package storing one target plugin.

[0134] Even if a single plugin package can store all target plugins, it will not store all target plugins in the same plugin package. This reduces the possibility of a single plugin package becoming too large and helps to achieve lightweight plugin packages.

[0135] In one embodiment, storing the target plugin in a plugin package includes:

[0136] Determine if the target plugin is already stored in the plugin package. If the target plugin is not stored in the plugin package, store the target plugin in the plugin package.

[0137] When storing a target plugin in a plugin package, first determine if the target plugin already exists in the package. If it doesn't, then store the target plugin in the package. If it already exists, there's no need to store it again.

[0138] For example, when there are multiple target plugins, it can be determined whether each target plugin has been stored in the plugin package, and target plugins that are not stored in the plugin package can be stored in the plugin package.

[0139] In one embodiment, reference Figure 4 This is a schematic diagram illustrating the loading of a target plugin. The host application loads the target plugin based on the runtime environment, including:

[0140] S301, Register a proxy component for the target component in the host application; wherein, the proxy component is used to call the target component of the target plugin.

[0141] S302 generates the plugin class corresponding to the target component within the target plugin.

[0142] S303 finds and loads plugin classes by calling the proxy component.

[0143] S304 loads the target component of the target plugin by calling the plugin class.

[0144] During the process of loading the target plugin in the host application, a proxy component can be registered in the host application first. This proxy component is a proxy component of the target component and is used to call the target component of the target plugin.

[0145] For example, the target component includes at least one of the following:

[0146] Activity components;

[0147] Service components;

[0148] Broadcast receiver;

[0149] Content provider.

[0150] The method and process of registering proxy components are not limited. For example, the proxy component can be registered in the manifest file of the host application, and the target component in the target plugin can be loaded and started through the proxy component.

[0151] For example, when registering a proxy component, the proxy component to be registered can be determined based on the target component. Different target components correspond to their own proxy components. For instance, if the target component is an Activity component, then the proxy component for that target component is the Activity component. If the target component is a Broadcast Receiver component, then the proxy component for that target component is the Broadcast Receiver component. If the target component is a Service component, then the proxy component for that target component is the Service component. If the target component is a Content Provider component, then the proxy component for that target component is the Content Provider component.

[0152] After identifying the target component of the target plugin, a plugin class corresponding to the target component can be generated within the target plugin. For example, the target plugin can be parsed to obtain the target component contained within it. Based on the parsed target plugin, the class corresponding to the target component in the target plugin can be generated, resulting in the plugin class. The process of generating the plugin class can also be viewed as the process of creating the plugin class.

[0153] The generated plugin class will differ depending on the target component. For example, when the target component is an activity component, the generated plugin class will be the first plugin class; when the target component is a service component, the generated plugin class will be the second plugin class.

[0154] For example, a plugin class can be generated through a proxy component of the target component. For instance, first start the proxy component of the target component, and then create the plugin class for that target component through the started proxy component.

[0155] After obtaining the plugin class of the plugin component, the proxy component is invoked to find and load the plugin class of the target component. Since the plugin class and the target component are associated, the corresponding target component can be determined after finding and loading the plugin class. The target component of the target plugin can then be loaded by invoking the plugin class.

[0156] In this embodiment, since the target plugin is dynamic and not fixed, a proxy component loads the target component within the target plugin. The proxy component acts as an intermediary, decoupling the host application and the target plugin. This reduces the registration of the target component within the target plugin in the host application and minimizes modifications to the host application when the target component changes. While enabling information exchange between the target plugin, the host application, and the operating system, it also maintains the dynamic nature of the target plugin, improving compatibility.

[0157] refer to Figure 5 This is a schematic diagram of loading a target component. Figure 5 The left column lists the target components of the target plugin, the middle column lists the proxy components of the target components, and the right column lists the components that the host application needs to load and invoke. The host application loads the target plugin from the target component through the proxy components.

[0158] In one embodiment, reference Figure 6 This is a diagram illustrating another type of information processing. After loading the target plugin, the method also includes:

[0159] S10, in response to detecting update information of the target plugin, obtain the latest version of the target plugin; wherein, the latest version has its own calling path.

[0160] S20, Create the first loader.

[0161] S30, based on the call path, uses the first loader to find and load the latest version of the target plugin.

[0162] S40 updates the target plugin in the plugin package to the latest version after loading the latest version of the target plugin.

[0163] After the target plugin is loaded, it can also be updated. This embodiment provides an update method.

[0164] After loading the target plugin, if an update is detected, it indicates that the current version of the target plugin is no longer the latest version. The latest version of the target plugin can then be obtained based on this update information.

[0165] There are no limitations on how to detect if a target plugin has been updated. For example, you can detect whether the target plugin has been updated by detecting update operations performed on the update control. Alternatively, you can detect whether the target plugin has been updated by configuring update parameters, which can include the detection frequency, allowing the system to automatically detect updates according to these parameters.

[0166] When an update to the target plugin is detected, the latest version of the target plugin can be obtained directly for updating.

[0167] During an update, a first loader can be created, which is the loader for plugins and can be used to load the target plugin.

[0168] When retrieving the latest version, the target plugin's latest version contains the call path for that version, and the format of this call path is not limited. After creating the first loader, the target plugin's latest version can be found and loaded based on the call path.

[0169] After loading the latest version of the target plugin, you can update the target plugin in the plugin package to the latest version.

[0170] Normally, during the operation of the host application, for the same plugin, there is a loader bound to it. Unloading the loader and updating the plugin are not supported. If the plugin is updated, the host application needs to be exited to load the updated plugin.

[0171] In this embodiment, by creating a first loader, the latest version of the target plugin can be loaded through the first loader, without having to load the latest version of the target plugin through the loader of the current version. That is, the target plugin of the current version is loaded through the existing loader, and the target plugin of the latest version is loaded through the first loader.

[0172] This eliminates the need to exit the host application when updating the target plugin, and then reload the latest version of the target plugin using the loader for the current version. Instead, the latest version of the target plugin can be loaded via the first loader while the host application is running, without exiting the application. This enables dynamic updates of the target plugin version without restarting the host application, minimizing disruption to the user experience and improving overall user satisfaction.

[0173] In one embodiment, the host application loads the target plugin based on the runtime environment, including:

[0174] The host application loads the first target class of the target plugin through the second loader to implement the function corresponding to the first target class in the host application.

[0175] It may also include: the target plugin loading a second target class of other plugins through a third loader, so as to run the target plugin according to the second target class.

[0176] There is a relationship between the second and third loaders. They can have a parent delegation model relationship. The second loader can be the parent loader of the third loader, and the third loader can also be the parent loader of the second loader. This can be determined according to business needs.

[0177] For example, the second and third loaders can be loaders in the system where the host application resides that match the host application and the target plugin.

[0178] For example, the second loader may include the Path Class Loader, and the third loader may include the PluginClass Loader.

[0179] The target plugin can include multiple different classes, each used to implement different functionalities. The first target class can be determined based on business requirements. Different first target classes may have different data types and different instantiated objects. The same applies to the second target class.

[0180] In this embodiment, the class in the target plugin loaded by the host application is denoted as the first target class.

[0181] The second loader is used by the host application to load the target plugin's class. When the host application calls the target plugin, the host application can load the first target class in the target plugin through the second loader.

[0182] When the host application loads the first target class through the second class loader, it can first delegate the task to the parent class loader of the second class loader to find and load the first target class. If the parent class loader of the second class loader can find and load the first target class, then the first target class can be found and loaded through the parent class loader. If the parent class loader of the second class loader cannot find the first target class, then the first target class can be found and loaded through the second class loader.

[0183] If the second class loader has no parent class loader, then the first target class is found and loaded through the second class loader.

[0184] After the host application calls the first target class in the target plugin, it can easily implement the function corresponding to the first target class in the host application.

[0185] Class loaders enable host applications to call target plugins without requiring modifications to the host application or other information, thus improving compatibility and user experience.

[0186] A third-party loader is used to load classes from other plugins. When a target plugin loads classes from other plugins besides itself, the target plugin can use the third-party loader to load classes from those other plugins.

[0187] In this embodiment, the class in other plugins besides the target plugin loaded by the target plugin is denoted as the second target class.

[0188] When a target plugin loads a second target class through a third class loader, it can first delegate the task to the parent class loader of the third class loader to find and load the second target class. If the parent class loader of the third class loader can find and load the second target class, then the second target class can be found and loaded through the parent class loader of the third class loader. If the parent class loader of the third class loader cannot find the second target class, then the second target class can be found and loaded through the third class loader.

[0189] When the third class loader has no parent class loader, the second target class is found and loaded through the third class loader.

[0190] In some cases, the normal operation of a target plugin depends on information from other plugins, thus requiring the target plugin to access that information. Class loaders enable this calling, facilitating inter-plugin communication and ensuring the target plugin's proper recording and operation. Class loaders also improve compatibility and user experience.

[0191] In one embodiment, the information processing method further includes:

[0192] The target plugin loads a third target class of the host application through a second loader and / or a third loader to enable the target plugin to run based on the third target class.

[0193] This embodiment is an example of a target plugin calling a class in the host application. The second and third loaders are also used by the target plugin to load classes in the host application.

[0194] For example, the class that the target plugin needs to call in the host application is denoted as the third target class.

[0195] In some cases, the target plugin's operation depends on information from the host application. In such cases, the target plugin needs to call classes within the host application. Calling a third-party target class facilitates the normal loading and execution of the target plugin.

[0196] In this embodiment, the target plugin can invoke classes in the host application through a second loader and / or a third loader. This reduces modifications to the host application and system when the target plugin changes dynamically, as the loader alone can access the information required by the target plugin, thus improving the user experience.

[0197] In addition, by using a joint lookup mechanism for loading classes, class lookup and loading are reduced, thus lowering the cost of class access.

[0198] In one embodiment, reference Figure 7 This is a diagram illustrating another type of call relationship.

[0199] Figure 7 The diagram illustrates the call relationships between the host application and the target plugin, as well as the call relationships between the target plugin and other plugins.

[0200] When the host application calls the first target class in the target plugin, the first target class can be loaded through the second loader. Figure 7 The second class loader shown has a parent class loader, which includes a fourth class loader and a fifth class loader. The fourth class loader is the highest class loader in the host application and may include the Boot ClassLoader.

[0201] The fifth class loader can include a Delegate Class Loader. The fifth class loader acts as the parent class loader of the second class loader, the fourth class loader acts as the parent class loader of the fifth class loader, and the second class loader acts as the parent class loader of the third class loader. Class loaders with parent-child relationships also have a parent delegation model relationship.

[0202] When the host application calls the first target class in the target plugin, it can first search for and load the first target class through the fourth loader according to the parent delegation model. If the fourth loader cannot find the first target class, then the fifth loader will search for and load the first target class. If the fifth loader cannot find the first target class, then the second loader will search for and load the first target class.

[0203] Similarly, the principle is the same when the target plugin calls a third target class in the host application.

[0204] For example, the fifth loader also includes a second loader, a loaded third loader, and an unloaded third loader. The second loader acts as the parent loader of the loaded third loader, and the loaded third loader acts as the parent loader of the unloaded third loader. When searching for and loading the corresponding target class through this fifth loader, the corresponding target class can first be searched for and loaded through the second loader. If the second loader cannot find the corresponding target class, then the corresponding target class is searched for and loaded through the loaded third loader. If the loaded third loader cannot find the corresponding target class, then the corresponding target class is searched for and loaded through the unloaded third loader.

[0205] In one embodiment, the host application contains backup information for the target plugin.

[0206] S300, the host application loads target plugins based on the runtime environment, including:

[0207] If directly loading the target plugin fails, the target plugin is located and loaded using backup information contained in the host application.

[0208] refer to Figure 8 This is a diagram illustrating another method of loading target plugins, combined with... Figure 8 The content shown indicates that the host application may contain information about the target plugin. This information serves as a backup of the target plugin, and may include all or only part of the target plugin's information.

[0209] When loading the target plugin using its own information, if a loading failure occurs, such as... Figure 8 The exceptions (bugs) shown can be resolved by loading the target plugin using backup information stored in the host application. This reduces the likelihood of target plugin loading errors, improves the success rate and stability of target plugin loading, and thus enhances the user experience.

[0210] For example, backup information can also be used to find target plugins. If the target plugin cannot be found, the backup information can be used to find the target plugin, thereby reducing loading errors caused by search failures.

[0211] For example, an exception to load the target plugin could include an exception to loading a class within the target plugin. An exception to find the target plugin could also include an exception to finding a class within the target plugin.

[0212] For example, at least some classes in the target plugin may include Figure 8 Module A is shown in the diagram.

[0213] In one embodiment, reference Figure 9 This is a schematic diagram of another information processing method, which also includes:

[0214] S50, expand the memory space for storing target files; wherein, target files include: files required to start the host application.

[0215] S60 stores target files based on the expanded memory space; the size of the memory space is positively correlated with the startup speed of the host application.

[0216] The host application runs on a terminal device, which has memory used to store data required for the application's runtime. This embodiment provides a way to improve the startup speed of the host application by expanding the memory space for storing target files. The larger the storage space, the more target files can be stored. The method of expanding the memory space is not limited; any feasible method is acceptable.

[0217] For example, you can specify a memory storage area for the target file, using a preset area in memory as the storage area for the target file, where the size of the preset area is larger than the target value.

[0218] For example, the target value is the size of the storage area where the target file is currently stored.

[0219] After expanding the memory space, the target file is stored in the expanded memory space.

[0220] When the host application starts, it can directly read the target file from this memory space. The larger the memory space, the faster the host application starts; the smaller the memory space, the slower the host application starts. Expanding the memory space reduces the information interaction between memory and other storage devices, thus reducing the process of reading the target file from other storage devices, thereby improving the startup speed of the host application and enhancing the user experience.

[0221] For example, the target file may include: a file that carries critical instructions and data for the host application's runtime, such as a DEX file. The DEX file may include a corresponding DEX cache, and the read speed of this file affects the application's startup. Optimizing the target plugin's storage at the bytecode level can improve the target plugin's startup speed.

[0222] In one embodiment, S300, the host application loads the target plugin based on the runtime environment, including:

[0223] A whitelist of preloaded classes is determined. Based on this whitelist, the host application preloads the classes in the target plugin that are on the whitelist using the class loader before starting the target plugin.

[0224] The classes in the whitelist represent the classes that need to be loaded when loading the target plugin. The whitelist can be determined based on the functions and classes contained in the target plugin.

[0225] For example, the classes that exist in the whitelist in different target plugins can be determined based on each target plugin; that is, the classes included in the whitelist can be determined based on the target plugin. For example, the classes in the whitelist may be the core classes of each target plugin.

[0226] For example, the whitelist may include at least one class contained in the target plugin, which can reduce the need to adjust the whitelist after the target plugin is switched.

[0227] For example, preloading can be performed by using a loader that has a parent delegation relationship.

[0228] For example, the host application can obtain the whitelist, for instance, it can obtain the whitelist from the cloud.

[0229] By preloading classes from the whitelist, classes that appear in the whitelist in the target plugin can be loaded in advance, which can reduce the total loading time of the target plugin and improve the loading efficiency of the target plugin.

[0230] In one embodiment, before loading the target plugin, the following is also included:

[0231] Disable validation of classes in the target plugin, and load the target plugin after finding the class to be loaded.

[0232] Normally, a verification process is performed on the target plugin before it is loaded. This embodiment omits this process, disabling the verification of the target plugin. After the target class in the target plugin is found, the target class is no longer verified. Disabling this verification saves the total time spent searching for and loading the target plugin, thereby improving loading speed. Disabling this verification does not affect the normal loading of the target plugin. Therefore, while ensuring the normal loading of the target plugin, loading efficiency is improved, thus enhancing the user experience.

[0233] For example, there is no limitation to the way to disable this verification. You can find the verification class in the runtime environment file, modify the parameters of the verification class, and change the verification mode to non-verification mode, thereby disabling the verification mode.

[0234] In one embodiment, reference Figure 10This is a schematic diagram of an information processing device, which includes:

[0235] Module 1 is used to determine the host application, the runtime environment corresponding to the host application, and the target plugin corresponding to the host application.

[0236] Storage module 2 is used to store the target plugin in a plugin package; wherein the host application, the runtime environment, and the plugin package are stored independently of each other;

[0237] Loading module 3 is used by the host application to load the target plugin based on the runtime environment.

[0238] In one embodiment, the number of target plugins is multiple;

[0239] Storage module 2 is used for:

[0240] The target plugin is stored in multiple plugin packages.

[0241] In one embodiment, storage module 2 is used for:

[0242] In response to the fact that the number of target plugins exceeds the preset number of plugins that a single plugin package can store, the target plugins are stored in multiple plugin packages respectively.

[0243] In one embodiment, storage module 2 is used for:

[0244] In response to the fact that at least some of the plugin packages correspond to different preset quantities, the target plugins are stored in multiple plugin packages according to the size of the preset quantities;

[0245] The number of target plugins stored in the plugin package is positively correlated with the preset number corresponding to the plugin package.

[0246] In one embodiment, storage module 2 is used for:

[0247] In response to the fact that the preset quantity corresponding to each of the plugin packages is the same, the target plugin is stored in each of the plugin packages; wherein, the quantity of the target plugin stored in each of the plugin packages is the same, or, at least some of the plugin packages store different quantities of the target plugin.

[0248] In one embodiment, storage module 2 is used for:

[0249] In response to the fact that the number of target plugins is less than the preset number of plugins that a single plugin package can store, the target plugins are stored in multiple plugin packages, wherein each plugin package stores one target plugin.

[0250] In one embodiment, storage module 2 is used for:

[0251] Determine whether the target plugin is already stored in the plugin package;

[0252] In response to the fact that the target plugin is not stored in the plugin package, the target plugin is stored in the plugin package.

[0253] In one embodiment, loading module 3 includes:

[0254] A registration unit is used to register a proxy component of a target component in the host application; wherein the proxy component is used to invoke the target component of the target plugin;

[0255] A generation unit is used to generate a plugin class corresponding to the target component within the target plugin;

[0256] The first loading unit is used to locate and load the plugin class by calling the proxy component;

[0257] The second loading unit is used to load the target component of the target plugin by calling the plugin class.

[0258] In one embodiment, the target component includes at least one of the following:

[0259] Activity components;

[0260] Service components;

[0261] Broadcast receiver;

[0262] Content provider.

[0263] In one embodiment, the apparatus further includes:

[0264] The detection module is used to obtain the latest version of the target plugin after loading the target plugin in response to detecting update information of the target plugin; wherein the latest version has its own calling path;

[0265] Create a module to create the first loader;

[0266] The processing module is used to locate and load the latest version of the target plugin through the first loader according to the call path;

[0267] An update module is used to update the target plugin in the plugin package to the latest version after loading the latest version of the target plugin.

[0268] In one embodiment, loading module 3 includes:

[0269] The third loading unit is used by the host application to load the first target class of the target plugin through the second loader, so as to realize the function corresponding to the first target class in the host application;

[0270] The fourth loading unit is used to load the second target class of other plugins through the third loader, so as to enable the target plugin to run according to the second target class;

[0271] The second loader and the third loader operate in a parent delegation model. The second loader is used by the host application to load the target plugin, and the third loader is used by plugins to load other plugins.

[0272] In one embodiment, loading module 3 includes:

[0273] The fifth loading unit is used for the target plugin to load the third target class of the host application through the second loader and the third loader, so as to realize the execution of the target plugin according to the third target class.

[0274] In one embodiment, the host application contains backup information of the target plugin;

[0275] Loading module 3 is used for:

[0276] If directly loading the target plugin fails, the target plugin is located and loaded using the backup information contained in the host application.

[0277] In one embodiment, the apparatus further includes:

[0278] An extension module is used to expand the memory space for storing target files; wherein, the target files include: files required to start the host application;

[0279] A storage module is used to store the target file based on the expanded memory space; wherein the size of the memory space is positively correlated with the startup speed of the host application.

[0280] In one embodiment, loading module 3 includes:

[0281] The determination unit is used to determine the whitelist of preloaded classes;

[0282] A preloading unit is used to preload classes in the target plugin that are on the whitelist before the target plugin is launched, by the host application using a class loader, based on the whitelist.

[0283] In one embodiment, the apparatus further includes:

[0284] The closing module is used to disable the validation of classes in the target plugin before loading the target plugin;

[0285] Loading module 3 is used to load the target plugin after the class to be loaded is found.

[0286] In another embodiment, an example of another information processing method is also provided.

[0287] refer to Figure 2 and Figure 3 The plugin package content has been reduced to include only the target plugin, such as the business app.apk. All business plugins share the same runtime environment, such as runtime components, and backward compatibility has been achieved. This reduces redundant APK distribution and disk space usage.

[0288] The traditional structure requires the host application to depend on many framework libraries, increasing the package size by more than 5MB and adding to the host's burden. The solution addresses this by having the host application depend on framework interfaces, achieving full dynamism and increasing the host package size negligibly (less than 10KB), containing only 20 methods. This achieves the following results:

[0289] The runtime environment (such as a plugin framework) is not released with the host, enabling dynamic deployment.

[0290] The impact on the host packet size is almost negligible;

[0291] Supports plugin framework and hot plugin updates;

[0292] Zero reflection and no hooks ensure maximum system fragment compatibility.

[0293] The relevant dependencies are as follows:

[0294] The host application depends on the first library file, such as the dynamic library;

[0295] The runtime environment depends on a second library file, such as the plugin framework depending on the common library;

[0296] The target plugin depends on a second library file, such as the common library.

[0297] In one embodiment, reference Figure 5 Register proxy components for the target component in the target plugin, such as Proxy Activity and Proxy Provider, in the host application to reduce the time spent on Manifest parsing.

[0298] Using FreeMarker technology, template classes for the four main components of the plugin are generated during compilation, and the corresponding classes are found and loaded during runtime.

[0299] By using Javassist technology, the interface bytecode is modified during compilation, so that it originally calls the system interface but instead calls our plugin interface, thus achieving its functionality through proxy technology.

[0300] By employing a proxy mechanism, the risk of API fragmentation from hooking the system is mitigated. This allows for support of the target plugin's API with minimal modification to the system source code, maximizing system compatibility. A self-developed, fully dynamic plugin framework is used, with zero reflection and no hooks, supporting hot plugin updates.

[0301] For example, custom themes are also supported, such as transparent themes, which can fix the black screen issue with transparent themes and maintain a consistent experience.

[0302] For example, it can also support the system's default startup modes, such as standard, singleTop, singleTask, and singleInstance, and support multiple singleTop and singleTask jumps.

[0303] For example, the target plugin can also be updated, along with the plugin's .so library, supporting dynamic switching of plugin versions without restarting the host application's process, and also supporting multiple architectures (armeabi, armeabi-v7a, arm64-v8a).

[0304] For example, in actual business development, plugins and the host are almost impossible to isolate. To facilitate communication between plugins and the host, a three-way access mechanism is provided during the design phase, allowing developers to quickly implement business logic. This supports host access to plugins, plugin access to the host, and plugin access to other plugins. Class loading can be achieved through a combined classloader lookup mechanism. (See reference) Figure 7 As shown.

[0305] The following three calling methods are included:

[0306] The host application calls the target plugin:

[0307] By employing a plugin interface abstraction and service-oriented strategy, the Plugin Class Loader is used to load its related classes.

[0308] The target plugin calls other plugins:

[0309] The Delegate Class Loader uses an internal array to identify the class and resource, find their class loader, and load it.

[0310] The target plugin calls the host application:

[0311] If a class cannot be found using the Plugin Class Loader's internal class loading strategy, it will be loaded through the host application's Path Class Loader.

[0312] In one embodiment, differential upgrades of the target plugin reduce cloud costs for the Content Delivery Network (CDN).

[0313] If a business plugin is updated and iterated very frequently, the actual difference in its plugin package is not significant. If the plugin is downloaded in its entirety every time, the CDN cloud cost will be very high. By using the Diff differential algorithm, bandwidth costs can be effectively reduced by more than 90%.

[0314] refer to Figure 11 Figure 12 Based on the diff algorithm, the server generates a difference package, compares the data of the two versions, and finds the differences between them. The client uses the patch algorithm to combine the old plugin package with the difference package to form a new plugin package.

[0315] This differential upgrade is suitable for plugin packages larger than 5MB, and is ideal for third-party business scenarios with high iteration frequency, loose coupling, and heavy resources.

[0316] Figure 11 The diagram shows the execution process of the host application on the terminal device. Figure 12 The diagram shows the execution process on the server side. Figure 11 and Figure 12 Other processes can be referenced. Figure 11 and Figure 12 As shown.

[0317] In one embodiment, reference Figure 13 This is a diagram illustrating an expansion of memory space. The local service layer uses the `TunboSpeedDex.speed(this)` method to locate the `DexCache` class corresponding to each DEX file and modifies the value of `resolveMethods` to achieve the desired result. Figure 13 Please refer to other information. Figure 13 As shown.

[0318] In one embodiment, reference Figure 14 This is a diagram illustrating how a host application can be launched. Before a class is loaded by the virtual machine, there is a step-by-step verification operation. This step can be disabled; the effect is the same as keeping it enabled, but it can reduce the time consumption by 20-30ms.

[0319] Specifically, you can find the VerifyMode enumeration class in runtime.h, locate its reference, and change it to KNone mode. Figure 14 Please refer to other information. Figure 14 As shown.

[0320] In one embodiment, the target plugin includes an experimental plugin and a reference plugin corresponding to the experimental plugin.

[0321] refer to Figure 15 S200, which is another schematic diagram for storing target plugins, may also include storing the target plugin in a plugin package, and may further include:

[0322] The experimental plugins are stored in the plugin package according to the preset reference information. Different preset reference information corresponds to different experimental plugins. The preset reference information may include at least: the type of the target user's group, the target user's location information, and the plugin's operator information.

[0323] Obtain the target information of the experimental plugin, which includes data related to the search, loading, and running processes.

[0324] This method serves as an example of experimenting with target plugins. It allows for the distribution of experimental plugins based on different preset reference information, thereby obtaining the target information for each experimental plugin. This improves the isolation between experimental plugins and reduces the low experimental efficiency caused by storing all plugins in a plugin package simultaneously. For example... Figure 15 The different experimental plugins shown can correspond to different experimental groups and control groups.

[0325] The above embodiments utilize a self-developed fully dynamic plugin framework with zero reflection and no hooks, supporting hot plugin updates. It supports four major components, custom themes, launch modes, and SO loading. It supports host access to plugins, plugin access to the host, and plugin access to other plugins. It features automated engineering management (hybrid compilation, packaging, unpacking, compatibility testing, and deployment).

[0326] By using target plugin differential upgrades, CDN cloud costs are reduced; by using Turbo Speed ​​Dex technology, low-end devices are optimized at the bytecode level; through the above solutions, we can truly achieve full dynamic, non-intrusive, zero-reflection and no-hook operation, and optimize terminal devices such as TVs with odex optimization, differential upgrades, AI preload, etc., making it a truly one-stop plug-in solution for TV terminals.

[0327] It should be noted that the terms "first" and "second" in the embodiments of this disclosure are for ease of description and distinction only, and have no other specific meaning.

[0328] Figure 16 This is a block diagram illustrating a terminal device according to an exemplary embodiment. For example, the terminal device may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0329] Reference Figure 16 The terminal device may include one or more of the following components: processing component 902, memory 904, power component 906, multimedia component 908, audio component 910, input / output (I / O) interface 912, sensor component 914, and communication component 916.

[0330] Processing component 902 typically controls the overall operation of the terminal device, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 902 may include one or more processors 920 to execute instructions to complete all or part of the steps of the methods described above. Furthermore, processing component 902 may include one or more modules to facilitate interaction between processing component 902 and other components. For example, processing component 902 may include a multimedia module to facilitate interaction between multimedia component 908 and processing component 902.

[0331] Memory 904 is configured to store various types of data to support operation on the terminal device. Examples of this data include instructions for any application or method operating on the terminal device, contact data, phonebook data, messages, pictures, videos, etc. Memory 904 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0332] Power component 906 provides power to various components of the terminal device. Power component 906 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the terminal device.

[0333] Multimedia component 908 includes a screen that provides an output interface between a terminal device and a user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 908 includes a front-facing camera and / or a rear-facing camera. When the terminal device is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera can receive external multimedia data. Each front-facing camera and rear-facing camera can be a fixed optical lens system or have focal length and optical zoom capabilities.

[0334] Audio component 910 is configured to output and / or input audio signals. For example, audio component 910 includes a microphone (MIC) configured to receive external audio signals when the terminal device is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 904 or transmitted via communication component 916. In some embodiments, audio component 910 also includes a speaker for outputting audio signals.

[0335] I / O interface 912 provides an interface between processing component 902 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0336] Sensor assembly 914 includes one or more sensors for providing status assessments of various aspects of the terminal device. For example, sensor assembly 914 can detect the on / off state of the terminal device, the relative positioning of components such as the display and keypad of the terminal device, changes in the position of the terminal device or a component of the terminal device, the presence or absence of user contact with the terminal device, the orientation or acceleration / deceleration of the terminal device, and temperature changes of the terminal device. Sensor assembly 914 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 914 may also include an optical sensor, such as a Complementary Metal Oxide Semiconductor (CMOS) or Charge Coupled Device (CCD) image sensor, for use in imaging applications. In some embodiments, sensor assembly 914 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0337] Communication component 916 is configured to facilitate wired or wireless communication between the terminal device and other devices. The terminal device can access wireless networks based on communication standards, such as Wi-Fi, 4G, or 5G, or combinations thereof. In one exemplary embodiment, communication component 916 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 916 also includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0338] In an exemplary embodiment, the terminal device may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0339] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 904 including executable instructions or a computer program, which can be executed by the processor 920 of the device 900 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0340] A non-transitory computer-readable storage medium, wherein when instructions in the storage medium are executed by a processor of a terminal device, the terminal device is able to perform any of the image processing methods described above in the embodiments of this disclosure.

[0341] This disclosure provides a computer program product comprising a computer program or executable instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer program or executable instructions from the computer-readable storage medium and executes the computer program or executable instructions, causing the computer device to perform any of the image processing methods described above in this disclosure.

[0342] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure 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.

[0343] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. An information processing method, characterized in that, include: Determine the host application, the runtime environment corresponding to the host application, and the target plugin corresponding to the host application; The target plugin is stored in a plugin package; wherein the host application, the runtime environment, and the plugin package are stored independently of each other; The host application loads the target plugin based on the runtime environment.

2. The method according to claim 1, characterized in that, The number of target plugins is multiple; The step of storing the target plugin in a plugin package includes: The target plugin is stored in multiple plugin packages.

3. The method according to claim 2, characterized in that, The step of storing the target plugin into multiple plugin packages includes: In response to the fact that the number of target plugins exceeds the preset number of plugins that a single plugin package can store, the target plugins are stored in multiple plugin packages respectively.

4. The method according to claim 3, characterized in that, The step of storing the target plugin into multiple plugin packages includes: In response to the fact that at least some of the plugin packages correspond to different preset quantities, the target plugins are stored in multiple plugin packages according to the size of the preset quantities; The number of target plugins stored in the plugin package is positively correlated with the preset number corresponding to the plugin package.

5. The method according to claim 3, characterized in that, The step of storing the target plugin into multiple plugin packages includes: In response to the fact that the preset quantity corresponding to each of the plugin packages is the same, the target plugin is stored in each of the plugin packages; wherein, the quantity of the target plugin stored in each of the plugin packages is the same, or, at least some of the plugin packages store different quantities of the target plugin.

6. The method according to claim 2, characterized in that, The step of storing the target plugin into multiple plugin packages includes: In response to the fact that the number of target plugins is less than the preset number of plugins that a single plugin package can store, the target plugins are stored in multiple plugin packages, wherein each plugin package stores one target plugin.

7. The method according to claim 1, characterized in that, The step of storing the target plugin in a plugin package includes: Determine whether the target plugin is already stored in the plugin package; In response to the fact that the target plugin is not stored in the plugin package, the target plugin is stored in the plugin package.

8. The method according to claim 1, characterized in that, The host application loads the target plugin based on the runtime environment, including: Register a proxy component for the target component in the host application; wherein the proxy component is used to invoke the target component of the target plugin; Generate the plugin class corresponding to the target component within the target plugin; The plugin class is located and loaded by calling the proxy component; The target component of the target plugin is loaded by calling the plugin class.

9. The method according to claim 8, characterized in that, The target component includes at least one of the following: Activity components; Service components; Broadcast receiver; Content provider.

10. The method according to claim 1, characterized in that, After loading the target plugin, the method further includes: In response to detecting update information of the target plugin, the latest version of the target plugin is obtained; wherein, the latest version has its own calling path; Create the first loader; Based on the call path, the first loader locates and loads the latest version of the target plugin; After loading the latest version of the target plugin, update the target plugin in the plugin package to the latest version.

11. The method according to claim 1, characterized in that, The host application loads the target plugin based on the runtime environment, including: The host application loads the first target class of the target plugin through the second loader to implement the function corresponding to the first target class in the host application; The target plugin loads the second target class of other plugins through a third loader, so as to run the target plugin according to the second target class; The second loader and the third loader operate in a parent delegation model. The second loader is used by the host application to load the target plugin, and the third loader is used by plugins to load other plugins.

12. The method according to claim 11, characterized in that, The method further includes: The target plugin loads the third target class of the host application through the second loader and the third loader, so as to run the target plugin according to the third target class.

13. The method according to claim 1, characterized in that, The host application contains backup information for the target plugin; The host application loads the target plugin based on the runtime environment, including: If directly loading the target plugin fails, the target plugin is located and loaded using the backup information contained in the host application.

14. The method according to claim 1, characterized in that, The method further includes: Expand the memory space for storing the target files; wherein, the target files include: files required to start the host application; The target file is stored in the expanded memory space; wherein the size of the memory space is positively correlated with the startup speed of the host application.

15. The method according to claim 1, characterized in that, The host application loads the target plugin based on the runtime environment, including: Determine the whitelist of preloaded classes; Based on the whitelist, before launching the target plugin, the host application preloads the classes in the target plugin that are on the whitelist via a class loader.

16. The method according to claim 1, characterized in that, Before loading the target plugin, the following is also included: Disable validation for classes in the target plugin; The target plugin is loaded after the class to be loaded is located.

17. An information processing device, characterized in that, include: The determination module is used to determine the host application, the runtime environment corresponding to the host application, and the target plugin corresponding to the host application. A storage module is used to store the target plugin in a plugin package; wherein the host application, the runtime environment, and the plugin package are stored independently of each other. A loading module is used by the host application to load the target plugin based on the runtime environment.

18. A terminal device, characterized in that, include: A processor and a memory for storing computer programs or executable instructions capable of running on the processor, wherein: When the processor is used to run the computer program or the executable instructions, the executable instructions perform the method described in any one of claims 1 to 16.

19. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores a computer program or computer-executable instructions, which, when executed by a processor, implement the method described in any one of claims 1 to 16.

20. A computer program product, comprising a computer program or executable instructions, characterized in that, When the computer program or executable instructions are executed by a processor, they implement the method of any one of claims 1 to 16.

Images