Response view determination method and device of application program, equipment and storage medium

Abstract

The embodiment of the invention provides a response view determination method and device of an application program, equipment and a storage medium, and the method comprises the steps: obtaining a current touch position in an application interface, and determining a response view of the application program based on preset attribute information of each interaction view in the application interface, a corresponding logic view hierarchical relationship and the current touch position; determining a target view response chain; generating view indication information according to the current calling states respectively corresponding to the plurality of preset system callback events; and determining a response view corresponding to the current touch position according to the view indication information and the target view response chain. According to the scheme, the natural view hierarchical relation conforming to the use habits of the user can be followed, it is guaranteed that the transmission direction of the touch event is consistent with the user expectation, it is guaranteed that the touch event is transmitted to the correct interaction view for response, and the use experience of the user is guaranteed.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for determining the response view of an application. Background Technology

[0002] With the rapid development of internet and smart terminal technologies, applications have become ubiquitous in diverse scenarios such as lifestyle services, business operations, entertainment, and smart hardware control, serving as the core carrier connecting users with digital services. The interactive view of an application can be a core user interface component responsible for information visualization and user interaction, or it can be the carrier for direct visual contact and behavioral interaction between the user and the application. For example, it can respond to touch events triggered by the user, such as clicks, swipes, zooms, and long presses, and execute corresponding feedback logic.

[0003] In related technologies, when a user triggers a touch event, the application (such as an iOS application) selects the corresponding interactive view to respond according to the set logical view hierarchy. However, as applications become more complex, interactive views begin to adopt diverse styles such as transparent or partially transparent. The interactive view selected based on the aforementioned logical view hierarchy may not be consistent with the user's expected direction of touch event transmission. This results in the touch event failing to be transmitted to the correct interactive view for response, deviating from the user's interaction expectations, reducing interaction quality, and affecting the user experience. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for determining the response view of an application. It can effectively construct a target view response chain and, by combining the current invocation state of a preset system callback event with the target view response chain, determine the response view corresponding to the current touch position. This method follows a natural view hierarchy that aligns with user habits, ensuring that the direction of touch event transmission is consistent with user expectations and that touch events are delivered to the correct interactive view for response. This guarantees a superior user experience and effectively solves the problem in existing technologies where touch events cannot be delivered to the correct interactive view during user-terminal device interaction, leading to deviations from user interaction expectations, decreased interaction quality, and negatively impacting the user experience.

[0005] In a first aspect, embodiments of this application provide a method for determining the response view of an application, the method comprising: Obtain the current touch position in the application interface, and determine the target view response chain based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position; View indication information is generated based on the current call status corresponding to several preset system callback events; Based on the view indication information and the target view response chain, determine the response view corresponding to the current touch position.

[0006] Secondly, embodiments of this application also provide a response view determination device for an application, comprising: The acquisition module is configured to acquire the current touch position in the application interface; The response chain determination module is configured to determine the target view response chain based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position. The indicator information determination module is configured to generate view indicator information based on the current call status corresponding to several preset system callback events. The response view determination module is configured to determine the response view corresponding to the current touch position based on the view indication information and the target view response chain.

[0007] Thirdly, embodiments of this application also provide a response view determination device for an application, the device comprising: One or more processors; Storage device, configured to store one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the application response view determination method described in the embodiments of this application.

[0008] Fourthly, embodiments of this application also provide a non-volatile storage medium for storing computer-executable instructions, which, when executed by a computer processor, are configured to execute the response view determination method of the application described in embodiments of this application.

[0009] Fifthly, embodiments of this application also provide a computer program product comprising a computer program stored in a computer-readable storage medium, wherein at least one processor of the device reads from the computer-readable storage medium and executes the computer program, causing the device to perform the response view determination method of the application described in embodiments of this application.

[0010] In this embodiment, a target view response chain is determined based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position. This logical view hierarchy provides the original hierarchical relationship between interactive views, while the preset attribute information and the current touch position help determine whether view pass-through is involved, thus reasonably constructing a target view response chain that conforms to the natural view hierarchy, providing an ordered set of candidate views for subsequently determining the final response view. View indication information is generated based on the current call status corresponding to several preset system callback events, effectively monitoring the actual call status of system callback events and assisting in indicating the interactive views that need to be traversed and determined in the target view response chain. Based on the view indication information and the target view response chain, the response view corresponding to the current touch position is determined. Interactive view traversal can be performed on the target view response chain that conforms to the natural view hierarchy, and the view indication information can be used for auxiliary judgment to accurately locate the response view that meets the user's interaction expectations, improving interaction quality. The above solution follows the natural view hierarchy that conforms to user habits, ensures that the direction of touch event transmission is consistent with user expectations, ensures that touch events are transmitted to the correct interactive view for response, and guarantees the user experience. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of an application interface and its logical view hierarchy. Figure 2 This is a schematic diagram of another application interface and its logical view hierarchy. Figure 3 A flowchart of a method for determining the response view of an application provided in an embodiment of this application; Figure 4 A flowchart illustrating a process for determining a target view response chain is provided in this application embodiment; Figure 5 A schematic diagram illustrating the extraction of the original view response chain corresponding to the current touch position from the logical view hierarchy, provided for embodiments of this application. Figure 6 A flowchart illustrating the process of adjusting an original view response chain to obtain a target view response chain, provided in an embodiment of this application; Figure 7 A schematic diagram illustrating the adjustment of the original view response chain to obtain the target view response chain, provided for embodiments of this application; Figure 8 A flowchart illustrating the process of determining the response view corresponding to the current touch position, as provided in this application embodiment; Figure 9 A schematic diagram illustrating the response determination method provided in the embodiments of this application for response judgment; Figure 10 A structural block diagram of an application response view determination device provided in this application embodiment; Figure 11 This is a schematic diagram of the structure of a device for determining the response view of an application provided in an embodiment of this application. Detailed Implementation

[0012] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the scope of the embodiments. Furthermore, it should be noted that, for ease of description, only the parts relevant to the embodiments of this application are shown in the accompanying drawings, not the entire structure.

