View display method, device, electronic equipment and storage medium of target application

Abstract

This application provides a method, apparatus, electronic device, and storage medium for displaying a view of a target application. The method is applied to the field of view display. The target application includes a framework layer and a business layer. The framework layer is used to construct the view framework of the target application, and the business layer is used to handle the view business of the target application. The method includes: in the framework layer, receiving a view creation request corresponding to the target application from a host; creating a target host container based on the view creation request; receiving the target view created by the business layer, and loading the target view into the target host container to display the target view. This method can avoid deep coupling between the framework layer and the business layer of the target application, thereby improving the dynamic expansion capability of the view runtime.

Description

Technical Field

[0001] This application relates to the field of view display, and more specifically, to a view display method, apparatus, electronic device, and storage medium for a target application in the field of view display. Background Technology

[0002] Currently, in the development of Android in-vehicle system applications, it is often necessary to implement cross-process UI (User Interface) display. However, in existing technologies, the cross-process UI display between the Launcher (host) and the client APP (Application) is deeply coupled. This results in the need to modify the underlying communication interface when adding new view types, and developers need to repeatedly handle Binder communication, Surface (graphics buffer) lifecycle management, and view rendering logic, leading to code redundancy, maintenance difficulties, and hard-coded view types. Furthermore, the lack of runtime dynamic expansion capabilities makes it difficult to meet the flexible and personalized needs of scenarios such as in-vehicle systems. Summary of the Invention

[0003] This application provides a view display method, apparatus, electronic device, and storage medium for a target application. This method can avoid deep coupling between the framework layer and the business layer of the target application, thereby improving the dynamic scalability of the view at runtime.

[0004] Firstly, a method for displaying a view of a target application is provided. The target application includes a framework layer and a business layer. The framework layer is used to construct the view framework of the target application, and the business layer is used to handle the view business of the target application. The method includes: in the framework layer, receiving a view creation request corresponding to the target application from the host; creating a target host container based on the view creation request; receiving the target view created by the business layer, and loading the target view into the target host container to display the target view.

[0005] The above technical solution clarifies the functions and responsibilities of different layers by dividing the target application into a framework layer and a business layer. The framework layer focuses on building the view framework of the target application, providing basic support for view display; the business layer is responsible for handling the view business of the target application and implementing specific business logic. The framework layer receives view creation requests corresponding to the target application from the host, creates a target host container based on the request, and receives the target view created by the business layer, loading it into the target host container for display. This layered design allows the framework layer and the business layer to work independently yet collaboratively. When a new view creation request is received, only the business layer needs to create the corresponding target view, while the framework layer can still receive the view creation request, create the target host container, and load the target view in the original way. Therefore, this method does not require multiple modifications to the underlying communication interface between the host and the framework layer based on new view creation requests. In addition, because the responsibilities of the framework layer and the business layer are clearly defined, and the framework layer focuses on building the view framework, it can uniformly handle low-level operations such as cross-process communication language between the host and the framework layer, lifecycle management of the graphics buffer, and rendering logic of the target view. This avoids repeatedly processing various low-level operations in the framework layer when a new view creation request is received; only the business layer needs to create the corresponding target view. Since this division of the framework layer and the business layer avoids repeatedly processing various low-level operations in the framework layer, this layered design allows the expansion of the target view to be dynamically performed at the runtime of other views, thus solving the problem of the lack of dynamic runtime expansion capability of views in existing technologies and meeting the flexible needs of view creation.

[0006] In conjunction with the first aspect, in some possible implementations, creating a target host container based on a view creation request includes: determining whether a host container corresponding to the target application exists in the framework layer based on the view creation request; if it is determined that no host container corresponding to the target application exists in the framework layer, then creating the target host container.

[0007] The above technical solution, in the process of creating the target host container based on the view creation request, first determines whether a host container corresponding to the target application already exists in the framework layer. Only if it is determined that no host container corresponding to the target application exists in the framework layer will the operation of creating the target host container be performed. This approach not only effectively saves resources by avoiding re-creation when a corresponding host container already exists, reducing memory consumption, but also improves the efficiency and accuracy of target host container creation. By accurately determining the target host container before creation, it avoids the confusion and errors that may result from repeated creation.

[0008] Combining the first aspect and the above implementation methods, in some possible implementation methods, receiving the target view created by the business layer includes: receiving the target view created by the business layer through a view receiving interface; wherein, the view receiving interface is located between the framework layer and the business layer and is used to host the target view created by the business layer.

[0009] The above technical solution achieves the reception of target views created by the business layer by setting up a view receiving interface. The view receiving interface, situated between the framework layer and the business layer, acts as a crucial bridge. It provides the business layer with a clear view hosting method; the business layer only needs to pass the created target view to the framework layer according to predetermined rules, without needing to concern itself with the framework layer's internal processing logic. This simplifies the business layer's development process and improves its independence and efficiency. Simultaneously, the framework layer can reliably and stably obtain the target view created by the business layer through the view receiving interface, facilitating subsequent operations such as loading the target view into the target host container for display. This design reduces the coupling between the framework layer and the business layer, improving the dynamic scalability of the view at runtime.

[0010] Combining the first aspect and the above implementation methods, in some possible implementation methods, a target view corresponding to the target application is created through the following steps: In the business layer, a target business entry point corresponding to the target application is generated; wherein, the target business entry point inherits from the framework entry point in the framework layer, and the framework entry point is used to receive view creation requests corresponding to the target application from the host; if the target business entry point is determined, a target view corresponding to the target application is created based on the preset view creation standard of the view creator interface; wherein, the view creator interface is located between the framework layer and the business layer.

