Layout file processing method and device, storage medium and electronic equipment

Abstract

The invention discloses a layout file processing method and device, a storage medium and electronic equipment. The method comprises the following steps: when a target application is compiled, obtaining structure information of a target layout file used for rendering a target application picture of the target application; generating target conversion strategy information based on the structure information, wherein a target conversion strategy comprises a first strategy used for indicating to simplify the structure of the target layout file, a second strategy used for indicating to simplify attribute information of the target layout file, and a third strategy used for indicating preprocessing for loading a view component in the target layout file; converting the target layout file into a target data type according to a target conversion strategy; and inserting the target byte code into an application byte code obtained after the target application is compiled. The technical problem of poor interface responsiveness caused by low layout analysis efficiency is solved.

Description

Technical Field

[0001] This application relates to the field of computers, and in particular, to a method and apparatus for processing layout files, a storage medium, and an electronic device. Background Art

[0002] In Android application development, the dynamic parsing of XML layout files and the instantiation of view components are the main reasons for application startup latency and interface lag. In the traditional method, LayoutInflater parses the layout file and creates a View at runtime. The reflection calls and deeply nested view hierarchies involved in this process significantly increase the burden on the UI thread. Especially on low-end devices with limited hardware resources, the user experience is greatly reduced.

[0003] In other words, in the method for processing layout files in the related art, there are still technical problems such as low layout parsing efficiency resulting in poor interface responsiveness.

[0004] For the above problems, no effective solution has been proposed yet. Summary of the Invention

[0005] Embodiments of this application provide a method and apparatus for processing layout files, a storage medium, and an electronic device to at least solve the technical problem of poor interface responsiveness caused by low layout parsing efficiency.

[0006] According to one aspect of the embodiments of this application, a method for processing a layout file is provided, including: when compiling a target application, obtaining structure information of a target layout file for rendering a target application screen of the target application, where the target layout file is used to describe the structure and appearance of the target application screen, and the structure information includes a view hierarchy corresponding to the target layout file and attribute configurations; generating target conversion policy information based on the structure information, where the target conversion policy information is used to guide the conversion of the target layout file to a target data type belonging to a target code structure, and the target conversion policy includes a first policy for indicating simplifying the structure of the target layout file, a second policy for indicating simplifying the attribute information of the target layout file, and a third policy for indicating preprocessing for loading view components in the target layout file; converting the target layout file into the target data type according to the target conversion policy, where each rendering object included in the target data type is used to render each view component in the target layout file; and inserting target bytecode into the application bytecode obtained after compiling the target application, where the target bytecode is used to call the target data type when the target application runs.

[0007] According to another aspect of the embodiments of the present application, there is also provided a processing device for layout files, including: an acquisition unit configured to acquire the structure information of a target layout file for rendering a target application screen when compiling a target application, where the target layout file is used to describe the structure and appearance of the target application screen, and the structure information includes the view hierarchy corresponding to the target layout file and the attribute configuration; a generation unit configured to generate target conversion policy information based on the structure information, where the target conversion policy information is used to guide the conversion of the target layout file into a target data type belonging to the target code structure, and the target conversion policy includes a first policy for indicating simplifying the structure of the target layout file, a second policy for indicating simplifying the attribute information of the target layout file, and a third policy for indicating preprocessing for loading view components in the target layout file; a conversion unit configured to convert the target layout file into the target data type according to the target conversion policy, where each rendering object included in the target data type is used to render each view component in the target layout file; an insertion unit configured to insert target bytecodes into the application bytecodes obtained after compiling the target application, where the target bytecodes are used to call the target data type when the target application runs.

[0008] According to still another aspect of the embodiments of the present application, there is also provided a computer-readable storage medium storing a computer program, where the computer program is configured to execute the above-mentioned layout file processing method when running.

[0009] According to still another aspect of the embodiments of the present application, there is provided a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the layout file processing method as described above.

[0010] According to still another aspect of the embodiments of the present application, there is also provided an electronic device including a memory and a processor, where the memory stores a computer program, and the processor is configured to execute the above-mentioned layout file processing method through the computer program.

[0011] In an embodiment of the present application, when compiling a target application, the structural information of a target layout file for rendering the target application screen of the target application is obtained, where the target layout file is used to describe the structure and appearance of the target application screen, and the structural information includes the view hierarchy and attribute configuration corresponding to the target layout file. Then, based on the structural information, target conversion policy information is generated, where the target conversion policy information is used to guide the conversion of the target layout file to a target data type belonging to the target code structure, and the target conversion policy includes a first policy for indicating simplifying the structure of the target layout file, a second policy for indicating simplifying the attribute information of the target layout file, and a third policy for indicating preprocessing for loading view components in the target layout file. Furthermore, the target layout file is converted into the target data type according to the target conversion policy, where each rendering object included in the target data type is used to render each view component in the target layout file. Then, target bytecode is inserted into the application bytecode obtained after the target application is compiled, where the target bytecode is used to call the target data type when the target application runs. In other words, by adopting the embodiment of the present application, on the one hand, by processing the layout file during compilation, the layout file parsing and reflection instantiation of view components through LayoutInflater during runtime are avoided, thereby greatly reducing the burden on the UI thread. This reduces the occurrence frequency of stuttering (frame drops) and improves the fluency of application startup and interface switching. On the other hand, by simplifying the structure of the target layout file with the first policy and streamlining the attribute information of the target layout file with the second policy, the deeply nested view hierarchy can be reduced, the layout complexity can be lowered, and unnecessary attribute settings can be reduced, thereby improving the parsing and rendering efficiency of the layout. On the one hand, by inserting the target bytecode into the compiled application bytecode, it is ensured that the optimization policy can take effect directly during runtime. The traditional layout loading method is avoided, the UI loading time during initialization and page switching is reduced, and the overall response speed of the application is improved. In summary, the embodiment of the present application successfully solves the technical problem of poor interface responsiveness caused by low efficiency in dynamically parsing layout files by deeply optimizing the layout file during the compilation period, generating an efficient code structure, and calling the optimized rendering object through the target bytecode during runtime, improving the interface responsiveness and overall performance of Android applications on various devices, and providing a smoother application experience for users. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:

[0013] Figure 1It is a flowchart of an optional method for processing a layout file according to an embodiment of the present application;

[0014] Figure 2 It is a schematic diagram of an optional method for processing a layout file according to an embodiment of the present application;

[0015] Figure 3 It is a schematic diagram of another optional method for processing a layout file according to an embodiment of the present application;

[0016] Figure 4 It is a schematic diagram of yet another optional method for processing a layout file according to an embodiment of the present application;

[0017] Figure 5 It is a schematic diagram of yet another optional method for processing a layout file according to an embodiment of the present application;

[0018] Figure 6 It is a schematic diagram of yet another optional method for processing a layout file according to an embodiment of the present application;

[0019] Figure 7 It is a flowchart of an optional method for processing a layout file according to an embodiment of the present application;

[0020] Figure 8 It is a flowchart of another optional method for processing a layout file according to an embodiment of the present application;

[0021] Figure 9 It is a schematic structural diagram of an optional device for processing a layout file according to an embodiment of the present application;

[0022] Figure 10 It is a schematic structural diagram of an optional electronic device according to an embodiment of the present application. Detailed implementation manners

[0023] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0024] It should be noted that the terms "first", "second", etc. in the description, claims and the above-mentioned drawings of this application are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of this application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0025] Optionally, as an alternative solution, as Figure 1 shown, the method for processing the above layout file includes:

[0026] S102, when compiling the target application, obtain the structure information of the target layout file for rendering the target application screen, where the target layout file is used to describe the structure and appearance of the target application screen, and the structure information includes the view hierarchy corresponding to the target layout file and the attribute configuration.

[0027] Optionally, the method for processing the above layout file can be but is not limited to being applied to at least the following scenarios:

