A UI interface adaptive constraint solving method and related apparatus

Abstract

This application provides a user interface (UI) adaptive constraint solving method and related apparatus. The method identifies and classifies multiple constraint relationships in the UI into two types: a first type of constraint relationship solved in an integrated development environment (IDE), and a second type of constraint relationship solved on a terminal or in the IDE. These multiple constraint relationships are used to determine the layout of one or more components in the UI. The IDE calculates a first intermediate solution set based on the first type of constraint relationships, and this first intermediate solution set is used together with the second type of constraint relationships to determine the layout of one or more components in the UI. Using this application embodiment can improve the rendering efficiency of the UI on the terminal.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for adaptive constraint solving of a UI interface. Background Technology

[0002] With the rapid development of electronic technology, the variety of terminals is increasing, leading to more and more significant differences in their display areas. Adapting to different terminal screens during development has become a common problem in the industry. To ensure compatibility with different terminal displays, the industry generally adopts an adaptive design approach: developing multiple interfaces to suit the needs of different terminals. While this approach provides a better experience on different terminals, it still has some shortcomings: for example, developing multiple interfaces to adapt to different terminals increases the workload for application developers. Furthermore, when the terminal's display area changes dynamically, this approach cannot dynamically adjust the display strategy to obtain the best display experience. Also, when supporting terminals with new screen resolutions or new display areas, an additional interface needs to be developed for adaptation. These shortcomings arise because the adaptive approach requires obtaining the terminal's display area size and resolution information, and then loading a suitable interface based on this information.

[0003] To address the aforementioned issues with adaptive layout solutions, the industry has proposed constraint layout. Currently, constraint layout constructs a flexible constraint system, using markers to describe the positional relationships between view components and blurring the limitations of the display area. During the display process, the terminal solves the linear equations of the layout constraints in real time to obtain the optimal display scheme for the current display area, greatly improving UI adaptability. Currently, the Cassowary algorithm is generally used to solve the linear equations of the layout constraints. For a system of linear equations, the Cassowary algorithm finds the possible values ​​of variables through incremental convergence, maximizing or minimizing the objective function. When a constraint in one of the equations changes, the algorithm recalculates the solution that maximizes or minimizes the objective function through successive convergence. The Cassowary linear constraint algorithm is based on the double simplex algorithm (simplex method, commonly used in numerical optimization for solving linear programming problems). When adding or removing constraints, it incrementally processes constraints at different levels by comparing local error gains and weighted sums. However, current optimizations for constraint solving are all implemented on the terminal. If the terminal cannot provide sufficient computing power, the constraint solving will take a long time, thus slowing down the UI rendering efficiency. Summary of the Invention

[0004] This application discloses a UI interface adaptive constraint solving method and related apparatus, which can improve the rendering efficiency of terminal UI interface.

[0005] In a first aspect, embodiments of this application disclose a UI interface adaptive constraint solving method, the method comprising:

[0006] Multiple constraints are obtained from the user interface (UI) interface, which are used to determine the layout of one or more components in the UI interface. Optionally, each constraint represents the position of a component in the UI interface, which can be relative to other components or an invisible guide line. The invisible guide line is a reference line in the UI interface used for comparison; it is an invisible line used to measure the position of components in the UI interface. For a given component, there may be one or at least two constraints. When there are at least two constraints, each of these constraints may only limit the position of the component to a certain extent (for example, one constraint only limits the position of the component relative to the component to the left, and another constraint limits the position of the component relative to the component above). The combination of at least two constraints can more accurately limit the position of the component in the UI interface.

[0007] A first intermediate solution set is calculated based on the first type of constraints among the plurality of constraints. The first type of constraints are those solved in an integrated development environment (IDE). This first intermediate solution set, together with the second type of constraints among the plurality of constraints, is used to determine the layout of one or more components in the UI interface. The second type of constraints are those solved on the terminal or in the IDE. In this method, the constraints of the plurality of UI interfaces are divided into a first type and a second type. The first type of constraints are solved in the IDE, while the second type of constraints can be solved on the terminal. Using this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational burden on the terminal when rendering the UI interface, thereby improving the efficiency of UI interface rendering.

[0008] In conjunction with the first aspect, in one possible implementation of the first aspect, the second type of constraint relationship includes constraint relationships relating to the display scene, or the second type of constraint relationship includes constraint relationships where the solution process requires the use of terminal data. Optionally, the second type of constraint relationship is identified by keywords in each constraint relationship, the keywords indicating that the constraint relationship is a constraint relationship relating to the display scene or a constraint relationship where the solution process requires the use of terminal data; conversely, constraint relationships not containing the keywords are constraint relationships of the first type.

[0009] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in another possible implementation of the first aspect, the constraint relationships of the second type can be classified as follows: the constraint relationships marked with the first keyword (such as the annotation containing "Vstack, Hstack") are classified into the second type, wherein the constraint relationships marked with the first keyword are constraint relationships of the display scene; the constraint relationships marked with the second keyword (such as the Bind() function) are classified into the second type, wherein the constraint relationships marked with the second keyword are constraint relationships of the terminal data required for the solution process.

[0010] It is understandable that, due to the different display scenarios and device parameters of different terminals, the constraints of a certain display scenario or a certain set of device parameters will not be applicable to all terminals. Therefore, the constraints of the display scenario and the constraints of the data of the terminal required for the solution process are classified into the second type, which can facilitate differentiated operations. Thus, when determining the layout of the UI interface, the layout information required by different terminals can be determined in a targeted manner.

[0011] In conjunction with the first aspect, or any of the possible implementations of the first aspect described above, the way to obtain the first type of constraint relationship in the second possible implementation of the first aspect can be as follows:

[0012] The constraint relationships between the first keyword and the second keyword that are not tagged are classified into the first type.

[0013] It is understandable that since the constraint relationship between the first keyword and the second keyword is usually applicable to various devices in various real-world scenarios, it is classified into the first type for unified processing and to save computational overhead.

[0014] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in the third possible implementation of the first aspect, the display scenario includes at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

[0015] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in the fourth possible implementation of the first aspect, the data of the terminal includes the terminal's device parameters and the data generated during the terminal's operation.

[0016] In conjunction with the first aspect, or any of the above-mentioned possible implementations of the first aspect, in the fifth possible implementation of the first aspect, the method further includes:

[0017] Calculate constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and the constraint relationship of the second type.

[0018] It is understandable that further solutions can be made based on the first intermediate solution set and the second type of constraints, which can further reduce the amount of computation on the terminal and thus improve the rendering efficiency of the terminal's UI interface.

[0019] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in the sixth possible implementation of the first aspect, the second type of constraint relationship includes constraint relationships of M display scenes, constraint relationships of N device parameters, and constraint relationships of P runtime-generated data; M, N, and P are all positive integers;

[0020] The computational constraint solution information includes:

[0021] Based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes, M second intermediate solution sets are calculated. Different second intermediate solution sets use different constraint relationships of the display scenes during calculation. The constraint solution information includes the constraint relationships of the M second intermediate solution sets and the N device parameters, wherein the constraint relationships of the device parameters are those required for solving the problem. Optionally, the constraint relationships of the display scenes are those required for solving the problem, and the constraint relationships of the runtime-generated data are those required for solving the problem, which involves using the data generated during device runtime.

[0022] In this application, device parameters, display scenarios, and data generated during terminal operation are the main factors affecting the UI display effect. For example, iPads and mobile phones have different device parameters, so the same type of APP needs to be displayed differently on these two types of terminals to provide users with a better visual experience. Similarly, for a regular mobile phone, landscape and portrait modes represent two different display scenarios, requiring differentiated display for these scenarios to ensure a better visual experience for users. Furthermore, for a chat application on a terminal, different display methods are needed depending on whether the number of chat characters generated during terminal operation is high or low, to provide users with a better visual experience. Based on this consideration, this application proposes to introduce the solution of constraints on device parameters, display scenarios, and data generated during terminal operation during the UI layout determination process, thereby demonstrating that device parameters, display scenarios, and data generated during terminal operation affect the UI display effect.

[0023] In this application embodiment, corresponding constraint relationships can be set for all display scenarios existing in the market (each display scenario has its own constraint relationship), or corresponding constraint relationships can be set for classic display scenarios (each display scenario has its own constraint relationship). Obtaining some or all of the constraint relationships for display scenarios in this way constitutes the constraint relationships for the M display scenarios mentioned in this application embodiment. Furthermore, this application considers the types of device parameters (specifically, inherent device parameters) that affect the UI interface display (such as the length, width, and height of the terminal), and sets corresponding constraint relationships to reflect the impact of these types of device parameters on the UI interface display, thus obtaining the constraint relationships for the aforementioned N device parameters. The input for solving these constraint relationships is the device parameters. In addition, this application also considers the data that may be generated during terminal operation that affects the UI interface display. Constraint relationships can be set for this data. These constraint relationships are used to reflect the impact of data generated during terminal operation on the UI interface display, and the input for solving them is the data generated during terminal operation. In this approach, M second intermediate solution sets are calculated for each of the M display scenarios. This allows for the provision of targeted second intermediate solution sets for terminals in different display scenarios, facilitating the determination of UI layouts for various terminals in each display scenario.

[0024] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in the seventh possible implementation of the first aspect, the second type of constraint relationship includes constraint relationships of M display scenes, constraint relationships of N device parameters, and constraint relationships of P runtime-generated data; M, N, and P are all positive integers; the calculation constraint solution information includes:

[0025] One or more third pieces of information are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different third pieces of information use different device parameters when calculating them.

[0026] The constraint solution information includes the plurality of third information.

[0027] In this approach, multiple sets of third-party information are calculated for each set of device parameters. This allows for the provision of targeted third-party information to terminals with different device parameters, facilitating the determination of UI layouts for various terminals.

[0028] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in the eighth possible implementation of the first aspect, the second type of constraint relationship includes constraint relationships of M display scenes, constraint relationships of N device parameters, and constraint relationships of P runtime-generated data; M, N, and P are all positive integers; the calculation constraint solution information includes:

[0029] One or more fourth pieces of information are calculated based on the constraint relationships of the P runtime-generated data, the M second intermediate solution sets, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different fourth pieces of information use different second intermediate solution sets or device parameters for calculation. The M second intermediate solution sets are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes. Different second intermediate solution sets use different constraint relationships of display scenes for calculation. The constraint solution information includes the multiple fourth pieces of information.

[0030] In this approach, multiple pieces of fourth information are calculated for M display scenarios and multiple sets of device parameters. This allows for the provision of targeted fourth information for terminals with different device parameters and display scenarios, facilitating the determination of UI layout for terminals with various display scenarios and device parameters.

[0031] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in the ninth possible implementation of the first aspect, obtaining multiple constraint relationships in the UI interface includes:

[0032] In response to user input, the plurality of constraint relationships are obtained, wherein the input operation includes at least one of drag operation and write operation, the drag operation is used to drag one or more components to a position on the screen, the plurality of constraint relationships are related to the position of the one or more components on the screen, and the write operation is used to write one or more constraint relationships among the plurality of constraint relationships.

[0033] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in the tenth possible implementation of the first aspect, before calculating the first intermediate solution set based on the first type of constraint relationship among the plurality of constraint relationships, the method further includes:

[0034] The types of the multiple constraint relationships are corrected based on the user's selection operation to determine the constraint relationships belonging to the first type and the constraint relationships belonging to the second type.

[0035] Here, the IDE first automatically classifies the constraint relationships into types, and then the human can further correct them. This not only improves the efficiency of type classification, but also ensures the accuracy of the classification.

[0036] Secondly, embodiments of this application provide a UI interface adaptive constraint solving method, the method comprising:

[0037] The system receives a resource file, wherein the resource file includes at least one of a first intermediate solution set and constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and a second type of constraint relationship, the first intermediate solution set is determined according to a first type of constraint relationship, the first type of constraint relationship is a constraint relationship solved in an integrated development environment (IDE), and the second type of constraint relationship is a constraint relationship solved on a terminal or the IDE, wherein the constraint relationship is used to describe the layout of one or more components of the UI interface of the terminal;

[0038] The layout of the components of the terminal's UI interface is determined based on the resource file.

[0039] In the above method, the constraints of multiple UI interfaces are divided into a first type and a second type. The constraints of the first type are solved in the IDE, while the constraints of the second type can be solved on the terminal. With this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational pressure on the terminal when rendering UI interfaces, thereby improving the efficiency of UI interface rendering.

[0040] In conjunction with the second aspect, in the first possible implementation of the second aspect,

[0041] Constraint relationships marked with the first keyword (such as annotations containing "Vstack" or "Hstack") are classified into the second type, where constraint relationships marked with the first keyword are constraint relationships of the display scenario;

[0042] Constraints marked with a second keyword (such as the Bind() function) are classified into the second type, where constraints marked with a second keyword are constraints that require terminal data to be used in the solution process.

[0043] It is understandable that, due to the different display scenarios and device parameters of different terminals, the constraints of a certain display scenario or a certain set of device parameters will not be applicable to all terminals. Therefore, the constraints of the display scenario and the constraints of the data of the terminal required for the solution process are classified into the second type, which can facilitate differentiated operations. Thus, when determining the layout of the UI interface, the layout information required by different terminals can be determined in a targeted manner.

[0044] In conjunction with the second aspect, or any of the above possible implementations of the second aspect, in the second possible implementation of the second aspect,

[0045] The constraint relationship between the first keyword and the second keyword that is not marked is classified into the first type.

[0046] It is understandable that since the constraint relationship between the first keyword and the second keyword is usually applicable to various devices in various real-world scenarios, it is classified into the first type for unified processing and to save computational overhead.

[0047] In conjunction with the second aspect, or any of the above possible implementations of the second aspect, in the third possible implementation of the second aspect, the display scenario includes at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

[0048] In conjunction with the second aspect, or any of the above possible implementations of the second aspect, in the fourth possible implementation of the second aspect, the data of the terminal includes the terminal's inherent device parameters and the data generated during the terminal's operation.

[0049] In conjunction with the second aspect, or any of the above possible implementations of the second aspect, in the fifth possible implementation of the second aspect, the constraint relationships classified into the second type include constraint relationships of M display scenes, constraint relationships of N device parameters, and constraint relationships of P runtime-generated data; M, N, and P are all positive integers.

[0050] The constraint solution information includes at least two of the following: second information, multiple third information, and multiple fourth information:

[0051] The second information includes M second intermediate solution sets and the constraint relationships of the N device parameters. Each second intermediate solution set is a solution set calculated based on the constraint relationship of one of the display scenarios from the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenarios. Different second intermediate solution sets use different constraint relationships of the display scenarios in their calculations.

[0052] The plurality of third information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and multiple sets of device parameters. Different device parameters are used when calculating different third information.