[0011] The above technical solution employs a rigorous and logical process in creating the target view corresponding to the target application at the business layer. First, a target business entry point corresponding to the target application is generated at the business layer, and this entry point inherits from the framework entry point in the framework layer. The framework entry point bears the crucial responsibility of receiving view creation requests corresponding to the target application from the host. This inheritance relationship allows the business layer to promptly obtain relevant requirements for view creation, providing a foundation for subsequent view creation. After determining the target business entry point, the target view is created according to the preset view creation standards of the view creator interface located between the framework layer and the business layer. The view creator interface, situated between the two layers, forms a bridge between the framework layer and the business layer. The preset view creation standards provide a unified and clear guideline for the business layer to create the target view, ensuring that the created target view conforms to the requirements and specifications of the framework layer. This design approach allows for clear division of labor and collaborative cooperation between the framework layer and the business layer during view creation. The framework layer provides basic interaction interfaces and creation standards, while the business layer is responsible for specific business logic and view generation. This ensures both the standardization and consistency of view creation while providing the business layer with a certain degree of flexibility to meet the business needs of different target applications. At the same time, this layered and interface design reduces the coupling between the framework layer and the business layer, and improves the dynamic scalability of the view at runtime.

[0012] Combining the first aspect and the above implementation methods, in some possible implementation methods, when the target business entry point is determined, a target view corresponding to the target application is created based on the preset view creation standard in the view creator interface, including: when the target business entry point is determined, a target view creator corresponding to the target application is generated based on the preset view creation standard in the view creator interface; and a target view corresponding to the target application is created based on the target view creator.

[0013] The above technical solution, after determining the target business entry point, creates the target view based on the preset view creation standards in the view creator interface. Specifically, firstly, a target view creator corresponding to the target application is generated based on the preset view creation standards. The preset view creation standards in the view creator interface provide a unified standard for generating target view creators, ensuring that the generated target view creators conform to the framework layer's general requirements and format standards for view creation, thereby guaranteeing the consistency of the subsequent view creation process and avoiding confusion or errors in view creation due to differences in creators. Next, the generated target view creator is used to create the target view corresponding to the target application. As a tool specifically designed for creating target views, the target view creator can accurately create target views that meet the needs of the target application. This step-by-step creation method makes the view creation process more scalable. The framework layer provides basic support and standard constraints for business layer view creation by providing the view creator interface and preset view creation standards, while the business layer generates specific business views through the target view creator. This layered collaborative model reduces the complexity of view creation and enhances the maintainability and scalability of view operation.

[0014] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the method further includes: if it is determined that there is a host container in the framework layer corresponding to the target application, then the host container corresponding to the target application is used as the target host container.

[0015] The above technical solution, when it is necessary to determine a suitable target host container for a target application, considers that the framework layer is pre-configured with various host containers for hosting different applications. Therefore, it can first query and determine whether a host container corresponding to the target application exists within the framework layer. If a host container corresponding to the target application exists in the framework layer, then that host container is directly used as the target host container. This method can directly utilize the corresponding host container already existing in the framework layer, avoiding the resource waste and increased development costs caused by repeatedly creating host containers, and improving resource utilization efficiency and development efficiency.

[0016] Combining the first aspect and the above implementation methods, in some possible implementation methods, the framework layer includes a framework entry point that receives a view creation request corresponding to the target application from the host. This includes: in the framework layer, receiving a request data packet sent by the host through an inter-process communication mechanism via the framework entry point; parsing the request data packet to obtain view information corresponding to the target application, in order to confirm that the view creation request has been received.

[0017] The above technical solution establishes a key component—the framework entry point—specifically for receiving requests from the host, thus clearly defining the request reception channel. Request data packets are transmitted via inter-process communication (IPC), a mature and stable communication method that ensures reliable data transfer between different processes, overcoming communication barriers caused by inter-process isolation and guaranteeing the accuracy of data transmission between the host and the framework layer. When a request data packet arrives at the framework layer, it is parsed. Parsing the request data packet extracts view information corresponding to the target application from complex data structures. By identifying and analyzing this view information, it can be accurately confirmed that a view creation request has been received. This parsing method enables the framework layer to accurately understand the host's needs, providing strong support for subsequent view creation operations based on this request.

[0018] Secondly, a view display device for a target application is provided. The target application includes a framework layer and a business layer. The framework layer is used to construct the view framework of the target application, and the business layer is used to process the view business of the target application. The device includes: a receiving module, used in the framework layer to receive a view creation request corresponding to the target application from the host; a creation module, used to create a target host container based on the view creation request; and a display module, used to receive the target view created by the business layer and load the target view into the target host container to display the target view.

[0019] In conjunction with the second aspect, in some implementations of the second aspect, the creation module is specifically used to: determine whether a host container corresponding to the target application exists in the framework layer based on the view creation request; if it is determined that no host container corresponding to the target application exists in the framework layer, then create the target host container.

[0020] In conjunction with the second aspect and the above implementation methods, in some implementation methods of the second aspect, the display module includes a receiving unit, which is specifically used to: receive a target view created by the business layer through a view receiving interface; wherein, the view receiving interface is located between the framework layer and the business layer and is used to host the target view created by the business layer.