[0028] 1) Video playback application: When developing a video playback application, the video details page may include multiple view components such as a video player, a recommended list, user comments, and an advertisement bar. The traditional layout loading method may cause UI lags and long waiting times. By using the method for processing the above layout file, the layout structure can be optimized during compilation, the number of levels can be reduced, similar attributes can be merged, and the loading of view components can be preprocessed, so that the video details page can be quickly loaded and the video can be played smoothly even on low-end devices. At the same time, the loading strategies of the recommended list and user comments can be dynamically adjusted to adapt to different network conditions and device performances.

[0029] 2) E-commerce application: The home page of an e-commerce platform often needs to display a large amount of complex information such as product pictures, sliding advertisements, and product classifications. By using the method for processing the above layout file, the application merges redundant containers during compilation, creates attribute references, and dynamically determines when to load view components, ensuring that the home page is loaded quickly and scrolls smoothly. Even in the case of unstable networks or limited hardware resources, key information such as product pictures and classifications can be preferentially displayed, while the loading of advertisements and detailed product information is delayed, providing a faster first-screen loading speed and a better user experience.

[0030] 3) Social applications: The dynamic timeline page of social applications usually contains dynamic content such as user avatars, status updates, comments, and pictures. The loading of this content will affect the response speed of the application. Through the above processing method of the layout file, it is possible to preprocess the layout, optimize the view hierarchy, and create static substitutes for dynamic view components. For example, if the device performance is low, the user avatar and status update can be loaded first, while the loading of comments and pictures can be delayed until the user scrolls to the visible area; at the same time, it also ensures consistency and efficiency on different devices, avoiding the problem of slow loading of complex layouts on low-end devices.

[0031] It should be noted that the processing logic code of each operation in steps S102 to S108 can be written into a Software Development Kit (SDK). Then, when the application is compiled, the SDK automatically completes the above steps without the need for relevant technical personnel to operate manually, thereby greatly improving the processing efficiency of the layout file.

[0032] Optionally, the above target layout file can be used but is not limited to indicating an Extensible Markup Language (XML) layout file. The XML layout file is a file format used to define the interface layout of Android application programs. It contains the definitions of the positions, sizes, styles, and other attributes of each element in the interface, and can describe the interface layout of the application program through XML syntax.

[0033] Furthermore, the structural information of the target layout file for obtaining the target application screen for rendering the target application can be but is not limited to including: at compile time, the system (such as the SDK) scans the resource file directory of the target application to identify all XML layout files. For each target layout file, the SDK uses an XML parser to read its content one by one, extracting the hierarchical structure of view components (such as LinearLayout, TextView, ImageView, etc.) and the attribute information of each component (such as width, height, background, text, etc.). For example, suppose there is an activity_main.xml layout file that contains a LinearLayout as the root container, with multiple TextView and ImageView components nested inside. The SDK reads this file during compilation, parses out the hierarchical structures of LinearLayout and its child components TextView and ImageView, and at the same time extracts the attribute information of each component.

[0034] S104. Generate target conversion strategy information based on the structure information, where the target conversion strategy information is used to guide the conversion of the target layout file into a target data type belonging to the target code structure. The target conversion strategy includes a first strategy for indicating simplifying the structure of the target layout file, a second strategy for indicating simplifying the attribute information of the target layout file, and a third strategy for indicating preprocessing the loading of view components in the target layout file.

[0035] It should be noted that the above first strategy can be but is not limited to simplifying the layout file structure. For example, merging redundant containers, merging duplicate LinearLayouts or FrameLayouts, or converting multiple RelativeLayouts or ConstraintLayouts into simpler or more complex containers to reduce the view hierarchy, etc.; the above second strategy is used to simplify the attribute information of the layout file. For example, creating a unified attribute reference for duplicate attributes to avoid setting each view component separately; converting dynamic attributes into static attributes to reduce the computational overhead during runtime, etc.; the above third strategy is used to preprocess the loading of view components.

[0036] Specifically, the above generating target conversion strategy information based on the structure information can be but is not limited to including: generating the first strategy based on the structure information; generating the second strategy based on the structure information; generating the third strategy based on the structure information.

[0037] S106. Convert the target layout file into the target data type according to the target conversion strategy, where each rendering object included in the target data type is used to render each view component in the target layout file.

[0038] Optionally, the above target data type can be but is not limited to indicating a JAVA class. In this embodiment, each layout file can be converted into a JAVA class. Specifically, during the compilation stage, according to the target conversion strategy information, the SDK will convert the XML layout file into an equivalent Java class. Each XML layout file will generate an independent Java class, which internally instantiates and initializes each view component and sets its attributes.

[0039] It should be noted that when converting the target layout file into the target data type according to the target conversion strategy, the initialization process of view objects can be unified through the abstract factory pattern or the builder pattern to reduce code duplication. For example, generating initialization code in batches for similar view objects (such as multiple TextViews), and also reducing duplicate code generation through loops or the factory pattern.

[0040] Among them, the factory pattern here is used to indicate the creation of a centralized object creation mechanism, which can generate view objects of specific types according to different parameters. For example, when dealing with the initialization of multiple TextViews, a TextViewFactory can be used. This factory generates TextView instances with unified attributes according to predefined parameters such as text styles, sizes, and colors. In this way, whether it is necessary to create a single TextView or multiple TextViews with similar attributes, it can be achieved by calling the factory method, which not only simplifies the code but also ensures the consistency of attributes and optimized efficiency. The builder pattern here is used to indicate that when creating view objects, the initialization process of the object can be more finely controlled through the builder pattern. The builder pattern allows for the gradual construction of a complex object, especially suitable for view components with multiple optional parameters. For example, for a complex LinearLayout that contains multiple child views, each with unique attribute settings, a LinearLayoutBuilder can be used to gradually add and configure the child views to ensure that the attributes of each child view can be correctly initialized, while the code structure is clear and easy to maintain. The loop pattern here is used to indicate that when dealing with multiple view objects with the same or similar attributes, loops can be used to batch generate initialization code to reduce code repetition. For example, if the layout file contains multiple ImageViews, each of which displays an image of the same size and shape, a loop can be used to iterate through all the ImageViews and generate the initialization code for each ImageView in the loop body, including setting the image resource, size, and position. In this way, not only is the amount of code reduced, but also the attribute settings of each ImageView are ensured to be consistent, improving the robustness and readability of the code.

[0041] S108, insert target bytecode into the application bytecode obtained after the target application is compiled, where the target bytecode is used to call the target data type when the target application runs.

[0042] It should be noted that the above target bytecode can be used but is not limited to indicating that the SDK intercepts the layout loading function (such as setContentView), and the call of this intercepted layout function is redirected to the JAVA class obtained after the XML layout file is transformed, thus avoiding the LayoutInflater reflection parsing process during runtime. This operation enables the application to directly call efficient Java code when loading the page, avoiding traditional XML parsing and reflection calls, thereby reducing the startup time and the burden on the UI thread.

