Efficient packing of components

Abstract

By analyzing telemetry data of multiple end devices, learn the correct cluster of operating system (OS) components to package for hydration to client devices. Telemetry data captures snapshots of OS components used or loaded by end devices during different application runs. An OS component service mines this telemetry data and compares how often pairs of OS components are used together by end devices during different application runs. Using these frequencies, the OS components are filtered and a clustering algorithm is applied in a relationship graph to determine whether the OS components are interdependent (meaning used together) or independent (meaning not used together). Interdependent OS components are packaged together into hydration packages and can be delivered to client computing devices that request any constituent OS component.

Description

Background Technology

[0001] Traditional operating systems (OSes) are designed to be widely used by many user groups across diverse user scenarios. OS engineers extended OS capabilities by allowing users to download and install additional OS components required by specific applications that are not available by default. However, with the diversification of the consumer space, defining custom OS combinations for each scenario is impractical and inefficient. This led to the design of OSes to adapt to the needs of different users over time by hydrating the required OS components to the local device on demand, as applications require them. However, applications today are unaware of all OS component dependencies and therefore only request specific OS components identified as missing by the application, without requesting other OS components that the application also needs but were not initially identified. Consequently, when the client computing device discovers the various dependencies of OS components, OS components are often downloaded sequentially and piecemeal, with OS component A being hydrated first, OS component B next, and so on. This piecemeal on-demand sequencing increases latency for applications to obtain the correct OS components and also wastes valuable processing, network, and storage resources used to download different batches of OS components.

[0002] Furthermore, downloadable OS component packages often do not contain the correct components, or include many components that are not used by the end device. Unused OS components waste the end device's valuable storage and processing resources, especially since they are loaded into valuable active memory. Packages missing necessary OS components require the end device to request and download additional components, wasting time and processing resources. Similarly, when loading OS components from persistent storage into active memory on a client device (e.g., to run a specific application), traditional OSes load pre-defined packages of components selected by the developer. For the same reasons mentioned above, these developer-selected packages often include OS components that are not used or needed by running applications, wasting the memory space they are moved to.

[0003] In both current scenarios—downloading missing OS components and moving OS components to active storage—the dependencies of the OS components hydrated to the client device are not known in advance by the requesting application and are subject to the developer's expertise. Therefore, unnecessary OS components are downloaded or moved to active storage, consuming valuable resources on the client device. Alternatively, necessary OS components may not be included in the OS package, and the client device subsequently needs to retrieve interdependent OS components piecemeal. Summary of the Invention

[0004] The disclosed examples will be described in detail below with reference to the accompanying figures. The following overview is provided to illustrate some of the examples disclosed herein. However, this is not intended to limit all examples to any particular configuration or sequence of operations.

[0005] The embodiments disclosed herein utilize machine learning to determine the interdependencies of OS components by analyzing telemetry data from numerous terminal devices. The telemetry data is analyzed, and the different OS components used by the terminal devices during different application runs are analyzed to determine their usage relationships (e.g., the frequency with which OS component A is used in conjunction with OS components B, C, etc.). These OS components are correlated based on the frequency or number of times they appear together in the telemetry data. Using clustering algorithms and filtering the telemetry data based on the frequency or number of times OS components appear together, OS components are classified as interdependent (meaning they are used together) or independent (meaning they are not used together). Interdependent OS components are grouped together to form clusters, and these clusters are correlated to create hydration packages, which can be hydrated to a client computing device whenever one of the OS components in a cluster is requested. For example, a request for OS component A can generate a cluster of interdependent, unrequested OS components B, C, and D. Thus, a client computing device requesting to download an OS component receives a hydration package with additional OS components operating alongside the requested OS component, saving valuable time and processing resources and avoiding the need to download other interdependent OS components later. Attached Figure Description

[0006] The disclosed examples are described in detail below with reference to the accompanying drawings listed below:

[0007] Figure 1 This is a block diagram of an example client computing device 100 used to implement the aspects disclosed herein;

[0008] Figure 2 This is a block diagram of a network environment 200 used to provide OS component services, which learn the interdependencies of OS components from many terminal devices;

[0009] Figure 3 The illustration shows a snapshot of telemetry data from a terminal device;

[0010] Figure 4 The diagram illustrates the frequencies of OS components appearing in telemetry data relative to each other;

[0011] Figure 5 The diagram illustrates a graphical representation of the created OS component cluster.

[0012] Figure 6 The diagram illustrates a workflow for building a cluster of components for autonomous OS components, which are then integrated into client computing devices; and

[0013] Figure 7The diagram illustrates a workflow for machine-generated clusters used to test and modify OS components. Detailed Implementation

[0014] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals are used throughout the drawings to denote the same or similar parts. References throughout this disclosure relating to particular examples and practices are provided for illustrative purposes only and are not intended to limit all examples unless otherwise indicated.

[0015] This disclosure relates to systems, methods, and computer program products for facilitating the dynamic addition and removal of OS components on a computing device based on interdependencies of OS components identified through machine learning. The disclosed embodiments and examples intelligently select the correct OS components to hydrate to a client device by learning interdependencies between OS components from telemetry of other end devices. In some embodiments, the analyzed telemetry data consists of snapshots of OS components running or loaded during different runs of an application on the end device. These snapshots of the telemetry data can then be analyzed to determine the interdependencies of OS components relative to each other. For example, during 100 runs of an application on different end devices (e.g., smartphones, laptops, wearables, etc.), OS component A may load OS component B 100% of the time but only OS component C 20% of the time. Therefore, OS component A can be considered interdependent with OS component B but independent of OS component C.

[0016] Once the interdependencies of OS components are determined from telemetry data from other devices, the OS components are organized into the cluster. When a client computing device requests an OS component, the entire cluster, including the requesting OS component and other interdependent OS components, is downloaded or hydrated to the client computing device.

[0017] Traditional operating systems (OSes) expose an application programming interface (API) surface through a series of applications and dynamically loaded libraries (DLLs). A single DLL may expose a series of API calls, which may be used by one or more applications executing on the client device. OSes, such as those developed by Microsoft in Redmond, Washington... The Mac, developed by Apple in Cupertino, California Android from Google in Mountain View, California TM Both OS and application development platforms (APIs) are equipped with a well-defined set of OS components and a consistent API surface to ensure cross-platform application compatibility. Application developers create software applications that use a subset of the full OS API surface, and therefore also use a subset of OS functionality. This utilized subset maps to a set of functions within the OS.

[0018] In the current context, an "OS component" is a software module that exposes an Application Programming Interface (API) surface that applications can use to connect to and access the underlying hardware. The sum of all the API surfaces exposed by all OS components constitutes the API surface usable by the application, sometimes referred to as a Software Development Kit (SDK). OS components can be loaded in the same address space as the application process or in a different process, in which case they can be accessed using remote procedure calls. Examples of OS components include, but are not limited to, dynamic link libraries (DLLs), binaries, etc. Internet (WinINET), indexer services, text-to-speech converters, etc.

[0019] The features of an application's operating system consist of several interdependent OS components. These OS components are modularly designed to support certain functions and call upon other components. OS components are designed to focus on the specific functions that constitute that feature. For example, OS components might be designed to render images to the screen, manage player movement in a game, track light reflections in objects, and so on.