[0013] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. The term "several" means one or more, and multiple means two or more. Furthermore, "and / or" in the specification and claims indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0014] The application response view determination method provided in this embodiment can effectively construct a target view response chain and, by combining the current invocation state of a preset system callback event with the target view response chain, accurately determine the response view corresponding to the current touch position. This application response view determination method can be specifically applied to applications in various application scenarios such as live video streaming, video conferencing, and instant messaging. The aforementioned application scenarios are merely exemplary and illustrative; in practical applications, the application response view determination method can also be used in other scenarios, which this embodiment does not limit.

[0015] The method for determining the response view of an application provided in this application embodiment can be executed by a computer device. The computer device refers to any electronic device with data computing, processing and storage capabilities, such as mobile phones, PCs (Personal Computers), tablet computers and other terminal devices. The application can be an iOS application. This application embodiment does not limit this.

[0016] The following describes the related technical background of the embodiments of this application, using an iOS application as an example: 1. View hierarchy: A: Logical view hierarchy (tree): In iOS applications, each interactive view has a list of child interactive views, thus all interactive views can form a tree-like logical relationship. Figure 1 This is a schematic diagram of an application interface and its logical view hierarchy, such as... Figure 1 As shown, the application interface contains interactive views A, B, C, D, E, and F. Interactive views E and F are sub-interactive views of interactive view C, interactive view D is a sub-interactive view of interactive view B, and interactive views B and C are sub-interactive views of interactive view A. It should be noted that the logical view hierarchy does not differentiate the hierarchical order of sub-interactive views within the same interactive view based on their overlapping relationships.

[0017] B: Natural View Hierarchy (Chain): Sub-interactive views within the same interactive view also have a hierarchical structure. For any two interactive views, it can be determined which is the upper level and which is the lower level. Based on this relationship, all interactive views can be hierarchically ordered to form a chain-like structure. (Reference) Figure 1 The provided interactive views have a natural view hierarchy from bottom to top as follows: A→B→D→C→E→F, for example, Figure 1 Interactive view C obscures interactive view B; therefore, interactive view C has a higher hierarchy than interactive view B in the natural view hierarchy.

[0018] 2. iOS Touch Event Mechanism: On iOS, touch events are primarily related to the following concepts: UITouch: Touch behavior. Each time a finger taps the screen, a UITouch object is generated, recording information such as the touch position. UIEvent: Touch event. A touch event is defined as the period from the first finger touching the screen to the last finger leaving the screen. A UIEvent may consist of multiple UITouch objects, meaning a single touch event may be composed of multiple touch actions.

[0019] UIResponder: The responder. A UIResponder can receive and process touch events. The most common UIResponder is UIView (interactive view). UIGestureRecognizer: A gesture recognizer. A gesture recognizer is a system-defined tool specifically designed to recognize specific gestures, such as taps and drags. A gesture recognizer needs to be bound to a UIView.

[0020] 3. Hittest chain: When handling touch events in iOS, the system first identifies the best-responding view (hitTestView) based on the relationship between the touch point and logical views. This process proceeds top-down. For each interactive view, it first checks whether the touch point is above any of its child interactive views, from highest to lowest hierarchy. If it is, the result of the child interactive view's check is returned. If the touch point is not on any child interactive view, but is on the current interactive view, the current interactive view is returned. Figure 1 For example, suppose the touch point is located at point E. Starting from interactive view A, we find the touch point is located in interactive view C. Then we continue checking the child interactive views of interactive view C, finding the touch point is not in interactive view F, and then in interactive view E. Since interactive view E is already a leaf node and has no child views, interactive view E can be considered the optimal response view to be found. Its corresponding view search chain A→C→E can be considered the Hittest chain.

[0021] 4. Responder chain: Each UIResponder has a `nextResponder` property. When it's not responding to touch events, you can delegate the touch event to its `nextResponder`. For interactive views, its default `nextResponder` is its parent view. Starting from `hitTestView`, tracing the `nextResponder` relationship from bottom to top yields the Responder chain. Figure 1 For example, assuming the touch point is located at E, its Hittest chain is A→C→E, then its Responder chain is E→C→A.

[0022] 5. How iOS handles touch events: a. First, find hitTestView through the Hittest chain; b. Collect the gesture recognizers bound to the interactive views on the Hittest chain; c. First, pass the touch event to these gesture recognizers for response, and then pass the touch event to the Responder chain for response; d. By default, if a gesture recognizer successfully identifies a gesture, it will prevent other gesture recognizers with lower priority from responding and will also cancel touch event responses in the Responder chain. In other words, the gesture recognizer's response has higher priority than the touch event.

[0023] e. If the gesture recognizer fails to recognize the touch event, the event will ultimately be handled by the Responder chain. Since receiving event responses via the Responder chain is rather primitive, in practice, the gesture recognizer is generally used for recognition.

[0024] As application development becomes more professional and complex, transparent and partially transparent interactive views will be used more frequently. Existing mechanisms may experience response issues. The following addresses this by... Figure 1 Please provide a detailed explanation. Figure 2 This is a schematic diagram of another application interface and its logical view hierarchy.

[0025] like Figure 2As shown, the specific visual interactive views in this application interface include a first toolbar 201, a second toolbar 202, an information bar 203, an information bar button 204, and a progress bar 205. Since the application interface requires that dragging the progress bar 205 hides the first toolbar 201, the second toolbar 202, and the information bar 203, a unified transparent "tool information view" can be used as the parent view for managing all toolbars and the information bar 203. The progress bar 205 itself cannot be hidden while being dragged, so it exists independently of this tool information view. To ensure a good user experience, the progress bar 205 can be a touch area with a certain height, which is nearly transparent, thus revealing the information bar button 204 above the information bar 203. Correspondingly, according to the original program logic, the existing logical view hierarchy 206 of the application interface can be obtained, where the existing logical view hierarchy 206 also shows the root view. For example, the current interaction requirement is: when a drag operation is performed within the touch area corresponding to the progress bar 205, the progress bar 205 should respond; when a click operation is performed within the same touch area, the information bar button 204 should respond. According to the aforementioned logical view hierarchy, since the progress bar 205 and the aforementioned tool information view 204 are at parallel levels (belonging to different branches of the logical view hierarchy (tree)), the progress bar 205 and the information bar button 204 are not related in the logical view hierarchy. The click operation received by the touch area corresponding to the progress bar 205 cannot be passed to the information bar button 204 for a response; it can only be passed to the root view. Furthermore, it cannot simultaneously capture the gesture recognizers bound to them, resulting in a response failure. From the user's actual needs, if the touch event is not responded to by the nearly transparent progress bar 205, it should continue to be responded to by the information bar button 204, which is visually located below the progress bar 205, i.e., the natural view hierarchy. The iOS system's mechanism for finding `hitTestView` and collecting related gesture recognizers actually follows the logical view hierarchy of interactive views, which is inherently contradictory. Related technologies offer some methods to address this issue, such as creating a new interactive view that simultaneously receives click and drag events, and then distributing these events to the progress bar 205 and the information bar button 204 respectively. However, this approach leads to forced coupling of different business logics. The progress bar 205 and the information bar button 204 each correspond to independent business logic, and their respective interactive views handle their own touch events. This forced coupling reduces the maintainability of the application. Therefore, this application provides a new mechanism that transmits touch events according to the natural view hierarchy, ensuring that touch events are correctly responded to by the views while maintaining the independence of business logic.

