General view processing method and device, storage medium and electronic equipment

Abstract

The application relates to a general view processing method and device, a storage medium and electronic equipment. The method comprises the following steps: constructing a floating layer container in a host Activity in advance; scanning the annotations of each Activity to be containerized display at the compilation stage, so as to identify the Activity that needs to be displayed in a floating layer mode, determine the Activity as a target Activity, and generate target Activity identification information identifying the target Activity; and performing a plug-in processing on an Activity starting method of the target Activity according to the target Activity identification information, so that when a starting request for the target Activity is detected at runtime, the target Activity is displayed in a floating layer mode in the host Activity. The application solves the technical problem of poor reusability of the existing Activity cross-terminal floating layer display.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and electronic device for processing general views. Background Technology

[0002] In Android application development, especially in scenarios that simultaneously support both Phone and Tablet devices, there are significant differences in interface display formats. With the diversification of terminal screen sizes and usage patterns, applications have seen a surge in customized view components, such as pop-ups, sidebar overlays, and bottom overlays, to enhance information capacity and interaction efficiency. However, in the Android system, Activities, as the core page carrier, are typically launched in full-screen mode by default. When an Activity is designed and implemented in full-screen mode on a Phone device, displaying it as a sidebar or overlay on a Tablet often requires extensive re-adaptation of the page structure, layout hierarchy, lifecycle management, and interaction logic, sometimes even necessitating the splitting or rewriting of the original page logic. Existing adaptation methods are not only costly to develop and complex to maintain, but also prone to introducing multiple page implementations, increasing system coupling and testing costs. Furthermore, the significant differences in display methods between different terminals make it difficult to establish a unified and reusable page management mechanism. Summary of the Invention

[0003] This application provides a method, apparatus, storage medium, and electronic device for processing a universal view, in order to solve the technical problem of poor reusability of existing Activity cross-terminal floating layer display.

[0004] Firstly, this application provides a method for processing a general view, comprising: pre-constructing a floating container in a host Activity, wherein the floating container is a side floating container or a middle floating container; scanning the annotations of each Activity to be containerized and displayed during compilation to identify the Activity that needs to be displayed in a floating manner and determine it as the target Activity, and generating target Activity identification information to identify the target Activity; and performing instrumentation processing on the Activity launch method of the target Activity according to the target Activity identification information, so that when a launch request for the target Activity is detected at runtime, a custom Fragment carrying the target Activity is created, and the custom Fragment is added to the floating container in the host Activity for display through Fragment management transactions, so that the target Activity is displayed in the host Activity in a floating manner.

[0005] Secondly, this application provides a general view processing apparatus, comprising: a construction module, configured to pre-construct a floating container in a host Activity, wherein the floating container is a side floating container or a middle floating container; an identification module, configured to scan the annotations of each Activity to be containerized and displayed during compilation to identify the Activity that needs to be displayed in a floating manner and determine it as the target Activity, and generate target Activity identification information to identify the target Activity; and a processing module, configured to perform instrumentation processing on the Activity launch method of the target Activity according to the target Activity identification information, so that when a launch request for the target Activity is detected at runtime, a custom Fragment carrying the target Activity is created, and the custom Fragment is added to the floating container in the host Activity for display through Fragment management transactions, so that the target Activity is displayed in the host Activity in a floating manner.

[0006] As an optional example, the above-mentioned building module includes: a setting unit, used to reserve a floating layer carrying area independent of the main content area in the page layout of the host Activity; an initialization unit, used to initialize the layout parameters of the floating layer carrying area according to the preset floating layer display type, so that the floating layer carrying area is configured as a side floating layer container or a middle floating layer container; and a configuration unit, used to configure a container management mechanism for controlling the display, hiding and hierarchical order of the floating layer carrying area, so as to support the target Activity to be dynamically displayed in the host Activity in the form of a floating layer.

[0007] As an optional example, the above apparatus further includes: a configuration module, configured to configure a custom annotation at the class definition level of the Activity that needs to be displayed in a floating manner before compilation, so as to identify it as an Activity that can be containerized and displayed; and a setting module, configured to set annotation parameters related to floating display in the above custom annotation, so as to declare that the corresponding Activity is displayed in a floating manner.