[0053] The plurality of fourth information includes solution information calculated based on the M second intermediate solution sets, the constraint relationships of the N device parameters, and multiple sets of device parameters. The second intermediate solution sets or device parameters used in the calculation of different fourth information are different. The constraint relationships of the device parameters are the constraint relationships of the terminal device parameters required for the solution.

[0054] In conjunction with the second aspect, or any of the above possible implementations of the second aspect, in the sixth possible implementation of the second aspect, determining the layout of the UI components of the terminal based on the resource file includes:

[0055] If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the layout of the terminal's UI interface is determined according to the first intermediate solution set, the constraint relationship of the N device parameters, and the constraint relationship of the P runtime-generated data; or,

[0056] If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a third piece of information, wherein the device parameters used to calculate the third piece of information are the same as the device parameters of the terminal; or,

[0057] If the display scene of the terminal belongs to one of the M display scenes, but the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a second intermediate solution set in the second information, the constraint relationship of the N device parameters, and the device parameters of the terminal. The calculation of the second intermediate solution set uses the constraint relationship of the terminal's display scene; or...

[0058] If the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a fourth piece of information. The second intermediate solution set used to calculate the fourth piece of information is calculated based on the constraint relationship of the display scene of the terminal, and the device parameters used to calculate the fourth piece of information are the same as the device parameters of the terminal.

[0059] In this approach, the terminal obtains solution information from different computational stages, such as the first, second, third, and fourth information. Then, based on its display scenario and device parameters, it selects the information closest to the final solution. Therefore, it can minimize the computational load on the terminal when calculating the final solution and improve the rendering efficiency of the UI interface.

[0060] In conjunction with the second aspect, or any of the above possible implementations of the second aspect, in the seventh possible implementation of the second aspect, the constraint relationships classified into the second type include constraint relationships of M display scenes, constraint relationships of N device parameters, and constraint relationships of P runtime-generated data.

[0061] Before receiving the resource file, the process also includes:

[0062] Send description information to the server, wherein the description information is used to describe the display scene and device parameters of the terminal;

[0063] If the server determines that the terminal's display scene does not belong to any of the M display scenes, and the terminal's device parameters do not belong to any of the multiple sets of device parameters, then the resource file includes the first intermediate solution set, the constraint relationships of the N device parameters, and the constraint relationships of the P runtime-generated data; or,

[0064] If the server determines that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one set of device parameters among the multiple sets of device parameters, then the resource file includes a third piece of information, wherein the third piece of information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and a set of device parameters, wherein the set of device parameters is the same as the device parameters of the terminal; or...

[0065] If the server determines that the terminal's display scene belongs to one of the M display scenes, but the terminal's device parameters do not belong to any of the multiple sets of device parameters, then the resource file includes a second intermediate solution set and the constraint relationships of the N device parameters. The second intermediate solution set is a solution set calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the terminal's display scene; or,

[0066] If the server determines that the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one set of device parameters among the multiple sets of device parameters, then the resource file includes a fourth piece of information, wherein the fourth piece of information includes solution information calculated based on the second intermediate solution set, the constraint relationship of the N device parameters, and the set of device parameters, wherein the constraint relationship of the device parameters is the constraint relationship of the terminal's device parameters that is needed for the solution.

[0067] In this approach, the terminal obtains solution information from different computational stages, such as the first, second, third, and fourth information. Then, based on its display scenario and device parameters, it selectively chooses the information closest to the final solution. This minimizes the computational load on the terminal when calculating the final solution. Furthermore, the selection of the information closest to the final solution is done by a device outside the terminal (such as an IDE), further reducing the terminal's computational load and improving the rendering efficiency of the terminal's UI.

[0068] Thirdly, embodiments of this application provide a UI-based adaptive constraint solving device, the device comprising:

[0069] The first acquisition unit acquires multiple constraint relationships in the user interface (UI), wherein the multiple constraint relationships are used to determine the layout of one or more components in the UI.

[0070] The calculation unit is used to calculate a first intermediate solution set based on a first type of constraint relationship among the plurality of constraint relationships. The first type of constraint relationship is a constraint relationship solved in an integrated development environment (IDE). The first intermediate solution set is used together with a second type of constraint relationship among the plurality of constraint relationships to determine the layout of one or more components in the UI interface. The second type of constraint relationship is a constraint relationship solved in a terminal or the IDE.

[0071] In the above method, the constraints of multiple UI interfaces are divided into a first type and a second type. The constraints of the first type are solved in the IDE, while the constraints of the second type can be solved on the terminal. With this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational pressure on the terminal when rendering UI interfaces, thereby improving the efficiency of UI interface rendering.

[0072] In conjunction with the third aspect, in one possible implementation of the third aspect, the second type of constraint relationship includes constraint relationships relating to the display scene, or the second type of constraint relationship includes constraint relationships where the solution process requires the use of terminal data. Optionally, the second type of constraint relationship is identified by keywords in each constraint relationship, the keywords indicating that the constraint relationship is a constraint relationship relating to the display scene or a constraint relationship where the solution process requires the use of terminal data; conversely, constraint relationships not containing the keywords are constraint relationships of the first type.

[0073] In conjunction with the third aspect, or any of the possible implementations of the third aspect described above, in yet another possible implementation of the third aspect, the way to obtain the second type of constraint relationship can be as follows:

[0074] Constraint relationships marked with the first keyword (such as annotations containing "Vstack" or "Hstack") are classified into the second type, where constraint relationships marked with the first keyword are constraint relationships of the display scene;

[0075] Constraints marked with a second keyword (such as the Bind() function) are classified into the second type. Constraints marked with a second keyword are those that require terminal data to be used in the solution process.

[0076] It is understandable that, due to the different display scenarios and device parameters of different terminals, the constraints of a certain display scenario or a certain set of device parameters will not be applicable to all terminals. Therefore, the constraints of the display scenario and the constraints of the data of the terminal required for the solution process are classified into the second type, which can facilitate differentiated operations. Thus, when determining the layout of the UI interface, the layout information required by different terminals can be determined in a targeted manner.

[0077] In conjunction with the third aspect, or any of the above possible implementations of the third aspect, the way to obtain the first type of constraint relationship in the second possible implementation of the third aspect can be as follows:

[0078] The constraint relationships between the first keyword and the second keyword that are not tagged are classified into the first type.

[0079] It is understandable that since the constraint relationship between the first keyword and the second keyword is usually applicable to various devices in various real-world scenarios, it is classified into the first type for unified processing and to save computational overhead.

[0080] In conjunction with the third aspect, or any of the above possible implementations of the third aspect, in the third possible implementation of the third aspect, the display scenario includes at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

[0081] In conjunction with the third aspect, or any of the above possible implementations of the third aspect, in the fourth possible implementation of the third aspect, the data of the terminal includes the terminal's inherent device parameters and the data generated during the terminal's operation.

[0082] In conjunction with the third aspect, or any of the above possible implementations of the third aspect, in the fifth possible implementation of the third aspect, the computing unit is further configured to:

[0083] Calculate constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and the constraint relationship of the second type.

[0084] It is understandable that further solutions can be made based on the first intermediate solution set and the second type of constraints, which can further reduce the amount of computation on the terminal and thus improve the rendering efficiency of the terminal's UI interface.

[0085] In conjunction with the third aspect, or any of the above possible implementations of the third aspect, in the sixth possible implementation of the third aspect, the second type of constraint relationship includes the constraint relationships of M display scenes, the constraint relationships of N device parameters, and the constraint relationships of P runtime-generated data; M, N, and P are all positive integers;

[0086] Regarding the calculation of constraint solution information, the calculation unit is specifically used for:

[0087] Based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes, M second intermediate solution sets are calculated. Different second intermediate solution sets use different constraint relationships of display scenes during calculation. The constraint solution information includes the constraint relationships of the M second intermediate solution sets and the N device parameters. The constraint relationships of the device parameters are the constraint relationships of the terminal's device parameters that need to be used for solving the problem. The constraint relationships of the display scenes are the constraint relationships of the display scenes that need to be used for solving the problem. The constraint relationships of the runtime-generated data are the constraint relationships of the data generated by the device during runtime that need to be used for solving the problem.

[0088] In this approach, M second intermediate solution sets are calculated for each of the M display scenarios. This allows for the provision of targeted second intermediate solution sets for terminals in different display scenarios, facilitating the determination of UI layouts for various terminals.

[0089] In conjunction with the third aspect, or any of the above possible implementations of the third aspect, in the seventh possible implementation of the third aspect, the second type of constraint relationship includes the constraint relationships of M display scenes, the constraint relationships of N device parameters, and the constraint relationships of P runtime-generated data; M, N, and P are all positive integers;

[0090] Regarding the calculation of constraint solution information, the calculation unit is specifically used for:

[0091] One or more third pieces of information are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different third pieces of information use different device parameters when calculating them. The constraint solution information includes the multiple third pieces of information.

[0092] In this approach, multiple sets of third-party information are calculated for each set of device parameters. This allows for the provision of targeted third-party information to terminals with different device parameters, facilitating the determination of UI layouts for various terminals.

[0093] In conjunction with the third aspect, or any of the above possible implementations of the third aspect, in the eighth possible implementation of the third aspect, the second type of constraint relationship includes the constraint relationships of M display scenes, the constraint relationships of N device parameters, and the constraint relationships of P runtime-generated data; M, N, and P are all positive integers;

[0094] Regarding the calculation of constraint solution information, the calculation unit is specifically used for:

[0095] One or more fourth pieces of information are calculated based on the constraint relationships of the P runtime-generated data, the M second intermediate solution sets, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different fourth pieces of information use different second intermediate solution sets or device parameters for calculation. The M second intermediate solution sets are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes. Different second intermediate solution sets use different constraint relationships of display scenes for calculation. The constraint solution information includes the multiple fourth pieces of information.

[0096] In this approach, multiple pieces of fourth information are calculated for M display scenarios and multiple sets of device parameters. This allows for the provision of targeted fourth information for terminals with different device parameters and display scenarios, facilitating the determination of UI layout for terminals with various display scenarios and device parameters.

[0097] In conjunction with the third aspect, or any of the above possible implementations of the third aspect, in the ninth possible implementation of the third aspect, in terms of obtaining multiple constraint relationships in the UI interface, the first output unit is specifically used for:

[0098] In response to user input, the plurality of constraint relationships are obtained, wherein the input operation includes at least one of drag operation and write operation, the drag operation is used to drag one or more components to a position on the screen, the plurality of constraint relationships are related to the position of the one or more components on the screen, and the write operation is used to write one or more constraint relationships among the plurality of constraint relationships.

[0099] In conjunction with the third aspect, or any of the above-described possible implementations of the third aspect, in the tenth possible implementation of the third aspect, the apparatus further includes:

[0100] A correction unit is configured to correct the types of the plurality of constraint relationships based on a user-input selection operation before the calculation unit calculates the first intermediate solution set based on the first type of constraint relationship among the plurality of constraint relationships, so as to determine the constraint relationships belonging to the first type and the constraint relationships belonging to the second type among the plurality of constraint relationships.

[0101] Here, the IDE first automatically classifies the constraint relationships into types, and then the human can further correct them. This not only improves the efficiency of type classification, but also ensures the accuracy of the classification.

[0102] Fourthly, embodiments of this application provide a UI-adaptive constraint solving device, the device comprising:

[0103] A receiving unit is configured to receive a resource file, wherein the resource file includes at least one of a first intermediate solution set and constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and a second type of constraint relationship, the first intermediate solution set is determined according to a first type of constraint relationship, the first type of constraint relationship is a constraint relationship solved in an integrated development environment (IDE), and the second type of constraint relationship is a constraint relationship solved on a terminal or the IDE, wherein the constraint relationship is used to describe the layout of one or more components of the UI interface of the terminal;

[0104] The determining unit is used to determine the layout of the components of the UI interface of the terminal based on the resource file.

[0105] In the above method, the constraints of multiple UI interfaces are divided into a first type and a second type. The constraints of the first type are solved in the IDE, while the constraints of the second type can be solved on the terminal. With this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational pressure on the terminal when rendering UI interfaces, thereby improving the efficiency of UI interface rendering.

[0106] In conjunction with the fourth aspect, in the first possible implementation of the fourth aspect,

[0107] Constraint relationships marked with the first keyword (such as annotations containing "Vstack" or "Hstack") are classified into the second type, where constraint relationships marked with the first keyword are constraint relationships of the display scenario;

[0108] Constraints marked with a second keyword (such as the Bind() function) are classified into the second type, where constraints marked with a second keyword are constraints that require terminal data to be used in the solution process.

[0109] It is understandable that, due to the different display scenarios and device parameters of different terminals, the constraints of a certain display scenario or a certain set of device parameters will not be applicable to all terminals. Therefore, the constraints of the display scenario and the constraints of the data of the terminal required for the solution process are classified into the second type, which can facilitate differentiated operations. Thus, when determining the layout of the UI interface, the layout information required by different terminals can be determined in a targeted manner.

[0110] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in the second possible implementation of the fourth aspect,

[0111] The constraint relationship between the first keyword and the second keyword that is not marked is classified into the first type.

[0112] It is understandable that since the constraint relationship between the first keyword and the second keyword is usually applicable to various devices in various real-world scenarios, it is classified into the first type for unified processing and to save computational overhead.

[0113] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in the third possible implementation of the fourth aspect, the display scenario includes at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

[0114] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in the fourth possible implementation of the fourth aspect, the data of the terminal includes the terminal's inherent device parameters and the data generated during the terminal's operation.

[0115] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in the fifth possible implementation of the fourth aspect, the constraint relationships classified into the second type include constraint relationships of M display scenes, constraint relationships of N device parameters, and constraint relationships of P runtime-generated data; M, N, and P are all positive integers.

[0116] The constraint solution information includes at least two of the following: second information, multiple third information, and multiple fourth information:

[0117] The second information includes M second intermediate solution sets and the constraint relationships of the N device parameters. Each second intermediate solution set is a solution set calculated based on the constraint relationship of one of the display scenarios from the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenarios. Different second intermediate solution sets use different constraint relationships of the display scenarios in their calculations.

[0118] The plurality of third information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and multiple sets of device parameters. Different device parameters are used when calculating different third information.

[0119] The plurality of fourth information includes solution information calculated based on the M second intermediate solution sets, the constraint relationships of the N device parameters, and multiple sets of device parameters. The second intermediate solution sets or device parameters used in the calculation of different fourth information are different. The constraint relationships of the device parameters are the constraint relationships of the terminal device parameters required for the solution.

[0120] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in the sixth possible implementation of the fourth aspect, when determining the layout of the UI components of the terminal based on the resource file, the determining unit is specifically used for:

[0121] If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the layout of the terminal's UI interface is determined according to the first intermediate solution set, the constraint relationship of the N device parameters, and the constraint relationship of the P runtime-generated data; or,