[0026] Figure 3A flowchart of a method for determining the response view of an application provided in an embodiment of this application is shown below. Figure 3 As shown, the method for determining the response view of this application specifically includes the following steps: Step S301: Obtain the current touch position in the application interface, and determine the target view response chain based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position.

[0027] The application interface can be the visual interface presented to the user by the currently running application, containing a collection of interactive or non-interactive elements such as text, buttons, and images. The current touch position can be the specific coordinate position in the screen coordinate system when the user interacts with the screen using a finger, stylus, etc. The interactive view can be a visual component in the application interface that supports user operations (such as clicking, swiping, and long-pressing), such as buttons, input boxes, and list items. The preset attribute information of the interactive view can be pre-configured parameters describing its inherent attributes, such as area range, size, and pass-through state. It should be noted that the area range can be the spatial range occupied by the interactive view in the screen coordinate system, the size can be the width and height of the interactive view, and the pass-through state can be an attribute that allows touch events to be passed through to lower-level views, including "on" and "off" states. It should be noted that the lower-level view here refers to the interactive view visually located below the interactive view. The logical view hierarchy can be the hierarchical relationship between various views that conforms to the original program logic of the system. However, directly determining the view response chain based on the logical view hierarchy can lead to the selected interactive view being inconsistent with the user's expected touch event transmission direction, causing the touch event to fail to be transmitted to the correct interactive view for response. For details, please refer to the aforementioned background description. Therefore, this embodiment selects the preset attribute information of each interactive view, the original logical view hierarchy, and the current touch position as key information. It accurately filters and sorts all interactive views in the application interface according to response priority, ultimately forming a candidate view sequence that may respond to touch events. Specifically, it can first use the logical view hierarchy as a basic framework, combined with the matching between the current touch position and the interactive view, to initially identify interactive views that meet the position association conditions and form an initial candidate sequence. Then, using the preset attribute information of the interactive views as the filtering and sorting criteria, and combining the current touch position, it further verifies the effectiveness of view matching and optimizes the sequence priority, ultimately obtaining the accurate target view response chain.

[0028] Figure 4 A flowchart illustrating a process for determining a target view response chain is provided in this application embodiment, as follows: Figure 4As shown, the specific implementation process for determining the target view response chain based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position includes the following steps: Step S401: Extract the original view response chain corresponding to the current touch position from the logical view hierarchy.

[0029] The logical view hierarchy can be a hierarchical relationship between views that conforms to the original program logic of the system. Specifically, it is based on application functional logic to divide the view hierarchy, which differs from the view stacking order perceived by the user. Therefore, the original view response chain corresponding to the current touch position can be extracted from this logical view hierarchy. This original view response chain can serve as a preliminary selection of interactive view sequences that are qualified to respond. These sequences are arranged from low to high logical priority, but dynamic attributes such as the pass-through state of the interactive views are not considered. Specifically, the implementation process for extracting the original view response chain corresponding to the current touch position from the logical view hierarchy is as follows: The logical view hierarchy is traversed level by level from low to high to identify several target interactive views associated with the current touch position; these target interactive views are then integrated in sequence to obtain the original view response chain.

[0030] The logical view hierarchy provides a tree-like logical relationship for all interactive views. Specifically, it can include multiple view levels from low to high, with each view level containing multiple parallel interactive views. The logical view hierarchy is traversed level by level from low to high. Specifically, it starts with the lowest-level interactive view in the logical view hierarchy, determining if the current touch position is within that view. If so, it continues to check if the interactive views at the next higher level cover the current touch position; otherwise, it checks other interactive views at the same level, until all levels in the logical view hierarchy have been traversed to obtain several target interactive views associated with the current touch position. These target interactive views are then integrated sequentially from low to high according to their logical view hierarchy to obtain the original view response chain, i.e., the Hittest chain. Target interactive views can be understood as views located on the Hittest chain. The following section combines... Figure 5 An exemplary description of how to determine the original view response chain is provided.

[0031] Figure 5 This is a schematic diagram illustrating the extraction of the original view response chain corresponding to the current touch position from the logical view hierarchy, as provided in an embodiment of this application. Figure 5As shown, the application interface contains six interactive views: Interactive View R, Interactive View A, Interactive View B, Interactive View C, Interactive View D, and Interactive View E. Interactive Views R, A, and D are not perspective views; they are drawn using color fills. Interactive Views B, C, and E are perspective views; they are drawn using wireframes. Figure 5 The current touch position 501 is shown in white. Additionally, Figure 5 A logical view hierarchy relationship 502 is also provided. According to this relationship, interactive view R has the highest hierarchy. Interactive views A, B, and C are different branches of the same hierarchy (tree), forming three branches of interactive view R. Interactive views D and E are also different branches of the same hierarchy (tree), forming two branches of interactive view C. Following the original program logic, since interactive view R is the root view, the current touch position must fall within it. Therefore, interactive view R can be considered one of the target interactive views. The next view level is then used to determine whether the current touch position falls within interactive view C, B, or A. It should be noted that, according to the system's underlying program logic, this view level confirms each branch sequentially in reverse order of view creation during design (i.e., "interactive view C - interactive view B - interactive view A"). Based on the layout of the interactive views in the application interface, the current touch position falls within interactive view C. Therefore, interactive view C can be identified as one of the target interactive views, without needing to traverse other interactive views at the same level. Next, it is determined whether the current touch position falls within interactive view D or interactive view E in the next view level. It should be noted that, according to the underlying program logic of the system, this view level is confirmed sequentially in the order of "interactive view E - interactive view D". Based on the layout of the interactive views in the application interface, the current touch position falls within interactive view E. Therefore, interactive view E can be identified as one of the target interactive views, and according to the underlying program logic of the system, it is not necessary to traverse other interactive views at the same level (i.e., other branches). Thus, the selected target interactive views are interactive view R, interactive view C, and interactive view E. Interactive views R, interactive view C, and interactive view E are integrated sequentially from low to high according to their logical view hierarchy to obtain the original view response chain 503, namely "R→C→E". However, since the original view response chain does not consider the pass-through state of the interactive view, the interactive views that perform response judgments in sequence may not be consistent with the direction of touch event transmission expected by the user. Adjustments to subsequent steps are required to obtain the final target view response chain.