[0008] As an optional example, the identification module includes: an acquisition unit, used to acquire the class definition information of each Activity to be containerized and displayed, and to parse the custom annotations configured in the class definition information; a filtering unit, used to filter out the Activities identified as being displayed in a floating layer mode based on the parsing results of the custom annotations, and to determine them as target Activities; and a generation unit, used to generate corresponding target Activity identification information for the target Activities, wherein the target Activity identification information includes the class identification information and display attribute information of the target Activities.

[0009] As an optional example, the above processing module includes: a determining unit, used to locate the Activity launch method of the target Activity and determine the target location for instrumentation based on the target Activity identification information; and a processing unit, used to enhance or replace the Activity launch method based on the target location, so as to intercept the launch request for the target Activity at runtime, and trigger the execution of the overlay display logic when the launch request is intercepted.

[0010] As an optional example, the above apparatus further includes: a creation module, configured to, after performing instrumentation on the Activity launch method of the target Activity according to the target Activity identification information, create a custom Fragment instance when a launch request for the target Activity is intercepted, and create or associate the Activity instance of the target Activity in the custom Fragment; a determination module, configured to hold and manage the view of the target Activity as the content view of the custom Fragment; and an addition module, configured to add the custom Fragment to the floating container corresponding to the target Activity in the host Activity through the Fragment management transaction, so that the target Activity is displayed on the page of the host Activity in the form of a floating layer.

[0011] As an optional example, the above apparatus further includes: a judgment module, configured to determine whether a custom Fragment in a display state exists in the floating layer container after the target Activity is displayed on the page of the host Activity in the form of a floating layer, when a back operation is detected; a control module, configured to control the custom Fragment to be removed or hidden from the floating layer container when a custom Fragment in a display state exists in the floating layer container, and synchronously terminate or reclaim the target Activity carried by the custom Fragment; and an execution module, configured to execute page back processing according to the original back logic or back stack order of the host Activity when no custom Fragment in a display state exists in the floating layer container.

[0012] Thirdly, this application provides a storage medium storing a computer program, wherein the computer program is executed by a processor to perform the processing method of the above-described general view.

[0013] Fourthly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the processing method of the general view described above through the computer program.

[0014] The technical solutions provided in this application have the following advantages compared with the prior art: This application employs a method of pre-constructing a floating container within the host Activity, wherein the floating container is either a side-mounted floating container or a middle floating container. During compilation, the annotations of each Activity to be containerized are scanned to identify the Activity that needs to be displayed as a floating layer, and this Activity is identified as the target Activity. Simultaneously, target Activity identification information is generated. Based on the target Activity identification information, instrumentation is performed on the Activity launch method of the target Activity. This ensures that when a launch request for the target Activity is detected at runtime, a custom Fragment is created to house the target Activity. The custom Fragment is then added to the floating container within the host Activity through Fragment management transactions, thus displaying the target Activity as a floating layer within the host Activity. The above method pre-builds a side or middle overlay container in the host Activity, adds annotations to the Activity to be containerized during compilation, and scans and identifies it to generate corresponding target Activity identification information. Then, based on the identification information, instrumentation is performed on the launch method of the target Activity so that it is no longer displayed in full-screen mode when launched at runtime. Instead, a custom Fragment is created to carry the target Activity, and the Fragment manages transactions to add it to the overlay container of the host Activity for display. This achieves the overlay presentation of the Activity. Without modifying the original Activity business logic, the Activity can be flexibly displayed in full-screen or overlay mode on different terminals or in different scenarios. This significantly reduces the cost of cross-terminal interface adaptation, improves page reusability and system scalability, and solves the technical problem of poor reusability of existing Activity cross-terminal overlay display. Attached Figure Description

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

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0018] Figure 1 This is a flowchart of an optional general view processing method according to an embodiment of this application; Figure 2 This is a flowchart illustrating a specific implementation of an optional general view processing method according to an embodiment of this application. Figure 3 This is a schematic diagram of the structure of a processing device according to an optional general view of an embodiment of this application; Figure 4 This is a schematic diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0021] According to a first aspect of the embodiments of this application, a method for processing a general view is provided, optionally, as follows: Figure 1 As shown, the above method includes: S102, a floating container is pre-built in the host Activity, wherein the floating container is a side floating container or a middle floating container; S104, During compilation, the annotations of each Activity to be containerized and displayed are scanned to identify the Activity that needs to be displayed as a floating layer and determine it as the target Activity. At the same time, target Activity identification information is generated to identify the target Activity. S106. Based on the target Activity identification information, instrumentation is performed on the Activity launch method of the target Activity so that when a launch request for the target Activity is detected at runtime, a custom Fragment carrying the target Activity is created, and the custom Fragment is added to the floating container in the host Activity for display through the Fragment management transaction, so that the target Activity is displayed in the host Activity as a floating layer.