[0021] In conjunction with the second aspect and the above implementation methods, in some implementation methods of the second aspect, the device further includes a generation module, specifically used to: create a target view corresponding to the target application through the following steps: in the business layer, generate a target business entry corresponding to the target application; wherein, the target business entry inherits from the framework entry in the framework layer, and the framework entry is used to receive a view creation request corresponding to the target application from the host; if the target business entry is determined, create a target view corresponding to the target application based on the preset view creation standard of the view creator interface; wherein, the view creator interface is located between the framework layer and the business layer.

[0022] In conjunction with the second aspect and the above implementation methods, in some implementation methods of the second aspect, the generation module is specifically used to: when the target business entry point is determined, create a target view corresponding to the target application based on the preset view creation standard in the view creator interface, including: when the target business entry point is determined, generate a target view creator corresponding to the target application based on the preset view creation standard in the view creator interface; and create a target view corresponding to the target application based on the target view creator.

[0023] In conjunction with the second aspect and the above implementation methods, in some implementation methods of the second aspect, the device further includes a determining module: if it is determined that there is a host container corresponding to the target application in the framework layer, then the host container corresponding to the target application is taken as the target host container.

[0024] Combining the second aspect and the above implementation methods, in some implementation methods of the second aspect, the framework layer includes a framework entry point. This receiving module is specifically used to: receive request data packets sent by the host through the inter-process communication mechanism in the framework layer; parse the request data packets to obtain view information corresponding to the target application, so as to confirm that the view creation request has been received.

[0025] Thirdly, an electronic device is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to perform the methods of the first aspect or any possible implementation thereof.

[0026] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0027] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0028] Figure 1 This is a schematic flowchart of a view display method for a target application provided in an embodiment of this application.

[0029] Figure 2 This is a schematic diagram of a view display method for a target application provided in an embodiment of this application.

[0030] Figure 3This is a sequence diagram of a view display method for a target application provided in an embodiment of this application.

[0031] Figure 4 This is a schematic diagram of the structure of a view display device for a target application provided in an embodiment of this application.

[0032] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0034] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0035] To facilitate understanding of the embodiments of this application, the technical terms involved in the embodiments of this application will be explained below: SurfaceControlViewHost: A mechanism provided by Android that allows one process to render a View onto a Surface (graphics buffer) and embed that Surface into the view hierarchy of another process.

[0036] Binder: Android system inter-process communication mechanism.

[0037] Host (host container): The container responsible for managing and displaying remote Surfaces.

[0038] Provider: The component responsible for creating and providing business view content.

[0039] Currently, in the development of Android in-vehicle system applications, it is often necessary to implement cross-process UI (User Interface) display. However, existing technologies typically have the following problems: High coupling problem: There is deep coupling between the Launcher (host) and the client APP (Application) in the cross-process UI display. The underlying communication code is often bound to specific business view logic, which means that adding a new view type requires modification of the underlying AIDL (Android Interface Definition Language) interface and communication code. Low development efficiency: Developers need to handle complex Binder communication, Surface (graphics buffer) lifecycle management, view rendering logic and thread scheduling at the same time. Different business needs to write similar classes, which results in code redundancy and increases maintenance costs. Poor scalability: The view type is usually hard-coded and lacks the ability to be dynamically extended at runtime, making it difficult to meet the flexible and personalized needs of scenarios such as automotive.

[0040] To at least address the aforementioned issues, embodiments of this application provide a view display method for a target application, applied to the framework layer of the target application. This method can avoid deep coupling between the framework layer and the business layer of the target application, thereby improving the dynamic scalability of the view at runtime.

[0041] Figure 1 This is a schematic flowchart of a view display method for a target application provided in an embodiment of this application.

[0042] For example, such as Figure 1 As shown, the method 100 includes: Step 101: In the framework layer, receive the view creation request corresponding to the target application from the host.

[0043] Step 102: Create the target host container based on the view creation request.

[0044] Step 103: Receive the target view created by the business layer and load the target view into the target host container to display the target view.

[0045] In this embodiment, the target application is divided into a framework layer and a business layer, clearly defining the functions and responsibilities of each layer. The framework layer focuses on building the view framework of the target application, providing basic support for view display; the business layer is responsible for handling the view business of the target application and implementing specific business logic. The framework layer receives view creation requests corresponding to the target application from the host, creates a target host container based on the request, and receives the target view created by the business layer, loading it into the target host container for display. This layered design allows the framework layer and the business layer to work independently yet collaboratively. When a new view creation request is received, only the business layer needs to create the corresponding target view, while the framework layer can still receive the view creation request, create the target host container, and load the target view in the original way. Therefore, this method does not require multiple modifications to the underlying communication interface between the host and the framework layer based on new view creation requests. In addition, because the responsibilities of the framework layer and the business layer are clearly defined, and the framework layer focuses on building the view framework, it can uniformly handle low-level operations such as cross-process communication language between the host and the framework layer, lifecycle management of the graphics buffer, and rendering logic of the target view. This avoids repeatedly processing various low-level operations in the framework layer when a new view creation request is received; only the business layer needs to create the corresponding target view. Since this division of the framework layer and the business layer avoids repeatedly processing various low-level operations in the framework layer, this layered design allows the expansion of the target view to be dynamically performed at the runtime of other views, thus solving the problem of the lack of dynamic runtime expansion capability of views in existing technologies and meeting the flexible needs of view creation.

[0046] The following is about Figure 1 The implementation of each step in the illustrated embodiment will be explained in detail.

