Cloud mobile phone client system adaptive to native-level multi-terminal experience and adaptive method

Abstract

The invention discloses a cloud mobile phone client system for realizing native-level multi-end experience adaptation and an adaptation method, the system takes end-cloud collaboration as a core architecture, and consists of a client adaptation engine deployed at a user terminal and a configuration management server at a cloud end; and the client adaptation engine and the configuration management server establish data interaction through an encrypted communication link to form a complete data flow closed loop of equipment feature uploading, dynamic configuration issuing and real-time updating feedback. A client adaptation engine is used as a core execution unit, an equipment information acquisition module, a configuration acquisition module, a state monitoring module, an interaction behavior mapping module, a rule analysis module, a rendering engine and a unified service interface layer are integrated, and all the modules adopt an event-driven mode to achieve efficient cooperation. And meanwhile, the matching adaptation method provides a complete and landing solution for multi-terminal native adaptation of the cloud mobile phone client, so that the experience consistency of cross-device use is greatly improved.

Description

Native-level multi-platform experience adaptation of cloud mobile client systems and adaptation methods Technical Field

[0001] This invention relates to the field of cloud phone system technology, specifically to a cloud phone client system and adaptation method with native-level multi-terminal experience adaptation. Background Technology

[0002] With the deep integration of cloud computing, edge computing, and 5G / 6G network technologies, the cloud terminal industry is experiencing explosive growth. Cloud phones, as one of the core forms of cloud terminals, leverage their advantages of cloud computing power and lightweight design to be widely used in diverse scenarios such as mobile office, cloud gaming, and remote collaboration. The market size continues to expand, and it is predicted that the global cloud terminal market will reach hundreds of billions of dollars by 2030, with the number of cloud-enabled terminals approaching 10 billion units. At the same time, terminal devices are showing a diversified and heterogeneous development trend, encompassing not only phones and tablets with different operating systems such as iOS and Android, but also devices with various forms such as foldable screens and high refresh rate screens. These different devices exhibit significant differences in hardware configuration (such as processor models and screen parameters), system characteristics, and interaction logic, posing a huge challenge to the multi-platform adaptation of cloud phone clients.

[0003] Currently, multi-platform adaptation of cloud mobile clients mainly adopts traditional cross-platform development frameworks (such as Flutter and React Native) or static adaptation solutions. Although these can achieve multi-platform coverage to a certain extent, they still face insurmountable technical bottlenecks and cannot meet users' demands for a native-level experience. Traditional cross-platform frameworks generally suffer from the practical dilemma of "write once, debug everywhere." Even with native bridging or unified rendering engine optimization, performance loss still occurs due to the presence of intermediate layers, leading to stuttering and latency issues in scenarios such as complex interactions and high-definition rendering. Furthermore, the fragility of third-party dependencies and the rapid iteration of frameworks significantly increase long-term maintenance costs and technical complexity.

[0004] In terms of adaptation accuracy, existing solutions mostly adopt a static, fixed-weight device feature matching method, applying a "one-size-fits-all" adaptation strategy to all devices. This fails to fully consider the hardware characteristics of different devices (such as differences in the form factor of foldable screens, differences in the refresh rate of high refresh rate screens, and performance differences of older processors) and the dynamic changes in actual usage scenarios, resulting in insufficient adaptation accuracy. For example, issues such as layout misalignment in the open / closed state of foldable screen devices, insufficient rendering smoothness of high refresh rate screen models, and interaction response delays of older processor models occur frequently. Adaptation blind spots for some niche software and professional tool applications further affect the user experience.