[0022] Optionally, this embodiment proposes a general view processing method applied to the Android platform, particularly suitable for application scenarios that simultaneously support both Phone and Pad devices. This method addresses the issues of high adaptation costs and poor reusability of existing Activity pages across different terminals and display formats. By uniformly modifying the Activity launch process, Activities that were originally displayed in full-screen mode can be flexibly displayed as side or center overlays without modifying their original implementation logic.

[0023] Specifically, such as Figure 2 The flowchart shown first demonstrates the pre-construction of a floating container within the host Activity. The host Activity is the Activity currently hosting the main interface. The floating container, independent of the host Activity's main content area, is used to hold pages displayed as floating layers. The floating container can be configured as a side-mounted or center-mounted floating container to adapt to different screen sizes and interaction scenarios, thus providing a unified foundation for the subsequent floating display of Activities.

[0024] Building upon this foundation, custom annotations are added to each Activity to be containerized and displayed in the application during compilation, and these annotations are uniformly scanned and parsed. Based on the parsing results, Activities marked as requiring display as overlays are identified and designated as target Activities. Simultaneously, corresponding target Activity identification information is generated for each target Activity. This target Activity identification information characterizes the target Activity's identity and its overlay display attributes, including at least the target Activity's class identifier and information related to the overlay display, such as container type, display position, or other display attributes, providing a basis for subsequent instrumentation and runtime processing.

[0025] Subsequently, instrumentation is performed on the target Activity's launch method based on the target Activity's identifier information. This instrumentation is completed at compile time. By enhancing or replacing the relevant launch methods used to launch the target Activity, when a launch request for the target Activity is detected at runtime, the application no longer directly launches the target Activity according to the original full-screen launch process, but instead executes the overlay display logic.

[0026] During runtime, when a launch request for the target Activity is intercepted, the system creates a custom Fragment to host the target Activity. The custom Fragment establishes a relationship with the target Activity and holds and manages the target Activity's view as the content view of the custom Fragment. Subsequently, through Fragment management transactions, the custom Fragment is added to the corresponding pre-built overlay container in the host Activity, thus displaying the target Activity as an overlay on top of the host Activity's interface. In this way, the target Activity remains logically an independent Activity, but its presentation is containerized and displayed as an overlay.

[0027] Optionally, in this embodiment, flexible switching of Activity display forms is achieved without disrupting the original Activity page structure and business logic, avoiding the problem of repeatedly developing and maintaining multiple sets of pages for different terminals or different display scenarios.

[0028] Optionally, this embodiment can achieve the floating display of Activity without modifying the original Activity implementation, significantly reducing the cost of cross-terminal adaptation; by using compile-time annotation scanning and instrumentation, it avoids the performance and stability risks caused by runtime system hooks; by utilizing the unified management mechanism of the host Activity and the floating container, it improves page reusability and the scalability of the overall architecture; it supports the flexible display of the same Activity in full-screen or floating mode on different devices or in different scenarios, improving user experience and development efficiency.

[0029] As an optional example, pre-building the overlay container in the host Activity includes: Reserve a floating layer area independent of the main content area in the page layout of the host Activity; Based on the preset floating layer display type, initialize the layout parameters of the floating layer carrying area so that the floating layer carrying area is configured as a side floating layer container or a middle floating layer container. Configure a container management mechanism for the floating layer area to control its display, hiding, and hierarchy order, so as to support the target Activity to be dynamically displayed in the host Activity as a floating layer.

