View hierarchy dynamic control method and related device

Abstract

The embodiments of the present disclosure disclose a view level dynamic control method and related equipment. The method comprises: constructing a level enumeration value of each type of view, the size of the level enumeration value mapping the display priority of the view in the vertical direction; wherein the encoding of the level enumeration value carries behavior control semantics; storing a target level enumeration value to a target view instance, the level enumeration value including the target level enumeration value, and the view including a target view; when the target view instance is added to a parent view, based on the target level enumeration value and the level enumeration value associated with the child view of the parent view, inserting the target view into a vertical direction position conforming to the display priority of the target view; according to the behavior control semantics carried by the target level enumeration value, determining that the target view matches a target mode, and then performing a preset display position adjustment operation on the target view to change the display state of the target view on the screen.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a view hierarchy dynamic control method, view hierarchy dynamic control device, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] In various applications with graphical user interfaces, it is often necessary to display multiple views simultaneously on the same screen, such as function operation areas, information display areas, pop-up reminders, and floating controls. Different views have different display priorities in the vertical direction (Z-axis), and their hierarchical relationship needs to be arranged reasonably according to business logic to avoid obscuring key information and ensure the normal operation of interactive operations.

[0003] Currently, the conventional method for managing view hierarchy is to hard-code and set a hierarchy value for each view individually. When there are many views and their types are complex, hierarchy conflicts or occlusion issues can easily occur when adding new views. Furthermore, if the hierarchy of a view needs to be adjusted, it is often necessary to modify the hierarchy attributes of multiple related views one by one, resulting in high maintenance costs and a high risk of errors. Summary of the Invention

[0004] This disclosure provides a view hierarchy dynamic control method, a view hierarchy dynamic control device, a computer device, a computer-readable storage medium, and a computer program product, which can prevent view hierarchy conflicts and achieve view hierarchy dynamic control under the same mode. Figure 1 To the point of being responsive.

[0005] This disclosure provides a method for dynamic control of view hierarchy. The method includes: constructing hierarchy enumeration values ​​for various types of views, wherein the size of the hierarchy enumeration values ​​maps the display priority of the views in the vertical direction; wherein the encoding of the hierarchy enumeration values ​​carries behavioral control semantics; associating and storing a target hierarchy enumeration value with a target view instance, wherein the hierarchy enumeration value includes the target hierarchy enumeration value, and the view includes the target view; when the target view instance is added to a parent view, based on the hierarchy enumeration value associated with the target hierarchy enumeration value and the hierarchy enumeration value associated with the child views of the parent view, inserting the target view into a vertical position that conforms to the display priority of the target view; determining, according to the behavioral control semantics carried by the target hierarchy enumeration value, that the target view matches a target mode, and then performing a preset display position adjustment operation on the target view to change the display state of the target view on the screen.

[0006] This disclosure provides a view hierarchy dynamic control device, comprising: a construction unit for constructing hierarchy enumeration values ​​for various types of views, wherein the size of the hierarchy enumeration values ​​maps the display priority of the views in the vertical direction; wherein the encoding of the hierarchy enumeration values ​​carries behavioral control semantics; a storage unit for storing a target hierarchy enumeration value associated with a target view instance, wherein the hierarchy enumeration value includes the target hierarchy enumeration value, and the view includes the target view; an insertion unit for inserting the target view into a vertical position that conforms to the display priority of the target view, based on the hierarchy enumeration value associated with the child views of the parent view, when the target view instance is added to a parent view; and an adjustment unit for determining that the target view matches a target mode according to the behavioral control semantics carried by the target hierarchy enumeration value, and then performing a preset display position adjustment operation on the target view to change the display state of the target view on the screen.

[0007] This disclosure provides a computer device including a processor, a memory, and an input / output interface. The processor is connected to both the memory and the input / output interface. The input / output interface is used to receive and output data. The memory is used to store a computer program. The processor is used to invoke the computer program to cause the computer device containing the processor to execute the method in any embodiment of this disclosure.

[0008] This disclosure provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, such that a computer device having the processor performs the methods of any embodiment of this disclosure.

[0009] This disclosure provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various alternative embodiments of this disclosure.

[0010] The view hierarchy dynamic control method, view hierarchy dynamic control device, computer equipment, computer-readable storage medium, and computer program product provided in this disclosure, on the one hand, achieve centralized and standardized management of view hierarchy by constructing a hierarchy enumeration value system that maps display priority to numerical values ​​and encodes behavioral control semantics. A single hierarchy enumeration value simultaneously completes hierarchy positioning and behavioral marking, reducing configuration complexity. On the other hand, by associating and storing hierarchy enumeration values ​​with view instances, view hierarchy can be independently marked, traceable, and managed in batches. Furthermore, when adding a view, insertion sort is automatically completed based on comparison of hierarchy enumeration values, eliminating the workload of manually specifying the hierarchy and preventing hierarchy conflicts from a mechanism perspective. Moreover, based on behavioral control semantics, display position adjustment is automatically executed when the view matches the target mode, achieving automated linkage between hierarchy management and scene response, reducing repetitive code for scene adaptation, and ensuring consistency of view behavior under the same mode. Attached Figure Description

[0011] Figure 1 This is an architecture diagram of a computer system provided in an embodiment of this disclosure.

[0012] Figure 2 This is a flowchart of a view hierarchy dynamic control method provided in an embodiment of this disclosure.

[0013] Figure 3 This is a flowchart of another view hierarchy dynamic control method provided in the embodiments of this disclosure.

[0014] Figure 4 This is a block diagram of a view hierarchy dynamic control device provided in an embodiment of this disclosure.

[0015] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this disclosure. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

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

[0018] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0019] Figure 1 This is a schematic diagram illustrating the implementation environment of a view hierarchy dynamic control method provided in this disclosure. For example... Figure 1 As shown, the implementation environment includes a computer device 101, which may be a server or a terminal. In this embodiment of the present disclosure, the view hierarchy dynamic control method of the present disclosure can be executed through the computer device 101.

[0020] In the application phase, this method can be deployed to various applications with graphical user interfaces, including but not limited to: live streaming applications, social applications, e-commerce applications, video conferencing applications, short video applications, multi-window split-screen applications, and accessibility applications. These application scenarios typically require the simultaneous display of multiple views, with dynamic management of the vertical display priority of each view.

[0021] In one application scenario, this method can be applied to the interface management of live streaming applications or video conferencing applications. Taking a live streaming application as an example, the live streaming interface contains multiple views (such as chat rooms, bulletin boards, function pop-ups, animation effects, document presentation windows, etc.). Through the hierarchical enumeration value system constructed in this embodiment, corresponding hierarchical enumeration values ​​are assigned to each view. The magnitude of the values ​​maps to the display priority, and the encoding carries behavioral control semantics. When a target view is added to a parent view, based on the comparison between the target hierarchical enumeration value and the hierarchical enumeration values ​​of existing child views, the target view is automatically inserted into a vertical position that matches its display priority. When the application scenario switches to a target mode (such as a clear screen mode), based on the behavioral control semantics carried by the target hierarchical enumeration value, the view matching the mode is automatically identified, and a preset display position adjustment operation is executed to change the display state of the view on the screen. In the following embodiments, the live streaming scenario is used as an example, but this disclosure is not limited to this.

[0022] In another application scenario, this method can be applied to the interface management of e-commerce detail pages or utility applications. Each functional area of ​​the detail page (such as the main product image, parameter area, review area, bottom purchase bar, customer service pop-up, etc.) is assigned a corresponding hierarchical enumeration value. During page loading or interaction, the system automatically sorts the hierarchy of each view according to the hierarchical enumeration value. When a specific scenario is triggered (such as a pop-up or screen orientation switching), the display position of the relevant views is automatically adjusted according to the behavior control semantics to avoid obscuring key interactive areas.

[0023] The server can be an independent physical server, a cluster of multiple physical servers, or a distributed system. It can also be a cloud server or server cluster providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, in-vehicle terminal, smart speaker, smartwatch, etc. The terminal and server can be directly or indirectly connected via wired or wireless communication. The specific connection method can be determined according to the actual application scenario, and this disclosure does not impose any limitations.

[0024] Figure 2 This is a flowchart illustrating a view hierarchy dynamic control method provided in an embodiment of this disclosure. The method provided in this embodiment can be executed by any computer device, including but not limited to terminals and / or servers. Figure 2 As shown, the method provided in this disclosure includes the following steps.

[0025] In S110, a hierarchy enumeration value for various types of views is constructed, and the size of the hierarchy enumeration value maps the display priority of the view in the vertical direction; wherein, the encoding of the hierarchy enumeration value carries behavioral control semantics.

[0026] In this embodiment of the disclosure, the hierarchical enumeration value refers to a set of enumeration constants with numerical relationships pre-assigned to various types of views in the application. The numerical value of the hierarchical enumeration value maps the display priority of the view in the vertical direction (i.e., the Z-axis direction, the direction perpendicular to the screen plane). The larger the value, the higher the display priority, and the higher the display priority of the view when it overlaps with other views. The view refers to the interface element in the application's graphical user interface used to display content or receive user interaction, including but not limited to function views and system views.

[0027] A functional view refers to a view created by developers to perform specific business functions. The following embodiments use functional views as examples, but the solutions provided in this disclosure are also applicable to system views, such as keyboards and pop-ups. Taking the keyboard as an example, the hierarchy of the keyboard's core functions, such as the typing area, can be changed without utilizing the solutions provided in this disclosure, but the hierarchy enumeration values ​​of the keyboard's non-core functional areas (i.e., second functional areas, such as input boxes, send buttons, blank areas, etc.) can be set. For example, the view hierarchy of the core functional area (i.e., the first functional area) of the system view is higher than the view hierarchy of the non-core functional areas of the system view and the view hierarchy of the functional view, thus avoiding conflict with the view hierarchy of the functional view.

[0028] For example, the hierarchical enumeration values ​​increase according to a preset gradient step size, with an insertion interval reserved between adjacent hierarchical enumeration values. For instance, the preset gradient step size can be 100, and the insertion interval reserved between adjacent hierarchical enumeration values ​​allows for the insertion of new hierarchical values ​​without adjusting existing enumeration values ​​when adding new view types later. It is understood that the 100 here is only for illustrative purposes, and this disclosure does not limit the specific value of the preset gradient step size.

[0029] In this embodiment of the disclosure, the encoding of the hierarchical enumeration value carries behavioral control semantics. The behavioral control semantics refer to the ability to express the type of operation that the view needs to perform in a specific scenario through the numerical encoding of the hierarchical enumeration value itself, without requiring additional configuration information.

[0030] For example, the behavior control semantics are carried by a preset number of digits in the hierarchical enumeration value. This embodiment of the disclosure can carry the behavior control semantics by using a preset number of digits in the hierarchical enumeration value; for example, different values ​​of the last digit represent different response behavior types.

[0031] For example, the preset operation includes performing a modulo operation on the preset digits of the target level enumeration value with a first preset value (hereinafter exemplified by 10, but this disclosure is not limited thereto), and the preset digits include the last digit of the target level enumeration value.

[0032] For example, when the last digit of the hierarchy enumeration value is 5, it indicates that the view is a clear screen response view, and the position adjustment operation of hiding or showing needs to be performed when the clear screen mode is switched; when the last digit is any other value, it indicates that the view does not respond to the clear screen mode.

[0033] In S120, the target level enumeration value is associated with and stored in the target view instance, wherein the level enumeration value includes the target level enumeration value and the view includes the target view.

[0034] In this embodiment of the disclosure, the target view refers to the specific view instance currently being operated on, and the target level enumeration value refers to the level enumeration value assigned to the target view. The associated storage refers to establishing a binding relationship between the target level enumeration value and the target view instance, so that the target view instance carries a unique level marker at runtime.

[0035] The implementation of the associated storage can differ across platforms. For example, on the iOS platform, the view level attribute (viewLevel) of the view base class (UIView) can be dynamically extended through the associated object mechanism of the Objective-C runtime; on the Android platform, the level enumeration value can be stored through the setTag method of the view base class (View); and on the Web platform, the level enumeration value can be stored through a custom data attribute (data-level). Through the aforementioned associated storage, each view instance can independently query its level information, achieving taggable, traceable, and batch-managed view levels. The following embodiments all use the Objective-C runtime extension mechanism as an example, but this disclosure is not limited to this.

[0036] In S130, when the target view instance is added to the parent view, the target view is inserted into a vertical position that conforms to the display priority of the target view, based on the target level enumeration value and the level enumeration value associated with the child view of the parent view.

[0037] In this embodiment of the disclosure, the parent view refers to the container view to which the target view is added. When a target view instance is added to the parent view through a view addition operation, the hierarchical enumeration values ​​associated with each of the existing subviews of the parent view are obtained. The target hierarchical enumeration value is compared with the hierarchical enumeration values ​​of each subview. Based on the comparison result, the insertion position of the target view in the subview array of the parent view is determined, so that the subview with the smaller hierarchical enumeration value is located at a lower position in the vertical direction, and the subview with the larger hierarchical enumeration value is located at a higher position, thereby automatically realizing the hierarchical sorting of incremental views.

[0038] For example, if the target layer enumeration value of the target view is 805, and the layer enumeration values ​​of the existing subviews in the parent view are 100, 305 and 2100 respectively, then by comparison, the target view is inserted above the subview with layer enumeration value 305 and below the subview with layer enumeration value 2100, so that it is in the correct display priority position.

[0039] In S140, based on the behavior control semantics carried by the target level enumeration value, it is determined that the target view matches the target pattern. Then, a preset display position adjustment operation is performed on the target view to change the display state of the target view on the screen.