[0005] At the interaction and rendering adaptation level, existing technologies struggle to accurately map the native interaction logic of different systems, often resorting to compromise-based unified interaction solutions. This forces users to adapt to interaction methods that don't align with their device's native operating habits. Furthermore, they are not responsive enough to changes in device states (such as screen shape and system theme), lacking dynamic adjustment mechanisms and prone to layout errors and theme inconsistencies, violating the core requirements of a native user experience. In addition, existing adaptation solutions often lack quantitatively driven adaptation mechanisms, failing to translate key aspects like device characteristics and configuration matching into calculable logic. Adaptation effectiveness relies on manual debugging, resulting in low efficiency and poor consistency, making it difficult to meet the rapid access needs of massive numbers of heterogeneous devices. Summary of the Invention

[0006] The cloud mobile client system proposed in this invention, which achieves native-level multi-terminal experience adaptation, can at least solve one of the technical problems in the background art.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: a cloud mobile client system that achieves native-level multi-terminal experience adaptation, the system comprising: a client adaptation engine deployed on the user terminal and a configuration management server in the cloud, characterized in that the client adaptation engine and the configuration management server establish data interaction through an encrypted communication link, forming a complete data flow closed loop of uploading device features to dynamic configuration distribution and completing real-time update feedback; wherein, the client adaptation engine, as the core execution unit, integrates six major modules: device information collection module, configuration acquisition module, status monitoring module, interaction behavior mapping module, rule parsing module, rendering engine, and unified business interface layer; the output of the device information collection module serves as the input of the configuration acquisition module, the dynamic configuration information received by the configuration acquisition module is synchronized to the rendering engine and interaction mapping module, the change command of the status monitoring module triggers the rendering engine update, and the unified business interface layer realizes the conversion and adaptation of business commands and abstract interaction commands.

[0008] On another front, a cloud mobile client adaptation method for achieving native-level multi-terminal experience adaptation is provided to drive the cloud mobile client system. The method includes the following steps: S100, constructing a device feature quantification model based on the characteristics of the cloud mobile client system; S200, designing dynamic weights to drive the device feature quantification model to generate a comprehensive quantification value; S300, setting a dynamically updated measurement standard for configuration matching based on the comprehensive quantification value; and S400, completing the cloud mobile client system driving by performing configuration matching according to the measurement standard.

[0009] Furthermore, the equipment feature quantification model construction method in step S100 of the present invention includes: transforming key aspects of equipment features, configuration matching, and interaction mapping into computable logic through a series of mathematical models; in the equipment feature quantification stage, designing an equipment feature quantification model, the core formula of which is:

[0010] In the formula, These are the weighting coefficients. The device feature quantification model assigns different importance weights to the five core features of the device, namely device type, system type and version, screen parameters, screen form and theme mode. Among them, screen parameters have the highest weight of 30% because they directly affect the layout rendering effect. Each feature is then converted into a calculable value.

[0011] Further, the comprehensive quantization value generation method in step S200 of the present invention includes: First, hardware differentiation preset of initial weights, constructing a weight preset library with a three-dimensional index of device model, core processor, and screen core parameters in the cloud, and matching differentiated initial weights for different hardware combinations; Dynamic correction and optimization are performed during operation, with two types of core data collected in real time on the device to drive weight iteration: 1. User interaction feedback, if a user of a certain model device triggers gesture failure or click unresponsiveness n times consecutively, or if the interaction satisfaction score associated with the feature is lower than 80 points for 7 consecutive days, the corresponding feature weight will be fine-tuned by a gradient of 5%-3%; 2. Rendering quality score, if the comprehensive score of the feature weight is lower than 80 points for 3 consecutive times, it is adjusted by 2% for every 5 points difference, and the single correction does not exceed 10%, and the cumulative correction does not exceed 50% of the initial value to avoid sudden changes in weight; Finally, a dynamic optimization closed loop is formed, the corrected weights on the device are temporarily stored locally, and after connecting to the network, they are synchronized to the cloud-specific weight library for that device model, and the cloud takes the average corrected weights of the same model device to generate a comprehensive quantization value, and newly connected devices of the same model directly reuse this benchmark value as the initial weight, without the need for repeated correction cycles.