[0122] If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a third piece of information, wherein the device parameters used to calculate the third piece of information are the same as the device parameters of the terminal; or,

[0123] If the display scene of the terminal belongs to one of the M display scenes, but the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a second intermediate solution set in the second information, the constraint relationship of the N device parameters, and the device parameters of the terminal. The calculation of the second intermediate solution set uses the constraint relationship of the terminal's display scene; or...

[0124] If the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a fourth piece of information. The second intermediate solution set used to calculate the fourth piece of information is calculated based on the constraint relationship of the display scene of the terminal, and the device parameters used to calculate the fourth piece of information are the same as the device parameters of the terminal.

[0125] In this approach, the terminal obtains solution information from different computational stages, such as the first, second, third, and fourth information. Then, based on its display scenario and device parameters, it selects the information closest to the final solution. Therefore, it can minimize the computational load on the terminal when calculating the final solution and improve the rendering efficiency of the UI interface.

[0126] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in the seventh possible implementation of the fourth aspect, the constraint relationships classified into the second type include the constraint relationships of M display scenes, the constraint relationships of N device parameters, and the constraint relationships of P runtime-generated data.

[0127] The device further includes:

[0128] The sending unit is configured to send description information to the server before the receiving unit receives the resource file, wherein the description information is used to describe the display scene and device parameters of the terminal;

[0129] If the terminal does not belong to any of the M display scenarios, and the terminal's device parameters do not belong to any of the multiple sets of device parameters, then the resource file includes the first intermediate solution set, the constraint relationships of the N device parameters, and the constraint relationships of the P runtime-generated data; or,

[0130] If the server determines that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one set of device parameters among the multiple sets of device parameters, then the resource file includes a third piece of information, wherein the third piece of information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and a set of device parameters, wherein the set of device parameters is the same as the device parameters of the terminal; or...

[0131] If the server determines that the terminal's display scene belongs to one of the M display scenes, but the terminal's device parameters do not belong to any of the multiple sets of device parameters, then the resource file includes a second intermediate solution set and the constraint relationships of the N device parameters. The second intermediate solution set is a solution set calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the terminal's display scene; or,

[0132] If the server determines that the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one set of device parameters among the multiple sets of device parameters, then the resource file includes a fourth piece of information, wherein the fourth piece of information includes solution information calculated based on the second intermediate solution set, the constraint relationship of the N device parameters, and the set of device parameters, wherein the constraint relationship of the device parameters is the constraint relationship of the terminal's device parameters that is needed for the solution.

[0133] In this approach, the terminal obtains solution information from different computational stages, such as the first, second, third, and fourth information. Then, based on its display scenario and device parameters, it selectively chooses the information closest to the final solution. This minimizes the computational load on the terminal when calculating the final solution. Furthermore, the selection of the information closest to the final solution is done by a device outside the terminal (such as an IDE), further reducing the terminal's computational load and improving the rendering efficiency of the terminal's UI.

[0134] Fifthly, embodiments of this application provide an apparatus equipped with an integrated development environment (IDE), the apparatus including a processor and a memory, the memory being used to store a computer program, and the processor being used to invoke the computer program to execute the method described in the first aspect, or any possible implementation of the first aspect.

[0135] In a sixth aspect, embodiments of this application provide a terminal including a processor and a memory, the memory being used to store a computer program, and the processor being used to invoke the computer program to execute the method described in the second aspect, or any possible implementation of the second aspect.

[0136] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on a processor, implements the method described in the first aspect or any possible implementation of the first aspect; or implements the method described in the second aspect or any possible implementation of the second aspect. Attached Figure Description

[0137] The accompanying drawings used in the embodiments of the present invention are described below.

[0138] Figure 1 This is a schematic diagram of the structure of an image rendering system provided in an embodiment of the present invention;

[0139] Figure 2 This is a flowchart illustrating a constraint solving method for a UI interface provided in an embodiment of the present invention;

[0140] Figure 3 This is a flowchart illustrating an adaptive solution method for a UI interface provided in an embodiment of the present invention;

[0141] Figure 4 This is a schematic diagram of a component in a UI interface provided by an embodiment of the present invention;

[0142] Figure 5 This is a flowchart illustrating an adaptive solution method for a UI interface provided in an embodiment of the present invention;

[0143] Figure 6 This is a schematic diagram illustrating the time consumption relationship for solving constraints according to an embodiment of the present invention;

[0144] Figure 7 This is a schematic diagram of the structure of a UI interface adaptive solver provided in an embodiment of the present invention;

[0145] Figure 8 This is a schematic diagram of the structure of a UI interface adaptive solver provided in an embodiment of the present invention;

[0146] Figure 9 This is a schematic diagram of the structure of an IDE provided in an embodiment of the present invention;

[0147] Figure 10 This is a schematic diagram of the structure of a terminal provided in an embodiment of the present invention;

[0148] Figure 11 This is a schematic diagram of the structure of another terminal provided in an embodiment of the present invention. Detailed Implementation

[0149] The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0150] Constraint layout is a solution for achieving adaptive layout. It's built using a flexible constraint system that describes the positional relationships between view components through constraint tags. For example, each constraint represents the position of a component relative to other components (such as parent or sibling components) or invisible guide lines, blurring the limitations of the display area. By solving these constraints, the optimal UI layout within the display area (or the display interface) can be obtained, significantly improving UI adaptability. The invisible guide lines are reference lines in the UI interface; they are invisible lines used to measure the position of components within the UI. This connection reflects relative positional relationships.

[0151] Optionally, the layout mentioned in the embodiments of this application reflects one or more of the positional relationships of various components in the UI interface, or the content to be displayed.

[0152] In this embodiment, the constraints include constraints on the display scene, constraints on data from the terminal required for the solution process, and so on. Optionally, these constraints may exist in the form of a system of equations.

[0153] Display scenarios can generally be categorized into irregularly shaped screen scenarios, foldable screen scenarios, landscape display scenarios, and portrait display scenarios. Terminals may also have other display scenarios, which will not be listed here. Typically, the constraints of a display scenario contain scenario-related keywords, such as Vstack and Hstack, which can be referred to as the primary keywords for ease of description. Generally, the display scenario of the same device may be the same or different at different times.

[0154] The solution process requires data from the terminal, which can specifically include one or more of the terminal's inherent device parameters (e.g., resolution, pixel density, or screen refresh rate) and data generated during terminal runtime (e.g., data generated during operation or data acquired from elsewhere during operation, such as downloads). Typically, the constraints on the terminal data used in the solution process contain keywords related to the terminal data; for ease of description, these can be referred to as secondary keywords. For example, the constraints on data generated during terminal runtime might contain the secondary keyword `Bind()`. Generally, different types of devices can have different device parameters, and devices of the same type can have the same device parameters.

[0155] Please see Figure 1 and Figure 2 , Figure 1 This is a schematic diagram of the structure of an image rendering system provided in an embodiment of the present invention. The system includes an integrated development environment (IDE) 101, a server 102, and a terminal 103. Figure 2 This is a flowchart illustrating a constraint solving method for a UI interface provided in an embodiment of this application. This method can be based on... Figure 1 The system shown is used to implement this; the following is about... Figure 1 The various parts of the system shown, and Figure 2 The process of the constraint solving method shown will be introduced.

[0156] IDE101 can be pre-configured to support the design of conditional constraints and the identification of constraint types. For example, some constraints can be identified as type 1, while others can be identified as type 2. Different types of constraints have different solution stages, so this can also be seen as identifying the solution stages of constraints. Optionally, IDE101 can be configured based on a development kit designed for a domain-specific language (DSL).

[0157] After the above configuration, IDE101 is used to generate the program code (also known as layout code) for constraints, infer and identify the types of constraints, perform pre-computation of constraint solutions, and package the solution information. Among these, the generation of the program code (also known as layout code) for constraints and the inference and identification of the types of constraints correspond to... Figure 2 The UI design phase is shown. The pre-calculation of constraint relationships and the packaging of solution information correspond to... Figure 2 The conditions for pre-computation are shown.

[0158] The method for generating constraint layout code in IDE101 is not limited here. Generation can include drag-and-drop generation; for example, the IDE displays some view components to the user, and the developer selects a specific view component with the mouse and drags it to the corresponding position on the UI interface. The IDE then generates the layout code for the constraint relationships of that view component. Alternatively, constraint layout code can be generated manually; for example, the developer can input the layout code into the IDE using the keyboard.

[0159] IDE101 supports the classification and identification of constraint types. For example, it supports classifying constraint types into a first type and a second type, and provides syntax support for corresponding keywords (e.g., compile, runtime) for these two types in its syntax design. This allows IDE101 to label the categorized constraints with the "compile" or "runtime" tags (or keywords). In this embodiment, the first type of constraint (or constraint marked with the "compile" keyword) requires solving on the IDE, not on the terminal. The second type of constraint (or constraint marked with the "runtime" keyword) allows solving on the terminal. This type of constraint may be solved on the terminal or the IDE, depending on the specific circumstances. For example, if the terminal finds that the required solution information already exists based on relevant conditions (such as display scene, device parameters, etc.), then it will not need to solve based on the second type of constraint. If the terminal finds that the required solution information does not exist based on relevant conditions, then it will solve based on the second type of constraint.

[0160] In this application, the obtained constraint relationships are divided into a first type and a second type and identified. This can be done automatically by the IDE, manually by the developer, or by a combination of the IDE and manual work. For example, the IDE first makes a preliminary inference based on predefined rules (such as making an inference based on the above-mentioned first keyword and second keyword), and then the developer corrects or supplements the results of the preliminary division.

[0161] The constraint pre-computation and solution information packaging on IDE101 involve two aspects. First, constraint pre-computation primarily involves solving for first-type constraints (those marked as "compile") to obtain a first intermediate solution set. It may also substitute second-type constraints (those marked as "runtime") into this first intermediate solution set to obtain a second intermediate solution set. Furthermore, it may substitute terminal data into either the first or second intermediate solution set to obtain the optimal constraint solution suitable for a specific display scenario or device. Second, solution information packaging involves packaging the obtained solution information, such as one or more items from the first or second intermediate solution set, or the optimal constraint solution.

[0162] Server 102 can be a single server or a server cluster consisting of multiple servers. Its main purpose is to store files generated by the IDE for one or more terminals to access (e.g., download). Figure 1 The diagram illustrates one terminal 103. The methods by which the other terminals obtain files from server 102 and use the files can be found in the description of terminal 103.

[0163] Terminal 103 is a device that requires a UI interface display. For example, applications A, B, and C deployed on this terminal have UI interface display requirements. Therefore, the specific positions of the view components of these applications in the display area need to be determined by terminal 103. In this application, the terminal can obtain constraint layout-related resource files from server 102, such as... Figure 2 As shown, if the terminal's device parameters belong to a specific set of device parameters, the terminal can directly read the optimal solution of the constraint relationship calculated based on that specific device parameter from the resource file. If the terminal's device parameters do not belong to a specific set of device parameters, the terminal reads a set of constraint relationships of the device parameters and an intermediate solution set matching its own display scene (such as the first intermediate solution set or the second intermediate solution set mentioned earlier) from the resource file, and then calculates an optimal solution of the constraint relationship by combining its own device parameters and other information. It can be understood that the optimal solution of the UI layout read or calculated by the terminal describes the position of each view component in the UI interface, so the terminal can render the UI interface based on this optimal solution.

[0164] Based on the above description, most of the constraints in the UI interface are solved on the IDE, while a small number of constraints can be solved (i.e., calculated) by the terminal, thus significantly reducing the computational burden on the terminal.

[0165] It should be noted that, in one of the alternative solutions, this option may not exist. Figure 1In the case of server 102, terminal 103 can obtain the corresponding files directly from the IDE without going through server 102.

[0166] It should be noted that when the aforementioned server 102 exists, server 102 can be deployed in the cloud, and IDE 101 can be deployed in the cloud or on the developer's local machine. Figure 1 A schematic diagram is provided using the example of IDE101 and server102 both being deployed in the cloud.

[0167] Please see Figure 3 , Figure 3 This invention provides a UI interface adaptive solution method, which, compared to other methods, offers a more comprehensive solution. Figure 2 The method shown will be described in more detail, and this method can be based on Figure 1 The system architecture shown, or other system architectures, can be used to implement this method, which includes, but is not limited to, the following steps:

[0168] Step S301: The IDE obtains multiple constraint relationships of one or more components in the UI interface.

[0169] Specifically, the IDE can respond to user input and obtain multiple constraints of the UI interface.

[0170] In one alternative approach, the input operation includes drag-and-drop operations and / or writing operations; in this case, the IDE responds to the user's input operation, including: the IDE responds to the user's drag-and-drop operations and / or writing operations.

[0171] The drag-and-drop operation is used to drag one or more components to a specific location. These constraints relate to the position of the one or more components on the screen, for example, ... Figure 4 As shown in part (a), after dragging view component A and view component B to a specific position using a drag-and-drop operation, as shown... Figure 4 As shown in section (b), the IDE automatically determines the position of view component A and view component B relative to the display boundary of the display interface or other view components. Figure 4 (This is indicated by the percentage of the length or width of the displayed interface). This description of relative position is what we call constraint relationship, which can be represented in code in the IDE.

[0172] The write operation is used to write constraints. For example, a user can type characters into the constraint editing area by typing on the keyboard, and after entering a part of the characters, a constraint can be obtained.

[0173] It is understood that after the user (in this step, the user refers to the developer) performs input operations multiple times, the multiple constraints of the UI interface can be obtained. Each constraint is used to describe the layout of one or more components in the UI interface of the terminal. Therefore, the multiple constraints can determine the layout of one or more components in the UI interface.

[0174] Step S302: The IDE obtains the type of each constraint relationship among the multiple constraint relationships.

[0175] In one optional scheme, the IDE derives the types of the multiple constraint relationships according to preset rules. For example, it classifies the constraint relationships of the display scene into the second type, the constraint relationships of the data that the solution process requires from the terminal into the second type, and the remaining constraint relationships into the first type. Optionally, the constraint relationships of the display scene specifically refer to the constraint relationships affected by the display scene. For example, the constraint relationships of the landscape display scene specifically refer to the constraint relationships affected by the landscape display scene, and the constraint relationships of the portrait display scene specifically refer to the constraint relationships affected by the portrait display scene. The constraint relationships of the display scene contain some scene-related keywords, such as Vstack, Hstack, etc., which can be referred to as the first keyword for ease of description. The constraint relationships of the data that the solution process requires from the terminal contain some keywords related to the terminal data, which can be referred to as the second keyword for ease of description. For example, the constraint relationships of the data generated during terminal runtime may contain the second keyword Bind().