[0040] In this embodiment of the disclosure, the target mode refers to a predefined interface display state or interaction scenario in the application. When the mode is activated, the display state or screen position of the relevant view is automatically adjusted. The matching refers to extracting behavioral control semantics from the encoding of the target level enumeration value, and determining whether the target view belongs to the view set that needs to respond to the target mode based on the behavioral control semantics. The display position adjustment operation refers to modifying the planar coordinates (e.g., X-axis and / or Y-axis directions) of the target view on the screen, including but not limited to translating the view outside the visible area of ​​the screen to achieve hiding, or translating the view back into the visible area of ​​the screen to achieve display.

[0041] The target modes in the embodiments of this disclosure include, but are not limited to, screen clearing mode, keyboard pop-up mode, landscape / portrait switching mode, and simple / normal mode.

[0042] Clear Screen Mode is a user interface display mode in which the application hides non-core views (such as chat rooms, bulletin boards, function buttons, pop-ups, etc.) with a single click, allowing the user to focus on the live content itself. Users can enter or exit Clear Screen Mode using preset gestures or interface controls. In Clear Screen Mode, interface elements marked as clear screen response views will automatically move out of the visible screen area; when exiting Clear Screen Mode, these views will return to their original positions.

[0043] Keyboard pop-up mode refers to an interaction mode that the interface enters when the system keyboard or in-app virtual keyboard is invoked and displayed on the screen. In this mode, the keyboard occupies a portion of the screen area and may obscure some functional views. By assigning hierarchy enumeration values ​​to non-core keyboard functional areas (such as input boxes, toolbars, background overlays, etc.) and views that need to avoid obscuring the keyboard, and automatically adjusting the display position or hierarchy of the relevant views when this mode is activated, key interactive areas can be avoided.

[0044] Landscape / portrait switching mode refers to a dynamic adaptation mode that the interface enters when the device orientation changes (such as when the user rotates the mobile terminal), causing the screen to switch between landscape and portrait display. In this mode, the position, size, and layout of some views need to be readjusted according to the new screen orientation to ensure that interface elements are displayed correctly and without errors in both landscape and portrait modes.

[0045] Simplified mode and normal mode are two switchable interface display modes. Simplified mode is typically used to simplify interface elements, highlight core content, or adapt to specific user scenarios (such as screen clearing linkage, low-performance device adaptation, etc.); normal mode is the interface state where regular functions are fully displayed. Switching between the two modes will trigger the display or hiding of the view, and the behavior control semantics carried by the hierarchy enumeration value can automatically respond.

[0046] For example, taking the target mode as the clear screen mode: when the last digit of the target level enumeration value is 5, the target view is determined to match the clear screen mode and belongs to the clear screen response view. When the application switches from non-clear screen mode to clear screen mode, the target view is horizontally shifted to outside the visible area of ​​the screen to hide it; when it returns from clear screen mode to non-clear screen mode, the target view is horizontally shifted back to the visible area of ​​the screen to restore its display.

[0047] Through the above steps S110 to S140, the embodiments of this disclosure realize centralized and standardized management of view hierarchy, automatic sorting of newly added views, and automatic response of view display status when scene mode is switched, effectively reducing the maintenance cost of view hierarchy management and the amount of repetitive code for scene adaptation.

[0048] The view hierarchy dynamic control method, view hierarchy dynamic control device, computer equipment, computer-readable storage medium, and computer program product provided in this disclosure, on the one hand, achieve centralized and standardized management of view hierarchy by constructing hierarchical enumeration values ​​for various views, mapping the numerical values ​​to vertical display priority, and encoding behavioral control semantics. The hierarchical relationship of all views is defined through a unified enumeration value system, with the numerical value directly reflecting the priority. Developers do not need to hardcode hierarchical values ​​scattered throughout the code; the hierarchical relationship is clear at a glance, transforming management from "dispersed and disordered" to "centralized and orderly." Simultaneously, the hierarchical enumeration values ​​carry dual information, reducing configuration complexity. The hierarchical enumeration values ​​not only express display priority but also carry behavioral control semantics in their encoding. Developers only need to assign a hierarchical enumeration value to a view to simultaneously complete hierarchical positioning and behavioral marking, eliminating the need to maintain separate hierarchical configuration tables and behavioral rule tables, resulting in high information density and low configuration cost. On the other hand, by associating and storing target hierarchical enumeration values ​​with target view instances, the view hierarchy becomes tagged, traceable, and batch-manageable. Each view instance carries its own hierarchy enumeration value. The system can query the hierarchy information of any view at runtime, and can also traverse, filter, and perform batch operations on all views by hierarchy value, solving the problem that view hierarchy information cannot be independently marked. Furthermore, by automatically inserting a target view into a vertical position that meets priority based on a comparison of hierarchy enumeration values ​​when it is added to a parent view, the system automates the hierarchy sorting of new views, eliminating the workload of manually specifying the hierarchy. Developers do not need to worry about the hierarchy position of a view relative to existing views when adding a view; the system automatically completes the insertion sorting based on the hierarchy enumeration value. This not only reduces the workload of manually writing sorting code but also avoids hierarchy errors and occlusion problems caused by human judgment mistakes. Moreover, when the target view matches the target pattern based on behavior control semantics, a preset display position adjustment operation is executed, changing the view's display state on the screen, achieving automated linkage between hierarchy management and scene response. When the application scenario changes (such as entering or exiting a certain display mode), the system can automatically identify the view that needs to respond based on the behavior control semantics carried by the view, and uniformly perform position adjustments. This eliminates the need for developers to write the display position adjustment logic for each view individually at the scene change point, reducing repetitive code for scene adaptation. At the same time, since the position adjustment operations of all views are driven by unified behavior control semantics, the view behavior under the same target mode is consistent, and there will be no problems such as inconsistent animation effects or different triggering conditions due to different developers or scattered code locations.

[0049] The following example, using a live streaming application scenario, illustrates the technical solution provided in this disclosure. However, this method can be applied to various applications with graphical user interfaces, such as live streaming applications, social applications, e-commerce applications, utility applications, video conferencing applications, short video applications, multi-window split-screen applications, and accessibility applications. For example, in a video conferencing scenario, hierarchical management can be implemented for views such as the speaker window, participant windows, chat windows, and shared screens; in an e-commerce details page scenario, views such as the main product image, parameter area, evaluation area, bottom purchase bar, and customer service pop-up can be automatically adapted; in short video applications, immersive mode switching can be implemented for views such as video footage, like / comment buttons, comment pop-up windows, and music effects; in multi-window split-screen mode, views can automatically adjust their hierarchy and display position; and in accessibility mode, view hierarchy and animation can be adjusted for visually impaired users to improve accessibility.

[0050] This disclosure provides a method, apparatus, system, and storage medium for dynamic control of view hierarchy, relating to the field of mobile application development, and particularly to live streaming interface development technology, specifically involving the automated management of view hierarchy within a live streaming room and the linkage implementation of screen clearing animation.

[0051] In live streaming mobile applications (especially e-commerce live streaming and conference live streaming scenarios), the live streaming interface typically contains numerous functional views, such as chat room views, announcement bar views, function pop-up views, animation effects views, and document presentation views. Different views need to be displayed at different vertical levels according to business logic to avoid undue obstruction of key interactive areas. Simultaneously, live streaming rooms generally have a need for screen-clearing interactions, where users can hide non-core views with a single click using preset actions, allowing the live stream to be focused on. The main technical issues related to this are as follows: First, view hierarchy management is chaotic. In traditional live streaming rooms, the hierarchy of views is mostly set through hard-coding. For example, the view corresponding to a streamer who appears first is below, and the view of a streamer who appears later is above, and this cannot be changed. When adding a view, hierarchy conflicts or occlusion issues are prone to occur. For example, the business expectation is that view A should be displayed above view B, but according to the hard-coded hierarchy values, view A can only be displayed below view B. In addition, when it is necessary to adjust the hierarchy of a view, the hierarchy attributes of multiple related views must be modified one by one, resulting in high maintenance costs.

[0052] Second, the screen clearing animation lacks coherence. The screen clearing operation requires writing separate hiding animation logic for each view to be hidden, resulting in high code redundancy. The animation effects, triggering conditions, and execution timing of different views often lack uniformity due to different developers or scattered code, leading to inconsistent user experience (UE).

[0053] Third, adapting to landscape / portrait mode and simplified mode switching is complex. When switching between landscape and portrait displays, or between simplified and normal modes, the display position and hierarchy of each view need to be adapted one by one. Related technologies require writing a large amount of repetitive adaptation code, which can easily lead to layout errors.

[0054] Fourth, there is a lack of unified hierarchical labeling and batch management capabilities. In traditional applications, views rely solely on the arrangement order of child views within a parent view to implicitly represent hierarchical relationships. This makes it impossible to independently label individual views or manage specific types of views in batches. When there are many types of views in a live streaming room and the scene changes rapidly, hierarchical management efficiency is low, and system scalability is insufficient.

[0055] To address at least one of the aforementioned issues, this embodiment constructs a hierarchical enumeration value system that maps numerical values ​​to display priorities and encodes behavioral control semantics. The hierarchical enumeration values ​​are associated and stored in each view instance. When a view is added, it is automatically sorted based on the comparison of the hierarchical enumeration values. When the scene mode is switched, the view position is automatically adjusted according to the behavioral control semantics. This achieves standardized management of view hierarchy, automatic sorting of newly added views, and automated linkage of scene response, effectively reducing the maintenance cost of hierarchical management and the amount of repetitive code for scene adaptation.

[0056] In this embodiment, the view hierarchy adjustment can be achieved by modifying the hierarchy enumeration value associated with the view instance. After the developer assigns or modifies the target hierarchy enumeration value for the target view, the system redetermines the vertical position of the target view based on the changed target hierarchy enumeration value, and automatically completes the layout update without modifying the hierarchy attributes of other views one by one.

[0057] This disclosure provides a method for dynamic control of view hierarchy, which is based on numerical gradient encoding combined with scenario-based rules to achieve automated management of view hierarchy and linkage with scene responses. This disclosure is based on the UIView and Objective-C runtime of the iOS platform for illustrative purposes, but its core ideas can be ported to other platforms. For example, in the Android platform, the hierarchy value can be stored through the setTag() method of the view base class, and the onLayout() method can be overridden to achieve automatic sorting; in the Flutter platform, a hierarchy attribute can be added to the drawing layer through a custom RenderObject; in React Native and Web platforms, the hierarchy value can be stored through a custom data attribute (such as data-level), and the screen clearing operation can be achieved by combining the z-index attribute of Cascading Style Sheets and script language traversal.

[0058] To address at least one of the aforementioned problems, embodiments of this disclosure achieve the following functionality by extending the view base class (e.g., UIView) and combining techniques such as hierarchical enumeration value definition, runtime associated storage, and method swizzling: (1) Standardized definition of view hierarchy enumeration values; (2) The hierarchical enumeration values ​​are associated with the view instance at runtime; (3) Automatic sorting and layout adaptation based on hierarchical enumeration value comparison; (4) Trigger screen clearing animation and scene linkage based on behavior control semantics carried by hierarchical enumeration values.

[0059] This disclosure standardizes the definition of the hierarchy values ​​of all views in the application scenario through enumeration types, with each hierarchy enumeration value corresponding to a type of view. The magnitude of the hierarchy enumeration value maps the display priority of the view in the vertical direction; the larger the value, the higher the display priority, and the view is displayed on the upper layer when it overlaps with other views.

[0060] In this embodiment, the hierarchical enumeration values ​​employ a numerical gradient design. The numerical gradient refers to setting the hierarchical enumeration values ​​to increase incrementally by a preset step size (e.g., 100), with an insertion interval reserved between adjacent hierarchical enumeration values. For example, the basic hierarchical values ​​can be set as a numerical sequence of 100, 200, 300, etc. When adding new view types, new hierarchical values ​​(e.g., 110, 150, 170, etc.) can be inserted within the reserved interval, achieving expansion without adjusting existing hierarchical enumeration values. This design ensures that the hierarchical system maintains overall order while possessing flexible dynamic expansion capabilities.