[0012] Furthermore, the configuration matching method based on the evaluation criteria in step S400 of the present invention includes: in the configuration matching stage, the system uses a cosine similarity algorithm to achieve accurate matching, the core formula of which is:

[0013] Calculate the similarity between the current device's feature ID card D and the various preset configuration templates C_j in the cloud. The similarity is represented by a value between 0 and 1. When the value reaches 80% or more, the configuration template is considered to be highly compatible with the device and is sent out as a dynamic configuration information package.

[0014] As can be seen from the above technical solutions, this method fundamentally solves the three major pain points of traditional cross-platform development through the core design of "end-cloud collaborative architecture, quantitative-driven adaptation, and native component invocation": Based on native component invocation and precise rule mapping, it avoids the performance loss caused by intermediate layers, and the animation smoothness and response speed are no different from native applications; Through dynamic state listening and real-time rendering, it achieves precise response to scenarios such as folding screen opening and closing and theme switching, without layout misalignment or theme inconsistency; Based on device feature quantification and similarity matching, it ensures that users of different systems can use familiar native interaction methods without having to adapt to compromise operations. Attached Figure Description

[0015] Figure 1 is a flowchart of the overall architecture and core module interaction of the cloud-edge collaboration of the present invention; Figure 2 is a flowchart of the cloud mobile client adaptation method of the present invention; Figure 3 is a flowchart of the device feature quantification and configuration matching process of the present invention; Figure 4 is a flowchart of the rendering optimization and dynamic response process of the present invention; Figure 5 is a flowchart of the weight dynamic optimization process of the present invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0017] As shown in Figure 1, the cloud mobile client system and adaptation method for achieving native-level multi-terminal experience adaptation described in this embodiment are based on an end-to-cloud collaboration architecture, consisting of a client adaptation engine deployed on the user terminal and a configuration management server in the cloud. The client adaptation engine and the configuration management server establish data interaction through an encrypted communication link, forming a complete data flow closed loop of device feature uploading → dynamic configuration distribution → real-time update feedback.

[0018] The client-side adaptation engine, as the core execution unit, integrates six modules: device information acquisition, configuration acquisition, status monitoring, interaction behavior mapping, rule parsing, rendering engine, and a unified business interface layer. These modules employ an event-driven model for efficient collaboration: the output of the device information acquisition module serves as the input to the configuration acquisition module; the dynamic configuration information received by the configuration acquisition module is synchronized to the rendering engine and interaction mapping module; change commands from the status monitoring module trigger rendering engine updates; and the unified business interface layer enables the conversion and adaptation between business commands and abstract interaction commands. This close collaboration between modules provides architectural support for native-level adaptation.

[0019] As shown in Figure 2, this solution provides a quantification-driven adaptation method for cloud mobile client systems to achieve native-level multi-terminal experience adaptation. The method includes the following steps: S100, constructing a device feature quantification model based on the characteristics of the cloud mobile client system; S200, designing dynamic weights to drive the device feature quantification model to generate a comprehensive quantification value; S300, setting dynamically updated measurement standards for configuration matching based on the comprehensive quantification value; S400, completing the cloud mobile client system driver by performing configuration matching according to the measurement standards.

[0020] The following provides a detailed explanation of each step: S100, Construct a device feature quantification model based on the characteristics of the cloud mobile client system; Transform key aspects such as device features, configuration matching, and interaction mapping into computable logic through a series of mathematical models to ensure adaptation accuracy and native experience.

[0021] In the device feature quantification stage, to address the difficulty in directly comparing multi-dimensional heterogeneous features (such as device type, system information, screen parameters, screen shape, theme mode, etc.), a device feature quantification model was designed, the core formula of which is:

[0022] In the formula, These are the weighting coefficients. It is a heterogeneous feature.