[0032] Reference Figure 4In conjunction with the foregoing, it also includes: Step S402: Adjust the original view response chain to obtain the target view response chain based on the pass-through status, area range and current touch position of each interactive view in the application interface.

[0033] The pass-through state controls whether an interactive view allows touch events to be passed through it to lower-level views. This includes "on" and "off" states. If the pass-through state is "on," the interactive view can pass touch events to interactive views located below it. It's important to note that this "lower" position refers to the view visually positioned below the interactive view. If the pass-through state is "off," the interactive view cannot pass touch events to interactive views located below it. The area range refers to the spatial extent of the interactive view in the screen coordinate system, used to determine whether the current touch position falls within the interactive view. Therefore, the original view response chain can be traversed to locate the interactive view with the pass-through state set to "on". Then, based on the logical view hierarchy and the current touch position, it is determined whether the current touch position is located at the same level (i.e., different branch) of the interactive view with the pass-through state set to "on" (views that are adjacent according to the reverse order of view creation during view design). Then, based on the aforementioned determination results, the pass-through state of the adjacent views, and the attribute information of other related views (e.g., the aforementioned sibling adjacent views and their subviews), it is determined whether there are view nodes that need to be supplemented in the original view response chain. Finally, based on the view nodes that need to be supplemented, the view nodes of the original view response chain are updated to obtain the target view response chain, thereby ensuring that the response priority of the target view response chain is consistent with the user's actual interaction needs.

[0034] Figure 6 This is a flowchart illustrating a process for adjusting an original view response chain to obtain a target view response chain, as provided in an embodiment of this application. Figure 6 As shown, the specific implementation process of adjusting the original view response chain to obtain the target view response chain based on the pass-through status, area range, and current touch position of each interactive view in the application interface includes the following steps: Step S601: If there is a first interactive view with a pass-through state enabled in the original view response chain, determine a second interactive view that is at the same view level and sequentially adjacent to the first interactive view.

[0035] The first interactive view is in an "on" state, which allows touch events to pass through other interactive views in its lower layer. Since each level of the logical view hierarchy in the original view response chain only determines one interactive view, ignoring other interactive views at the same level that have an overlapping relationship in their actual view positions, a second interactive view that is located at the same view level (i.e., a different branch) and is sequentially adjacent (based on the reverse order of view creation during view design, they are adjacent views) can be identified first. This second interactive view can be considered a potential candidate view that may be added to the original view response chain.

[0036] Step S602: If the current touch position is within the area of ​​the second interactive view, determine the supplementary node information based on the pass-through status of the second interactive view and the associated view information.

[0037] If the current touch position is within the area of ​​the second interactive view, it can be considered that the current touch position falls within both the first and second interactive views, and the touch event needs to be synchronously transmitted to the second interactive view. In one embodiment, if the pass-through state of the second interactive view is "off", then the second interactive view is directly determined as the pass-through parent node of the first interactive view, so that if the first interactive view cannot respond to the touch event, the second interactive view can then make the response judgment. In one embodiment, if the pass-through state of the second interactive view is "on", then in addition to determining the second interactive view as the pass-through parent node of the first interactive view, the related view information of the second interactive view is further referenced, such as the attribute information of views at the same level (i.e., different branches) and their subviews, and the aforementioned process is followed to determine whether there is a parent node that needs to be added to the second interactive view. Finally, the interactive views that need to be added based on the first interactive view, and their node relationships with the first interactive view, are determined as supplementary node information.

[0038] Step S603: Update the view nodes of the original view response chain based on the supplementary node information to obtain the target view response chain.

[0039] The supplementary node information can include the associated view nodes that need to be completed for each interactive view in the original view response chain whose pass-through state is "on". For example, if the second interactive view and the first interactive view are located at the same view level and are adjacent in sequence, and the current touch position is within the area of ​​the second interactive view, then the second interactive view can be added to the original view response chain as the pass-through parent node of the first interactive view. This achieves the purpose of updating view nodes, corrects the deviation of the original view response chain, and adapts to the flexible adjustment of the view response chain in scenarios where views at the same level overlap and pass-through enabled views exist, ensuring the rationality of the interaction.

[0040] The following combination Figure 7 An exemplary description of how to determine the target view response chain is provided. Figure 7 This is a schematic diagram illustrating the process of adjusting the original view response chain to obtain the target view response chain, as provided in an embodiment of this application.

[0041] like Figure 7 As shown, in Figure 4 Based on this, the application interface can be organized according to its logical view hierarchy to obtain the original view response chain 403, namely "R→C→E", where the original parent node of interactive view E is interactive view C, and the original parent node of interactive view C is interactive view R. However, since this original view response chain does not consider the pass-through state of interactive views, the interactive views that are sequentially judged for response may not be consistent with the user's expected direction of touch event transmission. Adjustments are needed in subsequent steps to obtain the final target view response chain. It should be noted that interactive views B, C, and E are pass-through views, and their pass-through state is "on". Therefore, according to this original view response chain 403, we can start with interactive view E. Since the pass-through state of interactive view E is "on", we can check interactive view D, which is at the same view hierarchy as interactive view E and is sequentially adjacent to it. Since the current touch position is not within the area of ​​interactive view D, it can be considered a view node unrelated to interactive view E. Therefore, no view node supplementation is needed between interactive view E and interactive view C. Next, we move on to interactive view C. Since interactive view C's pass-through state is "on," we can check interactive view B, which is at the same view level (i.e., a different branch) and sequentially adjacent (adjacent views according to the reverse order of view creation during view design). Because the current touch position is within the area of ​​interactive view B, and interactive view B has no subviews, we can determine interactive view B as the pass-through parent node of interactive view C. Then, since interactive view B's pass-through state is "on," we need to continue checking interactive view A, which is at the same view level and sequentially adjacent. Because the current touch position is within the area of ​​interactive view A, and interactive view A has no subviews, we can determine interactive view A as the pass-through parent node of interactive view B. Finally, we move on to interactive view R. Since interactive view R is the root view, we can determine that the process ends. At this point, we can obtain supplementary node information including "interactive view B is the pass-through parent node of interactive view C" and "interactive view A is the pass-through parent node of interactive view B." Then, based on the supplementary node information, the original view response chain 403 is updated to obtain the target view response chain 701, namely "R→A→B→C→E".

