Plug-in view loading method, electronic equipment and vehicle

Abstract

The invention provides a plug-in view loading method, electronic equipment and a vehicle, and the method comprises the steps: determining a plug-in view instance loaded by a plug-in and a system view instance loaded by a host through a pre-created custom context wrapper, isolating the construction of the plug-in view and the construction of a host view, and carrying out the loading of the plug-in view. According to the method, when the plug-in view is constructed, wrong access to host resources during construction of the plug-in view is avoided, the accuracy of view construction is improved, and the construction efficiency of the plug-in view is improved by directly calling the pre-loaded target view class and the corresponding constructor function from the cache and skipping class search and a reflection construction process of the constructor function.

Description

Technical Field

[0001] This application relates to the field of view loading technology, and more particularly to a method for loading plug-in views, electronic devices, and vehicles. Background Technology

[0002] As mobile applications become increasingly complex, monolithic application architectures face challenges such as excessively large installation packages and high coupling between functional modules. Pluginization technology offers a solution, allowing applications to dynamically load external plugins at runtime, thereby enabling dynamic functional expansion. However, Android's default security mechanisms restrict applications from directly accessing resources and classes in external APKs. While classes from plugins can be loaded using the DexClassLoader, displaying plugin views within plugins suffers from inefficiency and display anomalies. Summary of the Invention

[0003] In view of this, the purpose of this application is to propose a method for loading plug-in views, an electronic device, and a vehicle. By using a pre-created custom context wrapper to determine the plug-in view instance loaded by the plug-in, the construction of the plug-in view and the host view is isolated, thereby improving the accuracy of view construction. Furthermore, the construction efficiency of the plug-in view is improved through a pre-loaded caching mechanism.

[0004] To achieve the above objectives, this application provides a method for loading a pluggable view, comprising: In response to receiving a view loading request, the plugin view instance loaded by the plugin and the system view instance loaded by the host are determined based on the pre-created custom context wrapper and the view loading request. In response to the existence of a preloaded constructor for constructing the plugin view instance in the pre-created constructor cache mapping table, the custom class loader in the custom context wrapper is invoked to find the target view class corresponding to the plugin view instance; The preload constructor is called from the cache to construct the view of the target view class, resulting in the plugin view; Add the plugin view to the system view created by the host to obtain the window view.

[0005] Optionally, the custom context wrapper is created, including: Obtain plugin resources, create a custom class loader corresponding to the plugin based on the host class loader, and create a context wrapper to wrap the host context; The context wrapper is rewritten based on the plugin resources and the custom class loader to obtain a plugin context wrapper that directs resource access to the plugin. The original layout filler service of the cloned host is used to obtain the cloned layout filler service, and a custom factory is set for the cloned layout filler service to obtain the custom layout filler service. The original custom layout service in the plugin context wrapper is replaced with the custom layout filler service to obtain the custom context wrapper.

[0006] Optionally, the step of creating a custom class loader corresponding to the plugin based on the host class loader includes: The subclass of the host class loader is determined as the initial class loader; The class lookup path of the initial loader is defined to prioritize searching for the target view class in the cache; If the target view class is not found in the cache, search for the target view class in the parent class loader of the host system; If the target view class is not found in the parent class loader, the target view class is searched for in the plugin resources.

[0007] Optionally, the step of rewriting the context wrapper according to the plugin resources and the custom class loader to obtain a plugin context wrapper that directs resource access to the plugin includes: The return object of the resource acquisition method in the context wrapper is rewritten from the host resource to the plugin resource; Determine the plugin resource manager to manage the plugin resources, and rewrite the return object of the resource manager acquisition method in the context wrapper from the host resource manager to the plugin resource manager; The return object of the class loader method obtained in the context wrapper is rewritten by the host class loader to the custom class loader, thus obtaining the plugin context wrapper.

[0008] Optionally, the constructor cache mapping table is created, including: Determine the core view class corresponding to each plugin view; Locate the preload constructor used to load the core view class; The core view class is preloaded, and the constructor identifier of the preloaded constructor is added to the blank mapping table to obtain the constructor cache mapping table.

[0009] Optionally, determining the plugin view instance loaded by the plugin and the system view instance loaded by the host based on the pre-created custom context wrapper and the view loading request includes: Determine the layout file corresponding to the view loading request; The tag name of each view node in the layout file is identified based on the custom layout filler service in the custom context wrapper; In response to the presence of a plugin marker character in the tag name, the view instance corresponding to the tag name is classified as the plugin view instance; In response to the absence of a plugin marker character in the tag name, the view instance corresponding to the tag name is classified as a system view instance.

[0010] Optionally, the method for loading the plug-in view further includes: In response to the absence of a preloaded constructor for constructing the plugin view instance in the pre-created constructor cache map; The target view class is located in the parent class loader of the host system based on the custom class loader in the custom context wrapper. If the target view class does not exist in the parent class loader, the target view class is searched for in the plugin resources of the custom context wrapper. The target constructor for loading the target view class is determined based on the custom factory in the custom context wrapper. The target constructor is called to construct the view of the target view class, thereby obtaining the plugin view.