[0023] The device feature quantification model assigns different importance weights to five core device features (device type, system type and version, screen parameters, screen shape, and theme mode). Among these, screen parameters have the highest weight (30%) because they directly affect the layout rendering effect. After converting each feature into a calculable value, a comprehensive quantification value D between 0 and 1 is obtained through weighted summation. This quantification value is recorded as the device's "feature ID card," providing a unified standard for subsequent matching of optimal configurations.

[0024] S200. Dynamic weights are designed to drive the device feature quantification model to generate comprehensive quantified values. To address the insufficient accuracy of traditional static fixed weights in adapting to different device characteristics (model, processor, screen material, etc.) and actual usage scenarios, as shown in Figure 3, dynamic weights drive the device feature quantification model. These weights primarily refer to the weight coefficients for the five core features (device type, system information, screen parameters, screen shape, and theme mode) in the device feature quantification model. It adopts a dynamic adjustment strategy that combines initial hardware matching presets with subsequent data feedback corrections, replacing the traditional fixed weights. Its core objective is to ensure that the weight coefficients accurately match the hardware characteristics of specific devices and actual usage scenarios, making the generated comprehensive quantification value D more closely aligned with the matching requirements.

[0025] The core formula remains the same. But weighting coefficient Continuous optimization is achieved through a dynamic strategy of initial hardware matching presets, subsequent data feedback corrections, and iterative reuse and accumulation. The specific logic is as follows: First, the initial weights are preset based on hardware differences. A weight preset library with a three-dimensional index of "device model, core processor, and screen core parameters" is built in the cloud to match different initial weights for different hardware combinations. For example, the iPhone 15 Pro (high refresh rate screen + A17 Pro processor) has a preset screen parameter weight of 35%, the Huawei Mate60 Pro (foldable screen + Kirin 9000S processor) has a preset screen form factor weight of 30%, and older processor models such as Snapdragon 865 have a preset system information (related to performance adaptation) weight of 25%. The cloud will also periodically calibrate the initial weights of new devices and update the library through small-batch testing.

[0026] This hardware-based differentiated preset replaces the traditional "one-size-fits-all" fixed weights, ensuring the accuracy of initial adaptation from the source. As shown in Figure 4, the second step is dynamic correction and optimization during use. The device collects two types of core data in real time to drive weight iteration: First, user interaction feedback. If a user of a certain model triggers gesture failure or click unresponsiveness n times in a row, or if the interaction satisfaction score associated with a certain feature is lower than 80 points for 7 consecutive days, the corresponding feature weight will be fine-tuned by a gradient of 5% or 3%. Second, rendering quality score. If the comprehensive score of a certain feature weight is lower than 80 points for 3 consecutive times, it will be corrected by "2% adjustment for every 5 points difference", and the single correction will not exceed 10%, and the cumulative correction will not exceed 50% of the initial value to avoid sudden changes in weight. Finally, a dynamic optimization closed loop is formed. The corrected weights on the device are temporarily stored locally. After connecting to the network, they are synchronized to the cloud to the device model's exclusive weight library. The cloud takes the average corrected weights of the same model of devices to generate a comprehensive quantitative value, i.e., the "optimization benchmark value". Newly connected devices of the same model can directly reuse this benchmark value as the initial weight without repeating the correction cycle.

[0027] In simple terms, this model first matches initial weights to five core features of the device (device type, system information, screen parameters, screen form, and theme mode) according to hardware characteristics, then dynamically optimizes the weights using data, and finally obtains a comprehensive quantitative value D ("feature ID card") of 0-1 by weighted summation. Compared with traditional fixed weights, this value can be continuously optimized according to the device usage scenario, always fitting the matching requirements, and providing an accurate and dynamically updated measurement standard for subsequent configuration matching.

