Static coordination of the application view hierarchy

Abstract

A system for performing static coordination to render a graphical user interface (GUI) of an application is described. The system compiles source code associated with the application's GUI into rendering instructions for rendering a view hierarchy of the GUI. The view hierarchy defines graphical components of the GUI, and the rendering instructions include: initial rendering instructions for rendering the graphical components during an initial rendering of the GUI; and update rendering instructions for rendering a subset of the graphical components during subsequent renderings of the GUI. The system can automatically assign corresponding keys to one or more of the subsets of graphical components, wherein the update rendering instructions for rendering each of the one or more of the subsets of graphical components are uniquely identifiable based on the corresponding keys. The system executes the rendering instructions to update the graphical components identified by the corresponding keys.

Description

Background Art

[0001] Some applications or other types of computer programs provide a graphical user interface (GUI). A graphical user interface can be represented as a tree of GUI views, also called a "view hierarchy." As the application state changes (e.g., due to user input in response to operating system commands, because of data from a remote server, etc.), a coordinator can "coordinate" to update the components of the application's view hierarchy to accommodate the changes before rendering the GUI. Coordination can be complex and error-prone, especially when changes to application data affect the rendering of multiple different GUI views. Therefore, coordination can involve complex processes and become a performance bottleneck in managing and rendering the application GUI. Summary of the Invention

[0002] Describes techniques for implementing "static coordination" for rendering an application GUI. During compilation of application source code, an example compiler may separate a view hierarchy into static objects and dynamic objects. Static objects may be associated with components of a GUI that do not change appearance after initial rendering (e.g., a company logo, menu options, etc.). However, dynamic objects may be associated with components of a GUI that may, and sometimes do, change appearance from one rendering to the next (e.g., text fields, animations, etc.).

[0003] An example compiler can generate application machine code that causes the application to execute two different sets of rendering instructions at runtime. The application can execute an initial set of rendering instructions to render all static and dynamic components defined by the actual view hierarchy. However, after receiving the required view hierarchy for subsequent rendering, the application can execute a different set of rendering instructions or a set of update rendering instructions. The set of update rendering instructions is a subset of the initial set of rendering instructions and includes only the instructions required to re-render the objects of the dynamic components, because only the objects of the dynamic components can change between renderings. In this way, static coordination can enable the application to only have to allocate a reduced number of objects when rendering GUI components defined by a view hierarchy, compared to the full number of objects that would otherwise need to be allocated if the application were to render its view hierarchy using other coordination techniques. In one example, the present disclosure relates to a method for performing static coordination to render a graphical user interface of an application, the method comprising: receiving, by at least one processor, source code associated with the graphical user interface of the application; compiling the source code into a plurality of rendering instructions to render a view hierarchy of the graphical user interface, wherein the view hierarchy defines graphical components of the graphical user interface, and wherein the plurality of rendering instructions include: a set of initial rendering instructions for rendering the graphical components during initial rendering of the graphical user interface; and a set of update rendering instructions for rendering a subset of the graphical components during subsequent rendering of the graphical user interface; automatically assigning corresponding keys to one or more of the subset of graphical components during compilation of the source code, wherein the set of update rendering instructions for rendering each of the one or more of the subset of graphical components is uniquely identifiable according to the corresponding key; and executing the plurality of rendering instructions to display the graphical user interface of the application.

[0004] In another example, the present disclosure relates to a computing system comprising at least one processor configured to statically coordinate rendering of a graphical user interface of an application by at least: receiving source code associated with the graphical user interface of the application; and compiling the source code into a plurality of rendering instructions for rendering a view hierarchy of the graphical user interface. The view hierarchy defines graphical components of the graphical user interface, and the plurality of rendering instructions include: a set of initial rendering instructions for rendering the graphical components during an initial rendering of the graphical user interface; and a set of update rendering instructions for rendering a subset of the graphical components during subsequent renderings of the graphical user interface. The at least one processor may be further configured to automatically assign a corresponding key to one or more of the subset of graphical components during compilation of the source code, wherein the set of update rendering instructions for rendering each of the one or more of the subset of graphical components is uniquely identifiable based on the corresponding key. The at least one processor is further configured to statically coordinate rendering of the graphical user interface of the application by executing the plurality of rendering instructions to update one or more of the subset of graphical components identified by the corresponding key.

[0005] In another example, the present disclosure relates to a computer-readable storage medium that, when executed, causes at least one processor of a computing system to statically coordinate rendering of a graphical user interface of an application by at least: receiving source code associated with the graphical user interface of the application; and compiling the source code into a plurality of rendering instructions for rendering a view hierarchy of the graphical user interface. The view hierarchy defines graphical components of the graphical user interface, and the plurality of rendering instructions include: a set of initial rendering instructions for rendering the graphical components during an initial rendering of the graphical user interface; and a set of update rendering instructions for rendering a subset of the graphical components during subsequent renderings of the graphical user interface. The instructions, when executed, further cause the at least one processor to automatically assign corresponding keys to one or more of the subset of graphical components during compilation of the source code, wherein the set of update rendering instructions for rendering each of the one or more of the subset of graphical components is uniquely identifiable based on the corresponding keys. The instructions, when executed, further cause the at least one processor to statically coordinate rendering of the graphical user interface of the application by executing the plurality of rendering instructions to update one or more of the subset of graphical components identified by the corresponding keys.

[0006] In another example, the present disclosure relates to a system for performing static coordination to render a graphical user interface of an application, the system comprising: a component for receiving source code associated with the graphical user interface of the application; and a component for compiling the source code into a plurality of rendering instructions to render a view hierarchy of the graphical user interface. The view hierarchy defines graphical components of the graphical user interface, and the plurality of rendering instructions include: a set of initial rendering instructions for rendering the graphical components during an initial rendering of the graphical user interface; and a set of update rendering instructions for rendering a subset of the graphical components during subsequent renderings of the graphical user interface. The system may further include a component for automatically assigning a corresponding key to one or more of the subset of graphical components during compilation of the source code, wherein the set of update rendering instructions for rendering each of the one or more of the subset of graphical components is uniquely identifiable based on the corresponding key. The system further includes a component for executing the plurality of rendering instructions to update one or more of the subset of graphical components identified by the corresponding key.

[0007] The details of one or more examples are set forth in the accompanying drawings and the detailed description below. Other features, objects, and advantages of the disclosure will become apparent from the detailed description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a conceptual diagram illustrating an example system configured for static coordination to render a graphical user interface for an application, in accordance with techniques of this disclosure.

[0009] Figure 2 is a conceptual diagram illustrating example source code that has been separated into a set of initial rendering instructions and a set of update rendering instructions for statically coordinating rendering of an application's graphical user interface, in accordance with techniques of this disclosure.

[0010] Figure 3 is a block diagram illustrating an example computing system configured to perform static coordination to render a graphical user interface of an application, in accordance with techniques of this disclosure.

[0011] Figure 4 is a flow diagram illustrating example operations performed by a computing system configured to perform static coordination to render a graphical user interface of an application, in accordance with techniques of this disclosure. DETAILED DESCRIPTION