[0030] Optionally, in this embodiment, the process of pre-building the overlay container in the host Activity can be achieved by uniformly planning and initializing the page structure of the host Activity. Specifically, during the page layout stage of the host Activity, an independent overlay carrying area is reserved in advance outside the main content area. This overlay carrying area is isolated from the core business view of the host Activity and is used specifically to carry the target Activity page displayed in overlay mode, thereby avoiding interference between the overlay content and the layout structure and interaction logic of the main content area.

[0031] After the overlay carrying area is constructed, its layout parameters are initialized and configured according to the preset overlay display type. The overlay display type indicates the overlay display format of the target Activity, such as a side overlay or a center overlay. When the overlay display type is a side overlay, the position, width ratio, and alignment of the overlay carrying area within the host Activity page are configured to display it close to one side of the page. When the overlay display type is a center overlay, the size, position, and centering parameters of the overlay carrying area are adjusted to display it either covering or floating above the main content area. Through flexible configuration of layout parameters, different terminal sizes and usage scenarios can be adapted without changing the main layout of the host Activity.

[0032] Furthermore, to support the dynamic display of target Activities as overlays within the host Activity, a corresponding container management mechanism is configured for the overlay carrying area. This mechanism uniformly manages the display and hiding states of overlay content and controls the hierarchical order among multiple overlays. For example, when a new target Activity is opened as an overlay, its corresponding overlay content is placed on top of the current display hierarchy through the container management mechanism; when an overlay is closed or hidden, it is removed from the overlay carrying area or its visibility is adjusted. Through these methods, the overlay carrying area can stably and controllably carry the overlay display of multiple target Activities, thus providing a reliable foundation for the overall overlay Activity display solution.

[0033] As an optional example, the above methods also include, prior to compile time: Configure custom annotations at the class definition level of Activities that need to be displayed as overlays to mark them as Activities that can be containerized for display; Set annotation parameters related to the overlay display in the custom annotation to declare that the corresponding Activity will be displayed in an overlay manner.

[0034] Optionally, in this embodiment, the Activities that need to be displayed as overlays are identified and configured before entering the compilation phase. Specifically, during the application development phase, developers can configure custom annotations at the class definition level of the Activities that need to be displayed as overlays to explicitly identify the Activity as an Activity that can be containerized and displayed. Custom annotations act directly on the Activity class itself and do not depend on the page layout or runtime logic, thus providing a clear and stable identification entry point for subsequent unified processing without changing the original business code structure of the Activity.

[0035] Furthermore, custom annotations can be used to set annotation parameters related to the overlay display, declaring the overlay display attributes for the Activity. Annotation parameters at least indicate whether the Activity uses an overlay for display, and can further describe the specific form of the overlay display, such as the type of overlay container corresponding to the Activity, its display position, or its display size ratio. By explicitly declaring overlay display attributes at the annotation level, the configuration of the page display format can be decoupled from runtime logic, making the display strategy more centralized and maintainable.

[0036] By employing the above method, the configuration for overlay display is moved forward to the Activity class definition stage, enabling consistent and accurate identification of Activities that need to be displayed as overlays during subsequent compile-time processing. Compared to determining the display format at runtime through conditional judgments or system hooks, this approach is structurally clearer and facilitates the construction of stable automated processing flows. Furthermore, the introduction of custom annotations provides excellent extensibility for overlay display. When additional display parameters or support for more overlay types are needed, only the annotation parameters need to be extended, without requiring large-scale modifications to the existing Activity's business logic.

[0037] As an optional example, the annotations of each Activity to be containerized are scanned to identify the Activity that needs to be displayed as a floating layer, and this Activity is identified as the target Activity. Simultaneously, target Activity identification information is generated, including: Obtain the class definition information of each Activity to be containerized and displayed, and parse the custom annotations configured in the class definition information; Based on the parsing results of custom annotations, select the Activities that are marked as being displayed as overlays and identify them as the target Activities; Generate corresponding target Activity identification information for the target Activity, wherein the target Activity identification information includes the class identification information and display attribute information of the target Activity.

[0038] Optionally, in this embodiment, the class definition information of each Activity to be containerized and displayed in the application is first obtained during compilation. The class definition information may include the Activity's class name, package name, and metadata information related to the class declaration. Based on this, the custom annotations configured in the class definition information are parsed, and the floating layer display-related parameters declared in the annotations are extracted. Through a unified annotation parsing process, intrusive modifications to the Activity source code logic can be avoided, while ensuring the consistency and accuracy of the obtained identification information.

