Building optimized download modules leveraging modularized dependencies

Embodiments relate to building a downloadable application. In response to a request to build a downloadable application, a build system determines a set of resources used by the downloadable application. The build system reads this initial set of resources to discover other resources used by the downloadable application. The build system determines resource dependencies for the set of resources and the discovered set of resources, and creates a dependency data structure according to the resource dependencies. Using the dependency data structure, the build system determines a subset of the set of resources and the discovered set of resources to include in a module associated with the downloadable application.

BACKGROUND

Embodiments of the inventive subject matter generally relate to the field of networked computer system, and, more particularly, building downloadable applications using modularized dependencies to determine modules to include in the downloadable application.

Over time, web pages have grown increasingly sophisticated. For example, in the past, the content of a particular web page was fairly static. The content of the page did not change from one request to another. Today, web pages are dynamic, and the content of a particular page can be tailored to a particular user. Further, the content has become more sophisticated. For example, a web page can be designed to run application software downloaded from a web server.

Additionally, the types of devices that are capable of requesting and using web pages have grown. Now, in addition to traditional desktop computers, phones, tablet computers, music players etc. are now able to request and use web pages. Such devices may be connected to networks having differing capabilities (high bandwidth, low bandwidth etc.).

As the content for web pages has grown more sophisticated, so has the size of the content. A downloadable application for a web page can include hundreds if not thousands of modules. Past applications have tended to download modules as they are requested by a downloadable application. This can lead to a noticeable (and potentially irritating) pause in the execution of a downloadable application while the application waits for a module to be loaded.

SUMMARY

Embodiments include a computer program product and an apparatus for building a downloadable application. In response to a request to build the downloadable application, a build system determines a set of resources used by the downloadable application. The build system reads this initial set of resources to discover other resources used by the downloadable application. The build system determines resource dependencies for the set of resources and the discovered set of resources, and creates a dependency data structure according to the resource dependencies. Using the dependency data structure, the build system determines a subset of the set of resources and the discovered set of resources to include in a module associated with the downloadable application.

DESCRIPTION OF EMBODIMENT(S)

The description that follows includes exemplary systems, methods, techniques, instruction sequences and computer program products that embody techniques of the present inventive subject matter. However, it is understood that the described embodiments may be practiced without these specific details. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.

The embodiments of the invention automatically determine resources that are to be included in one or more modules for a downloadable application such that the modules are optimized to include only those resources that satisfy resource dependencies of the downloadable application. In previous systems, software developers have manually determined the modules and resources to build into an application. Such a manual process is difficult to manage given the number of resources a typical application requires. Further, errors in determining which resources to provide for an application build can lead to frustration by end users. If the developer is over-inclusive, the application can take longer to download to a client device. If the developer is under-inclusive, the client device must obtain the necessary resources at run-time, which can lead to irritating pauses while running the application.

The novel application build system described below determines, at application build time, modules that are optimized to include resources that satisfy resource dependencies of an application without including modules and resources that are not required by the application.

FIG. 1depicts a system100for building a downloadable application. System100includes an application builder102for building applications such as downloadable application104. Downloadable application104is typically comprised of multiple resources108that are used (or potentially used) by downloadable application104during the runtime of the application. Hundreds or even thousands of resources may be used during the runtime of a downloadable application. One or more resources may be provided as part of a module. In general, application builder102determines which resources may be used during the runtime of a downloadable application, and using techniques described below, assembles the resources into one or more modules that can be downloaded and run on a client device120.

The resources108can be of various types. Examples of resources include, but are not limited to, JavaScript resources, CSS (Cascading Style Sheet) resources, or HTML (HyperText Markup Language) resources. Additionally, resources can comprise audio and video data files that are used by a downloadable application. Other types of resources are possible and within the scope of the inventive subject matter. Resources may also be referred to as web-facing resources.

Resources108may be stored in a repository. In some embodiments, a Maven repository system may be used. A repository may be a local repository106or a remote repository110. Local repository106is resident on the system that application builder102executes on. In other words, local repository106is available to application builder102without requiring network access. Remote repository110is on a different system than application builder102. Application builder102uses network118to access the remote repository110. In some embodiments, network118is the Internet. In alternative embodiments, network118may be a LAN, WAN or corporate intranet.