[0176] Therefore, the IDE can deduce the types of the multiple constraint relationships according to preset rules as follows: Constraint relationships marked with a first keyword (e.g., annotations containing "Vstack" or "Hstack") are classified into the second type, where constraints marked with the first keyword are constraints related to the display scene; constraint relationships marked with a second keyword (e.g., the Bind() function) are classified into the second type, where constraints marked with the second keyword are constraints requiring terminal data during the solution process. Constraint relationships without first or second keywords are classified into the first type.

[0177] In another alternative approach, each of the aforementioned multiple constraints can be labeled by the user (e.g., a developer) to categorize the multiple constraints into a first type and a second type.

[0178] In another alternative approach, the IDE first derives the types of the multiple constraint relationships according to preset rules to obtain a preliminary classification result, and then the user (such as a developer) corrects the preliminary classification result. For example, the IDE corrects the types derived by the IDE based on the user's input selection operation to determine the first type of constraint relationship and the second type of constraint relationship among the multiple constraint relationships.

[0179] Optionally, after obtaining the type of each constraint among the plurality of constraint relationships, the IDE can display the type of each constraint relationship, for example, by displaying its type label after each constraint relationship.

[0180] In this embodiment, the display scenario can be a non-standard screen scenario (e.g., a notch screen), a foldable screen scenario, a landscape display scenario, a portrait display scenario, etc. The constraints for each display scenario are only valid within that specific scenario.

[0181] In this embodiment of the application, the data required for the solution process from the terminal may specifically include one or more of the following: the terminal's inherent device parameters (e.g., resolution, pixel density, or screen refresh rate) and data generated during the terminal's operation (e.g., data generated during operation or data obtained from elsewhere during operation, such as downloads). Different device types often correspond to different device parameters, such as different resolutions, pixel densities, or screen refresh rates.

[0182] In addition, when determining the type of multiple constraint relationships, you can either determine the type of these multiple constraint relationships uniformly after obtaining them, or you can determine the type of each constraint relationship when obtaining each constraint relationship.

[0183] To facilitate understanding, the generated constraint relationships and their corresponding types are illustrated below from a code perspective.

[0184] div_9.left+div_9.width–div_10.left+50==0,compile

[0185] div_10.left+div_10.width+100==div_2.left,compile

[0186] div_13.left+div_13.width+100==div_2.left,compile

[0187] div_7.left+div_7.width+100==Bind(div_2.left),runtime

[0188] div_8.left+div_8.width-Bind(div_6.left)+50>0,runtime

[0189] If Vstack:

[0190] div_13.left+div_13.width+100==div_2.left,runtime

[0191] If Hstack:

[0192] div_13.left+div_13.width+200==div_2.left,runtime

[0193] If DisplayCutout:

[0194] div_13.left+div_13.width+50==div_2.left,runtime

[0195] In the code above, `Bind()` is a data binding function. Solving `Bind()` requires parameters from the terminal runtime, and "Bind" in `Bind()` can be used as the second keyword mentioned above. When developers write (or drag and drop to generate) constraint relationships, they generate conditional functions to determine the type of display scenario. For example, `If Vstack` is a conditional function indicating that if it's a portrait display scenario, `Vstack` in `If Vstack` can be the first keyword mentioned above; similarly, `If Hstack` is a conditional function indicating that if it's a landscape display scenario, `Hstack` in `If Hstack` can be the first keyword mentioned above; and `IfDisplayCutout` is a conditional function indicating that if it's a landscape display scenario, `DisplayCutout` in `If DisplayCutout` can be the first keyword mentioned above.

[0196] As can be seen from the code above, the type of each constraint relationship can be represented by the keyword (or identifier, or label) added after the constraint relationship, where compile represents the first type and runtime represents the second type.

[0197] In this embodiment, the first type of constraint (or constraint marked with the `compile` keyword) is solved on the IDE, not on the terminal. The second type of constraint (or constraint marked with the `runtime` keyword) is allowed to be solved on the terminal. This type of constraint may be solved on the terminal or on the IDE. Ultimately, whether it is solved on the terminal or on the IDE depends on the specific situation. For example, if the terminal finds that the required solution information already exists based on relevant conditions (such as display scene, device parameters, etc.), then it does not need to solve based on the second type of constraint. If the terminal finds that the required solution information does not exist based on relevant conditions, then it will solve based on the second type of constraint, which will be described in detail later.

[0198] For ease of subsequent description, we can assume that the second type obtained above includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers.

[0199] Step S303: The IDE calculates the first intermediate solution set based on the first type of constraint relationship among multiple conditional constraint relationships.

[0200] It is understood that the first type of constraint relationship is only a part of the multiple constraint relationships. It does not consider special display scenarios or terminal data. Therefore, a preliminary solution can be obtained based on the first type of constraint relationship, but the final solution cannot be obtained at this time. Therefore, the preliminary solution obtained based on the first type of constraint relationship is called the first intermediate solution set for the convenience of subsequent description. Compared with the first type of constraint relationship, the first intermediate solution set can more intuitively and concisely reflect the layout of view components in the display area.

[0201] Step S304: The IDE outputs the first intermediate solution set.

[0202] Specifically, the IDE can send the first intermediate solution set directly to the terminal, or it can send the first intermediate solution set indirectly to the terminal. For example, the IDE can send the first intermediate solution set to an intermediate device, such as a server, and then the server can send the first intermediate solution set to the terminal.

[0203] The first intermediate solution set is specifically used by the terminal to further calculate the final solution of the constraint relationship by combining other information. The final solution of the constraint relationship can most accurately describe the layout of the UI components in the display area.

[0204] Optionally, the other information may include the constraint relationships of the N device parameters and the constraint relationships of the P runtime-generated data. This other information may also be sent directly or indirectly to the terminal by the IDE.

[0205] Optionally, the first intermediate solution set, the constraint relationships of N device parameters, and the constraint relationships of P runtime-generated data can be packaged together and sent to the terminal. The packaged data can be called the first information for easy subsequent description.

[0206] In this embodiment of the application, optionally, the IDE can also calculate and output constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and the constraint relationship of the second type.

[0207] For example, calculating constraint solution information can include:

[0208] The IDE calculates M second intermediate solution sets based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes. Different second intermediate solution sets use different display scenario constraints during calculation. For example, assuming M equals 2, meaning there are two display scenario constraints: one for landscape and one for portrait. The IDE will calculate one second intermediate solution set based on the first intermediate solution set, the constraints of the P runtime-generated data, and the constraints of the landscape display scenario. It will also calculate another second intermediate solution set based on the first intermediate solution set, the constraints of the P runtime-generated data, and the constraints of the portrait display scenario, resulting in two second intermediate solution sets, one for the landscape display scenario and the other for the portrait display scenario. Optionally, when calculating the corresponding second intermediate solution set based on the constraints of a certain display scenario, the process may include: the constraints of the P runtime-generated data require runtime-generated data for calculation. Therefore, the IDE combines the default values ​​of the runtime-generated data, the constraints of the P runtime-generated data, the first intermediate solution set, and the constraints of the specific display scenario to obtain the second intermediate solution set corresponding to that display scenario.

[0209] It is understood that the second intermediate solution set, compared to the first intermediate solution set, can more accurately reflect the layout of the view components in the display area. The constraint solution information includes at least the second information, which comprises the constraint relationships between M second intermediate solution sets and the N device parameters. That is to say, the constraint solution information includes this second information.

[0210] For example, calculation constraint solution information can include:

[0211] The IDE calculates one or more third pieces of information based on the first intermediate solution set, the constraints of P runtime-generated data, the constraints of N device parameters, and one or more sets of device parameters. Different device parameters are used in the calculation of different third pieces of information. For example, assuming that the multiple sets of device parameters are specifically two sets of device parameters, one set for Huawei P40 phones and one set for Apple iPhone 12 phones, then the IDE will calculate one third piece of information based on the first intermediate solution set, the constraints of the P runtime-generated data, the constraints of the N device parameters, and the one set of device parameters for Huawei P40 phones. The IDE will also calculate one more third piece of information based on the first intermediate solution set, the constraints of the P runtime-generated data, the constraints of the N device parameters, and the one set of device parameters for Apple iPhone 12 phones, for a total of two sets of third pieces of information. One set of third pieces of information applies to Huawei P40, and the other set applies to Apple iPhone 12. For example, calculating a third piece of information based on the first intermediate solution set, the constraints of the P runtime-generated data, the constraints of the N device parameters, and a set of device parameters of the Apple iPhone 12 can specifically include: substituting the set of device parameters of the Apple iPhone 12 into the constraints of the N device parameters to solve for intermediate constraints. In addition, the constraints of the P runtime-generated data need to use the runtime-generated data when participating in the calculation. Therefore, the default values ​​of the runtime-generated data, the constraints of the P runtime-generated data, the first intermediate solution set, and the intermediate constraints are combined and solved to obtain a third piece of information corresponding to the Apple iPhone 12.

[0212] The constraint solution information includes at least one or more of the third information.

[0213] For example, the computational constraint solution information may include:

[0214] The IDE calculates one or more fourth pieces of information based on the constraints of the P runtime-generated data, the M second intermediate solution sets, the constraints of the N device parameters, and one or more sets of device parameters. Different sets of second intermediate solution sets or device parameters are used in the calculation of different fourth pieces of information. Referring to the above explanation of the second and third information, changes in the display scenario and device parameters can lead to changes in the solution results. Therefore, specific fourth pieces of information are calculated for specific display scenarios and specific device parameters. For example, if the display scenario includes landscape and portrait displays, then 2... If the device parameters include those of a Huawei P40 phone and an Apple iPhone 12 phone, then using the above method, four pieces of fourth information can be calculated. One piece of fourth information is used to constrain the components in the UI of the Huawei P40 phone in landscape mode, one piece of fourth information is used to constrain the components in the UI of the Huawei P40 phone in portrait mode, one piece of fourth information is used to constrain the components in the UI of the Apple iPhone 12 phone in landscape mode, and one piece of fourth information is used to constrain the components in the UI of the Apple iPhone 12 phone in portrait mode.

[0215] Optionally, taking the fourth information corresponding to the landscape display scenario of the Apple iPhone 12 as an example, the calculation process can be as follows: When the constraint relationship of the P runtime-generated data is involved in the calculation, the runtime-generated data needs to be used. Therefore, the default value of the runtime-generated data and the constraint relationship of the P runtime-generated data are solved to obtain the first intermediate constraint. The constraint relationship of the landscape display scenario and the above-mentioned first intermediate solution set are combined to obtain the second intermediate solution set. The device parameters of the Apple iPhone 12 are substituted into the constraint relationship of the above-mentioned N device parameters to obtain the intermediate constraint. Then, the second intermediate solution set and the intermediate constraint are combined to obtain the fourth information corresponding to the landscape display scenario of the Apple iPhone 12. The calculation process of other fourth information is similar.

[0216] The constraint solution information mentioned above includes at least one or more of the fourth information.

[0217] Optionally, the constraint solution information may specifically include one or more of the second information, one or more third information, and one or more fourth information mentioned above.

[0218] Step S305: The server receives the first intermediate solution set sent by the IDE.

[0219] In addition, the server may also receive the constraint relationships of the aforementioned N device parameters and the constraint relationships of P runtime-generated data. For example, the server may receive the aforementioned first information.

[0220] The server can also receive one or more of the second information, one or more third information, and one or more fourth information mentioned above.

[0221] For ease of understanding, the following description will use the example of the server receiving the first message, the second message, one or more third messages, and one or more fourth messages sent by the IDE.

[0222] The server can be a single server or a cluster of servers; it is used to store resource files received from the IDE for the terminal to access, such as for downloading.

[0223] Optionally, the server can be deployed in the cloud, thus allowing internet-connected terminals to access resource files.

[0224] Step S306: The server sends a resource file to the terminal.

[0225] The terminal can proactively send a request to the server, which will then respond to the request and send the resource file to the terminal. Alternatively, the server can proactively send the resource file to the terminal periodically or when pre-defined conditions are met.

[0226] In this embodiment of the application, the resource file includes at least one of a first intermediate solution set and constraint solution information. More specifically, if the constraint solution information includes the aforementioned second information, one or more third information, and one or more fourth information, then the resource file may include one or more of the first information, the second information, one or more third information, and one or more fourth information.

[0227] To make it easier to understand, the following examples illustrate two possible scenarios for resource files.

[0228] Scenario 1: The server determines the display scene and device parameters of the terminal, and then sends the necessary information for the interface layout, i.e., resource files, to the terminal accordingly. The implementation process for this scenario is as follows:

[0229] The server receives description information sent by the terminal device. The description information describes the terminal's device parameters and the current display scenario, such as landscape display, portrait display, or irregular screen display.

[0230] If the description information indicates that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the resource file sent by the server to the terminal includes the first intermediate solution set, the constraint relationship of the N device parameters, and the constraint relationship of the P runtime-generated data, that is, the resource file includes the first information.

[0231] If the description information indicates that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one set of device parameters among the multiple sets of device parameters, then the resource file sent by the server to the terminal includes a third piece of information, wherein the third piece of information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and a set of device parameters, wherein the set of device parameters is the same as the device parameters of the terminal.

[0232] If the description information indicates that the display scene of the terminal belongs to one of the M display scenes, but the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the resource file sent by the server to the terminal includes a second intermediate solution set and the constraint relationship of the N device parameters, that is, it includes part of the content in the second information. The second intermediate solution set is a solution set calculated based on the first intermediate solution set, the constraint relationship of the P runtime-generated data, and the constraint relationship of one of the M display scenes. The display scene is the same as the display scene of the terminal.

[0233] If the description information indicates that the terminal's display scene belongs to one of the M display scenes, and the terminal's device parameters belong to one set of device parameters among the multiple sets of device parameters, then the resource file sent by the server to the terminal includes a fourth piece of information. This fourth piece of information includes solution information calculated based on the second intermediate solution set, the constraint relationships of the N device parameters, and the set of device parameters. It can be understood that the second intermediate solution set uses the constraint relationships of the terminal's display scene during calculation; the set of device parameters is the same as the terminal's device parameters.

[0234] The approach in scenario one is that the server selects the appropriate solution information for the UI layout based on the terminal's display scenario, device parameters, and other factors, and then sends the selected solution information to the terminal.

[0235] Scenario 2: The resource file sent by the server to the terminal includes various information related to the interface layout, such as at least two of the first, second, one or more third, and one or more fourth pieces of information mentioned above. For ease of description, the following explanation will use the example of a resource file including the first, second, one or more third, and one or more fourth pieces of information. After receiving the resource file, the terminal selects the appropriate interface layout information based on its display scenario and device parameters.

[0236] Step S307: The terminal receives the resource file sent by the server.

[0237] Step S308: The terminal determines the layout of its UI interface based on the resource file.

[0238] In the case of scenario one above, the resource file contains layout information applicable to the terminal, so the terminal can directly determine the layout of its UI interface based on the resource file.