[0061] For example, taking a live streaming application scenario, the hierarchical enumeration values ​​are defined as follows (for illustrative purposes only, this disclosure is not limited thereto): 100-299 range: Basic live streaming layer (such as document presentation view, document presentation video view, etc.); 300-599 range: Interactive information layer (such as header shadow, countdown, navigation bar, broadcaster's network speed view, etc.); 600-899 range: Message animation layer (such as live room atmosphere messages, payment success messages, chat room views, etc.); 900-1399 range: Function operation layer (such as the same platform user layer, anchor function bar, sub-venue button, activity recommendation, etc.); 1400-1699 range: Pop-up display layer (such as audience list, announcement view, control panel, animations of interest, etc.); 1700-1999 range: Keyboard and tool layer (such as keyboard background view, keyboard layer, AI assistant floating button, etc.); 2000 and above: highest priority layer (such as reminder pop-ups, push views, screenshot sharing layer, etc.).

[0062] The aforementioned interval division places views belonging to the same functional category within the same hierarchical interval, facilitating unified management and batch operations. Furthermore, multiple views belonging to the same category can share the same hierarchical enumeration value. For example, multiple floating buttons can share the same hierarchical enumeration value; when a new floating button appears in the live stream, the hierarchical enumeration value of an existing floating button can be reused.

[0063] In this embodiment of the disclosure, the encoding of the hierarchical enumeration value also carries behavioral control semantics. The behavioral control semantics refer to the ability of the hierarchical enumeration value itself to express the type of response operation that the view needs to perform in a specific target mode, without requiring additional configuration information. Specifically, the behavioral control semantics can be carried by a preset number of digits in the hierarchical enumeration value. One implementation method is that the last digit of the hierarchical enumeration value represents the behavioral category of the view.

[0064] For example, the encoding rule ending in 5 is used as an example: when the last digit of the hierarchical enumeration value is 5 (i.e., the hierarchical enumeration value modulo 10 equals 5), the view is marked as a screen clearing response view, and a position adjustment operation must be performed when switching screen clearing modes. For example, the last digit of the header shadow view (305), the anchor network speed view (505), the chat room view (805), the anchor bottom function bar (1005), the top announcement view (1505), the AI ​​assistant floating button (1705), etc. are all 5, and they all belong to the set of screen clearing response views.

[0065] It should be noted that the above last-bit encoding is only an exemplary implementation of behavior control semantics. In practical applications, more complex mathematical encoding rules can be used to express more types of behavior identifiers. For example: the last two bits represent different behavior types (such as last bit 1 for clearing the screen and hiding, last bit 2 for keyboard avoidance, last bit 3 for landscape mode hiding, etc.); prime number encoding is used to represent special priorities; Fibonacci sequence encoding is used to ensure expansion intervals; or multiple rules can be allowed to take effect simultaneously through rule combination operations (such as (viewLevel / 100)%2==0 && viewLevel%10==5 means that two conditions are met at the same time).

[0066] For example, constructing the hierarchy enumeration values ​​for various types of views includes: defining the hierarchy enumeration values ​​in the category header file of the view base class, and declaring the hierarchy enumeration values ​​corresponding to various types of views in the enumeration type set in the category header file.

[0067] In some embodiments, the hierarchical enumeration values ​​are defined in the category header file of the view base class, and are centrally declared using enumeration types. When developers include this category header file, they can simultaneously obtain the definitions of all hierarchical enumeration values ​​and the corresponding hierarchical management capabilities without loading additional configuration files. In other possible implementations, unified hierarchical enumeration values ​​can also be provided through a separate configuration file for centralized management and to prevent developers from arbitrarily specifying values ​​in the code. This approach has the advantage of low intrusion.

[0068] For example, associating and storing the target hierarchy enumeration value to the target view instance includes: defining a view hierarchy attribute and its corresponding setting method for the view base class through category extension, wherein the view hierarchy attribute is used to carry the hierarchy enumeration value; in response to the assignment operation of the view hierarchy attribute, calling the setting method to store the passed target hierarchy enumeration value to the target view instance through a runtime association mechanism, so that the target view instance obtains the display priority and its behavior control semantics in the vertical direction through the view hierarchy attribute.

[0069] After the hierarchical enumeration value system is constructed, in response to the developer's hierarchical marking operation on the target view (such as specifying a corresponding target hierarchical enumeration value for a target view instance), this embodiment of the disclosure stores the target hierarchical enumeration value in the target view instance through a runtime association mechanism.

[0070] Taking the iOS platform as an example, the Objective-C runtime's Associated Object mechanism allows extending the view hierarchy attribute (e.g., named `viewLevel`) of the base view class (UIView) through a category, and implementing its setting method. Inside this setting method, the passed-in target hierarchy enumeration value is associated and stored in the target view instance via the `objc_setAssociatedObject` function. Thus, developers only need to call this setting method and pass in the target hierarchy enumeration value (e.g., `view.viewLevel=TJViewLevel_ChatRoom`) to complete the hierarchy marking and associated storage for the target view, ensuring that the view instance carries a unique hierarchy marker.

[0071] It should be noted that if a view does not have its view hierarchy attribute explicitly set, its default value can be set to zero (or other preset initial value), indicating that the view has the lowest display priority. This view will also participate in the subsequent automatic sorting process and will be arranged at the bottom.

[0072] In cross-platform implementations, the specific method of associated storage can be adjusted accordingly: on the Android platform, the hierarchy value can be stored through the `setTag()` method of the view base class; on the Web platform, the hierarchy value can be stored through custom data attributes (such as `data-level`); on the Flutter platform, the hierarchy attribute can be stored in the drawing layer through a custom `RenderObject`. Regardless of the platform used, the goal is to establish a one-to-one binding relationship between the hierarchy enumeration value and the view instance, so that each view instance can independently query its hierarchy information, achieving the taggability, traceability, and batch management of the view hierarchy.

[0073] For example, when the target view instance is added to the parent view, based on the target level enumeration value and the level enumeration values ​​associated with the child views of the parent view, the target view is inserted into a vertical position that conforms to the display priority of the target view. This includes: by overriding the view addition method of the parent view, intercepting the view addition operation when the view addition method is called; inside the view addition method, obtaining the level enumeration values ​​associated with each child view of the parent view and comparing them with the target level enumeration value; according to the comparison result, inserting the target view above the child views in the child view array of the parent view whose level enumeration value is less than the target level enumeration value and above the child views whose level enumeration value is greater than the target level enumeration value, so as to automatically realize the level sorting in the vertical direction.

[0074] In this embodiment of the disclosure, when the target view instance is added to the parent view, the target view is automatically inserted into a vertical position that conforms to its display priority based on a comparison between the target level enumeration value and the level enumeration values ​​associated with each of the current child views of the parent view.

[0075] For example, the level values ​​of all views in the live room are standardized by the enumeration type TJViewLevel. Each level enumeration value corresponds to a type of view, and the view that needs to participate in the screen clearing animation is marked by the rule "level value % 10 == 5".

[0076] For example, the hierarchy enumeration value ranges from 100 to ∞, and the screen clearing animation is marked as needed. The hierarchy enumeration value increases in order of business priority (e.g., Alert pop-up 2100 > Chat room 805) to ensure that high-priority views are not obscured. The hierarchy value of views that need to be cleared (such as header shadow, chat room, and bottom function bar of the anchor) ends in 5, which can be quickly identified by rules without the need for additional storage of markers.

[0077] Specifically, taking the iOS platform as an example, the view addition operation can be intercepted within the view base class's view addition method (such as the `addSubview:` method). When the target view is added, the hierarchy enumeration values ​​associated with all existing subviews of the parent view are obtained, and the target view's hierarchy enumeration value is compared with the hierarchy enumeration values ​​of each subview. Based on the comparison result, the insertion position of the target view in the parent view's subview array is determined, placing subviews with smaller hierarchy enumeration values ​​at lower vertical positions and subviews with larger hierarchy enumeration values ​​at higher positions, thus automatically achieving incremental view hierarchy sorting.

[0078] For example, if the target view has a hierarchy enumeration value of 805, and the existing child views in the parent view have hierarchy enumeration values ​​of 100, 305, and 2100 respectively, then by comparison, the target view is inserted above the child view with a hierarchy enumeration value of 305 and below the child view with a hierarchy enumeration value of 2100, placing it in the correct display priority position. This process is fully automated; developers do not need to worry about the hierarchy position of a view relative to existing views when adding it. The system automatically completes the insertion sort based on the hierarchy enumeration value, thus avoiding hierarchy conflicts caused by human error.

[0079] In other embodiments, adjacent level enumeration values ​​can also be set in an incremental manner, for example, the level enumeration values ​​can be set sequentially as 1, 2, 3, 4, etc.

[0080] In addition, when system views (such as keyboard, status bar, system pop-ups, control center, etc.) pop up, if the non-core functional areas of the system view are assigned corresponding hierarchical enumeration values, they will also be included in the above-mentioned automatic sorting logic.

[0081] For example, the scene state signal also represents the display mode state of the application interface, which includes switching between landscape and portrait modes, or between normal and simplified modes. The method further includes: when the display mode state changes, the observer subscribes to trigger the position update callback to automatically adapt the view layout under different display modes.

[0082] For example, based on the behavioral control semantics carried by the target level enumeration value, if it is determined that the target view matches the target pattern, then a preset display position adjustment operation is performed on the target view, including: when it is detected that the behavioral control semantics carried by the target level enumeration value matches the target pattern, creating an observer subscription to the scene state signal representing the target pattern, and encapsulating the position update callback in the subscription; when the value of the scene state signal changes, the preset display position adjustment operation is realized by automatically triggering the execution of the position update callback.

[0083] For example, determining whether the target view matches the target pattern based on the behavioral control semantics carried by the target level enumeration value includes: performing a preset operation on the preset number of the target level enumeration value to obtain the operation result; and determining whether the target view matches the target pattern based on the operation result.

[0084] For example, the target mode includes a screen clearing mode, and the display position adjustment operation includes a position adjustment operation for hiding or displaying a view. Specifically, determining that the target view matches the target mode based on the calculation result includes: determining that the target view matches the screen clearing mode when the calculation result equals a second preset value.

[0085] For example, when the value of the scene state signal changes, a preset display position adjustment operation is achieved by automatically triggering the position update callback, including: when the scene state signal indicates entering the clear screen mode, a translation operation is performed to translate the planar coordinates of the target view instance horizontally to outside the visible area of ​​the screen to hide the target view; when the scene state signal indicates exiting the clear screen mode, a translation operation is performed to translate the planar coordinates of the target view instance horizontally back to the visible area of ​​the plane to restore the display of the target view.

[0086] For example, when creating an observer subscription, the target view instance is passed to the location update callback in a first reference mode (weak reference), and when the location update callback starts executing, the first reference mode is converted to a second reference mode (strong reference) to the target view instance.

[0087] For example, performing a translation operation to move the planar coordinates of the target view instance horizontally outside the visible area of ​​the screen includes: performing a screen clearing animation using a first animation duration parameter to move the planar coordinates of the target view instance horizontally outside the visible area of ​​the screen. Wherein, performing a translation operation to move the planar coordinates of the target view instance horizontally back into the visible area of ​​the plane to restore the display of the target view includes: performing a restoration animation using a second animation duration parameter to move the planar coordinates of the target view instance horizontally back into the visible area of ​​the plane to restore the display of the target view; wherein the first animation duration parameter is less than the second animation duration parameter.

[0088] For example, the method provided in this disclosure further includes: when it is determined that the target view instance belongs to a preset pop-up type and the current screen orientation is landscape, triggering a layout reset operation of the target view instance before the panning operation.

[0089] After the view carries the hierarchy enumeration value and completes automatic sorting, this embodiment of the disclosure further executes a preset display position adjustment operation based on the behavior control semantics carried by the hierarchy enumeration value when the target view matches the target mode. The target mode includes, but is not limited to, screen clearing mode, keyboard pop-up mode, landscape / portrait switching mode, and switching between simplified mode and normal mode. Wherein: The following example, using the screen clearing mode, illustrates the linkage mechanism of scene response.

[0090] When a developer specifies a target hierarchy enumeration value for a target view using a setting method, the setting method internally checks whether the last digit of the set target hierarchy enumeration value modulo 10 equals 5. If so, it automatically creates an observer subscription relationship for the scene state signal representing the clear screen mode and encapsulates the position update callback within this subscription. This position update callback encapsulates the specific logic for adjusting the view position.

[0091] When the value of the clear screen mode status signal changes, including switching from a non-clear screen state to a clear screen state, or returning from a clear screen state to a non-clear screen state, the position update callback is automatically triggered. Specifically: when entering clear screen mode, a translation operation is performed to move the planar coordinates of the target view horizontally outside the visible area of ​​the screen to achieve hiding; when exiting clear screen mode, a translation operation is performed to move the planar coordinates of the target view horizontally back into the visible area of ​​the screen to achieve restoration of display.

[0092] When establishing the observer subscription relationship, the target view instance is passed to the location update callback using a weak reference to avoid memory leaks caused by the strong holding between the subscription relationship and the view instance. When the location update callback begins execution, the weak reference is temporarily converted to a strong reference to the target view instance to ensure that the view instance is not accidentally released during callback execution.

[0093] Furthermore, the aforementioned panning operation is executed using a first animation duration parameter when entering screen-clearing mode and a second animation duration parameter when exiting screen-clearing mode, with the first animation duration parameter being shorter than the second animation duration parameter. For example, the animation duration when entering screen-clearing mode can be set to zero (i.e., instantaneous hiding) to quickly respond to the user's screen-clearing operation; the animation duration when exiting screen-clearing mode can be set to 0.25 seconds to provide a smooth recovery transition. This differentiated design allows users to receive immediate feedback when triggering screen-clearing and a comfortable visual experience when canceling screen-clearing.

[0094] Furthermore, before performing a panning operation, the type attribute of the target view instance and the current screen orientation of the device can be determined. When it is determined that the target view instance belongs to the preset pop-up type and the current screen orientation is landscape, an additional layout reset operation for the view is triggered before and after the panning operation to recalculate its internal subview layout in landscape mode, avoiding layout disorder caused by changes in landscape width.

[0095] Regarding screen clearing animations, in addition to the basic "hide / show" states, multi-level screen clearing modes can be implemented. For example: lightweight screen clearing mode (only hiding views whose layer enumeration values ​​satisfy the first modulo operation condition), deep screen clearing mode (hiding more views whose layer enumeration values ​​satisfy the second modulo operation condition), and immersive mode (only retaining the live stream view and hiding all other views). Multiple screen clearing levels can be achieved by setting different modulo rules (such as mod 3, mod 4, mod 10, mod 100, etc.). Furthermore, custom screen clearing (allowing users to choose which views to retain during screen clearing) and timed screen clearing (automatically entering screen clearing mode after a period of inactivity) are also supported.

[0096] For example, the method provided in this disclosure further includes: when the target level enumeration value of the target view is dynamically adjusted after the target view has been added to the parent view, or when the vertical level order of each target view is disrupted, calling the sorting interface to rearrange the child views of the parent view according to their respective level enumeration values; and placing each child view on top of the parent view in the sorted order.

[0097] Based on the aforementioned automatic sorting mechanism, this disclosure also provides a sorting interface. When the view's hierarchy enumeration value is dynamically modified after the view has been added to the parent view, or when the vertical hierarchy order of the views is disrupted by external code operations (such as calling the system's bringSubviewToFront: or sendSubviewToBack: methods), this sorting interface can be called to fully rearrange all subviews of the parent view according to their respective associated hierarchy enumeration values. Following the rearranged order, each subview is placed at the top of the parent view to reconstruct the vertical hierarchy order that conforms to the hierarchy enumeration values.

[0098] This sorting interface serves as an error correction and fault tolerance mechanism, working in conjunction with the aforementioned automatic sorting: automatic sorting handles daily incremental insertion scenarios, while the sorting interface handles dynamic adjustments and exception recovery scenarios for existing views, jointly ensuring the correctness of hierarchical management under different circumstances.