In response to a request to build a downloadable application104, dependency analyzer112reads a set of resources that have been identified as being included in the downloadable application104and determines dependencies within the identified resources on other resources that have were not necessarily identified as being included in the downloadable application104(referred to as “discovered resources”). The dependency analyzer112then analyzes the discovered resources for any dependencies on other resources. The process continues recursively until no new resources are discovered as a dependency of another resource.

As resources are identified or discovered, identifiers for the resources are added to a dependency data structure116. In some embodiments, dependency data structure116comprises a dependency graph. The dependency data structure116may be used to identify a name of a resource, the location of the resource, the number of references to the resource, and resources that depend on the resource. The dependency data structure116is then used to determine a subset of resources108that will potentially be used by downloadable application104. A module containing the subset of resources is then created. The module may be downloaded by a client device120that is to execute the downloadable application104.

The module that is created as described above may be referred to as an “optimized module.” The module is optimized in the sense that it contains the resources that downloadable application104may need during its runtime, but does not include substantially more than what may be required.

Client device120may be any type of device configured to execute a downloadable application104. Examples of such devices include personal computers, laptop computers, tablet computers, personal digital assistants, mobile telephones, and set-top boxes. The embodiments of the invention are not limited to any particular type of client device120.

The above-described dependency analysis may be referred to as a static analysis. That is, the information used to determine dependencies is obtained from the resources themselves. In some embodiments, the system includes runtime analysis to determine dependencies and resources to include in one or more modules of downloadable application104. Runtime analyzer114monitors the execution of downloadable application104. The analysis may be performed on test systems prior to deployment of the application or the analysis may be performed as users download and run downloadable application104onto their client devices120.

The runtime analysis may produce runtime characteristics122. The runtime characteristics may include resource dependencies that were not discovered during the static analysis. Additionally, the runtime characteristics122may include statistics such as the number of times a resource was used by various instances of downloadable application104. The runtime characteristics122may be used by dependency analyzer112to modify dependency data structure116, for example, by adding resources that were discovered during the runtime analysis and by including usage statistics for the resources in the dependency data structure116.

Further details on the operation of the system are provided below.

FIG. 2depicts a flowchart200illustrating example operations for building a downloadable application. For example purposes, operations associated with the blocks inFIG. 2will be described as being performed by an application build system (“system”), which may, for example, include any or all of the elements described inFIG. 1or4.FIG. 2illustrates a flow200that the system can perform.

At block202, the system receives a request to build a downloadable application. The request may be issued from within an application development environment or as a command line to a command interpreter.

At block204, the system determines an initial set of resources associated with the application. The system discovers URIs (Uniform Resource Identifiers) that may include or refer to valid resources for an application. For example, the system determines file types, file locations and repositories (both local and remote) that may contain valid resources for a downloadable application. The system may use development toolkits, development frameworks, development environments or other application development tools to determine where valid resources may be located.

As noted above, the system also uses dynamic analysis of previous executions of an application to provide data to the system. Such dynamic analysis may identify browser plug-ins, include libraries, or other resources that are used by an application.

At block206, the system determines a set of resources that have dependencies based on the currently identified resources or modules. In some embodiments, the system reads the definitions of the resource (for example, from a file containing the definition of the resource) to determine dependencies in the resource. The system may identify dependencies in various ways. In examples where a resource is a JavaScript resource, a dependency may be identified using an “import” statement. In examples where a Dojo toolkit is used, a “require” statement may identify a dependency. HTML resource files may be scanned to determine dependencies on CSS files, rules or other resources. CSS rules and inheritance may be used to identify dependencies. For example, a CSS class may depend from its parent. In addition, a CSS rule may be overridden by a later encountered rule. Thus in some embodiments, the ordering of rules is analyzed to determine the true dependencies associated with the CSS rules used by an HTML resource.