[0011] Optionally, before determining the plugin view instance loaded by the plugin and the system view instance loaded by the host based on the pre-created custom context wrapper and the view loading request, the method further includes: The loading status of the plugin resources in the custom context wrapper is determined by checking the initialization flag. In response to the incomplete loading, the time interval between the current moment and the initialization start moment is determined as the loading wait time; If the loading wait time is greater than or equal to a preset time threshold, and the plugin initialization is determined to have failed, the response to the view loading request will be terminated.

[0012] Based on the same inventive concept, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor implements the method described above when executing the computer program.

[0013] Based on the same inventive concept, this application also provides a non-transitory computer-readable storage medium that stores computer instructions for causing a computer to perform the method described above.

[0014] As can be seen from the above, the plug-in view loading method, electronic device, and vehicle provided in this application, upon receiving a view loading request, determine the plug-in view instance loaded by the plug-in and the system view instance loaded by the host based on a pre-created custom context wrapper and the view loading request. If a pre-loaded constructor for constructing the plug-in view instance exists in the pre-created constructor cache mapping table, the custom class loader in the custom context wrapper is called to find the target view class corresponding to the plug-in view instance. The pre-loaded constructor is called from the cache to construct the view of the target view class, resulting in the plug-in view. The plug-in view is then added to the system view created by the host, resulting in the window view. By determining the plug-in view instance loaded by the plug-in and the system view instance loaded by the host through the pre-created custom context wrapper, the construction of the plug-in view and the host view is isolated, avoiding incorrect access to host resources when constructing the plug-in view, thus improving the accuracy of view construction. Furthermore, by directly calling the pre-loaded target view class and its corresponding constructor from the cache, the class lookup and constructor reflection construction process are skipped, improving the construction efficiency of the plug-in view. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating the method for loading a pluggable view according to an embodiment of this application; Figure 2 A flowchart illustrating the plugin initialization process in this application embodiment; Figure 3 This is a schematic diagram of a loading device for a plug-in view according to an embodiment of this application; Figure 4 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0018] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0019] In this article, it is important to understand that any number of elements in the accompanying figures is for illustrative purposes and not for limitation, and any naming is for distinction only and has no limiting meaning.

[0020] Based on the above background description, the following situations also exist in the related technologies: In related technologies, classes in plugins are loaded using the DexClassLoader. However, problems arise when using the DexClassLoader to load classes from plugins, including: 1. Resource isolation issue: The plugin view component cannot correctly load resources (such as images, strings, etc.) in the plugin APK, resulting in abnormal display.

[0021] 2. Class loading issue: Custom view classes in the plugin cannot be loaded and instantiated correctly; 3. Context management issue: Plugin view components use the host application's context environment and cannot access plugin resources and classes. 4. Performance Issues: Each time a plugin component is loaded, the plugin APK needs to be parsed repeatedly, resulting in inefficient plugin view construction. Therefore, a more efficient and stable plugin view loading solution is needed.

[0022] The plug-in view loading method, electronic device, and vehicle provided in this application, upon receiving a view loading request, determine the plug-in view instance loaded by the plug-in and the system view instance loaded by the host based on a pre-created custom context wrapper and the view loading request. If a pre-loaded constructor for constructing the plug-in view instance exists in a pre-created constructor cache mapping table, the custom class loader in the custom context wrapper is called to find the target view class corresponding to the plug-in view instance. The pre-loaded constructor is called from the cache to construct the view of the target view class, resulting in the plug-in view. The plug-in view is then added to the system view created by the host, resulting in a window view. By determining the plug-in view instance loaded by the plug-in and the system view instance loaded by the host through a pre-created custom context wrapper, the construction of the plug-in view and the host view is isolated, avoiding incorrect access to host resources during plug-in view construction and improving the accuracy of view construction. Furthermore, by directly calling the pre-loaded target view class and its corresponding constructor from the cache, the class lookup and constructor reflection construction process are skipped, improving the construction efficiency of the plug-in view.

[0023] The following describes in detail, with reference to the accompanying drawings, the method for loading plug-in views provided in the embodiments of this application.

[0024] In some embodiments, such as Figure 1 As shown, a method for loading a plug-in view includes steps 101-104.

[0025] Step 101: In response to receiving a view loading request, determine the plugin view instance loaded by the plugin and the system view instance loaded by the host based on the pre-created custom context wrapper and the view loading request.