[0099] For example, the target mode includes a screen clearing mode; when the target hierarchy enumeration value carries behavioral control semantics that determine that the target view matches the screen clearing mode, the display position adjustment operation includes adjusting the layout position of the target view. Specifically, performing a preset display position adjustment operation on the target view includes: exchanging a first layout setting method with a second layout setting method of the view base class; after the exchange, when the second layout setting method is called to set the planar coordinates of the target view, the first layout setting method is actually called; within the first layout setting method, based on the behavioral control semantics carried in the target hierarchy enumeration value associated with the target view and whether the current state is screen clearing mode, it is determined whether to correct the planar coordinates; if it is determined that the planar coordinates should be corrected, the corrected planar coordinates of the target view are calculated based on the display rules corresponding to the screen clearing mode, and the corrected planar coordinates are applied to the target view by indirectly calling the function name of the first layout setting method to change the display position of the target view on the screen; if it is determined that the planar coordinates should not be corrected, the planar coordinates are applied to the target view by indirectly calling the second layout setting method.

[0100] This disclosure also utilizes method swizzling technology to achieve automatic position correction based on behavioral control semantics and scene state during view layout.

[0101] Specifically, taking the iOS platform as an example, when the application starts (e.g., in the load method of the view base class category), the implementations of the view base class's original layout setting method (such as the setFrame: method, referred to as the second layout setting method) and the custom layout setting method (i.e., the first layout setting method) are swapped. After the swap, external code calls to the view layout setting method (such as view.frame=newFrame) actually enter the custom layout setting method.

[0102] Inside the custom layout setting method, the target hierarchy enumeration value associated with the target view is obtained. Based on the behavior control semantics it carries and the current scene state (such as whether it is in clear screen mode), it is determined whether the planar coordinates need to be corrected. If correction is required, the corrected planar coordinates are calculated based on the current scene state (for example, the horizontal coordinates are offset to the outside of the screen when clearing the screen, and offset back to the inside of the screen when restoring). The corrected planar coordinates are then applied to the target view by indirectly calling the original layout setting method, which has been swapped, through the function name of the custom layout setting method. If no correction is required, the original planar coordinates are directly applied to the target view through this indirect call.

[0103] By using the above-described method of exchange, coordinate correction logic based on hierarchy enumeration values ​​and scene state can be automatically inserted during each view layout operation without modifying any existing code. The method call path after the exchange is as follows: the external call to the setFrame: method actually enters the custom layout setting method, judges and corrects the coordinates, calls the function name of the custom layout setting method (at this time, the original setFrame: method implementation is actually executed), and completes the application of the corrected coordinates.

[0104] Although the above embodiments are primarily described using Objective-C on the iOS platform, the ideas presented in these embodiments can be ported to other platforms. On the Android platform, the layer enumeration value can be stored using the `setTag()` method of the view base class (android.view.View), automatic sorting based on the layer value can be achieved by overriding the `onLayout()` method, and position adjustments can be made using the view's `setTranslationX()` method or by modifying layout parameters. On the Flutter platform, a layer attribute can be added to the drawing layer using a custom `RenderObject`, and the drawing order and position of child components can be adjusted based on the layer value during the layout phase. On React Native and Web platforms, layer values ​​can be stored on DOM elements using custom data attributes (such as `data-level`), vertical layering can be managed using the `z-index` property of Cascading Style Sheets, and batch hiding and restoring in clear screen mode can be achieved by traversing the DOM using JavaScript.

[0105] The technical solutions provided in this disclosure can improve development efficiency in several ways. Firstly, view hierarchy and scene response are managed through a unified hierarchy enumeration value system. When adding a new view, only the corresponding hierarchy enumeration value needs to be assigned, eliminating the need to write repetitive layout and animation code, thus improving development efficiency. Secondly, maintenance costs are reduced. Adjusting the hierarchy only requires modifying the definition of the corresponding hierarchy enumeration value, without modifying the hierarchy attributes of each view individually. Once an enumeration value is modified, all view instances referencing that enumeration value automatically obtain the updated hierarchy, reducing maintenance costs. When it is necessary to temporarily change the hierarchy of a view, a new hierarchy enumeration value can be directly assigned to the view hierarchy attribute of that view instance, and the original value can be restored later. Thirdly, a unified user experience is provided. The screen clearing animation effect is standardized. All views requiring screen clearing are identified through unified rules and the animation logic execution position is adjusted uniformly, avoiding inconsistent animation effects and triggering conditions caused by different developers or scattered code. The layout remains consistent during landscape and portrait mode switching and simplified mode switching, avoiding view occlusion and layout errors. On the other hand, it boasts strong compatibility and ease of integration. Based on view base class classification extension and runtime association mechanisms, it exhibits low invasiveness to existing code structures. Existing projects can adopt this solution without large-scale migration; they only need to import the classification file and assign hierarchy values ​​to views according to the hierarchy enumeration value system. Furthermore, since it uses extended attributes rather than modifying native system attributes, it avoids conflicts with hierarchy operations in other modules. In addition, the system is highly scalable. The hierarchy management interface design supports the rapid integration of newly added views; only new hierarchy enumeration values ​​need to be assigned, improving system scalability. The reserved insertion interval through numerical gradient design provides ample space for future business expansion.

[0106] For example, embodiments of this disclosure can also achieve hierarchical state persistence by storing the viewLevel value and associated scene rules (such as screen clearing and hiding, and landscape / portrait screen adaptation) in a local configuration library.

[0107] For example, the target mode includes a keyboard pop-up mode. Perform a preset display position adjustment operation on the target view, including: when the system keyboard pops up, traversing each view instance that has been associated with and stored with a hierarchy enumeration value, and identifying the set of views that must be avoided in the keyboard pop-up mode; based on the identification result, creating a temporary overlay view for the keyboard pop-up mode, the temporary overlay view being assigned a corresponding hierarchy enumeration value and included in automatic sorting; when the temporary overlay view receives a click event, determining whether to pass the click event through based on the hierarchy enumeration value of the view below the clicked position; if the hierarchy enumeration value of the view below the clicked position is higher than the hierarchy enumeration value of the temporary overlay view, then passing the click event through to the view below the clicked position for processing; if the hierarchy enumeration value of the view below the clicked position does not exceed the hierarchy enumeration value of the temporary overlay view, then the temporary overlay view intercepts and responds to the click event to retract the system keyboard; when the system keyboard retracts, traversing the hierarchy enumeration values ​​of each view instance, batch removing the temporary views created in the keyboard pop-up mode, and restoring the view hierarchy state before the keyboard pop-up.

[0108] Taking live streaming applications as an example, when a user makes a text comment or search within the live stream, the system keyboard is brought up and displayed at the bottom of the screen. At this time, the keyboard and its related interface elements may obscure functional views such as the chat input box, send button, and emoji panel. Traditional solutions typically require developers to manually handle the interface avoidance logic when the keyboard pops up in each view controller, resulting in repetitive code and easy omissions.

[0109] In this embodiment of the disclosure, when the system keyboard pops up, the view instances in the current interface that have been associated with and stored with hierarchical enumeration values ​​are traversed, and the set of views that must be avoided in the keyboard pop-up mode is identified based on the hierarchical enumeration values ​​of each view. According to the identification results, a temporary overlay view is created for the keyboard pop-up mode. This temporary overlay view is assigned a corresponding hierarchical enumeration value (e.g., the hierarchical value located below the keyboard layer) and inserted into the correct vertical position through the aforementioned automatic sorting mechanism.

[0110] When the temporary overlay view receives a user's click event, it doesn't simply intercept all click events to hide the keyboard. Instead, it determines whether to pass the click event through based on the hierarchy enumeration value of the view below the clicked location. If there's a view below the clicked location with a higher hierarchy enumeration value than the temporary overlay view (e.g., a notification pop-up or push view at the highest priority level), the click event is passed through to that view for processing, allowing the user to continue operating the high-priority view while the keyboard is still active. For example, when the keyboard is active, the user can still directly click the "Same Platform Invitation" pop-up on the screen to respond without hiding the keyboard first. If the hierarchy enumeration value of the view below the clicked location does not exceed the temporary overlay view's hierarchy enumeration value (i.e., the view below is a normal function view or there are no other views), the temporary overlay view intercepts and responds to the click event, performing the operation of hiding the system keyboard, consistent with the user's expectation of hiding the keyboard by clicking on a blank area. When the system keyboard is retracted, the hierarchy enumeration values ​​of each view instance are traversed to quickly locate and remove temporary overlay views and other associated temporary views created in the keyboard pop-up mode, restoring the interface to the view hierarchy state before the keyboard pop-up.

[0111] This mechanism automates view avoidance in keyboard pop-up scenarios, eliminating the need for developers to write separate keyboard adaptation code for each page and reducing repetitive development work. Furthermore, by using click event pass-through based on hierarchy enumeration values, it provides a convenient interaction of clicking on a blank area to retract the keyboard when it pops up, without affecting the normal operation of high-priority views, thus avoiding interaction disruptions caused by keyboard overlays. Simultaneously, it automatically clears temporary views and restores the original hierarchy state after the keyboard is retracted, eliminating the need for developers to manually manage the lifecycle of temporary views.

[0112] The following examples, using some code, illustrate how the solutions provided in this disclosure are implemented.