[0028] S300: Based on the comprehensive quantitative value, the dynamic update measurement standard for configuration matching is set. As shown in Figure 5, in the initial state, the weight coefficient is accurately matched based on the specific hardware parameters of the device. The cloud builds a preset mapping library of device hardware and weights. The core rules are as follows: ① Use the device model, core processor + screen core parameters as a three-dimensional index, and preset differentiated weights for different hardware combinations; ② Prioritize the features related to device core adaptation. For example, models with high refresh rate screens (such as iPhone 15 Pro) have a preset screen parameter weight of 35% (higher than the base value); foldable screen models (such as Huawei Mate 60 Pro) have a preset screen form weight of 30% (higher than the base value); older processor models (such as Snapdragon 865 models) have a preset system information (related to performance adaptation) weight of 25% (higher than the base value); ③ The cloud regularly collects the hardware parameters of newly launched devices, calibrates the optimal initial weight through small-batch adaptation tests, and updates it to the preset library to ensure the initial adaptation accuracy when new devices are connected.

[0029] During device use, the system dynamically adjusts weight coefficients based on two types of core data to ensure that the weights continuously match the actual adaptation scenarios. The adjustment rules are as follows: The device side records user interaction feedback in real time. If a user of a certain model triggers feedback such as gesture operation failure or no response to clicks n times (custom number) consecutively (associated with screen parameters or device type features), the weight of the corresponding feature will be automatically increased by 5% gradient. If the satisfaction score of the interaction feedback associated with a certain feature (collected through pop-up surveys) is lower than 80 points for 7 consecutive days, the weight will be fine-tuned by 3% gradient. Combined with the comprehensive rendering quality score, if the score under a certain feature weight is lower than 80 points for 3 consecutive times (such as layout misalignment caused by excessively low screen parameter weights), the weight adjustment is triggered. The difference between the score and the passing line (80 points) is calculated, and the corresponding feature weight is adjusted by 2% for every 5 points of difference. Among these, the single adjustment range of a single feature weight does not exceed 10%, and the cumulative adjustment range does not exceed 50% of the initial value to avoid sudden weight changes that may cause adaptation failure.

[0030] In summary, this solution forms an iterative closed loop of execution on the device side, storage in the cloud, and full reuse through dynamic weights: ① The weights corrected on the device side are temporarily stored locally and synchronized to the cloud device model-specific weight library when connected to the network; ② The cloud takes the average of the corrected weights for the same model of device to generate the optimized weight benchmark value for that model; ③ Newly connected devices of the same model directly call the optimized weight benchmark value as the initial weight, without having to go through the correction cycle again, thus improving the efficiency of batch adaptation.

[0031] S400: Based on the evaluation criteria, the system completes the configuration matching for the cloud mobile client system. During the configuration matching phase, the system uses a cosine similarity algorithm for accurate matching; the core formula is: .

[0032] In layman's terms, this algorithm calculates the similarity between the current device's "feature ID" D and various pre-set configuration templates C_j in the cloud. The similarity is represented by a value between 0 and 1. When the value reaches 80% or higher, the configuration template is considered to be highly compatible with the device, and it is distributed as a dynamic configuration information package. The dynamic configuration information package includes layout templates, theme resources, interaction rule sets, etc. The matching degree of each sub-configuration with the device is also evaluated in conjunction with feature weights to ensure the accuracy of the configuration.

[0033] In terms of interaction adaptation, the system first converts the operation instructions of the business function modules into abstract instructions that do not depend on the specific system. Then, based on the current device's operating system type (such as iOS or Android) and the interaction rules issued by the cloud, the abstract instructions are converted into the system's native operation instructions.

[0034] For example, the "back" operation will automatically match the side swipe back on iOS or the bottom navigation bar back on Android; at the same time, the system will adjust the standard gesture coordinates proportionally to the screen ratio for different screen sizes to ensure that the operation range on small-screen phones and large-screen tablets is in line with user habits.

[0035] Rendering optimization and dynamic response are key aspects of ensuring a native user experience. Optimize the model through rendering Achieve native interface generation. The core of this model is to combine device characteristics, optimal configuration templates, and the system's native UI component library. Through a dedicated rendering function, it parses the layout and theme requirements in the configuration and calls native components to generate the interface, fundamentally ensuring the native feel of the interface.