[0026] In practice, a custom context wrapper is used to direct resource requests from the plugin view to the plugin itself. By creating a pre-built custom context wrapper, an independent sandbox environment (including class loading, resource acquisition, and context environment) is created for the plugin, isolated from the host application but still controllable by the host. This allows the target view class in the plugin to be correctly loaded, instantiated, and run within this sandbox environment. The custom context wrapper bypasses the limitations of the Android system. Its essence lies in not forcing the plugin to adapt to the host environment, but rather proactively constructing an independent sandbox environment compatible with the host, thereby achieving efficient, stable, and seamless loading of the plugin view. Caching optimizations (class caching, constructor caching) and thread-safe controls (view classification tags, counting latches) are crucial to ensuring its performance and production environment reliability.

[0027] The view loading process can be divided into two phases: the preparation phase and the runtime phase. The preparation phase involves preloading the custom context wrapper and resources (classes and constructors) used for creation. The runtime phase is used to create the view based on the view loading request and the custom context wrapper from the preparation phase. The preparation phase is illustrated in the following example.

[0028] In some embodiments, creating a custom context wrapper includes: Obtain plugin resources, create a custom class loader corresponding to the plugin based on the host class loader, and create a context wrapper to wrap the host context; The context wrapper is rewritten based on the plugin resources and the custom class loader to obtain a plugin context wrapper that directs resource access to the plugin. The original layout filler service of the cloned host is cloned to obtain the cloned layout filler service, and a custom factory is set for the cloned layout filler service to obtain the custom layout filler service. The original custom layout service in the plugin context wrapper is replaced with a custom layout filler service to obtain the custom context wrapper.

[0029] In practice, the preparation phase includes the following processes: Step 1: Obtain plugin resources.

[0030] Action: The system uses the package manager to pass in the path to the plugin APK and parses the uninstalled plugin APK file. For example, it retrieves basic information about the plugin package's PACKAGE_NAME by calling PackageManager.getPackageInfo; The plugin's resource object mPluginResources can be obtained by calling PackageManager.getResourcesForApplication.

[0031] Access various resource files within the plugin by retrieving the resource manager mAssetManage.

[0032] Objective: To obtain basic information about the plugin APK, including resource objects and resource manager information. Output: You obtain a resource object `mPluginResources` specific to this plugin and its underlying resource manager `mAssetManage`. The resource object `mPluginResources` determines how to obtain resources from the plugin APK, completely isolating it from the host application's resources. The resource manager `mAssetManage` manages the plugin's resources.

[0033] Step 2: Build a custom class loader.

[0034] In some embodiments, a custom class loader corresponding to the plugin is created based on the host class loader, including: The subclass of the host class loader is determined as the initial class loader; Define the class lookup path of the initial loader to prioritize looking up the target view class in the cache; If the target view class is not found in the cache, search for the target view class in the parent class loader of the host system; If the target view class does not exist in the parent class loader, search for the target view class in the plugin resources.

[0035] In practice, the action of building a custom class loader is as follows: create a custom class loader mClassLoader that inherits from the class loader DexClassLoader.

[0036] Objective: To enable the host application to find and load classes (especially custom plugin view classes) in the plugin APK. Among them, the class loader DexClassLoader is a tool for loading classes from Dex files (plugin APKs). In other words, the class loader DexClassLoader in related technologies can only load plugin components from plugin APKs, and each time a plugin component (such as a plugin view) is loaded, the plugin APK needs to be parsed repeatedly, resulting in low efficiency in constructing plugin views.

[0037] The custom class loader mClassLoader introduces a class caching mechanism on top of the original class loader DexClassLoader: the custom class loader mClassLoader maintains a cache internally. Before loading a class, it checks the cache first. If the class has already been loaded (the class has been preloaded and is already stored in the cache), it is returned directly. The caching mechanism avoids the overhead of repeatedly loading the same class and improves the construction efficiency of plugin views.

[0038] If the corresponding class is not found in the cache, the internal parent delegation model is used to look up the class: even if a custom class loader mClassLoader is used, the standard parent delegation mechanism is followed, that is, the parent loader tries to load it first, and if the parent loader cannot find it, it will load it itself, to prevent the class in the plugin from conflicting with the class with the same name in the host, and to ensure the consistency and safety of the class lookup process.

[0039] Part Three: Creating a plugin context wrapper for plugins.

[0040] In some embodiments, the context wrapper is rewritten according to the plugin resources and the custom class loader to obtain a plugin context wrapper that directs resource access to the plugin, including: The return object of the resource retrieval method in the context wrapper is rewritten from the host resource to the plugin resource; Determine the plugin resource manager to be used to manage plugin resources, and rewrite the return object of the resource manager method in the context wrapper from the host resource manager to the plugin resource manager; The return object of the class loader method obtained in the context wrapper is rewritten by the host class loader to a custom class loader, resulting in the plugin context wrapper.

[0041] In practice, the action of creating a plugin context wrapper is as follows: create a context wrapper that wraps the host context and allows for customization. It wraps the context of the host application, but it is necessary to override the key methods of the context wrapper to change the resource access pointer of the context wrapper.