[0043] In an embodiment of the present application, when compiling a target application, structure information of a target layout file for rendering a target application screen of the target application is obtained. The target layout file is used to describe the structure and appearance of the target application screen, and the structure information includes a view hierarchy corresponding to the target layout file and attribute configurations. Then, target conversion policy information is generated based on the structure information. The target conversion policy information is used to guide the conversion of the target layout file into a target data type belonging to the target code structure. The target conversion policy includes a first policy for indicating simplifying the structure of the target layout file, a second policy for indicating simplifying the attribute information of the target layout file, and a third policy for indicating preprocessing for loading view components in the target layout file. Furthermore, the target layout file is converted into the target data type according to the target conversion policy, where each rendering object included in the target data type is used to render each view component in the target layout file. Next, target bytecode is inserted into the application bytecode obtained after compiling the target application, where the target bytecode is used to call the target data type when the target application runs. In other words, in the embodiment of the present application, on the one hand, by processing the layout file during compilation, the layout file parsing and reflection instantiation of view components through LayoutInflater during runtime are avoided, thus greatly reducing the burden on the UI thread. This reduces the occurrence frequency of stuttering (frame drops) and improves the fluency of application startup and interface switching. On the other hand, by simplifying the structure of the target layout file with the first policy and streamlining the attribute information of the target layout file with the second policy, the deeply nested view hierarchy can be reduced, the layout complexity can be lowered, and unnecessary attribute settings can be reduced, thereby improving the parsing and rendering efficiency of the layout. On the other hand, by inserting the target bytecode into the compiled application bytecode, it is ensured that the optimization policy can take effect directly during runtime. The traditional layout loading method is avoided, the UI loading time during initialization and page switching is reduced, and the overall response speed of the application is improved. In summary, the embodiment of the present application successfully solves the technical problem of poor interface responsiveness caused by low efficiency in dynamically parsing layout files by deeply optimizing the layout file during compilation, generating an efficient code structure, and calling the optimized rendering object through the target bytecode during runtime, improving the interface responsiveness and overall performance of Android applications on various devices and providing a smoother application experience for users.

[0044] Optionally, as an alternative solution, generating the target conversion policy information based on the structure information includes:

[0045] Determining a first sub-policy for indicating adding view components in a redundant container in the target layout file to the upper-level container file of the redundant container and removing the redundant container file.

[0046] It should be noted that in a layout file, if a container (such as LinearLayout or FrameLayout) contains only one child element or its function can be replaced by an upper-level container, then this container is considered redundant, providing no additional layout effects or value, but instead increasing the layout complexity and rendering cost.

[0047] Specifically, the above-mentioned specific implementation manner for determining to indicate adding the view components in the redundant containers in the target layout file to the upper-level container file of the redundant containers may include, but is not limited to: during compilation, the SDK analyzes the layout file to identify those redundant containers that contain only one child element or whose functions can be replaced by an upper-level container. For example, if there is only one child View in a LinearLayout, the SDK will directly place this child View into the upper-level container and remove this LinearLayout container. For example, as Figure 2 shown in (a) below, assume that a layout file contains a container A with only one element 1 inside. The SDK will Figure 2 as shown in (b) below directly move the element 1 to the upper-level container of container A, that is, container B, and remove container A, thereby reducing the layout level and optimizing the rendering performance.

[0048] It should be noted that the above examples and implementation manners are optional examples and implementation manners provided for the convenience of explaining the above steps, and there is no limitation on the method for processing the above layout file.

[0049] Determine a second sub-strategy for indicating merging multiple first-type containers arranged vertically in the target layout file into the same first-type container.

[0050] Optionally, the above first-type container can be used to indicate a container for arranging child elements vertically, such as LinearLayout. Specifically, the above-mentioned second sub-strategy for determining to indicate merging multiple first-type containers arranged vertically in the target layout file into the same first-type container may include, but is not limited to, the following steps:

[0051] Analyze the layout file, merge consecutive LinearLayout containers in the vertical direction into a large LinearLayout container, and consider the layout_weight and gravity attributes between views during the merging process to ensure that the behavior of the merged container is consistent with the original behavior. For example, as Figure 3 shown in (a) below, there are two consecutive LinearLayouts in the layout file, namely LinearLayoutA and LinearLayoutB, both set to be arranged vertically and each containing some child Views. The SDK will identify these two LinearLayouts, asFigure 3 In (b), merge them into a large LinearLayout C, and recalculate the arrangement rules of the child views according to the weight and gravity attributes in the original layout file to simplify the layout structure.

[0052] It should be noted that the above examples and implementation manners are optional examples and implementation manners provided for facilitating the explanation of the above steps, and there is no limitation on the processing method of the above layout file.

[0053] Determine a third sub-strategy for instructing to merge multiple first-type container files that meet the merging conditions into a second-type container; wherein, the first-type container is used for vertically arranging child elements, and the second-type container is used for relative positioning between view components.

[0054] It should be noted that the above second-type container refers to a container for positioning the relative positions between view components, such as RelativeLayout or ConstraintLayout, which can provide more complex layout effects, such as positioning a view based on other views.

[0055] Specifically, the above-mentioned determination of the third sub-strategy for instructing to merge multiple first-type container files that meet the merging conditions into a second-type container can be implemented through the following steps:

[0056] The SDK analyzes the layout file, converts multiple first-type containers (LinearLayout) that meet certain conditions (such as overly complex nested levels, that is, the number of nested levels exceeds the level threshold), and merges them into a second-type container (such as ConstraintLayout), which can reduce the nested levels and improve the layout parsing efficiency. For example, the layout file contains multiple consecutive LinearLayouts, each arranged vertically. If there are complex nested relationships among these LinearLayouts, the SDK will convert them into a ConstraintLayout to present the same effect through more concise layout rules.

[0057] It should be noted that the above examples and implementation manners are optional examples and implementation manners provided for facilitating the explanation of the above steps, and there is no limitation on the processing method of the above layout file.

[0058] Determine a fourth sub-strategy for instructing to convert the circular dependency relationship between view components in the second-type container into a linear dependency relationship, wherein the circular dependency relationship is used to indicate the mutual dependency positioning relationship between view components.

[0059] Optionally, the above circular dependencies can be used, but are not limited to, indicating that in a layout file, if there are positioning relationships where view components depend on each other, i.e., the positioning of element A depends on element B, while the positioning of element B depends on element A, forming a circular dependency. This will increase the complexity of layout parsing and sometimes even cause parsing errors.

[0060] Specifically, the above-mentioned fourth sub-strategy for determining the conversion of circular dependencies between view components in the second type of container into linear dependencies can be implemented through the following steps:

[0061] In the second type of container (such as RelativeLayout or ConstraintLayout), the SDK identifies and parses circular dependencies through algorithms and converts them into linear dependencies to simplify the layout parsing process. For example, in a RelativeLayout, as Figure 4 shown, component A depends on component B, component B depends on component C, but component C depends on component A. Among them, this mutual dependence on the positioning rules forms a circular dependency. The SDK will adjust the dependency rules and adjust them into a linear form. For example, as Figure 5 shown, let component A depend on component B, component B depend on C, but no longer let component C depend on component A, thus solving the circular dependency problem.

[0062] It should be noted that the above examples and implementation methods are optional examples and implementation methods provided for the convenience of explaining the above steps, and there is no limitation on the above method for processing layout files.

[0063] Determine the fifth sub-strategy for indicating the removal of redundant dependency relationships between view components in the second type of container, where the redundant dependency relationship is used to indicate the repeated dependency positioning relationships corresponding to view elements.

[0064] Optionally, the above redundant dependency relationship means that in a layout, if the positioning rule of a view component can be deduced from other existing rules, then this additional positioning rule is redundant, increasing the complexity of the layout and the parsing time.

[0065] Specifically, the above-mentioned fifth sub-strategy for determining the removal of redundant dependency relationships between view components in the second type of container can be implemented through the following steps:

[0066] The SDK analyzes the layout file, identifies and removes those redundant dependency relationships that can be replaced by other dependency rules, and optimizes the parsing and rendering efficiency of the layout. For example, assume that as Figure 6 shown in (a), component A depends on component B, and component A also depends on component C. Then the redundant dependency relationship needs to be removed. For example, asFigure 6 As shown in (b), the dependency of Component A on Component B is removed. For another example, if a TextView depends on the right side of a Button, and the Button is already fixed on the left side of the screen, then the part in the positioning rule of the TextView that depends on the right side of the Button is redundant, and the SDK will directly remove this part of the dependency to simplify the layout parsing.

[0067] It should be noted that the above examples and implementation manners are optional examples and implementation manners provided for facilitating the explanation of the above steps, and there is no limitation on the method for processing the above layout file.