[0036] To respond to device status changes in real time, the system employs a combined interrupt-driven and polling monitoring mechanism: an interrupt notification is triggered directly when the system theme changes; and the screen status is checked every 100 milliseconds when the screen shape changes (e.g., when a foldable screen is opened or closed). Screen shape is monitored via... In simple terms, the determination involves calculating the ratio of the current screen area to the standard area when the foldable screen is fully unfolded. If the ratio is less than 30%, it is determined to be in a folded state; if it is greater than 90%, it is determined to be in an unfolded state. The theme mode, on the other hand, calculates the average brightness of the three RGB color channels of the system theme color. The system determines whether an average value below 128 indicates dark mode or above 128 indicates light mode. After a status change, the system updates device characteristic information and re-renders the interface. For example, it changes the theme color and icons when the theme changes, and adjusts the control layout density when the screen is folded. To ensure rendering quality, the system comprehensively evaluates three dimensions: layout accuracy (ideally no obstruction), theme consistency (matching the system theme), and rendering smoothness (shortest rendering time is better). These three dimensions account for 40%, 30%, and 30% of the weight, respectively. A comprehensive score of 80 or above is considered acceptable; otherwise, a re-rendering is triggered.

[0037] The complete adaptation process forms a closed loop: In the initial rendering phase, the device information collection module collects device information every 500 milliseconds and generates a "feature ID card," which is then uploaded to the cloud via an encrypted network. The cloud matches the optimal configuration and distributes the data, and the client calls native components to generate the initial interface. In the interaction adaptation phase, business commands generated by user operations are first converted into abstract commands, then mapped to native operation commands for execution, and the execution results are fed back to the business module. In the dynamic response phase, after the status listener detects changes in screen shape or theme, it immediately updates the device features and re-renders the corresponding interface. Throughout the process, the system verifies the effectiveness of the adaptation by statistically analyzing the percentage of successful executions of interaction commands. If the success rate is below 95%, the interaction rules are updated. At the same time, the system controls the interaction response latency, requiring that the time from command reception to execution completion does not exceed 150 milliseconds. If it exceeds this, the system improves smoothness by optimizing animation duration and other methods to ensure that users do not experience any latency during operation.

[0038] In summary, this method, through its core design of "end-to-cloud collaborative architecture, quantified adaptation, and native component invocation," fundamentally solves the three major pain points of traditional cross-platform development: Based on native component invocation and precise rule mapping, it avoids performance losses caused by intermediate layers, ensuring animation smoothness and response speed indistinguishable from native applications; through dynamic state monitoring and real-time rendering, it achieves precise responses to scenarios such as folding screen opening and closing and theme switching, preventing layout misalignment or theme inconsistencies; based on device feature quantification and similarity matching, it ensures that users of different systems can use familiar native interaction methods without needing to adapt to compromises. Business function modules access the system through a unified registration mechanism, requiring module identification, a list of invoked interfaces, and dependent system services during registration; when modules such as the personal center are loaded, loading priority is determined by combining module resource size (30% weight) and historical call frequency (70% weight), with high-frequency call modules loaded first, further improving system efficiency. This technical solution provides a complete and implementable solution for multi-terminal native adaptation of cloud mobile clients, significantly improving the consistency of experience across devices.

[0039] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0040] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0041] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the mobile source emission prediction methods based on time-series feature migration described in the above embodiments.

[0042] It is understood that the systems, devices, and storage media provided in the embodiments of the present invention correspond to the methods provided in the embodiments of the present invention, and the explanations, examples, and beneficial effects of the relevant content can be referred to the corresponding parts of the above methods.

[0043] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0044] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0045] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0046] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention 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 the present invention.

Claims