[0047] Regarding step 101, it can be understood that the aforementioned host can be understood as the desktop launcher of the vehicle's head unit. The aforementioned target application can be understood as the APP on the vehicle's head unit.

[0048] The target application includes a framework layer and a business layer. The framework layer is used to construct the view framework of the target application. In this embodiment, the view framework can be understood as a component for displaying the view. Therefore, the framework layer can be understood as a component for constructing the view. The business layer is used to process the view business of the target application. In this embodiment, processing the view business of the target application can be understood as creating the view of the target application. Therefore, the business layer can be understood as a view creation layer.

[0049] Within the target application's framework layer, there exists a framework entry point. This entry point receives view creation requests corresponding to the target application from the host. The host sends the view creation request to the target application via IPC (Inter-Process Communication) mechanism, which is then received by the target application's framework entry point.

[0050] The aforementioned framework entry point can be implemented using the BaseWallpaperProvider class. Specifically, the host Launcher uses the Android system's IPC mechanism to call the call() method of the framework entry point BaseWallpaperProvider to send a view creation request to BaseWallpaperProvider.

[0051] In some embodiments, receiving a view creation request corresponding to the target application from the host includes: in the framework layer, receiving a request data packet sent by the host through an inter-process communication mechanism via the framework entry point; parsing the request data packet to obtain view information corresponding to the target application, so as to confirm that the view creation request has been received.

[0052] It is understandable that the aforementioned inter-process communication mechanism can be interpreted as an IPC mechanism. The request data packet may include the view type, view number, and display number, etc.

[0053] The host sends the request data packet to the target application through the IPC mechanism. The target application's framework entry point receives the request data packet and parses it to obtain the view information corresponding to the target application. This view information can refer to the aforementioned view type, view number, and display number, etc. If the view information is confirmed to have been received, the framework layer can confirm that the view creation request has been received.

[0054] The view types mentioned above correspond to the target application. Specifically, if the target application is a music application, the view type is a music view; if the target application is a video application, the view type is a video view.

[0055] The above technical solution establishes a key component—the framework entry point—specifically for receiving requests from the host, thus clearly defining the request reception channel. Request data packets are transmitted via inter-process communication (IPC), a mature and stable communication method that ensures reliable data transfer between different processes, overcoming communication barriers caused by inter-process isolation and guaranteeing the accuracy of data transmission between the host and the framework layer. When a request data packet arrives at the framework layer, it is parsed. Parsing the request data packet extracts view information corresponding to the target application from complex data structures. By identifying and analyzing this view information, it can be accurately confirmed that a view creation request has been received. This parsing method enables the framework layer to accurately understand the host's needs, providing strong support for subsequent view creation operations based on this request.

[0056] Regarding step 102, it can be understood that the aforementioned target host container is used to host the view corresponding to the view creation request. The framework layer creates the target host container based on the received view creation request.

[0057] In some embodiments, creating a target host container based on a view creation request includes: determining whether a host container corresponding to the target application exists in the framework layer based on the view creation request; if it is determined that no host container corresponding to the target application exists in the framework layer, then creating the target host container.

[0058] It is understandable that there is a singleton manager in the framework layer, which pre-stores a set of correspondences. These correspondences describe the relationship between the target application and the host container, that is, each target application corresponds to one host container.

[0059] The singleton manager described above can be implemented using the WidgetInstanceManager class. Specifically, the WidgetInstanceManager stores a rootVews:Map, used to determine whether a host container corresponding to the target application exists.

[0060] The singleton manager in the framework layer queries the above correspondence based on the view creation request to determine whether there is a host container in the framework layer corresponding to the target application. If it is determined that there is no host container in the framework layer corresponding to the target application, a general host container is created and used as the target host container.

[0061] The target host container mentioned above can be implemented using the SurfaceRootView class. Specifically, the singleton manager WidgetInstanceManager queries the rootVews:Map to determine if a host container corresponding to the target application exists. If it does not exist, a generic host container is created, and this generic host container is used as the target host container SurfaceRootView.

[0062] The aforementioned general host container can be understood as a host container capable of hosting any view corresponding to an application.

[0063] The above technical solution, in the process of creating the target host container based on the view creation request, first determines whether a host container corresponding to the target application already exists in the framework layer. Only if it is determined that no host container corresponding to the target application exists in the framework layer will the operation of creating the target host container be performed. This approach not only effectively saves resources by avoiding re-creation when a corresponding host container already exists, reducing memory consumption, but also improves the efficiency and accuracy of target host container creation. By accurately determining the target host container before creation, it avoids the confusion and errors that may result from repeated creation.

[0064] In some embodiments, the method further includes: if it is determined that there is a host container in the framework layer corresponding to the target application, then the host container corresponding to the target application is used as the target host container.

[0065] Understandably, after the singleton manager in the framework layer queries the corresponding relationship, if it is determined that there is a host container in the framework layer that corresponds to the target application, then the host container corresponding to the target application is directly used as the target host container.

[0066] The above technical solution, when it is necessary to determine a suitable target host container for a target application, considers that the framework layer is pre-configured with various host containers for hosting different applications. Therefore, it can first query and determine whether a host container corresponding to the target application exists within the framework layer. If a host container corresponding to the target application exists in the framework layer, then that host container is directly used as the target host container. This method can directly utilize the corresponding host container already existing in the framework layer, avoiding the resource waste and increased development costs caused by repeatedly creating host containers, and improving resource utilization efficiency and development efficiency.

