Touch screen terminal operation button holding posture adaptive adaptation method, device and medium

Abstract

The application provides a touch screen terminal operation button holding posture adaptive adaptation method, device and medium, which is used for solving the technical problems of low automation degree and poor flexibility of interactive button adaptive adaptation. The method comprises the following steps: acquiring the frame pressure distribution data and the screen contact area data of a touch screen terminal to be processed; performing multi-dimensional state verification based on the frame pressure distribution data and the screen contact area data, and identifying a target holding mode; acquiring interface layout data of a currently running software, performing multi-level feature recognition based on the interface layout data, and determining core operation buttons of the currently running software; generating corresponding button arrangement control instructions according to the target holding mode and the core operation buttons; and dynamically adjusting screen display coordinates of the core operation buttons according to the button arrangement control instructions, and synchronously updating touch coordinate mapping relationships.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and provides a method, device and medium for adaptive adaptation of the grip posture of touch screen terminal operation buttons. Background Technology

[0002] With the development of mobile terminal technology, touch screen terminals equipped with large-size displays have become the mainstream in the market. Due to the large screen size of touch screen terminals, users often find it difficult to reach function buttons at the far end of the screen when operating with one hand. To improve the convenience of one-handed operation, existing one-handed operation adaptation solutions usually adopt a global screen shrinking mode, that is, the entire screen display is globally and proportionally shrunk and shifted to the lower left or right corner of the screen when manually triggered by the user; or, some application software provides a fixed left or right-biased static arrangement for certain operation buttons during the design.

[0003] However, the aforementioned adaptation solutions lack the ability to adaptively perceive the user's real-time physical holding posture and the specific interface structure of the currently running software. On the one hand, users often need to dynamically switch between left and right hand holding modes in actual use, and existing static layouts or manual screen shrinking solutions cannot automatically switch positions according to the user's holding state; on the other hand, the interface control attributes and core interaction button layouts of different applications vary greatly, resulting in low automation and poor flexibility in the adaptive adaptation of core interaction buttons when operating large-screen touch terminals with one hand. Summary of the Invention

[0004] This application provides a method, device, and medium for adaptive adaptation of the grip posture of operation buttons on a touch screen terminal, which solves the technical problem of low automation and poor flexibility in the adaptive adaptation of core interaction buttons when operating with one hand.

[0005] A method for adaptively adapting the grip posture of operation buttons on a touchscreen terminal includes: Acquire the edge pressure distribution data and screen contact area data of the touch screen terminal to be processed; Multi-dimensional state verification is performed based on the edge pressure distribution data and the screen contact area data to identify the target grip mode. Obtain the interface layout data of the currently running software, perform multi-level feature recognition based on the interface layout data, and determine the core operation buttons of the currently running software; Based on the target grip mode and the core operation buttons, generate corresponding button layout control commands; The screen display coordinates of the core operation buttons are dynamically adjusted according to the button layout control instructions, and the touch coordinate mapping relationship is updated synchronously.

[0006] A touchscreen terminal device includes a processor and a memory, the memory being used to store a computer program, and the processor executing the touchscreen terminal operation button grip posture adaptive adaptation method as described above when running the computer program.

[0007] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the aforementioned method for adaptively adapting the grip posture of touchscreen terminal operation buttons. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a flowchart illustrating a method for adaptively adapting the grip posture of touchscreen terminal operation buttons according to an embodiment of this application; Figure 2 This is a schematic diagram of the left / right hand grip and the corresponding sensor position in a method for adaptive adaptation of the grip posture of a touch screen terminal operation button in one embodiment of this application; Figure 3 This is a schematic diagram of a touch screen terminal operation button grip posture adaptive device according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a touch screen terminal device according to one embodiment of this application. Detailed Implementation

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

[0011] In one embodiment, such as Figure 1 As shown, this application provides a method for adaptively adapting the grip posture of touch screen terminal operation buttons, which can be used in a touch screen terminal operation button grip posture adaptive system, including the following steps: S101. Obtain the edge pressure distribution data and screen contact area data of the touch screen terminal to be processed; S102. Perform multi-dimensional state verification based on the edge pressure distribution data and the screen contact area data to identify the target grip mode; S103. Obtain the interface layout data of the currently running software, perform multi-level feature recognition based on the interface layout data, and determine the core operation buttons of the currently running software. S104. Generate corresponding button layout control instructions based on the target grip mode and the core operation buttons; S105. Dynamically adjust the screen display coordinates of the core operation buttons according to the button layout control command, and synchronously update the touch coordinate mapping relationship.

[0012] In practical mobile terminal usage scenarios, single-handed operation of large-screen touchscreen terminals (such as smartphones with an inch or larger screen) often leads to inconvenience and accidental touches due to the limited reach of the fingers. To address these shortcomings, in this embodiment, the system first acquires the edge pressure distribution data and screen contact area data of the touchscreen terminal to be processed. Specifically, the system needs to collect raw underlying hardware data representing the user's current physical grip posture in real time through the combined collaboration of multiple sensors. Among them, the edge pressure distribution data refers to the magnitude, direction, and spatial distribution characteristics of the force generated by the user's hand pressing on the physical edge of the touchscreen terminal. As an example, this edge pressure distribution data can be collected in real time at high frequency by a high-precision pressure sensor array (e.g., four equally spaced pressure sensors with a sampling frequency of 100Hz on each side) evenly distributed on the inner sides of the left and right frames of the touchscreen terminal. The screen contact area data refers to the coordinates and time characteristics of the physical area, contact length, and duration covered by the user's finger or palm edge on the screen edge or body surface. As an example, this data can be acquired through touch sensors distributed along the edges of the phone screen or capacitive touch sensors located on the back of the device, to help identify the user's physical grip posture. Through the combination of these multi-dimensional sensors, the system can accurately perceive the user's real-time physical force and contact state.

[0013] After acquiring the aforementioned basic multidimensional sensing data, the system executes step S102, performing multidimensional state verification based on the edge pressure distribution data and the screen contact area data to identify the target grip pattern. This multidimensional state verification aims to accurately transform the underlying physical sensing data into an understandable abstract grip intention state machine. It does not rely on the instantaneous threshold judgment of a single sensor changing over time, but rather on a process of deep fusion and joint verification of multi-source heterogeneous sensing data. Preferably, before performing state verification, to address noise interference from slight finger tremors or slight body shaking, the system can first use a Kalman filter algorithm to smooth and denoise the original pressure data, obtaining high-fidelity target pressure data. Next, the system performs multi-dimensional valid grip verification and accidental touch elimination. Specifically, it compares the target pressure data with personalized pressure thresholds (e.g., total pressure on both sides ≥ 5N and average pressure on at least one side ≥ 2N), and performs multiple interleaved comparisons of the screen contact area data with preset contact length boundaries (e.g., contact area length ≥ 5cm) and preset duration thresholds (e.g., stable duration ≥ 300ms). Only when all the above pressure, length, and time features pass the verification does the system determine the current detection state as a valid grip state, thereby accurately distinguishing between active user grip and invalid interference scenarios such as the phone being statically placed on a table, accidental touch in a pocket, or unintentional light touch with a single finger. In the valid grip state, the system further identifies the left-hand grip mode or right-hand grip mode as the final target grip mode based on the distribution difference of the target pressure data on the left and right sides of the touch screen terminal (e.g., when holding with the left hand, the average pressure value of the sensors on the left side is greater than that on the right side, and the pressure values ​​of the two sensors in the lower middle of the left side are the highest). This comprehensive verification mechanism fundamentally eliminates interference from environmental noise and non-active gripping operations, ensuring high accuracy of the sensor's automatic detection results.