[0042] Reference Figure 3 In conjunction with the foregoing, it also includes: Step S302: Generate view indication information based on the current call status corresponding to several preset system callback events.

[0043] System callback events can be predefined by the operating system and are standardized events used to handle UI (User Interface) events. They are automatically triggered by the system at specific interaction stages, and their core function is to transmit event information and coordinate the response logic of view components. The preceding steps have achieved the acquisition of the target view response chain according to the natural view hierarchy, but the transparent parent node in the target view response chain cannot be used directly; the specific timing of its use needs to be determined. Therefore, this embodiment chooses to monitor the state of preset system callback events. These preset system callback events are associated with whether the transparent view needs to transmit touch events, and can help determine the view transmission direction of touch events. By combining the current call states corresponding to several preset system callback events according to the requirements, view indication information can be determined for the subsequent response view determination process.

[0044] For example, the following are some preset system callback events associated with transparent views: 1. [UITouchesEvent_addTouch:forDelayedDelivery], which is a callback event during the touch event handling phase. It is triggered after the view response chain is determined, automatically collecting gesture recognizers from the view response chain and associating them with the current touch event to prepare for subsequent gesture recognition and event response in the response view. Therefore, this callback event is in the process of being invoked, and it needs to consider whether the transparent view allows touch events to pass through to the lower-level view to ensure the accuracy of subsequent responses; 2. [UIRemoteKeyboards] [peekApplicationEvent:] is a callback event for keyboard interaction and application event coordination. It is used by the system keyboard to determine whether to respond to events generated within the current application. The impact of transparent views such as transparent pop-ups and transparent input boxes needs to be considered to ensure accurate linkage between the keyboard and application events. [UIWindowsendEvent:] is a callback event during the event dispatch phase. It is used to dispatch trigger events to the interactive window, supports event object reuse, and actively notifies gesture recognizers to respond when touch behavior states change. It needs to determine the order in which gesture recognizers receive touch events and the response priority. For example, gesture recognition in a child view may prevent gesture recognition in the parent view. Therefore, it is necessary to consider allowing touch events to pass through to lower-level views in transparent views to ensure accurate event dispatch. Of course, other preset callback events associated with transparent views can be set according to the processing logic of the actual application scenario, which are not limited here. The current calling state can indicate the current execution status of the preset system callback event, including "calling" and "call completed," to indicate whether the system has called the relevant callback method. The view indication information can be obtained by integrating the call status of several preset system callback events, and is used to indicate whether the relevant method calls of these preset system callback events have been triggered.

[0045] In one embodiment, the specific implementation process for generating view indication information based on the current call states corresponding to several preset system callback events may be as follows: determine the status flag information for the current call state corresponding to each preset system callback event, and combine the obtained status flag information to obtain view indication information. In another embodiment, the specific implementation process for generating view indication information based on the current call states corresponding to several preset system callback events may be as follows: determine the status flag information based on the current call state corresponding to each preset system callback event; and integrate the status flag information corresponding to multiple preset system callback events to obtain view indication information. The status flag information may be a standardized identifier used to represent the current call state of a single preset system callback event, and its specific form may be a number, string, or enumeration value, etc. For example, the status flag information may be a set flag bit; if the preset system callback event is detected as being in "calling", the value of the flag bit may be set to "1", and if the preset system callback event is detected as being in "call completed", the value of the flag bit may be set to "0". After determining the flag values ​​corresponding to each preset system callback event, the values ​​of each flag can be ORed to obtain the result value. This result value can be regarded as view indication information, used to indicate whether there is an event that is "being called" among these preset system callback events. For example, for the system callback event [UITouchesEvent_addTouch:forDelayedDelivery], the flag isAddingTouch can be set accordingly; for the system callback event [UIRemoteKeyboards peekApplicationEvent:], the flag isRemoteKeyboardPeeking can be set accordingly; and for the system callback event [UIWindow sendEvent:], the flag isSendingTouchEvent can be set accordingly. The view indication information can be the flag shouldReplaceSuperView. The specific integrated calculation is as follows: shouldReplaceSuperView = isAddingTouch || isRemoteKeyboardPeeking || isSendingTouchEvent.

[0046] Therefore, by integrating the status flag information corresponding to multiple preset system callback events, the scattered individual event status flags can be integrated into globally referable view indication information, providing a dynamic verification basis for subsequently determining the response view.

[0047] Step S303: Determine the response view corresponding to the current touch position based on the view indication information and the target view response chain.

[0048] The target view response chain provides a view response path that conforms to the user's actual visual habits, rather than being determined by the system's original logical view hierarchy. Based on this target view response chain, it can provide information on the pass-through relationships between interactive views, their own attribute information, and, combined with view indication information, can determine whether each interactive view in the target view response chain, starting from the first interactive view (the highest-level interactive view), can be used as a response view through the bound gesture recognizer, until the response view corresponding to the current touch position is determined, so as to respond to the touch event and execute the corresponding interaction logic.

[0049] Figure 8 This is a flowchart illustrating a process for determining the response view corresponding to the current touch position, as provided in an embodiment of this application. Figure 8 As shown, the specific implementation process of determining the response view corresponding to the current touch position based on the view indication information and the target view response chain includes the following steps: Step S801: Determine the candidate interactive view currently being processed from the target view response chain, and determine the preset gesture information corresponding to the candidate interactive view.