[0067] For step 103, it can be understood that the target host container of the framework layer receives the target view created by the business layer, and loads and displays the target view in the target host container.

[0068] In some embodiments, receiving a target view created by the business layer includes: receiving the target view created by the business layer through a view receiving interface; wherein the view receiving interface is located between the framework layer and the business layer and is used to host the target view created by the business layer.

[0069] It is understandable that there exists a view receiving interface between the framework layer and the business layer of the target application. This view receiving window can host all views created by the business layer, including the target view. Therefore, through the aforementioned view receiving interface, the target host container of the framework layer can receive the target view created by the business layer.

[0070] The aforementioned view receiving interface can be implemented using the IWallpaperView class. Specifically, the created target view is hosted by the view receiving interface IWallpaperView, and the singleton manager WidgetInstanceManager loads the target view into the target host container SurfaceRootView so that it can receive it.

[0071] The above technical solution achieves the reception of target views created by the business layer by setting up a view receiving interface. The view receiving interface, situated between the framework layer and the business layer, acts as a crucial bridge. It provides the business layer with a clear view hosting method; the business layer only needs to pass the created target view to the framework layer according to predetermined rules, without needing to concern itself with the framework layer's internal processing logic. This simplifies the business layer's development process and improves its independence and efficiency. Simultaneously, the framework layer can reliably and stably obtain the target view created by the business layer through the view receiving interface, facilitating subsequent operations such as loading the target view into the target host container for display. This design reduces the coupling between the framework layer and the business layer, improving the dynamic scalability of the view at runtime.

[0072] The following section will detail a method for creating a target view.

[0073] In some embodiments, a target view corresponding to the target application is created through the following steps: In the business layer, a target business entry corresponding to the target application is generated; wherein, the target business entry inherits from the framework entry in the framework layer, and the framework entry is used to receive a view creation request corresponding to the target application from the host; if the target business entry is determined, a target view corresponding to the target application is created based on the preset view creation standard of the view creator interface; wherein, the view creator interface is located between the framework layer and the business layer.

[0074] Understandably, in the target application's business layer, a target business entry point corresponding to the target application is first generated based on the framework entry point in the framework layer. Since this target business entry point inherits from the framework entry point in the framework layer, and the framework entry point is used to receive view creation requests from the host corresponding to the target application, the target business entry point can also know about view creation requests from the host corresponding to the target application. The aforementioned target business entry point can be understood as a business entry point corresponding to the target application.

[0075] The aforementioned business entry point can be implemented using the LrcWallpaperProvider class. Specifically, a business entry point LrcWallpaperProvider that inherits from the framework entry point BaseWallpaperProvider is generated. Once the business entry point LrcWallpaperProvider is determined, the target view corresponding to the target application is created.

[0076] Between the framework layer and the business layer of the target application, there exists a view creator interface. When a target business entry point is identified and is aware of the view creation request, the target business entry point creates a target view corresponding to the target application based on the preset view creation standards of the view creator interface. These preset view creation standards can be understood as preset view creation methods.

[0077] The aforementioned view creator interface can be implemented using the IViewFactory class. Specifically, using the IViewFactory view creator interface as a standard, the target view corresponding to the target application is created.

[0078] The above technical solution employs a rigorous and logical process in creating the target view corresponding to the target application at the business layer. First, a target business entry point corresponding to the target application is generated at the business layer, and this entry point inherits from the framework entry point in the framework layer. The framework entry point bears the crucial responsibility of receiving view creation requests corresponding to the target application from the host. This inheritance relationship allows the business layer to promptly obtain relevant requirements for view creation, providing a foundation for subsequent view creation. After determining the target business entry point, the target view is created according to the preset view creation standards of the view creator interface located between the framework layer and the business layer. The view creator interface, situated between the two layers, forms a bridge between the framework layer and the business layer. The preset view creation standards provide a unified and clear guideline for the business layer to create the target view, ensuring that the created target view conforms to the requirements and specifications of the framework layer. This design approach allows for clear division of labor and collaborative cooperation between the framework layer and the business layer during view creation. The framework layer provides basic interaction interfaces and creation standards, while the business layer is responsible for specific business logic and view generation. This ensures both the standardization and consistency of view creation while providing the business layer with a certain degree of flexibility to meet the business needs of different target applications. At the same time, this layered and interface design reduces the coupling between the framework layer and the business layer, and improves the dynamic scalability of the view at runtime.

[0079] In some embodiments, when a target business entry point is determined, a target view corresponding to the target application is created based on a preset view creation standard in the view creator interface, including: when a target business entry point is determined, a target view creator corresponding to the target application is generated based on a preset view creation standard in the view creator interface; and a target view corresponding to the target application is created based on the target view creator.

[0080] Understandably, if a target business entry point is identified and the target business entry point is aware of the view creation request, the business layer generates a target view creator corresponding to the target application by calling the preset view creation method of the view creator interface, and uses the target view creator to create the target view corresponding to the target application.

[0081] The aforementioned target view creator can be implemented using the LrcViewFactory class, and the aforementioned target view can be implemented using the SimpleLrcView class. Specifically, a target view creator LrcViewFactory corresponding to the target application is created based on the view creator interface IViewFactory. At this point, the target view creator LrcViewFactory creates the specific target view SimpleLrcView.