[0068] Determine a sixth sub-strategy for indicating converting a first sub-class container that meets the conversion condition into a first-class container or a third-class container, where the second-class container includes a first sub-class container and a second sub-class container, the layout simplicity of the first sub-class container is higher than that of the second sub-class container, and the third-class container is used to stack and configure multiple view components at the same position.

[0069] It should be noted that the above first sub-class container can be used to indicate RelativeLayout, the above second sub-class container can be used to indicate ConstraintLayout, and the above third-class container is used to indicate FrameLayout.

[0070] Specifically, the above determination of the sixth sub-strategy for indicating converting a first sub-class container that meets the conversion condition into a first-class container or a third-class container can be implemented through the following steps:

[0071] Based on layout requirements and efficiency improvement considerations, the SDK will convert the first subclass container (such as RelativeLayoutc) that meets the conversion conditions into the first type of container (such as LinearLayout) or the third type of container (such as FrameLayout) to improve the layout adaptability and rendering performance. Among them, the above conversion conditions can include but are not limited to: the arrangement of view components: If the components in the RelativeLayout are mainly arranged vertically or horizontally and there is no complex relative positioning requirement, the SDK may convert the RelativeLayout into a LinearLayout because the LinearLayout is more efficient in handling linearly arranged components. It avoids the complex dependency resolution in the RelativeLayout and reduces the layout calculation time. The overlapping situation of view components: For scenarios where multiple view components need to be overlaid or stacked on the screen, the SDK may choose to convert the RelativeLayout or LinearLayout into a FrameLayout. The FrameLayout allows views to be directly stacked without considering the relative positioning between components, which is suitable for scenarios that need to display dynamic overlays (such as dialog boxes, prompt messages), simplifies the layout, and improves the rendering speed. Performance and compatibility: The SDK will determine the conversion type of the container according to the hardware performance and Android version of the target device. For example, for devices with lower performance, the SDK may tend to use simpler layout containers such as LinearLayout or FrameLayout to reduce the CPU overhead of layout calculation and rendering. For high-performance devices, the SDK may keep the RelativeLayout or use more complex containers such as ConstraintLayout to achieve more complex interface effects and higher performance ceilings. Layout efficiency and maintenance cost: The SDK will also consider the efficiency after layout optimization and the convenience of later maintenance. For example, if the component dependency in the RelativeLayout is too complex, the SDK may convert it into a LinearLayout or FrameLayout to simplify the layout code and reduce the complexity of later maintenance. On the contrary, for scenarios where the maintenance cost is not the main consideration factor but the efficiency improvement is crucial, the SDK may keep or optimize the RelativeLayout and use more advanced layout optimization algorithms.

[0072] For example, if the views in a RelativeLayout are only arranged vertically, the SDK will convert it into a LinearLayout to improve the rendering efficiency.

[0073] It should be noted that the above examples and implementation manners are optional examples and implementation manners provided for facilitating the explanation of the above steps, and there is no limitation on the method for processing the above layout file.

[0074] Among them, the first strategy includes a first sub-strategy, a second sub-strategy, a third sub-strategy, a fourth sub-strategy, a fifth sub-strategy, and a sixth sub-strategy.

[0075] In the embodiment of the present application, on the one hand, by determining the first sub-strategy, the view components in the redundant containers in the XML layout file are merged into the containers at the upper level, and the redundant containers are removed. This strategy reduces unnecessary view levels, simplifies the layout structure, thereby reducing the rendering complexity, reducing the processing burden on the UI thread, and improving the startup speed and interface response performance of the application. On the other hand, the second sub-strategy allows multiple first-class containers (such as LinearLayout) arranged vertically to be merged into the same container. This merging reduces the number of containers, avoids excessive nesting, and improves the efficiency of layout parsing and rendering. Especially when there are multiple vertically arranged containers with similar levels in the layout file, the effect is particularly significant. On the one hand again, the third sub-strategy is used to convert and merge multiple first-class container files that meet the conditions into a second-class container (such as ConstraintLayout or RelativeLayout). This conversion optimizes the arrangement method of the layout, uses more efficient layout controls, improves the rendering speed of the layout, and at the same time keeps the visual effect of the layout unchanged, improving the compatibility and performance of the application on different devices. On the one hand again, the fourth sub-strategy and the fifth sub-strategy are respectively used to convert the circular dependencies between the view components in the second-class container into linear dependencies and remove redundant dependency relationships. These strategies solve the common dependency conflicts and repeated positioning problems in the layout, ensure that the positioning logic of each view component is clearer and more efficient, avoid additional calculations during the layout parsing process, and improve the loading and drawing speed of the layout. On the one hand again, the sixth sub-strategy is used to convert the first-subclass container that meets the conversion conditions into a first-class container or a third-class container. This conversion intelligently selects a more suitable container type for layout optimization according to the layout requirements and efficiency improvement considerations. For example, some containers are converted into lighter or more complex but more efficient container types to ensure the adaptability and rendering performance of the layout.

[0076] Optionally, as an alternative solution, generating the target conversion strategy information based on the structure information further includes:

[0077] Determining a seventh sub-strategy for indicating to create an attribute reference object for multiple view components whose attribute information in the target layout file matches each other.

[0078] It should be noted that the role of the seventh sub-strategy is to identify multiple view components in the target layout file whose attribute information matches each other and create an attribute reference object. This means that if multiple View components share the same attributes (such as background color, margin, font style, etc.), the system will not set these attributes separately for each component, but create a unified attribute reference object, which can be referenced by all relevant components. This strategy significantly reduces the repeated setting of attributes in the code, reduces memory consumption, improves the execution efficiency of the code, and simplifies the code structure of the layout file.

[0079] Optionally, the above steps can be implemented but are not limited to the following steps: S1, Attribute Recognition: Traverse the layout file and collect the attribute information of all view components. S2, Attribute Matching: Compare the attributes of different view components and identify which components share the same attributes. S3, Reference Object Creation: Create a reference object for the shared attributes, which can be a style definition in a resource file or a ViewGroup containing all the shared attributes. S4, Code Generation: In the generated Java code, use this reference object to replace the repeated setting of all shared attributes. For example, if multiple TextViews have the same text style, the SDK will generate a style reference and reference this style in the initialization code of the TextView, rather than repeatedly setting the font, size, and color of each TextView.

[0080] It should be noted that the above implementation is an optional implementation provided for the convenience of explaining the above steps, and there is no limitation on the method for processing the above layout file.

[0081] In the case where it is determined that there are dynamic view components in the target layout file, an eighth sub-strategy for indicating that no code conversion operation needs to be performed on the dynamic view components is determined. Among them, in the case where the target account used to request the display of the application screen where the dynamic view component is located does not meet the target conditions, the sub-screen corresponding to the view component will not be displayed on the application screen.

[0082] It should be noted that the above dynamic view components can be but are not limited to views used to indicate that their content is dynamically generated or modified according to real-time data or user behavior, such as scrolling news titles, user comment lists, dynamically loaded advertisement spaces, etc.

[0083] Furthermore, the above target account can be but is not limited to a parameter set used to indicate conditions such as device performance, network status, or user preferences. The SDK dynamically adjusts the layout and view loading strategies based on these conditions. The above target conditions can be but are not limited to the account information of the target account, such as account level, account preferences, etc. When these conditions are not met, the SDK will take measures to simplify or disable the loading of dynamic view components.

[0084] Among them, the second strategy includes a seventh sub-strategy and an eighth sub-strategy.