[0050] The target view response chain provides multiple candidate interactive views eligible to respond. Therefore, candidate interactive views can be retrieved from the target view response chain in descending order of hierarchy for processing to determine whether they can respond to the touch event corresponding to the current touch position. Specifically, the preset gesture information corresponding to the candidate interactive view can be the gesture recognizer bound to that candidate interactive view. This gesture recognizer can autonomously determine whether to respond to the touch event to determine whether the candidate interactive view is the final response view. This gesture recognizer can be pre-bound to the candidate interactive view and has gesture recognition rules set, including supported gesture types (e.g., click, swipe, long press), gesture triggering conditions, etc.

[0051] Step S802: If the touch event corresponding to the current touch position does not match the preset gesture information, extract the associated field information corresponding to the candidate interactive view from the target view response chain.

[0052] If the touch event corresponding to the current touch position does not match the preset gesture information, meaning the gesture recognizer cannot respond to the touch event, it can be considered that the candidate interactive view is not the response view corresponding to the current touch position. Therefore, it is necessary to determine the response view from other interactive views in the target view response chain. Since the target view response chain is adjusted based on the pass-through characteristics of the interactive view, and the pass-through state of the candidate interactive view may be "on" or "off", it is necessary to combine the associated field information recorded for each candidate interactive view in the target view response chain to determine whether the next candidate interactive view participating in the judgment is the original parent view or the pass-through parent view of the currently processed interactive view. The associated field information may include the pass-through state field, the pass-through parent node field, and the touch behavior field of the candidate interactive view. The pass-through state field can be used to record whether the pass-through state of the candidate interactive view is "on" or "off". The pass-through parent node field can be used to record whether the candidate interactive view has a pass-through parent view. The touch behavior field can be used to record whether the candidate interactive view has a touch behavior event, so as to verify whether the candidate interactive view still needs to perform the pass-through of the touch event.

[0053] Optionally, after determining the preset gesture information corresponding to the candidate interactive view, the method further includes: If the touch event corresponding to the current touch position matches the preset gesture information, the candidate interactive view is determined as the response view corresponding to the current touch position, and the touch event is responded to based on the preset gesture information.

[0054] If the touch event corresponding to the current touch position matches the preset gesture information, it can be considered that its gesture recognizer can respond to the touch event. Therefore, the candidate interaction view is the response view corresponding to the current touch position, and the preset response logic can continue to be executed to respond to the touch event in order to fulfill the user's interaction needs.

[0055] Step S803: If the associated field information meets the preset transparent value retrieval conditions and the view indication information meets the preset transparent transmission conditions, determine the response view corresponding to the current touch position based on the perspective parent view of the candidate interactive view.

[0056] Among them, the associated field information meets the preset passthrough value conditions. This can be: the current value of the passthrough status field indicates that the passthrough status of the candidate interactive view is "on"; the current value of the passthrough parent node field indicates that a passthrough parent view of the candidate interactive view has been recorded; and the current value of the touch behavior field indicates that a touch behavior event of the candidate interactive view has been recorded. For example, the passthrough status field is `passThoughMode`, where a value of "true" indicates that passthrough is on, and a value of "false" indicates that passthrough is off. The passthrough parent node field is `passThoughSuperview`, where a non-empty value indicates that a passthrough parent view exists. The touch behavior field is `passThoughTouch`, where a non-empty value indicates that the touch event can be responded to. The view indication information meets the preset passthrough transmission conditions. This can be: the current value of the view indication information or the character content indicating that a preset system callback event is in the "calling" event state. For example, the view indicator information is the flag `shouldReplaceSuperView`. If `shouldReplaceSuperView` is "1", it means the relevant callback event has been triggered; if `shouldReplaceSuperView` is "0", it means the relevant callback event has not been triggered. Therefore, if the associated field information meets the preset passthrough value condition, and the view indicator information meets the preset passthrough transmission condition, it can be considered that the candidate interactive view needs to perform touch event passthrough. For example, combining the aforementioned field example, the specific code judgment condition for the associated field information meeting the preset passthrough value condition and the view indicator information meeting the preset passthrough transmission condition is as follows: `passThoughMode == true && passThoughSuperview != nil && passThoughTouch != nil && shouldReplaceSuperView`. Furthermore, when the associated field information meets the preset passthrough value condition and the view indicator information meets the preset passthrough transmission condition, the next interactive view to determine whether to respond to the touch event corresponding to the current touch position is the perspective parent view of this candidate interactive view. By determining whether the gesture recognizer corresponding to the pass-through parent view can respond to the touch event at the current touch position, it can be determined whether the pass-through parent view is the final responding view. If the gesture recognizer corresponding to the pass-through parent view cannot respond to the touch event, the process described above is repeated to extract the parent node view of the pass-through parent view for judgment, until the response chain of the target view is traversed to the end.

[0057] Optionally, after extracting the associated field information corresponding to the candidate interactive view from the target view response chain, the method further includes: If the associated field information does not meet the preset pass-through value conditions, or the view indication information does not meet the preset pass-through transmission conditions, the response view corresponding to the current touch position is determined based on the original parent view of the candidate interactive view.

[0058] If the associated field information does not meet the preset pass-through value conditions, or the view indication information does not meet the preset pass-through conditions, it can be considered that the candidate interactive view does not need to perform touch event pass-through. Therefore, according to the original view response chain, the next interactive view to determine whether to respond to the touch event corresponding to the current touch position is the original parent view of the candidate interactive view. By determining whether the gesture recognizer corresponding to the original parent view can respond to the touch event corresponding to the current touch position, it can be determined whether the original parent view is the final response view. If the gesture recognizer corresponding to the original parent view cannot respond to the touch event, the parent node view of the original parent view is extracted and judged according to the aforementioned process until the target view response chain is traversed to the end.

[0059] The above describes a method for determining the target view response chain based on the preset attribute information, corresponding logical view hierarchy, and current touch position of each interactive view in the application interface. This logical view hierarchy provides the original system hierarchy between interactive views, while the preset attribute information and current touch position help determine whether view pass-through is involved. This allows for the reasonable construction of a target view response chain that conforms to the natural view hierarchy, providing an ordered set of candidate views for determining the final response view. View indication information is generated based on the current call status of several preset system callback events, effectively monitoring the actual call status of system callback events and indicating the interactive views that need to be traversed in the target view response chain. Based on the view indication information and the target view response chain, the response view corresponding to the current touch position is determined. This allows for interactive view traversal of the target view response chain that conforms to the natural view hierarchy, combined with view indication information for further judgment, to accurately locate the response view that meets the user's interaction expectations, thus improving interaction quality. This solution follows the natural view hierarchy that aligns with user habits, ensures that the direction of touch event transmission is consistent with user expectations, ensures that touch events are delivered to the correct interactive view for response, and guarantees a positive user experience.