[0039] Subsequently, based on the parsing results of the custom annotations, all Activities are filtered to identify those that need to be displayed as a floating layer, and these are designated as target Activities. The target Activities are the set of pages that require subsequent startup flow modifications and floating layer display. This filtering process clearly distinguishes between Activities displayed in normal full-screen mode and those requiring floating layer display, avoiding impact on unrelated pages.

[0040] After identifying the target Activity, corresponding target Activity identification information is generated for each target Activity. This target Activity identification information uniquely identifies the target Activity and its overlay display attributes, and includes at least the target Activity's class identifier and display attribute information related to the overlay display. The class identifier is used to locate the specific Activity class during subsequent processing, while the display attribute information indicates the overlay container type, display position, or other display parameters corresponding to the target Activity. By generating and maintaining this target Activity identification information, accurate identification and flexible control of the target Activity can be achieved during subsequent compile-time instrumentation and runtime display phases, thus providing reliable support for the stable implementation of the overall general view processing method.

[0041] As an optional example, instrumentation of the target Activity's launch method based on the target Activity's identifier information includes: Locate the Activity launch method of the target Activity and determine the target location for instrumentation based on the target Activity's identifier information; Enhance or replace the Activity launch method based on the target location to intercept launch requests for the target Activity at runtime, and trigger the execution of overlay display logic when a launch request is intercepted.

[0042] Optionally, in this embodiment, the Activity launch method used to start the target Activity in the application is first located based on the target Activity identification information. The Activity launch method may include system calls or framework methods used to trigger Activity transitions. By analyzing the class identification information of the target Activity and its call relationships, the target location where instrumentation needs to be performed is determined. The target location is used to indicate where the original launch logic should be enhanced or replaced to ensure that the launch request for the target Activity can be accurately captured at runtime.

[0043] After determining the target location, the Activity launch method is enhanced or replaced based on that location. This enhancement or replacement introduces logic to intercept launch requests while maintaining the integrity of the original method structure. When the application triggers a launch request for the target Activity during runtime, the instrumented launch method will prioritize executing the interception logic, thus preventing the target Activity from launching directly in the original full-screen mode.

[0044] Upon intercepting a launch request for the target Activity, the instrumentation logic triggers the execution of pre-defined overlay display logic. This overlay display logic replaces the original Activity launch process, guiding the target Activity to be displayed in an overlay manner. For example, it can be achieved by creating a custom Fragment to host the target Activity and adding it to the host Activity's overlay container. Through this instrumentation approach, unified control over the target Activity's launch behavior can be achieved at runtime, changing the target Activity's display format from full-screen to overlay. This allows for flexible and efficient switching of page display methods without intruding on existing business logic.

[0045] As an optional example, after instrumenting the Activity launch method of the target Activity based on the target Activity identifier information, the above method further includes: When a launch request for the target Activity is intercepted, a custom Fragment instance is created, and the Activity instance of the target Activity is created or associated within the custom Fragment. Hold and manage the view of the target Activity as the content view of the custom Fragment; By managing transactions using Fragments, a custom Fragment is added to the floating container corresponding to the target Activity within the host Activity, so that the target Activity is displayed as a floating layer on top of the host Activity's page.

[0046] Optionally, in this embodiment, when a launch request for the target Activity is intercepted during application execution, the system first creates a custom Fragment instance to host the target Activity. The custom Fragment serves as an intermediate unit for overlay display, used to import the target Activity's view content into the host Activity's page structure. After creating the custom Fragment, an Activity instance of the target Activity is created or associated within it, ensuring that the target Activity remains a logically independent Activity object, thereby guaranteeing its original lifecycle management and business logic can function normally.

[0047] Subsequently, the target Activity's view is held and managed as the content view of the custom Fragment. By directly entrusting the target Activity's UI view to the custom Fragment, the layout of the target Activity's page can be avoided, while its UI rendering process is isolated from the main content area of ​​the host Activity, thus achieving a floating display effect. The custom Fragment is responsible for the unified management of the target Activity's view's display state, including operations such as view loading, display, and release.