[0042] Objective: To provide a "correct" runtime environment for plugin views. When a plugin view needs to access resources or class loaders at runtime, it should be able to invoke the plugin's own resources instead of the host's resources, thus avoiding resource acquisition errors. Key methods for rewriting the context wrapper include: The return object of the getResources() method in the context wrapper is rewritten from the host resource to return the plugin resource obtained in the first step.

[0043] The return object of the getAssets() method in the context wrapper is rewritten from the host resource manager to return the plugin's resource manager mAssetManage obtained in the first step.

[0044] The return object of the getClassLoader() method in the context wrapper is rewritten by the host class loader to the custom class loader mClassLoader created in the second step.

[0045] The rewritten plugin context wrapper redirects resources from the host application to the plugin's resources. When a view in the plugin runs within this context wrapper, accessing resources via methods like `getResources()` is actually redirected to the plugin's own resources, not the host application's. This resolves the core issue of context mismatch.

[0046] Part 4: Set up a custom view to create a factory.

[0047] Action: In the plugin context wrapper, when the system requests the layout inflater service, a custom factory is set up for it. The process of setting up the custom factory includes: first, cloning a default layout inflater service, LayoutInflater, to obtain a cloned layout inflater service. The factory resource in the cloned layout inflater service is empty. Then, a custom factory, Factory2, is set up in the cloned layout inflater service, resulting in the custom layout inflater service LayoutInflater.Factory2. The default layout inflater service may have an existing factory (e.g., Factory1), so the custom factory is defined as Factory2 at this time to avoid duplicate IDs that could cause call conflicts.

[0048] Objective: To intercept the view creation process. The default layout filler service can only recognize view classes in the host application. By intercepting the view creation process, the default layout filler service can be instructed: "When a plugin view instance needs to be created, please use the custom class loader mClassLoader to load the class."

[0049] Implementation: In the createView method of the custom factory view creation, a custom class loader is used to load the class name specified in the XML layout file, and then the view instance is created by calling the constructor from the cache (or by reflection).

[0050] Meanwhile, the return object of the system service retrieval method getSystemService() in the context wrapper is rewritten from the host layout inflater service to a custom factory of the custom layout inflater service LayoutInflater.Factory2 to realize the view construction.

[0051] The custom layout inflater service LayoutInflater.Factory2 is used because the default layout inflater service LayoutInflater has certain limitations. In the Android system, when creating a view from an XML layout file (such as my_plugin_view.xml) using the default layout inflater service LayoutInflater, the default service LayoutInflater parses the tags in the XML layout file (such as the plugin view tag).<com.plugin.MyCustomView> The default lookup logic of the LayoutInflater service is to call the host application's class loader, DexClassLoader, to load the class. The host application's DexClassLoader only knows the host application's own classes and Android system classes, and has no knowledge of the classes in the plugin APK. When the host application's DexClassLoader attempts to load the plugin view corresponding to the plugin view tag, it will fail because the plugin's class name cannot be found, causing the application to crash.

[0052] A custom layout inflater service, LayoutInflater.Factory2, is used to intercept the view creation process and inform the default layout inflater service, LayoutInflater: "When encountering an unrecognized (non-host) class name, do not report an error directly. Instead, use the custom layout inflater service, LayoutInflater.Factory2, to call the custom class loader to attempt to load the plugin view."

[0053] For example, the interception process is as follows: The host requests the default layout inflater service LayoutInflater. The custom context wrapper ContextWrapper intercepts the service request and returns a customized layout inflater service LayoutInflater.Factory2 (containing a custom factory). When the custom layout inflater service LayoutInflater.Factory2 parses the XML layout file, it encounters a plugin view tag. The custom factory intercepts the view creation process of the plugin view corresponding to the plugin view tag, and the custom factory determines the creation method of the plugin view until the plugin view is created.

[0054] When building a custom layout inflater service, `LayoutInflater.Factory2`, it is forbidden to directly modify the default layout inflater service, `LayoutInflater`. That is, it is forbidden to directly rewrite the default `LayoutInflater` service as the custom `LayoutInflater.Factory2`. This is because the default `LayoutInflater` service is a global layout inflater service, and directly modifying it will affect the creation of the host application's own views. Cloning an independent layout inflater service allows for the construction of plugin views without affecting the host application's view construction, thus isolating the excessively long plugin view construction process from the system view construction process and avoiding errors.

[0055] Finally, the original custom layout service in the plugin context wrapper is replaced with a custom layout filler service, resulting in a custom context wrapper. At this point, a sandbox environment customized for the plugin has been set up. This environment has independent resources, an independent class loader, and a custom layout filler service, preparing for subsequent view creation. The sandbox environment is an isolated and restricted runtime space; programs within the sandbox can operate freely but cannot affect the real system outside the sandbox.

[0056] Step 5: Preload and cache core classes.

[0057] Action: During initialization, preload some commonly used core view classes in the plugin (such as the map view MAP_CLASS_NAME) and cache their constructors VIEW_CONSTRUCTORS in a constructor cache map.