[0020] "Telemetry data" refers to a snapshot of data collected from a computing device that specifies instances of running applications and OS components that are being used or loaded during the operation of these applications. Generally, instances of running applications and the OS components they invoke are referred to herein as "traces" or "stack traces." The disclosed embodiments collect and analyze telemetry data from a wide range of computing devices, such as, but not limited to, laptops, mobile tablets, smartphones, game consoles, Internet of Things (IoT) devices, augmented reality (AR) or virtual reality (VR) headsets, etc.

[0021] "Interdependence" refers to two OS components that are determined to be used together based on telemetry data from the terminal device. Conversely, "independent" OS components are OS components that are determined not to be used together based on telemetry data from the terminal device.

[0022] "OS cluster" or "cluster" refers to one or more components used for downloading to a client device. A cluster can include any number of OS components (e.g., one, two, five, ten, etc.). In some embodiments, an OS cluster includes only "bidirectionally dependent" OS components, meaning they are determined to be interdependent in two directions (e.g., from OS component A to B and from OS component B to A). "Direct" bidirectional interdependence means that two OS components are determined to be interdependent in two directions (e.g., OS component A to B and B to A). For example, OS components A and B are present with each other 100% of the time in both directions, or at least both are present above a interdependence threshold. "Indirect" bidirectional interdependence means that two OS components (e.g., OS components A and C) are not directly dependent on each other in at least one direction, but are interdependent with an intermediate OS component (e.g., B). For example, OS component A may be present with C 100% of the time, while C is present with C only 20% of the time; however, B is present with both A and C 100% of the time. In such a case, OS components A and C are determined to be interdependent based on their intermediate relationship with B. Therefore, bidirectional dependencies between OS components within an OS cluster can be satisfied directly between OS components or indirectly through intermediate OS components.

[0023] A "hydration package" is a group of one or more OS clusters. The disclosed OS clusters differ from hydration packages in that a cluster is an atomic unit where all OS components have direct or indirect bidirectional dependencies; however, a hydration package can include clusters interconnected through strong directional dependencies. "Bidirectional interdependence" means that OS components are determined to depend on each other in two ways, for example, OS component A to B and OS component B to A.

[0024] Along these routes, an OS cluster consists of a set of strongly connected components that are directly or indirectly interdependent with other OS components classified into the same cluster. A hydration package consists of one or more OS clusters, one of which is an immediate OS cluster containing the OS components requested by the client machine. Other OS clusters are associated with the immediate cluster using the techniques described below. Specifically, the association between two OS clusters is measured by the directional edges of the graph of relationships from any OS component in one cluster to any other OS component in the other cluster.

[0025] "Hydration" and "performing hydration" refer to: (1) downloading OS components from an online resource (e.g., a server) to a client device, and / or (2) loading OS components from the local storage of the client computing device into its active memory. Conversely, "dehydration" and "performing dehydration" refer to the operation of removing OS components from the storage or active memory of the client computing device. Furthermore, "local" files and OS components are stored in the memory of the client computing device, rather than in a remote resource such as a server.

[0026] The disclosed embodiments hydrate interdependent OS components to client computing devices in a single download package, rather than sequentially. For example, an OS cluster including interdependent OS components A, B, and C can be hydrated to a client device that only requests OS component A. Traditional hydration systems require the client device to download OS component A, find that OS component B is needed, then download OS component B, find that OS component C is needed, then download OS component C, and so on. This sequential, fragmented hydration increases the total time required to download all necessary, interdependent OS components. However, the disclosed embodiments machine the interdependencies of OS components in advance from telemetry data from other end devices and package all interdependent OS components together for simultaneous hydration. This saves significant time, delivers necessary OS components to client computing devices more quickly, and frees up processing resources needed to replenish OS components over longer periods.

[0027] After providing an overview of some of the disclosed examples and clarifying some terminology, please refer to the accompanying drawings to further illustrate some additional details. The illustrated configurations and sequences of operation are provided to help the reader understand some aspects of the disclosed examples. The drawings are not intended to limit all examples; therefore, some examples may contain different components, devices, or sequences of operation without departing from the scope of the disclosed examples discussed herein. In other words, some examples may be implemented or function in ways different from those shown.

[0028] Figure 1This is a block diagram of an example client computing device 100 for implementing the aspects disclosed herein. Client computing device 100 includes one or more processors 104, input / output (I / O) ports 104, a communication interface 106, computer storage memory (memory) 108, I / O components 110, and communication paths 112. Client computing device 100 is capable of communicating with other online devices via network 114. Client computing device 100 is merely an example of a suitable computing environment and is not intended to impose any limitation on the scope or functionality of the invention. Although client computing device 100 is depicted as a seemingly single device, multiple client computing devices 100 can work together and share the depicted device resources. For example, various processors 102 and memories 108 can be housed and distributed across multiple client computing devices 100.

[0029] Processor 102 includes any number of microprocessors, microcontrollers, analog circuit devices, or similar devices programmed to execute computer-executable instructions for implementing aspects of this disclosure. In some examples, processor 106 is programmed to execute instructions, such as those illustrated in other figures discussed herein.

[0030] I / O port 104 connects various I / O components 110 to the client computing device 100. Example I / O components 120 include, but are not limited to, speakers, displays, touchscreens, augmented reality and virtual reality (AR and VR) headsets, peripherals, microphones, joysticks, scanners, printers, etc. These components are well known to those skilled in the art and do not need to be discussed in detail here.

[0031] Communication interface 106 allows the transfer of software and data between client computer device 100 and external devices via network 114. Examples of communication interface 106 may include a modem, network interface (e.g., Ethernet card), communication port, PCMCIA slot, and card, etc. The software and data transferred via communication interface 106 may be electronic, electromagnetic, optical, or other signals that can be received by communication interface 106. These signals are provided to communication interface 106 via communication path (e.g., channel) 112. This communication path 112 carries signals and can be implemented using wired, wireless, fiber optic, telephone, cellular, radio frequency (RF), or other communication channels.

[0032] Network 114 can include any computer network or combination thereof. Examples of computer networks that can be configured to operate as network 306 include, but are not limited to, wireless networks; terrestrial lines; cable lines; digital subscriber lines (DSL); fiber optic lines; cellular networks (e.g., 3G, 4G, 5G, etc.); local area networks (LANs); wide area networks (WANs); metropolitan area networks (MANs); or the like. However, network 114 is not limited to connections coupling independent computer units. Instead, network 114 can also include subsystems for transmitting data between servers or computing devices. For example, network 114 can also include point-to-point connections, the Internet, Ethernet, electrical buses, neural networks, or other internal systems. Such network architectures are well known and do not need to be discussed in detail here.

[0033] Computer storage memory 108 includes any number of memory devices associated with or accessible by client computing device 100. Computer storage memory 108 may take the form of computer storage media as described below and is operatively configured to provide client computing device 100 with storage of computer-readable instructions, data structures, program modules, and other data for storing and accessing instructions configured to perform various operations of this disclosure. Computer storage memory 108 may include volatile and / or non-volatile memory, removable or non-removable memory, data disks in a virtual environment, or combinations thereof. Furthermore, computer storage memory 108 may include any number of memories associated with or accessible by client computing device 100. Examples of client computing device 100 include, but are not limited to, random access memory (RAM); read-only memory (ROM); electronically erasable programmable read-only memory (EEPROM); flash memory or other memory technologies; CD-ROM, digital versatile disc (DVD), or other optical or holographic media; cassette tape, magnetic tape, disk storage, or other magnetic storage devices; memory connected to an analog computing device; or any other computer memory.