[0082] The above technical solution, after determining the target business entry point, creates the target view based on the preset view creation standards in the view creator interface. Specifically, firstly, a target view creator corresponding to the target application is generated based on the preset view creation standards. The preset view creation standards in the view creator interface provide a unified standard for generating target view creators, ensuring that the generated target view creators conform to the framework layer's general requirements and format standards for view creation, thereby guaranteeing the consistency of the subsequent view creation process and avoiding confusion or errors in view creation due to differences in creators. Next, the generated target view creator is used to create the target view corresponding to the target application. As a tool specifically designed for creating target views, the target view creator can accurately create target views that meet the needs of the target application. This step-by-step creation method makes the view creation process more scalable. The framework layer provides basic support and standard constraints for business layer view creation by providing the view creator interface and preset view creation standards, while the business layer generates specific business views through the target view creator. This layered collaborative model reduces the complexity of view creation and enhances the maintainability and scalability of view operation.

[0083] Figure 2 This is a schematic diagram of a view display method for a target application provided in an embodiment of this application.

[0084] For example, such as Figure 2 As shown, Figure 2 It involves 8 classes, including: BaseWallpaperProvider, WidgetInstanceManager, SurfaceRootView, IViewFactory, IWallpaperView, LrcWallpaperProvider, LrcViewFactory, and SmipleLrcView.

[0085] In the above Figure 2 In this framework, IViewFactory and IWallpaperView serve as abstract interface layers for the target application, defining the contract between the framework layer and the business layer, and are key to implementing the blind management mechanism. IViewFactory and IWallpaperView will be introduced separately below: IViewFactory: A view creator interface that specifies how view business logic is created (e.g., createView()).

[0086] IWallpaperView: The view receiving interface, which specifies the lifecycle behaviors that all view business logic must have, such as the lifecycle callback method onLifecycle() and the view acquisition method getView(). Specific lifecycle callback methods include: pause onViewPause(), resume onViewResume(), destroy onViewDeleted(), etc.

[0087] To illustrate the two interfaces above, consider this example: they essentially define a "unified socket standard." `IViewFactory` specifies "how to manufacture a plug," while `IWallpaperView` specifies "how the plug should function after being powered on (e.g., switching on / off)." The framework layer only recognizes this standard interface, not the shape of the plug. In other words, the framework layer doesn't recognize the specific view content, only the view hosted by this interface, thus achieving complete decoupling between the framework and specific business logic.

[0088] In the above Figure 2 In this framework, BaseWallpaperProvider, WidgetInstanceManager, and SurfaceRootView serve as the framework layer for the target application, used to construct its view framework. The following sections will introduce BaseWallpaperProvider, WidgetInstanceManager, and SurfaceRootView respectively.

[0089] BaseWallpaperProvider: The basic wallpaper provider, also known as the content provider, serves as the unified framework entry point for cross-process communication. It is responsible for receiving and parsing the host's request data packets and solidifying common request processing logic (e.g., parameter parsing, permission verification). This allows the abstract method `getViewFactory()` to delegate the specific view creation authority to subclasses. Figure 2 The subclass can be understood as LrcWallpaperProvider, a lyrics wallpaper provider.

[0090] WidgetInstanceManager: A singleton manager used to receive requests from the host and coordinate with other components to use createOrUpdateInstance() to complete the creation and updating of views. For example, it can create the host container SurfaceRootView, create views through the view creator, add the created views to the host container SurfaceRootView, and manage the lifecycle of all created views.

[0091] SurfaceRootView: The target host container, which serves as the host container for the view receiving interface IWallpaperView. It is used not only to manage SurfaceControlViewHost, but also to receive views through addView(), so that the views can be rendered onto the cross-process Surface for display through setRemoteSurface().

[0092] To illustrate the three classes above, the content provider BaseWallpaperProvider acts as a "bus operator," responsible for answering all "request calls" from the host. BaseWallpaperProvider can not only understand general request voices but also automatically transfer calls to specific business departments (i.e., the lyrics wallpaper provider LrcWallpaperProvider) based on the type of business. However, BaseWallpaperProvider requires each business department to provide a "manufacturing specialist" (i.e., the lyrics view creator LrcViewFactory) to subsequently produce products (Views).

[0093] WidgetInstanceManager acts as a "dispatch and command center," recording each view. When it receives a view creation request from the target application, it executes the following standardized workflow: 1. Determine whether the target view corresponding to the target application already exists. If it does, load the target view directly into the host container corresponding to the target application for display to avoid waste. 2. If it does not exist, create a generic host container; 3. Create the target view; 4. Load the created target view into the general host container; 5. Record the completed target view for easy management later.

[0094] In the above Figure 2 In this framework, LrcWallpaperProvider, LrcViewFactory, and SmipleLrcView serve as the business layer of the target application, handling its view functionality. The following sections will introduce LrcWallpaperProvider, LrcViewFactory, and SmipleLrcView respectively.

[0095] LrcWallpaperProvider: A lyrics wallpaper provider, a subclass of the framework entry point BaseWallpaperProvider, and therefore can also be called the business entry point, specifically used to provide lyrics wallpapers.

[0096] LrcViewFactory: Lyrics view creator, also known as the target creator mentioned above, is an implementation class of the view creator interface IViewFactory, specifically designed for creating lyrics views.

[0097] SmipleLrcView: The lyrics view, which is the target view mentioned above. After creation, it can be sent to the view receiving interface IWallpaperView for hosting.