[0058] Objective: To significantly improve the speed of creating subsequent plugin view instances. Since retrieving the constructor via reflection is a time-consuming operation, caching the constructor in advance avoids performing reflection every time a view is created, thus improving the efficiency of plugin view construction. The process of creating the constructor cache mapping table is shown in the following example.

[0059] In some embodiments, creating a constructor cache mapping table includes: Determine the core view class corresponding to each plugin view; Locate the preload constructor used to load the core view classes; The core view classes are preloaded, and the constructor identifier of the preloaded constructor is added to the blank mapping table to obtain the constructor cache mapping table.

[0060] In practice, the core view class can be determined based on the priority of each plug-in view. For example, in the navigation view interface, the map view corresponds to the highest priority (first priority), the path view representing the navigation route corresponds to the second priority (lower than first priority), the vehicle view representing the vehicle's location corresponds to the third priority (lower than second priority), and the background view corresponds to the lowest priority (fourth priority). A threshold priority can be set to distinguish between core views and ordinary views. For example, if the second priority is set as the threshold priority, views with a priority greater than or equal to the threshold priority are designated as core views, and views with a priority less than the threshold priority are designated as ordinary views. Thus, the map view and path view are core views, and the classes corresponding to the map view and path view are core view classes. The vehicle view and background view are ordinary views, and the classes corresponding to the vehicle view and background view are core view classes.

[0061] Optionally, views can be categorized by frequency of use. Frequency of use is measured by the ratio of the number of times each view has been created in its view history to the total number of times window views have been created, representing the proportion of times a view is used when a window view is created. For example, when creating a navigation window view, the map view, route view, and vehicle view are displayed 100% of the time, so their frequency of use is 1, meaning they are used 100 times. The zoom view, however, is only displayed when the user zooms in and the zoom level reaches a certain threshold. Therefore, in 100 window view creations, the zoom view might only be created 20 times, resulting in a frequency of use of 0.2, meaning it is used 20% of the time. Then, a threshold value (e.g., 0.5) can be set to categorize different views. Views with a frequency of use greater than or equal to the threshold are defined as core views, while those with a frequency of use less than the threshold are defined as ordinary views. Thus, the map view, route view, and vehicle view are core views, and the corresponding classes are core view classes; the zoom view is also a core view, and the corresponding class is an ordinary view class.

[0062] Optionally, to meet personalized needs, a window view preloading mode can be set. In this mode, all view classes corresponding to the window view are treated as core view classes, and all view classes are preloaded. To avoid excessive computational resource consumption during preloading, an alert will be issued based on the current available computational resources and the resource requirements for preloading the window view when setting the window view preloading mode. If the ratio of the required resources to the current available computational resources is greater than or equal to the preset maximum usage ratio, the window view preloading mode will be deactivated. If the ratio is less than the preset maximum usage ratio, the window view preloading mode will be entered, and all view classes of the window view will be preloaded. Alerts are used to prevent preloading from affecting the use of other functions, ensuring security.

[0063] After the preparation phase is completed, the runtime phase begins. During runtime, when a user clicks a plugin function icon, the host needs to display the window view corresponding to the plugin function icon. This generates a view loading request. Upon receiving the view loading request, the view loading process is executed. First, it is necessary to distinguish which of the loaded window views are system view instances created by the host and which are plugin view instances created by the plugin. The classification and identification process is illustrated in the following example.

[0064] In some embodiments, determining the plugin view instance loaded by the plugin and the system view instance loaded by the host, based on a pre-created custom context wrapper and a view loading request, includes: Determine the layout file corresponding to the view load request; Identify the tag name of each view node in the layout file based on the custom layout filler service in the custom context wrapper; In response to the presence of plugin marker characters in the tag name, the view instance corresponding to the tag name is classified as a plugin view instance; In response to the absence of plugin marker characters in the tag name, the view instance corresponding to the tag name is classified as a system view instance.

[0065] In practice, when the custom layout filler service begins parsing the layout file, it first consults the custom factory for each view tag it encounters. The custom factory determines whether the view needs plugin processing based on preset rules: for simple tag names that don't contain a package name (such as TextView, Button, etc.), it's identified as a system view example and handled by the host's default mechanism. For custom views matching the plugin package tag name, the custom class loader is activated to create the corresponding plugin view. This intelligent routing mechanism ensures that system views maintain native performance, while plugin views receive customized processing.

[0066] For the specific process of classification and recognition, the first step is to determine the layout file corresponding to the view loading request. The layout file is a data file that controls the layout of different views in terms of view position and view hierarchy. Since the layout file needs to lay out all the views, it includes information about all the views.