[0048] After completing the above steps, the custom Fragment is added to the corresponding overlay container in the host Activity using Fragment management transactions. This overlay container is a pre-built side or center overlay container in the host Activity, allowing unified control over the display position, hierarchy, and visibility of the overlay content. This method allows the target Activity's view to be displayed as an overlay on top of the host Activity's page without affecting the host Activity's original main content layout. Thus, while maintaining the original functionality and logical integrity of the target Activity, flexible switching of the Activity's page display format is achieved, providing a universal and low-cost technical solution for interface adaptation across multiple terminals and scenarios.

[0049] As an alternative example, after the target Activity is displayed as a floating layer above the host Activity's page, the above method also includes: When a return operation is detected, determine whether there is a custom Fragment in the floating container that is in the display state; If a custom Fragment is in the display state within the overlay container, control the removal or hiding of the custom Fragment from the overlay container, and synchronously terminate or reclaim the target Activity carried by the custom Fragment; If there is no custom Fragment in the floating container that is in the display state, the page back process is executed according to the original back logic of the host Activity or the back stack order.

[0050] Optionally, in this embodiment, when the system detects a return operation (including physical back button, gesture back, or navigation back) during runtime, it first determines whether there is a custom Fragment in the floating container maintained by the current host Activity that is in a display state. If a custom Fragment is detected in the floating container, the floating layer is processed first. The custom Fragment is removed or hidden from the floating container by controlling the Fragment transaction. At the same time, the lifecycle end, resource reclamation, or state saving logic of the target Activity it carries is triggered synchronously, thereby ensuring that the floating page can be closed in the expected order and avoiding resource leakage or state disorder. If it is determined that there is no custom Fragment in the floating container that is in a display state, it means that the current page is in the normal display state of the host Activity. The system returns the back control to the host Activity and executes the page back processing according to its original back logic or back stack order. By adopting the above method, without intruding on the business code, unified management and priority control of the back-back behavior of the floating layer Activity and the host page are achieved, effectively avoiding conflicts between the floating layer and the native back-back mechanism, and improving the consistency of page interaction, system stability and user experience under multi-terminal adaptation.

[0051] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0052] According to another aspect of the embodiments of this application, a general view processing apparatus is also provided, such as... Figure 3 As shown, it includes: Module 302 is used to pre-build a floating container in the host Activity, wherein the floating container is a side floating container or a middle floating container; The identification module 304 is used to scan the annotations of each Activity to be containerized and displayed during the compilation period to identify the Activity that needs to be displayed as a floating layer and determine it as the target Activity, while generating target Activity identification information to identify the target Activity; The processing module 306 is used to perform instrumentation on the Activity launch method of the target Activity according to the target Activity identification information, so that when a launch request for the target Activity is detected at runtime, a custom Fragment is created to carry the target Activity, and the custom Fragment is added to the floating container in the host Activity for display through the Fragment management transaction, so that the target Activity is displayed in the host Activity as a floating layer.

[0053] It should be noted that the construction module 302 in this embodiment can be used to execute step S102 in this application embodiment, the identification module 304 in this embodiment can be used to execute step S104 in this application embodiment, and the processing module 306 in this embodiment can be used to execute step S106 in this application embodiment.

[0054] As an optional example, the building blocks include: The setting unit is used to reserve a floating layer area that is independent of the main content area in the page layout of the host Activity; The initialization unit is used to initialize the layout parameters of the floating layer carrying area according to the preset floating layer display type, so that the floating layer carrying area is configured as a side floating layer container or a middle floating layer container. The configuration unit is used to configure a container management mechanism for the floating layer carrying area to control the display, hiding and hierarchical order, so as to support the target Activity to be dynamically displayed in the host Activity as a floating layer.

[0055] As an optional example, the above-described apparatus further includes: The configuration module is used to configure custom annotations at the class definition level of Activities that need to be displayed as overlays before compilation, so as to mark them as Activities that can be containerized and displayed. The settings module is used to set annotation parameters related to the display of the overlay in custom annotations, so as to declare that the corresponding Activity will be displayed in an overlay manner.