1. A cloud mobile client system that achieves native-level multi-terminal experience adaptation, the system comprising: The client-side adaptation engine deployed on the user terminal and the configuration management server in the cloud are characterized by establishing data interaction between the client-side adaptation engine and the configuration management server through an encrypted communication link, forming a complete data flow loop of uploading device features to dynamic configuration distribution and completing real-time update feedback. Among them, the client-side adaptation engine, as the core execution unit, integrates six major modules: device information acquisition module, configuration acquisition module, status monitoring module, interaction behavior mapping module, rule parsing module, rendering engine, and unified business interface layer. The output of the device information acquisition module serves as the input of the configuration acquisition module. The dynamic configuration information received by the configuration acquisition module is synchronized to the rendering engine and interaction mapping module. Change instructions from the status monitoring module trigger rendering engine updates, and the unified business interface layer realizes the conversion and adaptation of business instructions and abstract interaction instructions.

2. A cloud mobile client adaptation method for achieving native-level multi-terminal experience adaptation, used to drive the cloud mobile client system of claim 1, characterized in that, The method steps include: S100, constructing a device feature quantification model based on the characteristics of the cloud mobile client system; S200, designing dynamic weights to drive the device feature quantification model to generate a comprehensive quantification value; S300, setting a dynamically updated measurement standard for configuration matching based on the comprehensive quantification value; S400, completing the cloud mobile client system driving by performing configuration matching according to the measurement standard.

3. The cloud mobile client adaptation method for achieving native-level multi-terminal experience adaptation according to claim 2, characterized in that, The equipment feature quantification model construction method in step S100 includes: transforming key aspects of equipment features, configuration matching, and interaction mapping into computable logic through a series of mathematical models; and designing an equipment feature quantification model in the equipment feature quantification stage, the core formula of which is: In the formula, These are the weighting coefficients. The device feature quantification model assigns different importance weights to the five core features of the device, namely device type, system type and version, screen parameters, screen form and theme mode. Among them, screen parameters have the highest weight of 30% because they directly affect the layout rendering effect. Each feature is then converted into a calculable value.

4. The cloud mobile client adaptation method for achieving native-level multi-terminal experience adaptation according to claim 2, characterized in that, The comprehensive quantization value generation method in step S200 includes: First, hardware-differentiated preset of initial weights. A weight preset library with a three-dimensional index of device model, core processor, and screen core parameters is built in the cloud to match differentiated initial weights for different hardware combinations. During operation, dynamic correction and optimization are performed. Two types of core data are collected in real time on the device to drive weight iteration:

1. User interaction feedback: If a user of a certain model device triggers gesture failure or click unresponsiveness n times in a row, or if the interaction satisfaction score associated with a feature is lower than 80 points for 7 consecutive days, the corresponding feature weight will be fine-tuned by a gradient of 5%-3%.

2. Rendering quality score: If the comprehensive score of the feature weight is lower than 80 points for 3 consecutive times, it is adjusted by 2% for every 5 points of difference, and the single adjustment does not exceed 10%, and the cumulative adjustment does not exceed 50% of the initial value to avoid sudden changes in weight. Finally, a dynamic optimization closed loop is formed. The corrected weights on the device are temporarily stored locally. After connecting to the network, they are synchronized to the cloud-specific weight library for that device model. The cloud takes the average corrected weights of the same model devices to generate a comprehensive quantization value. Newly connected devices of the same model directly reuse this benchmark value as the initial weight without repeating the correction cycle.

5. The cloud mobile client adaptation method for achieving native-level multi-terminal experience adaptation according to claim 2, characterized in that, Step S400, which involves configuring and matching based on the evaluation criteria, includes the following: In the configuration matching stage, the system uses a cosine similarity algorithm to achieve accurate matching. The core formula is: Calculate the similarity between the current device's feature ID card D and the various preset configuration templates C_j in the cloud. The similarity is represented by a value between 0 and 1. When the value reaches 80% or more, the configuration template is considered to be highly compatible with the device and is sent out as a dynamic configuration information package.

Images