[0067] The custom layout filler service within the custom context wrapper parses the layout file into a tree of view objects. The custom layout filler service first parses the root node; it reads the layout file and locates the root tag (e.g., ...). <linearlayout>Based on the root tag name, check if it contains a period "." to distinguish between system views (such as TextView) and plugin views (such as com.example.CustomView). Then, starting from the root node, traverse all child nodes under the root node. Next, read the tag name of each child node. That is, read the tag name of each view node in the layout file and identify whether each tag name contains the plugin marker character ".". If the tag name contains the plugin marker character, it means that the tag name is a plugin tag name, and the view instance corresponding to that tag name is a plugin view instance; if the tag name does not contain the plugin marker character, it means that the tag name is a system tag name, and the view instance corresponding to that tag name is a system view instance. Step 102: In response to the existence of a preloaded constructor for constructing a plugin view instance in the pre-created constructor cache map, the custom class loader in the custom context wrapper is invoked to find the target view class corresponding to the plugin view instance.

[0068] In practice, since the core view classes have already been preloaded during the preparation phase, when loading a class, the search for the target view class is prioritized from the cache. The custom class loader `mClassLoader` internally maintains a cache. Before loading a target view class, the cache is checked first. If it has already been loaded (the target view class has been preloaded and is stored in the cache), the target view class is returned directly. This caching mechanism avoids the overhead of repeatedly loading the same class, improving the construction efficiency of plugin views. If the corresponding class is not found in the cache, an inner parent delegation model is used for class lookup: even when using the custom class loader `mClassLoader`, the standard parent delegation mechanism is followed, meaning the parent loader attempts to load the class first, and only loads it if the parent loader cannot find it. This prevents conflicts between classes with the same name in the plugin and classes with the same name in the host, ensuring the consistency and safety of the class lookup process.

[0069] Step 103: Call the preload constructor from the cache to construct the view of the target view class and obtain the plugin view.

[0070] In practice, for plugin view instances, a custom factory initiates a dynamic class loading process. First, it checks whether a pre-loaded constructor cache exists based on a pre-created constructor cache mapping table. If the cache is hit, the constructor is used directly, avoiding repeated reflection operations.

[0071] If the cache is not hit, the complete dynamic loading process is executed, as shown in the following example.

[0072] In some embodiments, the method for loading a pluggable view further includes: In response to the absence of a preloaded constructor for constructing a plugin view instance in a pre-created constructor cache map; The target view class is searched in the host system's parent class loader based on the custom class loader in the custom context wrapper. If the target view class is not found in the parent class loader, search for the target view class in the plugin resources of the custom context wrapper. The target constructor for loading the target view class is determined based on the custom factory in the custom context wrapper. Call the target constructor to construct the view of the target view class, and obtain the plugin view.

[0073] In practice, if the preloaded constructor for constructing the plugin view instance does not exist in the pre-created constructor cache mapping table, the corresponding constructor and target view class cannot be found in the cache, so dynamic loading of the constructor and target view class is required.

[0074] First, the target view class is searched for in the host system's parent class loader using the custom class loader in the custom context wrapper. If the target view class is not found in the parent class loader, the custom class loader searches for it in plugin resources (such as plugin DEX files). Then, type safety verification is performed on the target view class to ensure that the loaded class is indeed a subclass of View.

[0075] The custom factory in the custom context wrapper obtains the target constructor of the target view class through reflection. This constructor must accept basic information parameters from the custom context wrapper and the plugin package in the plugin resources.

[0076] After obtaining the target constructor, the custom factory uses it to create the plugin view. The key to this step is passing in the correct context object—it must be a custom context wrapper, not the host's original context wrapper. This ensures that during plugin view creation, the plugin's own resource manager is used when accessing resources, avoiding resource lookup failures.

[0077] Step 104: Add the plugin view to the system view created by the host to obtain the window view.

[0078] After implementation, once the plug-in view is constructed, the custom factory parses and applies the layout file to determine the plug-in view's size parameters, margins, weights, and other visual attributes, ensuring that the plug-in view is displayed in the system view as designed, thus obtaining the window view.

[0079] In some embodiments, such as Figure 2 As shown, before determining the plugin view instance loaded by the plugin and the system view instance loaded by the host based on the pre-created custom context wrapper and view load request, the process also includes: Step 201: Determine whether the plugin resources in the custom context wrapper have been loaded by checking the initialization flag.

[0080] In practice, before officially entering the runtime phase, it is necessary to ensure that the preparation phase has been completed. The availability of a plugin is determined by checking whether plugin initialization is complete, thus preventing plugin view loading failures. Initial completion is indicated by the completion of plugin resource loading in the custom context wrapper; therefore, checking the initialization flag determines whether plugin resources in the custom context wrapper have been loaded successfully.

[0081] Step 202: In response to the loading not being completed, the time interval between the current time and the initialization start time is determined as the loading wait time.

[0082] In practice, if loading is not completed, the initialization will not be directly determined as a failure. Instead, the loading wait time from the start of initialization to the current time will be determined, and the loading wait time will be used to determine whether there is really an initialization failure problem.

[0083] Step 203: In response to the loading wait time being greater than or equal to the preset time threshold, determine that the plugin initialization has failed and terminate the response view loading request.