[0239] For example, if the resource file includes the aforementioned first information, namely, the first intermediate solution set, the constraint relationships of the N device parameters, and the constraint relationships of the P runtime-generated data, then the terminal can substitute its own device parameters into the constraint relationships of the N device parameters to solve for intermediate constraints. In addition, since the constraint relationships of the P runtime-generated data require the use of runtime-generated data when participating in the calculation, the first intermediate solution set, intermediate constraints, the default values ​​of the terminal runtime-generated data, and the constraint relationships of the P runtime-generated data are combined to solve for the final solution of the constraint relationships. This final solution can more accurately reflect the layout of the view components in the display area of ​​the UI interface. Therefore, the terminal can render the UI interface based on this final solution.

[0240] For example, if the resource file includes a second intermediate solution set from the aforementioned second information and the constraint relationships of the N device parameters, then the terminal substitutes its own device parameters into the constraint relationships of the N device parameters to solve for intermediate constraints. Then, it combines the second intermediate solution set and the intermediate constraints to solve for the final solution of the constraint relationships. This final solution can more accurately reflect the layout of the view components in the display area of ​​the UI interface; therefore, the terminal can render the UI interface based on this final solution.

[0241] For example, if the resource file includes one of the aforementioned third pieces of information, since this third piece of information is calculated based on the device parameters of the terminal, it is the optimal solution for the constraints of the terminal's UI interface. This final solution can more accurately reflect the layout of the view components in the display area of ​​the UI interface. Therefore, the terminal can render the UI interface based on this final solution.

[0242] For example, if the resource file includes one of the aforementioned fourth pieces of information, since this fourth piece of information is calculated based on the device parameters of the terminal and the display scene of the terminal, it is the optimal solution of the constraint relationship of the UI interface of the terminal. This final solution can more accurately reflect the layout of the view components in the display area of ​​the UI interface. Therefore, the terminal can render the UI interface based on this final solution.

[0243] In one alternative approach, if the terminal obtains the actual values ​​of the runtime-generated data after running for a period of time, these actual values ​​can be substituted into the final solution to update the optimal solution. This process can be considered as replacing the default values ​​of the runtime-generated data with the actual values. After the optimal solution is updated, it can be rendered again based on the updated optimal solution, thereby improving the rendering effect of the UI.

[0244] Regarding scenario two above, the resource file contains a lot of information, including layout information suitable for this terminal and layout information not suitable for it. Therefore, the terminal needs to select the layout information suitable for itself based on its display scenario and device parameters, and then determine the layout of the terminal's UI interface based on the layout information suitable for itself. For example, as... Figure 5 As shown, the terminal loads an APK file, which includes the aforementioned resource files. Additionally, the terminal reads its own device parameters, which may include the terminal's resolution, pixel density, screen refresh rate, and other device attribute information. Then, based on the read device parameters, it selects the required layout information from the original resource files. The process of selecting the required layout information is as follows: Figure 5 As shown in the dashed box.

[0245] If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the layout information selected from the resource file includes the first information mentioned above, namely, the first intermediate solution set, the constraint relationship of N device parameters, and the constraint relationship of P runtime-generated data.

[0246] Then, the terminal can substitute its own device parameters into the constraints of N device parameters to solve for intermediate constraints. Furthermore, since the constraints of the P runtime-generated data require runtime-generated data for calculation, the terminal combines the first intermediate solution set, intermediate constraints, default values ​​of the runtime-generated data, and the constraints of the P runtime-generated data to obtain the final solution for the constraints. This final solution more accurately reflects the layout of the view components in the UI display area. Therefore, the terminal can render the UI based on this final solution. This scenario corresponds to... Figure 5 Process D in the process.

[0247] If the terminal's display scene does not belong to any of the M display scenes, and the terminal's device parameters belong to one set of device parameters among the multiple sets, then the layout information selected by the terminal from the resource file includes a third piece of information. The device parameters used to calculate this third piece of information are the same as the terminal's device parameters. Since the device parameters used to calculate this third piece of information are the same as the terminal's device parameters, this third piece of information is the optimal solution for the constraints of the terminal's UI interface. This final solution can more accurately reflect the layout of view components in the display area of ​​the UI interface. Therefore, the terminal can render the UI interface based on this final solution. This situation corresponds to... Figure 5 Process B in the process.

[0248] If the terminal's display scene belongs to one of the M display scenes, but the terminal's device parameters do not belong to any of the multiple sets of device parameters, then the layout information selected by the terminal from the resource file includes a second intermediate solution set from the aforementioned second information and the constraint relationships of the N device parameters. The calculation of the second intermediate solution set uses the constraint relationships of the target display scene, which is the same as the terminal's display scene (i.e., the calculation of the second intermediate solution set uses the constraint relationships of the terminal's display scene). Then, the terminal substitutes its own device parameters into the constraint relationships of the N device parameters to solve for intermediate constraints. Then, it combines the second intermediate solution set and the intermediate constraints to solve for the final solution of the constraint relationships. This final solution can more accurately reflect the layout of the view components in the display area of ​​the UI interface; therefore, the terminal can render the UI interface based on this final solution. This situation corresponds to... Figure 5 Process C in the process.

[0249] If the terminal's display scene belongs to one of the M display scenes, and the terminal's device parameters belong to one of the multiple sets of device parameters, then the layout information selected by the terminal from the resource file includes one of the aforementioned fourth pieces of information. The second intermediate solution set used to calculate the fourth piece of information is obtained based on the constraint relationship of the target display scene (i.e., the terminal's display scene), and the device parameters used to calculate the fourth piece of information are the same as the terminal's device parameters. Since this fourth piece of information is calculated for the terminal's device parameters and the terminal's display scene, it is the optimal solution for the constraint relationship of the terminal's UI interface. This final solution can more accurately reflect the layout of the view components in the display area of ​​the UI interface. Therefore, the terminal can render the UI interface based on this final solution. This situation corresponds to... Figure 5 Process A in the process.

[0250] This application, through experimental data, reveals that when the entire constraint solving process is implemented on the terminal, the proportion of the entire rendering process occupied by constraint solving gradually increases with the complexity of the constraints. For example... Figure 6 As shown, solving 4 constraints takes only 0.02ms, accounting for 1.4% of the rendering time, while solving 1015 constraints takes 13.67ms, increasing the proportion of the rendering time to 33%.

[0251] The process of solving constraints can be partially or entirely completed in the IDE, and the results are compared with those of completing it entirely on the terminal, as shown in Table 1:

[0252] Table 1

[0253] Implementation Time taken (average of 500,000 attempts) The entire process of solving for constraints is completed at the terminal (existing technology). 4.06778935 milliseconds (ms) The process of solving for constraints is partially or entirely completed within the IDE (this application). 1.276350074 milliseconds (ms)

[0254] As shown in Table 1, in the prior art, solving 92 constraint relationships on the terminal takes 4.06778935ms. In contrast, this application completes most of the calculations for these 92 constraint relationships in the IDE, with the terminal taking only 1.276350074ms, representing only 31.4% of the time required by the prior art. Therefore, in this embodiment, the terminal solving time is significantly reduced, thus significantly improving the efficiency of terminal UI rendering.

[0255] exist Figure 3In the described method, the constraints of multiple UI interfaces are divided into a first type and a second type. The constraints of the first type are solved in the IDE, while the constraints of the second type can be solved on the terminal. With this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational pressure when rendering UI interfaces on the terminal and improving the efficiency of UI interface rendering.

[0256] The methods of the embodiments of the present invention have been described in detail above, and the apparatus of the embodiments of the present invention is provided below.

[0257] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a UI interface adaptive constraint solving device 70 provided in an embodiment of the present invention. The device 70 can be the aforementioned IDE, or a device in the IDE. The device 70 can include a first acquisition unit 701 and a calculation unit 702, wherein each unit is described in detail below.

[0258] The first acquisition unit 701 acquires multiple constraint relationships in the user interface (UI), wherein the multiple constraint relationships are used to determine the layout of one or more components in the UI.

[0259] The calculation unit 702 is used to calculate a first intermediate solution set based on the first type of constraint relationship among the plurality of constraint relationships. The first type of constraint relationship is the constraint relationship solved in the integrated development environment (IDE). The first intermediate solution set is used together with the second type of constraint relationship among the plurality of constraint relationships to determine the layout of one or more components in the UI interface. The second type of constraint relationship is the constraint relationship solved in the terminal or the IDE.

[0260] In the above method, the constraints of multiple UI interfaces are divided into a first type and a second type. The constraints of the first type are solved in the IDE, while the constraints of the second type can be solved on the terminal. With this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational pressure on the terminal when rendering UI interfaces, thereby improving the efficiency of UI interface rendering.

[0261] In one alternative approach, the second type of constraint relationship includes constraints relating to the display scene, or constraints relating to data required by the terminal during the solution process. Optionally, the second type of constraint relationship is identified by keywords in each constraint relationship, the keywords indicating whether the constraint relationship relates to the display scene or requires data from the terminal during the solution process; conversely, constraint relationships not containing the keywords are the first type of constraint relationships.

[0262] In one alternative approach, the second type of constraint relationship can be obtained by partitioning as follows:

[0263] Constraint relationships marked with the first keyword (such as annotations containing "Vstack" or "Hstack") are classified into the second type, where constraint relationships marked with the first keyword are constraint relationships of the display scene;

[0264] Constraints marked with a second keyword (such as the Bind() function) are classified into the second type. Constraints marked with a second keyword are those that require terminal data to be used in the solution process.

[0265] It is understandable that, due to the different display scenarios and device parameters of different terminals, the constraints of a certain display scenario or a certain set of device parameters will not be applicable to all terminals. Therefore, the constraints of the display scenario and the constraints of the data of the terminal required for the solution process are classified into the second type, which can facilitate differentiated operations. Thus, when determining the layout of the UI interface, the layout information required by different terminals can be determined in a targeted manner.

[0266] In another alternative approach, the first type of constraint relationship can be obtained by partitioning as follows:

[0267] The constraint relationships between the first keyword and the second keyword that are not tagged are classified into the first type.

[0268] It is understandable that since the constraint relationship between the first keyword and the second keyword is usually applicable to various devices in various real-world scenarios, it is classified into the first type for unified processing and to save computational overhead.

[0269] In another alternative solution, the display scenario includes at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

[0270] In another alternative, the terminal's data includes the terminal's inherent device parameters and data generated during the terminal's operation.

[0271] In another alternative embodiment, the computing unit 702 is further configured to:

[0272] Calculate constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and the constraint relationship of the second type.

[0273] It is understandable that further solutions can be made based on the first intermediate solution set and the second type of constraints, which can further reduce the amount of computation on the terminal and thus improve the rendering efficiency of the terminal's UI interface.

[0274] In another alternative scheme, the second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers.

[0275] Regarding the calculation of constraint solution information, the calculation unit 702 is specifically used for:

[0276] Based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes, M second intermediate solution sets are calculated. Different second intermediate solution sets use different constraint relationships of display scenes during calculation. The constraint solution information includes the constraint relationships of the M second intermediate solution sets and the N device parameters. The constraint relationships of the device parameters are the constraint relationships of the terminal's device parameters that need to be used for solving the problem. The constraint relationships of the display scenes are the constraint relationships of the display scenes that need to be used for solving the problem. The constraint relationships of the runtime-generated data are the constraint relationships of the data generated by the device during runtime that need to be used for solving the problem.

[0277] In this approach, M second intermediate solution sets are calculated for each of the M display scenarios. This allows for the provision of targeted second intermediate solution sets for terminals in different display scenarios, facilitating the determination of UI layouts for various terminals.

[0278] In another alternative scheme: the second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers;

[0279] Regarding the calculation of constraint solution information, the calculation unit 702 is specifically used for:

[0280] One or more third pieces of information are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different third pieces of information use different device parameters when calculating them. The constraint solution information includes the multiple third pieces of information.

[0281] In this approach, multiple sets of third-party information are calculated for each set of device parameters. This allows for the provision of targeted third-party information to terminals with different device parameters, facilitating the determination of UI layouts for various terminals.

[0282] In another alternative scheme, the second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers.

[0283] Regarding the calculation of constraint solution information, the calculation unit 702 is specifically used for:

[0284] Multiple pieces of fourth information are calculated based on the constraint relationships of the P runtime-generated data, the M second intermediate solution sets, the constraint relationships of the N device parameters, and multiple sets of device parameters. Different second intermediate solution sets or device parameters are used in the calculation of different pieces of fourth information. The M second intermediate solution sets are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes. Different second intermediate solution sets are used in the calculation of different display scene constraint relationships. The constraint solution information includes the multiple pieces of fourth information.

[0285] In this approach, multiple pieces of fourth information are calculated for M display scenarios and multiple sets of device parameters. This allows for the provision of targeted fourth information for terminals with different device parameters and display scenarios, facilitating the determination of UI layout for terminals with various display scenarios and device parameters.

[0286] In another alternative embodiment, regarding the acquisition of multiple constraint relationships in the UI interface, the first acquisition unit 701 is specifically used for:

[0287] In response to user input, the plurality of constraint relationships are obtained, wherein the input operation includes at least one of drag operation and write operation, the drag operation is used to drag one or more components to a position on the screen, the plurality of constraint relationships are related to the position of the one or more components on the screen, and the write operation is used to write one or more constraint relationships among the plurality of constraint relationships.

[0288] In another alternative embodiment, the device 70 further includes:

[0289] A correction unit is configured to correct the types of the plurality of constraint relationships based on a user-input selection operation before the calculation unit calculates the first intermediate solution set based on the first type of constraint relationship among the plurality of constraint relationships, so as to determine the constraint relationships belonging to the first type and the constraint relationships belonging to the second type among the plurality of constraint relationships.

[0290] Here, the IDE first automatically classifies the constraint relationships into types, and then the human can further correct them. This not only improves the efficiency of type classification, but also ensures the accuracy of the classification.

[0291] It should be noted that the implementation of each unit can also be referenced accordingly. Figure 3 The corresponding description of the method embodiments shown.

[0292] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a UI interface adaptive constraint solving device 80 provided in an embodiment of the present invention. The device can be the aforementioned terminal or a device in the aforementioned terminal. The device 80 may include a receiving unit 801 and a determining unit 802, wherein the detailed description of each unit is as follows.

[0293] The receiving unit 801 is configured to receive a resource file, wherein the resource file includes at least one of a first intermediate solution set and constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and a second type of constraint relationship, the first intermediate solution set is determined according to a first type of constraint relationship, the first type of constraint relationship is a constraint relationship solved in an integrated development environment (IDE), and the second type of constraint relationship is a constraint relationship solved on a terminal or the IDE, wherein the constraint relationship is used to describe the layout of one or more components of the UI interface of the terminal;

[0294] The determining unit 802 is used to determine the layout of the components of the UI interface of the terminal based on the resource file.

[0295] In the above method, the constraints of multiple UI interfaces are divided into a first type and a second type. The constraints of the first type are solved in the IDE, while the constraints of the second type can be solved on the terminal. With this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational pressure on the terminal when rendering UI interfaces, thereby improving the efficiency of UI interface rendering.

[0296] In one alternative approach:

[0297] Constraint relationships marked with the first keyword (such as annotations containing "Vstack" or "Hstack") are classified into the second type, where constraint relationships marked with the first keyword are constraint relationships of the display scenario;

[0298] Constraints marked with a second keyword (such as the Bind() function) are classified into the second type, where constraints marked with a second keyword are constraints that require terminal data to be used in the solution process.

[0299] It is understandable that, due to the different display scenarios and device parameters of different terminals, the constraints of a certain display scenario or a certain set of device parameters will not be applicable to all terminals. Therefore, the constraints of the display scenario and the constraints of the data of the terminal required for the solution process are classified into the second type, which can facilitate differentiated operations. Thus, when determining the layout of the UI interface, the layout information required by different terminals can be determined in a targeted manner.

[0300] In another alternative solution:

[0301] The constraint relationship between the first keyword and the second keyword that is not marked is classified into the first type.

[0302] It is understandable that since the constraint relationship between the first keyword and the second keyword is usually applicable to various devices in various real-world scenarios, it is classified into the first type for unified processing and to save computational overhead.

[0303] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in the third possible implementation of the fourth aspect, the display scenario includes at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

[0304] In another alternative, the terminal's data includes the terminal's inherent device parameters and data generated during the terminal's operation.

[0305] In another alternative scheme, the constraints classified into the second type include constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers.

[0306] The constraint solution information includes at least two of the following: second information, multiple third information, and multiple fourth information:

[0307] The second information includes M second intermediate solution sets and the constraint relationships of the N device parameters. Each second intermediate solution set is a solution set calculated based on the constraint relationship of one of the display scenarios from the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenarios. Different second intermediate solution sets use different constraint relationships of the display scenarios in their calculations.

[0308] The plurality of third information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and multiple sets of device parameters. Different device parameters are used when calculating different third information.

[0309] The plurality of fourth information includes solution information calculated based on the M second intermediate solution sets, the constraint relationships of the N device parameters, and multiple sets of device parameters. The second intermediate solution sets or device parameters used in the calculation of different fourth information are different.

[0310] In another alternative approach, when determining the layout of the UI components of the terminal based on the resource file, the determining unit is specifically used for:

[0311] If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the layout of the terminal's UI interface is determined according to the first intermediate solution set, the constraint relationship of the N device parameters, and the constraint relationship of the P runtime-generated data; or,

[0312] If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a third piece of information, wherein the device parameters used to calculate the third piece of information are the same as the device parameters of the terminal; or,

[0313] If the display scene of the terminal belongs to one of the M display scenes, but the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a second intermediate solution set in the second information, the constraint relationship of the N device parameters, and the device parameters of the terminal. The calculation of the second intermediate solution set uses the constraint relationship of the terminal's display scene; or...

[0314] If the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a fourth piece of information. The second intermediate solution set used to calculate the fourth piece of information is calculated based on the constraint relationship of the display scene of the terminal. The device parameters used to calculate the fourth piece of information are the same as the device parameters of the terminal. The constraint relationship of the device parameters is the constraint relationship of the device parameters of the terminal that is needed to solve the problem.

[0315] In this approach, the terminal obtains solution information from different computational stages, such as the first, second, third, and fourth information. Then, based on its display scenario and device parameters, it selects the information closest to the final solution. Therefore, it can minimize the computational load on the terminal when calculating the final solution and improve the rendering efficiency of the UI interface.

[0316] In another alternative scheme, the constraints classified into the second type include constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data.

[0317] The device further includes:

[0318] The sending unit is configured to send description information to the server before the receiving unit receives the resource file, wherein the description information is used to describe the display scene and device parameters of the terminal;

[0319] If the terminal does not belong to any of the M display scenarios, and the terminal's device parameters do not belong to any of the multiple sets of device parameters, then the resource file includes the first intermediate solution set, the constraint relationships of the N device parameters, and the constraint relationships of the P runtime-generated data; or,

[0320] If the server determines that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one set of device parameters among the multiple sets of device parameters, then the resource file includes a third piece of information, wherein the third piece of information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and a set of device parameters, wherein the set of device parameters is the same as the device parameters of the terminal; or...

[0321] If the server determines that the terminal's display scene belongs to one of the M display scenes, but the terminal's device parameters do not belong to any of the multiple sets of device parameters, then the resource file includes a second intermediate solution set and the constraint relationships of the N device parameters. The second intermediate solution set is a solution set calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the terminal's display scene; or,

[0322] If the server determines that the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one set of device parameters among the multiple sets of device parameters, then the resource file includes a fourth piece of information, wherein the fourth piece of information includes solution information calculated based on the second intermediate solution set, the constraint relationship of the N device parameters, and the set of device parameters, wherein the constraint relationship of the device parameters is the constraint relationship of the terminal's device parameters that is needed for the solution.

[0323] In this approach, the terminal obtains solution information from different computational stages, such as the first, second, third, and fourth information. Then, based on its display scenario and device parameters, it selectively chooses the information closest to the final solution. This minimizes the computational load on the terminal when calculating the final solution. Furthermore, the selection of the information closest to the final solution is done by a device outside the terminal (such as an IDE), further reducing the terminal's computational load and improving the rendering efficiency of the terminal's UI.

[0324] It should be noted that the implementation of each unit can also be referenced accordingly. Figure 3 The corresponding description of the method embodiments shown.

[0325] Please see Figure 9 , Figure 9 This invention provides a compiler IDE90, which includes a processor 901, a memory 902, and a communication interface 903. The processor 901, the memory 902, and the communication interface 903 are interconnected via a bus.

[0326] The memory 902 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), and is used for related computer programs and data. The communication interface 903 is used for receiving and sending data.