[0012] Reconciliation is a process performed by a coordinator during the rendering of a view hierarchy. Declarative reconciliation involves comparing the previous view hierarchy with the desired GUI hierarchy (e.g., emitted from a GUI component's render function) to determine a set of transformations that the coordinator can perform to transform the previous view hierarchy into the desired view hierarchy. From a user's perspective, reconciliation can be an undiscoverable implementation detail. However, reconciliation can be complex and lead to performance bottlenecks when managing and rendering the GUI.

[0013] Some coordinators do "naive unoptimized coordination." In naive unoptimized coordination, the coordinator will recreate or instantiate an entirely new view hierarchy from scratch each time the view hierarchy is rendered (for example, once every sixtieth of a second in an animation). The coordinator can walk through the previously instantiated view hierarchy and the new view hierarchy to determine which GUI views in the previous view hierarchy need to be rendered to reflect the desired view hierarchy. Essentially, the naive optimized coordinator can instantiate an entirely new GUI view tree each time the application GUI needs to be rendered, even if only some of the GUI views need to change. Naive unoptimized coordination is computationally intensive and consumes increasing processing resources to recreate or instantiate the entire view hierarchy each time the application data changes or the GUI needs to be rendered.

[0014] Instead of instantiating an entirely new view hierarchy for each render, some coordinators perform Virtual Document Object Model (VDOM) reconciliation. In "VDOM reconciliation," the coordinator allocates and maintains a VDOM tree that represents the actual (i.e., currently instantiated) view hierarchy maintained by the application. During each render, the coordinator allocates an entirely new VDOM tree that represents the desired view hierarchy, rather than instantiating a second view hierarchy. The coordinator can traverse the desired and actual VDOM trees to identify differences between the two. The coordinator can then manipulate the actual instantiated view hierarchy based on the identified differences in the two VDOM trees to render the actual view hierarchy to the desired view hierarchy. By allocating VDOM trees and running comparisons between the VDOM trees, rather than instantiating and comparing entire multiple view hierarchies as during naive, unoptimized reconciliation, the coordinator can have improved performance.

[0015] The present disclosure relates to improving coordination performance and reducing coordination complexity even further by performing "static coordination" techniques, rather than performing the VDOM coordination described above. Static coordination enables an application to render and update a GUI view hierarchy by allocating only a subset of the objects that would otherwise have to be allocated for VDOM coordination. When rendering a view hierarchy according to static coordination techniques, an application can avoid regularly allocating multiple VDOM trees during each rendering; the application can instead render the view hierarchy once and then, during each subsequent rendering, regularly allocate only a subset (e.g., a minimum number) of all the objects required to define the dynamic components of the GUI, while ignoring the static components of the GUI, since only the dynamic components can change from one rendering of the GUI to another. An application that benefits from static coordination can execute a set of initial rendering instructions to initially render all dynamic and static objects of the view hierarchy. However, during each subsequent rendering, the application executes a set of update rendering instructions to evaluate any objects associated with the dynamic components of the GUI that may have changed, without evaluating any objects that remained static.

[0016] Figure 1 is a conceptual diagram illustrating an example system configured for static coordination to render a graphical user interface for an application according to the techniques of this disclosure. System 100 includes a computing system 160 in communication with computing device 110 via network 130. Although operations attributed to system 100 are primarily described as being performed by a single computing device 110 and / or a single computing system 160, in some examples, operations of system 100 may be performed by multiple computing devices. Figure 1 More or fewer computing devices and computing systems may be shown. For example, some operations attributed to computing device 110 may be performed by computing system 160, and vice versa.

[0017] Network 130 represents any public or private communication network, such as a cellular, Wi-Fi, and / or other type of network, for transmitting data between computing systems, servers, and computing devices. Network 130 may include one or more network hubs, network switches, network routers, or any other network devices operatively coupled to each other to provide for information exchange between computing system 160 and computing device 110. Computing system 160 and computing device 110 may transmit and receive data over network 130 using any suitable communication technology.

[0018] Computing system 160 and computing device 110 may each be operatively coupled to network 130 using respective network links. The links coupling computing system 160 and computing device 110 to network 130 may be Ethernet, ATM, or other types of network connections, and such connections may be wireless and / or wired.

[0019] Computing system 160 includes a remote compiler module 162. Computing device 110 includes a local compiler module 122, a user interface (UI) module 120, an application module 124, and a user interface component ("UIC") 112. UIC 112 is configured to output user interfaces 114A and 114B (collectively, "user interfaces 114").

[0020] Computing system 160 represents any combination of one or more computers, mainframes, servers (including so-called "blades"), cloud computing systems, or other types of remote computing systems capable of exchanging information as part of a remote computing service via network 130. For example, computing system 160 may provide access to application developer services (e.g., application builder services, compiler services, debugging services, etc.), client devices such as computing device 110 may upload source code to the application developer services for compilation by computing system 160, and the client devices may download application executable files or packages from the application developer services, which the client devices may then execute locally on the devices.

[0021] Computing device 110 represents any suitable computing device or computing system capable of exchanging information via network 130 to access remote computing services provided by computing system 160. For example, computing device 110 may be a mobile device from which a user provides input to interact with a user interface associated with computing system 160, e.g., to cause computing device 110 to download an application executable file compiled by computing system 160 for local installation on computing device 110. Examples of computing device 110 include mobile phones, tablet computers, laptop computers, desktop computers, servers, mainframes, blade computers, wearable devices (e.g., computerized watches, etc.), home automation devices, auxiliary devices, gaming consoles and systems, media players, e-book readers, television platforms, car navigation or infotainment systems, or any other type of mobile, non-mobile, wearable, and non-wearable computing device configured to execute applications.

[0022] The UIC 112 of the computing device 110 can function as an input and / or output device for the computing device 110. The UIC 112 can be implemented using various technologies. For example, the UIC 112 can function as an input device using a presence-sensitive input screen, microphone technology, infrared sensor technology, or other input device technology for receiving user input. The UIC 112 can also function as an output device configured to present output to a user using any one or more display devices, speaker technology, tactile feedback technology, or other input device technology for outputting information to a user.

[0023] Modules 120, 122, 124, and 162 may perform the operations described herein using software, hardware, firmware, or a mixture of hardware, software, and firmware resident in and / or executing at computing device 110 and computing system 160. Computing device 110 and computing system 160 may execute modules 120, 122, and 124, and module 162, respectively, with multiple respective processors or multiple respective devices, as respective virtual machines executing on underlying hardware, as one or more respective services of an operating system or computing platform, and / or as one or more respective executable programs at an application layer of a respective computing platform.

[0024] UI module 120 of computing device 110 controls UIC 112, including determining the content presented by UIC 112 and the information exchanged between UIC 112 and other applications or components of computing device 110 (e.g., application module 124 and compiler module 122). For example, when controlling the content displayed by UIC 112, UI module 120 may receive information from application module 124 that forms the basis for some or all of user interface 114A. In response, UI module 120 may output instructions and information to UIC 112 that cause UIC 112 to display user interface 114 based on the information received from application module 124. When processing input detected by UIC 112, UI module 120 may receive information from UIC 112 in response to input detected at a location of a presence-sensitive input component of UIC 112 that corresponds to the location of a display component of UIC 112 where an element of user interface 114 is displayed. UI module 120 propagates information about input detected by UIC 112 to other components of computing device 110 to interpret the input and cause computing device 110 to perform one or more functions in response to the input.

[0025] In some examples, UI module 120 may receive an indication of one or more user inputs detected at UIC 112 and may output information about the user inputs to compiler module 122, application module 124, or any other application or component of computing device 110 for which the user inputs are intended. For example, UIC 112 may detect the user inputs and send data about the user inputs to UI module 120. UI module 120 may generate one or more touch events based on the detected inputs. A touch event may include information characterizing the user inputs, such as a positional component of the user input (e.g., [x, y] coordinates), a temporal component (e.g., when the user input was received), a force component (e.g., the amount of pressure applied by the user input), or other data about the user input (e.g., velocity, acceleration, direction, density, etc.). Based on the positional information of the touch events generated from the user inputs, UI module 120 may determine that the detected user inputs are associated with aspects of user interface 114 and may send an indication of the one or more touch events to application module 124 for further interpretation.

[0026] Application modules 124 represent standalone, machine-readable executable files, packages, programs, routines, or containers comprised of one or more object files and other files that, when executed, operate at the application layer of computing device 110. Computing device 110 can execute instructions associated with application modules 124 to perform functions or provide services. For example, application modules 124 can perform functions such as outputting information to UI module 120 so that user interface 114 is rendered and output for display. While examples of application modules 124 are too numerous to list comprehensively, application modules 124 may include the following to provide a few examples of different application categories: business or productivity applications, developer tools, educational applications, entertainment applications, financial applications, gaming applications, graphics or design applications, health and fitness applications, lifestyle or assistant applications, medical applications, music applications, news applications, photography, video and other multimedia applications, reference applications, social networking applications, sports applications, travel applications, utility applications, weather applications, communication applications, calendar applications, or any other category or type of application.

[0027] The machine-readable instructions that make up the application module 124 are compiled from the source code 116 into object code, byte code, or other machine-executable instructions. The source code 116 may include one or more files of human-readable instructions written in a programming language, either manually created by one or more developers or automatically generated by one or more machines. A compiler, such as the compiler modules 122 and 162, may interpret the human-readable instructions of the source code 116 and compile the instructions into machine-readable instructions that make up machine-executable code (e.g., byte code) or so-called "object files."

[0028] The one or more files (e.g., text files) comprising source code 116 may be divided into consecutive "lines" of source code. Each "line" of source code may be associated with a specific programming instruction or portion thereof. A single programming instruction may span a single line or multiple lines of source code 116. For example, a rendering instruction stated in source code 116 may begin on one line and end on a different line, thereby spanning a series of consecutive lines of source code 116.

[0029] The instructions contained in the source code 116 may define the user interface 114. The user interface 114 may be any type of graphical user interface comprised of graphical content that provides user control to the application module 124 and communicates output associated with the application module 124. Examples of graphical content include images, graphics, text, animations, and any other type of graphical content that the computing device 110 may display with the UIC 112. The user interface 114 may include dynamic content (e.g., one or more dynamic components) that changes based on changes in the state of the application module 124. Additionally or alternatively, the user interface 114 may include static content (e.g., one or more static components) that remains constant between successive renderings of the user interface 114, regardless of changes in the state of the application module 124.

[0030] Source code 116 may define a view hierarchy associated with application module 124 that represents the state of user interface 114 during different execution points of application module 124. The view hierarchy may be represented as a tree of GUI views. When the state of application module 124 changes, due to user interaction with user interface 114 or in response to other information obtained by application module 124, application module 124 may need to update the GUI views so that user interface 114 conveys the current state of application module 124.

[0031] For example, user interface 114A is an initial rendering of user interface 114 and may be defined by a first GUI view. User interface 114A includes dynamic components 132A and 132B and static components 134A and 134B. User interface 114B represents a subsequent rendering of user interface 114 that may replace the initial rendering of user interface 114A and may be defined by one or more second GUI views. Like user interface 114A, user interface 114B also includes static components 134A and 134B because static components 134A and 134B represent static content that remains constant between successive renderings of user interface 114 regardless of changes in the state of application module 124. However, unlike the first GUI view that defines user interface 114A, the one or more second GUI views that define user interface 114B specify dynamic content that is different from user interface 114A. As a result of the rendering of user interface 114B, dynamic components 132A and 132B of user interface 114A, as defined in the first GUI view, are replaced by dynamic components 132A' and 132B', as defined in one or more second GUI views. Application module 124 may execute instructions that configure application module 124 to manage user interface 114 from one rendering to the next.

[0032] A common method of updating the view hierarchy is for an application to "walk" through the tree of GUI views via specific render calls made along the way, manually manipulating the nodes of the tree. Manual view manipulation can be complex and can sometimes introduce errors during rendering. Manual manipulation requires the application to identify and execute a rendering function during each rendering that is associated with each individual node of the GUI view tree that needs to be updated from one state to the next. The rendering application may encounter an illegal state, for example, where an update to one node of the GUI view tree inadvertently conflicts with another node of the GUI view tree in an unexpected way (for example, if the application attempts to set a value on a node that the application had previously removed from the view hierarchy). When manual manipulation is involved, GUI maintenance complexity can increase exponentially as the number of views of the view hierarchy that need to be updated increases. With the increases in computing power in recent years, other techniques for maintaining GUI views have been attempted.

[0033] Some systems rely on a declarative programming model that relieves developers of the burden of developing program instructions for maintaining and updating the GUI. Some developers prefer to use declarative programming to define view hierarchies because declarative programming can make the source code more modular, easier to read, and easier to understand. A declarative GUI model can explicitly regenerate the entire GUI view from scratch each time a GUI view needs to be rendered, thereby avoiding the complexity of manually maintaining the view hierarchy. However, a purely declarative GUI model that regenerates the entire GUI view from scratch each time a GUI view needs to be rendered may consume unnecessary computing resources and power to execute an entire set of rendering instructions for the entire view hierarchy during each rendering.

[0034] According to the techniques of this disclosure, application module 124 performs "static coordination" to maintain the view hierarchy of user interface 114. Static coordination enables the use of declarative programming to specify the view hierarchy (given the current state of application module 124), and during compilation, compiler module 122 determines how to efficiently transform the existing view hierarchy into the developer's desired view hierarchy.

[0035] Compiler modules 122 and 162 are examples of compilers configured to perform various aspects of static coordination. Compiler module 122 is a locally executed compiler, whereas compiler module 162 represents a remote compiler or remote compilation service. In addition to their respective execution environments, compiler modules 122 and 162 each take source code 116 as input and generate object files that comprise an application executable file (such as application module 124). Compiler modules 122 and 162 can be standalone compilers, compiler subcomponents, compiler submodules, compiler plug-ins, or any other type of module or submodule configured to perform static coordination techniques during compilation of source code 116.

[0036] Compiler modules 122 and 162 can be two-level compilers. For example, compiler module 122 can compile high-level source code from the highest level down to one or more intermediate levels, and then compile the intermediate levels of source code down to a machine-readable form. For example, compiler module 122 can compile source code from a high-level language down to an operating system-specific language. The second level of compiler module 122 can compile operating system-specific code into a machine-independent code form for local execution on a computing device running a specific operating system. Compiler module 122 can compile the same source code from a high-level language down to a different operating system-specific language. The second level of compiler module 122 can compile a second version of the operating system-specific code into a machine-independent code form for local execution on a computing device running a different operating system.

[0037] In some examples, compiler modules 122 and 162 are just-in-time (JIT) compilers. A just-in-time compiler compiles an application for execution at runtime, rather than compiling the application prior to execution. For example, compiler module 122 can continuously compile or otherwise convert source code, byte code, or other high-level language into machine code while the application is executing. Compiler modules 122 and 162 can continuously analyze the execution of the program and recompile when it is determined that performance improvements can be achieved in a manner that outweighs any reduction in computing resources required to perform the recompilation. Compiler modules 122 and 162 can perform JIT compilation by performing a combination of ahead-of-time compilation (AOT) and interpretation. For ease of description, although compiler module 162 can perform similar (if not identical) techniques related to static coordination, static coordination techniques are primarily described as being performed by compiler module 122.

[0038] Compiler module 122 can provide a declarative application programming interface (API) that enables an application (including application module 124) to render a GUI without having to explicitly change each individual front-end GUI view. For example, a developer can declare the components of a view hierarchy for user interface 114 within source code 116, just as a developer would typically specify a view hierarchy, i.e., using declarative programming and without having to specify the logic required to coordinate rendering between view hierarchies (e.g., changing from one application state to the next).

[0039] Like programming functions or subroutines, components are reusable building blocks of source code. These building blocks can be complex and specialized features. For example, a contact manager application may define individual components that render specific graphical elements to display contact data. By definition, each component has or acts as a render function, which is called whenever the component's view hierarchy may need to be updated (such as when some application data changes and the view needs to reflect the new data). The component's render function uses a set of properties defined by the component to generate the desired view hierarchy by executing appropriate statements. Ideally, rendering of a particular component is requested every frame (e.g., 60 times per second), such as to handle animations or other rapidly changing view hierarchies. A component may need to be re-rendered for many reasons, including: the component was previously invisible but is now visible; the component's data has changed; the component is being animated and needs to be drawn in the next frame; or the display displaying the component has been selected, resized, or has otherwise changed layout characteristics. Compiler module 122 can compile the application to ensure that the view hierarchy of each component is updated upon rendering to reflect the desired view hierarchy.

[0040] Instead of requiring the developer to specify how to coordinate the view hierarchy between renderings, the compiler module 122 automatically generates object code that maintains and coordinates the view hierarchy. The compiler module 122 includes the generated object code as part of the remaining object code generated by the compiler module when compiling the source code 116 into the application module 124.

[0041] In operation, compiler module 122 can perform static coordination to render user interface 114 of application module 124. Compiler module 122 can receive source code 116 as input source code associated with user interface 114. Upon receipt, compiler module 122 can parse source code 116 and perform other analysis of source code 116 to compile source code 116 into machine-executable instructions, including rendering instructions for rendering a view hierarchy of user interface 114. One thing that makes compiler module 122 different from other compilers of application source code is that compiler module 122 can generate two sets of rendering instructions to render the view hierarchy of user interface 114.

[0042] Compiler module 122 may generate a first set of rendering instructions that are executed during an initial rendering of user interface 114. For example, user interface 114A may be an initial rendering of user interface 114 and may be output for display at UIC 112 when application module 124 begins displaying user interface 114. The rendering instructions executed by application module 124 and / or UI module 120 to display user interface 114A may be part of the first set of rendering instructions generated by compiler module 122. The first set of rendering instructions (also referred to as an initial set of rendering instructions) includes instructions for rendering both static and dynamic graphical components of user interface 114 during the initial rendering of user interface 114. For example, the initial set of rendering instructions may include instructions for rendering dynamic components 132A and 132B and instructions for rendering static components 134A and 134B.

[0043] Compiler module 122 may generate a second set of merged rendering instructions to be executed during a subsequent rendering of user interface 114. For example, user interface 114B may be a subsequent rendering of user interface 114 and may be output for display at UIC 112 after application module 124 changes state from when application module 124 initially begins displaying user interface 114A. The rendering instructions executed by application module 124 and / or UI module 120 to display user interface 114B may be part of the second set of rendering instructions generated by compiler module 122. The second set of rendering instructions (also referred to as a set of update rendering instructions) includes instructions for rendering dynamic, rather than static, graphical components during a subsequent rendering of user interface 114. For example, a set of update rendering instructions may include instructions for rendering dynamic components 132A' and 132B', without any instructions for rendering static components 134A and 134B.

[0044] During execution of application module 124, application module 124 may execute two sets of rendering instructions to display user interface 114. After executing the initial set of rendering instructions during an initial rendering of user interface 114 (e.g., user interface 114A), and during each subsequent rendering of user interface 114 (e.g., user interface 114B), application module 124 may avoid executing the initial set of rendering instructions and instead execute a set of update rendering instructions.

[0045] Figure 2 It is a conceptual diagram that further helps to understand the "static coordination" technology. Figure 2 The conceptual diagram of FIG. 116 illustrates example source code according to the techniques of the present disclosure that has been transformed into a set of initial rendering instructions and a set of update rendering instructions for statically coordinating rendering of an application's graphical user interface. As an example of source code 116, Figure 2 A portion of source code 216 is included. Figure 2 When compiling an application, the compiler (such as Figure 1 The compiler 122 of FIG. 1 may decompose the source code 216 into a set of initial rendering instructions 218A and a set of update rendering instructions 218B so that the application can perform static coordination.

[0046] Compiler 122 may receive source code 216 as input. During compilation of source code 216, compiler 122 may create one or more sets of object code that define two different sets of rendering instructions 218A and 218B, for example, to render user interface 114. In some examples, an initial set of rendering instructions 218A may include an update set of rendering instructions 218B. For example, the initial set of rendering instructions 218A and the update set of rendering instructions 218B may together form a total set of rendering instructions that are initially executed during an initial rendering cycle. In this example, the initial set of rendering instructions 218A and the update set of rendering instructions 218B may be executed in parallel.

[0047] At a high level, specifically by identifying any object in the source code 216 of the graphics component of a specified view hierarchy that includes dynamic properties that can or do change from one rendering to the next, the compiler 122 can identify any dynamic objects from the source code 216. For example, by identifying any object in the source code 216 of the graphics component of a specified view hierarchy that does not include any dynamic properties and instead includes only static properties that remain constant from one rendering to the next, the compiler 122 can identify any static objects from the source code 216.

[0048] The compiler 122 can generate a set of initial rendering instructions 218A by packaging the rendering instructions together such that, when executed during an initial rendering of the view hierarchy, both dynamic components and static components are rendered as part of the view hierarchy. The compiler 122 can generate a set of update rendering instructions 218B by packaging the rendering instructions together such that, when executed during any subsequent rendering of the view hierarchy, dynamic components are re-rendered instead of static components as part of updating the view hierarchy.

[0049] For example, Figure 2As shown in , source code 216 includes instructions associated with a dynamic component of a graphical user interface. The dynamic component is called "AboutPageComponent" and includes a set of rendering instructions that, when executed as part of an application module, cause the dynamic component to be rendered and displayed. The AboutPageComponent primarily includes static properties, including a name property having a static value of "My Fancy App Name" and a description property having a static value of "My app is a todo list that is very fancy." In addition to the static properties, the AboutPageComponent also includes a dynamic property called a version property that includes a dynamic value assigned to a variable "appVersion." While the values ​​assigned to the name and description properties may never change from one rendering to another, the version property can and likely will change between renderings.

[0050] The compiler module 122 can decompose the source code 216 into a set of initial rendering instructions 218A for initially rendering the AboutPageComponent and a set of update rendering instructions 218B for subsequently rendering the AboutPageComponent. The set of initial rendering instructions 218A includes rendering instructions that define how to render at least the static properties of the AboutPageComponent. In some examples, the set of initial rendering instructions 218A also includes rendering instructions that define how to render the dynamic properties of the AboutPageComponent. However, the set of update rendering instructions 218B only includes rendering instructions that define how to render the dynamic properties of the AboutPageComponent, and does not render the static properties because the values ​​of the static properties do not change between renderings, so there is no need to render the static properties.

[0051] Instead of creating and allocating a VDOM at runtime, the compiler 122 can perform static analysis at compile time and, based on the instructions 218A and 218B, generate optimized object code (e.g., byte code) that minimizes object allocations during view hierarchy coordination. The compiler module 122 can avoid performing VDOM allocations by generating object code (e.g., byte code) that embeds or "encodes" view hierarchy updates within the rendering instructions for each component. Thus, instead of instantiating a VDOM that is then passed to a general coordinator, the compiler module 122 can create application modules that are rendered using fewer object allocations and, therefore, can consume less memory at runtime and / or can consume less power maintaining and evaluating VDOM allocations during each rendering. Thus, by performing static coordination, the compiler module 122 can utilize information determined from the source code 216 at compile time to reduce the overall amount of work performed later during coordination.

[0052] For example, many aspects of a component's subview hierarchy are statically known at compile time. A component may use a linear layout for its subview hierarchy, or may have an image that never changes (e.g., a product logo). Adding nodes to the VDOM tree will require allocating individual VDOM nodes for each component property, whether constant over time or dynamic. Additionally, each rendering will require maintaining these nodes, setting their values, accessing them during reconciliation, and comparing them to the nodes of the previous VDOM tree to determine if there are any differences. However, accessing nodes associated with component properties that never change during reconciliation may waste computing resources. When re-rendering a component view, the compiler 122 can create object code and compile the application executable to include logic that ignores properties that remain static.

[0053] Information known at compile time can be used to reduce the set of checks that need to be generated. Some constructs, such as loops, may still require allocation. However, the compiler 122 can generally generate object code that requires a fraction of the total number of comparisons that would otherwise be performed using VDOM coordination. The comparisons performed during static coordination are a strict subset of the comparisons already performed by the VDOM coordinator. In fact, a simple implementation of the code generator might only emit the exact coordination code that will be executed by the VDOM coordinator.

[0054] Figure 3 is a block diagram illustrating an example computing device configured to perform static coordination to render a graphical user interface of an application, in accordance with techniques of this disclosure. Figure 3 The computing device 310 is Figure 1 Computing device 310 is an example of computing device 110 and is described in the context of computing device 110. Computing device 310 may include some or all of the capabilities of computing device 110. Figure 3Only one particular example of computing device 310 is illustrated, and many other examples of computing device 310 may be used in other situations and may include a subset of the components included in the example computing device 310, or may include Figure 3 Additional components not shown.

[0055] like Figure 3 As shown in the example of FIG, computing device 310 includes one or more user interface components (UIC) 312, one or more processors 340, one or more input components 342, one or more communication units 344, one or more output components 346, and one or more storage components 348. UIC 312 includes display component 202 and presence sensitive input (PSI) component 204.

[0056] The storage component 348 of the computing device 310 also includes a UI module 320, a compiler module 322, and an application module 324. Additionally, the storage component 248 includes source code 316, and within the application module 324 is object code 319.

[0057] Communication channels 350 can interconnect each of components 302, 304, 312, 316, 319, 320, 322, 324, 340, 342, 344, 346, and 348 for inter-component communication (physically, communicatively, and / or operationally). In some examples, communication channels 350 can include a system bus, a network connection, an inter-process communication data structure, or any other method for transferring data.

[0058] One or more input components 342 of computing device 310 can receive input. Examples of input are sensor, tactile, audio, and video input. In one example, input components 342 of computing device 300 include a presence-sensitive display, a touch-sensitive screen, a sensor, a mouse, a keyboard, a voice response system, a camera, a microphone, or any other type of device for detecting input generated from a person or machine. In some examples, input components 342 include one or more location sensors (GPS components, Wi-Fi components, cellular components), one or more temperature sensors, one or more motion sensors (e.g., accelerometers, gyroscopes), one or more pressure sensors (e.g., barometers), one or more ambient light sensors, and one or more other sensors (e.g., microphones, cameras, infrared proximity sensors, hygrometers, etc.).

[0059] One or more output components 346 of computing device 310 can generate output. Examples of output are tactile, audio, and video output. In one example, output components 346 of computing device 310 include a presence-sensitive display, a sound card, a video graphics adapter card, speakers, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device for generating output to a person or machine.

[0060] The one or more communication units 344 of the computing device 310 can communicate with external devices via one or more wired and / or wireless networks by transmitting and / or receiving network signals over one or more networks. Examples of communication units 344 include a network interface card (e.g., an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and / or receive information. Other examples of communication units 344 can include a shortwave radio, a cellular data radio, a wireless network radio, and a universal serial bus (USB) controller.

[0061] UIC 312 of computing device 310 is an example of UIC 112 of computing device 110. For example, UIC 312 may display a graphical user interface, such as user interface 114, from which a user of computing device 310 may provide input to computing device 310 or view output from computing device 310.

[0062] UIC 312 includes a display component 302 and a PSI component 304. Display component 302 can be a screen on which UIC 312 displays information, and PSI component 304 can detect objects at and / or near display component 302. As an example range, presence-sensitive input component 304 can detect objects, such as a finger or stylus, within two inches or less of display component 302. Presence-sensitive input component 304 can determine the position (e.g., [x, y] coordinates) of display component 302 at which the object was detected. In another example range, presence-sensitive input component 304 can detect objects that are six inches or less from display component 302, and other distances are also possible. PSI component 304 can determine the position of display component 302 selected by a user's finger using capacitive, inductive, and / or optical recognition techniques. In some examples, presence-sensitive input component 304 also provides output to the user using tactile, audio, or video stimulation as described with respect to display component 302.

[0063] Although illustrated as an internal component of computing device 310, UIC 312 may also represent an external component that shares a data path with computing device 310 to transmit and / or receive input and output. For example, in one example, UIC 312 represents a built-in component of computing device 310 that is located within and physically connected to the external packaging of computing device 310 (e.g., a screen on a mobile phone). In another example, UIC 312 represents an external component of computing device 310 that is located outside and physically separate from the packaging of computing device 310 (e.g., a monitor, projector, etc. that shares a wired and / or wireless data path with a tablet computer).

[0064] One or more processors 340 can implement functions and / or execute instructions within computing device 310. For example, processor 340 on computing device 310 can receive and execute instructions stored by storage component 348, which performs the functions of modules 320, 322, and 324. The instructions executed by processor 340 can cause computing device 310 to store information within storage component 348 during program execution. Examples of processor 340 include an application processor, a display controller, a sensor hub, and any other hardware configured to function as a processing unit. Modules 320, 322, and 324 can be operated by processor 340 to perform various actions or functions of computing device 310.

[0065] One or more storage components 348 within computing device 310 may store information for processing during operation of computing device 310 (e.g., computing device 310 may store data accessed by modules 320, 322, and 324 during execution at computing device 310). In some examples, storage component 348 is temporary memory, and in other examples, storage component 348 is a computer-readable storage medium.

[0066] As a memory, the primary purpose of storage component 348 may not be configured for long-term storage, but rather may be configured for short-term storage of information as volatile memory, so that if computing device 310 is powered off, the stored contents are not retained. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, storage component 348 also includes one or more computer-readable storage media. Storage component 348 can be configured to store a greater amount of information than volatile memory.

[0067] The storage component 348 can be configured to store information long-term as a non-volatile memory space and retain the information after power on / off cycles. Examples of non-volatile memory include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. The storage component 348 can store program instructions and / or information (e.g., data) associated with the modules 320, 322, and 324.

[0068] The UI module 320 is Figure 1 324 and manages input and output to the UIC 312 on behalf of the modules 322, 324, and any other applications or modules installed on the computing device 310. For example, the UI module 320 can direct indications of input received by the PSI component 304 to the compiler module 322 and the application module 324. The UI module 320 can direct indications of output received from the modules 322 and 324 to the display component 302.

[0069] Application module 324 is Figure 1 319. Application module 324 is comprised of object code 319. Application module 324 can be referred to as an executable file or a package comprised of one or more files (including object code 319).

[0070] Compiler module 322 is Figure 1 316. The compiler module 322 is configured to take the source code 316 as input and, in response, generate the object code 319. The compiler module 322 is configured to perform static coordination when compiling the source code 316, as described above in Figure 1 As indicated in the description of , this means that the compiler module 322 can generate the object code 319 to define at least two different sets of rendering instructions based on the source code 318.

[0071] For example, compiler module 322 can parse source code 322 into two types of objects. Compiler module 322 can identify a set of dynamic objects, each of which includes one or more dynamic properties that can change between renderings. Additionally, compiler module 322 can identify a set of static objects, which do not include any dynamic properties and therefore do not change between renderings.

[0072] The compiler module 322 can obtain multiple sets of dynamic and static objects and generate a set of initial rendering instructions to render the dynamic and static objects during an initial rendering of the GUI associated with the application module 324. Alternatively, the compiler module 322 can obtain only the set of dynamic objects and generate a set of update rendering instructions to re-render the dynamic objects that may change over time during subsequent renderings of the GUI associated with the application module 324 without re-rendering the static objects. For example, Figure 2 The rendering instructions 218A and 218B are considered as example sets of initial and update rendering instructions generated from the source code 216.

[0073] In some examples, to further improve efficiency in managing and rendering the GUI, compiler module 322 can perform automatic keying techniques to ensure that dynamic objects in the GUI are rendered correctly. Compiler module 322 can generate rendering instructions such that a unique identifier is assigned to each dynamic object. Using the unique identifier, compiler module 322 can ensure that rendering instructions associated with one dynamic object are not misinterpreted as being used for a different, similar dynamic object.

[0074] The compiler module 322 can determine whether to duplicate any dynamic graphics components of the GUI in the GUI. For example, two or more GUI controls (e.g., buttons, text boxes, etc.) can appear similar in form or function when displayed as part of the GUI. To ensure that an update to a particular dynamic graphics component does not accidentally result in an update to a different, similar dynamic graphics component, the compiler module 222 can automatically assign a corresponding key to each dynamic graphics component that is duplicated in the GUI. The compiler module 322 can generate rendering instructions for the graphics components of the GUI that incorporate the corresponding key so that during execution, the correct rendering instructions are executed to update the particular graphics component. In other words, the compiler module 322 can generate corresponding rendering instructions for each dynamic graphics component that is duplicated in the GUI, and the rendering instructions can be uniquely identified based on the corresponding key.

[0075] In some cases, compiler module 322 can generate a key based on characteristics of source code 318. As an example, compiler module 322 can generate a corresponding key assigned to each dynamic graphics component copied in the GUI based on the location within source code 318 where the dynamic graphics component is referenced. For example, the location used by compiler module 322 can be based on the corresponding line number within source code 318 where the dynamic graphics component is referenced. As another example, the location used by compiler module 322 can be based on the corresponding location of the first byte of a set of rendering instructions appearing within source code 318 that defines each of the dynamic graphics components. In this way, when compiler module 322 generates object code 316, compiler module 322 can incorporate embedded rendering instructions, where specific portions of the embedded rendering instructions are assigned to specific dynamic objects that match the corresponding key.

[0076] Figure 4 is a flow chart illustrating example operations performed by a computing system configured to perform static coordination to render a graphical user interface of an application in accordance with the techniques of this disclosure. Figure 1 The context of the computing device 110 is described in Figure 4 .

[0077] In operation, computing device 110 may compile application source code into one or more object files of the application using static coordination techniques. As an initial step, computing device 110 may receive source code associated with a graphical user interface of the application (410). For example, compiler module 122 may receive source code 116 as a file input received via a developer user interface presented at UIC 112. A developer may write code at the developer user interface and interact with the developer user interface to cause compiler 122 to load and begin analyzing source code 116.

[0078] Computing device 110 may compile source code into a plurality of rendering instructions, the plurality of rendering instructions including a set of initial rendering instructions and a set of update rendering instructions (420). For example, when source code 116 is compiled by a user of computing device 110, compiler module 122 may perform static coordination by dividing a portion of source code 116 into two sets of instructions: a first set associated with dynamic objects and a second set associated with static objects. Compiler module 122 may generate object code (e.g., object code 319) including the two sets of rendering instructions. When executed as part of application module 124, the first set of rendering instructions may cause UIC 112 to display both static and dynamic objects (e.g., user interface 114A). When executed as part of application module 124, the second set of rendering instructions may cause UIC 112 to display updates only to dynamic objects without changing static objects (e.g., user interface 114B). Compiler module 122 may automatically assign corresponding keys to one or more of the subset of graphics components during compilation, wherein a set of update rendering instructions for rendering each of the one or more of the subset of graphics components is uniquely identifiable based on the corresponding keys.

[0079] Computing device 110 may execute application 430 . For example, a processor of computing device 110 (eg, processor 240 ) may execute application 124 and, in doing so, execute the two sets of rendering instructions created in step 420 .

[0080] Computing device 110 may initially render a graphical user interface (440) by executing the set of initial rendering instructions. Specifically, during initial rendering of a GUI associated with application module 124, computing device 110 may execute a first set of "initial" rendering instructions to cause UIC 112 to display user interface 114A.

[0081] Computing device 110 may subsequently, and in some examples, repeatedly, render the graphical user interface (450) by executing a set of update rendering instructions. For example, during each rendering of the GUI associated with application module 124 that occurs after the initial rendering, computing device 110 may execute a second set of "update" rendering instructions to cause UIC 112 to display user interface 114B.

[0082] When executing application module 124, computing device 110 may disambiguate similar or duplicate dynamic graphical components by relying on corresponding key embeddings in corresponding rendering instructions for each dynamic component. For example, if dynamic components 132A and 132B reuse similar rendering functionality and appear similar within user interface 114A, compiler 122 may embed a unique key or other identifier in the rendering instructions for components 132A and 132B such that updates to rendered user interface 114A occur at the appropriate component 132A' or 132B' and are not carried over to other components 132A' or 132B'. By automatically typing the dynamic components of a GUI in this manner and generating embedded machine-readable instructions for rendering the dynamic components, a computing device (such as computing device 110) may render the GUI more efficiently and with fewer errors than other computing devices, such as those that rely on manual (i.e., developer-initiated) keying techniques.

[0083] Various aspects of the techniques described in this disclosure may relate to the examples listed below.

[0084] Example 1. A method for performing static coordination to render a graphical user interface of an application, the method comprising: receiving source code associated with the graphical user interface of the application by at least one processor; compiling the source code into multiple rendering instructions to render a view hierarchy of the graphical user interface, wherein the view hierarchy defines graphical components of the graphical user interface, and wherein the multiple rendering instructions include: a set of initial rendering instructions for rendering the graphical components during initial rendering of the graphical user interface; and a set of update rendering instructions for rendering a subset of the graphical components during subsequent rendering of the graphical user interface; and automatically assigning corresponding keys to one or more of the subsets of graphical components during compilation of the source code, wherein the set of update rendering instructions for rendering each of the one or more of the subsets of graphical components can be uniquely identified according to the corresponding keys; and executing the multiple rendering instructions to update one or more of the subsets of graphical components identified by the corresponding keys.

[0085] Example 2. A method according to Example 1, wherein executing multiple rendering instructions includes: after executing a set of initial rendering instructions during an initial rendering of a graphical user interface: during each subsequent rendering of the graphical user interface, avoiding executing the set of initial rendering instructions and executing a set of update rendering instructions to update one or more of a subset of graphical components identified by the corresponding key.

[0086] Example 3. A method according to Example 1, wherein compiling multiple rendering instructions includes: identifying from the source code a set of dynamic objects that include one or more dynamic properties; and identifying from the source code a set of static objects that do not include any dynamic properties, wherein an initial set of rendering instructions includes instructions for rendering both the set of dynamic objects and the set of static objects, and wherein a set of update rendering instructions includes instructions for rendering the set of dynamic objects without rendering the set of static objects.

[0087] Example 4. A method according to Example 1, wherein compiling multiple rendering instructions further includes: determining whether any one of the graphical components is copied in the graphical user interface; automatically assigning a corresponding key to each of the graphical components copied in the graphical user interface, wherein the corresponding rendering instruction in the multiple rendering instructions from each graphical component copied in the graphical user interface can be uniquely identified according to the corresponding key.

[0088] Example 5. The method of Example 4, further comprising generating a corresponding key assigned to each graphical component replicated in the graphical user interface based on a location within the source code that references the dynamic graphical component.

[0089] Example 6. The method of example 5, wherein the location comprises a corresponding location of a first byte where the plurality of rendering instructions for each of the graphics components reside within the source code.

[0090] Example 7. The method of example 1, wherein the plurality of rendering instructions comprises embedded rendering instructions compiled into machine-readable code.

[0091] Example 8. A device configured to perform static coordination to render a graphical user interface of an application, the device comprising: one or more processors configured to: receive source code associated with the graphical user interface of the application; compile the source code into multiple rendering instructions to render a view hierarchy of the graphical user interface, wherein the view hierarchy defines graphical components of the graphical user interface, and wherein the multiple rendering instructions include: a set of initial rendering instructions for rendering the graphical components during initial rendering of the graphical user interface; and a set of update rendering instructions for rendering a subset of the graphical components during subsequent rendering of the graphical user interface; and automatically assigning corresponding keys to one or more of the subsets of graphical components during compilation of the source code, wherein the set of update rendering instructions for rendering each of the one or more of the subsets of graphical components can be uniquely identified according to the corresponding keys; and execute the multiple rendering instructions to update one or more of the subsets of graphical components identified by the corresponding keys; and a display configured to present the graphical components.

[0092] Example 9. An apparatus according to Example 8, wherein the one or more processors are configured to: after executing a set of initial rendering instructions during an initial rendering of a graphical user interface: during each subsequent rendering of the graphical user interface, avoid executing the set of initial rendering instructions and execute a set of update rendering instructions to update one or more of a subset of graphical components identified by the corresponding key.

[0093] Example 10. An apparatus according to Example 8, wherein the one or more processors are configured to: identify from the source code a set of dynamic objects that include one or more dynamic properties; and identify from the source code a set of static objects that do not include any dynamic properties, wherein the set of initial rendering instructions includes instructions for rendering both the set of dynamic objects and the set of static objects, and wherein the set of update rendering instructions includes instructions for rendering the set of dynamic objects without rendering the set of static objects.

[0094] Example 11. An apparatus according to Example 8, wherein one or more processors are configured to: determine whether to copy any one of the graphical components in the graphical user interface; automatically assign a corresponding key to each of the graphical components copied in the graphical user interface, wherein a corresponding rendering instruction from a plurality of rendering instructions from each graphical component copied in the graphical user interface can be uniquely identified according to the corresponding key.

[0095] Example 12. The apparatus of Example 11, wherein the one or more processors are further configured to generate a corresponding key assigned to each graphical component replicated in the graphical user interface based on a location within the source code where the dynamic graphical component is referenced.

[0096] Example 13. The apparatus of Example 12, wherein the location comprises a corresponding location of a first byte where the plurality of rendering instructions for each of the graphics components reside within the source code.

[0097] Example 14. The apparatus of Example 8, wherein the plurality of rendering instructions comprises embedded rendering instructions compiled into machine-readable code.

[0098] Example 15. A non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors to: receive source code associated with a graphical user interface of an application; compile the source code into a plurality of rendering instructions to render a view hierarchy of the graphical user interface, wherein the view hierarchy defines graphical components of the graphical user interface, and wherein the plurality of rendering instructions include: a set of initial rendering instructions for rendering the graphical components during an initial rendering of the graphical user interface; and a set of update rendering instructions for rendering a subset of the graphical components during a subsequent rendering of the graphical user interface; and automatically assign a corresponding key to one or more of the subset of graphical components during compilation of the source code, wherein the set of update rendering instructions for rendering each of the one or more of the subset of graphical components is uniquely identifiable based on the corresponding key; and execute the plurality of rendering instructions to update one or more of the subset of graphical components identified by the corresponding key.

[0099] Example 16. A non-transitory computer-readable storage medium according to Example 15, wherein the instructions, when executed, cause one or more processors to: after executing a set of initial rendering instructions during an initial rendering of a graphical user interface: during each subsequent rendering of the graphical user interface, avoid executing the set of initial rendering instructions and execute a set of update rendering instructions to update one or more of a subset of graphical components identified by the corresponding key.

[0100] Example 17. The non-transitory computer-readable storage medium of Example 15, wherein the instructions, when executed, cause one or more processors to: identify from the source code a set of dynamic objects that include one or more dynamic properties; and identify from the source code a set of static objects that do not include any dynamic properties, wherein the set of initial rendering instructions includes instructions for rendering both the set of dynamic objects and the set of static objects, and wherein the set of update rendering instructions includes instructions for rendering the set of dynamic objects without rendering the set of static objects.

[0101] Example 18. A non-transitory computer-readable storage medium according to Example 15, wherein the instructions, when executed, cause one or more processors to: determine whether any of the graphical components is copied in the graphical user interface; and automatically assign a corresponding key to each of the graphical components copied in the graphical user interface, wherein a corresponding rendering instruction from a plurality of rendering instructions for each graphical component copied in the graphical user interface is uniquely identifiable based on the corresponding key.

[0102] Example 19. The non-transitory computer-readable storage medium of Example 18, wherein the instructions, when executed, further cause the one or more processors to: generate a corresponding key assigned to each graphical component replicated in the graphical user interface based on a location within the source code where the dynamic graphical component is referenced.

[0103] Example 20. The non-transitory computer-readable storage medium of Example 19, wherein the location comprises a corresponding location of a first byte where the plurality of rendering instructions for each of the graphics components reside within the source code.

[0104] Example 21. The non-transitory computer-readable storage medium of Example 15, wherein the plurality of rendering instructions comprises embedded rendering instructions compiled into machine-readable code.

[0105] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on or transmitted through a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include one or more computer-readable storage media corresponding to tangible media (such as data storage media), or communication media, including, for example, any media that facilitates the transfer of a computer program from one place to another according to a communication protocol. In this manner, computer-readable media may generally correspond to (1) a non-transitory tangible computer-readable storage medium, or (2) a communication medium, such as a signal or carrier wave. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in this disclosure. A computer program product may include computer-readable media.

[0106] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices, or other magnetic storage devices, flash memory, or any other storage medium that can be used to store the desired program code in the form of instructions or data structures and that can be accessed by a computer. Moreover, any connection is appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio and microwaves, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio and microwaves are included in the definition of media. However, it should be understood that one or more computer-readable storage media and data storage media do not include connections, carrier waves, signals or other temporary media, but instead refer to non-temporary tangible storage media. Disks and optical disks used herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0107] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Thus, the term "processor" as used herein may refer to any of the aforementioned structures or any other structures suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules. Furthermore, the techniques may be implemented entirely in one or more circuits or logic elements.

[0108] The technology of the present disclosure can be implemented in various devices or equipment, including wireless handsets, integrated circuits (ICs), or a group of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize the functional aspects of devices configured to perform the disclosed technology, but they do not necessarily need to be implemented by different hardware units. Instead, as described above, the various units can be combined in a hardware unit or provided by a collection of interoperable hardware units including one or more processors as described above in combination with appropriate software and / or firmware.

[0109] Various embodiments have been described. These and other embodiments are within the scope of the following claims.

Claims

1. A method for performing static coordination to render a graphical user interface of an application, the method comprising: receiving, by at least one processor, source code associated with the graphical user interface of an application; Compiling the source code into two sets of rendering instructions for rendering a view hierarchy of the graphical user interface, wherein the view hierarchy defines a plurality of graphical components of the graphical user interface, and wherein the two sets of rendering instructions include: a set of initial rendering instructions for rendering all static and dynamic graphical components of the view hierarchy at runtime during an initial rendering of the graphical user interface, and a set of update rendering instructions for rendering the dynamic graphics component at runtime during a subsequent rendering of the graphical user interface, automatically assigning a corresponding key to each of the dynamic graphics components while compiling the source code, wherein the set of updated rendering instructions for rendering each of one or more of the dynamic graphics components is uniquely identifiable based on the corresponding key; Initially rendering the graphical user interface by at least executing the set of initial rendering instructions at runtime, wherein rendering of the graphical user interface includes rendering all of the static graphical components and the dynamic graphical components of the view hierarchy of the graphical user interface; and During each subsequent rendering of the graphical user interface and without recompiling the source code: executing, at runtime, the set of update rendering instructions to update one or more of the dynamic graphics components identified by the corresponding key; and Avoid executing the set of initial rendering instructions.

2. The method according to claim 1, wherein Compiling the two sets of rendering instructions includes: identifying, from the source code, a set of dynamic objects comprising one or more dynamic properties; and identifying from the source code a set of static objects that do not include any dynamic properties, wherein the set of initial rendering instructions includes instructions for rendering both the set of dynamic objects and the set of static objects, and The set of update rendering instructions includes instructions for rendering the set of dynamic objects but not rendering the set of static objects.

3. The method according to claim 1, wherein Compiling the two sets of rendering instructions further includes: determining whether any of the plurality of graphical components is duplicated in the graphical user interface; and automatically assigning the corresponding key to each of the plurality of graphical components replicated in the graphical user interface, Wherein, the corresponding rendering instruction in the two sets of rendering instructions for each graphical component replicated in the graphical user interface is uniquely identifiable according to the corresponding key.

4. The method according to claim 3, wherein: Compiling the two sets of rendering instructions further includes: The corresponding key assigned to each graphical component copied in the graphical user interface is generated based on a location within the source code that references the copied graphical component.

5. The method according to claim 4, wherein The locations include corresponding locations of a first byte at which the two sets of rendering instructions for the copied graphics component reside within the source code.

6. The method according to claim 1, wherein The two sets of rendering instructions include embedded rendering instructions compiled into machine-readable code.

7. A computing system comprising at least one processor configured to perform any one of the methods according to claims 1 to 6.

8. A system comprising means for performing any one of the methods according to claims 1 to 6.

9. A computer-readable storage medium comprising instructions that, when executed, cause at least one processor to perform any one of the methods of claims 1 to 6.

Images