[0084] In practice, if the loading wait time is greater than or equal to the preset time threshold, it indicates that the initialization process has lasted for a long time and has not been completed, suggesting an abnormality in the initialization process. Therefore, the plugin initialization is confirmed to have failed, and the response view loading request is terminated. If the loading wait time is less than the preset time threshold, the initialization process continues to wait until it is completed or an initialization error is confirmed, ensuring that the plugin view can be successfully constructed.

[0085] In summary, this application's embodiments effectively solve the core challenges in Android plugin development through an innovative pluggable view loading mechanism, efficient resource management strategies, and thread-safe state control design. By employing a custom class caching mechanism, custom context wrapper resource isolation technology, and constructor caching optimization strategies, this application's embodiments achieve efficient loading and stable operation of pluggable view components, significantly improving pluggable view loading efficiency while maintaining good system compatibility. Applicable to various Android versions, it has broad engineering application value and promising prospects for widespread adoption.

[0086] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0087] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0088] Based on the same inventive concept, corresponding to any of the above-described embodiments, this application also provides a loading device for plug-in views.

[0089] refer to Figure 3 The loading device for the plug-in view includes: The view classification module 10 is configured to: in response to receiving a view loading request, determine the plugin view instance loaded by the plugin and the system view instance loaded by the host based on the pre-created custom context wrapper and the view loading request; The view class lookup module 20 is configured to: in response to the existence of a preloaded constructor for constructing a plugin view instance in a pre-created constructor cache map, call the custom class loader in the custom context wrapper to look up the target view class corresponding to the plugin view instance; Plugin view building module 30 is configured to: call the preload constructor from the cache to construct the view of the target view class and obtain the plugin view; View blending module 40 is configured to add plug-in views to system views created by the host to obtain window views.

[0090] Optionally, the loading device for pluggable views also includes a resource preparation module 00, configured to: Obtain plugin resources, create a custom class loader corresponding to the plugin based on the host class loader, and create a context wrapper to wrap the host context; The context wrapper is rewritten based on the plugin resources and the custom class loader to obtain a plugin context wrapper that directs resource access to the plugin. The original layout filler service of the cloned host is cloned to obtain the cloned layout filler service, and a custom factory is set for the cloned layout filler service to obtain the custom layout filler service. The original custom layout service in the plugin context wrapper is replaced with a custom layout filler service to obtain the custom context wrapper.

[0091] Optionally, resource preparation module 00 is also configured as follows: The subclass of the host class loader is determined as the initial class loader; Define the class lookup path of the initial loader to prioritize looking up the target view class in the cache; If the target view class is not found in the cache, search for the target view class in the parent class loader of the host system; If the target view class does not exist in the parent class loader, search for the target view class in the plugin resources.

[0092] Optionally, resource preparation module 00 is also configured as follows: The return object of the resource retrieval method in the context wrapper is rewritten from the host resource to the plugin resource; Determine the plugin resource manager to be used to manage plugin resources, and rewrite the return object of the resource manager method in the context wrapper from the host resource manager to the plugin resource manager; The return object of the class loader method obtained in the context wrapper is rewritten by the host class loader to a custom class loader, resulting in the plugin context wrapper.

[0093] Optionally, resource preparation module 00 is also configured as follows: Determine the core view class corresponding to each plugin view; Locate the preload constructor used to load the core view classes; The core view classes are preloaded, and the constructor identifier of the preloaded constructor is added to the blank mapping table to obtain the constructor cache mapping table.

[0094] Optionally, the view classification module 10 is also configured as follows: Determine the layout file corresponding to the view load request; Identify the tag name of each view node in the layout file based on the custom layout filler service in the custom context wrapper; In response to the presence of plugin marker characters in the tag name, the view instance corresponding to the tag name is classified as a plugin view instance; In response to the absence of plugin marker characters in the tag name, the view instance corresponding to the tag name is classified as a system view instance.

[0095] Optionally, the view class lookup module 20 is also configured as follows: In response to the absence of a preloaded constructor for constructing a plugin view instance in a pre-created constructor cache map; The target view class is searched in the host system's parent class loader based on the custom class loader in the custom context wrapper. If the target view class is not found in the parent class loader, search for the target view class in the plugin resources of the custom context wrapper. The target constructor for loading the target view class is determined based on the custom factory in the custom context wrapper. Call the target constructor to construct the view of the target view class, and obtain the plugin view.

[0096] Optionally, the view classification module 10 is also configured as follows: Determine whether the plugin resources in the custom context wrapper have been loaded by checking the initialization flags; In response to the incomplete loading, the time interval between the current moment and the initialization start moment is determined as the loading wait time; If the loading wait time is greater than or equal to a preset time threshold, and the plugin initialization has failed, the response view loading request will be terminated.

[0097] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0098] The apparatus described above is used to implement the corresponding plug-in view loading method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0099] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the plug-in view loading method described in any of the above embodiments.