[0056] As an optional example, the recognition module includes: The acquisition unit is used to acquire the class definition information of each Activity to be containerized and displayed, and to parse the custom annotations configured in the class definition information; The filtering unit is used to filter out Activities that are marked as being displayed in a floating manner based on the parsing results of custom annotations, and to identify them as the target Activities; The generation unit is used to generate corresponding target Activity identification information for the target Activity, wherein the target Activity identification information includes the class identification information and display attribute information of the target Activity.

[0057] As an optional example, the processing module includes: The determining unit is used to locate the Activity launch method of the target Activity and determine the target location for instrumentation based on the target Activity's identification information; The processing unit is used to enhance or replace the Activity launch method based on the target location, so as to intercept the launch request for the target Activity at runtime, and trigger the execution of the overlay display logic when the launch request is intercepted.

[0058] As an optional example, the above-described apparatus further includes: The module is created to perform instrumentation on the Activity launch method of the target Activity based on the target Activity's identifier information. When a launch request for the target Activity is intercepted, a custom Fragment instance is created, and the target Activity's Activity instance is created or associated in the custom Fragment. The determination module is used to hold and manage the view of the target Activity as the content view of a custom Fragment; The Add module is used to add custom Fragments to the floating container corresponding to the target Activity in the host Activity through Fragment management transactions, so that the target Activity is displayed as a floating layer on the host Activity's page.

[0059] As an optional example, the above-described apparatus further includes: The judgment module is used to determine whether there is a custom Fragment in the floating layer container when a back operation is detected after the target Activity is displayed on the page of the host Activity in the form of a floating layer. The control module is used to remove or hide a custom Fragment from the overlay container when there is a custom Fragment in the overlay container that is in the display state, and to simultaneously terminate or reclaim the target Activity carried by the custom Fragment. The execution module is used to perform page back processing according to the original back logic of the host Activity or the back stack order when there is no custom Fragment in the floating container that is in the display state.

[0060] For other examples of this embodiment, please refer to the examples above, which will not be repeated here.

[0061] Figure 4 This is a schematic diagram of an optional electronic device according to an embodiment of this application, such as... Figure 4 As shown, it includes a processor 402, a communication interface 404, a memory 406, and a communication bus 408. The processor 402, communication interface 404, and memory 406 communicate with each other via the communication bus 408. Memory 406 is used to store computer programs; When processor 402 executes a computer program stored in memory 406, it performs the following steps: In the host Activity, a floating container is pre-built, which can be a side floating container or a middle floating container; During compilation, the annotations of each Activity to be containerized and displayed are scanned to identify the Activity that needs to be displayed as a floating layer and determine it as the target Activity. At the same time, target Activity identification information is generated to identify the target Activity. Based on the target Activity's identifier information, instrumentation is performed on the target Activity's Activity launch method so that when a launch request for the target Activity is detected at runtime, a custom Fragment is created to host the target Activity. The custom Fragment is then added to the floating container in the host Activity for display through Fragment management transactions, so that the target Activity is displayed in the host Activity as a floating layer.

[0062] Optionally, in this embodiment, the communication bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single thick line, but this does not indicate that there is only one bus or one type of bus. The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0063] The memory may include RAM, or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0064] As an example, the memory 406 described above may include, but is not limited to, the building module 302, the identification module 304, and the processing module 306 in the processing device of the general view described above. Furthermore, it may include, but is not limited to, other module units in the processing device of the general view described above, which will not be elaborated upon in this example.

[0065] The processor mentioned above can be a general-purpose processor, including but not limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0066] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0067] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. The device implementing the above general view processing method can be a terminal device, such as a smartphone (e.g., Android phone, iOS phone), tablet computer, PDA, mobile Internet Device (MID), PAD, etc. Figure 4 This does not limit the structure of the aforementioned electronic devices. For example, the electronic device may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0068] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, ROM, RAM, disk or optical disk, etc.

[0069] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, which, when executed by a processor, performs the steps in the processing method of the general view described above.