[0060] Figure 9 This is a schematic diagram illustrating the response determination method provided in the embodiments of this application. For example... Figure 9 As shown, in Figure 4Based on this, the original view response chain 403 is "R→C→E", while the adjusted target view response chain 701 is "R→A→B→C→E". Each interactive view is bound to a corresponding gesture recognizer. Gesture recognition is performed according to the target view response chain 701. If a gesture recognizer in an interactive view successfully recognizes a gesture, it can prevent the recognition of the same type of gesture recognizer in its parent node. For example, `panGesture` is a swipe gesture recognizer, specifically recognizing a series of move events; `tapGesture` is a tap gesture recognizer, specifically recognizing a finger touching and leaving the screen. Assume that interactive view R is bound to two gesture recognizers, `panR` and `tapR`, interactive view C is bound to a gesture recognizer `panC`, and interactive view B is bound to a gesture recognizer `tapB`. The system continues to determine whether to respond to user actions based on the current interactive view C. Without considering pass-through, taking the original view response chain 403 "R→C→E" as an example, the system will record the gesture recognizers on interactive views R and C: panR, tapR, and panC. Subsequent touch events such as begin, move, cancel, and end will be passed to these three gesture recognizers. If the move distance exceeds a threshold, the pan gesture recognizer will succeed. In this case, both panR and panC will succeed. Since the interactive view C corresponding to panC is a child node of the interactive view R corresponding to panR, after panC succeeds, the system will cause panR to fail. Therefore, panC completes its response, and interactive view C becomes the final response view. If the move distance does not exceed the threshold, both panC and panR will fail, but interactive view R will still have tapR successfully recognize it. Therefore, tapR performs the response, and interactive view R becomes the final response view.

[0061] However, since interactive view C is a pass-through view, if interactive view C cannot respond, the user actually expects interactive view B to respond. However, the original view response chain 403 does not include interactive view B. Therefore, when the system sends a touch event, it will not pass it to the gesture recognizer bound to interactive view B, and the gesture recognizer bound to interactive view B will not be able to recognize it successfully. Thus, according to the relevant steps of the embodiments of this application, the original view response chain 403 will be adjusted to the target view response chain 701, that is, "R→A→B→C→E". When interactive view C is in a pass-through state and meets the other conditions mentioned in the foregoing embodiments, the parent node of interactive view C is actually its pass-through parent view, that is, interactive view B. Correspondingly, the system will record multiple gesture recognizers, including panR, tapR, tapB, and panC, etc. When a user clicks on interactive view C, both tapR and tapB can respond. However, interactive view B is the pass-through parent view of interactive view C, and interactive view B is a grandchild node of interactive view R. Therefore, tapB will successfully recognize the click first, while tapR will fail to recognize it. In other words, the user's click behavior is responded to by interactive view B.

[0062] Figure 10 This is a structural block diagram of an application response view determination device provided in an embodiment of this application. The device has functional modules and beneficial effects corresponding to the above-described method. For example... Figure 10 As shown, the device specifically includes: Module 1001 is configured to acquire the current touch position in the application interface; The response chain determination module 1002 is configured to determine the target view response chain based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position. The instruction information determination module 1003 is configured to generate view instruction information based on the current call status corresponding to several preset system callback events; The response view determination module 1004 is configured to determine the response view corresponding to the current touch position based on the view indication information and the target view response chain.

[0063] The above-described approach, based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position, determines the target view response chain. This logical view hierarchy provides the original hierarchical relationship between interactive views, while the preset attribute information and the current touch position help determine whether view pass-through is involved. This allows for the reasonable construction of a target view response chain that conforms to the natural view hierarchy, providing an ordered set of candidate views for determining the final response view. View indication information is generated based on the current call status of several preset system callback events, effectively monitoring the actual call status of system callback events and assisting in indicating the interactive views that need to be traversed in the target view response chain. Based on the view indication information and the target view response chain, the response view corresponding to the current touch position is determined. Interactive view traversal can be performed on the target view response chain that conforms to the natural view hierarchy, and the view indication information can be used for auxiliary judgment to accurately locate the response view that meets the user's interaction expectations, improving interaction quality. This solution follows the natural view hierarchy that aligns with user habits, ensures that the direction of touch event transmission is consistent with user expectations, ensures that touch events are transmitted to the correct interactive view for response, and guarantees the user experience.

[0064] In one possible embodiment, the preset attribute information includes the pass-through status and the area range; the response chain determination module 1002 is further configured to: Extract the original view response chain corresponding to the current touch position from the logical view hierarchy; The target view response chain is obtained by adjusting the original view response chain based on the pass-through status, area range, and current touch position of each interactive view in the application interface.

[0065] In one possible embodiment, the response chain determination module 1002 is further configured to: If a first interactive view with a pass-through state enabled exists in the original view response chain, determine a second interactive view that is at the same view level and sequentially adjacent to the first interactive view. If the current touch position is within the area of ​​the second interactive view, supplementary node information is determined based on the pass-through status of the second interactive view and the associated view information; The target view response chain is obtained by updating the view nodes of the original view response chain based on the supplementary node information.

[0066] In one possible embodiment, the response chain determination module 1002 is further configured to: The logical view hierarchy is traversed level by level from low to high to determine several target interactive views associated with the current touch position. The original view response chain is obtained by sequentially integrating several target interactive views.

[0067] In one possible embodiment, the number of preset system callback events is multiple; the indication information determination module 1003 is further configured to: Determine the status flag information based on the current call status corresponding to each preset system callback event; The view indication information is obtained by integrating the status flag information corresponding to multiple preset system callback events.

[0068] In one possible embodiment, the response view determination module 1004 is further configured to: Determine the candidate interactive view to be processed from the target view response chain, and determine the preset gesture information corresponding to the candidate interactive view; If the touch event corresponding to the current touch position does not match the preset gesture information, extract the associated field information corresponding to the candidate interactive view from the target view response chain; If the associated field information meets the preset pass-through value conditions and the view indication information meets the preset pass-through transmission conditions, the response view corresponding to the current touch position is determined based on the perspective parent view of the candidate interactive view.