[0085] In the embodiments of the present application, on the one hand, the role of the seventh sub-strategy is to identify multiple view components in the target layout file whose attribute information matches each other and create an attribute reference object. This means that if multiple View components share the same attributes (such as background color, margin, font style, etc.), the system will not set these attributes separately for each component, but create a unified attribute reference object, which can be referenced by all relevant components. This strategy significantly reduces the duplicate setting of attributes in the code, reduces memory consumption, improves the execution efficiency of the code, and simplifies the code structure of the layout file. On the other hand, the eighth sub-strategy allows the SDK to identify and mark dynamic view components in the layout. These components usually contain dynamic content (such as live streams, scrolling news headlines, etc.) that depends on real-time data or user interactions. In the code conversion stage, the SDK does not generate static layout code for these dynamic view components, but retains their dynamic loading ability, thereby reducing the development complexity and cost.

[0086] Optionally, as an alternative solution, generating the target conversion strategy information based on the structure information further includes:

[0087] Determining a ninth sub-strategy for indicating adding the mapping relationship between the identification information of each view component in the target layout file and the reference object of each view component to the target data type.

[0088] It should be noted that the above identification information can be, but is not limited to, used to indicate the unique identifier (id) assigned to view components (such as TextView, ImageView) in the layout file, for referencing and operating these view components in the code. The above reference object is an instance and creation of a reference for each view component in the Java code generated by the SDK, enabling developers to directly operate the components through these references without dynamically searching or creating them at runtime. The above mapping relationship is that in the compilation stage, the SDK creates a mapping table to associate the id of the view component with the corresponding Java reference object for quickly and accurately accessing and operating the components at runtime.

[0089] Optionally, the ninth sub-strategy for determining to add the mapping relationship between the identification information of each view component in the target layout file and the reference object of each view component to the target data type may but is not limited to indicating that: during the compilation phase, the SDK analyzes the view components in the target layout file and establishes a mapping relationship between its id attribute and the view reference object in the newly generated Java class. This mapping pre-exists in the JAVA class, facilitating quick access to these views during runtime and avoiding the overhead of dynamically searching for views through mechanisms such as reflection.

[0090] Determine the tenth sub-strategy for determining to add the attribute measurement results of each view component in the target layout file to the target data type, where the attribute measurement results include the size and position information of the view component;

[0091] Optionally, the above attribute measurement results may but are not limited to indicating the final size (width, height) and position information of the view component calculated by the SDK. These information are used to determine the final position and size of the component for rendering during the application runtime.

[0092] In the case where it is determined that there are complex view components in the target layout file with a view complexity exceeding the first complexity, determine the eleventh sub-strategy for converting the complex view components into simplified view components, where the complex view components are used for rendering the screen on devices where the performance parameters meet the target performance conditions, and the above simplified view components are used for rendering the screen on devices where the performance parameters do not meet the target performance conditions. The view complexity of the simplified view components is the second complexity, the first complexity is higher than the second complexity, and the higher the complexity, the fewer the nested levels, the fewer the attribute information, and the fewer the animation effects in the view components.

[0093] It should be noted that the above view complexity is a parameter value determined based on attributes such as the nested levels of the view components, the number of set attributes, and the animation effects that affect the rendering performance. The higher the complexity, the higher the requirement for device performance. Further, the above first complexity is a preset complexity threshold. When the complexity of a certain view component in the layout file exceeds this threshold, the SDK will consider whether it is necessary to convert it into a simplified view component.

[0094] Optionally, compared with the complex view components, the above-mentioned simplified view components have components with lower complexity, usually manifested as fewer nested levels, simpler property settings, and reduction or removal of animation effects. This simplification helps reduce the rendering overhead and improve the performance of the application on low-end devices. The above-mentioned second complexity is the complexity standard of the simplified view components, which is lower than the first complexity, enabling the simplified view components to be rendered with better performance on performance-constrained devices and providing a smooth user experience. For example, the SDK will reduce unnecessary animation effects and the number of views in the dynamic view components and simplify complex view property settings (such as reducing transparency, shadow effects, etc.) to obtain the above-mentioned static view components, ensuring that the layout code can run efficiently on low-end devices and reducing memory and CPU overhead.

[0095] Among them, the third strategy includes the ninth sub-strategy, the tenth sub-strategy, and the eleventh strategy.

[0096] In the embodiments of the present application, on the one hand, the ninth sub-strategy pre-creates the mapping relationship between the identification information of the view component and the reference object during the compilation phase and directly adds these mappings to the target data type, thus avoiding the lookup and instantiation overhead during runtime. During the runtime of the application, the SDK can directly access and reference the view component according to the stored mapping relationship, significantly reducing the burden on the UI thread. By completing the creation of the mapping relationship during compilation, the application can directly call the initialized view object during runtime, reducing the complexity of the code execution path and making the layout loading process more efficient. On the other hand, the tenth sub-strategy effectively avoids the measurement operation during runtime, reduces the overhead of the UI thread, and ensures the smoothness of UI rendering. Further, since the property measurement results have been preprocessed and stored in the target data type, the application does not need to perform real-time measurement when loading the interface, thus significantly improving the loading speed of the interface. This is particularly effective in enhancing the user experience, especially on low-end devices with limited hardware resources. On the other hand, the eleventh sub-strategy can automatically identify and convert complex view components whose view complexity exceeds the first complexity into simplified view components. The simplified view components have a lower second complexity, that is, fewer nested levels, simpler property settings, and omission or reduction of animation effects, thus significantly reducing the processing overhead of the CPU and GPU, ensuring that the application on low-performance devices can start quickly and run smoothly, and avoiding the decline in user experience caused by device performance limitations.

[0097] Optionally, as an alternative solution, inserting target bytecode into the application bytecode obtained after compiling the target application further includes:

[0098] S1. When receiving a request message for requesting to display a target application screen of a running target application, call a target rendering object in a target data type that matches a view component requested to be displayed in the target application screen through a target bytecode in an application bytecode of the target application.

[0099] It should be noted that the above target rendering object is an optimized object in the target data type for directly rendering view components at runtime, avoiding the traditional reflection call and XML parsing processes. The above target application screen is any interface requested to be displayed by a user in the target application and consists of multiple view components. The above request message is a signal or information received by the application when the user triggers an interface display request, which can be a user operation (such as clicking or swiping) or an internal event of the application.

[0100] S2. Render the target application screen by using the target rendering object.

[0101] It should be noted that the above steps S1 to S2 can be but are not limited to being automatically executed by the SDK without manual intervention by developers.

[0102] Optionally, the above steps S1 to S2 can be but are not limited to being explained through the following steps:

[0103] S1. Request message reception: For example, when a user clicks the "Home" button on the navigation bar, the application receives a request to load and display the home screen.

[0104] S2. Target bytecode call: Intercept this request through the target bytecode inserted into the application bytecode in advance during application compilation. The application no longer parses the XML layout file through the traditional LayoutInflater, but directly calls a Java code class that matches the home screen.

[0105] S3. Target rendering object loading and rendering: When an application screen request arrives, the SDK locates the corresponding target rendering object according to the request message and loads it into memory. Then, the SDK calls the rendering method of the target rendering object to present the application screen without performing traditional steps such as layout file parsing and reflection call view component instantiation.

[0106] It should be noted that the above examples and implementation manners are optional examples and implementation manners provided for facilitating the explanation of the above steps, and there is no limitation on the method for processing the above layout file.

[0107] With the embodiments of the present application, on the one hand, when a user requests to display a specific target application screen, by directly invoking the optimized target rendering object that matches the view component requested to be displayed upon receiving the request information, the waiting time is reduced and the response speed of the user interface is improved. Invoking the rendering object in the target data type using the target bytecode during runtime avoids the reflection overhead and layout parsing delay that may be encountered in the traditional layout loading process. This means that the application can render the screen requested by the user with lower CPU and memory consumption, especially on low-end devices with limited resources, where this advantage is more obvious. On the other hand, by loading and rendering view components on demand, it is intelligently determined which components are currently needed by the user, and these components are preferentially loaded and rendered instead of loading the entire layout at once. This dynamic loading mechanism reduces unnecessary resource consumption and improves the page loading speed and application running efficiency. On the other hand, developers do not need to additionally handle the loading and rendering logic of view components in the code. The SDK or related tools complete the optimization during the compilation phase, and the optimized rendering object is directly invoked during runtime, thereby reducing the complexity and maintenance cost for developers.