[0014] After determining the user's current target grip mode, in order to provide targeted interface adaptation, the system executes step S103 to obtain the interface layout data of the currently running software. Based on the interface layout data, multi-level feature recognition is performed to determine the core operation buttons of the currently running software. Interface layout data refers to the structured metadata contained in the UI control tree structure, unique component identifiers, control attributes, and hierarchical topology relationships of the application currently running in the foreground during view rendering and display. Since the interface layouts of different applications, and even different business scenarios within the same application, vary greatly, the system constructs a multi-level feature recognition system from shallow to deep to accurately locate key interaction entry points. Specifically, this multi-level feature recognition may include a package name matching layer, a control feature layer, a semantic recognition layer, and a user learning layer. The system first obtains application identification information (such as package name) of the foreground software and matches it in a classification database to initially identify the core button types preset for this type of software (for example, when the package name of the system call application is matched, the core button types are identified as answer, hang up, mute, and hold). Next, it extracts control identifiers (such as unique resource IDs) and control attributes (such as Button type) from the interface layout data and matches the first operation control that meets the conditions in the feature library. For some non-standard interfaces or custom controls, the system can also extract text semantics through offline OCR image text recognition, calculate the semantic similarity between the text content and the core operation using a lightweight Chinese semantic matching model, and match a second operation control with a similarity ≥85%. In addition, it can obtain historical interaction operation frequency data and extract a third operation control that meets the high-frequency operation condition. Finally, the controls identified at these multiple levels are merged to confirm the core operation buttons of the current foreground software. This process enables the system to have the ability to accurately capture core controls applicable to all scenarios.