[0100] Figure 4 This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0101] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0102] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0103] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0104] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0105] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0106] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0107] The electronic device described above is used to implement the corresponding plug-in view loading method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0108] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the plug-in view loading method as described in any of the above embodiments.

[0109] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0110] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the plug-in view loading method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0111] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a vehicle, including the electronic device or plug-in view loading device of the above embodiments, and executes the plug-in view loading method as described in any of the above embodiments through the electronic device or plug-in view loading device of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0112] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application is limited to these examples; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0113] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0114] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0115] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the claims of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.< / linearlayout>

Claims

1. A method for loading a plug-in view, characterized by, The method comprises the following steps: in response to receiving a view loading request, determining a plug-in view instance loaded by a plug-in and a system view instance loaded by a host according to a pre-created custom context wrapper and the view loading request; in response to the pre-created constructor cache mapping table containing a preloaded constructor for constructing the plug-in view instance, calling a custom class loader in the custom context wrapper to find a target view class corresponding to the plug-in view instance; calling the preloaded constructor to perform view construction on the target view class to obtain the plug-in view from the cache; adding the plug-in view to a system view created by the host to obtain a window view. 2.The method of Claim 1, wherein, The method of creating the custom context wrapper comprises the following steps: obtaining a plug-in resource, creating a custom class loader corresponding to the plug-in according to a host class loader, and creating a context wrapper for wrapping a host context; performing method override on the context wrapper according to the plug-in resource and the custom class loader to obtain a plug-in context wrapper with resource access directed to the plug-in; cloning an original layout filler service of the host to obtain a cloned layout filler service, and setting a custom factory for the cloned layout filler service to obtain a custom layout filler service; replacing an original custom layout service in the plug-in context wrapper with the custom layout filler service to obtain the custom context wrapper.

3. The method of claim 2, wherein, The method of creating the custom class loader according to the host class loader comprises the following steps: determining a subclass of the host class loader as an initial loader; defining a class lookup path of the initial loader as a path for preferentially searching for a target view class in a cache; in response to the target view class not existing in the cache, searching for the target view class in a parent class loader of a host system; in response to the target view class not existing in the parent class loader, searching for the target view class in the plug-in resource. 4.The method of Claim 2, wherein, The method of performing method override on the context wrapper according to the plug-in resource and the custom class loader to obtain the plug-in context wrapper with resource access directed to the plug-in comprises the following steps: rewriting a return object of a resource obtaining method in the context wrapper from a host resource to the plug-in resource; determining a plug-in resource manager for managing the plug-in resource, and rewriting a return object of a resource manager obtaining method in the context wrapper from a host resource manager to the plug-in resource manager; rewriting a return object of a class loader obtaining method in the context wrapper from a host class loader to the custom class loader to obtain the plug-in context wrapper.

5. The method of claim 2, wherein, The method of creating the constructor cache mapping table comprises the following steps: determining a core view class corresponding to each plug-in view; finding a preloaded constructor for loading the core view class; preloading the core view class, and adding a constructor identifier of the preloaded constructor to a blank mapping table to obtain the constructor cache mapping table. 6.The method of Claim 1, wherein, The method of determining a plug-in view instance loaded by a plug-in and a system view instance loaded by a host according to a pre-created custom context wrapper and a view loading request comprises the following steps: determining a layout file corresponding to the view loading request; identifying a tag name of each view node in the layout file according to a custom layout filler service in the custom context wrapper; in response to the presence of a plug-in mark character in the tag name, classifying a view instance corresponding to the tag name as the plug-in view instance; in response to the absence of a plug-in mark character in the tag name, classifying a view instance corresponding to the tag name as the system view instance. 7.The method of Claim 1, wherein, Further comprising: in response to the absence of a pre-created constructor cache mapping table for constructing the plug-in view instance; finding the target view class in a parent class loader of a host system according to a custom class loader in the custom context wrapper; in response to the absence of the target view class in the parent class loader, finding the target view class in a plug-in resource of the custom context wrapper; determining a target constructor for loading the target view class according to a custom factory in the custom context wrapper; invoking the target constructor to perform view construction on the target view class to obtain the plug-in view. 8.The method of Claim 1, wherein, Before the determining of the plug-in view instance loaded by the plug-in and the system view instance loaded by the host according to the pre-created custom context wrapper and the view loading request, further comprising: determining whether plug-in resources in the custom context wrapper are loaded by checking an initialization flag bit; in response to the loading being incomplete, determining a time interval between a current time and an initialization start time as a loading waiting duration; in response to the loading waiting duration being greater than or equal to a preset duration threshold, determining that plug-in initialization fails, and terminating the response to the view loading request.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The processor implements the method of any one of claims 1 to 8 when executing the program.

10. A vehicle characterized by comprising: The electronic device of claim 9 is included. The electronic device of claim 9 is included.

Images