[0108] Optionally, as an alternative solution, invoking the target rendering object that matches the view component requested to be displayed in the target application screen from the target bytecode in the application bytecode of the target application includes:

[0109] In the case where the target rendering object is a complex rendering object, obtain the performance parameters of the target device used to run the target application, where the complex rendering object is obtained by converting complex view components with a view complexity in the target layout file exceeding a first complexity, and the performance parameters are used to characterize the device performance of the target device.

[0110] It should be noted that the above complex rendering object is a rendering object obtained by converting complex view components and used for rendering on high-performance devices. Complex rendering objects usually have richer visual effects and more complex interaction logics, but also have higher requirements for the hardware performance of the device.

[0111] Optionally, the above performance parameters can include but are not limited to a series of metrics used to characterize the hardware performance of the target device, including but not limited to CPU frequency, GPU performance, memory size, screen resolution, etc. These parameters are the key basis for the SDK to determine whether to use a complex rendering object or a simplified rendering object.

[0112] In the case where the performance parameters meet the target performance conditions, load the target rendering object into the memory area.

[0113] It should be noted that the above target performance conditions can be, but are not limited to, preset performance index thresholds for determining whether the device meets the rendering conditions of complex rendering objects. If the device performance is lower than these conditions, the SDK will select to load simplified rendering objects to ensure the smooth operation of the application.

[0114] In the case where the performance parameters do not meet the target performance conditions, the simplified rendering object matching the target rendering object is loaded into the memory area, where the simplified rendering object is obtained by converting a simplified view component, and the simplified view component is obtained by simplifying a complex view component. The view complexity of the simplified view component is the second complexity, and the first complexity is higher than the second complexity.

[0115] Optionally, the above simplified rendering object is a rendering object obtained by converting a simplified view component and used for rendering on a device with lower performance. The simplified rendering object reduces the complexity of rendering and the performance requirements for the device by means such as reducing the nesting level, simplifying the attribute settings, and removing animation effects.

[0116] In other words, by adopting the embodiment of the present application, the SDK can dynamically select the rendering object according to the device performance, ensure that the application can provide a smooth user interface on different devices, and avoid interface lags and delays caused by insufficient device performance. Whether the user uses a high-end or low-end device, the SDK can ensure the basic functions and interface response speed of the application, improving the overall user experience.

[0117] Optionally, after rendering the target application screen using the target rendering object, it further includes: in the case of determining a reference rendering object associated with the target rendering object, rendering the target application screen using the reference rendering object, where the reference view elements corresponding to the reference rendering object and the view elements of the target rendering object are associated in the target application screen.

[0118] It should be noted that for the static content of the view component corresponding to the above reference rendering object, pre-rendered code is generated for the static content view, and the rendering task is completed in the background thread to reduce the pressure on the main thread. In other words, the reference rendering object refers to an object that is associated with the target rendering object in certain scenarios and is used to assist or reference the target rendering object for screen rendering. The reference rendering object can be an object containing relevant view components or visual effects, and these components or effects are associated with the view elements of the target rendering object in terms of visual presentation or logical relationship. For example, the display state of a view component may depend on the existence or attribute value of another view component.

[0119] It should be further noted that the above-mentioned association relationship refers to the mutually dependent relationship between the target rendering object and the reference rendering object. This relationship may be based on the logical, visual, or data levels. For example, the update of the display states of two view elements may need to be synchronized, or the position and size of one element may depend on the property measurement results of another element to be determined. During the implementation process, the SDK will identify these association relationships and utilize the reference rendering object to optimize the rendering process of the target rendering object in appropriate scenarios to ensure visual consistency and logical correctness.

[0120] Optionally, as an optional example, the processing method of the above layout file can be generally explained but not limited to through the following steps:

[0121] Execute the following steps as shown in Figure 7 during the compilation stage of the target application:

[0122] Execute step S702, Structure Information Acquisition: The SDK reads the target layout file and analyzes its structure information, including the view hierarchy and attribute configurations, to identify redundant containers, nested structures, and dependencies. Then execute step S704, where the SDK generates policy information for optimizing the layout structure based on the analysis results. This includes: Redundant Container Merging: 1) Container Analysis: Traverse the layout tree to identify redundant containers (such as LinearLayout or FrameLayout without child elements). If the container's role is only for grouping, has no background set, or no special attributes specified, it can be removed and the child elements' hierarchy can be directly promoted. 2) Linear Merging: Merge nested LinearLayouts. For example, two vertically oriented LinearLayouts can be merged into one. By analyzing attributes such as layout_weight and gravity, recalculate the distribution rules to ensure consistent behavior after merging. Layout Nesting Optimization: 1) Dependency Simplification: Resolve the dependencies of the constraints in RelativeLayout or ConstraintLayout to generate a dependency graph. Detect circular dependencies and redundant constraints, and simplify the layout rules through topological sorting to reduce complex relationships to single-layer constraint rules. 2) Automatic Conversion: Convert multi-layer nested layouts (such as multi-layer LinearLayout) to equivalent ConstraintLayout to reduce nesting. Select more efficient layouts according to actual needs (such as replacing some RelativeLayout with FrameLayout or LinearLayout). Attribute Optimization: 1) Attribute Merging: Detect whether view objects at the same level share the same attributes (such as padding, margin), generate a unified style reference, and reduce duplicate settings. Automatically extract common attributes such as colors and text styles to resource files to generate more concise code. 2) Dynamic Attribute Calculation: By calculating the dependency relationships of attributes (such as dynamic width and height calculation), generate them as needed in Java code instead of static initialization to reduce unnecessary memory allocation. View Initialization Optimization: 1) Static Resource Mapping: In the Java class, pre-generate the mapping of view IDs and corresponding references through constants or static fields to avoid runtime lookups. Directly generate view instantiation code (such as TextView textView = new TextView(context);) and set attributes to avoid reflection calls. 2) Batch Initialization: Generate initialization code for similar view objects in batches (such as multiple TextViews), reducing duplicate code generation through loops or factory patterns. Drawing and Layout Process Optimization: 1) Measurement Process Simplification: Analyze the layout file to generate measurement results in advance for views with fixed width and height, avoiding multiple measurements at runtime. 2) Dynamically calculate the dependency relationships of the layout tree and only update the affected part of the views to reduce unnecessary redrawing.3) Pre-rendering optimization: Generate pre-rendering code for static content views, complete the rendering task in the background thread, and reduce the pressure on the main thread. Code structure optimization: 1) Modular generation: Divide the layout file into modules, generate independent Java classes for each module, and keep the code concise and clear. 2) Code compression: Use the abstract factory pattern or the builder pattern to unify the initialization process of view objects and reduce code duplication. 3) Logging and debugging assistance: Automatically insert log code (such as recording timestamps when generating views) for easy debugging and performance detection. Then perform step S706, code generation and bytecode instrumentation: Based on the above optimization strategies, the SDK generates Java code corresponding to the target data type and inserts the target bytecode into the application bytecode through bytecode instrumentation technology, so that the application directly calls the optimized layout code during runtime.

[0123] During the running stage of the target application, perform the following steps as Figure 8 shown:

[0124] Perform step S802, where the SDK detects the performance parameters of the target device and determines whether the rendering conditions for complex view components are met. Then perform step S804. According to the device performance, the SDK calls the complex rendering object or the simplified rendering object in the target data type and loads it into the memory area. Then perform step S806, using the loaded rendering object to efficiently render the target application screen to ensure the compatibility and performance of the application on different devices. Then perform step S808. When a reference rendering object associated with the target rendering object is determined, use the reference rendering object to pre-render the target application screen, where the reference view elements corresponding to the reference rendering object and the view elements of the target rendering object are associated in the target application screen.