[0113] The following example, using a live streaming application scenario, illustrates a specific definition method for hierarchical enumeration values ​​in this embodiment of the disclosure: typedef NS_ENUM(NSUInteger,TJViewLevel){ TJViewLevel_Document = 100, / / Document demonstration TJViewLevel_DocumentVideo = 200, / / Document demonstration video TJViewLevel_Shadow = 305, / / Clears and removes header and bottom shadows. TJViewLevel_BackCount = 400, / / Countdown level TJViewLevel_NaView = 402, / / Navigation bar view for landscape live stream TJViewLevel_NetworkSpeed ​​= 505, / / The network speed view for the broadcaster disappears after clearing the screen. TJViewLevel_AnimationMsgs = 600, / / Live stream atmosphere messages (click to grab, messages I'm interested in, messages to enter the live stream) TJViewLevel_AnimationMsgs_Pay = 700, / / Live stream notification for successful payment, ambient message TJViewLevel_ChatRoom = 805, / / Clear screen and disappear chat room view TJViewLevel_SameLive = 900, / / Same-platform user layer TJViewLevel_AnchorBottom = 1005, / / Clear screen and disappear the bottom function bar of the anchor. TJViewLevel_Left-TopListBtn = 1105, / / The "Request to Share Stage" button for the top-left sub-venue is cleared and disappears. TJViewLevel_RightTopaActivity = 1200, / / Activity carousel in the upper right corner TJViewLevel_ProjectBottom = 1305, / / Project recommendation pop-up below TJViewLevel_ActivityBottom = 1355, / / Pop-up window for recommended activities below / / Horizontal layer for recommended live streams / / TJViewLevel_ShareBubble = 1365, / / Shared bubble layer / / Temporarily commented out TJViewLevel_NormalPopUp = 1400, / / Audience list, sharing, control panel, initiate transaction, publish event, publish sub-venue, traffic generation, document demonstration folder, report, same-stage application list TJViewLevel_Announcement = 1505, / / Top announcement view, disappears when clearing the screen in portrait mode live streams. TJViewLevel_Announcement_L = 1105, / / Top announcement view, disappears when the live stream is in landscape mode. TJViewLevel_cooperationGif = 1600, / / Clicking on an image that interests me will bring up a GIF. TJViewLevel_KeyBoardBgView = 1699, / / Background view of the Emoticon keyboard TJViewLevel_KeyBoard = 1700, / / Emoticon keyboard layer TJViewLevel_AiAssistant = 1705, / / AI assistant floating button level TJViewLevel_UserInfo = 1800, / / Pop-up window for viewing user information TJViewLevel_Leave = 1900, / / Leave TJViewLevel_DetailPreView = 2000, / / Live stream password and details pop-up window TJViewLevel_EndLiveVideo = 2050, / / Live stream ends, promotional video clearing gesture animation layer TJViewLevel_RecommandView = 2070, / / Recommended view for live stream TJViewLevel_Alert = 2100, / / Alert pop-ups (stream increase / decrease pop-ups, same-stage invitation pop-ups, start same-stage pop-ups, same-stage rejection pop-ups, same-stage rejection pop-ups, leave to go to sub-venue pop-ups, currently presenting document pop-ups, start broadcast reminder, start same-stage) TJViewLevel_Push = 2200, / / Push notification / / The live stream title and close button location do not need to be specifically specified. TJViewLevel_Interest_Animation = 2300, / / Animation for intended collaboration TJViewLevel_ScreenShot = 2400, / / Screenshot sharing layer TJViewLevel_ShareBubble = 2405, / / Share bubble layer TJViewLevel_ShareForLandscape = 2410, / / Share pop-up for landscape live streaming }; The TJViewLevel enumeration type defines the hierarchy enumeration values ​​for all views in the live stream, ranging from 100 to 2410. Each enumeration value's name indicates its corresponding view type. The numerical value directly maps to the view's display priority in the vertical direction; a larger value indicates a higher display priority, meaning the view will appear on top when overlapping with other views. For example, the alert pop-up (TJViewLevel_Alert=2100) has a higher display priority than the chat room view (TJViewLevel_ChatRoom=805), ensuring that high-priority views are not obscured by low-priority views.

[0114] In the above definition, views corresponding to enumeration values ​​ending in 5 (such as 305, 505, 805, 1005, 1105, 1305, 1355, 1505, 1705, 2405) whose last digit modulo 10 equals 5 belong to the set of views that respond to screen clearing and will be automatically hidden or restored when switching screen clearing modes. Views corresponding to enumeration values ​​whose last digit is not 5 (such as 100, 200, 400, 402, 600, 700, 900, 1200, 1400, 1600, 1699, 1700, 1800, 1900, 2000, 2050, 2070, 2100, 2200, 2300, 2400, 2410) do not respond to screen clearing mode and maintain their display state during screen clearing.

[0115] To facilitate understanding the design philosophy of numerical gradients in the above hierarchical enumeration value system, the following explanation uses the hierarchical enumeration value (TJViewLevel_NaView=402) corresponding to the landscape navigation bar view as an example. The value of this enumeration is not arbitrarily set, but rather takes into account three design intentions: numerical gradient, business priority, and screen clearing behavior coding. Specifically, this is reflected in the following three dimensions: First, the numerical gradient dimension. TJViewLevel_NaView=402 belongs to the 400 gradient segment (between 400 and 499). Within this segment, below it is the layer enumeration value corresponding to the countdown view (TJViewLevel_BackCount=400), and above it is the layer enumeration value corresponding to the broadcaster's network speed view belonging to the 500 gradient segment (TJViewLevel_NetworkSpeed ​​=505). Choosing 402 instead of adjacent values ​​such as 401 or 403 reserves several usable intermediate values ​​between 400 and 505, such as 401, 403 to 499, and 500 to 504, to facilitate the insertion of other views with similar priorities (such as 410, 430, 450, etc.) within this segment in the future without adjusting the definition of existing layer enumeration values.

[0116] Second, the business priority dimension. The landscape navigation bar carries core interactive functions such as back, title, and more operations. Its display priority should be slightly higher than the countdown view that only displays information, but much lower than views closer to the core live broadcast operations, such as the broadcaster's network speed, chat room, and function bar. 402 is greater than 400, satisfying the priority requirement of "slightly higher than the countdown"; 402 is much less than 505, ensuring that the navigation bar will not obscure important views that need to be hidden when clearing the screen. This design allows the relative priority relationship of each view to be accurately expressed through numerical values.

[0117] Third, the encoding dimension of the screen clearing behavior. The core rule of this embodiment is that when the last bit of the hierarchy enumeration value is modulo 10 and equals 5, the view is marked as a screen clearing response view. The last bit of 402 is 2, which is not equal to 5. Therefore, the landscape navigation bar does not participate in the screen clearing animation when switching screen clearing mode and remains within the visible area of ​​the screen. This design meets the product expectation: users trigger screen clearing to block non-core information such as bullet comments and announcements, but the navigation bar (especially the back button) is an essential operation entry point and should be retained when clearing the screen. Otherwise, users will not be able to easily exit the screen clearing mode or perform the back operation. If the hierarchy enumeration value of the navigation bar is set to 405, its last bit is 5, and it will be incorrectly included in the screen clearing hidden list; if it is set to 400, it is the same as the countdown view hierarchy value, and it cannot be guaranteed that the navigation bar will always be displayed on the countdown.

[0118] The numerical gradient design in this embodiment is manifested at two levels: at the macro level, numerical intervals belonging to different functional categories are defined by step sizes (such as 100, 200, 300), with a large gap between each interval to allow for the expansion of functional layers; at the micro level, specific level enumeration values ​​within the same interval can be precisely set using smaller numerical intervals to finely control the relative hierarchical relationships between related views. This dual-level gradient design makes the level enumeration value system of this embodiment neither a rigid arithmetic sequence nor an isolated and scattered set of values, but a complete scheme with flexible and precise coding capabilities within an ordered framework.

[0119] When developers use this solution in the live streaming interface, they only need to declare a view instance, set its corresponding hierarchy enumeration value, and then add the view to the parent view to complete all the configuration for hierarchy marking and automatic sorting. For example, consider the bottom function bar view for the streamer: self.mBottomView=[[TJMeetingOnlineLiveBottomView alloc] init]; self.mBottomView.viewLevel=TJViewLevel_AnchorBottom; [self.view addSubview: self.mBottomView]; The three lines of code above complete the view creation, hierarchy marking, and addition operations, respectively. The first line creates a view instance for the bottom function bar of the anchor; the second line assigns the hierarchy enumeration value `TJViewLevel_AnchorBottom` (corresponding to a value of 1005) to this view instance through the view hierarchy attribute. The last digit of this value is 5, indicating that the view belongs to the clear screen response view set; the third line adds the view to its parent view, triggering the automatic sorting mechanism to insert the view into the vertical position that matches its hierarchy enumeration value. Developers do not need to write any additional hierarchy comparison code or animation listener code; subsequent clear screen responses, landscape / portrait adaptation, and other behaviors are all handled automatically by the system.

[0120] The following provides a detailed explanation of the internal implementation of the view level property setting method (setViewLevel:). This setting method encapsulates runtime associated storage of level enumeration values, automatic registration of screen clearing response behavior, and compatibility handling for special view types, achieving an integrated "setting is configuration" effect.

[0121] / / / viewLevel's set method

[0122] / / / @param viewLevel viewLevel

[0123] -(void) setViewLevel:(TJViewLevel) viewLevel{

[0124] objc_setAssociatedObject(self,_cmd,@(viewLevel), OBJC_ASSOCIATION_RETAIN); / / Stores the viewLevel value in the UIView instance through the Runtime association mechanism. if(viewLevel%10==5){ / / Determine if this view needs to participate in the screen clearing (last digit is 5)} @WeakSelf(self); / / Defines a weak reference to self to prevent subsequent blocks from strongly holding self and causing a retain cycle. [RACObserve(TJLiveInstance.shareInstance, isSimpleMode) subscribeNext:^(id_Nullable x) { / / Subscribe to the clear screen mode status signal and establish an observer subscription relationship. @StrongSelf(self); / / The block temporarily converts the view to a strong reference during execution to ensure that the view is not released during execution. BOOL isSimpleMode=[x boolValue]; / / Get whether the current screen clearing mode is active. if([self transformLeft]){ / / Determine if a left-moving animation / screen clearing animation is needed. [self transformFrameToLeft]; }else{ CGFloat maxWidth=MAX(UIScreenWidth,UIScreenHeight); / / Calculate the maximum screen width (compatible with landscape and portrait orientations) self.right= isSimpleMode?((self.right>0)?(self.right-maxWidth):self.right):((self.right>0)?(self.right>maxWidth?self.right-maxWidth):self.right):(self.right+maxWidth)); / / Adjusts the horizontal position of the view according to the clear screen mode. When clearing the screen, it shifts to the right by the screen width (moves out of the visible area); when not clearing the screen, it returns to its original position. BOOL isAlert=[self isKindOfClass:NSClassFromString (@"TJMeetingOnlineProjectAlertPopWindow")]; / / Determine if the current view is an alert pop-up. if(isAlert && kIsLandscape){ TJMeetingOnlineProjectAlertPopWindow aLert= (TJMeetingOnlineProjectAlertPopWindow self; [aAlert resetFrame:self.frame]; / / If it's a pop-up window in landscape mode, call resetFrame to reset the layout. } } }]; } The internal logic of the above setup method will be explained in detail step by step below.

[0125] Step 1: Using the Objective-C runtime's associated object mechanism, the passed-in hierarchy enumeration value (viewLevel parameter, i.e., the target hierarchy enumeration value) is associated and stored in the current view instance (self, i.e., the target view instance). `_cmd` is the unique identifier of the current method, serving as the key for the associated storage, ensuring that the hierarchy enumeration value of each view instance is stored independently and can be queried. `OBJC_ASSOCIATION_RETAIN` indicates that the value object is held by a strong reference. Through this mechanism, the hierarchy storage capacity of the view instance is dynamically extended without modifying the original definition of the view base class.

[0126] Step 2: Perform a modulo operation (modulo 10) on the passed-in level enumeration value and determine if the result is equal to 5. If it is equal to 5, it indicates that the view belongs to the clear screen response view set and needs to be automatically registered for clear screen response behavior; if it is not equal to 5, the setting method will only complete the association storage in Step 1 and then return, and the view will not participate in the clear screen response.

[0127] Step 3: Define a weak reference to the current view instance using `@WeakSelf(self)`. The purpose is that a code block will be created in subsequent steps and handed over to a signal from the reactive programming framework. If this code block directly and strongly references `self`, a circular chain of holding relationships will form: "view instance holding signal subscription - signal holding code block - code block holding view instance," preventing the view instance from being released and causing a memory leak. Therefore, by first passing the view instance to the code block using a weak reference, this circular chain is broken.

[0128] Step 4: Using the ReactiveCocoa (RAC) framework, create an observer subscription relationship for the scene state signal representing the clear mode (i.e., the isSimpleMode property on the TJLiveInstance.shareInstance singleton object). When the clear mode state changes (switching from non-clear mode to clear mode, or reverting from clear mode to non-clear mode), this signal will automatically trigger the execution of the subscription callback (i.e., the subsequent code block). This subscription relationship remains valid after it is set up until the view instance is destroyed.

[0129] Step 5: When the subscription callback (code block) begins execution, use `@StrongSelf(self)` to temporarily convert the weak reference passed in Step 3 into a strong reference to the current view instance. This conversion ensures that the view instance is not accidentally released throughout the callback execution, guaranteeing the safety of subsequent position adjustment operations. After the callback execution is complete, the strong reference is automatically released, and the circular holding chain remains broken.

[0130] Step 6: Get the current screen clearing mode status value (isSimpleMode) from the callback parameter x. This value is a boolean type, indicating whether the screen clearing mode is currently active.

[0131] Steps 7 through 9: Calculate and adjust the horizontal position of the view based on the screen clearing mode status. Specifically, if the view is currently in screen clearing mode, its planar coordinates are translated horizontally out of the visible screen area (i.e., offset to the right by one screen width) to achieve a hidden effect; if the view exits screen clearing mode, its planar coordinates are translated back into the visible screen area to restore display. Here, `maxWidth` takes the maximum value of the screen width and height to ensure compatibility with landscape and portrait screen switching scenarios.

[0132] Steps 10 and 11: Determine if the current view instance belongs to the preset pop-up type (i.e., the TJMeetingOnlineProjectAlertPopWindow class or its subclasses) and if the current device is in landscape mode. When both conditions are met, in addition to the panning operation, the resetFrame: method defined inside the pop-up view is called to recalculate its internal subview layout in landscape mode. This is because the width of the pop-up differs significantly between landscape and portrait modes, and simple panning may cause internal layout errors. A layout reset operation is needed to ensure the correctness of the display effect. It should be noted that the resetFrame: method itself is an existing layout method of the pop-up class. This solution does not change the internal implementation of this method, but rather implements the automatic triggering of this method by encapsulating the judgment conditions. Developers do not need to manually search for pop-up objects and determine whether to call this method in multiple scenarios. This call is automatically registered when setting the hierarchy enumeration value and is automatically executed when the scenario changes.

[0133] In the above setup method, the mechanism for converting between weak and strong references has the following technical effects: First, prevent memory leaks. Live streaming rooms contain numerous views that are frequently created and destroyed (such as pop-ups, animation effects, and temporary overlays). If a strong circular hold is formed between the observer subscription relationship established in the setup method and the view instance, these views cannot be released even after being removed from the interface, leading to continuous memory growth and potentially causing application lag or crashes. By passing view instances using weak references and temporarily converting them to strong references during callback execution, the safety of view instances during callback execution is ensured, and memory leaks caused by circular references are avoided, providing a fundamental guarantee for the long-term stable operation of the screen clearing listener function.

[0134] Secondly, it demonstrates the engineering feasibility of low-intrusion extension. This solution emphasizes low invasiveness to the existing code structure, meaning that hierarchical management and scene response capabilities can be added without changing the existing controller or view management logic. Directly implementing listener subscriptions in the category extension of the view base class requires careful handling of memory management issues; otherwise, low invasiveness might introduce new memory risks. Through the aforementioned reference management mechanism, this solution encapsulates complexity in the underlying extension. Upper-level developers only need to call the set method and pass in the hierarchy enumeration value, without needing to worry about the details of subscription creation and destruction, achieving a balance between simplicity and robustness.

[0135] The judgment conditions in steps 10 to 11 above are logical AND (&&), which require both isAlert and kIsLandscape to be true before the resetFrame: call is triggered. Therefore, the following three situations will not trigger this call: (1) the current view is not a pop-up window type; (2) the current device is in portrait mode; (3) neither of these conditions is met.

[0136] The reason why a pop-up window in portrait mode doesn't need to trigger `resetFrame:` ​​is that in portrait mode, the screen width is narrower, and the pop-up window width is usually close to or equal to the screen width. A simple translation operation can move it entirely into or out of the visible screen area without causing width overflow or internal layout errors. In landscape mode, however, the screen width is much larger than the height. If the pop-up window is simply translated, some areas may get stuck off-screen or the width of internal subviews may not adapt to the new orientation. Therefore, a layout reset operation needs to be triggered. This differentiated approach reflects a design philosophy that pursues automated management while ensuring precise compatibility for special scenarios.

[0137] This disclosure employs method swizzling to insert automatic correction logic based on hierarchy enumeration values ​​and scene states into the view layout setting method without modifying the original implementation of the view base class. Method swizzling is initiated during the application startup phase, specifically within the `load` method of the view base class's category extension. The `load` method is automatically invoked when the class is loaded into the runtime environment, ensuring that method swizzling is completed before all view instances are created.

[0138] +(void)load

[0139] {

[0140] / / Swap the implementations of the base UIView's `setFrame:` ​​method and the custom `liveRoom_setFrame:` ​​method. After the swap, the mapping between the method names and their implementation pointers (IMPs) is reversed: `setFrame:` ​​points to the implementation of the custom layout setting method, and `liveRoom_setFrame:` ​​points to the implementation of the base UIView's layout setting method.

[0141] Swizzling_exchangeMethod([UIView class],@selector(setFrame:), @selector(liveRoom_setFrame:)); } After the swap is complete, external code calls to view layout setting methods (such as view.frame=newRect) actually enter the custom layout setting method liveRoom_setFrame:. This method internally performs coordinate corrections based on the hierarchy enumeration values ​​and scene state, and then indirectly calls the swapped original implementation to complete the actual layout setting. -(void)liveRoom_setFrame:(CGRect)frame { / / Determine if the current view has a valid hierarchy and is a view that responds to screen clearing. if(self.viewLevel>=100&&self.viewLevel%10==5){ / / Determine whether a screen clearing animation should be executed (special handling in screen clearing mode). if([self transformLeft]){ / / Check if the x-coordinate has changed if(self.frame.origin.x !=frame.origin.x){ [self liveRoom_setFrame:frame]; / / Call the original setFrame implementation [self transformFrameToLeft]; / / Perform left frame shift. }else{ [self liveRoom_setFrame:frame]; / / The x-coordinate remains unchanged, so it is set directly. }else{ / / In the case of non-left shift, obtain the target frame and calculate the correct position. CGRect rect=frame; BOOL isSimpleMode=TJLiveInstance.shareInstance.isSimpleMode; CGFloat maxWidth=MAX(UIScreenWidth,UIScreenHeight); CGFloat frameRight=rect.size.width+rect.origin.x; / / Calculate the target position of the right edge of the view based on the clear screen mode CGFloat right= isSimpleMode?((frameRight>0)? (frameRight-UIScreenWidth):frameRight):((frameRight>0)? (frameRight>maxWidth?(frameRight-maxWidth):frameRight): (frameRight+UIScreenWidth)); / / If the calculated right edge position does not match the original value, correct origin.x if ((rect.origin.x+rect.size.width)!=right){ rect.origin.x=right-rect.size.width; } / / Call the original setFrame to set the corrected frame [self liveRoom_setFrame:rect]; } } else / / Call the original setFrame method directly if the view is not cleared or no valid layer is set. [self liveRoom_setFrame:frame]; } The internal logic of the above custom layout setting method will be explained in detail step by step below.

[0142] Step 1: Determine if the current view instance meets two conditions: First, the level enumeration value is greater than or equal to 100 (indicating a valid level value has been set); second, the last digit of the level enumeration value modulo 10 equals 5 (indicating that the view belongs to the clear screen response view set). Only if both conditions are met simultaneously will the coordinate correction logic proceed; otherwise, jump directly to Step 8, passing the original coordinate parameters to the original layout setting method implementation as is.

[0143] Step 2: Determine if the conditions for executing a left pan animation are met. A left pan animation is a screen-clearing animation that moves the view to the left side of the visible area of ​​the screen.

[0144] Step 3 (when the left shift condition is met): Compare the current horizontal coordinates of the view with the target horizontal coordinates to see if they have changed. If they have changed, first call the original layout setting method (via [self liveRoom_setFrame:frame], since the methods have been swapped, the actual implementation here is the system's original setFrame: method), applying the target frame to the view; then execute the left animation to move the view outside the visible area on the left side of the screen. If the horizontal coordinates have not changed, directly call the original layout setting method to complete the setting.

[0145] Steps four through seven (when the left-shift condition is not met): A coordinate correction method based on right edge calculation is adopted. First, obtain the clear screen mode state (isSimpleMode) and the maximum screen width (take the maximum value of the screen width and height to be compatible with landscape and portrait screen switching); then, calculate the current coordinates of the right edge of the target frame (frameRight); next, calculate the target position of the right edge according to the clear screen mode state.

[0146] The calculation logic for coordinate correction is as follows: If the screen is currently in clear mode, the right edge coordinates are subtracted from the screen width, causing the view to be horizontally shifted outside the visible area of ​​the screen to achieve hiding; if the screen is not in clear mode, the right edge coordinates are restored to the visible area of ​​the screen. If the calculated target position of the right edge is inconsistent with the original right edge position, the corrected horizontal coordinates (origin.x) are calculated based on the target position of the right edge to correct the view position. Finally, [self liveRoom_setFrame:rect] is called with the corrected frame as the parameter. Since the methods have been swapped, the liveRoom_setFrame: method name here actually points to the implementation of the system's original setFrame: method, so this call applies the corrected coordinate parameters to the view through the system's original layout path.

[0147] Step 8: For views that do not meet the two conditions in Step 1 (i.e., no valid layer value is set, or they do not belong to the clear screen response view set), the original frame parameter is directly passed to the system's original layout setting method through [self liveRoom_setFrame:frame] without any coordinate correction.

[0148] The call path after the method swap can be summarized as follows: the external `setFrame:` ​​method is called, which actually enters the custom layout setting method `liveRoom_setFrame:`, determines and corrects the coordinates, and then calls the `liveRoom_setFrame:` ​​method (at this point, the implementation of the original system `setFrame:` ​​method is actually executed), thus applying the corrected coordinates. This "method name and implementation misalignment" mechanism is a characteristic of method swapping technology. After the swap, the implementation corresponding to the `setFrame:` ​​method name has been replaced with custom logic, while the implementation corresponding to the `liveRoom_setFrame:` ​​method name is the original system logic. Therefore, calling `[self liveRoom_setFrame:rect]` in the custom method is not a recursive call to itself, but rather an indirect call to the original system implementation through the swapped method name. This design allows this solution to automatically insert coordinate correction steps based on hierarchy enumeration values ​​and scene states during each view layout operation without modifying any existing calls to `setFrame:`, achieving a zero-intrusion extension to the system layout behavior.

[0149] The essence of the aforementioned coordinate correction mechanism is to perform scene-aware translation transformation on the view's planar coordinates. In clear screen mode, the view's horizontal coordinates are offset horizontally by one screen width, causing the view to move out of the screen's visible area to achieve concealment. When exiting clear screen mode, the view's horizontal coordinates are translated back into the screen's visible area to restore its display. The view's size and the layout of its internal subviews remain unchanged during this process; only its overall position is translated.

[0150] Since the final layout setting method is called after coordinate correction, subsequent layout processing of the view, including layer attribute synchronization, transformation matrix calculation, subview layout triggering, rendering mark updating, automatic layout constraint processing, and animation submission, is all completed through the system's standard layout path. This solution only corrects the input parameters in advance; the subsequent layout process is entirely guaranteed by the system's verified mechanisms. Therefore, the correctness and stability of the layout result are consistent with directly calling the system's original method.

[0151] This embodiment of the disclosure achieves incremental view hierarchical sorting by overriding the view addition method of the view base class, intercepting the addition operation when the view is added to the parent view, and automatically determining the insertion position based on the comparison of the hierarchy enumeration value.

[0152] -(void)addSubview:(UIView )view{

[0153] / / Call the parent class's original addSubview method to complete the basic addition of the view.

[0154] [super addSubview:view];

[0155] / / Perform automatic sorting and insertion based on hierarchical enumeration values

[0156] [self insertSubview:view];

[0157] }

[0158] -(void)insertSubview: (UIView )view

[0159] {

[0160] / / Get all child views of the parent view

[0161] NSMutableArray <UIView > subviews=[NSMutableArray

[0162] arrayWithArray:self.subviews];

[0163] / / Iterate through existing subviews to find the correct insertion position.

[0164] for (UIView aSubView in subviews){

[0165] / / If the new view hierarchy value is greater than or equal to the currently traversed subview hierarchy value, continue searching forward.

[0166] if(view.viewLevel>=aSubView.viewLevle){

[0167] continue?

[0168] else

[0169] {

[0170] / / Find the first child view with a higher hierarchy value than the new view, and insert the new view below it.

[0171] [self insertSubview:view belowSubview:aSubview];

[0172] break

[0173] }

[0174] }

[0175] }

[0176] In the `addSubview:` method of the view addition class, the parent class's original addition method `[superaddSubview:view]` is first called to complete the basic operation of adding the view to the end of the parent view's subview array. Then, the `insertSubview:` method is called to perform automatic sorting and insertion based on the hierarchy enumeration values.

[0177] In the `insertSubview:` method, first, an array copy of all existing subviews of the parent view is obtained. Then, each subview in the array is traversed, and the level enumeration value (view.viewLevel) of the newly added view is compared with the level enumeration value (aSubView.viewLevel) of the currently traversed subview.

[0178] If the hierarchy enumeration value of the new view is greater than or equal to the hierarchy enumeration value of the currently traversed subview, it means that the display priority of the new view is not lower than that of the subview and should be displayed above that subview. Therefore, continue is executed to skip the current subview and continue to traverse and search.

[0179] If the hierarchy enumeration value of the new view is less than the hierarchy enumeration value of the currently traversed subview, it means that the first subview with a higher display priority than the new view has been found. At this time, [self insertSubview:view belowSubview:aSubView] is called to insert the new view below the subview (that is, in the vertical direction, it is one level below the subview), and then break is executed to terminate the traversal.

[0180] Through the above traversal comparison mechanism, the newly added view is automatically inserted into a vertical position that matches its level enumeration value: above all subviews whose level enumeration value is less than or equal to it, and below all subviews whose level enumeration value is greater than it.

[0181] The essence of the above automatic sorting algorithm is the application of insertion sort in view hierarchy management. Assuming that the existing subviews of the parent view are already arranged in ascending order of their hierarchy enumeration values ​​(i.e., views with smaller hierarchy values ​​are in lower vertical positions, and views with larger hierarchy values ​​are in higher positions), the new view can ensure that the entire subview array remains ordered after insertion by finding the first subview with a hierarchy value greater than its own in one traversal and inserting it below it.

[0182] This automatic sorting mechanism has the following technical advantages: First, when developers add views, they do not need to manually calculate and specify the view's hierarchical position in the parent view. The system automatically completes the insertion sort based on the hierarchical enumeration value, eliminating the need for manual code writing to manage hierarchical levels. Second, the sorting logic is encapsulated in the category extension of the view base class, making it transparent to the upper-level business code and conforming to the principle of low intrusion. Third, the insertion position is determined through a numerical comparison mechanism, which avoids hierarchical conflicts and occlusion problems caused by human judgment errors.

[0183] Based on the aforementioned automatic sorting mechanism, this embodiment of the disclosure also provides a sorting interface for full error correction when an anomaly occurs in the view hierarchy order. The implementation of the sorting interface is as follows: -(void)sortViewLevel{ / / Get all child views of the parent view NSMutableArray <UIView > subviews=[NSMutableArray arrayWidthArray:self.subviews]; / / Sort by hierarchical enumeration values ​​in ascending order for(int i=0;i<(subviews.count-1);i++){ for(int j=0;j<(subviews.count-i -1);j++){ if(subviews[j].viewLevel>subviews[j+1].viewLevel){ [subviews exchangeObjectAtIndex:j+1 withObjectAtIndex:j]; } } } / / Place each subview on top of the parent view in the sorted order. for(UIView (subview in subviews){ [self bringSubviewToFront:subview]; } } The execution logic of the above code will be explained in detail below.

[0184] Step 1: Obtain an array copy of all current child views of the parent view. The child views in this array may be out of order due to dynamic modification of the hierarchy enumeration values ​​or external code operations, and need to be rearranged.

[0185] Step Two: The subview array is rearranged using a sorting algorithm (bubble sort is used as an example in this embodiment, but any applicable sorting algorithm can be used in actual implementation). The sorting is based on the level enumeration value associated with each subview, arranged in ascending order of value. In the specific implementation of bubble sort, the subview array is traversed through a double loop, comparing the level enumeration values ​​of two adjacent subviews. If the level enumeration value of the preceding subview is greater than that of the following subview, their positions in the array are swapped. After sorting, the subviews in the array are arranged in ascending order of level enumeration value, that is, the view with the smaller level value is at the front of the array, and the view with the larger level value is at the back of the array.

[0186] Step 3: Following the sorted array order, call the `bringSubviewToFront:` method on each subview in sequence. This method moves the specified view to the end of the parent view's subview array. During view rendering, the order of the subview array from front to back corresponds to the vertical hierarchy from bottom to top. In the sorted array, the view with the smallest hierarchy enumeration value is at the front of the array and is first moved to the end of the array (i.e., the top layer) by calling `bringSubviewToFront:`; then the view with the second smallest hierarchy enumeration value is moved to the top layer, and so on. After the traversal is complete, the view with the largest hierarchy enumeration value is moved to the top layer last, ultimately occupying the highest position in the vertical direction. Through the above sequence of operations, the vertical hierarchy order of all subviews in the parent view is reconstructed to the correct order that strictly corresponds to the size of their respective hierarchy enumeration values.

[0187] The automatic sorting mechanism and sorting interface mechanism in this embodiment have different triggering conditions and applicable scenarios. The two work together to form a complete closed loop of view hierarchy management.

[0188] The automatic sorting mechanism is triggered when a view is added to its parent view (addSubview:). This mechanism takes effect during incremental view insertion, ensuring that each new view is automatically placed in the correct position matching its hierarchy enumeration value. Automatic sorting is a routine incremental operation, ensuring the real-time order of newly added views. However, the automatic sorting mechanism cannot cover the following two scenarios: Scenario 1: The hierarchy enumeration value of a view is dynamically modified after it has been added to the parent view. When a view has been added and is in the parent view's subview array, if its hierarchy enumeration value is assigned a new value due to business requirements (e.g., changed from 805 representing a chat room view to 2100 representing a notification pop-up), this modification will not trigger the `addSubview:` method again, and therefore automatic sorting will not be executed. At this point, although the view's hierarchy enumeration value has been updated to the new value, its actual position in the subview array remains unchanged, causing a mismatch between the hierarchy value and the actual display position.

[0189] Scenario 2: External code directly alters the order of subviews using native system methods. In live streaming applications, third-party libraries, legacy code, or code written by other developers may directly call native system methods (such as `bringSubviewToFront:`, `sendSubviewToBack:`, or `insertSubview:aboveSubview:`) to manipulate the view hierarchy. These operations bypass the automatic sorting mechanism of this solution and may directly change the position of subviews in the array, leading to a discrepancy between the hierarchy order and the size of the hierarchy enumeration values.

[0190] The sorting interface mechanism is a full-scale error correction mechanism designed to address the two scenarios mentioned above. It doesn't care how views were added or how the current order was disrupted; it only uses the current hierarchy enumeration value associated with each view as the sole basis to completely rearrange all child views of the parent view, forcibly restoring the correct hierarchy order. When an exception occurs that automatic sorting cannot cover, the sorting interface mechanism is called once by the developer or the system at an appropriate time to completely correct the disordered hierarchy.

[0191] In this embodiment, an interception and fault tolerance dual-layer architecture is formed between automatic sorting and the sorting interface: automatic sorting is responsible for real-time ordering during daily incremental insertion, while the sorting interface is responsible for error correction and recovery of the existing view after dynamic changes or external intervention. The two complement each other rather than replace each other, and together ensure that the view hierarchy strictly conforms to the display priority relationship defined by the hierarchy enumeration value under any circumstances.

[0192] In this embodiment, automatic sorting and the sorting interface jointly manage the occlusion relationship of views in the vertical direction (Z-axis), i.e., determining "which view is on top and which view is below"; while the layout position adjustment implemented by the method exchange technology (such as coordinate correction in clear screen mode) manages the display position of views in the horizontal direction (X / Y-axis), i.e., determining "where the view appears on the screen". The three operate independently and in parallel. Specifically: when a view is created and its level enumeration value is set, it is placed in the correct layer position on the Z-axis through automatic sorting; when the business code sets the planar coordinates of the view, due to the method exchange mechanism, the coordinates are checked by the custom layout setting method before being actually applied. If the current scene mode is a specific scenario mode (such as clear screen mode) and the level enumeration value of the view carries the corresponding behavior control semantics, its X / Y coordinates are automatically corrected (such as moving the view outside the visible area of ​​the screen during clear screen); when the Z-axis level order is disrupted due to dynamic modification of the level enumeration value or external code operations, the sorting interface can be called for full error correction. The three elements act on different layout attributes of the view, execute in parallel without interfering with each other, and together form a complete closed loop of view hierarchy and position management.

[0193] In this embodiment, the sorting interface mechanism has the following technical effects: First, it overcomes the limitation that automatic sorting is only triggered when added and cannot cover dynamic modification and external intervention scenarios, enabling this solution to maintain hierarchical correctness in various complex engineering environments; Second, by providing an explicit call interface, it empowers developers to actively trigger full sorting when needed, increasing the system's flexibility and controllability in scenarios such as abnormal recovery and state reset; Third, the two-layer architecture design of automatic sorting and sorting interface enhances the robustness of the solution and avoids the stability defects that pure automation solutions may suffer from due to their inability to cover boundary scenarios.

[0194] In this embodiment of the disclosure, when the clear screen response view switches to clear screen mode, it needs to perform a position adjustment operation. This operation is implemented through the view position update function transformFrameToLeft. This function is encapsulated in the callback subscribed by the observer and is automatically triggered when the clear screen mode state signal changes.

[0195] -(void)transformFrameToLeft

[0196] {

[0197] / / Get current scene status information

[0198] BOOL isSimpleMode=TJLiveInstance.shareInstance.isSimpleMode;

[0199] / / Get the live stream controller

[0200] UIViewController aVC=TJ LiveInstance.shareInstance.liveVC;

[0201] / / Get the status of the live chat panel

[0202] BOOL isOpen=[[aVC valueForKeyPath:@”mLiveBoardView.isOpen”]boolValue];

[0203] / / Get the number of people connected in the live stream

[0204] NSInteger playerCount=[[aVC

[0205] valueForKeyPath:@”mLiveBoardView.wapper.playerCount”]integerValue

[0206] / / Get the maximum screen width

[0207] CGFloat maxWidth=MAX(UIScreenWidth,UIScreenHeight);

[0208] / / Check if the current view's type attribute is a pop-up type

[0209] BOOL isAlert=[self

[0210] isKindOfClass:NSClassFromString

[0211] (@”TJMeetingOnlineProjectAlertPopWindow”)];

[0212] BOOL isMiniAlert=[self

[0213] isKindOfClass:NSClassFromString

[0214] (@”TJMeetingOnlineProjectAlertPopWindow”)];

[0215] BOOL aBool=(isAlert / / isMiniAlert)&& !kIsLandscape;

[0216] / / Execute the animation, determining its duration and target position based on the scene state.

[0217] [UIView animateWithDuration:isSimpleMode?0:.25 animations:^{

[0218] self.left=(isSimpleMode / / (isOpen&&playerCount>0))?

[0219] -maxWidth: / / When clearing the screen or during a live chat, move it to the outer left side of the screen.

[0220] kAdaptTopW(10); / / Otherwise, move to a position 10 units away from the left.

[0221] }];

[0222] }

[0223] The execution logic of the above code will be explained in detail below.

[0224] Step 1: Obtain Current Scene State Information. Before adjusting the position, first obtain the current scene state related to the animation decision. This includes: whether the screen is currently in clear mode (isSimpleMode); whether the current live chat panel is open (isOpen); the number of participants in the current live chat panel (playerCount); and the maximum width of the current screen (maxWidth, the maximum of the screen width and height to ensure compatibility with landscape and portrait screen switching). The above state information collectively determines the duration and target position of the subsequent animation.

[0225] Step 2: Determine the type attribute of the current view. Through runtime type determination, determine whether the current view belongs to the alert pop-up type (TJMeetingOnlineProjectAlertPopWindow or its subclass), and combine this with the current screen orientation to determine whether the pop-up is in portrait mode. This determination result can be used for special layout handling during subsequent landscape / portrait switching.

[0226] Step 3: Execute the animation, and determine the animation duration and view target position based on the scene state.

[0227] Regarding animation duration: If the current screen clearing mode is true, the animation duration is set to zero, meaning the view's position movement is completed instantly. If the current screen clearing mode is false, the animation duration is set to 0.25 seconds, meaning the view transitions smoothly to the target position with an animation.

[0228] In this embodiment, the state variable in the code is named isSimpleMode, but in the description of the specific implementation, it is repeatedly described as "screen clearing mode". The relationship between the two is as follows: From a business perspective: Clear Screen Mode refers to a user-initiated action via preset gestures or interface controls to hide non-core views with a single click, aiming to focus on the live stream. Simplified Mode is a switchable interface display mode used to simplify interface elements and highlight core content. It can be accessed via the Clear Screen action or through other methods (such as a settings switch). Both modes achieve the same result: hiding non-core views and retaining the core live stream content.

[0229] At the code implementation level: The two modes mentioned above reuse the same scene state signal (i.e., the `isSimpleMode` attribute), which uniformly drives the position adjustment operations of all screen-clearing response views. Therefore, in the code example, `isSimpleMode` indicates whether it is in simple mode or screen-clearing mode, and there is no distinction between the two in terms of state management and view response mechanism. From the solution perspective, regardless of whether the trigger source is a screen-clearing gesture or a simple mode switch, it is uniformly identified and driven by the behavior control semantics carried by the hierarchical enumeration value (the last bit modulo 10 equals 5), reflecting the design concept of "one set of mechanisms adapting to multiple scenarios".

[0230] Therefore, in this specific embodiment, both "clear screen mode" and "simple mode" refer to the same type of interface display mode, namely, a mode that hides non-core views and focuses on core content. The scene state signal for this mode is encapsulated as the `isSimpleMode` property, and its change automatically triggers the position adjustment operation of the relevant views. In other words, "clear screen mode" is a scene state that drives the view to hide / show, while `isSimpleMode` is the variable name of this scene state signal in the code implementation; the two are equivalent in actual function. Of course, this solution can also be extended to separate the clear screen mode and simple mode into two independent scene state signals, each driving different view behaviors. This extension is an optional implementation method within the scope of this solution.

[0231] Regarding the target position of the view: If the current screen is cleared, or the live chat panel is open and the number of live chat participants is greater than zero (isOpen && playerCount>0), then the horizontal coordinate of the view is set to the negative maximum screen width (self.left=-maxWidth), causing the view to be moved out of the visible area on the left side of the screen, thus achieving a hidden effect. If neither of the two conditions is met (i.e., neither screen is cleared nor there is a live chat activity), then the horizontal coordinate of the view is set to a preset distance on the left side of the screen (self.left=kAdaptTopW(10)), causing the view to return to its normal display position.

[0232] In this embodiment of the disclosure, the animation duration when entering the clear screen mode (zero seconds) is different from the animation duration when exiting the clear screen mode (0.25 seconds). This differentiated design is based on the following considerations: When entering the clear screen mode, users trigger the clear screen operation through preset gestures or interface controls, expecting an instant response and a quickly displayed clean live stream. If a non-zero animation duration is used, users will perceive a delay, resulting in a less responsive experience. Therefore, the hide animation is zero seconds long, completing instantly to match the intuitive "one-click clear" operation.

[0233] When exiting clear screen mode, the user cancels the clear screen operation, and the hidden views need to be restored. If a zero-second duration were used, all views would flash back at the same instant, resulting in a visually abrupt and jarring effect. Therefore, a smooth 0.25-second transition is used for the restoration animation, allowing the views to slide in from the outside of the screen, providing a soft and natural visual experience.

[0234] In this embodiment, the same view position update function handles the transitions in both directions: entering and exiting the screen clearing process. A shorter animation duration is used for quick hiding when entering the screen clearing process, while a longer animation duration is used for smooth recovery when exiting. The different animation parameters for different directions balance operational responsiveness and visual comfort.

[0235] In this embodiment, the view hiding operation in clear screen mode is performed by translating the view outside the visible area of ​​the screen (self.left=-maxWidth), rather than directly setting the view's hidden attribute (such as self.hidden=YES). First, the view's rendering state is preserved. When the view is translated off-screen, its layer tree, layout information, and current rendering state remain unchanged. When it needs to be restored to its original position, it can be translated back directly without re-triggering the view's creation, layout, and rendering processes. If the hidden attribute method is used, some view frames may trigger additional layout calculations or state resets when switching between hiding and showing, increasing unnecessary performance overhead. Second, the animation effect is smoother and more natural. The animation effect of a view sliding in from outside the screen is more in line with the user's visual expectations than a simple fade-in or instantaneous appearance, especially when handling multiple views restoring to display simultaneously; the translation animation provides a unified and coherent visual experience. Third, conflicts between the hidden attribute and business logic are avoided. Some views may have their visibility controlled by hidden attributes in the business logic (e.g., showing or hiding based on data status). If the screen clearing operation directly modifies this attribute, it may conflict with the business logic, causing the view's business state to fail to be correctly restored during recovery. Using a panning method to independently control the view's screen position avoids interference with the hidden attributes in the business logic.

[0236] In this embodiment, the state of the live chat panel being open and someone is connected (isOpen && playerCount>0) is treated the same as the screen clearing mode, triggering a left-shifting and hiding operation in both cases. In live streaming applications, the live chat panel usually occupies a portion of the screen (e.g., the bottom or side area) when it pops up. If non-core views (such as announcements, chat rooms, function buttons, etc.) remain in their original positions on the screen, they may obscure the live chat screen or the operation area related to live chat, affecting the user's participation in live chat interaction. Therefore, this embodiment treats the live chat panel activity as a scenario state similar to screen clearing, reusing the same set of left-shifting drawing logic to automatically move non-core views marked as screen clearing response views off the screen, ensuring the complete visibility and interactive convenience of the live chat screen. When the live chat ends (panel closed and number of connected users reaches zero), the above views automatically return to their original positions.

[0237] It's important to note that the `transformFrameToLeft` function mentioned above is not called manually by the developer. Instead, it's encapsulated within the observer subscription callback method, and registration is completed inside the view's hierarchy enumeration value setting method (`setViewLevel:`). When the developer sets the hierarchy enumeration value for a view instance, the setting method detects that the last digit of the enumeration value, modulo 10, equals 5 (i.e., it belongs to a clear screen response view), and immediately creates an observer subscription relationship for the scene state signal (`isSimpleMode`) representing the clear screen mode. This subscription callback method encapsulates the call to the `transformFrameToLeft` function. When the value of the clear screen mode state signal changes in any direction due to user operation or system state switching, including switching from non-clear screen mode to clear screen mode, or reverting from clear screen mode to non-clear screen mode, the callback method is automatically triggered and executed, calling the `transformFrameToLeft` function to hide or restore the view. This mechanism allows the developer to register the view's responsiveness to clear screen scenes in the same operation of setting the hierarchy enumeration value. While obtaining the hierarchy marker, the view automatically gains the ability to respond to changes in the scene state. Any subsequent switch to the clear screen mode will automatically trigger the corresponding adjustment of the view position. Developers do not need to write any additional listening code or animation code in the controller or view class, which reflects the low-intrusion design concept of "setting is configuration" in this solution.

[0238] Figure 3 This is a flowchart of another view hierarchy dynamic control method provided in the embodiments of this disclosure. Figure 3 A live streaming process is provided, including the following steps.

[0239] S1: Page initialization.

[0240] S2: Enumeration value configuration: LiveShowType

[0241] -LiveShowType_Normal (Normal Display)

[0242] - LiveShowType_Single (Single live stream display).

[0243] S3: Initialize core properties: - Buried point: mFromPage / mFromPageLocation - Data: mLiveListArray (list of live stream rooms) - Control: doLiveWhenAppear (autoplay switch) - Callback: endLiveBlock (End callback) -Buried points: mLiveDurationLocationPlace (1 = Off / 3 = Toggle).

[0244] S4: Determine if the page will autoplay when it is displayed? (doLiveWhenAppear==YES?) If no, execute S5; if yes, execute S6.

[0245] S5: Wait for active playback: doLiveStartPlay. Then execute S7.

[0246] S6: Execute autoplay: doLiveStartPlayWhenViedDidDisplay. Then execute S7.

[0247] S7: Initialize the chat window: mChatRoomVC.

[0248] S8: The live stream is running normally.

[0249] S9: Determine if an operation type has been triggered?

[0250] S101: If the bottom function bar is hidden, then hide the bottom function bar (commented method: hideBottom:), and then return to S8.

[0251] S102: If closing the document presentation is triggered, then doCloseAllFilePopWindow, and then return to S8.

[0252] S103: If the input box height changes, then doToolBarDidChangeHeight:(CGFloat)height, and then return to S8.

[0253] S104: If the keyboard / bottom menu is logged out, then doEndEditAction and then return to S8.

[0254] S105: If simultaneous application processing is triggered, getAllApplyUsersShowTip:(BOOL)isShowPopView, and then return to S8.

[0255] S106: If the screen clear / show function is triggered, then clearOrShowScreen, and then return to S8.

[0256] S107: If an active return to the live room is triggered, then doExitLiveRoomAction (active return), and then execute S11.

[0257] S108: If an IM exception is triggered / the live stream ends, then doEndLiveRoomWhenLiveFinished (passively rollback), and then execute S11.

[0258] S11: Execution end callback: endLiveBlock.

[0259] S12: Live stream closed (mLiveDurationLocationPlace flag).

[0260] Figure 4 This is a block diagram of a view hierarchy dynamic control device provided in an embodiment of this disclosure. Figure 4 As shown, the apparatus 100 provided in this embodiment includes: a construction unit 110, configured to construct hierarchical enumeration values ​​for various types of views, wherein the size of the hierarchical enumeration values ​​maps the display priority of the views in the vertical direction; wherein the encoding of the hierarchical enumeration values ​​carries behavioral control semantics; a storage unit 120, configured to associate and store target hierarchical enumeration values ​​with target view instances, wherein the hierarchical enumeration values ​​include the target hierarchical enumeration values ​​and the views include target views; an insertion unit 130, configured to, when the target view instance is added to a parent view, insert the target view into a vertical position that conforms to the display priority of the target view based on the hierarchical enumeration values ​​associated with the child views of the parent view; and an adjustment unit 140, configured to, based on the behavioral control semantics carried by the target hierarchical enumeration values, determine that the target view matches a target mode, and then perform a preset display position adjustment operation on the target view to change the display state of the target view on the screen.

[0261] Figure 4 Other aspects of the embodiments can be found in the above embodiments, and will not be repeated here.

[0262] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0263] Optionally, the data involved in the embodiments of this disclosure may be stored in a computer device, or may be stored based on cloud storage technology or blockchain technology, without limitation.

[0264] See Figure 5 , Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this disclosure. Figure 5 As shown, the computer device in this embodiment may include one or more processors 1701, a memory 1702, and an input / output interface 1703. The processor 1701, memory 1702, and input / output interface 1703 are connected via a bus 1704. The memory 1702 stores a computer program, which includes program instructions. The input / output interface 1703 receives and outputs data, such as for data interaction between the host machine and the computer device, or for data interaction between various virtual machines within the host machine. The processor 1701 executes the program instructions stored in the memory 1702. The processor 1701 can execute the steps of the method provided in any embodiment of this disclosure.

[0265] In some feasible implementations, the processor 1701 may be a central processing unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0266] The memory 1702 may include read-only memory and random access memory, and provides instructions and data to the processor 1701 and input / output interface 1703. A portion of the memory 1702 may also include non-volatile random access memory. For example, the memory 1702 may also store device type information.

[0267] In practice, the computer device can execute the implementation methods provided by each step in any of the above method embodiments through its built-in functional modules. For details, please refer to the implementation methods provided by each step in the figure shown in the above method embodiments, which will not be repeated here.

[0268] This disclosure provides a computer device including a processor, an input / output interface, and a memory. The processor retrieves a computer program from the memory and executes the steps of the method shown in any of the above embodiments.

[0269] This disclosure also provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and executed by the view hierarchy dynamic control method provided in each step of any of the above embodiments. Specific implementations of each step in any of the above embodiments can be found therein and will not be repeated here. Furthermore, the beneficial effects of using the same method will not be repeated here either. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this disclosure, please refer to the description of the method embodiments of this disclosure. As an example, the computer program can be deployed to execute on a single computer device, or on multiple computer devices located in one location, or on multiple computer devices distributed across multiple locations and interconnected via a communication network.

[0270] The computer-readable storage medium can be the view-level dynamic control device provided in any of the foregoing embodiments or the internal storage unit of the computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0271] This disclosure also provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various alternative embodiments described above.

[0272] The above-disclosed embodiments are merely preferred embodiments of this disclosure and should not be construed as limiting the scope of this disclosure.

Claims

1. A method for dynamic control of view hierarchy, characterized in that, include: Construct hierarchical enumeration values ​​for various types of views, wherein the size of the hierarchical enumeration value maps the display priority of the view in the vertical direction; wherein the encoding of the hierarchical enumeration value carries behavioral control semantics; The target level enumeration value is associated and stored with the target view instance, wherein the level enumeration value includes the target level enumeration value, and the view includes the target view; When the target view instance is added to the parent view, the target view is inserted into a vertical position that conforms to the display priority of the target view, based on the target level enumeration value and the level enumeration value associated with the child views of the parent view. Based on the behavioral control semantics carried by the target level enumeration value, if it is determined that the target view matches the target pattern, then a preset display position adjustment operation is performed on the target view to change the display state of the target view on the screen.

2. The method as described in claim 1, characterized in that, Based on the behavioral control semantics carried by the target level enumeration value, if it is determined that the target view matches the target pattern, then a preset display position adjustment operation is performed on the target view, including: When the behavior control semantics carried by the target level enumeration value are detected to match the target pattern, an observer subscription for the scene state signal representing the target pattern is created, and the position update callback is encapsulated in the subscription; When the value of the scene state signal changes, the preset display position adjustment operation is achieved by automatically triggering the position update callback.

3. The method as described in claim 2, characterized in that, The behavioral control semantics are carried by a preset number of digits in the hierarchical enumeration value; wherein, determining the target view and target pattern match based on the behavioral control semantics carried by the target hierarchical enumeration value includes: Perform a preset operation on the preset number of the target level enumeration value to obtain the operation result; Based on the calculation results, it is determined that the target view matches the target pattern.

4. The method as described in claim 3, characterized in that, The preset operation includes performing a modulo operation of a first preset value on the preset digits of the target level enumeration value, wherein the preset digits include the last digit of the target level enumeration value.

5. The method as described in claim 3 or 4, characterized in that, The target mode includes a screen clearing mode, and the display position adjustment operation includes adjusting the position of the hidden view or the displayed view. Determining whether the target view matches the target pattern based on the calculation result includes: When the calculation result is equal to the second preset value, it is determined that the target view matches the screen clearing mode.

6. The method as described in claim 2, characterized in that, Also includes: When creating an observer subscription, the target view instance is passed to the location update callback in a first reference manner, and when the location update callback begins execution, the first reference manner is converted to a second reference manner for the target view instance.

7. The method as described in claim 5, characterized in that, When the value of the scene state signal changes, a preset display position adjustment operation is implemented by automatically triggering the position update callback, including: When the scene state signal indicates that the screen is clearing, a translation operation is performed to translate the planar coordinates of the target view instance horizontally to outside the visible area of ​​the screen, so as to hide the target view. When the scene status signal indicates that the screen clearing mode has been exited, a translation operation is performed to translate the planar coordinates of the target view instance back to the visible area of ​​the plane along the horizontal direction, so as to restore the display of the target view.

8. The method as described in claim 7, characterized in that, Performing a translation operation to move the planar coordinates of the target view instance horizontally outside the visible area of ​​the screen includes: The screen clearing animation is executed using the first animation duration parameter, which translates the planar coordinates of the target view instance horizontally to outside the visible area of ​​the screen. The process of performing a translation operation to move the planar coordinates of the target view instance back to the visible area of ​​the plane along the horizontal direction to restore the display of the target view includes: The second animation duration parameter is used to execute the restoration animation, which translates the planar coordinates of the target view instance back to the planar visible area in the horizontal direction to restore the display of the target view; Wherein, the first animation duration parameter is less than the second animation duration parameter.

9. The method as described in claim 7, characterized in that, Also includes: When it is determined that the target view instance belongs to a preset pop-up type and the current screen orientation is landscape, the layout reset operation of the target view instance is triggered before the panning operation.

10. The method as described in claim 2, characterized in that, The scene state signal also represents the display mode state of the application interface, including switching between landscape and portrait modes, or switching between normal mode and clear screen mode; wherein, the method further includes: When the display mode state changes, the observer subscription triggers the position update callback to automatically adapt the view layout to different display modes.

11. The method as described in claim 1, characterized in that, The target mode includes a screen clearing mode; when the target level enumeration value carries behavioral control semantics and determines that the target view matches the screen clearing mode, the display position adjustment operation includes adjusting the layout position of the target view; The operation of performing a preset display position adjustment on the target view includes: Swap the first layout setting method with the second layout setting method of the view base class; After the swap, when the second layout setting method is invoked to set the planar coordinates of the target view, the first layout setting method is actually invoked; Within the first layout setting method, it is determined whether to correct the planar coordinates based on the behavior control semantics carried in the target hierarchy enumeration value associated with the target view and whether the screen is currently cleared. If it is determined that the planar coordinates should be corrected, the corrected planar coordinates of the target view are calculated based on the display rules corresponding to the clear screen mode. The corrected planar coordinates are then applied to the target view by indirectly calling the function name of the first layout setting method, thereby changing the display position of the target view on the screen. If it is determined that the planar coordinates should not be corrected, then the planar coordinates are applied to the target view by indirectly calling the second layout setting method.

12. The method as described in claim 1, characterized in that, Associate the target hierarchy enumeration values ​​with the target view instance, including: By expanding the view base class through classification, view hierarchy attributes and their corresponding setting methods are defined for the view base class. The view hierarchy attributes are used to hold hierarchy enumeration values. In response to the assignment operation of the view hierarchy attribute, the setting method is called to store the passed target hierarchy enumeration value into the target view instance through the runtime association mechanism, so that the target view instance can obtain the display priority and behavior control semantics of the target view instance in the vertical direction through the view hierarchy attribute.

13. The method as described in claim 1, characterized in that, The hierarchical enumeration values ​​increase according to a preset gradient step size, and an insertion interval is reserved between adjacent hierarchical enumeration values.

14. The method as described in claim 1, characterized in that, Also includes: When the target level enumeration value of the target view is dynamically adjusted after the target view has been added to the parent view, or when the vertical level order of each target view is disrupted, the sorting interface is called to rearrange the child views of the parent view according to their respective level enumeration values. Place each subview on top of the parent view in the ordered sequence.

15. The method as described in claim 1, characterized in that, When the target view instance is added to the parent view, based on the target hierarchy enumeration value and the hierarchy enumeration value associated with the child views of the parent view, the target view is inserted into a vertical position that conforms to the display priority of the target view, including: By overriding the view addition method of the parent view, the view addition operation is intercepted when the view addition method is called; Inside the view addition method, the hierarchical enumeration values ​​associated with each of the child views of the parent view are obtained and compared with the target hierarchical enumeration value. Based on the comparison results, the target view is inserted above the subviews in the subview array of the parent view whose level enumeration value is less than the target level enumeration value, and below the subviews whose level enumeration value is greater than the target level enumeration value.

16. The method as described in claim 1, characterized in that, Construct hierarchical enumeration values ​​for various views, including: The hierarchical enumeration values ​​are defined in the category header file of the view base class, and the hierarchical enumeration values ​​corresponding to each type of view are declared in the enumeration type set in the category header file.

17. The method as described in claim 1, characterized in that, The view includes a system view; the system view has a first functional area and a second functional area; the second functional area is assigned a corresponding hierarchical enumeration value, and the assigned hierarchical enumeration value is associated and stored in the corresponding system view instance.

18. The method as described in claim 1, characterized in that, The target mode includes a keyboard pop-up mode; Perform a preset display position adjustment operation on the target view, including: When the system keyboard pops up, iterate through each view instance that has been associated with and stored hierarchical enumeration values, and identify the set of views that must be avoided in the keyboard pop-up mode. Based on the recognition results, a temporary overlay view is created for the keyboard pop-up mode. The temporary overlay view is assigned a corresponding level enumeration value and included in the automatic sorting. When the temporary overlay view receives a click event, it determines whether to pass through the click event based on the layer enumeration value of the view below the clicked position; If the layer enumeration value of the view below the clicked location is higher than the layer enumeration value of the temporary overlay view, the click event will be passed through to the view below the clicked location for processing. If the layer enumeration value of the view below the clicked location does not exceed the layer enumeration value of the temporary overlay view, then the temporary overlay view intercepts and responds to the click event to hide the system keyboard. When the system keyboard is retracted, the hierarchy enumeration values ​​of each view instance are traversed, and temporary views created in the keyboard pop-up mode are removed in batches, restoring the view hierarchy state to that before the keyboard pop-up.

19. A view hierarchy dynamic control device, characterized in that, include: A construction unit is used to construct hierarchical enumeration values ​​for various types of views. The size of the hierarchical enumeration value maps the display priority of the view in the vertical direction. The encoding of the hierarchical enumeration value carries behavioral control semantics. A storage unit is used to associate and store target level enumeration values ​​with a target view instance, wherein the level enumeration values ​​include the target level enumeration values ​​and the view includes the target view; An insertion unit is used to insert the target view into a vertical position that conforms to the display priority of the target view when the target view instance is added to the parent view, based on the target level enumeration value and the level enumeration value associated with the child views of the parent view. The adjustment unit is used to determine whether the target view matches the target pattern based on the behavior control semantics carried by the target level enumeration value, and then perform a preset display position adjustment operation on the target view to change the display state of the target view on the screen.

20. A computer device, characterized in that, Includes processor, memory, and input / output interfaces; The processor is connected to the memory and the input / output interface respectively, wherein the input / output interface is used to receive data and output data, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the method according to any one of claims 1-18.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-18.

22. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1-18.

Images