[0098] When the content manager BaseWallpaperProvider receives a view creation request from another application, it generates a business entry point for that application. This entry point is also a subclass of the content manager BaseWallpaperProvider. Based on the preset view creation standard of the view creator interface IViewFactory, it generates a view creator for that application, uses that view creator to create the view for that application, and then entrusts that view to the view receiving interface IWallpaperView. The singleton manager WidgetInstanceManager loads the view from the view receiving interface IWallpaperView into the host container SurfaceRootView for display.

[0099] Figure 3 This is a sequence diagram of a view display method for a target application provided in an embodiment of this application.

[0100] For example, such as Figure 3 As shown, the method 300 includes: Step 301: Launcher sends a request data packet to BaseWallpaperProvider.

[0101] Step 302: BaseWallpaperProvider parses the request data packet to obtain the view creation request.

[0102] Step 303: BaseWallpaperProvider delegates to WidgetInstanceManager to create the view corresponding to the target application.

[0103] Step 304: WidgetInstanceManager creates the host container corresponding to the target application.

[0104] Step 305: WidgetInstanceManager creates the target view creator corresponding to the target application.

[0105] Step 306: LrcViewFactory creates the target view.

[0106] Step 307: Load the target view into the host container corresponding to the target application for display.

[0107] The following is combined Figure 1 The method shown is for Figure 3 The steps of the method shown are explained below: First, the Launcher uses Android's IPC mechanism to call the `call()` method of the framework entry point `BaseWallpaperProvider` to send a request data packet. Upon receiving the request data packet, `BaseWallpaperProvider` parses it to obtain the view creation request corresponding to the target application. `BaseWallpaperProvider` then delegates the view business logic to the singleton manager `WidgetInstanceManager`. `WidgetInstanceManager` queries the `rootVews:Map` (i.e., the pre-stored mapping in `WidgetInstanceManager`) to determine if a host container corresponding to the target application exists. If it does, the host container corresponding to the target application is directly used as the target host container `SurfaceRootView`. If it does not exist, a generic host container is created and used as the target host container SurfaceRootView to host the business view to be created. Then, a business entry LrcWallpaperProvider that inherits from the framework entry BaseWallpaperProvider is generated, and a target view creator LrcViewFactory corresponding to the target application is created based on the view creator interface IViewFactory. At this time, the target view creator LrcViewFactory creates the specific target view SimpleLrcView and manages it to the view receiving interface IWallpaperView. Finally, the singleton manager WidgetInstanceManager loads the target view SimpleLrcView into the target host container SurfaceRootView, and the target host container SurfaceRootView completes the display of the target view SimpleLrcView.

[0108] In summary, the view display method for a target application provided in this application has the following beneficial effects: First, complete decoupling: The framework layer and business layer are completely separated, building a highly cohesive, loosely coupled plug-in architecture. This solution achieves complete decoupling of business logic from the underlying communication framework through a three-layer mechanism: interface hosting, creator creation, and host container isolation. Specifically, business developers only need to focus on two core contracts: implementing the view receiver interface IWallpaperView, defining the view's lifecycle and rendering behavior; and providing a concrete implementation of the view receiver interface IViewFactor for on-demand view creation. All complex logic interacting with the Android system—including cross-process Binder calls, Surface allocation and recycling, Display binding, etc.—is uniformly encapsulated at the framework layer by the content provider BaseWallpaperProvider and the singleton manager WidgetInstanceManager. The business layer has zero dependency on AIDL, zero contact with Binder, and zero handling of the Surface lifecycle, completely avoiding the deep coupling problems in traditional dynamic wallpaper development. This decoupling not only improves the view's scalability but also forms clear boundaries of responsibility.

[0109] Secondly, high scalability and runtime hot updates: Support for dynamic loading of business functions strictly adheres to the open / closed principle, meaning it is open for extension but closed for modification. When a new business type (e.g., video wallpaper) needs to be added, developers only need to write a new view creator, VideoViewFactory, to create a new view, VideoWallpaperView, without modifying any framework layer code, and without needing to recompile or deploy the Launcher.

[0110] Third, significantly improved development efficiency: maximized framework reuse, minimal business code, and accelerated product iteration. Through high-level abstraction and reuse of common logic, the technology in this application significantly reduces repetitive development workload. Taking the singleton manager BaseWallpaperProvider as an example, it encapsulates the creation process of the host container SurfaceRootView, which in turn handles the view display process uniformly. Actual tests show that the amount of business-side code is reduced by an average of about 70%. Taking "lyrics wallpaper" as an example, the traditional implementation requires writing a complete WallpaperService subclass (about 67 lines), including boilerplate code such as Surface lifecycle management, thread control, and event listening; while under the new architecture, developers only need to implement the lyrics view SimpleLrcView and the view creator LrcViewFactory, with the core business code compressed to less than 18 lines. This not only shortens the development cycle of individual functions but also reduces the number of days from design to launch of new UI effects.

[0111] Fourth, robustness and stability are comprehensively improved: The technical solution of this application sinks non-functional requirements such as resource management, exception protection, and thread safety to the framework layer to form a unified protection mechanism and avoid memory leaks caused by developers' negligence.

[0112] Figure 4 This is a schematic diagram of the structure of a view display device for a target application provided in an embodiment of this application.

[0113] For example, such as Figure 4 As shown, the device 400 includes: The receiving module 401 is used in the framework layer to receive a view creation request from the host corresponding to the target application.