[0015] After accurately locating the core operation buttons, the system generates corresponding button layout control instructions based on the target grip mode and the core operation buttons. The system maps and associates the comfortable single-handed grip area corresponding to the target grip mode (e.g., the golden operating area within the same side's 1 / 3 width region where fingers can most easily operate when holding a large-screen phone with one hand, specifically located in the 40%-60% vertical range of the screen) with the characteristics of the core operation buttons, calculates reasonable rearrangement geometric parameters and transformation matrices, and then generates the corresponding button layout control instructions. Preferably, when generating these control instructions, the system also performs differentiated layout rule processing based on the attribute type of the currently running software (e.g., determining whether it is system-level software such as call or emergency call). If it is system-level software, a first layout control instruction is generated, limited to the same side's anti-mistouch area and with a relatively fixed order, to ensure the stability of muscle memory for high-risk safety operations; if it is third-party software, a second layout control instruction is generated, allowing the core buttons to rearrange themselves within the same side's display area, avoiding other controls, to accommodate the diverse adaptability of third-party interfaces.

[0016] Finally, the system dynamically adjusts the screen display coordinates of the core operation buttons according to the button layout control instructions, and synchronously updates the touch coordinate mapping relationship. This is the final execution output stage of the adaptive adaptation scheme. After receiving the button layout control instructions, the display driver chip or system graphics rendering engine of the touch screen terminal will trigger the coordinate adjustment process when it detects that the current interface is in a period of idle time without user touch operation, so as not to affect the user's normal continuous input. During the adjustment process, the system will modify the layout display coordinates of the core operation buttons in the current foreground interface in real time, and with the help of preset smooth attribute animation (the animation duration is fixed at ≤100ms), smoothly move the core operation buttons to the target comfortable display area on the physical screen, and maintain their display size greater than or equal to the preset minimum operable size threshold to avoid the buttons shrinking or becoming difficult to click due to the position adjustment. At the same time, in order to ensure the effectiveness of user interaction, the system must synchronously update the touch coordinate mapping relationship. The touch coordinate mapping relationship refers to the coordinate mapping transformation rules between the physical click coordinates collected by the touch panel hardware layer and the virtual control hot zone response range identified by the operating system application layer. When the visual display coordinates of the core operation buttons shift, the system must force a synchronous refresh of the underlying touch mapping relationship to ensure that the adjusted physical click position and the visual display position are absolutely geometrically aligned, ensuring that the actual area of ​​the button clicked by the user is completely consistent with the display area, thus completely avoiding touch offset misalignment issues.

[0017] In this embodiment, the system collects multi-source heterogeneous frame pressure and screen contact data in step S101, and performs comprehensive judgment using the multi-dimensional state verification rules in step S102. This multi-source hardware data fusion multi-dimensional verification mechanism can deeply filter out environmental noise and instantaneous interference from non-active operations, significantly improving the recognition accuracy of left and right hand grip modes. After accurately identifying the target grip posture, the system breaks through the barrier of traditional solutions being unable to perceive specific application interface content through the multi-level feature recognition system from shallow to deep in step S103, and achieves the locking of heterogeneous software core interaction buttons. Then, through the generation of control commands, dynamic adjustment of coordinates, and synchronous refresh of touch mapping relationships in steps S104 and S105, the core operation buttons that were originally located in the blind spot of the large screen or on the opposite side and were difficult to reach with one hand can be seamlessly and faithfully adaptively moved to the same side operation area most comfortable for the user's fingers in the form of smooth animation. It addresses common defects in one-handed interaction on 6.5-inch and larger mobile terminals, such as the inability to reach buttons with one hand due to fixed static button layout, high operation latency, and high accidental touch rate of adjacent function keys due to finger overextension. Without changing the original business code of the application, it significantly shortens the one-handed operation response time of core buttons in high-frequency scenarios such as calls, social networking, and payments (for example, the average operation time is reduced from 1.5 seconds to less than 0.3 seconds), reduces the accidental touch rate of one-handed operation to an extremely low level, and improves the system operation stability, human-computer interaction smoothness, and operational safety experience of touch screen terminal devices in complex and ever-changing handheld interaction environments.

[0018] In one embodiment, the step of performing multi-dimensional state verification based on the edge pressure distribution data and the screen contact area data to identify the target grip pattern includes: S1021. Perform data smoothing and noise reduction processing on the acquired border pressure distribution data to obtain target pressure data; S1022. Compare the target pressure data with the personalized pressure threshold, and compare the screen contact area data with the preset contact length boundary and the preset duration threshold. S1023. If the target pressure data is greater than or equal to the personalized pressure threshold, and the screen contact area data satisfies the preset contact length boundary and the preset duration threshold, then the current detection state is determined to be an effective grip state. S1024. In the effective grip state, based on the distribution difference of the target pressure data on both sides of the touch screen terminal, determine the left-hand grip mode or the right-hand grip mode as the target grip mode.

[0019] As a further refinement and technical development of the aforementioned button posture adaptive adaptation method, after obtaining the original border pressure distribution data and screen contact area data, the system will call a dedicated algorithm engine to perform a high-precision multi-dimensional state verification process. For example... Figure 2 As shown, in real-world applications, users often experience slight finger muscle tremors when operating a handheld touchscreen terminal. Furthermore, in dynamic physical environments such as while riding in a vehicle or walking, the shaking of the device can cause irregular, instantaneous mechanical impacts on the pressure sensors on both sides. These interferences result in the raw pressure data being directly acquired containing strong high-frequency fluctuation noise. If this is used directly as a basis for judgment, it will lead to high-frequency flickering and erroneous switching of the user interface. To eliminate these uncertainties, the system first performs data smoothing and denoising processing on the acquired frame pressure distribution data to obtain the target pressure data.

[0020] Specifically, the data smoothing and denoising process in step S1021 employs a Kalman filter algorithm specifically engineered and fine-tuned for the handheld force characteristics of mobile terminals. This algorithm does not rely on a large historical data cache during operation and can be streamed on the phone's main processor with extremely low memory usage and processing latency (e.g., single-frame data processing time is less than 1 millisecond, fully adaptable to a 100Hz sensor sampling frequency). In the specific mathematical space modeling, the system constructs: The state transition matrix A, a two-dimensional identity matrix, characterizes the continuous and gradual change in pressure on both sides of the hand during normal physical grip. The covariance matrix Q of the system process noise is preferably based on the power spectral density of slight finger tremors measured in the laboratory. Simultaneously, the observation matrix H can also be a two-dimensional identity matrix; the observation noise covariance matrix R of the hardware measurement noise is set according to the electrical manufacturing bias parameters of the pressure sensor. Within each sampling period, the processor dynamically calculates the optimal target pressure data for the current moment through a two-step closed-loop iteration of prediction and update using Kalman filtering.

[0021] After obtaining high-fidelity target pressure data, the system, in order to further eliminate interference from various complex scenarios involving non-active handheld operation, executes step S1022, comparing the target pressure data with a personalized pressure threshold, and comparing the screen contact area data with a preset contact length boundary and a preset duration threshold. The target pressure data physically includes the denoised average pressure values ​​on the left and right sides; while the personalized pressure threshold is a force reference boundary that is adaptively and dynamically learned and updated based on the physiological characteristics of different users (such as hand size and basic grip strength). As an example, the personalized pressure threshold can be initialized to a general default threshold upon first use, such as setting the total pressure on the left and right sides to be greater than or equal to 5N, and at least one side's average pressure value to be greater than or equal to 2N. The preset contact length boundary, in a physical geometric sense, refers to the minimum length of the continuous touch segment that the side of the palm or fingertip will inevitably generate on the touch sensor at the edge of the screen when a human hand holds a large-screen terminal. As an example, this contact length boundary can be preset to 5cm. The preset duration threshold is a hard filter window applied to state stability on the time axis. As an example, the duration threshold can be set to 300 milliseconds, but there is no specific limitation.

[0022] If the target pressure data is greater than or equal to the personalized pressure threshold, and the screen contact area data satisfies the preset contact length boundary and the preset duration threshold, then the current detection state is determined to be a valid grip state. In practical application scenarios, the system's internal state machine will only formally determine the current trigger state as a valid grip state when the above three hard constraints are simultaneously aligned. As a specific scenario example, when a user places their phone horizontally or vertically on a horizontal table and experiences brief pressure due to external compression, or when the phone is placed in the user's pocket or backpack and experiences large-area friction as the user walks, or when the user accidentally touches a small part of the screen edge with a single finger while extending their finger, in these invalid interference scenarios, although some sensor indicators may momentarily exceed the limits, the system will keenly detect that these signals cannot simultaneously meet the three hard thresholds of total pressure, 5cm contact length, and 300ms stable duration, and will directly discard these signals as invalid interference, perfectly protecting the purity of the state determination.

[0023] The system determines the target grip mode (left-hand or right-hand grip) based on the distribution difference of the target pressure data on both sides of the touchscreen terminal. This step utilizes the different anatomical force-applying characteristics of the left and right hands when holding a device with one hand to provide precise guidance for interface reconstruction. When a user holds a large-screen terminal with their left hand, the thenar eminence of the palm and the fingertips of the other four fingers exert a significant clamping force on the mid-frame. This results in the target pressure data collected by the pressure sensors distributed on the inner side of the left mid-frame being significantly greater than the pressure data on the right side. Furthermore, the highest global pressure peak is typically observed on the pressure sensors corresponding to the lower-middle area of ​​the left side (i.e., the core force application area of ​​the palm). By analyzing this distribution difference—significantly greater force on the left side and accompanied by a specific force center—the system can accurately determine with a high degree of certainty that the user is currently in a left-hand grip mode. Conversely, when the overall force amplitude on the right side is statistically significantly greater than that on the left, and the force center is located in the lower-middle right side, the system accurately determines that the user is currently in a right-hand grip mode. The determined target grip pattern will be immediately input as a global control variable to the subsequent layout control module.

[0024] In this embodiment, various complex non-handheld accidental touch scenarios that are very likely to occur in daily life, such as static pressure on the desktop, friction from bumps in the pocket, and occasional light touches by a single finger, can be natively isolated, reducing the false trigger rate of invalid scenarios to an absolute zero value; finally, through step S1024, the spatial asymmetric distribution law of pressure on both sides and the local maximum force characteristics are used to make a judgment in the effective grip state, thereby improving the overall recognition accuracy of the device for left and right handheld postures.

[0025] In one embodiment, the personalized stress threshold is constructed in the following manner: S1031. Extract the historical average pressure data under the pre-stored historical effective grip conditions; S1032. Based on the historical average pressure data and the preset default pressure threshold, a weighted calculation is performed to generate the updated personalized pressure threshold.

[0026] This embodiment refines the generation of personalized pressure thresholds, a core parameter for personalized adaptation of touchscreen terminals. Significant individual differences exist in hand size, physiological structure, and basic grip strength among different users. If the system uses a fixed, rigid pressure threshold throughout its lifecycle, it will inevitably lead to a two-way mismatch: users with smaller hands or lighter grips will struggle to reach a higher threshold and thus fail to trigger posture recognition, while users with larger hands or heavier grips are highly susceptible to excessive force, causing frequent false triggers.

[0027] First, the system extracts pre-stored historical average pressure data under effective grip conditions. During the initial activation or initialization phase of the touchscreen terminal, the system uses a widely applicable default threshold (e.g., a default threshold of 5N for total left and right pressure and 2N for single-side pressure) as the initial baseline to start the recognition module. In subsequent daily user interactions, the system continuously and silently records full-dimensional pressure data (including single-side frame force characteristics and mode selection results) for each successful trigger and determination of an "effective grip state" in the background, storing and persisting this data to the local storage module to form a dedicated user history dataset. When a preset update trigger condition is met, the system extracts effective operation data within a target time window (for example, extracting data from the user's last 7 days) from this historical dataset and calculates the historical average pressure data. Preferably, a weighted logic based on operation time decay can be introduced when calculating this average pressure data; that is, the more recent the operation data, the higher its weight in the average calculation, to accurately depict the user's recent grip force habits.

[0028] The system performs a weighted calculation based on the historical average pressure data and a preset default pressure threshold to generate an updated personalized pressure threshold. This is not merely a simple data overwrite process, but a smooth evolution process to prevent drastic threshold jumps caused by short-term abnormal grip strength (such as abnormal grip strength due to hand fatigue after lifting heavy objects). The system uses a weighted average algorithm to balance the user's historical real-world habits with the system's stable default rules. As a specific algorithm implementation, its core weighted calculation formula is as follows: Further preferably, to ensure the robustness of the adaptive learning algorithm under extreme boundary conditions, the system also sets strict anomaly constraint rules for the generated personalized pressure threshold. For example, the adaptive fluctuation range of the total pressure threshold is strictly limited to between 3N and 8N, and the single-sided pressure threshold is limited to between 1N and 4N. When the calculated weighted average overflows this safe range, the system will forcibly take the boundary value of this range for truncation, thereby ensuring that the detection range of the underlying hardware pressure sensor is not breached. Regarding the update timing, the system can be configured to automatically execute the above extraction and calculation steps during the idle period in the early morning of each day to replace the judgment threshold for the next day; or, when it is detected that the number of times the user manually intervenes to switch the grip mode in a short period of time (e.g., within a certain day) exceeds the set abnormal frequency (e.g., 5 times), the system will immediately trigger the threshold update mechanism to respond to and correct the current potentially mismatched threshold as quickly as possible, and quickly adapt to changes in the user's grip habits.

[0029] In this embodiment, the system extracts historical average pressure data representing users' real habits and uses a weighted calculation formula to fuse it with the default pressure threshold of a stable baseline. This dynamically learned adaptive parameter gradually replaces the rigid static configuration, giving the system the ability to actively track shifts in users' physiological habits. Furthermore, the system's default baseline and attenuation weights effectively buffer against the contamination impact of single abnormal data. This eliminates the perception blind spots caused by excessively high recognition thresholds due to differences in user hand size and grip strength, leading to missed judgments or false triggers due to overly sensitive recognition. This allows the underlying sensor response of large-screen touch terminals to achieve truly highly personalized adaptation for each individual. Simultaneously, the fully automatic background silent calculation and update mechanism eliminates the need for users to deal with complex parameter adjustments, greatly improving the generalization ability and accuracy of the system's underlying posture recognition module for various complex natural populations.

[0030] In one embodiment, the step of performing multi-level feature recognition based on the interface layout data to determine the core operation buttons of the currently running software includes: S1041. Obtain the application identification information of the currently running software, and match the core control of the positioning and calibration type in the classification library based on the application identification information; S1042. Extract the control identifier code and control attribute from the interface layout data, and match the first operation control that meets the conditions in the feature library based on the control identifier code and the control attribute. S1043. Perform image text recognition on the interface layout data to extract text semantics, and obtain the second operation control by semantic similarity calculation and matching. S1044. Obtain the historical interaction operation frequency data of the currently running software, and extract the third operation control that meets the operation frequency condition based on the historical interaction operation frequency data. S1045. Merge the core control of the calibration type, the first operation control, the second operation control, and the third operation control to confirm the core operation button.

[0031] The system acquires the application identifier information of the currently running software and matches and identifies the core controls of the specified type in the classification library based on this information. The application identifier information refers to the package name that uniquely represents a specific foreground application in the operating system. As an example, the system can capture the names of currently active foreground packages in real time through the underlying application management module (such as com.android.dialer for the system call application, com.tencent.mm for the WeChat application, or com.eg.android.AlipayGphone for the Alipay application). The classification library is a standardized software classification model dictionary that is pre-set within the system and supports dynamic expansion.

[0032] Preferably, this classification library divides all mobile applications into five high-frequency core categories: communication applications (such as system calls, SMS, emergency calls, and contacts), social interaction applications (such as social and content applications), payment and financial applications (such as payment and wealth management applications), utility system applications (such as system settings, file management, browsers, and calculators), and photography and imaging applications (such as system camera, photo album, and photo editing applications), with no specific limitations. The system performs hash matching between the captured application identifier information and this classification library. Once a match is successful, the core controls of the corresponding preset label type for that type of software can be directly locked. As a specific scenario example, when the package name of a system call application is matched, the core control type is initially locked as "answer, hang up, mute, hold, call back, emergency call, send" at a macro level; while when a payment and financial application is matched, it is initially locked as "confirm payment, pay, next step, cancel, complete, verify". This level, as the first macro package name matching layer, completes the initial positioning of the software business scenario.

[0033] Next, the system extracts the control identifiers and attributes from the interface layout data, and matches the first operational control that meets the conditions in the feature library based on the control identifiers and attributes. This step, as the second layer of control features, delves into the micro-level of code and view topology. As a preferred implementation, without disrupting the software runtime sandbox, the system sends requests to the operating system's view rendering engine through an accessibility service framework (such as AccessibilityService in Android or UIKit in iOS) to traverse the entire view tree hierarchy currently in the foreground interface in real time. The extracted "control identifier" is physically defined as a unique resource ID assigned to a UI component during the development and compilation phase. For example, the unique resource ID for the Android system's call hang-up button is com.android.dialer:id / end_call_button, and the unique resource ID for the WeChat send button is com.tencent.mm:id / send_btn. The extracted "control attributes" include the control's hard type attributes (such as a standard Button control, an ImageButton control, or a custom click component with a clickable listener attribute) as well as geometric spatial information such as the current screen's absolute coordinates and boundary dimensions. The system inputs these extracted micro-metadata into a pre-set core button feature library for precise string and type matching. If a control's resource ID substring or text feature completely matches the preset hard rules in the feature library, it is marked as the first operation control that meets the conditions. This layer greatly ensures the fast recognition efficiency for standard native interfaces.

[0034] To further cope with more tricky custom non-standard interfaces, the system simultaneously performs image text recognition on the interface layout data to extract text semantics, and obtains a second operation control through semantic similarity calculation and matching. This step serves as the third semantic recognition layer, which is specifically used to solve the code blind area where accessibility services cannot extract valid standard control IDs caused by third-party developers using special non-standard custom control drawing (Custom View), web hybrid development (H25 / Hybrid) or game engine rendering. Preferably, in order to maintain the feasibility of this function in extreme safety production or emergency communication environments where external network connections are completely cut off, the system deploys a set of offline image text recognition (OCR) and semantic matching models. When an interface refresh is detected, the lightweight mobile OCR model (for example, a Paddle OCR mobile model with a model size smaller than 10MB, and the recognition time for a single interface image is less than 50 milliseconds) performs localized offline text recognition on the current button view area or the full screen, and accurately extracts the character text displayed on the surface of the button control (supporting mixed recognition of Chinese, English and numbers, with a recognition accuracy of no less than 98%). Subsequently, the system invokes a 300-dimensional Word2Vec lightweight word vector model fine-tuned and trained based on specific mobile phone operation scenario corpora (such as 1 million pieces of daily mobile phone interaction semantic corpora), converts the extracted character text into a hidden layer space vector, and performs cosine similarity formula calculation in the mathematical vector space with the core operation keyword library built in the system (for example, Chinese contains 32 words such as "answer, hang up, confirm, send, pay, cancel, save, delete", and English contains 28 words such as "OK, Confirm, Send, Pay, Cancel, Delete"). If the calculated cosine similarity score is greater than or equal to the preset hard threshold of 85%, even if the button lacks a correct resource ID due to non-standard design, the system will still determine that it represents a core operation based on high-confidence text semantics, and mark it as the second operation control, so as to implement targeted supplementation for the non-standard components not covered by the aforementioned feature layer. For some non-standard pure icon (Icon) buttons with no text at all, the system can also reuse the joint analysis of icon geometric feature matching and click event flow attributes as a fallback solution for semantic recognition.

[0035] Furthermore, to cater to the unique long-tail operational preferences of different individuals, the system acquires historical interaction frequency data of the currently running software and extracts third operational controls that meet the frequency criteria based on this data. This step, as the fourth user learning layer, continuously tracks and structurally records the user's historical click behavior within a specific foreground software within an independent, secure logical partition on the system's local machine. As a preferred adaptive learning rule, the system counts the click frequency of each interactive component within a single application within a specific time window. If it detects that a user has clicked a non-core button in a specific location more than three times consecutively, or that the button's total click frequency ranks among the top three of all controls in the application, the system automatically extracts and marks the personalized component that meets the frequency criteria as the third operational control, thus perfectly supplementing user-specific high-frequency personalized operation scenarios not pre-defined by the system.

[0036] Finally, the system merges and confirms the core control of the specified type, the first operation control, the second operation control, and the third operation control as the core operation button. In the specific fusion decision, the system performs a mathematical union fusion and deduplication calculation on the candidate control sets output from the four independent levels, constructing a final, unique physical list of core operation buttons containing the current screen's absolute coordinates and geometric dimensions. Preferably, when executing the final fusion confirmation, the user's manual marking or canceling of the core button via click on the system settings interface or interactive card has the highest logical priority, directly forcibly overriding and correcting any candidate results automatically identified by the system. To prevent the core button from deforming during subsequent interface optimization and reconstruction, in system pop-up AI interface optimization or node merging scenarios, the final fused and confirmed core operation button is used as an absolute termination interception condition for the physical merging of interface elements, prohibiting the core button from merging with other unrelated secondary controls in the underlying code tree. This ensures the independent operability of the core operation button from a spatial topology perspective, avoiding button position shifts or shrinkage of the click response area after merging.

[0037] In this embodiment, the system abandons the crude approach of traditional technologies that rely solely on a single rule or fixed coordinate scaling. Without requiring any code refactoring or seamless optimization by application vendors, it achieves targeted locking capabilities for controls in a vast array of mobile applications spanning various sectors such as calling, social networking, payment, tools, and video. A breakthrough has been achieved in the overall recognition accuracy for both mainstream and non-standard third-party applications. It eliminates the security risks of button disappearance, overlapping functions, or operational malfunctions caused by control parsing failures, and establishes a solid, fault-tolerant, and debug-free high-reliability data foundation for subsequent adaptive rearrangement commands and secure translation of touch coordinates.

[0038] In one embodiment, generating corresponding button layout control instructions based on the target grip mode and the core operation buttons includes: Obtain the attribute type of the currently running software and determine whether the attribute type is system-level software; If the attribute type is system-level software, a first layout control instruction is generated as the button layout control instruction. The first layout control instruction is used to restrict the core operation button to the anti-accidental touch area on the same side corresponding to the target grip mode, and to keep the relative order of the buttons fixed. If the attribute type is not system-level software, a second layout control instruction is generated as the button layout control instruction. The second layout control instruction allows the core operation button to be rearranged within the same side display area corresponding to the target grip mode, avoiding other controls.

[0039] After completing the hand grip perception and core button locking, the system needs to proceed to the deployment decision-making and command issuance phase. In the actual mobile terminal software ecosystem, different software has fundamentally different requirements for operational security and interface flexibility. For example, system functions such as calls and emergency calls directly relate to users' communication security and personal safety, with extremely low tolerance for error; while third-party applications such as social networking and entertainment have complex and diverse interfaces, placing greater emphasis on interface adaptation and compatibility. To resolve this contradiction, the system introduces a differentiated adaptation engine, which first obtains the attribute type of the currently running software and determines whether the attribute type is system-level software.

[0040] In this process, attribute type is represented at the system level as the application's permission identifier and source characteristics. System-level software refers to core applications that are pre-installed on the touchscreen terminal, cannot be uninstalled, and have underlying system permissions. Examples include system calls, SMS, emergency call modules, or system settings. Conversely, applications whose attribute type is not system-level software refer to third-party applications downloaded and installed by the user from the app store, such as various third-party WeChat social networking, Alipay payment, or short video entertainment software. The system calls the operating system's package manager or permission control center to retrieve and determine in real time whether the foreground application belongs to system-level software, using this as a hard distribution routing condition for subsequent deployment strategies.

[0041] If the attribute type is system-level software, a first layout control instruction is generated as the button layout control instruction. This first layout control instruction restricts the core operation buttons to the same-side anti-mistouch area corresponding to the target grip mode, while maintaining a fixed relative button order. At the physical and execution level, the first layout control instruction is a UI redraw safety control protocol with the highest system rendering priority and strict geometric boundary locking. The same-side anti-mistouch area refers to an absolutely safe, isolated bounding box defined at the visual rendering level (e.g., forcibly limited to 1 / 3 of the screen width on the same side of the target gripping hand, and the minimum physical size of the button cannot be compressed, such as forcibly maintaining 8mm×8mm or more, with adjacent button spacing greater than or equal to 3mm). The system relies on this instruction to forcibly converge the extracted system software core operation buttons (such as the "emergency call" or "hang up" button) into this area. Simultaneously, maintaining a fixed relative button order means that regardless of how the interface is panned or adjusted, the vertical or horizontal arrangement topology within the button group is completely locked; for example, the hang up button is always directly above the mute button. The core operations of system-level software directly affect the user's personal or communication safety. Strictly fixed areas and sequences can help the human finger muscles form extremely stable muscle memory. In case of emergency or panic, users do not need to think twice to find the button. They can achieve fast and accurate clicks with their eyes closed simply by relying on muscle instinct, completely avoiding fatal mis-touches and operation delays caused by position jumps or size reductions.

[0042] Conversely, if the attribute type is not system-level software, a second layout control instruction is generated as the button layout control instruction. This second layout control instruction allows the core operation button to be rearranged within the same side display area corresponding to the target grip mode, avoiding other controls. The second layout control instruction is a highly flexible and adaptive layout protocol in its rendering logic. The same side display area also refers to the comfortable reach range on the user's grip side (such as the left or right 1 / 3 area of ​​the screen). Avoiding other controls for rearrangement means that when the system moves the core operation button (such as the "Confirm Payment" button in a third-party payment application or the "Send" button in a social application) to the same side display area, it reads in real-time the original cluttered or varied background UI tree structure of the third-party application (such as floating windows, complex chat bubbles, or video progress bars). Once it is calculated that the core button will physically overlap with the original controls of the third-party application after translation, the second layout control instruction drives the core operation button to make elastic fine-tuning adjustments vertically or horizontally within the basic range to find the most suitable insertion gap. The principle behind this flexible layout mechanism is that the interface layouts of third-party applications vary greatly and are not controlled by system vendors. If rigid and fixed layout rules are used, core buttons may easily obscure the key content areas of the third-party software. By giving them the ability to adapt to avoid and rearrange, visual harmony and touch accessibility can be maximized, and the overall adaptability and flexibility of the interface can be improved.

[0043] This embodiment resolves the security and compatibility conflict in cross-application adaptive layout. On the one hand, it builds an absolutely solid operational defense for high-frequency, high-risk lifecycle scenarios such as calls and emergency calls, allowing users to achieve zero-latency, zero-accidental-touch ultra-fast interaction through muscle memory, thus ensuring the bottom line of communication security. On the other hand, it empowers a massive number of third-party applications with extremely flexible and non-obstructive adaptation capabilities to avoid and adapt to the original UI elements, maximizing operational convenience while maintaining the visual integrity of the interface, and achieving secure and flexible dual-dimensional adaptive coverage of large-screen terminals across all scenarios inside and outside the system.

[0044] In one embodiment, this application provides a method for adaptively adapting the grip posture of touch screen terminal operation buttons. The step of generating corresponding button layout control instructions based on the target grip mode and the core operation buttons further includes the following steps: S1061. Obtain the historical click coordinate set for the core operation button, and calculate the center coordinates of the corresponding click hotspot based on the historical click coordinate set; S1062. Calculate the spatial offset between the current center coordinates of the core operation button and the center coordinates of the click hotspot; S1063. Generate position fine-tuning parameters based on the spatial offset; S1064. Obtain the physical screen size parameters of the touch screen terminal, and calculate the width parameters of the layout area based on the physical screen size parameters; S1065. The position fine-tuning parameter and the layout area width parameter are incorporated into the button layout control command.

[0045] Different users have vastly different finger lengths and varying habits when holding a phone vertically. This means that even if buttons are moved to the same side, some users may still find them difficult to reach at the same vertical height. Furthermore, the physical dimensions of large-screen touchscreen devices on the market vary greatly (e.g., from 6.5 inches to 7.2 inches), and a static, fixed width ratio (e.g., rigidly fixed at 1 / 3 of the screen width) cannot perfectly fit all models. Therefore, the system first initiates dynamic tracking based on the individual physiological characteristics of each user.

[0046] The system acquires a historical set of click coordinates for the core operation button and calculates the corresponding center coordinates of the click hotspot based on this set. At the data flow level, the system silently records the absolute touch coordinates of the screen each time the user successfully triggers the core operation button in the background. As the number of operations accumulates, these scattered coordinate points form a historical click coordinate set on a two-dimensional plane. The system preferably uses a Gaussian kernel density estimation algorithm to fit the probability density function to this coordinate set. Through kernel function smoothing, the system can accurately extract the probability density peak point from the discrete coordinate point cloud; this peak point is defined as the center coordinate of the click hotspot. This center coordinate accurately depicts the optimal striking point position where the user's finger is most natural and without muscle strain under the current grip posture.

[0047] The system calculates the spatial offset between the current center coordinates of the core operation button and the center coordinates of the click hotspot, and generates position fine-tuning parameters based on the spatial offset. The system calculates the vector difference (mainly the vertical Y-axis offset) between the button center rendered in the current UI and the user's actual habitual click point using geometric vector subtraction. Based on this spatial offset, the system generates corresponding position fine-tuning parameters. Preferably, to prevent drastic button position fluctuations that could cause visual discomfort to the user, the system imposes strict physical displacement constraints on these position fine-tuning parameters: the maximum offset of a single fine-tuning adjustment is limited to no more than 2% of the physical screen height; furthermore, the execution timing of these fine-tuning parameters is strictly limited to idle intervals when no user interaction is detected on the interface, ensuring zero visual interference for the user throughout the adjustment process. In addition, as a sensitivity triggering rule, when the system detects that the user's clicks are all within the edge area of ​​the current core operation button for more than three consecutive times, it immediately triggers the generation and distribution of these position fine-tuning parameters to adapt to and correct the current coordinate mismatch as quickly as possible.

[0048] After generating the vertical fine-tuning parameters for the user, the system executes step S1064 to obtain the physical screen size parameters of the touchscreen terminal and calculate the width parameters of the layout area based on these parameters. This step is to address the issue of lateral touch rate attenuation caused by different terminal hardware sizes. The physical screen size parameters are typically represented at the hardware level as the physical length of the screen diagonal (in inches). The system internally uses a non-linear size adaptive calculation engine, whose core calculation formula is as follows: The physical and ergonomic logic behind this formula is that the larger the screen size, the smaller the proportion of the thumb's absolute physiological coverage area relative to the entire screen when the user holds it with one hand. Therefore, the system adaptively calculates and appropriately increases the width ratio of the layout area on larger devices. For example, according to the built-in all-scenario parameter configuration table, when the terminal is 6.5 inches, the calculated layout width ratio is 30% (i.e., one-third of the screen width); while when the terminal size reaches 7.2 inches, the layout width ratio will adaptively expand to 31.4%.

[0049] Finally, the position fine-tuning parameters and the layout area width parameters are incorporated into the button layout control instruction. Through this packaged injection operation, when the underlying UI rendering engine parses the instruction, it can not only send the core buttons to the same side, but also use the layout area width parameters to finely define the absolute boundaries of the horizontal containers, and use the position fine-tuning parameters to perform pixel-level precise correction on the vertical axis.

[0050] This embodiment eliminates the adaptation blind spots and operational constraints caused by varying finger lengths and terminal screen sizes (ranging from 6.5 inches to 7.2 inches). Whether a user with smaller hands is using an extra-large screen terminal, or there is a short-term shift in operating habits, the system can achieve precise and personalized fit for each user without any manual dragging or setting (zero learning cost), greatly improving the ultimate comfort and personalized response accuracy of large-screen interactive operations.

[0051] In one embodiment, this application provides a method for adaptively adjusting the grip posture of touch screen terminal operation buttons, wherein the step of dynamically adjusting the screen display coordinates of the core operation buttons according to the button layout control command includes: S1071. When the current interface is detected to be in a period of inactivity without user touch operation, the coordinate adjustment process is triggered. S1072. During the coordinate adjustment process, the display size of the core operation button is maintained to be greater than or equal to the preset minimum operable size threshold.

[0052] In real-world dynamic operation scenarios, if the system forcibly changes the position of core operation buttons when the user is about to click or their finger is sliding on the screen, it will directly cause the user's expected landing point to miss or accidentally touch other controls. To completely avoid this timing conflict, the system executes step S1071, which triggers the coordinate adjustment process when it detects that the current interface is in a free interval without user touch operation.

[0053] Specifically, at the system's underlying physical level, a "free interval without user touch operation" is defined as the touch-screen terminal's touch driver panel not reporting any valid physical contact events (such as press, move, or long press events) to the operating system within the current time frame. The system's underlying layer continuously polls the screen state using a touch event listener. When the system receives a mode switching or layout adjustment signal, it first checks whether the screen is currently being touched. If the user's finger is touching the screen (e.g., scrolling through content), the system temporarily stores the coordinate switching operation in a background execution queue, entering a silent waiting state. Once the system detects the user's finger lifting off the screen, it accurately captures the so-called operation free interval, and the system's underlying graphics rendering engine immediately wakes up the queue, formally triggering the coordinate adjustment process. As a preferred implementation, this coordinate adjustment process is not a sudden, abrupt flash, but rather uses system-level attribute animation to achieve a smooth transition in position, with the animation duration strictly limited to less than or equal to 100ms. This smooth displacement within an extremely short time ensures visual continuity while preventing screen flickering or stuttering, and completely avoids interrupting or interfering with the user's subsequent continuous operation rhythm.

[0054] Meanwhile, to prevent buttons from being over-compressed during complex interface rearrangement, the system simultaneously executes step S1072, maintaining the display size of the core operation button greater than or equal to a preset minimum operable size threshold during the coordinate adjustment process. In the UI redrawing logic, when the core operation button is forcibly moved to the same side of the display area, the system's native layout algorithm easily sacrifices component size to gain layout space in order to avoid other existing controls. However, the core operation button is a crucial entry point for users to perform high-frequency, high-risk interactions; if its size is too small, it will exceed the physical touch accuracy limit of human fingertips. Therefore, the preset minimum operable size threshold is set as a rigid lower limit for component rendering size in engineering, representing the minimum physical area that ensures comfortable and accurate clicking by human fingers.

[0055] As an example, the system assigns different rigid constraint parameters based on the different attributes of the software: For system-level software (such as call answering / hanging up, emergency call applications), since its operation is directly related to communication and personal safety, the system sets its minimum operable size threshold to be no less than 8mm × 8mm, and prohibits any form of code-level scaling and compression when reconstructing coordinates; while for third-party software, in order to ensure basic click accuracy while taking into account interface aesthetics and avoidance flexibility, its minimum operable size threshold can be set to 6mm × 6mm. When executing dynamic layout instructions to redraw the interface topology tree, once the system calculates that the remaining space at the target position cannot accommodate the minimum operable size threshold, the rendering engine will trigger an anti-overlap alarm, prioritizing displacement rather than scaling to find new gaps, thereby firmly protecting the clickable physical boundary of the button.

[0056] This embodiment eliminates ghost touches or accidental touches caused by sudden changes in button coordinates during dynamic layout, ensuring seamless and imperceptible dynamic switching. Simultaneously, it adheres to the minimum physical click area of ​​components, ensuring that the adjusted core buttons maintain extremely high blind click accuracy in any extreme avoidance scenario. Throughout the entire process, while ensuring the interface's adaptive flexibility, it achieves an absolute balance between smooth user visual experience and high touch interaction success rate.

[0057] In one embodiment, this application provides a method for adaptive adaptation of the grip posture of touch screen terminal operation buttons. After dynamically adjusting the screen display coordinates of the core operation buttons according to the button layout control command, the method further includes: S1081. Calculate the switching frequency of the target grip mode within a set time window; S1082. If the switching frequency is greater than or equal to the set first frequency threshold, then the preset duration threshold is lowered. S1083. If the switching frequency is less than the set second frequency threshold, then the preset duration threshold is increased.

[0058] As a further refinement of the aforementioned posture adaptive adaptation solution, after completing the dynamic arrangement of the core buttons, to better meet the personalized needs of different users regarding the sensitivity of grip switching, the system introduces a mode switching sensitivity adaptive tracking and adjustment mechanism. In actual large-screen terminal interaction scenarios, different users exhibit significantly polarized usage habits: some users are accustomed to frequently switching between their left and right hands in complex environments, requiring the system to have extremely high and sensitive switching response speeds; while other users consistently use only one hand (such as the right hand), and these users are extremely averse to unexpected changes in the arrangement position, requiring a lower probability of accidental triggering. If the system always adopts an unchanging judgment sensitivity, it will inevitably be unable to simultaneously meet the experience requirements of both groups.

[0059] To this end, the system first executes step S1081 to count the switching frequency of the target grip mode within a set time window. Specifically, the system continuously tracks and records the absolute number of events in the underlying control logic sandbox where the user effectively switches between grip states (i.e., from left-hand mode to right-hand mode, or vice versa). The set time window is used to define the time span for the statistics; as an example, it can be set to a daily cycle of the past 3 days. The system uses the total number of switches within this time window divided by the number of days to calculate the average daily switching frequency parameter, which accurately digitizes the user's recent left-hand / right-hand alternation activity.

[0060] If the switching frequency is greater than or equal to a set first frequency threshold, the preset duration threshold is lowered. This first frequency threshold is a mathematical threshold used by the system to define a group of active users who frequently switch. As a preferred configuration, this first frequency threshold can be set to 5 times / day. When the recent switching frequency calculated by the system reaches or exceeds this threshold, the current user is determined to be an active user who frequently switches. At this time, in order to comprehensively improve the system's responsiveness, the system will send a parameter modification instruction to the underlying state machine to lower the aforementioned preset duration threshold used for multi-dimensional state verification (for example, lowering it from the default hard threshold of 300 milliseconds to 200 milliseconds). Lowering this time verification window means that after the underlying sensor detects a reversal in the bilateral pressure distribution, it only needs to maintain a very short 200-millisecond stabilization period to trigger the UI rearrangement, thereby significantly eliminating the user's sense of waiting and accelerating the response speed of layout switching.

[0061] Conversely, if the switching frequency is less than the set second frequency threshold, the preset duration threshold is increased. This second frequency threshold is a threshold used by the system to define users with a fixed one-handed grip habit. As a preferred configuration, this second frequency threshold can be set to 1 time / day. When the switching frequency calculated by the system is lower than this low-activity threshold, it is determined that the current user basically does not switch hands. To prevent unnecessary arrangement jitter caused by slight deformation of the grip posture (such as a brief shift in the center of gravity of the palm) due to muscle fatigue during prolonged one-handed operation, the system will increase the preset duration threshold (e.g., from the default 300 milliseconds to 500 milliseconds). By extending the verification time filtering window, the system is forced to require the pressure reversal feature to last for at least half a second before recognition, greatly enhancing the system's tolerance to instantaneous mechanical environmental changes and local pressure fluctuations. For switching frequencies between the above two (e.g., 1 to 5 times / day), the system maintains the default parameters unchanged.

[0062] More preferably, in order to absolutely respect the user's active control intention in adaptive adjustment, if the system detects that the user actively initiates a manual mode switching command through the operating system's settings menu or quick control center, the system will forcibly suspend at the software level and prohibit triggering any automatic switching and adjustment mechanism based on the above frequency calculation within the next preset time buffer period (e.g., 2 minutes). This completely avoids the user's preferred arrangement that has just been manually set being instantly overwritten and tampered with by the underlying automatic rules, ensuring the smoothness and rationality of human-computer interaction logic.

[0063] In this embodiment, users accustomed to frequent alternation of use of both hands can enjoy a seamless and responsive ultra-fast switching action (e.g., reducing layout reconstruction latency to the 200ms level), greatly improving the smoothness of dynamic interaction. Simultaneously, it provides users accustomed to fixed one-handed operation with a robust anti-interference defense, reducing the rate of incorrect layout switching caused by minor adjustments to hand grip or hand fatigue to an extremely low level. The entire adaptive sensitivity adjustment loop runs silently in the background, eliminating the need for users to navigate complex parameter tuning pages, achieving ultimate inclusiveness and a balanced experience across diverse and complex user habits with zero learning cost.

[0064] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0065] In one embodiment, such as Figure 3 As shown, a touchscreen terminal operation button grip posture adaptive device is provided, including: The data acquisition module 310 is used to acquire the edge pressure distribution data and screen contact area data of the touch screen terminal to be processed. The pattern recognition module 320 is used to perform multi-dimensional state verification based on the edge pressure distribution data and the screen contact area data to identify the target grip pattern. Button determination module 330 is used to acquire the interface layout data of the currently running software, perform multi-level feature recognition based on the interface layout data, and determine the core operation buttons of the currently running software. The instruction generation module 340 is used to generate corresponding button layout control instructions based on the target grip mode and the core operation buttons; The coordinate adjustment module 350 is used to dynamically adjust the screen display coordinates of the core operation buttons according to the button layout control command, and synchronously update the touch coordinate mapping relationship.

[0066] In one embodiment, such as Figure 4As shown, a touch screen terminal device is provided, wherein the processor of the touch screen terminal device is used to provide computing and control capabilities, the touch screen terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the steps of a touch screen terminal operation button grip posture adaptive adaptation method as described in any of the preceding claims.

[0067] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the above-described method for adaptively adapting the grip posture of a touchscreen terminal operation button.

[0068] The details regarding the equipment and media can be found in the description of the aforementioned method embodiments, and will not be repeated here.

[0069] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Furthermore, any references to memory, storage, user databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory.

[0070] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0071] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for adaptively adapting the grip posture of operation buttons on a touchscreen terminal, characterized in that, include: Acquire the edge pressure distribution data and screen contact area data of the touch screen terminal to be processed; Multi-dimensional state verification is performed based on the edge pressure distribution data and the screen contact area data to identify the target grip mode. Obtain the interface layout data of the currently running software, perform multi-level feature recognition based on the interface layout data, and determine the core operation buttons of the currently running software; Based on the target grip mode and the core operation buttons, generate corresponding button layout control commands; The screen display coordinates of the core operation buttons are dynamically adjusted according to the button layout control instructions, and the touch coordinate mapping relationship is updated synchronously.