[0070] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0071] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0072] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0073] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0074] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of 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 system, 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, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0075] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0076] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0077] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing a general view, characterized in that, include: A floating layer container is pre-built in the host Activity, wherein the floating layer container is a side floating layer container or a middle floating layer container; During compilation, the annotations of each Activity to be containerized and displayed are scanned to identify the Activity that needs to be displayed as a floating layer and determine it as the target Activity. At the same time, target Activity identification information is generated to identify the target Activity. Based on the target Activity identification information, instrumentation is performed on the Activity launch method of the target Activity so that when a launch request for the target Activity is detected at runtime, a custom Fragment is created to carry the target Activity, and the custom Fragment is added to the floating container in the host Activity for display through Fragment management transactions, so that the target Activity is displayed in the host Activity as a floating layer.

2. The method according to claim 1, characterized in that, Pre-building the overlay container in the host Activity includes: In the page layout of the host Activity, a floating layer area independent of the main content area is reserved; According to the preset floating layer display type, initialize the layout parameters of the floating layer carrying area so that the floating layer carrying area is configured as a side floating layer container or a middle floating layer container. Configure a container management mechanism for the floating layer carrying area to control the display, hiding and hierarchical order, so as to support the target Activity to be dynamically displayed in the host Activity in the form of a floating layer.

3. The method according to claim 1, characterized in that, Prior to compilation, the method further includes: Configure custom annotations at the class definition level of Activities that need to be displayed as overlays to mark them as Activities that can be containerized for display; Set the annotation parameters related to the floating layer display in the custom annotation to declare that the corresponding Activity will be displayed in a floating layer manner.

4. The method according to claim 1, characterized in that, The annotations of each Activity to be containerized and displayed are scanned to identify the Activity that needs to be displayed as a floating layer, and this Activity is determined as the target Activity. Simultaneously, target Activity identification information is generated to identify the target Activity, including: Obtain the class definition information of each Activity to be containerized and displayed, and parse the custom annotations configured in the class definition information; Based on the parsing results of the custom annotations, the Activities that are identified as being displayed in a floating manner are selected and determined as the target Activities; Generate corresponding target Activity identification information for the target Activity, wherein the target Activity identification information includes the class identification information and display attribute information of the target Activity.

5. The method according to any one of claims 1 to 4, characterized in that, Based on the target Activity identifier information, the instrumentation process performed on the Activity launch method of the target Activity includes: Locate the Activity launch method of the target Activity, and determine the target location for instrumentation based on the target Activity's identifier information; The Activity launch method is enhanced or replaced based on the target location so that launch requests for the target Activity are intercepted at runtime, and when the launch request is intercepted, the floating display logic is triggered.

6. The method according to claim 5, characterized in that, After performing instrumentation on the Activity launch method of the target Activity based on the target Activity identifier information, the method further includes: When a launch request for the target Activity is intercepted, a custom Fragment instance is created, and an Activity instance of the target Activity is created or associated within the custom Fragment. The view of the target Activity is held and managed as the content view of the custom Fragment; The custom Fragment is added to the floating container corresponding to the target Activity in the host Activity through the Fragment management transaction, so that the target Activity is displayed on the page of the host Activity in the form of a floating layer.

7. The method according to claim 6, characterized in that, After the target Activity is displayed as a floating layer on top of the host Activity's page, the method further includes: When a return operation is detected, it is determined whether there is a custom Fragment in the floating layer container that is in a display state; If a custom Fragment is displayed in the floating layer container, control the custom Fragment to be removed or hidden from the floating layer container, and simultaneously terminate or reclaim the target Activity carried by the custom Fragment; If there is no custom Fragment in the display state in the floating layer container, the page back process is executed according to the original back logic of the host Activity or the back stack order.

8. A universal view processing apparatus, characterized in that, include: A building module is used to pre-build a floating layer container in the host Activity, wherein the floating layer container is a side floating layer container or a middle floating layer container; The identification module is used to scan the annotations of each Activity to be containerized and displayed during the compilation phase, so as to identify the Activity that needs to be displayed as a floating layer and determine it as the target Activity, and at the same time generate target Activity identification information to identify the target Activity; The processing module is used to perform instrumentation on the Activity launch method of the target Activity according to the target Activity identification information, so that when a launch request for the target Activity is detected at runtime, a custom Fragment is created to carry the target Activity, and the custom Fragment is added to the floating container in the host Activity for display through Fragment management transactions, so that the target Activity is displayed in the host Activity as a floating layer.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to perform the method described in any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 7 through the computer program.

Images