[0327] Processor 901 can be one or more central processing units (CPUs). If processor 901 is a CPU, the CPU can be a single-core CPU or a multi-core CPU.

[0328] The processor 901 in the IDE90 is used to read the computer program code stored in the memory 902 and perform the following operations:

[0329] Multiple constraints are obtained from the user interface (UI) interface, which are used to determine the layout of one or more components in the UI interface. Optionally, each constraint represents the position of a component in the UI interface, which can be relative to other components or an invisible guide line. The invisible guide line is a reference line in the UI interface used for comparison; it is an invisible line used to measure the position of components in the UI interface. For a given component, there may be one or at least two constraints. When there are at least two constraints, each of these constraints can only limit the position of the component to a certain extent. The combination of at least two constraints can more accurately limit the position of the component in the UI interface.

[0330] A first intermediate solution set is calculated based on the first type of constraint relationship among the plurality of constraint relationships. The first type of constraint relationship is the constraint relationship solved in the integrated development environment (IDE). The first intermediate solution set is used together with the second type of constraint relationship among the plurality of constraint relationships to determine the layout of one or more components in the UI interface. The second type of constraint relationship is the constraint relationship solved in the terminal or the IDE.

[0331] In the above method, the constraints of multiple UI interfaces are divided into a first type and a second type. The constraints of the first type are solved in the IDE, while the constraints of the second type can be solved on the terminal. With this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational pressure on the terminal when rendering UI interfaces, thereby improving the efficiency of UI interface rendering.

[0332] In conjunction with the first aspect, in one possible implementation of the first aspect, the second type of constraint relationship includes constraint relationships relating to the display scene, or the second type of constraint relationship includes constraint relationships where the solution process requires the use of terminal data. Optionally, the second type of constraint relationship is identified by keywords in each constraint relationship, the keywords indicating that the constraint relationship is a constraint relationship relating to the display scene or a constraint relationship where the solution process requires the use of terminal data; conversely, constraint relationships not containing the keywords are constraint relationships of the first type.

[0333] In another alternative approach, the second type of constraint relationship can be obtained as follows:

[0334] Constraint relationships marked with the first keyword (such as annotations containing "Vstack" or "Hstack") are classified into the second type, where constraint relationships marked with the first keyword are constraint relationships of the display scene;

[0335] Constraints marked with a second keyword (such as the Bind() function) are classified into the second type. Constraints marked with a second keyword are those that require terminal data to be used in the solution process.

[0336] It is understandable that, due to the different display scenarios and device parameters of different terminals, the constraints of a certain display scenario or a certain set of device parameters will not be applicable to all terminals. Therefore, the constraints of the display scenario and the constraints of the data of the terminal required for the solution process are classified into the second type, which can facilitate differentiated operations. Thus, when determining the layout of the UI interface, the layout information required by different terminals can be determined in a targeted manner.

[0337] In another alternative approach, the first type of constraint relations can be obtained as follows:

[0338] The constraint relationships between the first keyword and the second keyword that are not tagged are classified into the first type.

[0339] It is understandable that since the constraint relationship between the first keyword and the second keyword is usually applicable to various devices in various real-world scenarios, it is classified into the first type for unified processing and to save computational overhead.

[0340] In another alternative solution, the display scenario includes at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

[0341] In another alternative, the terminal's data includes the terminal's inherent device parameters and data generated during the terminal's operation.

[0342] In yet another alternative, the processor is also used for:

[0343] Constraint solution information is output through the aforementioned communication interface, wherein the constraint solution information is the solution information calculated based on the first intermediate solution set and the constraint relationship of the second type.

[0344] It is understandable that further solutions can be made based on the first intermediate solution set and the second type of constraints, which can further reduce the amount of computation on the terminal and thus improve the rendering efficiency of the terminal's UI interface.

[0345] In another alternative scheme, the constraints classified into the second type include constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers.

[0346] Regarding the computational constraint solution information, the processor is specifically used for:

[0347] Based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes, M second intermediate solution sets are calculated. Different second intermediate solution sets use different constraint relationships of display scenes during calculation. The constraint solution information includes the constraint relationships of the M second intermediate solution sets and the N device parameters. The constraint relationships of the device parameters are the constraint relationships of the terminal's device parameters that need to be used for solving the problem. The constraint relationships of the display scenes are the constraint relationships of the display scenes that need to be used for solving the problem. The constraint relationships of the runtime-generated data are the constraint relationships of the data generated by the device during runtime that need to be used for solving the problem.

[0348] In this approach, M second intermediate solution sets are calculated for each of the M display scenarios. This allows for the provision of targeted second intermediate solution sets for terminals in different display scenarios, facilitating the determination of UI layouts for various terminals in different display scenarios.

[0349] In another alternative scheme, the second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers.

[0350] Regarding the computational constraint solution information, the processor is specifically used for:

[0351] One or more third pieces of information are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different third pieces of information use different device parameters when calculating them. The constraint solution information includes the multiple third pieces of information.

[0352] In this approach, multiple sets of third-party information are calculated for each set of device parameters. This allows for the provision of targeted third-party information to terminals with different device parameters, facilitating the determination of UI layouts for various terminals.

[0353] In another alternative scheme, the second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers.

[0354] Regarding the computational constraint solution information, the processor is specifically used for:

[0355] One or more pieces of fourth information are calculated based on the constraint relationships of the P runtime-generated data, M second intermediate solution sets, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different fourth information uses different second intermediate solution sets or device parameters for calculation. The M second intermediate solution sets are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes. Different second intermediate solution sets use different display scene constraint relationships for calculation. The constraint relationships of the device parameters are the constraint relationships of the terminal's device parameters that are needed for solving the problem. The constraint solution information includes the multiple pieces of fourth information.

[0356] In this approach, multiple pieces of fourth information are calculated for M display scenarios and multiple sets of device parameters. This allows for the provision of targeted fourth information for terminals with different device parameters and display scenarios, facilitating the determination of UI layout for terminals with various display scenarios and device parameters.

[0357] In another alternative embodiment, regarding the acquisition of multiple constraint relationships in the UI interface, the processor is specifically used for:

[0358] In response to user input, the plurality of constraint relationships are obtained, wherein the input operation includes at least one of drag operation and write operation, the drag operation is used to drag one or more components to a position on the screen, the plurality of constraint relationships are related to the position of the one or more components on the screen, and the write operation is used to write one or more constraint relationships among the plurality of constraint relationships.

[0359] In another alternative embodiment, before calculating the first intermediate solution set based on the first type of constraint relationships among the plurality of constraint relationships, the processor is further configured to:

[0360] The types of the multiple constraint relationships are corrected based on the user's selection operation to determine the constraint relationships belonging to the first type and the constraint relationships belonging to the second type.

[0361] Here, the IDE first automatically classifies the constraint relationships into types, and then the human can further correct them. This not only improves the efficiency of type classification, but also ensures the accuracy of the classification.

[0362] It should be noted that the implementation of each operation can also be referenced accordingly. Figure 3 The corresponding description of the method embodiments shown.

[0363] Please see Figure 10 This is a schematic diagram of the structure of a terminal 1000 used in an embodiment of the present invention. The terminal 1000 includes a memory 1080, a processor 1050, and a display device 1040. The memory 1080 stores computer programs, including an operating system program 1082 and application programs 1081, where the application program 1081 includes a browser program. The processor 1050 reads the computer program from the memory 1080 and then executes the methods defined by the computer program. For example, the processor 1050 reads the operating system program 1082 to run the operating system and implement various functions of the operating system on the terminal 1000, or reads one or more application programs 1081 to run the application on the terminal. For example, it reads the browser program to run a browser. The browser's UI needs to be presented to the user, so the terminal executes the aforementioned UI interface adaptive constraint solving method.

[0364] Processor 1050 may include one or more processors, for example, processor 1050 may include one or more central processing units. When processor 1050 includes multiple processors, these multiple processors may be integrated on the same chip or may be independent chips. A processor may include one or more processing cores. The following embodiments are all described using multi-core as an example, but the UI interface adaptive constraint solving method provided in the embodiments of the present invention can also be applied to single-core processors.

[0365] In addition, the memory 1080 also stores other data 1083 besides the computer program. The other data 1083 may include data generated after the operating system 1082 or the application 1081 is run. This data includes system data (such as the configuration parameters of the operating system) and user data. For example, the first information, second information, third information, fourth information, etc. obtained by the terminal can be regarded as user data. The final solution of the constraint relationship obtained by solving based on this information can also be regarded as user data.

[0366] The memory 1080 generally includes main memory and secondary storage. Main memory can be random access memory (RAM), read-only memory (ROM), and cache, etc. Secondary storage can be hard disk, optical disk, USB flash drive, floppy disk, or tape drive, etc. Computer programs are usually stored on secondary storage, and the processor loads the computer program from secondary storage into main memory before executing the processing. In this embodiment of the invention, the first, second, third, and fourth information, etc., can be stored on secondary storage. When it is necessary to solve a problem based on this information, and when rendering the UI interface after obtaining the final solution, this information or the final solution can be loaded into main memory first.