2. The method according to claim 1, characterized in that, The step of performing multi-dimensional state verification based on the edge pressure distribution data and the screen contact area data to identify the target grip pattern includes: The acquired border pressure distribution data is subjected to data smoothing and noise reduction processing to obtain target pressure data; The target pressure data is compared with a personalized pressure threshold, and the screen contact area data is compared with a preset contact length boundary and a preset duration threshold. If the target pressure data is greater than or equal to the personalized pressure threshold, and the screen contact area data satisfies the preset contact length boundary and the preset duration threshold, then the current detection state is determined to be an effective grip state. In the effective grip state, based on the difference in the distribution of the target pressure data on both sides of the touch screen terminal, the left-hand grip mode or the right-hand grip mode is determined as the target grip mode.

3. The method according to claim 2, characterized in that, The personalized stress threshold is constructed in the following way: Extract the historical average pressure data under pre-stored historical effective grip conditions; The updated personalized pressure threshold is generated by weighting the historical average pressure data and the preset default pressure threshold.

4. The method according to claim 1, characterized in that, The step of performing multi-level feature recognition based on the interface layout data to determine the core operation buttons of the currently running software includes: Obtain the application identification information of the currently running software, and match the core control of the positioning and calibration type in the classification library based on the application identification information; Extract the control identifier and control attributes from the interface layout data, and match the first operation control that meets the conditions in the feature library based on the control identifier and control attributes; The interface layout data is subjected to image text recognition to extract text semantics, and the second operation control is obtained by semantic similarity calculation and matching. Obtain historical interaction frequency data of the currently running software, and extract third operation controls that meet the operation frequency conditions based on the historical interaction frequency data; The core control of the specified type, the first operation control, the second operation control, and the third operation control are merged and confirmed as the core operation button.