At block208, the system checks to determine if any new resource dependencies were discovered. If the system discovers new resource dependencies, then at block210the system updates the dependency data structure with the newly discovered dependencies and returns to block206to determine if further dependencies exist in the newly discovered resources.

Otherwise, if no new dependencies are found, at block212, the system uses the dependency data structure to determine the set of resources to include in a resource package for a downloadable application. The dependency data structure may be analyzed in various ways to determine which resources to include. For example, the system may analyze the dependency data structure to determine ordering issues that may affect whether a resource is actually needed to resolve a dependency. As in the example noted above, CSS resources may be overridden and thus not necessarily be required to resolve dependencies. The dependency data structure can be used to determine whether ordering of CSS resources affects the dependency on CSS resources. Such analysis can be effective in removing numerous unnecessary CSS rules and resources from an application.

Further, the system may analyze the dependency data structure to determine the modularization of the downloadable application. For example, the list may be used to determine a Dojo profile. In some embodiments, the system builds all of the resources identified in the dependency data structure into a single module for a downloadable application. In alternative embodiments, the system builds multiple modules using the dependency data structure. For example, data from runtime analysis of an application may also be used in conjunction with the dependency data to determine how many different resource modules to build for a downloadable application. Statistical analysis obtained from the run-time analysis may be used to determine that resources that are frequently used are placed in a module that is downloaded when the application is instantiated on a client device, while resources that are seldom actually used by the application may be placed in a module that is downloaded only if a resource in the module is actually needed by the downloadable application.

Additionally, other processes executed during the build of a downloadable application may use the dependency data structure build the downloadable application. For example, an application minimizer process may use the dependency data structure to determine a set of resources that are to be minimized before being included in modules for the downloadable application. The list may be used to supply resources to other optimizing tools for further optimization of a downloadable application.

The depicted flowchart is provided as an example to aid in understanding embodiments, and should not be used to limit embodiments. Embodiments can perform additional operations, fewer operations, operations in parallel, operation in a different order, etc.

FIG. 3depicts an example dependency graph300. In the example shown, resources A-G are identified as potentially being used by a downloadable application. Those of skill in the art will appreciate that a typical downloadable application will use many more resources than those illustrated inFIG. 3. In the example illustrated, resource A depends on resources B-E. Resource B in turn depends on resource C. Resource D depends on resource F and resource E depends on both resource F and G. Resources X, Y and Z were identified as potential resources for the application, but during the process described above, eliminated as not being required (for example, the resource was in a toolkit referenced by the application but not actually used, or the resource was overridden by another resource). The links illustrating the dependencies in dependency graph300indicate the results of statistical analysis of previous instances of the application, that provide the percentage of times the resource is actually used in previous instances of the application.

Applying the above-described method to the example dependency graph, some embodiments build a resource library for the downloadable application that includes all of the modules A-G while excluding X-Z. Alternative embodiments may determine that because resource C is seldom used (2%), that modules A-B and D-G may be built in a library that is downloaded upon application instantiation on a client device, while resource C is built in a library that is only downloaded when needed by a running application.

FIG. 4depicts an example computer system. A computer system includes a processor unit401(possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The computer system includes memory407. The memory407may be system memory (e.g., one or more of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.) or any one or more of the above already described possible realizations of machine-readable media. The computer system also includes a bus403(e.g., PCI, ISA, PCI-Express, HyperTransport®, InfiniBand®, NuBus, etc.), a network interface405(e.g., an ATM interface, an Ethernet interface, a Frame Relay interface, SONET interface, wireless interface, etc.), and a storage device(s)409(e.g., optical storage, magnetic storage, etc.). The memory407embodies functionality to implement embodiments described above. The memory407may include one or more functionalities that facilitate the method of building a downloadable application as described above. Any one of these functionalities may be partially (or entirely) implemented in hardware and/or on the processor unit401. For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor unit401, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated inFIG. 4(e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor unit401, the storage device(s)409, and the network interface405are coupled to the bus403. Although illustrated as being coupled to the bus403, the memory407may be coupled to the processor unit401.