[0114] Create module 402, which is used to create the target host container based on the view creation request.

[0115] Display module 403 is used to receive the target view created by the business layer and load the target view into the target host container to display the target view.

[0116] In one possible implementation, the creation module is specifically used to: determine whether a host container corresponding to the target application exists in the framework layer based on the view creation request; if it is determined that no host container corresponding to the target application exists in the framework layer, then create the target host container.

[0117] In one possible implementation, the display module includes a receiving unit, which is specifically used to: receive a target view created by the business layer through a view receiving interface; wherein the view receiving interface is located between the framework layer and the business layer and is used to host the target view created by the business layer.

[0118] In one possible implementation, the device further includes a generation module, specifically configured to: create a target view corresponding to the target application through the following steps: in the business layer, generate a target business entry corresponding to the target application; wherein the target business entry inherits from the framework entry in the framework layer, and the framework entry is used to receive a view creation request corresponding to the target application from the host; if the target business entry is determined, create a target view corresponding to the target application based on the preset view creation standard of the view creator interface; wherein the view creator interface is located between the framework layer and the business layer.

[0119] In one possible implementation, the generation module is specifically used to: upon determining that the target business entry point is obtained, create a target view corresponding to the target application based on the preset view creation standard in the view creator interface, including: upon determining that the target business entry point is obtained, generating a target view creator corresponding to the target application based on the preset view creation standard in the view creator interface; and creating a target view corresponding to the target application based on the target view creator.

[0120] In one possible implementation, the device further includes a determining module: if a host container corresponding to the target application exists in the determined framework layer, then the host container corresponding to the target application is taken as the target host container.

[0121] In one possible implementation, the framework layer includes a framework entry point. This receiving module is specifically used to: receive request data packets sent by the host through the inter-process communication mechanism via the framework entry point in the framework layer; parse the request data packets to obtain view information corresponding to the target application, so as to confirm that the view creation request has been received.

[0122] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0123] For example, such as Figure 5 As shown, the electronic device 500 includes a memory 501 and a processor 502. The memory 501 stores executable program code 5011, and the processor 502 is used to call and execute the executable program code 5011 to perform a view display method for a target application.

[0124] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform a view display method for a target application provided in embodiments of this application.

[0125] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0126] When each functional module is divided according to its corresponding function, the device may also include a receiving module, a creation module, and a display module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0127] It should be understood that the apparatus provided in this embodiment is used to execute the view display method of the target application described above, and therefore can achieve the same effect as the implementation method described above.

[0128] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant program code.

[0129] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0130] In addition, the apparatus provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a view display method for a target application provided in the above embodiments.

[0131] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the aforementioned related method steps to implement a view display method for a target application provided in the above embodiment.

[0132] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a view display method for a target application provided in the above embodiment.

[0133] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0134] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0135] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0136] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for displaying a view of a target application, characterized in that, The target application includes a framework layer and a business layer. The framework layer is used to construct the view framework of the target application, and the business layer is used to handle the view business of the target application. The method includes: In the framework layer, a view creation request corresponding to the target application is received from the host. Based on the view creation request, create the target host container; Receive the target view created by the business layer and load the target view into the target host container to display the target view.

2. The method according to claim 1, characterized in that, The creation of the target host container based on the view creation request includes: Based on the view creation request, determine whether there is a host container in the framework layer corresponding to the target application; If it is determined that there is no host container corresponding to the target application in the framework layer, then the target host container is created.

3. The method according to claim 1, characterized in that, Receiving the target view created by the business layer includes: The target view created by the business layer is received through a view receiving interface; wherein, the view receiving interface is located between the framework layer and the business layer, and is used to host the target view created by the business layer.

4. The method according to claim 1, characterized in that, Create a target view corresponding to the target application by following these steps: In the business layer, a target business entry point corresponding to the target application is generated; wherein, the target business entry point inherits from the framework entry point in the framework layer, and the framework entry point is used to receive a view creation request from the host corresponding to the target application; Once the target business entry point is determined, a target view corresponding to the target application is created based on the preset view creation standard of the view creator interface; wherein, the view creator interface is located between the framework layer and the business layer.

5. The method according to claim 4, characterized in that, The step of creating a target view corresponding to the target application based on the preset view creation standards in the view creator interface, after determining that the target business entry point has been obtained, includes: Once the target business entry point is determined, a target view creator corresponding to the target application is generated based on the preset view creation standard of the view creator interface. Based on the target view creator, a target view corresponding to the target application is created.

6. The method according to claim 2, characterized in that, The method further includes: If it is determined that a host container corresponding to the target application exists in the framework layer, then the host container corresponding to the target application is taken as the target host container.

7. The method according to claim 1, characterized in that, The framework layer includes a framework entry point, and receiving a view creation request from the host corresponding to the target application includes: In the framework layer, the request data packets sent by the host through the inter-process communication mechanism are received through the framework entry point; The request data packet is parsed to obtain view information corresponding to the target application, in order to confirm that the view creation request has been received.

8. A view display device for a target application, characterized in that, The target application includes a framework layer and a business layer. The framework layer is used to construct the view framework of the target application, and the business layer is used to process the view business of the target application. The apparatus includes: The receiving module is configured to receive, within the framework layer, a view creation request from the host corresponding to the target application; A creation module is used to create a target host container based on the view creation request; The display module is used to receive the target view created by the business layer and load the target view into the target host container to display the target view.

9. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the electronic device to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 7.

Images