[0125] It should be noted that in some embodiments, the compilation stage and the running stage of the target application can be executed on the same device or on different devices, and this is not limited in this embodiment.

[0126] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0127] According to another aspect of the embodiments of the present application, there is also provided a layout file processing device for implementing the above layout file processing method. As Figure 9 shown, the device includes:

[0128] An acquisition unit 902, configured to acquire structure information of a target layout file for rendering a target application screen when compiling the target application, where the target layout file is used to describe the structure and appearance of the target application screen, and the structure information includes a view hierarchy corresponding to the target layout file and attribute configurations;

[0129] A generation unit 904, configured to generate target conversion policy information based on the structure information, where the target conversion policy information is used to guide the conversion of the target layout file into a target data type belonging to the target code structure, and the target conversion policy includes a first policy for indicating simplifying the structure of the target layout file, a second policy for indicating simplifying the attribute information of the target layout file, and a third policy for indicating preprocessing for loading view components in the target layout file;

[0130] A conversion unit 906, configured to convert the target layout file into the target data type according to the target conversion policy, where each rendering object included in the target data type is used to render each view component in the target layout file;

[0131] An insertion unit 908, configured to insert target bytecodes into the application bytecodes obtained after compiling the target application, where the target bytecodes are used to call the target data type when the target application runs.

[0132] Optionally, in this embodiment, the above-mentioned generating unit includes: a first determination module, configured to determine a first sub-strategy for indicating adding view components in redundant containers in the target layout file to the upper-level container file of the redundant containers and removing the redundant container files; determine a second sub-strategy for indicating merging multiple first-type containers arranged vertically in the target layout file into the same first-type container; determine a third sub-strategy for indicating merging multiple first-type container files that meet the merging conditions into a second-type container, wherein the first-type container is used for arranging sub-elements vertically, and the second-type container is used for positioning the relative positioning between view components; determine a fourth sub-strategy for indicating converting the circular dependency relationship between view components in the second-type container into a linear dependency relationship, wherein the circular dependency relationship is used to indicate the mutual dependency positioning relationship between view components; determine a fifth sub-strategy for indicating removing the redundant dependency relationship between view components in the second-type container, wherein the redundant dependency relationship is used to indicate the repeated dependency positioning relationship corresponding to view elements; determine a sixth sub-strategy for indicating converting a first sub-type container that meets the conversion conditions into a first-type container or a third-type container, wherein the second-type container includes a first sub-type container and a second sub-type container, and the layout simplicity of the first sub-type container is higher than that of the second sub-type container, and the third-type container is used for superimposing and configuring multiple view components at the same position; wherein the first strategy includes the first sub-strategy, the second sub-strategy, the third sub-strategy, the fourth sub-strategy, the fifth sub-strategy, and the sixth sub-strategy.

[0133] Optionally, in this embodiment, the above-mentioned generating unit further includes: a second determination module, configured to determine a seventh sub-strategy for indicating creating an attribute reference object for multiple view components with mutually matching attribute information in the target layout file; and in the case of determining that there are dynamic view components in the target layout file, determine an eighth sub-strategy for indicating that no code conversion operation needs to be performed on the dynamic view components, wherein in the case that the target account for requesting to display the application screen where the dynamic view component is located does not meet the target conditions, the sub-screen corresponding to the view component will not be displayed on the application screen; wherein the second strategy includes the seventh sub-strategy and the eighth sub-strategy.

[0134] Optionally, in this embodiment, the above-mentioned generating unit further includes: a third determination module, configured to determine a ninth sub-policy for indicating adding the mapping relationship between the identification information of each view component in the target layout file and the reference object of each view component to the target data type; determine a tenth sub-policy for indicating adding the attribute measurement results of each view component in the target layout file to the target data type, where the attribute measurement results include the size and position information of the view component; in the case of determining that there is a complex view component in the target layout file whose view complexity exceeds the first complexity, determine an eleventh sub-policy for converting the complex view component into a simplified view component, where the complex view component is used for rendering the screen on a device whose performance parameters meet the target performance conditions, and the above-mentioned simplified view component is used for rendering the screen on a device whose performance parameters do not meet the target performance conditions, and the view complexity of the simplified view component is the second complexity, the first complexity is higher than the second complexity, and the higher the complexity of the view component, the fewer the nested levels and the fewer the attribute information and animation effects set; where the third policy includes the ninth sub-policy, the tenth sub-policy, and the eleventh sub-policy.

[0135] Optionally, in this embodiment, the above-mentioned layout file processing device further includes: a calling unit, configured to, when receiving request information for requesting to display a target application screen of a running target application, call a target rendering object in the target data type that matches the view component requested to be displayed in the target application screen through a target bytecode in the application bytecode of the target application; a rendering unit, configured to render the target application screen by using the target rendering object.

[0136] Optionally, in this embodiment, the above-mentioned calling unit includes: an obtaining module, configured to obtain the performance parameters of a target device for running the target application when the target rendering object is a complex rendering object, where the complex rendering object is obtained by converting a complex view component whose view complexity in the target layout file exceeds the first complexity, and the performance parameters are used to characterize the device performance of the target device; a first loading module, configured to load the target rendering object into the memory area when the performance parameters meet the target performance conditions; a second loading module, configured to load a simplified rendering object that matches the target rendering object into the memory area when the performance parameters do not meet the target performance conditions, where the simplified rendering object is obtained by converting a simplified view component, and the simplified view component is obtained by simplifying the complex view component, and the view complexity of the simplified view component is the second complexity, and the first complexity is higher than the second complexity.

[0137] For specific embodiments, reference may be made to the examples shown in the above-mentioned layout file processing method, and details are not described herein again.

[0138] According to another aspect of the embodiments of the present application, there is also provided an electronic device for implementing the processing method of the above layout file. The electronic device may be a terminal device or a server. In this embodiment, the electronic device is taken as an example of a server for illustration. As Figure 10 shown, the electronic device includes a memory 1002 and a processor 1004. A computer program is stored in the memory 1002, and the processor 1004 is configured to execute the steps in any of the above method embodiments through the computer program.

[0139] Optionally, in this embodiment, the above electronic device may be at least one of multiple network devices in a computer network.

[0140] Optionally, in this embodiment, the above processor may be configured to execute each step in the above processing method of the layout file through a computer program.

[0141] Optionally, those of ordinary skill in the art can understand that Figure 10 the structure shown is only schematic. The electronic device may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, and a mobile Internet device (MID), a PAD and other terminal devices. Figure 10 It does not limit the structure of the above electronic device. For example, the electronic device may further include more or fewer components (such as a network interface, etc.) than those shown in Figure 10 , or have a different configuration from that shown in Figure 10 .

[0142] Among them, the memory 1002 can be used to store software programs and modules, such as the program instructions / modules corresponding to the processing method and device of the layout file in the embodiments of the present application. The processor 1004 runs the software programs and modules stored in the memory 1002, thereby executing various functional applications and data processing, that is, implementing the above processing method of the layout file. The memory 1002 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, a flash memory, or other non-volatile solid-state memories. In some instances, the memory 1002 may further include a memory remotely set relative to the processor 1004, and these remote memories can be connected to the terminal through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof. As an example, as Figure 10As shown, the above-mentioned memory 1002 may but is not limited to include the acquisition unit 902, generation unit 904, conversion unit 906, and insertion unit 908 in the processing device for the above-mentioned layout file. In addition, it may also include but is not limited to other module units in the processing device for the above-mentioned layout file, which will not be elaborated in this example.

[0143] Optionally, the above-mentioned transmission device 1006 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wired network and a wireless network. In one example, the transmission device 1006 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers through a network cable, so as to communicate with the Internet or a local area network. In one example, the transmission device 1006 is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0144] In addition, the above-mentioned electronic device further includes: a connection bus 1008 for connecting each module component in the above-mentioned electronic device.