[0367] The operating system program 1082 contains a computer program that can implement the UI interface adaptive constraint solving method provided in the embodiments of the present invention, so that after the processor 1050 reads the operating system program 1082, it performs the following operations:

[0368] The system receives a resource file, wherein the resource file includes at least one of a first intermediate solution set and constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and a second type of constraint relationship, the first intermediate solution set is determined according to a first type of constraint relationship, the first type of constraint relationship is a constraint relationship solved in an integrated development environment (IDE), and the second type of constraint relationship is a constraint relationship solved on a terminal or the IDE, wherein the constraint relationship is used to describe the layout of one or more components of the UI interface of the terminal;

[0369] The layout of the components of the terminal's UI interface is determined based on the resource file.

[0370] In the above method, the constraints of multiple UI interfaces are divided into a first type and a second type. The constraints of the first type are solved in the IDE, while the constraints of the second type can be solved on the terminal. With this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational pressure on the terminal when rendering UI interfaces, thereby improving the efficiency of UI interface rendering.

[0371] In one alternative approach:

[0372] Constraint relationships marked with the first keyword (such as annotations containing "Vstack" or "Hstack") are classified into the second type, where constraint relationships marked with the first keyword are constraint relationships of the display scenario;

[0373] Constraints marked with a second keyword (such as the Bind() function) are classified into the second type, where constraints marked with a second keyword are constraints that require terminal data to be used in the solution process.

[0374] It is understandable that, due to the different display scenarios and device parameters of different terminals, the constraints of a certain display scenario or a certain set of device parameters will not be applicable to all terminals. Therefore, the constraints of the display scenario and the constraints of the data of the terminal required for the solution process are classified into the second type, which can facilitate differentiated operations. Thus, when determining the layout of the UI interface, the layout information required by different terminals can be determined in a targeted manner.

[0375] In another alternative solution:

[0376] The constraint relationship between the first keyword and the second keyword that is not marked is classified into the first type.

[0377] It is understandable that since the constraint relationship between the first keyword and the second keyword is usually applicable to various devices in various real-world scenarios, it is classified into the first type for unified processing and to save computational overhead.

[0378] In another alternative solution, the display scenario includes at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

[0379] In another alternative, the terminal's data includes the terminal's device parameters and data generated during the terminal's operation.

[0380] In another alternative scheme, the constraints classified into the second type include constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers.

[0381] The constraint solution information includes at least two of the following: second information, multiple third information, and multiple fourth information:

[0382] The second information includes M second intermediate solution sets and the constraint relationships of the N device parameters. Each second intermediate solution set is a solution set calculated based on the constraint relationship of one of the display scenarios from the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenarios. Different second intermediate solution sets use different constraint relationships of the display scenarios in their calculations.

[0383] The plurality of third information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and multiple sets of device parameters. Different device parameters are used when calculating different third information.

[0384] The plurality of fourth information includes solution information calculated based on the M second intermediate solution sets, the constraint relationships of the N device parameters, and multiple sets of device parameters. The second intermediate solution sets or device parameters used in the calculation of different fourth information are different. The constraint relationships of the device parameters are the constraint relationships of the terminal device parameters required for the solution.

[0385] In another alternative embodiment, regarding the step of determining the layout of the UI components of the terminal based on the resource file, the processor is specifically configured to:

[0386] If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the layout of the terminal's UI interface is determined according to the first intermediate solution set, the constraint relationship of the N device parameters, and the constraint relationship of the P runtime-generated data; or,

[0387] If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a third piece of information, wherein the device parameters used to calculate the third piece of information are the same as the device parameters of the terminal; or,

[0388] If the display scene of the terminal belongs to one of the M display scenes, but the device parameters of the terminal do not belong to any of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a second intermediate solution set in the second information, the constraint relationship of the N device parameters, and the device parameters of the terminal. The calculation of the second intermediate solution set uses the constraint relationship of the terminal's display scene; or...

[0389] If the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one of the multiple sets of device parameters, then the layout of the UI interface of the terminal is determined according to a fourth piece of information. The second intermediate solution set used to calculate the fourth piece of information is calculated based on the constraint relationship of the display scene of the terminal, and the device parameters used to calculate the fourth piece of information are the same as the device parameters of the terminal.

[0390] In this approach, the terminal obtains solution information from different computational stages, such as the first, second, third, and fourth information. Then, based on its display scenario and device parameters, it selects the information closest to the final solution. Therefore, it can minimize the computational load on the terminal when calculating the final solution and improve the rendering efficiency of the UI interface.

[0391] In another alternative scheme, the constraints classified into the second type include constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data.

[0392] Before receiving the resource file through the communication interface, the processor is further configured to:

[0393] The terminal sends description information to the server through the communication interface, wherein the description information is used to describe the display scene and device parameters of the terminal.

[0394] If the server determines that the terminal's display scene does not belong to any of the M display scenes, and the terminal's device parameters do not belong to any of the multiple sets of device parameters, then the resource file includes the first intermediate solution set, the constraint relationships of the N device parameters, and the constraint relationships of the P runtime-generated data; or,

[0395] If the server determines that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one set of device parameters among the multiple sets of device parameters, then the resource file includes a third piece of information, wherein the third piece of information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and a set of device parameters, wherein the set of device parameters is the same as the device parameters of the terminal; or...

[0396] If the server determines that the terminal's display scene belongs to one of the M display scenes, but the terminal's device parameters do not belong to any of the multiple sets of device parameters, then the resource file includes a second intermediate solution set and the constraint relationships of the N device parameters. The second intermediate solution set is a solution set calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the terminal's display scene; or,

[0397] If the server determines that the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one set of device parameters among the multiple sets of device parameters, then the resource file includes a fourth piece of information, wherein the fourth piece of information includes solution information calculated based on the second intermediate solution set, the constraint relationship of the N device parameters, and the set of device parameters, wherein the constraint relationship of the device parameters is the constraint relationship of the terminal's device parameters that is needed for the solution.

[0398] In this approach, the terminal obtains solution information from different computational stages, such as the first, second, third, and fourth information. Then, based on its own display scenario and device parameters, it selects the information it needs to calculate the final solution of the constraint relationship. This can minimize the amount of computation on the terminal and improve the rendering efficiency of the UI interface.

[0399] In this approach, the terminal obtains solution information from different computational stages, such as the first, second, third, and fourth information. Then, based on its display scenario and device parameters, it selectively chooses the information closest to the final solution. This minimizes the computational load on the terminal when calculating the final solution. Furthermore, the selection of the information closest to the final solution is done by a device outside the terminal (such as an IDE), further reducing the terminal's computational load and improving the rendering efficiency of the terminal's UI.

[0400] It should be noted that the implementation of each operation can also be referenced accordingly. Figure 3 The corresponding description of the method embodiments shown.

[0401] Furthermore, the operating system can expose the UI interface adaptive constraint solving function call interface to upper-layer applications. After the processor 1050 reads the application 1081 from the memory 1080 and runs the application, the application can call the UI interface adaptive constraint solving function provided in the operating system through the call interface to obtain the final solution of the constraint relationship and then render the UI interface.

[0402] Terminal 1000 may further include an input device 1030 for receiving input digital information, character information, or contact touch operations / non-contact gestures, and generating signal inputs related to user settings and function control of terminal 1000. Specifically, in this embodiment of the invention, the input device 1030 may include a touch panel 1031. The touch panel 1031, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel 1031), and drive corresponding connection devices according to a pre-set program. Optionally, the touch panel 1031 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 1050, and can also receive and execute commands sent by the processor 1050. For example, when a user taps a virtual button on the touch panel 1031 with their finger, the touch detection device detects the signal generated by the tap and then transmits the signal to the touch controller. The touch controller then converts the signal into coordinates and sends them to the processor 1050. The processor 1050 performs the corresponding operation based on the coordinates and the type of the signal (single or double tap) and displays the operation result on the display panel 1041.

[0403] The touch panel 1031 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 1031, the input device 1030 may also include other input devices 1032, which may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0404] Terminal 1000 may also include a display device 1040, which includes a display panel 1041 for displaying information input by the user or information provided to the user, as well as various menu interfaces of terminal 1000. It is understood that any content displayed on display device 1040 requires UI rendering, and before rendering, the aforementioned UI adaptive constraint solving method must be executed. The specific process can be found in [reference needed]. Figure 3 The corresponding description of the method embodiment is shown below. The display device 1040 may include a display panel 1041, which may optionally be configured as a liquid crystal display (LCD) or an organic light-emitting diode (OLED). In some other embodiments, a touch panel 1031 may cover the display panel 1041 to form a touch display screen.

[0405] In addition to the above, terminal 1000 may also include a power supply 1090 for powering other modules, a camera 1060 for taking photos or videos, a positioning module (such as GPS) 1061 for obtaining the terminal's geographical location, a gyroscope 1062 for obtaining the terminal's orientation (such as angle, orientation, etc.), and a timer 1063 for recording time. Terminal 1000 may also include one or more sensors 1020, such as an accelerometer or a light sensor. Terminal 1000 may also include a radio frequency (RF) circuit 1010 for network communication with wireless network devices, and may also include a WiFi module 1070 for WiFi communication with other devices.

[0406] The above mainly introduces the specific process of the method provided by the embodiments of the present invention. The following will combine... Figure 11 Taking the Android operating system as an example, this paper introduces the implementation location and runtime state of the method provided in the embodiments of the present invention. For more specific method flow, please refer to the foregoing embodiments.

[0407] Please see Figure 11This is a schematic diagram of the structure of a terminal 1100 provided in an embodiment of the present invention. The terminal 1100 can be a device according to an embodiment of the present invention. The terminal 1100 includes an application layer 1110 and an operating system layer 1150, which can be an Android operating system. The operating system layer 1150 is further divided into a framework layer 1120, a core library layer 1130, and a driver layer 1140. Figure 11 The operating system layer 1150 in the middle can be considered as Figure 10 A specific implementation of the OS / 1082, Figure 11 The application layer 1110 in the middle can be considered as Figure 10 This is a specific implementation of application 1081. The driver layer 1140 includes a CPU driver 1141, a GPU driver 1142, a display controller driver 1143, a positioning module driver 1144, a gyroscope driver 1145, and a timer driver 1146, etc. The core library layer 1130 is the core part of the operating system, including input / output services 1131, core services 1132, media services 1134, etc. The media service 1143 contains a JPEG image library 1, a PNG image library 2, and image libraries of other formats. The media service 1143 also includes an algorithm library, which stores algorithms related to image processing in this invention, such as algorithms for selecting a first image and algorithms for selecting a reference image. The framework layer 1120 may include a graphics service 1124, a system service 1121, a web service 1122, and a customer service 1123, etc.; the graphics service 1124 may include image encoding codecs, video encoding codecs, and audio encoding codecs, etc., and the present invention applies image encoding. The application layer 1110 may include a gallery 1111, a media player 1112, and a browser 1113, etc.