5. The method according to claim 1, characterized in that, The step of generating corresponding button layout control commands based on the target grip mode and the core operation buttons includes: Obtain the attribute type of the currently running software and determine whether the attribute type is system-level software; If the attribute type is system-level software, a first layout control instruction is generated as the button layout control instruction. The first layout control instruction is used to restrict the core operation button to the anti-accidental touch area on the same side corresponding to the target grip mode, and to keep the relative order of the buttons fixed. If the attribute type is not system-level software, a second layout control instruction is generated as the button layout control instruction. The second layout control instruction allows the core operation button to be rearranged within the same side display area corresponding to the target grip mode, avoiding other controls.

6. The method according to claim 1, characterized in that, The step of generating corresponding button layout control commands based on the target grip mode and the core operation buttons also includes: Obtain the historical click coordinate set for the core operation button, and calculate the center coordinates of the corresponding click hotspot based on the historical click coordinate set; Calculate the spatial offset between the current center coordinates of the core operation button and the center coordinates of the clicked hotspot; Position fine-tuning parameters are generated based on the spatial offset; Obtain the physical screen size parameters of the touch screen terminal, and calculate the width parameters of the layout area based on the physical screen size parameters; The position fine-tuning parameter and the layout area width parameter are incorporated into the button layout control command.

7. The method according to claim 1, characterized in that, The step of dynamically adjusting the screen display coordinates of the core operation buttons according to the button layout control command includes: When the current interface is detected to be in a period of inactivity without user touch operation, the coordinate adjustment process is triggered. During the coordinate adjustment process, the display size of the core operation button is maintained to be greater than or equal to the preset minimum operable size threshold.

8. The method according to claim 2, characterized in that, After dynamically adjusting the screen display coordinates of the core operation buttons according to the button layout control command, the method further includes: The frequency of switching of the target grip mode within a set time window is statistically analyzed; If the switching frequency is greater than or equal to the set first frequency threshold, then the preset duration threshold is lowered. If the switching frequency is less than the set second frequency threshold, then the preset duration threshold is increased.

9. A touchscreen terminal device, comprising a processor and a memory, wherein the memory is used to store computer programs, characterized in that, When the processor runs the computer program, it executes the touch screen terminal operation button grip posture adaptive adaptation method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the touch screen terminal operation button grip posture adaptive adaptation method as described in any one of claims 1 to 8.

Images