[0145] In other embodiments, the above-mentioned terminal device or server may be a node in a distributed system. Among them, the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the multiple nodes through network communication. Among them, the nodes can form a point-to-point network, and any form of computing device, such as servers, terminals and other electronic devices, can become a node in the blockchain system by joining the point-to-point network.

[0146] According to one aspect of the present application, there is provided a computer program product, which includes computer programs / instructions, and the computer programs / instructions include program codes for executing the above-mentioned method. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part, and / or installed from a removable medium. When the computer program is executed by a central processing unit, it executes various functions provided by the embodiments of the present application.

[0147] According to one aspect of the present application, there is also provided another computer program product, including a non-volatile computer-readable storage medium, and the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it realizes the steps of the methods in various embodiments of the present application.

[0148] According to one aspect of the present application, there is provided a computer-readable storage medium, a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above-mentioned method.

[0149] Optionally, in this embodiment, the above computer-readable storage medium may be configured to store a computer program for executing each step in the processing method of the layout file.

[0150] Optionally, in the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of the overall module or unit that includes the functions of the module or unit.

[0151] Optionally, in this embodiment, those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the relevant hardware of the terminal device through a program, and this program can be stored in a computer-readable storage medium. The storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, an optical disc, etc.

[0152] If the integrated unit in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing one or more computer devices (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0153] In the above embodiments of the present application, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0154] In several embodiments provided by the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of units or modules can be in an electrical or other form.

[0155] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0156] In addition, each functional unit in various embodiments of the present application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0157] The above are only the preferred embodiments of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. A method for processing a layout file, characterized in that: include: When compiling the target application, obtaining structural information of a target layout file for rendering a target application screen of the target application, wherein the target layout file is used to describe the structure and appearance of the target application screen, and the structural information includes a view hierarchy and attribute configuration corresponding to the target layout file; Generate target conversion strategy information based on the structure information, wherein the target conversion strategy information is used to guide the conversion of the target layout file to a target data type belonging to the target code structure, and the target conversion strategy includes a first strategy for indicating simplification of the structure of the target layout file, a second strategy for indicating simplification of attribute information of the target layout file, and a third strategy for indicating preprocessing of loading a view component in the target layout file; Converting the target layout file into the target data type according to the target conversion strategy, wherein each rendering object included in the target data type is used to render each view component in the target layout file; The target bytecode is inserted into the application bytecode obtained after the target application is compiled, wherein the target bytecode is used to call the target data type when the target application is running.

2. The method according to claim 1, characterized in that The generating target conversion strategy information based on the structure information includes: Determine a first sub-strategy for instructing to add the view component in the redundant container in the target layout file to the upper-level container file of the redundant container and to remove the redundant container file; Determine a second sub-strategy for instructing to merge multiple first-class containers arranged vertically in the target layout file into the same first-class container; determine a third sub-strategy for instructing to merge multiple first-class container files that meet the merging condition into a second-class container; wherein the first-class container is used to vertically arrange sub-elements, and the second-class container is used to locate the relative positioning between view components; Determine a fourth sub-strategy for indicating conversion of a circular dependency relationship between view components in the second type of container into a linear dependency relationship, wherein the circular dependency relationship is used to indicate that there is a mutual dependency positioning relationship between the view components; determine a fifth sub-strategy for indicating removal of redundant dependency relationships between view components in the second type of container, wherein the redundant dependency relationship is used to indicate repeated dependency positioning relationships corresponding to view elements; Determine a sixth sub-strategy for instructing to convert a first sub-class container that meets the conversion condition into a first class container or a third class container, wherein the second class container includes a first sub-class container and a second sub-class container, the layout simplicity of the first sub-class container is higher than that of the second sub-class container, and the third class container is used to overlay and configure multiple view components in the same position; The first strategy includes the first sub-strategy, the second sub-strategy, the third sub-strategy, the fourth sub-strategy, the fifth sub-strategy and the sixth sub-strategy.

3. The method according to claim 1, characterized in that The generating target conversion strategy information based on the structure information further includes: Determining a seventh sub-strategy for instructing to create attribute reference objects for a plurality of view components whose attribute information matches each other in the target layout file; In the case where it is determined that a dynamic view component exists in the target layout file, an eighth sub-strategy is determined for indicating that there is no need to perform a code conversion operation on the dynamic view component, wherein, if the target account for requesting to display the application screen where the dynamic view component is located does not meet the target condition, the sub-screen corresponding to the view component will not be displayed in the application screen; The second strategy includes the seventh sub-strategy and the eighth sub-strategy.

4. The method according to claim 1, characterized in that Generating the target conversion strategy information based on the structure information also includes: Determine a ninth sub-strategy for instructing to add a mapping relationship between identification information of each view component in the target layout file and a reference object of each view component to the target data type; Determine a tenth sub-strategy for instructing to add the property measurement results of each view component in the target layout file to the target data type, wherein the property measurement results include size and position information of the view component; In the case where it is determined that a complex view component having a view complexity exceeding a first complexity exists in the target layout file, an eleventh sub-strategy for converting the complex view component into a simplified view component is determined, wherein the complex view component is used to render a screen on a device whose performance parameters meet the target performance conditions, and the simplified view component is used to render a screen on a device whose performance parameters do not meet the target performance conditions, and the view complexity of the simplified view component is a second complexity, the first complexity is higher than the second complexity, and a view component with a higher complexity has fewer nested levels and is provided with less attribute information and animation effects; The third strategy includes the ninth sub-strategy, the tenth sub-strategy and the eleventh sub-strategy.

5. The method according to any one of claims 1 to 4, characterized in that Inserting the target bytecode into the application bytecode obtained after compiling the target application also includes: In case of receiving request information for requesting to display a target application screen of a running target application, calling a target rendering object in the target data type that matches a view component requested to be displayed in the target application screen through the target bytecode in the application bytecode of the target application; The target application screen is rendered using the target rendering object.

6. The method according to claim 5, characterized in that The calling of the target rendering object in the target data type that matches the view component requested to be displayed in the target application screen by the target bytecode in the application bytecode of the target application comprises: In the case where the target rendering object is a complex rendering object, obtaining a performance parameter of a target device for running the target application, wherein the complex rendering object is obtained by converting a complex view component whose view complexity of the target layout file exceeds a first complexity, and the performance parameter is used to characterize the device performance of the target device; If the performance parameter meets the target performance condition, loading the target rendering object into the memory area; When the performance parameters do not meet the target performance conditions, a simplified rendering object matching the target rendering object is loaded into the memory area, wherein the simplified rendering object is converted from a simplified view component, the simplified view component is obtained by simplifying the complex view component, the view complexity of the simplified view component is a second complexity, and the first complexity is higher than the second complexity.

7. A layout file processing device, characterized in that: include: an acquisition unit, configured to acquire structural information of a target layout file used to render a target application screen of the target application when compiling the target application, wherein the target layout file is used to describe the structure and appearance of the target application screen, and the structural information includes a view hierarchy and attribute configuration corresponding to the target layout file; a generating unit, configured to generate target conversion strategy information based on the structure information, wherein the target conversion strategy information is used to guide the conversion of the target layout file to a target data type belonging to a target code structure, and the target conversion strategy includes a first strategy for indicating simplification of the structure of the target layout file, a second strategy for indicating simplification of attribute information of the target layout file, and a third strategy for indicating preprocessing of loading a view component in the target layout file; A conversion unit, configured to convert the target layout file into the target data type according to the target conversion strategy, wherein each rendering object included in the target data type is used to render each view component in the target layout file; The insertion unit is used to insert the target bytecode into the application bytecode obtained after compiling the target application, wherein the target bytecode is used to call the target data type when the target application is running.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program is executed by a processor to perform the method described in any one of claims 1 to 6.

9. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 6 through the computer program.

Images