[0408] In addition, below the driver layer 1140, the computer system 1100 also includes a hardware layer 1160. The hardware layer 1160 of the computer system 1100 may include a central processing unit (CPU) 1151 and a graphics processing unit (GPU) 1152 (equivalent to...). Figure 10 The processor 1050 (a specific implementation of the processor) may also include a memory 1153 (equivalent to...). Figure 10 The memory 1080 in the middle includes main memory and secondary memory, and may also include a positioning module 1154 (equivalent to Figure 10The positioning module 1061 and the gyroscope 1155 (equivalent to) Figure 10 The display device 1602 in the middle may also include a timer 1156 (equivalent to...). Figure 10 The timer 1063 in the memory can also include one or more sensors (equivalent to...). Figure 10 (Sensor 1020 in the middle). Of course, in addition to this, the hardware layer 1160 may also include... Figure 10 The power supply, camera, RF circuitry, and WiFi module shown may also include Figure 10 Other hardware modules, such as memory controllers and display controllers, are not shown in the diagram.

[0409] This invention also provides a chip system, which includes at least one processor, a memory, and interface circuitry. The memory, the transceiver, and the at least one processor are interconnected via circuitry. The at least one memory stores a computer program. When the computer program is executed by the processor, it implements... Figure 3 The method flow is shown.

[0410] This invention also provides a computer-readable storage medium storing a computer program that, when executed on a processor, implements... Figure 3 The method flow shown is thus implemented.

[0411] This invention also provides a computer program product that, when run on a processor, implements... Figure 3 The method flow is shown.

[0412] In summary, by implementing the embodiments of the present invention, the constraint relationships of multiple UI interfaces are divided into a first type and a second type. The first type of constraint relationships are solved in the IDE, while the second type of constraint relationships can be solved on the terminal. Using this mechanism, most of the solving operations can be completed on the IDE, thus significantly reducing the computational burden on the terminal when rendering UI interfaces, thereby improving the efficiency of UI interface rendering. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program using computer program-related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing computer program code, such as ROM or RAM, magnetic disks, or optical disks.

Claims

1. A UI interface adaptive constraint solving method, characterized in that, include: Obtain multiple constraint relationships in the user interface (UI) interface, wherein the multiple constraint relationships are used to determine the layout of one or more components in the UI interface; A first intermediate solution set is calculated based on the first type of constraint relationship among the plurality of constraint relationships. The first type of constraint relationship is the constraint relationship solved in the integrated development environment (IDE). The first intermediate solution set is used together with the second type of constraint relationship among the plurality of constraint relationships to determine the layout of one or more components in the UI interface. The second type of constraint relationship is the constraint relationship solved in the terminal or the IDE. The second type of constraint relationship includes constraint relationships involving the display scene, or the second type of constraint relationship includes constraint relationships that require the use of data from the terminal.

2. The method according to claim 1, characterized in that, Also includes: The second type of constraint relation is identified by keywords in each constraint relation. The keywords are used to indicate that the constraint relation is a constraint relation involving the display scene or to indicate that the solution of the constraint relation requires the use of the terminal's data. Constraint relations that do not contain the keywords are constraint relations of the first type.

3. The method according to claim 1 or 2, characterized in that, The display scenarios include at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

4. The method according to claim 1 or 2, characterized in that, The terminal's data includes the terminal's device parameters and the data generated during the terminal's operation.

5. The method according to claim 4, characterized in that, Also includes: Calculate constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and the constraint relationship of the second type.

6. The method according to claim 5, characterized in that, The second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data. M, N, and P are all positive integers; The computational constraint solution information includes: Based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes, M second intermediate solution sets are calculated. Different second intermediate solution sets use different constraint relationships of the display scenes during calculation. The constraint solution information includes the constraint relationships of the M second intermediate solution sets and the N device parameters, wherein the constraint relationships of the N device parameters are the constraint relationships of the terminal's device parameters.

7. The method according to claim 5, characterized in that, The second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data. M, N, and P are all positive integers; The computational constraint solution information includes: One or more third pieces of information are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different third pieces of information use different device parameters when calculating them. The constraint solution information includes the multiple third pieces of information.

8. The method according to claim 5, characterized in that, The second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data. M, N, and P are all positive integers; The computational constraint solution information includes: One or more fourth pieces of information are calculated based on the constraint relationships of the P runtime-generated data, the M second intermediate solution sets, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different fourth pieces of information use different second intermediate solution sets or device parameters for calculation. The M second intermediate solution sets are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes. Different second intermediate solution sets use different constraint relationships of display scenes for calculation. The constraint solution information includes the multiple fourth pieces of information.

9. The method according to claim 1 or 2, characterized in that, The process of obtaining multiple constraint relationships in the user interface (UI) includes: In response to user input, the plurality of constraint relationships are obtained, wherein the input operation includes at least one of drag operation and write operation, the drag operation is used to drag one or more components to a position on the screen, the plurality of constraint relationships are related to the position of the one or more components on the screen, and the write operation is used to write one or more constraint relationships among the plurality of constraint relationships.

10. The method according to claim 1 or 2, characterized in that, Before calculating the first intermediate solution set based on the first type of constraint relationship among the plurality of constraint relationships, the method further includes: The types of the multiple constraint relationships are corrected based on the user's selection operation to determine the constraint relationships belonging to the first type and the constraint relationships belonging to the second type.

11. A method for adaptive constraint solving of a user interface (UI), characterized in that, include: The system receives a resource file, wherein the resource file includes at least one of a first intermediate solution set and constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and a second type of constraint relationship, the first intermediate solution set is determined according to a first type of constraint relationship, the first type of constraint relationship is a constraint relationship solved in an integrated development environment (IDE), and the second type of constraint relationship is a constraint relationship solved on a terminal or the IDE, wherein the constraint relationship is used to describe the layout of one or more components of the UI interface of the terminal; The layout of the components of the terminal's UI interface is determined based on the resource file; The constraint relationships marked with the first keyword are classified into the second type, wherein the constraint relationships marked with the first keyword are constraint relationships of the display scene; The constraint relationships marked with the second keyword are classified into the second type, wherein solving the constraint relationships marked with the second keyword requires the use of the terminal's data.

12. The method according to claim 11, characterized in that, The constraint relationship between the first keyword and the second keyword that is not marked is classified into the first type.

13. The method according to claim 11 or 12, characterized in that, The display scenarios include at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

14. The method according to claim 11 or 12, characterized in that, The terminal's data includes the terminal's device parameters and the data generated during the terminal's operation.

15. The method according to claim 14, characterized in that, The constraints classified into the second type include constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data. M, N, and P are all positive integers; The constraint solution information includes at least two of the following: second information, multiple third information, and multiple fourth information: The second information includes M second intermediate solution sets and the constraint relationships of the N device parameters. Each second intermediate solution set is a solution set calculated based on the constraint relationship of one of the display scenarios from the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenarios. Different second intermediate solution sets use different constraint relationships of the display scenarios in their calculations. The plurality of third information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different device parameters are used when calculating different third information. The plurality of fourth information includes solution information calculated based on the M second intermediate solution sets, the constraint relationships of the N device parameters, and one or more sets of device parameters. The second intermediate solution sets or device parameters used in the calculation of different fourth information are different. The constraint relationships of the N device parameters are the constraint relationships of the device parameters of the terminal.

16. The method according to claim 15, characterized in that, The step of determining the layout of the UI components of the terminal based on the resource file includes: If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to one or more sets of device parameters, then the layout of the terminal's UI interface is determined according to the first intermediate solution set, the constraint relationships of the N device parameters, and the constraint relationships of the P runtime-generated data; or, If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one of the group or more groups of device parameters, then the layout of the UI interface of the terminal is determined according to a third piece of information, wherein the device parameters used to calculate the third piece of information are the same as the device parameters of the terminal; or, If the display scene of the terminal belongs to one of the M display scenes, but the device parameters of the terminal do not belong to any of the group of device parameters, then the layout of the UI interface of the terminal is determined according to a second intermediate solution set in the second information, the constraint relationship of the N device parameters, and the device parameters of the terminal, wherein the calculation of the second intermediate solution set uses the constraint relationship of the display scene of the terminal; or, If the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one of the group or more groups of device parameters, then the layout of the UI interface of the terminal is determined according to a fourth piece of information. The second intermediate solution set used to calculate the fourth piece of information is calculated based on the constraint relationship of the display scene of the terminal, and the device parameters used to calculate the fourth piece of information are the same as the device parameters of the terminal.

17. The method according to claim 14, characterized in that, The constraints classified into the second type include constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data. Before receiving the resource file, the process also includes: Send description information to the server, wherein the description information is used to describe the display scene and device parameters of the terminal; If the server determines that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to any of the one or more sets of device parameters, then the resource file includes the first intermediate solution set, the constraint relationships of the N device parameters, and the constraint relationships of the P runtime-generated data; or, If the server determines that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one of the sets of device parameters, then the resource file includes third information, wherein the third information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and a set of device parameters, wherein the set of device parameters is the same as the device parameters of the terminal; or... If the server determines that the terminal's display scene belongs to one of the M display scenes, but the terminal's device parameters do not belong to any of the sets of device parameters, then the resource file includes a second intermediate solution set and the constraint relationships of the N device parameters. The second intermediate solution set is a solution set calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the terminal's display scene; or, If the server determines that the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one of the group or more groups of device parameters, then the resource file includes a fourth piece of information, wherein the fourth piece of information includes solution information calculated based on the second intermediate solution set, the constraint relationship of the N device parameters, and the group of device parameters, wherein the constraint relationship of the device parameters is the constraint relationship of the terminal's device parameters that is needed for the solution.

18. A user interface (UI) adaptive constraint solving device, characterized in that, include: The first acquisition unit acquires multiple constraint relationships in the user interface (UI), wherein the multiple constraint relationships are used to determine the layout of one or more components in the UI. The calculation unit is configured to calculate a first intermediate solution set based on a first type of constraint relationship among the plurality of constraint relationships. The first type of constraint relationship is a constraint relationship solved in an integrated development environment (IDE). The first intermediate solution set is used together with a second type of constraint relationship among the plurality of constraint relationships to determine the layout of one or more components in the UI interface. The second type of constraint relationship is a constraint relationship solved on a terminal or in the IDE. The second type of constraint relationship includes constraint relationships involving the display scene, or the second type of constraint relationship includes constraint relationships that require the use of data from the terminal.

19. The apparatus according to claim 18, characterized in that, Also includes: The identification unit is used to identify the second type of constraint relationship through keywords in each constraint relationship. The keywords are used to indicate that the constraint relationship is a constraint relationship involving the display scene or to indicate that the solution of the constraint relationship requires the use of the terminal's data. Constraint relationships that do not contain the keywords are constraint relationships of the first type.

20. The apparatus according to claim 18 or 19, characterized in that, The display scenarios include at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

21. The apparatus according to claim 18, characterized in that, The terminal's data includes the terminal's device parameters and the data generated during the terminal's operation.

22. The apparatus according to claim 21, characterized in that, The computing unit is also used for: Calculate constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and the constraint relationship of the second type.

23. The apparatus according to claim 22, characterized in that, The second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers. Regarding the calculation of constraint solution information, the calculation unit is specifically used for: Based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenarios, M second intermediate solution sets are calculated. Different second intermediate solution sets use different constraint relationships of display scenarios during calculation. The constraint solution information includes the constraint relationships of the M second intermediate solution sets and the N device parameters, wherein the constraint relationships of the device parameters are the constraint relationships of the terminal device parameters required for the solution.

24. The apparatus according to claim 22 or 23, characterized in that, The second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers. Regarding the calculation of constraint solution information, the calculation unit is specifically used for: One or more third pieces of information are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different third pieces of information use different device parameters when calculating them. The constraint solution information includes the multiple third pieces of information.

25. The apparatus according to claim 22 or 23, characterized in that, The second type of constraint relationship includes constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data; M, N, and P are all positive integers. Regarding the calculation of constraint solution information, the calculation unit is specifically used for: One or more fourth pieces of information are calculated based on the constraint relationships of the P runtime-generated data, the M second intermediate solution sets, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different fourth pieces of information use different second intermediate solution sets or device parameters for calculation. The M second intermediate solution sets are calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenes. Different second intermediate solution sets use different constraint relationships of display scenes for calculation. The constraint solution information includes the multiple fourth pieces of information.

26. The apparatus according to claim 18 or 19, characterized in that, Regarding the acquisition of multiple constraint relationships in the user interface (UI), the first acquisition unit is specifically used for: In response to user input, the plurality of constraint relationships are obtained, wherein the input operation includes at least one of drag operation and write operation, the drag operation is used to drag one or more components to a position on the screen, the plurality of constraint relationships are related to the position of the one or more components on the screen, and the write operation is used to write one or more constraint relationships among the plurality of constraint relationships.

27. The apparatus according to claim 18 or 19, characterized in that, The device further includes: A correction unit is configured to correct the types of the multiple constraint relationships based on a user-input selection operation before the calculation unit calculates the first intermediate solution set based on the first type of constraint relationship among the multiple constraint relationships, so as to determine the constraint relationships belonging to the first type and the constraint relationships belonging to the second type among the multiple constraint relationships.

28. A user interface (UI) adaptive constraint solving device, characterized in that, include: A receiving unit is configured to receive a resource file, wherein the resource file includes at least one of a first intermediate solution set and constraint solution information, wherein the constraint solution information is solution information calculated based on the first intermediate solution set and a second type of constraint relationship, the first intermediate solution set is determined according to a first type of constraint relationship, the first type of constraint relationship is a constraint relationship solved in an integrated development environment (IDE), and the second type of constraint relationship is a constraint relationship solved on a terminal or the IDE, wherein the constraint relationship is used to describe the layout of one or more components of the UI interface of the terminal; The determining unit is used to determine the layout of the components of the UI interface of the terminal based on the resource file; The constraint relationships marked with the first keyword are classified into the second type, wherein the constraint relationships marked with the first keyword are constraint relationships of the display scene; The constraint relationships marked with the second keyword are classified into the second type, wherein solving the constraint relationships marked with the second keyword requires the use of the terminal's data.

29. The apparatus according to claim 28, characterized in that, The constraint relationship between the first keyword and the second keyword that is not marked is classified into the first type.

30. The apparatus according to claim 28 or 29, characterized in that, The display scenarios include at least one of the following: irregular screen scenario, foldable screen scenario, landscape display scenario, and portrait display scenario.

31. The apparatus according to claim 28 or 29, characterized in that, The terminal's data includes the terminal's device parameters and the data generated during the terminal's operation.

32. The apparatus according to claim 31, characterized in that, The constraints classified into the second type include constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data. M, N, and P are all positive integers; The constraint solution information includes at least two of the following: second information, multiple third information, and multiple fourth information: The second information includes M second intermediate solution sets and the constraint relationships of the N device parameters. Each second intermediate solution set is a solution set calculated based on the constraint relationship of one of the display scenarios from the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the M display scenarios. Different second intermediate solution sets use different constraint relationships of the display scenarios in their calculations. The plurality of third information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and one or more sets of device parameters. Different device parameters are used when calculating different third information. The plurality of fourth information includes solution information calculated based on the M second intermediate solution sets, the constraint relationships of the N device parameters, and one or more sets of device parameters. The second intermediate solution sets or device parameters used in the calculation of different fourth information are different. The constraint relationships of the device parameters are the constraint relationships of the terminal device parameters required for the solution.

33. The apparatus according to claim 32, characterized in that, The determining unit is specifically used to determine the layout of the UI components of the terminal based on the resource file. If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to one or more sets of device parameters, then the layout of the UI interface of the terminal is determined according to the first intermediate solution set, the constraint relationship of the N device parameters and the constraint relationship of the P runtime-generated data. or, If the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one of the group or more groups of device parameters, then the layout of the UI interface of the terminal is determined according to a third piece of information, wherein the device parameters used to calculate the third piece of information are the same as the device parameters of the terminal; or, If the display scene of the terminal belongs to one of the M display scenes, but the device parameters of the terminal do not belong to any of the group of device parameters, then the layout of the UI interface of the terminal is determined according to a second intermediate solution set in the second information, the constraint relationship of the N device parameters, and the device parameters of the terminal, wherein the calculation of the second intermediate solution set uses the constraint relationship of the display scene of the terminal; or, If the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one of the group or more groups of device parameters, then the layout of the UI interface of the terminal is determined according to a fourth piece of information. The second intermediate solution set used to calculate the fourth piece of information is calculated based on the constraint relationship of the display scene of the terminal, and the device parameters used to calculate the fourth piece of information are the same as the device parameters of the terminal.

34. The apparatus according to claim 31, characterized in that, The constraints classified into the second type include constraints on M display scenes, constraints on N device parameters, and constraints on P runtime-generated data. The device further includes: The sending unit is configured to send description information to the server before the receiving unit receives the resource file, wherein the description information is used to describe the display scene and device parameters of the terminal; If the server determines that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal do not belong to any of the one or more sets of device parameters, then the resource file includes the first intermediate solution set, the constraint relationships of the N device parameters, and the constraint relationships of the P runtime-generated data; or, If the server determines that the display scene of the terminal does not belong to any of the M display scenes, and the device parameters of the terminal belong to one of the sets of device parameters, then the resource file includes third information, wherein the third information includes solution information calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, the constraint relationships of the N device parameters, and a set of device parameters, wherein the set of device parameters is the same as the device parameters of the terminal; or... If the server determines that the terminal's display scene belongs to one of the M display scenes, but the terminal's device parameters do not belong to any of the sets of device parameters, then the resource file includes a second intermediate solution set and the constraint relationships of the N device parameters. The second intermediate solution set is a solution set calculated based on the first intermediate solution set, the constraint relationships of the P runtime-generated data, and the constraint relationships of the terminal's display scene; or, If the server determines that the display scene of the terminal belongs to one of the M display scenes, and the device parameters of the terminal belong to one of the group or more groups of device parameters, then the resource file includes a fourth piece of information, wherein the fourth piece of information includes solution information calculated based on the second intermediate solution set, the constraint relationship of the N device parameters, and the group of device parameters, wherein the constraint relationship of the device parameters is the constraint relationship of the terminal's device parameters that is needed for the solution.

35. A device equipped with an integrated development environment (IDE), characterized in that, The apparatus includes a processor and a memory, the memory being used to store a computer program, and the processor being used to invoke the computer program to perform the method according to any one of claims 1-10.

36. A terminal, characterized in that, It includes a processor and a memory, the memory being used to store a computer program, and the processor being used to invoke the computer program to perform the method according to any one of claims 11-17.

37. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a processor, implements the method described in any one of claims 1-17.

Images