[0069] In one possible embodiment, the response view determination module 1004 is further configured to: If the associated field information does not meet the preset pass-through value conditions, or the view indication information does not meet the preset pass-through transmission conditions, the response view corresponding to the current touch position is determined based on the original parent view of the candidate interactive view.

[0070] In one possible embodiment, the response view determination module 1004 is further configured to: If the touch event corresponding to the current touch position matches the preset gesture information, the candidate interactive view is determined as the response view corresponding to the current touch position, and the touch event is responded to based on the preset gesture information.

[0071] Figure 11 A schematic diagram of the structure of a device for determining the response view of an application provided in an embodiment of this application, such as... Figure 11 As shown, the device includes a processor 1101, a memory 1102, an input device 1103, and an output device 1104.

[0072] The number of processors 1101 can be one or more. Figure 11 Taking a processor 1101 as an example; the processor 1101, memory 1102, input device 1103, and output device 1104 can be connected via a bus or other means. Figure 11Taking a bus connection as an example, memory 1102, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the application response view determination method in this embodiment. Processor 1101 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in memory 1102, thereby implementing the aforementioned application response view determination method. Input device 1103 can be configured to receive input digital or character information and generate key signal inputs related to user settings and function control of the device. Output device 1104 may include display devices such as a display screen.

[0073] This application also provides a non-volatile storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are configured to execute a response view determination method for an application described in the above embodiments. The method includes: obtaining the current touch position in the application interface; determining a target view response chain based on preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position; generating view indication information according to the current call status corresponding to several preset system callback events; and determining the response view corresponding to the current touch position based on the view indication information and the target view response chain.

[0074] It is worth noting that in the embodiments of the response view determination device of the above application, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not configured to limit the protection scope of the embodiments of this application.

[0075] In some possible implementations, various aspects of the methods provided in this application can also be implemented as a program product, including program code that, when run on a computer device, is configured to cause the computer device to perform the steps of the methods according to the various exemplary embodiments of this application described above. For example, the computer device can execute a response view determination method for an application program described in an embodiment of this application. The program product may be implemented using a combination of one or more readable media.

Claims

1. A method for determining the response view of an application, characterized in that, include: Obtain the current touch position in the application interface, and determine the target view response chain based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position; View indication information is generated based on the current call status corresponding to several preset system callback events; Based on the view indication information and the target view response chain, determine the response view corresponding to the current touch position.

2. The method for determining the response view of an application according to claim 1, characterized in that, The preset attribute information includes the pass-through status and the area range; The determination of the target view response chain based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position includes: Extract the original view response chain corresponding to the current touch position from the logical view hierarchy; Based on the pass-through status, area range, and current touch position of each interactive view in the application interface, the original view response chain is adjusted to obtain the target view response chain.

3. The method for determining the response view of an application according to claim 2, characterized in that, The step of adjusting the original view response chain to obtain the target view response chain based on the pass-through state, area range, and current touch position of each interactive view in the application interface includes: If a first interactive view with a pass-through state enabled exists in the original view response chain, a second interactive view that is at the same view level and sequentially adjacent to the first interactive view is determined. If the current touch position is within the area of ​​the second interactive view, supplementary node information is determined based on the pass-through state of the second interactive view and the associated view information; The target view response chain is obtained by updating the view nodes of the original view response chain based on the supplementary node information.

4. The method for determining the response view of an application according to claim 2, characterized in that, The step of extracting the original view response chain corresponding to the current touch position from the logical view hierarchy includes: The logical view hierarchy is traversed level by level from low to high to determine several target interactive views associated with the current touch position. The original view response chain is obtained by sequentially integrating the several target interactive views.

5. The method for determining the response view of an application according to claim 1, characterized in that, The number of preset system callback events is multiple; The step of generating view indication information based on the current call status corresponding to several preset system callback events includes: Determine the status flag information based on the current call status corresponding to each preset system callback event; The view indication information is obtained by integrating the status flag information corresponding to the multiple preset system callback events.

6. The method for determining the response view of an application according to claim 1, characterized in that, Determining the response view corresponding to the current touch position based on the view indication information and the target view response chain includes: The current candidate interactive view is determined from the target view response chain, and the preset gesture information corresponding to the candidate interactive view is determined; If the touch event corresponding to the current touch position does not match the preset gesture information, the associated field information corresponding to the candidate interactive view is extracted from the target view response chain; If the associated field information meets the preset transparent value conditions and the view indication information meets the preset transparent transmission conditions, the response view corresponding to the current touch position is determined based on the perspective parent view of the candidate interactive view.

7. The method for determining the response view of an application according to claim 6, characterized in that, After extracting the associated field information corresponding to the candidate interactive view from the target view response chain, the method further includes: If the associated field information does not meet the preset pass-through value conditions, or the view indication information does not meet the preset pass-through transmission conditions, the response view corresponding to the current touch position is determined based on the original parent view of the candidate interactive view.

8. The method for determining the response view of an application according to claim 6, characterized in that, After determining the preset gesture information corresponding to the candidate interactive view, the method further includes: If the touch event corresponding to the current touch position matches the preset gesture information, the candidate interaction view is determined as the response view corresponding to the current touch position, and the touch event is responded to based on the preset gesture information.

9. A response view determination device for an application, characterized in that, include: The acquisition module is configured to acquire the current touch position in the application interface; The response chain determination module is configured to determine the target view response chain based on the preset attribute information of each interactive view in the application interface, the corresponding logical view hierarchy, and the current touch position. The indicator information determination module is configured to generate view indicator information based on the current call status corresponding to several preset system callback events. The response view determination module is configured to determine the response view corresponding to the current touch position based on the view indication information and the target view response chain.

10. A response view determination device for an application, characterized in that, The device includes: one or more processors; and a storage device configured to store one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the response view determination method of the application according to any one of claims 1-8.

11. A non-volatile storage medium for storing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are configured to perform the response view determination method of the application program as described in any one of claims 1-8.

12. A computer program product, comprising a computer program, characterized in that, The computer program is stored in a computer-readable storage medium, and at least one processor of the device reads from the computer-readable storage medium and executes the computer program, causing the device to perform the response view determination method of the application according to any one of claims 1-8.

Images