Input interaction method and system for mobile terminal

Abstract

This specification provides an input interaction method and system for a mobile terminal. In the method, after the webpage view detects a user's preset operation on a placeholder input box in the webpage view, the dynamic container side activates the native input box in the dynamic container, triggers the system keyboard to pop up, and hides the placeholder input box. Subsequently, the dynamic container side determines an adjustment instruction based on the position information of the native input box and the expected position of the system keyboard, and sends an adjustment notification containing the adjustment instruction to the webpage view side. The webpage view side adjusts the page layout according to the adjustment instruction in the adjustment notification so that the native input box and the system keyboard do not obstruct each other.

Description

1. Manual This manual relates to the field of internet technology, and more particularly to an input interaction method and system for a mobile terminal. Background Technology With the rapid development of mobile internet technology, the application forms of mobile terminals are becoming increasingly diverse. To balance development efficiency, cross-platform capabilities, and user experience, hybrid applications and applications based on dynamic frameworks (such as React Native and Flutter) have been widely used. These applications typically include view components (such as WebView) that run web page content and dynamic containers for native UI components that support high-performance, complex interactions. A common scenario during user interaction with these applications is that users need to input text within the web page view. However, in mobile hybrid or dynamic application environments, communication delays and coordination between web page threads and native threads are difficult, resulting in sluggish input response and unsmooth layout adjustments. Therefore, there is an urgent need to provide a method that can provide a seamless and smooth input interaction experience. The content of the background technology section is merely information known only to the inventor and does not represent that the above information had entered the public domain before the date of this disclosure, nor does it represent that it can be considered prior art in this disclosure. Summary of the Invention This specification provides an input interaction method and system for a mobile terminal, applicable to scenarios requiring smooth text input within a webpage view in an application. In a first aspect, this specification provides an input interaction method for a mobile terminal, comprising: a webpage view side listening to a user's preset operation on a placeholder input box in the webpage view; activating a native input box in a dynamic container via a dynamic container side, triggering a system keyboard to pop up, and hiding the placeholder input box; the dynamic container side determining an adjustment instruction based on the position information of the native input box and the expected position of the system keyboard; the dynamic container side sending an adjustment notification to the webpage view side, the adjustment notification including the adjustment instruction; and the webpage view side adjusting the page layout based on the adjustment instruction, so that the native input box and the system keyboard do not obstruct each other. In some embodiments, the dynamic container side and the system keyboard run on a native thread, and the webpage view side runs on a webpage thread.In some embodiments, the webpage view side listens to a user's preset operation on a placeholder input box in the webpage view, activates a native input box in the dynamic container through the dynamic container side, triggers the system keyboard to pop up, and hides the placeholder input box. This includes: the event listener on the webpage view side listens to the user's preset operation on the placeholder input box in the webpage view, sends a first request through a first interface provided by the dynamic container side, the first request being used to request activation of the native input box in the dynamic container; the dynamic container side calls the native input component interface provided by the dynamic container side to activate the native input box, triggers the system keyboard to pop up, and instructs the webpage view side to hide the placeholder input box; and the webpage view side hides the placeholder input box. In some embodiments, the dynamic container side calls the native input component interface provided by the dynamic container side to activate the native input box and trigger the system keyboard to pop up, including: the dynamic container side obtaining the configuration information of the native input box; the dynamic container side calling the native input component interface provided by the dynamic container side to create a native input box instance and initialize the native input box based on the configuration information; the dynamic container side making the native input box visible through the input method provided by the operating system and requesting input focus; and the dynamic container side triggering the system keyboard to pop up in response to the successful activation event of the native input box. In some embodiments, the configuration information includes one or more of the following: input box type, placeholder, keyboard type, border style, rounded corner radius, and shadow effect; the configuration information is stored in a remote server or local storage. In some embodiments, instructing the webpage view to hide the placeholder input box includes: after activating the native input box, the dynamic container sends a first message to the webpage view via a predefined communication mechanism, the first message instructing the webpage view to hide the placeholder input box; or, after activating the native input box, the dynamic container calls a first callback function, the first callback function instructing the webpage view to hide the placeholder input box. In some embodiments, hiding the placeholder input box on the webpage view includes: the webpage view modifies the Cascading Style Sheets (CSS) property of the placeholder input box or removes the placeholder input box from the Document Object Model (DOM). In some embodiments, the native input box is used to receive and display target data entered by the user through the system keyboard; the method further includes: the dynamic container listens for the user entering target data in the native input box and synchronizes the target data to the webpage view; and the webpage view responds based on the target data.In some embodiments, the dynamic container side listens to target data entered by the user in the native input box and synchronizes the target data to the webpage view side, including: the dynamic container side captures each keyboard input event of the user in the native input box, packages the captured target data into a second message, and sends the second message to the webpage view side through a predefined communication mechanism. In some embodiments, the webpage view side responds based on the target data, including: the webpage view side parses the target data and updates the display element associated with the placeholder input box in the webpage view side based on the parsing result to respond to user input. In some embodiments, the method further includes: after the dynamic container side listens to the user's keyboard collapse operation, it hides the system keyboard, hides the native input box, and sends a keyboard collapse command to the webpage view side; and the webpage view side responds to the keyboard collapse command by redisplaying the placeholder input box. In some embodiments, sending the keyboard collapse command to the webpage view side includes: the dynamic container side encapsulates the keyboard collapse command into a third message and sends the third message to the webpage view side through a predefined communication mechanism provided by the dynamic container side. In some embodiments, the dynamic container side hides the system keyboard and the native input box after detecting the user's keyboard collapse operation, including: after detecting the user's keyboard collapse operation, the dynamic container side calls an interface or method provided by the operating system to hide the system keyboard and remove the native input box from the screen. In some embodiments, the dynamic container side and the webpage view side communicate via shared memory. In some embodiments, the method further includes: during the operation of the native input component, the dynamic container side receives an update instruction from the webpage view side through a predefined communication mechanism; and the dynamic container side dynamically adjusts the configuration information of the native input box according to the update instruction. In a second aspect, this specification also provides an input interaction system for a mobile terminal, including at least one storage medium and at least one processor, the at least one storage medium storing at least one instruction set for performing input interaction of the mobile terminal; the at least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and executes the method described in any one of the first aspects above according to the instructions of the at least one instruction set.As can be seen from the above technical solutions, the input interaction method and system for mobile terminals provided in this specification are executed collaboratively by the webpage view side, the dynamic container side, and the operating system layer. After the webpage view side detects a user's preset operation on a placeholder input box in the webpage view, it activates the native input box in the dynamic container through the dynamic container side, triggering the system keyboard to pop up and hiding the placeholder input box. Subsequently, the dynamic container side determines an adjustment instruction based on the position information of the native input box and the expected position of the system keyboard, and sends an adjustment notification containing the adjustment instruction to the webpage view side. The webpage view side adjusts the page layout according to the adjustment instruction, ensuring that the native input box and the system keyboard do not obstruct each other. The above technical solution, by introducing a native input box on the dynamic container side to replace the placeholder input box in the webpage view, and based on real-time calculation of the position of the native input box and the expected position of the system keyboard, achieves automatic avoidance and layout adjustment between the system keyboard and the native input box when input is triggered. This method, by directly interacting with the system keyboard through the native input box, avoids the input delay, focus management chaos, and inconsistent keyboard response that may occur with web page input boxes in mixed environments, thus improving the immediacy and stability of input response. Furthermore, the method described above, which uses real-time calculation on the dynamic container side to guide layout adjustments on the web page view side, ensures that the native input box remains within the visible area above the system keyboard regardless of screen size, keyboard type, or device orientation. This solves the problem of interrupted user input experience caused by the system keyboard obscuring the native input box, achieving a seamless, continuous, and smooth input visual flow, and improving user interaction satisfaction and operational efficiency. Other functions of the mobile terminal input interaction method and system provided in this specification will be partially listed in the following description. The inventive aspects of the mobile terminal input interaction method and system provided in this specification can be fully explained through practice or use of the methods, devices, and combinations described in the detailed examples below. Brief Description of the Drawings: To more clearly illustrate the technical solutions in the embodiments of this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 illustrates an application scenario of an input interaction system for a mobile terminal according to an embodiment of this specification. Figure 2 illustrates a hardware structure diagram of a computing device according to some embodiments of this specification. HK 30135241 A 4 Figure 3 illustrates a flowchart of an input interaction method for a mobile terminal according to an embodiment of this specification. Figure 4 illustrates a flowchart of the initialization process of a native input box according to an embodiment of this specification.Figure 5 illustrates a schematic diagram of a system keyboard hiding process according to an embodiment of this specification. Figure 6 illustrates a schematic flowchart of an input interaction method for a mobile terminal according to another embodiment of this specification. Detailed Description The following description provides specific application scenarios and requirements for this specification, intended to enable those skilled in the art to make and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of this specification. Therefore, this specification is not limited to the illustrated embodiments, but rather to the widest scope consistent with the claims. The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. When used in this specification, the terms “comprising,” “including,” and / or “containing” mean that the associated integers, steps, operations, elements, and / or components are present, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or that other features, integers, steps, operations, elements, components, and / or groups may be added to the system / method. Considering the following description, these and other features of this specification, as well as the operation and function of related structural elements, and the economy of component combination and manufacture, can be significantly improved. All of these form part of this specification with reference to the accompanying drawings. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale. The flowcharts used in this specification illustrate the operation of a system implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented sequentially. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more other operations may be added to the flowcharts. One or more operations may be removed from the flowcharts. In this specification, "X includes at least one of A, B, or C" means that X includes at least A, or X includes at least B, or X includes at least C. That is, X may include only any one of A, B, and C, or any combination of A, B, and C, as well as other possible contents / elements. Any combination of A, B, and C may be A, B, C, AB, AC, BC, or ABC. In this specification, unless otherwise stated, the relationships between structures can be direct or indirect.For example, when describing "A is connected to B", unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is above B", unless it is explicitly stated that A is directly above B (AB are adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB are separated by other elements, and A is above B). And so on. It should be noted that the user data obtained in this specification is authorized by the user and does not involve user privacy. HK 30135241 A 5 For ease of description, the terms that will appear later in this specification will be explained first. Shared memory: A high-performance communication method. Both parties in a shared memory connection can access the same memory area. After one party writes data to the shared memory, it notifies the other party to read the written data through a simple semaphore or event, without needing to go through the operating system kernel, thereby improving the data transfer rate. Webpage View Side: The interface that carries the webpage content, responsible for rendering and displaying the webpage, and handling its visual presentation and interaction. Dynamic Container Side: Provides a container for dynamically loading and managing content, supporting real-time updates and expansion, enhancing user experience. Native Input Box: An input component natively provided by the operating system, possessing system-level input processing capabilities, with good compatibility and stability. System Keyboard: An input tool provided by the operating system, responsible for receiving user input commands and passing them to the application. Native Thread: An independent execution unit managed by the operating system, with independent memory space and execution flow, capable of parallel execution. Webpage Thread: A thread used to handle webpage-related tasks, responsible for webpage rendering, script execution, and event handling. The methods provided in this specification are applicable to input interaction scenarios in mobile terminals where webpages and native components are rendered in a hybrid manner. Examples include: posting comments on product details pages in e-commerce applications with embedded WebViews, filling out search boxes in news clients developed using React Native, or entering data into embedded forms in enterprise applications built using the Flutter framework. The input interaction method provided in this specification can be deployed on various mobile terminals such as smartphones, tablets, and wearable devices to handle text input requests triggered by users in hybrid application interfaces. In related technologies, when a user triggers a text input request in a hybrid application scenario, the input box on the webpage view side typically responds directly. However, this method can easily obscure the input area when the system keyboard pops up, and the keyboard height and behavior may vary across different devices and system versions, resulting in users not being able to see the real-time input content.In other words, in dynamic, cross-platform hybrid application scenarios, the related technologies are prone to keyboard obstruction, focus loss, or response lag during input interaction due to factors such as dynamically variable page layout, differences in keyboard behavior, and inter-thread communication delays, affecting input efficiency and user experience. Dynamically variable page layout includes, but is not limited to: Web page content shifting position, changing height, or rearranging elements due to data loading, animation execution, or user scrolling, causing the preset input area positioning to fail. Differences in keyboard behavior include, but are not limited to: differences in keyboard pop-up height, animation duration, and collapse triggering mechanisms across different operating systems, input method types, or device sizes, making fixed layout adjustment strategies difficult to apply universally. Inter-thread communication delays include, but are not limited to: serialization overhead and asynchronous scheduling delays in communication between web page threads and native threads via bridging, easily causing a disconnect between input activation, data synchronization, and layout adjustment. Therefore, this specification provides an input interaction method for mobile terminals that works collaboratively between the web page view side, the dynamic container side, and the operating system layer. In this system, the web view side listens for user actions on placeholder input boxes and receives adjustment commands from the dynamic container. The dynamic container side activates the native input box and determines the adjustment command based on the native input box's position and the expected position of the system keyboard. This cross-threaded collaborative approach (HK 30135241 A 6) maintains the dynamic flexibility of web page content without sacrificing web development efficiency and cross-platform capabilities. The dynamic container side obtains the precise position of the native input box and the expected position of the system keyboard in real time, calculates the unobstructed adjustment command, and feeds it back to the web view side for execution. Once the web view side completes the page layout adaptation based on the adjustment command, it ensures that the native input box and the system keyboard never obstruct each other. This achieves a unified web input experience and native input performance, overcoming the keyboard obstruction problem and system keyboard pop-up latency in related technologies, and improving the interactive smoothness and visual integrity of mixed application input scenarios. It should be noted that the above description of the application scenario is only one of the many usage scenarios provided in this manual. Those skilled in the art will understand that when the mobile terminal input interaction method and system provided in this specification are applied to other usage scenarios, their implementation methods and technical effects are similar. Figure 1 shows a schematic diagram of an application scenario 100 of a mobile terminal input interaction system 130 provided according to an embodiment of this specification. As shown in Figure 1, this application scenario may include the mobile terminal input interaction system 130 (hereinafter referred to as: interaction system 130). In some embodiments, the interaction system 130 may be a system that provides hybrid application input interaction optimization services.The interactive system 130 comprises a webpage view side and a dynamic container side. The webpage view side runs on the webpage thread and is responsible for rendering and displaying webpage content. The dynamic container side runs on the native thread and is responsible for managing the native input boxes. Data and command interaction is possible between the webpage view side and the dynamic container side. The dynamic container side has the ability to activate native input boxes, calculate page layout adjustment commands, and send these commands to the webpage view side. The webpage view side has the ability to listen for user actions, hide placeholder input boxes, and dynamically adjust the page layout based on adjustment commands. Specifically, after the webpage view side detects a user's preset action on a placeholder input box, the dynamic container side is triggered and activates the native input box, invokes the system keyboard, and simultaneously instructs the webpage view side to hide the placeholder input box. Subsequently, the dynamic container side calculates based on the real-time position of the native input box and the expected position of the system keyboard, generates adjustment commands, and sends adjustment notifications to the webpage view side. The webpage view adjusts the page layout according to the adjustment instructions in the adjustment notification, ensuring that the native input box and the system keyboard do not obstruct each other. This ensures that there is no content obstruction during user input, so that the input content corresponding to the user's input operation is not obscured by the system keyboard and is displayed normally in the corresponding position on the webpage view. The interactive system 130 is a computing system with certain computing capabilities. The interactive system 130 can correspond to a single mobile terminal device or a test or management cluster composed of multiple mobile devices. The interactive system 130 can be integrated locally within a mobile application or deployed remotely as middleware service. In this case, the physical device corresponding to the interactive system 130 can store data or instructions for executing the mobile terminal input interaction method described in this specification, and can execute or be used to execute the data or instructions. In some embodiments, the physical device corresponding to the interactive system 130 may include a hardware device with data information processing capabilities and the necessary programs required to drive the hardware device. It should be noted that the user data obtained in this specification is all authorized by the user and does not involve user privacy. Figure 2 shows a schematic diagram of the hardware structure of a computing device 200 provided according to some embodiments of this specification. The computing device 200 can serve as the input interaction system 130 of the mobile terminal in FIG1. ​​In some embodiments, when the input interaction system 130 of the mobile terminal employs a device cluster, the computing device 200 can serve as any one device in the input interaction system 130 of the mobile terminal. As shown in FIG2, the computing device 200 includes at least one storage medium 230 and at least one processor 220. In some embodiments, the computing device 200 may further include an internal communication bus 210.In some embodiments, the computing device 200 may further include a communication port 250. In some embodiments, the computing device 200 may further include an I / O component 260. An internal communication bus 210 may connect different system components, including storage medium 230 and processor 220. I / O component 260 supports input / output between the computing device 200 and other components. The communication port 250 is used for data communication between the computing device 200 and the outside world. For example, the computing device 200 may connect to a network through the communication port 250. The storage medium 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 232, a read-only storage medium (ROM) 234, or a random access storage medium (RAM) 236. The storage medium 230 also includes at least one instruction set stored in the data storage device. The instruction set is computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that execute the input interaction methods of the mobile terminal provided in this specification. At least one processor 220 is communicatively connected to at least one storage medium 230 via an internal communication bus 210. The at least one processor 220 is used to execute the at least one instruction set described above. When the input interaction system 130 of the mobile terminal is running, the at least one processor 220 reads the at least one instruction set and executes the input interaction method of the mobile terminal provided in this specification according to the instructions of the at least one instruction set. The processor 220 can execute all the steps included in the input interaction method of the mobile terminal. The processor 220 can be in the form of one or more processors. The processor 220 can issue execution instructions. The processor 220 can include one or more hardware processors, such as a microcontroller, microprocessor, reduced instruction set computer (RISC), application-specific integrated circuit (ASIC), application-specific instruction set processor (ASIP), central processing unit (CPU), graphics processing unit (GPU), physical processing unit (PPU), microcontroller unit, digital signal processor (DSP), field-programmable gate array (FPGA), advanced RISC machine (ARM), programmable logic device (PLD), any circuit or processor capable of performing one or more functions, or any combination thereof. For illustrative purposes only, only one processor 220 is shown in the accompanying drawings of the computing device 200. However, it should be noted that the computing device 200 may also include multiple processors, and therefore, the operations and / or method steps disclosed herein may be executed by a single processor or by multiple processors in combination, as described herein.For example, if the processor 220 of the computing device 200 in this specification executes steps A and B, it should be understood that steps A and B can also be executed jointly or separately by two different processors 220 (e.g., the first processor executes step A, the second processor executes step B, or the first and second processors jointly execute steps A and B). Figure 3 shows a flowchart of an input interaction method for a mobile terminal according to an embodiment of this specification; the input interaction method P300 of the mobile terminal can be executed by the input interaction system 130 of the mobile terminal. As shown in Figure 3, the method P300 provided in this specification may include S310-S370, wherein: S310: The webpage view side listens to the user's preset operation on the placeholder input box in the webpage view, activates the native input box in the dynamic container through the dynamic container side, triggers the system keyboard to pop up, and hides the placeholder input box. HK 30135241 A 8 Wherein, the dynamic container side and the system keyboard run on the native thread, ensuring the response speed and performance of the system keyboard and avoiding webpage thread blocking. The webpage view runs on the webpage thread. Communication between the dynamic container and the webpage view is achieved through shared memory, improving communication efficiency and enabling millisecond-level data transfer, thus ensuring smooth rendering of the webpage view. Preset operations can be user touch actions on placeholder input boxes or user clicks on placeholder input boxes within the webpage view. Upon receiving a preset operation, the webpage view notifies the dynamic container. Upon receiving the notification, the dynamic container activates the native input box within its managed dynamic container. Since the native input box is a native component, it directly triggers the operating system to display the system keyboard. Simultaneously, to maintain a clean interface on the webpage view and avoid user confusion, the placeholder input boxes on the webpage view are hidden, leaving the input task entirely to the native input boxes. In some embodiments, the event listener on the webpage view detects a user's preset operation on a placeholder input box and sends a first request to the dynamic container through a first interface provided by the dynamic container. This first request is used to request the activation of the native input box within the dynamic container. The dynamic container side calls the native input component interface provided by the dynamic container side to activate the native input box, trigger the system keyboard to pop up, and instruct the web page view side to hide the placeholder input box. This method of activating the native input box and triggering the system keyboard to pop up through the dynamic container side improves the speed and reduces the latency of the system keyboard pop-up. For example, the web page view side runs web page code, which binds an event listener to the placeholder input box element to listen for preset user actions on the placeholder input box. In some embodiments, the dynamic container side obtains the configuration information of the native input box.The configuration information can be sent from the web view side to the dynamic container side via a communication interface, or it can be dynamically loaded based on preset rules or remote configuration. The dynamic container side calls the native input component interface provided by itself to create a native input box instance and initializes the native input box based on the configuration information, thereby ensuring that the native input box maintains visual and logical consistency with the placeholder input box on the web view side in terms of style and behavior. The dynamic container side makes the native input box visible through the input methods provided by the operating system and requests input focus. In response to the successful activation event of the native input box, the dynamic container side triggers the system keyboard to pop up. Through the above standardized interface and configuration information-driven approach, seamless switching and accurate restoration of the input box from the placeholder input box on the web view side to the native input box are achieved. This not only retains the flexible configuration capabilities of the web view side but also ensures the immediacy and stability of input response through the system-level integration of the native input box. In some embodiments, the dynamic container side can parse the configuration information of the native input box from the first request. The configuration information includes one or more of the following: input box type (single-line / multi-line), placeholders, keyboard type (default, numeric, email, etc.), border style, corner radius, and shadow effect. This configuration information is stored on a remote server or local storage. The dynamic container calls the native input component interface to create a native input box instance. This native input component interface is operating system dependent, for example, in React Native. <textinput>The component corresponds to the UITextField text input field in Apple's mobile operating system, or the TextField in Flutter corresponds to the EditText text input field in Android's mobile operating system. The dynamic container then initializes the native input field instance using configuration information to obtain the native input field. Subsequently, the dynamic container adds the native input field to the current view hierarchy using the input methods provided by the operating system, making the native input field visible, and calls the corresponding focus request method of the operating system to request input focus. For example, in Apple's mobile operating system (iOS), it calls "becomeFirstResponder," and in Android's mobile operating system, it calls "requestFocus." When the native input field successfully gains focus, the operating system automatically responds and pops up the system keyboard. The dynamic container can listen for the native input field's focus event and use it as a confirmation event that the keyboard has been triggered. In some embodiments, the dynamic container needs to instruct the web view to hide the placeholder input field while or after activating the native input field. Figure 4 illustrates the initialization process of a native input box according to an embodiment of this specification. As shown in Figure 4, after the webpage view completes rendering, it sends a command to create a dynamic container to the dynamic container side. After creating the dynamic container, the dynamic container side sends a creation success command to the webpage view side. Upon receiving the creation success command, the webpage view side sends the configuration information of the native input box to the dynamic container side. The dynamic container side creates a native input box instance and completes the configuration of the native input box based on its configuration information. After the native input box is successfully created, the dynamic container side sends a creation success command to the webpage view side. Subsequently, the webpage view side listens for whether autofocus needs to be activated. After detecting a user's preset operation on the placeholder input box in the webpage view, the webpage view side triggers the keyboard activation process, activates the native input box in the dynamic container through the dynamic container side, triggers the system keyboard to pop up, and hides the placeholder input box. S330: The dynamic container side determines the adjustment command based on the position information of the native input box and the expected position of the system keyboard. In some embodiments, the system keyboard may obscure the native input field after it pops up, preventing the user from seeing their input. Therefore, the dynamic container side calculates whether the page layout needs to be adjusted, and how, based on the position of the native input field and the expected position of the system keyboard. For example, the dynamic container side can obtain the position information of the native input field, such as the coordinates of the top-left corner and the width and height of the native input field.Meanwhile, the dynamic container can predict or obtain the expected position of the system keyboard after it pops up, such as the expected position and height of the system keyboard, based on system interfaces or empirical data. In some embodiments, after the native input box is activated and added to the view hierarchy, the dynamic container can obtain the position and size of the native input box in the screen coordinate system corresponding to the current display page through the system interface corresponding to the operating system. For example, on iOS, the `convertRect:toView:` method can be used to obtain the rectangular frame of the native input box relative to the window. On Android, the `getLocationOnScreen()` method can be used to obtain the coordinates of the native input box, and the obtained information usually includes the x-coordinate, y-coordinate, width, and height of the input box. In addition, the position of the system keyboard (height and whether it covers the bottom of the screen) is generally dynamic and may change due to the system keyboard type, device model, and current landscape / portrait state. The dynamic container can obtain the position of the system keyboard by listening to system keyboard notifications or by prediction and querying. In the scenario of listening to system keyboard notifications, the operating system generally sends system notifications when the system keyboard is about to be shown / hidden. The dynamic container can determine the expected position of the system keyboard through information carried in system notifications. In scenarios involving predicting and querying the system keyboard position, the dynamic container can predict the expected position of the system keyboard by querying a preset mapping table based on the configured system keyboard type and device information before triggering the system keyboard. Alternatively, as per HK 30135241 A 10, after the system keyboard pops up, the dynamic container can determine the expected position of the system keyboard by querying the layout information of the display page. The dynamic container can determine whether there is any obstruction between the system keyboard and the native input box by comparing the input box position and the expected keyboard position. Specifically, the dynamic container compares the position of the native input box (including at least the y-coordinate of the bottom edge and the height of the native input box) with the expected position of the system keyboard (the y-coordinate of the top edge of the system keyboard). If the bottom edge coordinate of the native input box is greater than the top edge coordinate of the system keyboard, it means that the native input box will be obscured by the system keyboard. If the bottom coordinates of the native input box are less than or equal to the top coordinates of the system keyboard, it means there is no obstruction between the system keyboard and the native input box. In this case, no adjustment instructions are needed, and the native input box and the system keyboard can be displayed normally on the webpage. If there is obstruction between the native input box and the system keyboard, or if the position of the native input box is not ideal (e.g., the native input box is at the bottom of the screen), the dynamic container will calculate how the native input box needs to be moved, or how the page content displayed on the screen needs to be adjusted, so that the native input box moves to the visible area above the system keyboard.For example, the dynamic container needs to calculate how many pixels to move the native input box upwards so that the moved native input box is fully displayed above the system keyboard. Therefore, the offset can be calculated as: offset = bottom coordinates of the native input box - top coordinates of the system keyboard. If offset > 0, it means that the native input box needs to be adjusted upwards by an offset of pixels. Based on the above calculation results, the dynamic container generates adjustment instructions that the webpage view can understand and execute. For example, the adjustment instructions could be: "Scroll the page content on the webpage view upwards by 100 pixels", or "Move the position of the container containing the native input box upwards by 150 pixels". Alternatively, adjustment instructions can be generated using a format agreed upon in the protocol between the dynamic container side and the webpage view side, for example: "{ action: 'scrollTo', y: offset}: Instructs the webpage view to scroll the page to the specified position. { action: 'adjustPosition', inputId: 'myInput', offsetY: -offset}: Instructs the webpage view to move the native input box or its container upwards by offset pixels. { action: 'focusAndScroll', elementId: 'myInput', offset: offset}: A composite instruction combining focus and scrolling." It should be understood that the above embodiments are merely illustrative, and the content of the specific adjustment instructions can be flexibly adjusted according to user needs, and is not limited to the embodiments described above. S350: The dynamic container side sends an adjustment notification to the webpage view side, the adjustment notification including the adjustment instructions. The dynamic container side can send the adjustment notification containing the adjustment instructions to the webpage view side through a predefined communication mechanism, so that the webpage view side adjusts the page layout in the webpage view according to the adjustment notification. S370: The webpage view adjusts the page layout based on adjustment instructions, ensuring that the native input fields and the system keyboard do not obstruct each other. Upon receiving an adjustment notification, the webpage view parses the adjustment instructions. Then, it adjusts the page layout accordingly by manipulating CSS properties or the Document Object Model (DOM). For example, the webpage view can scroll the entire webpage document (document.body.scrollTop) or adjust the position of the parent container containing the input fields (transform: translateY(-100px)). The adjusted native input fields in the webpage view are fully displayed above the system keyboard, ensuring that the user can always see the input fields and the entered text, achieving an unobstructed input experience.The adjusted page layout allows users to input smoothly in a native input box that is appropriately positioned and not obstructed by the keyboard. In some embodiments, to ensure display quality, after executing the adjustment instruction, the web view side can calculate whether the adjusted position of the native input box does not obstruct the system keyboard area. If insufficient or excessive adjustment is found, the web view side can fine-tune the position of the native input box to optimize the display effect. In summary, the input interaction method P300 and system 130 of the mobile terminal provided in this specification are executed collaboratively by the web view side, the dynamic container side, and the operating system layer. After the web view side detects a user's preset operation on a placeholder input box in the web view, it activates the native input box in the dynamic container through the dynamic container side, triggers the system keyboard to pop up, and hides the placeholder input box. Subsequently, the dynamic container side determines the adjustment instruction based on the position information of the native input box and the expected position of the system keyboard, and sends an adjustment notification containing the adjustment instruction to the web view side. The web view side adjusts the page layout according to the adjustment instruction to ensure that the native input box and the system keyboard do not obstruct each other. The aforementioned technical solution replaces the placeholder input box in the webpage view with a native input box on the dynamic container side. Based on real-time calculation of the native input box's position and the expected position of the system keyboard, it achieves automatic avoidance and layout adjustment between the system keyboard and the native input box when input is triggered. This direct interaction between the native input box and the system keyboard avoids the input delay, focus management confusion, and inconsistent keyboard response issues that may occur with webpage input boxes in mixed environments, improving the immediacy and stability of input response. Furthermore, the method of real-time calculation on the dynamic container side to guide layout adjustments on the webpage view side ensures that the native input box remains within the visible area above the system keyboard regardless of screen size, keyboard type, or device orientation. This solves the problem of interrupted user input experience caused by the system keyboard obscuring the native input box, achieving a seamless, continuous, and smooth input visual flow, improving user interaction satisfaction and operational efficiency. In some embodiments, the dynamic container side can instruct the webpage view side to hide the placeholder input box while or after activating the native input box by sending a message or using a callback function. The dynamic container can send a first message to the webpage view via a predefined communication mechanism (such as WebSocket, custom events, message queues, etc.). This first message instructs the webpage view to hide the placeholder input box. Alternatively, after activating the native input box, the dynamic container can call a first callback function, which instructs the webpage view to hide the placeholder input box.In some embodiments, when a user performs a preset operation on a placeholder input box, the web view layer can send a request to the dynamic container via the `sendToDynamicContainer` function. After activating the native input box, the dynamic container calls the `onNativeInputActivated` callback function, which is responsible for hiding the placeholder input box. Sending messages and callback functions are two different communication mechanisms used in mobile terminal input interaction methods to pass information and instructions between the web view layer, the dynamic container, and the container layer. Sending messages is an asynchronous communication mechanism that allows one component (such as the dynamic container side) to send information to another component (such as the web view side) without immediately waiting for a response. This mechanism is typically used in scenarios where loose coupling between components is required, i.e., components do not need to directly know each other's specific implementation details. For example, after activating the native input box, the dynamic container side can send an activation success message to the web view side via a predefined communication mechanism (such as WebSocket, custom events, message queues, etc.). The activation success message may contain instructions such as "hide the placeholder input box". The webpage view listens for user actions on the placeholder input box and performs corresponding actions upon receiving a successful activation message, such as hiding the placeholder input box by modifying CSS properties or removing the element from the DOM. HK 30135241 A 12 illustrates the implementation of the message communication mechanism using JavaScript: / / Webpage view layer listens for messages from the dynamic container document.addEventListener('messageFromDynamicContainer', function(event) { if (event.data.command === 'hidePlaceholderInput') { / / Hide the placeholder input box document.getElementById('placeholderInput').style.display = 'none';}}); ``` Here, callback functions are a synchronous or asynchronous communication mechanism, where one function (callback) is called after another function has finished executing. Callback functions are typically used for operations that need to be executed sequentially, or when one operation depends on the result of another. For example, after activating the native input field, the dynamic container might call a predefined callback function that instructs the web view to hide the placeholder input field. The callback function can be defined directly in the dynamic container's code or passed as an argument to the calling function.Here's an example using JavaScript to illustrate the implementation of a callback function communication mechanism: `function activateNativeInputAndHidePlaceholder() { / / Function to activate the native input box, hides the placeholder input box upon successful activation dynamicContainer.activateNativeInput(function() { / / Callback function after the native input box is activated, hides the placeholder input box webpageLayer.hidePlaceholderInput();});} / / Function to hide the placeholder input box defined on the webpage view side function hidePlaceholderInput() { var placeholderInput = document.getElementById('placeholderInput'); placeholderInput.style.display = 'none'; / / Sets the style to invisible}` In the example above, the `activateNativeInput` function activates the native input box and accepts a callback function as a parameter. This callback function executes after the native input box is successfully activated, notifying the webpage view to hide the placeholder input box. In other words, sending messages and callback functions are both effective mechanisms for communication between different components in mobile terminal input interaction methods. Sending messages provides a flexible asynchronous communication method, while callback functions ensure the order and determinism of operations. In practical applications, the choice of specific communication mechanism can be flexibly determined according to user needs and application scenarios to achieve a smooth and reliable input interaction experience. For example, after receiving a hide instruction from the dynamic container side, the webpage view side executes the hide operation of the placeholder input box. The webpage view side can modify the Cascading Style Sheets (CSS) properties of the placeholder input box or remove the placeholder input box from the Document Object Model (DOM). For example, the webpage view side can set the display property of the placeholder input box to none, so that the placeholder input box is hidden and does not occupy layout space, thus completely removing it from the document flow and making it invisible. Alternatively, the visibility property can be set to hidden to retain its layout placeholder but hide the content. Or it can be moved out of the visible area (position: absolute; left: -9999px;). Alternatively, the placeholder input element can be removed directly from its parent node (removeChild) on the webpage view side, thereby eliminating the placeholder input at the structural level.Hiding placeholder input boxes avoids visual overlap and interaction confusion caused by the simultaneous presence of native input boxes and webpage placeholder input boxes, ensuring the uniqueness and clarity of the user's visual focus during input, while ensuring that all input events are concentrated on the native input box. CSS property modification is suitable for scenarios requiring quick restoration of display, offering strong reversibility and not affecting DOM structure stability. DOM removal is suitable for situations where the placeholder box does not need to be displayed again after input, which helps streamline page nodes and improve rendering efficiency. The specific method of hiding placeholder input boxes can be flexibly adjusted according to different application scenarios, system performance, or restoration requirements, and is not limited to the embodiments described above. In some embodiments, the configuration information of the native input box supports dynamic hot updates. Specifically, during the operation of the native input component, the dynamic container receives update instructions from the webpage view through a predefined communication mechanism. The dynamic container dynamically adjusts the configuration information of the native input box according to the update instructions. For example, during the operation of the native input component, such as when the user needs to receive and input a verification code after entering content, the keyboard type needs to be switched from "default keyboard" to "numeric keyboard". The web view can send update commands to the dynamic container side via a predefined communication mechanism. Upon receiving the update command, the dynamic container side parses it to extract the updated configuration information. Subsequently, the dynamic container side calls the native input box's interface to dynamically update the native input box's configuration information during the native input component's runtime. This dynamic hot-update capability allows the web view side to flexibly update the native input box's configuration information according to the current application scenario, improving the efficiency and flexibility of the interaction. In some embodiments, the native input box is used to receive and display target data entered by the user via the system keyboard. The dynamic container side listens for the user entering target data in the native input box and synchronizes the target data to the web view side. The web view side responds based on the target data. When the user starts typing in the native input box, the input content needs to be organized into target data and synchronized back to the web view side so that the web view can process this target data (such as real-time validation, search suggestions, word count, etc.). For example, the dynamic container side captures each keyboard input event of the user in the native input box, packages the captured target data into a second message, and sends the second message to the web view side through a predefined communication mechanism. The predefined communication mechanism can be a predefined communication channel or interface. When input is made in the native input field, a series of native events (keyboard input events) are triggered, such as the text change callback method (onChangeText) triggered when the text content changes (React Native), and the text change event (textChanged) triggered when the text has been changed (iOS / Android).After capturing keyboard input events, the dynamic container side triggers a listener whenever the input content changes (e.g., a single keystroke, continuous input, content deletion, etc.), and obtains the complete text in the current input box or the content of the change (delta). The dynamic container side packages the target data into a structured second message. For example: { type: 'inputSync', inputId: 'myInput', text: 'text entered by the user'}, and sends the second message to the webpage view side through a predefined communication mechanism. In some embodiments, the webpage view side parses the target data and updates the display elements associated with the placeholder input box in the webpage view side based on the parsing result to respond to user input. Specifically, after receiving the second message, the webpage view side extracts the target data from the second message and parses the target data, achieving millisecond-level response from native input events to webpage logic. Through the above process, although the user (HK 30135241 A 14) enters target data in the native input box, the entered target data can be fed back to the webpage view side in real time and accurately. The placeholder input box on the webpage view side is synchronously filled with the target data entered by the user through the above synchronization mechanism. After the dynamic container side listens for the user's keyboard collapse operation, it hides the system keyboard, hides the native input box, and sends a keyboard collapse command to the webpage view side. The webpage view side responds to the keyboard collapse command and redisplays the placeholder input box. In some embodiments, the keyboard collapse operation can be triggered by the user, such as: the user clicks the "Done" or "Back" control on the system keyboard, clicks other screen areas outside the native input box and system keyboard, etc. After listening for the user's keyboard collapse operation, the dynamic container side calls the operating system's system interface to make the native input box lose focus, thereby collapsing the system keyboard and removing the native input box from the view hierarchy, or setting the state of the native input box to invisible. For example, the dynamic container side encapsulates the keyboard collapse command as a third message and sends the third message to the webpage view side through a predefined communication mechanism provided by the dynamic container side. After receiving the third message, the webpage view receives the placeholder input box and redisplays it. The specific method of redisplaying the placeholder input box corresponds to the method of hiding it previously. Specifically, if the placeholder input box was previously hidden using CSS, it is redisplayed by restoring its CSS properties. Alternatively, if the placeholder input box was previously removed from the DOM, it is redisplayed by reinserting the placeholder input box element into its original position. In some embodiments, the page layout may be adjusted during the display of the native input box and the system keyboard. Therefore, after the system keyboard is collapsed, the webpage view can restore the page layout, for example, by restoring the scroll position or resetting it through translation.Of course, the adjusted page layout can also remain unchanged. Whether the page layout is adjusted after the system keyboard is hidden can be flexibly set according to user needs and is not limited to the embodiments given above. After the dynamic container side listens to the user's keyboard hiding operation, it calls the system interface or method provided by the operating system to hide the system keyboard and remove the native input box from the screen. Figure 5 shows a schematic diagram of the system keyboard hiding process according to an embodiment of this specification. As shown in Figure 5, after the dynamic container side listens to the user triggering the system keyboard hiding, it triggers the CSS animation of the system keyboard hiding and sends a third message to the web page view side to notify the web page view side that the system keyboard has been hidden. After receiving the third message, the web page view side redisplays the placeholder input box. Figure 6 shows a flowchart of an input interaction method for a mobile terminal according to another embodiment of this specification. As shown in Figure 6, the input interaction process of the mobile terminal may include multiple stages, each of which has its own corresponding execution flow, such as: initialization process, keyboard lifting process, keyboard hiding process, and input content sending process. The process corresponding to each stage is described below. After the user enters the webpage view of the application, if it is determined that the current terminal device's system capabilities support loading a dynamic container, the initialization process is executed. If a loading error is detected or the dynamic container is not supported, the rendering mode of the pure webpage view is automatically switched. This embodiment only describes the case where loading a dynamic container is supported. As shown in Figure 6, in the initialization process, the webpage view side initiates a request to create a dynamic container by calling the JavaScript interface (jsapi.invokeCabinInput.create). After the dynamic container is successfully created, the dynamic container side sends a creation success instruction to the webpage view side. Subsequently, the webpage view side sends the configuration information of the native input box to the dynamic container side, so that the dynamic container side creates and completes the initialization configuration of the native input box instance HK 30135241 A 15 based on the configuration information, such as setting parameters such as input box style and keyboard type. After successful configuration, the dynamic container side returns a creation success message to the webpage view side. Specifically, the initialization process needs to be re-executed after the webpage view changes, that is, after the user switches from the current page view to another page view, or after the user exits the current page view and re-enters the current page view.After the initialization process is complete, the web view side binds the corresponding event listeners by adding event listeners to the document object (document.addEventListener) and calls the cross-platform communication method (sendToWeb) to establish a bidirectional communication mechanism between the dynamic container and the web view (e.g., AiPage), preparing for subsequent input event synchronization and command transmission. Continuing as shown in Figure 6, during the keyboard pull-up process, when the user clicks on the input area in the web view to trigger input, the web view side calls the interface (jsapi.invokeCabinInput.sendToCabin.showBeforeSetData) to pass the relevant data from the web view side (e.g., BizPage) to the dynamic container side before the native input box is displayed. Next, the web view side calls the display interface (jsapi.invokeCabinInput.show) to notify the dynamic container side to display the native input box. After successfully displaying the native input box, the dynamic container side sends a display success message to the web view side. After receiving the successful display message, the webpage view notifies the dynamic container to automatically request focus and bring up the system keyboard via the interface (jsapi.invokeCabinInput.sendToCabin.requestFocus). Simultaneously, the webpage view hides the existing placeholder input boxes to avoid visual overlap with the native input boxes. Continuing as shown in Figure 6, during the keyboard hiding process, when the dynamic container detects a user triggering a keyboard hiding operation (such as clicking the complete control or clicking other blank areas), it triggers the Cascading Style Sheets (CSS) animation effect for the system keyboard hiding. Subsequently, the dynamic container sends a keyboard hiding event (sendToWeb.onKeyboardHide) to the webpage view (e.g., AiPage) to notify it that the system keyboard has been hidden. The webpage view responds to this notification, redisplaying the previously hidden placeholder input boxes and restoring the original page layout. Continuing as shown in Figure 6, in the input content sending process, after the user finishes typing and clicks the send button, the dynamic container sends a message (sendToWeb.sendMessage) to the web view, synchronizing the text content in the native input box to the web view (BizPage). Subsequently, the dynamic container performs UI operations such as clearing the native input box and updating the button state. Finally, the dynamic container triggers the keyboard hiding process described above to hide the native input box and restore the display of the placeholder input box on the web view, thus completing a full input interaction loop. After sending, the user can continue to initiate new input interactions.If the system detects that the current environment does not support native input components or an anomaly occurs, it can automatically revert to the rendering mode of the webpage view to ensure the availability of normal input box functionality. This specification also provides a computer-readable non-transitory storage medium storing at least one set of instructions executable for input interaction on a mobile terminal. When the at least one set of instructions is executed by a processor, it instructs the processor to implement the steps of the mobile terminal input interaction method P300 of this specification. In some possible implementations, various aspects of this specification can also be implemented as a program product comprising program code. When the program product runs on the input interaction system 130 of the mobile terminal, the program code causes the input interaction system 130 of the mobile terminal to execute the steps of the method P300 described in this specification. The program product for implementing the above method can employ a portable compact disc read-only memory (CD-ROM) containing program code and can run on the input interaction system 130 of the mobile terminal. However, the program product described in this specification is not limited to this. In this specification (HK 30135241 A 16), a readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system. The program product can take any combination of one or more readable media. A readable medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. A computer-readable storage medium can include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium can also be any readable medium other than a readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.Program code for performing the operations described herein can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. Specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous. In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure may be presented by way of example only and may not be restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments of this specification. Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment," "an embodiment," or "an alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics may be suitably combined in one or more embodiments of this specification. It should be understood that in the foregoing description of embodiments of this specification, various features are combined in a single embodiment, drawing, or description therein for the purpose of simplifying the description and aiding in understanding a feature. However, this does not mean that such combinations of features are necessary, and those skilled in the art, upon reading this specification, may readily identify some of the devices as separate embodiments. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. And the content of each secondary embodiment is valid even if it contains fewer than all the features of a single foregoing disclosed embodiment. HK 30135241 A 17 Every patent, patent application, publication of a patent application, and other material such as articles, books, specifications, publications, documents, literature, etc. (excluding any historical examination documents associated with them) cited in this disclosure are incorporated herein by reference for all purposes relating to this disclosure, such as in the specification and claims of this disclosure.However, if there is any inconsistency or conflict between the descriptions, definitions, and / or terms used in the foregoing materials and those used in this disclosure, the descriptions, definitions, and / or terms used in this disclosure shall prevail. Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications. HK 30135241 A 1 Claim 1. An input interaction method for a mobile terminal, the method comprising: a webpage view side listening to a user's preset operation on a placeholder input box in the webpage view, activating a native input box in a dynamic container through a dynamic container side, triggering a system keyboard to pop up, and hiding the placeholder input box; the dynamic container side determining an adjustment instruction based on the position information of the native input box and the expected position of the system keyboard; the dynamic container side sending an adjustment notification to the webpage view side, the adjustment notification including: the adjustment instruction; and the webpage view side adjusting the page layout based on the adjustment instruction, so that the native input box and the system keyboard do not obscure each other. 2. The method according to claim 1, wherein the dynamic container side and the system keyboard run on a native thread, and the webpage view side runs on a webpage thread. 3. The method according to claim 1, wherein the webpage view side listens to a user's preset operation on a placeholder input box in the webpage view, activates a native input box in the dynamic container through the dynamic container side, triggers the system keyboard to pop up, and hides the placeholder input box, comprising: the event listener on the webpage view side listens to a user's preset operation on a placeholder input box in the webpage view, sends a first request through a first interface provided by the dynamic container side, the first request being used to request activation of the native input box in the dynamic container; the dynamic container side calls the native input component interface provided by the dynamic container side to activate the native input box, triggers the system keyboard to pop up, and instructs the webpage view side to hide the placeholder input box; and the webpage view side hides the placeholder input box.4. The method according to claim 3, wherein the dynamic container side calls the native input component interface provided by the dynamic container side to activate the native input box and trigger the system keyboard pop-up, comprising: the dynamic container side obtaining the configuration information of the native input box; the dynamic container side calling the native input component interface provided by the dynamic container side to create the native input box instance and initialize the native input box based on the configuration information; the dynamic container side making the native input box visible through the input method provided by the operating system and requesting input focus; and the dynamic container side triggering the system keyboard pop-up in response to the successful activation event of the native input box. 5. The method according to claim 4, wherein the configuration information includes one or more of the following: input box type, placeholder, keyboard type, border style, rounded corner radius, and shadow effect; the configuration information is stored in a remote server or local storage. 6. The method according to claim 3, wherein instructing the webpage view side to hide the placeholder input box includes: after activating the native input box, the dynamic container side sends a first message to the webpage view side through a predefined communication mechanism, the first message being used to instruct the webpage view side to hide the placeholder input box; or, after activating the native input box, the dynamic container side calls a first callback function, the first callback function being used to instruct the webpage view side to hide the placeholder input box. 7. The method according to claim 6, wherein hiding the placeholder input box on the webpage view side includes: the webpage view side modifies the Cascading Style Sheets (CSS) property of the placeholder input box or removes the placeholder input box from the Document Object Model (DOM). 8. The method according to claim 1, wherein the native input box is used to receive and display target data input by the user through the system keyboard; the method further includes: the dynamic container side listens to the user inputting target data in the native input box and synchronizes the target data to the webpage view side; and the webpage view side responds based on the target data. 9. The method according to claim 8, wherein the dynamic container side listens to the target data entered by the user in the native input box and synchronizes the target data to the web page view side, comprising: the dynamic container side capturing each keyboard input event of the user in the native input box, packaging the captured target data into a second message, and sending the second message to the web page view side through a predefined communication mechanism.10. The method of claim 8, wherein the response by the webpage view side based on the target data includes: the webpage view side parsing the target data and updating the display element associated with the placeholder input box in the webpage view side based on the parsing result to respond to user input. 11. The method of claim 1, further comprising: after the dynamic container side detects the user's keyboard collapse operation, hiding the system keyboard, hiding the native input box, and sending a keyboard collapse command to the webpage view side; and the webpage view side responding to the keyboard collapse command by redisplaying the placeholder input box. 12. The method of claim 11, wherein sending the keyboard collapse command to the webpage view side includes: the dynamic container side encapsulating the keyboard collapse command into a third message and sending the third message to the webpage view side through a predefined communication mechanism provided by the dynamic container side. 13. An input interaction system for a mobile terminal, comprising: at least one storage medium storing at least one instruction set for performing input interaction of the mobile terminal; and at least one processor communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and executes the method according to any one of claims 1-12 according to the instructions of the at least one instruction set.HK 30135241 A 1 Manual Appendix 130 100 Displaying Input Content on a Webpage View Mobile Terminal Input Interaction System Webpage View Side Dynamic Container Side Input Operation Figure 1 Figure 2 HK 30135241 A 2 The webpage view side listens to the user's preset operation on the placeholder input box in the webpage view, activates the native input box in the dynamic container through the dynamic container side, triggers the system keyboard to pop up, and hides the placeholder input box S310 P300 The dynamic container side determines the adjustment instruction based on the position information of the native input box and the expected position of the system keyboard S330 The dynamic container side sends an adjustment notification to the webpage view side, the adjustment notification including: Adjustment instruction S350 The webpage view side adjusts the page layout based on the adjustment instruction so that the native input box and the system keyboard do not obstruct each other S370 Figure 3 HK 30135241 A 3 The webpage view side and the dynamic container side trigger the keyboard pull-up process Start Creating the dynamic container Created successfully The configuration information of the native input box Created successfully Listened for the need to pull up the autofocus Figure 4 The webpage view side sends a third message to the dynamic container side, notifying the system that the keyboard has been triggered to hide. The user triggers the system keyboard to hide. The CSS animation of the system keyboard being collapsed is displayed. A placeholder input box is shown. (Figure 5: HK 30135241 A 4) The user enters the webpage view and triggers the keyboard to pull up. The process begins: Creating the dynamic container. The configuration information of the native input box is successfully created. The creation is successful. The listener detects that it needs to be pulled up. The autofocus initialization process is bound to the communication method between the dynamic container and the system capability. The system capability supports loading the dynamic container. Event binding is used. The keyboard pull-up process hides the placeholder input box. The system transmits relevant data and notifies the native input box to be displayed. The display is successful. The notification is sent to the dynamic container side. The autofocus is pulled up and the keyboard is hidden. The sending button is clicked. The content of the native input box is synchronized. The keyboard pull-up process is synchronized. The keyboard hide process is synchronized. The sending button is clicked. The user triggers the system keyboard to hide. The CSS animation of the system keyboard being collapsed is sent. A third message is sent to notify the system that the keyboard has been triggered to hide. A placeholder input box is displayed. The native input box is cleared. The button state is updated. The keyboard hide process is triggered. (Figure 6: HK 30135241 A)< / textinput>