[0034] Computer storage memory 108 can be located inside the client computing device 100 (e.g., Figure 1 The computer storage medium 108 may be located outside the client computing device 100 (not shown) or both (not shown). Additionally or alternatively, the computer storage medium 108 may be distributed across multiple client computing devices 100 and / or servers, for example, in a virtualized environment providing distributed processing. For the purposes of this disclosure, “computer storage medium,” “computer storage memory,” “memory,” and “memory device” are synonyms for computer storage medium 108, and none of these terms include carrier waves or propagation signaling.

[0035] In some examples, computer storage memory 108 stores executable computer instructions for an operating system (OS) 116, various OS components 118 (including those hydrated according to the techniques disclosed herein), and various software applications 120. OS 116 can be any OS designed to control the functions of client computing device 100, including, for example, but not limited to, those from Redmond, Washington. Developed From Cupertino, California Developed MAC Android, developed by Google in Mountain View, California, is an open-source application. TM open source wait.

[0036] Computer storage memory 108 includes main (or "active") memory and secondary memory. Those skilled in the art will understand that active memory is direct-access memory for the processor 102 and is where various applications 120 and OS components 118 are stored. Persistent memory is "persistent" storage (e.g., non-volatile) where low-level OS routines responsible for memory functions, such as disk operation scheduling, head movement, error handling, etc., are stored. Among other functions, persistent memory contains the Basic Input / Output System (BIOS) for moving the correct applications to main memory at startup. Although different OSes store different routines and functions in main memory and secondary memory, this disclosure refers to embodiments using active memory to run application 120 and necessary OS components 118, and using persistent memory to permanently store application 120 and OS components 118 when not in operation. Some specific embodiments discussed below refer to loading application 120 and OS components 118 into active memory for execution.

[0037] OS 116 includes an OS component downloader 122 and an OS loader 124, among other things. The OS component downloader 122 retrieves the necessary OS components 118 required by application 120 from an online source via network 114. The OS loader 124 loads the various OS components 118 into the active memory of computer storage memory 108 for use by application 120 at runtime. For example, using support... Fitness applications for peripheral devices may require OS component 118. Synchronization, among other things. When the fitness app is open. Specific DLLs of the synchronous OS component 118 can be moved to active memory (as described below).

[0038] In operation, the client computing device 100 executes an application 120 that uses a specific OS component 118. For example, a word processing application may have a dictation function that translates text into a specific language. The final language (e.g., Mandarin, English, etc.), and possibly the language-specific font (e.g., Cyrillic), can be packaged into an OS component 118, which must be stored locally on the client computing device 100 for the dictation function to function correctly. If the final language and font are not stored locally, the component downloader 122 must request these necessary OS components 118 for the dictation function to function correctly.

[0039] Traditionally, OS components 118 are not packaged based on their relative dependencies on each other. Instead, they are packaged based on developers assembling downloadable packages. This requires developers to understand and keep up-to-date with the interdependencies. As discussed in more detail below, the disclosed embodiments learn the correct OS components 118 based on the independence of OS components 118 learned from telemetry data from a large number of other computing devices to provide component downloader 122. In this way, the disclosed embodiments machine the correct OS components 118 to provide to client computing device 100.

[0040] In the depicted embodiment, three OS components 118 (A, B, and C) are hydrated to client computing device 100 in cluster 126, and two OS components 118 (D and E) are hydrated to client computing device 100 in cluster 128. These different clusters 126 and 128 represent groups of interdependent OS components 118 that are hydrated to client computing device 100 at the same time or in the same downloadable package. In other words, the five OS components (AE) shown are hydrated to client computing device 100 in two different download clusters 126 and 128.

[0041] Figure 2 A block diagram of network environment 200 is shown, used to learn the interdependencies of OS components 118 by analyzing many other client computing devices shown as terminal devices 150A-N. Network environment 200 involves Figure 1The client computing device 100, one or more servers 202, and terminal devices 150A-N shown are all capable of communicating via network 114. Terminal devices 150A-N represent any number of computing devices 100, such as laptops (150A), smartphones (150B), tablets (150C), etc. Any type of computing device capable of communicating via network 114 can be used as a terminal device for mining telemetry data 250 to learn the interdependencies of OS components 118. For example, connected cars; robots; AR or VR headsets; wearable devices (such as watches, glasses, etc.); personal computers; IoT devices; etc., can all provide publicly available telemetry data for learning the interdependencies of OS components 118.

[0042] In addition, the networked environment 200 includes a client computing device (in Figure 1 In the example shown (marked as 100), the client computing device requests and receives OS component 118 as clusters 126 and 128. For the purposes of this example, client computing device 100 requests one of the OS components 118 (e.g., component A), and server 200 responds with two clusters 126 and 128 of OS component 118 that include component A. The two clusters 126 and 128 shown are connected to each other to indicate that they are included in a single package for download. In other words, all components A in clusters 126 and 128 are hydrated to client computing device 100, even if client computing device 100 requests only a single component (component A). Due to the interdependencies learned using the techniques discussed below, the remaining OS components 118 (component B) are hydrated to client computing device 100 along with the requested OS component (component A).

[0043] Terminal devices 150A-N provide telemetry data 250 to server 200. Telemetry data 250 includes snapshots of OS components 118 that are running or at least loaded for various applications. For example, one snapshot of a given application might list different DLLs used for...

[0044] Server 200 can be any type of server or remote computing device, serving as a dedicated, relational, virtual, private, public, hybrid, or other cloud-based resource. The server includes or can access processor 202, I / O port 204, communication interface 206, computer storage memory 208, I / O components 210, and communication path 212, similar to... Figure 1 Components with the same markings. Server topology and processing resources are generally well known to those skilled in the art and need not be discussed in detail here; it is simply stated that any server configuration can be used to execute the OS components discussed below on a server.

[0045] Server 200 hosts (stores and executes) OS component service 214, which is configured to analyze telemetry data 250 from terminal devices 150A-N, machine learn the interdependencies of OS components specified in the telemetry data 250, and build a cluster of OS components 118 for hydration to requesting client computing devices 100. To this end, OS component service 214 includes a relational module 216, a clustering module 218, and a simulator 220. Before discussing these three, a snapshot of the telemetry data 250 provides some clarity.

[0046] As described above, each of the terminal devices 150A-N transmits telemetry data 250, which contains snapshots of OS components 118 that are running or at least loaded by executing applications on the terminal devices 150A-N. Examples of these include... Figure 3 As shown, these are labeled Snapshots 302, 304, 306, and 308. Snapshot 302 captures OS components A, B, and C loaded during the first run (run 1) of the application (application 1). Snapshot 304 captures OS components A, B, D, and F loaded during run 2 of application 1. Snapshot 306 captures OS components A, B, C, and E loaded during run 1 of the second application (application 2). Snapshot 308 captures OS components A, B, C, E, and G loaded during run 1 of the second application (application 2). Therefore, Snapshots 302-308 indicate which OS components 118 are present during different runs of application 120, thereby creating a dataset that can be analyzed to machine learn the interdependencies of OS components 118. The different snapshots 302-308 can be stored on server 200, as depicted in server storage 222, or in remote cloud storage accessible by server 200.

[0047] In some embodiments, snapshots 302-308 of terminal devices 150A-N are captured at a predetermined sampling rate. For example, terminal devices 150A-N may capture snapshots 302-308 at preset time intervals (e.g., in milliseconds, seconds, minutes, hours, etc.). Alternatively, snapshots 302-308 may be captured when application 120 is opened or closed. Such sampling rates and triggering conditions may be set by developers or learned from datasets through machine learning.

[0048] The relationship module 216 of OS component service 214 analyzes the telemetry data 250 snapshots of terminal devices 150A-N and establishes an association mapping (referred to herein as a "relationship graph," as shown in 224) between OS components 118. This association mapping captures the degree of association between each OS component 118 and other OS components 118. An example of relationship graph 224 is shown in... Figure 4As shown, OS component AG represents all OS components 118 from telemetry data 250 from all terminal devices 150A-N. In this case, relationship module 216 determines the number or frequency (e.g., percentage) of each OS component AG appearing in the telemetry data 250 (e.g., in a snapshot) and each other OS component AG. For example, as Figure 4 As shown, OS component AC appears with the other OS components 100% of the time. However, OS component D appears with OS component A 20% of the time, OS component B appears with OS component C 50% of the time, OS component D appears with OS component F 100% of the time, and OS component E appears with OS component G 0% of the time.

[0049] Instead of percentages between OS components A and B, some embodiments use count values, which represent the total number of times OS components A and B are found together in telemetry data 250. For example, if OS component A is found in a snapshot containing OS component B, the count values ​​for OS components A and B are incremented.

[0050] Relationship module 216 constructs relationship graph 224 to reflect these percentages or frequencies in which OS components AG are found together in telemetry data 250. The percentage or count values ​​between OS components AB are referred to herein as “relationship data.” Furthermore, it should be noted that “frequency” and “percentage” are used interchangeably herein to indicate the number of times OS component 118 is found with another OS component in the snapshot set. For clarity, percentages between OS components AG are used to discuss embodiments, but counts (rather than percentages) can be used equally. Relationship graph 224 indicates the coupling between the use of one OS component 118 and the use of another OS component 118. The various percentages or counts in relationship graph 224 represent the magnitude of the relationships between OS components 118, indicating the likelihood of OS components 118 being used in combination with each other.

[0051] However, it should be noted that the associated sizes between OS components 118 are not always symmetrical. Instead, they are directional, meaning that the percentage indicates how frequently one OS component 118 is found together with another OS component, but vice versa. The percentage of the first OS component 118 to the second OS component 118 may differ from the percentage of the second OS component 118 to the first OS component. Figure 4 As shown, OS component G is discovered 21% of the time when OS component E exists in the snapshot; however, OS component E is discovered 100% of the time when OS component G exists in the snapshot. Therefore, the percentage from E to G (21%) is different from the percentage from G to E (100%).

[0052] Clustering module 218 uses percentages from relation graph 224 to determine which OS components AG are interdependent and which are independent. To do this, clustering module 216 first trims the data in relation graph 224 using the following parameters: (1) a interdependency threshold (percentage or count), and (2) the separation between percentages or counts in one direction of OS components 118 (E to G) and their inverse relationship (G to E). In some embodiments, these parameters are applied to remove or filter data of OS components 118 from relation graph 224 to reduce the size of the OS cluster. This may also vary depending on the type of clustering algorithm used.

[0053] The interdependency threshold indicates a threshold percentage or count that defines the relationship between two OS components 118. If this threshold is exceeded, OS component 118 is classified as interdependent; otherwise, it is classified as independent. For example, the interdependency threshold can be set to 50%, and any OS component 118 with a relationship greater than 50% with other OS components can be identified as interdependent, while OS components with a percentage less than the interdependency threshold can be classified as independent.

[0054] The separation parameter indicates the acceptable percentage or count between the relationships of the two OS components 118 in different directions. (As discussed above and...) Figure 4 The example shown illustrates a directional relationship of 21% from OS component E to OS component G, and a directional relationship of 100% from OS component G to OS component E. The separation parameter indicates that if a directional relationship is considered interdependent, the percentage of the inverse relationship must be less than an acceptable percentage of the separation parameter. For example, if the separation parameter is 40%, and the relationship from OS component G to OS component E is considered interdependent—based on exceeding the previously discussed interdependency threshold (e.g., 50%)—then the relationship from OS component E to OS component G is considered independent (not interdependent) because the difference between the two percentages (100% and 21%) exceeds the 40% separation parameter. If it does not exceed the separation parameter (i.e., the percentages from G to E and E to G are within each other's separation parameters), then the relationship from OS component E to OS component G will be classified as interdependent, even if the percentage from D to A does not exceed the interdependency threshold.

[0055] Additionally or alternatively, after the above-described trimming (noise filtering), some embodiments also note any directional relationship of 0% (i.e., not appearing with other OS components 118) and automatically change the reciprocal directional relationship to 0%. Similarly, if one direction is non-zero, in some embodiments, the other direction may be changed to non-zero (e.g., minimum value).

[0056] Consider another example, assuming a interdependency threshold of 50% and a separation parameter of 30%. And... Figure 4 The example provided shows that the relationship from OS component G to OS component F is 55%, which exceeds the interdependency threshold, thus triggering clustering module 218 to classify F to G as interdependent. Due to this classification, clustering module 218 also checks the interdependency of OS component F to G, which is 45%, not exceeding the 50% interdependency threshold. In summary, F to G is 55%, and G to F is 45%. Because the difference between these two inverse relationships is less than the separation parameter (30%), clustering module 218 also classifies the relationship from OS component G to F as interdependent based on the separation parameter. In other words, when a directional relationship exceeds the interdependency threshold (F to G) but its inverse directional relationship (G to F) does not, the latter relationship (G to F) can still be classified as potentially interdependent because it is within the separation parameter of the directional relationship that does indeed exceed the interdependency threshold.

[0057] In some embodiments, the interdependence threshold and separation parameter are more complex than a fixed threshold and subtractive separation, respectively. Some embodiments use a separation degree that considers each directional relationship of the OS components 118, rather than just the difference. For example, the following equation can be applied to calculate the separation degree between two OS components A and B: Many other techniques can be used to calculate the separation.

[0058] Relationship module 216 is configured to apply interdependency thresholds and separation parameters to filter relationship graph 224 and prepare it for clustering. Oriented relationships in OS component 118, without passing any parameters, can be marked, edited, deleted, or modified to display in the same way.

[0059] Clustering module 218 organizes OS components 118 into clusters, such as clusters 126 and 128, which can be assembled into a hydration package 129 for download to client computing device 100. In some embodiments, clustering module 218 applies clustering algorithms to identify which OS components 118 are interdependent and which are independent to create OS clusters 126 and 128. OS cluster 218 is created by grouping interdependent OS components 118 together. As shown, OS components A, B, and C are interdependent and are therefore organized into cluster 126. OS components D and E are interdependent and are organized into OS cluster 128.

[0060] In some embodiments, clustering module 218 applies the Dulmage Mendelsohn algorithm to relation graph 224 to determine whether OS components 118 are interdependent or independent. Alternative embodiments use different clustering algorithms, such as K-means, mean shift, density-based spatial clustering with noise application (DBSCAN), expectation-maximization (EM) clustering using Gaussian mixture models (GMM), agglomerative hierarchical clustering, etc. By applying such clustering algorithms, clustering module 218 can identify interdependent OS components 118 from relation graph 224 and then create OS clusters 126, 128 of the interdependent OS components 118.

[0061] Some embodiments require direct or indirect bidirectional mutual dependence before being included in OS clusters 126, 128, meaning that two OS components 118 are determined to be mutually dependent in both directions (e.g., A to B and B to A). If either direction is independent (e.g., not exceeding a mutual dependence threshold or separation parameter), some embodiments do not package OS components 118 together into the cluster. Therefore, in some embodiments, OS clusters 126, 128 (classified by clustering module 218) contain only components with direct or indirect bidirectional mutual dependence.

[0062] Furthermore, direct bidirectional interdependence refers to two OS components 118 being determined to be directly or indirectly interdependent in two directions (e.g., OS component A to B and B to A). Examples of direct interdependence include OS component A and OS component B being interdependent in both directions. For example, OS component A is present with OS component B 100% of the time, OS component B is present with OS component A 100% of the time, and the interdependence threshold is 60% (this threshold is exceeded in both directions).

[0063] In some embodiments, clustering module 218 creates hydration packages 129 for one or more of clusters 126 and 128. As described, hydration package 129 includes OS clusters 126 and 128. In some embodiments, clustering module 218 associates OS clusters with each other based on directional relationships that make up OS cluster 118. This association is accomplished by comparing the directional relationships of OS components 118, and if any OS component 118 in one OS cluster 126 has a directional relationship with another OS component 118 in another cluster 128, then the two OS clusters 126 and 128 are packaged together in the same hydration package 129. In other words, some embodiments combine OS clusters into hydration packages 129 based on one or more OS components 118 having a relationship greater than a packaging threshold.

[0064] Additionally or alternatively, an indirect packing threshold can also be applied to pack OS clusters 126 and 128 into a hydration pack 129. In this case, the directional relationships between OS components 118 in the associated OS clusters 126 and 128 are checked to see if they exceed a threshold higher than the packing threshold. For example, the highest relationship between OS components 118 in OS clusters 126 and 128 could be 55%, exceeding the 50% packing threshold, thus associating OS cluster 128 with OS cluster 126. Furthermore, the directional relationships between OS components 118 in OS cluster 128 and other OS components not in either OS cluster 126 or 128 can be checked to see if they exceed a higher indirect packing threshold (e.g., 75%). For example, if OS component E in OS cluster 128 has a 90% relationship with another OS component 118 not in either OS cluster 126 or 128, then that additional OS component 118 and its associated cluster are included in the hydration pack 129. In summary, the directional relationships of OS components 118 in the associated OS clusters 126 and 128 are checked to see if they have strong relationships (e.g., greater than the indirect packing threshold) to indicate that other OS clusters should be included in the hydration package 129. If so, they are added to the hydration package 129 by the clustering module 218.

[0065] When client computing device 100 requests an OS component that is already clustered with other interdependent OS components 118, the entire hydration package 129 of the OS clusters 126, 128 of the interdependent OS components 118 is sent to client computing device 100 for hydration on it. For example, Figure 2 The example illustrates how clustering module 218 creates a hydration package 129 containing clusters 126 (with interdependent OS components A, B, and C) and 128 (with interdependent OS components D and E). If client computing device 100 requests OS component A, the entire hydration package 129 (containing OS component AE) of clusters 126 and 128 to which OS component A belongs is hydrated to client computing device 100. Although client computing device 100 only requests OS component A, it also receives other OS components BE, eliminating the need to download these other interdependent OS components 118 later.

[0066] Figure 5The diagram illustrates the component graph of OS component AG, which is grouped into four distinct clusters 502, 504, 506, and 508 based on their directional relationships with each other. A total of four clusters 502-508 are shown as having different OS components AF. Specifically, OS components A and B are grouped into cluster 502; OS components B, C, and D are grouped into cluster 504; OS component F is grouped into OS cluster 506; and OS component G is grouped into cluster 508. Cluster 502 contains OS components A and E because they have a bidirectional mutual dependency, attributed to their presence in telemetry data exceeding a 50% mutual dependency threshold. Similarly, OS components B, C, and D are grouped into OS cluster 504 based on a bidirectional mutual dependency threshold exceeding 50%. OS components F and G do not have bidirectional mutual dependencies with other OS components and are therefore grouped into their own OS clusters 506 and 508, respectively.

[0067] Figure 5 A hydration package 529, comprising OS clusters 502, 504, and 508, is also illustrated based on direct and indirect packing thresholds. In the depicted example, the direct packing threshold is set at 75%, meaning that the directional relationship between any OS component AG in one cluster 502-508 and an OS component AG in another cluster 502-508 is greater than 75%, creating an interdependence between the two clusters 502-508 and including both clusters 502-508 in the hydration package 529. Furthermore, the indirect packing threshold is set at 85%, meaning that the directional relationship between any OS component AG in the associated (second) cluster 502-508 and another OS component AG in a third cluster 502-508 outside the two associated clusters is greater than 85%, creating another interdependence between the third cluster 502-508 and the two directly related clusters 502-508. In other words, the direct and indirect packing thresholds are used to directly or indirectly (meaning via another cluster) merge different clusters 502-508 into the hydration package 529.

[0068] Applying direct and indirect packing thresholds, hydration package 529 is created to include clusters 502, 504, and 508. Upon closer inspection, cluster 502 contains 90% of the relationships from OS component A to B, creating an interdependency between clusters 502 and 504. Furthermore, the relationship from OS component D to G is 90%, exceeding the indirect packing threshold, thus creating an interdependency between clusters 502 and 508 via cluster 504. However, cluster 506 does not exceed either the direct or indirect packing threshold, nor the interdependency threshold, and therefore is not included in hydration package 529.

[0069] Clustering module 218 analyzes telemetry data 250 to create these interrelationships among OS clusters 502, 504, and 508 and generates a hydration package 529. Then, when client computing device 100 requests OS component A, for example, the entire hydration package 529 of OS clusters 502, 504, and 508 is hydrated to client computing device 100. This allows client computing device 100 to simultaneously receive interdependent OS components E, B, C, D, and G along with OS component A, thereby saving valuable time and processing resources.

[0070] See you again Figure 2 Some embodiments include a simulator 220 to verify efficiency and train a relation module 216 and a clustering module 218 to create more efficient relation graphs 224 and clusters 126, 128, respectively. The simulator 220 hydrates the learned clusters 126, 128 to a test computer and monitors the usage of OS components 118 based on key metrics to understand the effectiveness of OS component services 214 in creating clusters 126, 128, where all OS components 118 actually require application 120. Furthermore, the test computer can be an actual client computing device 100 or a simulated device in a cloud environment (e.g., on a server or virtual machine). The simulator 220 is optional and not used in all embodiments.

[0071] Key metrics used to measure hydration to the simulated clusters 126 and 128 of the test computers include measures indicating any of the following: (1) whether the hydration OS component 118 is used while application 120 is running; (2) the amount of time OS component 118 is used while application 120 is running; and / or (3) how many times application 120 does not have OS component 118 available to it on the local machine. The first two indicate whether OS component service 214 is selecting the OS component 118 that is actually being used, while the third indicates whether OS component service 214 is missing the required OS component 118.

[0072] Feedback data 220 is provided by testing clusters 126 and 128 against these key indicators. Clustering module 218 can use this feedback data 220 when selecting OS components 118 to specifically include clusters 126 and 128. For example, clustering module 218 can initially include OS components A, B, and C from cluster 126 running on a test computer with simulator 220, and measure against the aforementioned key indicators. During simulation, simulator 220 may find that application 120 only uses OS components A and B (not C), and OS component D is missing because it does not meet the aforementioned interdependence threshold or separation parameter, so OS component D is not included. This feedback data 220 can be provided to clustering module 218, which then modifies cluster 126 by removing OS component C and adding OS component D.

[0073] Simulations and measurements against these key indicators allow clustering module 218 to determine whether to modify the various thresholds and clustering algorithms mentioned herein to include more or fewer OS components 118 in the cluster by changing the interdependency thresholds or separation parameters discussed herein. Additionally or alternatively, by changing the packing threshold used for inter-cluster grouping, simulations can be used to relax or tighten the use of inter-cluster interrelatedness for generating hydration packages 129. In other words, the interdependency thresholds, separation parameters, and packing thresholds can be modified by machine learning or by developers based on simulations of applications running on test devices.

[0074] Additionally or alternatively, this feedback data 220 can be used to modify the interdependency threshold and separation parameters without user intervention. For example, if the interdependency threshold is set to 50% but the necessary OS component 118 is missing, the feedback data 220 from the simulator 220 can signal the relationship module 216 to decrease either parameter. Alternatively, if the extra OS component 118 is not used, the feedback data 220 from the simulator can signal the relationship module 216 to increase the aforementioned parameters. The relationship module 216 can then examine the telemetry data to identify the interdependency threshold and / or separation parameters that will produce the actual OS component 118 required by the application 120 under test.

[0075] In this way, simulator 220 provides another way to build a robust cluster of OS components 118 using real-world test data to hydrate to client computing device 100. OS components 118 can be added to or removed from the cluster based on the test data, and the correct interdependency thresholds and / or separation parameters can be learned from the feedback data 220 from the computer under test. Finally, this simulation can be manual or automatic, as long as it achieves the goal of replicating user interactions with application 120.

[0076] To date, embodiments for learning the interdependencies of OS components 118 from other terminal devices 150A-N and then creating clusters of OS components 118 to hydrate to client computing device 100 have been disclosed. The same techniques can also be used, or alternatively, to identify which clusters of OS components 118 already stored on client computing device 100 should be loaded from secondary storage into active storage. For example, a client computing device may have OS components A, B, and C already stored on its hard disk. When a particular application 120 requests to use OS component A, it may know that OS component B will also be needed and should therefore be moved to active storage as well. To simplify things, in some embodiments, the interdependencies determined from telemetry data 250 are shared with client computing device 100. These interdependencies guide OS loader 124 to load a set (e.g., more than one) of locally stored interdependent OS components 118 into active storage simultaneously upon request.

[0077] Figure 6 The diagram illustrates a workflow 600 for autonomously building a cluster of OS components, which are then used to hydrate client computing devices. As shown in 602, telemetry data from multiple end devices is analyzed. This telemetry data includes snapshots of different applications and OS components running on the end devices (e.g., ...). Figure 3 (Snapshots 302-308 in the data). All OS components identified in the snapshots of telemetry data are correlated to determine if any dependencies exist, as shown in 604. Example workflow 600A can be executed to correlate OS components with each other and identify dependencies between them.

[0078] The correlation workflow 600A involves identifying OS components first in telemetry data, as shown in 606. Each OS is then analyzed to learn which combinations of OS components are frequently found together during application runtime. For this purpose, OS components are selected, as shown in 608. The data is then filtered or pruned using directional relationship data from the telemetry data (e.g., the percentage of time OS components are found together), for example, as shown in 610, OS component A is found 25% of the time with OS component B, 10% of the time with OS component C, 80% of the time with OS component D, and so on. An alternative embodiment counts the number of times an OS component is found together with each of the other OS components—for example, OS component A is found 5 times with OS component B, 10 times with OS component C, 12 times with OS component D, and so on. After these frequencies or counts are determined, the embodiment runs the same steps for the next OS component until a frequency / count has been determined for all identified OS components, as shown in decision box 612.

[0079] Similar to Figure 3 The relationship graph shown is generated, as illustrated in 614. This graph illustrates the frequency / count between pairs of OS components in the telemetry data. As shown in 616, the graph is filtered by applying the aforementioned interdependency threshold, separation parameter, or by modifying, altering, or deleting directional relationship percentages or counts. Once the graph is filtered, a clustering algorithm is applied to identify OS components as interdependent or independent, and the categorized OS components are organized into clusters based on their dependencies, as illustrated in 618.

[0080] Returning to workflow 700, the directional relationship data of the OS components in the cluster is analyzed to correlate the clusters with each other, as shown in 616. This involves applying the aforementioned packing thresholds to determine whether clusters can be correlated together. A hydration package containing one or more correlated clusters is created, as shown in 618.

[0081] The OS component service awaits requests from client computing devices that request OS components within their clusters that have been hydrated, as shown in 624. When such a request arrives (e.g., for OS component A), the relevant cluster's hydrated components are hydrated to the client computing device, as shown in 626. This hydration can thus involve downloading all OS components from the cluster.

[0082] Figure 7 The diagram illustrates a workflow 700 for testing and modifying machine-generated OS component clusters. Workflow 700 is executed after the OS component clusters are created by the previously discussed OS component services, for example, the operations of workflow 600. As shown in 702, interdependent OS component clusters are identified. The OS component clusters are then watered into a test computer, as shown in 704. As previously mentioned, the test computer can be a client computing device or a simulated computer in a cloud environment. Essentially, the test computer can be any device or instruction set used to mimic how a user interacts with an application. Once the OS component clusters are watered into the test computer, the application runs on the test computer, as shown in 706.

[0083] As shown in 708, key metrics from the test computer with a hydrated cluster are measured. These key metrics can indicate any of the following: (1) whether the hydrated OS components are used during application runtime; (2) the amount of time the OS components are used during application runtime; and / or the number of times the application requires dehydrated OS components. Along these lines, decision box 710 shows the test computer being checked to see if the OS components in the hydrated cluster are running. Those components that are verified to be interdependent are shown in 714. For example, if the cluster contains OS components A, B, and C, and the test computer shows that OS components A and B are running, the interdependence classification of components A and B remains unchanged. OS components that are not running in the cluster (e.g., OS component C in the example above) are indicated as independent in the feedback data, as shown in 716, and are also removed from the cluster, as shown in 718.

[0084] Another key metric is checking if the cluster is missing any OS components. This is demonstrated by examining the telemetry data of the test computer to see if the running applications require any dehydrated OS components (i.e., OS components not stored locally on the test computer). This is illustrated in decision box 712. If not, feedback data indicating cluster completion is created, as shown in 720. However, if yes, the missing OS components are indicated in the feedback data, as shown in 722, and the missing OS components are added to the cluster, as shown in 724. Additional examples

[0085] Some additional examples are described in the following clauses: 1A. A method for constructing a cluster of OS components for hydration to a client computing device, the method comprising: Analyze telemetry data from multiple terminal devices to determine the interdependencies of different OS components, the telemetry data including the trajectories of the different OS components during previous operation on the multiple terminal devices; The different OS components are correlated based on the telemetry data to determine that at least two OS components are interdependent; and Create the component cluster to include one or more OS components that are interconnected with each other. 2A. The method according to Clause 1A, wherein the interrelationship of the different OS components includes applying a clustering algorithm to classify the at least two OS components among the OS components. 3A. The method according to Clause 2A, wherein the clustering algorithm comprises at least one of the following: the Durmagi-Mendelson algorithm, K-means, mean shift, density-based spatial clustering with noise application (DBSCAN), expectation-maximization (EM) clustering using a Gaussian mixture model (GMM), or agglomerative hierarchical clustering. 4A. The method according to any one of clauses 1A-3A, wherein the interrelation of the different OS components comprises first filtering at least some of the different OS components by: Create a relationship diagram of the different OS components; Calculate the difference between a first frequency from the first OS component to the second OS component and a second frequency from the second OS component to the first OS component; Determine that the difference is less than a separation parameter, which specifies the maximum difference between two frequencies of the different OS components; Based on the comparison between the determined frequency and the interdependency threshold, some OS components among the different OS components are filtered from the relationship graph. 5A. The method according to any one of clauses 1A-4A, wherein the interrelation of the different OS components includes first filtering at least some of the OS components by: Create a relationship diagram of the different OS components; Calculate the difference between a first frequency from the first OS component to the second OS component and a second frequency from the second OS component to the first OS component; Determine that the difference is less than a separation parameter, which specifies the maximum difference between two frequencies of the different OS components; Based on the comparison between the determined frequency and the interdependency threshold, some OS components among the different OS components are filtered from the relationship graph. 6A. The method according to any one of clauses 1A-5A further comprises: Create a hydration package, the hydration package comprising the component cluster having one or more OS components that are interconnected among the OS components. 7A. The method described under Clause 6A further includes: Receive requests from the client computing device for OS components in the component cluster; and The hydration package, comprising the cluster of components having one or more interconnected OS components, is sent to the client computing device for hydration thereon. 8A. The method according to any one of clauses 1A-7A further includes simulating the hydration package on the test terminal device by hydrating the hydration package to the test terminal device, executing an application thereon, and analyzing the required OS components for the executed application. 9A. The method according to any one of clauses 1A-8A further comprises: Hydrate at least two of the OS components in the OS components to the test computer; When the test computer is running one or more applications, at least two of the OS components are used multiple times by the test computer; and Based on the fact that at least two OS components in the OS components are used multiple times by the test computer, the interdependence classification of the at least two OS components in the OS components is maintained. 10A. The method according to any one of clauses 1A-9A further comprises: Hydrate at least two of the OS components in the OS components to the test computer; After at least two OS components have been hydrated, determine the OS components that need to be missing on the test computer; and Based on the missing OS components required on the test computer, the missing OS components are added to the component cluster. 11A. The method according to any one of clauses 1A-10A further includes adjusting the interdependence threshold used to associate the different OS components with each other based on the missing OS component. 12A. The method according to any one of clauses 1A-12A, wherein the telemetry data includes a snapshot of the operation of the application on the terminal device acquired at a sampling rate. 13A. The method according to any one of clauses 1A-13A, wherein the client computing device includes at least one of a laptop computer, a mobile tablet computer, a smartphone, a game console, an Internet of Things (IoT) device, an augmented reality (AR) headset, or a virtual reality (VR) headset. 14A. A system for building a hydration package, the hydration package including one or more component clusters of operating system (OS) components, the hydration package being used to hydrate the OS components to a client computing device, the system comprising: A memory, implemented with instructions for constructing a cluster of one or more components based on the interdependencies of different OS components; and One or more processors are programmed to: Analyzing telemetry data from multiple terminal devices to determine the interdependencies of different OS components, the telemetry data including the trajectories of the different OS components during previous operation on the multiple terminal devices. The different OS components are correlated based on the telemetry data to determine that at least two OS components are interdependent; Create the one or more component clusters to include one or more OS components that are interconnected; and Create the hydration package that includes the cluster of one or more components. 15A. The system as described in Clause 14A, wherein the interrelationship of the different OS components includes: Analyze the directional relationships between the different OS components; Identify directional relationships that exceed a mutual dependence threshold; The pair of OS components with bidirectional interdependencies among the different OS components are identified at least in part based on the directional relationship exceeding the interdependency threshold; and The pairs of OS components in the different OS components are classified as interdependent based at least in part on the identification of the pairs of OS components that have bidirectional interdependence in the different OS components. 16A. The system according to any one of clauses 14A-15A, wherein the creation of said cluster of one or more components comprises at least in part: The different OS components that are identified as interdependent will be grouped into multiple clusters; Analyze the directional relationship between the first group of OS components in the first cluster and the second group of OS components in the second cluster; Determine that the directional relationship between at least one OS component in the first group of OS components in the first cluster and at least one OS component in the second group of OS components in the second cluster exceeds a packaging threshold; and Based on the determination, the hydration package is created to include the first cluster and the second cluster. 17A. The system according to any one of clauses 14A-16A, wherein said one or more processors are further programmed to: Hydrate one or more of the relevant OS components to the test computer; After one or more of the relevant OS components have been hydrated, it is determined that the hydrated OS components are not used on the test computer; and Remove the unused OS components from the hydration package. 18A. One or more computer storage devices, implemented with computer-executable instructions for constructing a cluster of operating system (OS) components for hydration to a client computing device, the OS components for hydration to the client computing device, the one or more computer storage devices comprising: The relationship module is configured as follows: Analyzing telemetry data from multiple terminal devices to determine the interdependencies of different OS components, the telemetry data including trajectories between the different OS components during previous operation on the multiple terminal devices; and A clustering module applies a clustering algorithm to the telemetry data to create the component cluster that includes one or more OS components from the OS components. 19A. One or more computer storage storage devices as described in Clause 18A, further comprising: The test module is configured as follows: Hydrate the component cluster to the test computer; Monitor applications running on the test computer that use one of the one or more OS components; Identify any missing OS components required by the test computer during application execution; and Add the missing OS component to the component cluster. 20A. One or more computer storage devices according to any one of clauses 18A-19A, wherein the one or more OS components were initially determined to be independent at least in part based on not exceeding the interdependency threshold, but were subsequently determined to be interdependent based on exceeding the separation parameter.

[0086] The disclosed embodiments, examples, and techniques can be described in the general context of software, hardware components, or program modules. Typically, such modules contain routines, programs, objects, elements, components, data structures, etc., that perform specific tasks or implement specific abstract data types. The terms "module," "function," and "component" as used herein generally refer to software, firmware, hardware, or a combination thereof. The techniques described herein are platform-independent and can therefore be implemented on a wide range of commercial computing platforms and processing configurations.

[0087] The examples and embodiments disclosed herein can be described in the general context of computer code or machine-usable instructions, including computer-executable instructions (e.g., program components) that are executed by a computer or other machine (e.g., a personal data assistant or other handheld device). Typically, program components, including routines, programs, objects, components, data structures, etc., are code adapted to perform a specific task or implement a specific abstract data type. The disclosed examples can be practiced in a variety of system configurations, including personal computers, laptops, smartphones, mobile tablets, handheld devices, consumer electronics, dedicated computing devices, etc. The disclosed examples can also be practiced in distributed computing environments, such as... Figure 2 Those disclosed herein and described in more detail below, wherein the tasks are performed by remote processing devices linked via a communication network.

[0088] In one embodiment, this disclosure is directed to one or more computer systems or computing devices capable of implementing the functions of the embodiments described herein. In particular, some of the disclosed functions are performed by client computing devices, while others are performed by one or more cloud-based devices or servers. Examples of client computing devices are provided in... Figure 1 An example of a server is shown in [the image / description]. Figure 2 The functions of the disclosed client computing device can be performed by the disclosed server, and vice versa.

[0089] Although aspects of this disclosure have been described with reference to various examples and their associated operations, those skilled in the art will understand that combinations of operations from any number of different examples are also within the scope of aspects of this disclosure.

[0090] The order in which the operations in the disclosed examples illustrated and described herein are performed or executed is not required, and they may be performed in different orders in various examples. For example, a particular operation may be performed or executed before, simultaneously with, or after another operation within the scope of this disclosure.

[0091] When describing elements or examples of aspects of this disclosure, the articles “a,” “an,” “the,” and “the” mean one or more elements present in the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that additional elements may be present in addition to the listed elements. The term “exemplary” means “an example.” The phrase “one or more of the following A, B, and C” means at least one of A and / or B and / or C.

[0092] Having described aspects of this disclosure in detail, it will be apparent that modifications and variations are possible without departing from the scope of the aspects of this disclosure as defined in the appended claims. Since various changes can be made to the foregoing constructions, products, and methods without departing from the scope of the aspects of this disclosure, all that is included in the foregoing description and shown in the accompanying drawings should be interpreted as illustrative rather than restrictive.

Claims

1. A computer-implemented method for constructing a cluster of components for an operating system (OS) for use in a client computing device, the cluster of components comprising: Analyze telemetry data from multiple terminal devices to determine the interdependencies of different OS components, the telemetry data including the trajectories of the different OS components during previous runs of the application on the multiple terminal devices; The different OS components are correlated based on the telemetry data to determine that at least two OS components are interdependent; Create the component cluster to include one or more OS components that are interconnected with each other; Create a hydration package, the hydration package comprising the component cluster having one or more OS components that are interconnected among the OS components; Receive requests from the client computing device for OS components in the component cluster; as well as The hydration packet, comprising the cluster of components having one or more interconnected OS components, is sent to the client computing device for hydration on the client computing device.

2. The computer-implemented method according to claim 1, wherein the interrelationship of the different OS components includes applying a clustering algorithm to classify the at least two OS components.

3. The computer-implemented method according to claim 2, wherein the clustering algorithm includes at least one of the following: the Dulmagi-Mendelson algorithm, K-means, mean shift, density-based applied spatial clustering with noise (DBSCAN), expectation-maximization (EM) clustering using a Gaussian mixture model (GMM), or agglomerative hierarchical clustering.

4. The computer-implemented method of claim 1, wherein the interrelation of the different OS components comprises first filtering at least some of the OS components by: Create a relationship diagram of the OS components; Determine a first frequency from the first OS component to the second OS component minus a second frequency from the second OS component to the first OS component; The first frequency and the second frequency are compared with a cross-dependency threshold; as well as Based on the comparison between the determined frequency and the interdependency threshold, some OS components in the OS components are filtered from the relationship graph.

5. The computer-implemented method according to claim 1 or 4, wherein the interrelation of the different OS components comprises first filtering at least some of the OS components by: Create a relationship diagram of the OS components; Calculate the difference between a first frequency from the first OS component to the second OS component and a second frequency from the second OS component to the first OS component; Determine that the difference is less than a separation parameter, which specifies the maximum difference between two frequencies of the OS component; as well as Based on the comparison of the determined difference and separation parameters, some OS components in the OS components are filtered from the relationship graph.

6. The computer-implemented method according to claim 1, further comprising: The hydration package is simulated on the test terminal device by hydrating the hydration package, executing the application thereon, and analyzing the necessary OS components for the executed application.

7. The computer-implemented method according to claim 1, further comprising: Hydrate at least two of the OS components in the OS components to the test computer; It is determined that at least two OS components in the OS are used multiple times by the test computer while the test computer is running one or more applications; as well as Based on the fact that at least two OS components in the OS components are used multiple times by the test computer, the interdependence classification of the at least two OS components in the OS components is maintained.

8. The computer-implemented method according to claim 1, further comprising: Hydrate at least two of the OS components in the OS components to the test computer; After at least two OS components in the OS components have been hydrated, it is determined that there is a missing OS component that is needed on the test computer; as well as Based on the fact that the missing OS component is needed on the test computer, the missing OS component is added to the component cluster.

9. The computer-implemented method of claim 8, further comprising adjusting a mutual dependency threshold for associating the different OS components based on the missing OS component.

10. The computer-implemented method of claim 1, wherein the telemetry data includes snapshots of the operation of the application on the terminal device acquired at a sampling rate.

11. The computer-implemented method of claim 1, wherein the client computing device comprises at least one of the following: a laptop computer, a mobile tablet computer, a smartphone, a game console, an Internet of Things (IoT) device, an augmented reality (AR) headset, or a virtual reality (VR) headset.

12. A system for constructing a hydration package of a component cluster including an operating system (OS) component, the hydration package being hydrated to a client computing device, the system comprising: The memory is equipped with instructions for constructing the component cluster based on the interdependencies of different OS components; as well as One or more processors are programmed to: Telemetry data from multiple terminal devices is analyzed to determine the interdependencies of different OS components, including the trajectories of these different OS components during previous runs of applications on the multiple terminal devices. The different OS components are correlated based on the telemetry data to determine that at least two OS components are interdependent; Create the component cluster to include one or more OS components that are interconnected with each other; Create the hydration package that includes the cluster of said components; Receive requests from the client computing device for OS components in the component cluster; as well as The hydration packet, comprising the cluster of components having one or more interconnected OS components, is sent to the client computing device for hydration on the client computing device.

13. The system of claim 12, wherein the interconnected OS components are related to each other and are classified as interdependent or independent by the application of a clustering algorithm.

14. The system of claim 13, wherein the one or more processors are further programmed to: Hydrate the one or more interconnected OS components to the test computer; After the one or more interconnected OS components have been hydrated, it is determined that the hydrated OS components are not used on the test computer; and Remove the unused OS component from the component cluster.

15. The system of claim 12, wherein the one or more processors are further programmed to: Hydrate the at least two OS components to the test computer; After at least two OS components have been hydrated, it is determined that a missing OS component is required on the test computer; and Based on the fact that the missing OS component is needed on the test computer, the missing OS component is added to the component cluster.

16. A computer storage medium embodied with computer-executable instructions, the computer-executable instructions being configured to construct a cluster of operating system (OS) components for use in hydration of a client computing device by performing the following operations: Analyze telemetry data from multiple terminal devices to: Determining the interdependencies of different OS components, the telemetry data includes the trajectories of the different OS components during previous operation of the applications on the multiple terminal devices, and The different OS components are correlated based on the telemetry data to determine that at least two OS components are interdependent; as well as Create the component cluster that includes one or more OS components that are interconnected with each other; Create a hydration package, the hydration package comprising the component cluster having one or more OS components that are interconnected among the OS components; Receive requests from the client computing device for OS components in the component cluster; as well as The hydration packet, comprising the cluster of components having one or more interconnected OS components, is sent to the client computing device for hydration on the client computing device.

17. The computer storage medium according to claim 16, further comprising: Hydrate the component cluster to the test computer; Monitor applications running on the test computer that use one of the one or more interconnected OS components; It was determined that there were missing OS components required by the test computer during the operation of the application; as well as Add the missing OS component to the component cluster.

18. The computer storage medium of claim 16, wherein the one or more OS components that are interconnected are initially determined to be independent at least in part based on not exceeding a mutual dependence threshold, but are subsequently determined to be interdependent based on exceeding a separation parameter.

Images