Monitoring application loading

Methods, systems, and apparatus, for determining when an application is sufficiently instantiated to be subject to a crawling operation. In an aspect, a method includes instantiating a native application instance that generates environment instances for display on a user device within the native application instance; in response to the instantiation of the native application instance: monitoring for occurrences of activity lifecycle events of the native application instance, monitoring for changes in a memory footprint of the native application instance, and generating, in response to the monitoring of the lifecycle events and monitoring of the changes in the memory footprint indicating the native application instance is sufficiently instantiated to be subject to a crawling operation, a load signal indicating the native application instance is sufficiently instantiated to be subject to the crawling operation.

BACKGROUND

The Internet provides access to a wide variety of information. For example, digital image files, video and/or audio files, as well as web page resources for particular subjects or particular news articles, are accessible over the Internet. With respect to web page resources, many of these resources are designed to facilitate the performing of particular functions, such as banking, booking hotel reservations, shopping, etc., or to provide structured information, such as on-line encyclopedias, movie databases, etc.

Furthermore, with the advent of tablet computers and smart phones, native applications that facilitate the performance of the same functions facilitated by the use of web page resources are now being provided in large numbers. Additionally, native applications that do not have websites with synchronous content, such as games, are also very popular on tablet computers and smart phones. Accordingly, search systems now also facilitate searching of these native applications.

One process by which search systems gather information for native applications is by accessing “deep links” for the native applications. A deep link is an instruction specifying a particular environment instance of a native application and configured to cause the native application to instantiate the environment instance of the specified native application when selected at a user device. The native application generates the environment instance for display within the native application on a user device.

Once the native application is instantiated, the search system may crawl and index the content provided in the environmental instance. The native application, however, should be fully instantiated before the crawling and indexing operation beings, otherwise some information may not be indexed.

SUMMARY

This specification describes technologies relating to monitoring application loading to determine when an application is sufficiently instantiated to be subject to a crawling operation.

In general, one innovative aspect of the subject matter described in this specification include the actions of instantiating a native application instance that generates environment instances for display on a user device within the native application instance; in response to the instantiation of the native application instance: monitoring for occurrences of activity lifecycle events of the native application instance, monitoring for changes in a memory footprint of the native application instance, and generating, in response to the monitoring of the lifecycle events and monitoring of the changes in the memory footprint indicating the native application instance is sufficiently instantiated to be subject to a crawling operation, a load signal indicating the native application instance is sufficiently instantiated to be subject to the crawling operation. Other embodiments of this aspect include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.

Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. By monitoring subsets of the requests, activity lifecycle events, and memory footprint the system does not need to rely on a fixed timeout and thus makes better use of resources than other systems that use and require fixed timeouts to initiate a crawling operation. This results in a more efficient utilization of system resources, as time is not wasted for timeouts that are too long, and fewer re-crawls of native applications due to incomplete loads are required. Further, the monitoring of subsets of the requests, activity lifecycle events, and memory footprint decreases the likelihood that the crawling and indexing operation will fail or omit information from the crawling and indexing operations. The method also automatically adjusts to each particular application, and need not be individually tuned or otherwise require application-specific parameters. This provides the additional benefit of not requiring system tuning by administrations, which further reduces system maintenance costs.

DETAILED DESCRIPTION

A system receives a set of deep links for a native application and, for each deep link, instantiates the native application in preparation for crawling and indexing content provided by the native application in response to the deep link. As used herein, a native application generates environment instances for display on a user device within an environment of the native application, and operates independent of a browser application on the user device. A native application is an application specifically designed to run on a particular user device operating system and machine firmware. Native applications thus differ from browser-based applications and browser-rendered resources. The latter require all, or at least some, elements or instructions downloaded from a web server each time they are instantiated or rendered. Furthermore, browser-based applications and browser-rendered resources can be processed by all web-capable mobile devices within the browser and thus are not operating system specific.

A deep link is an instruction specifying a particular environment instance of a native application and configured to cause the native application to instantiate the environment instance of the specified native application when selected at a user device. The native application generates the environment instance for display within the native application on a user device. For example, a deep link may specify a selection menu for a game environment; or content from a website, such as a news site, forum, and the like; or a particular recipe for a cooking application; and the like.

To properly crawl and index native application content, the system must determine when the native application is sufficiently instantiated, e.g., finished loading and displaying the content that should be crawled for the deep link. Applications, however, may go through many states: fetching some content, processing the content, showing intermediate results before displaying final results, etc.

The system and methods in this specification perform an automatic and application-independent way of determining when an application is sufficiently instantiated for a crawling and indexing operation. In an implementation, the system, in response to the instantiation of the native application instance, monitors for occurrences of activity lifecycle events of the native application instance and monitors for changes in a memory footprint of the native application instance. When the monitoring indicates that the native application is sufficiently instantiated to be subject to the crawling operation, the system generates a load signal. The load signal causes a crawling system to crawl and index the content of the native application instance.

In some implementations, the load signal is generated based on monitoring a lack of a new activity lifecycle event and monitoring a steady memory footprint. Monitoring of additional load factors can also be considered, such as whether there are outstanding content requests. In some implementations, each monitored load factor must have a constituent load signal generated before the load signal for the native application is generated. In other implementations, the constituent load signals may serve as votes, and the load signal for the native application is generated when a majority of constituent load signals is generated. In still other implementations, any given constituent load signal may be dependent on another constituent load signal, e.g., a constituent load signal for the memory footprint may not be generated until a constituent load signal for the activity lifecycle events is generated, or vice-versa.

These features and additional features are described in more detail below.

FIG. 1is a block diagram of an example environment100in which native applications are indexed in response to determining the native applications are sufficiently instantiated.

A computer network102, such as the Internet, connects resource publisher web sites104, application publishers106, user devices108and a search system110.

A resource publisher website104includes one or more web resources105associated with a domain and hosted by one or more servers in one or more locations. Generally, a resource publisher website is a collection of web pages formatted in hypertext markup language (HTML) that can contain text, images, multimedia content, and programming elements. Each website104is maintained by a content publisher, which is an entity that controls, manages and/or owns the website104.

A web page resource is any data that can be provided by a publisher website104over the network102and that has a resource address, e.g., a uniform resource locator (URL). Web resources may be HTML pages, images files, video files, audio files, and feed sources, to name just a few. The resources may include embedded information, e.g., meta information and hyperlinks, and/or embedded instructions, e.g., client-side scripts.

An application publisher website106may also include one or more web resources105, and also provides native applications107. As described above, a native application107is an application specifically designed to run on a particular user device operating system and machine firmware. As used in this specification, an “environment instance” is a display environment within a native application and in which is displayed content, such as text, images, and the like. An environment instance is specific to the particular native application, and the native application is specific to the particular operating system of the user device108. An environment instance differs from a rendered web resource in that the environment instance is generated within and specific to the native application, while a web resource may be rendered in any browser for which the web page resource is compatible, and is independent of the operating system of the user device.

A user device108is an electronic device that is under the control of a user. A user device108is typically capable of requesting and receiving web page resources105and native applications107over the network102. Example user devices108include personal computers, mobile communication devices, and tablet computers.

To search web resources105and the native applications107, the search system110accesses a web index112and an application index114. The web index112is an index of web resources105that has, for example, been built from crawling the publisher web sites104. The application index114is an index of environment instances for native applications107, and is constructed using an indexer114that receives data crawled from an application instance122of a native application. Although shown as separate indexes, the web index112and the application index114can be combined in a single index.

The user devices108submit search queries to the search system110. In response to each query, the search system110accesses the web index112and the application index114to respectively identify resources and applications that are relevant to the query. The search system110may, for example, identify the resources and applications in the form of web resource search results and native application search results, respectively. Once generated, the search results are provided to the user device108from which the query was received.

A web resource search result is data generated by the search system110that identifies a web resource and provides information that satisfies a particular search query. A web resource search result for a resource can include a web page title, a snippet of text extracted from the resource, and a resource locator for the resource, e.g., the URL of a web page. A native application search result specifies a native application and is generated in response to a search of the application index114of environment instances. A native application search results includes a “deep link” specifying a particular environment instance of the native application and which is configured to cause the native application to instantiate the specified environmental instance. For example, selection of a native application search result may cause the native application to launch (if installed on the user device108) and generate an environment instance referenced in the application search result in the form of a screen shot.

As described above, publishers106that provide native applications107also provide deep links to the search system110. Furthermore, third parties may also provide deep links for native applications. Additionally, the search system110can discover deep links from other multiple sources, such as app maps, web page annotations, etc., and thus the set of deep links may be constantly changing. For example, an application publisher may provide a list of deep links109in the form of uniform resource identifiers (URIs) (or other instruction types that are specific to the native application published by the publisher). These deep links are deep links that publisher106desires to be crawled and indexed in the application index114.

In some implementations, to crawl and index the native applications107, the search system110, or a system associated with the search system110, uses an operating system emulator120that emulates an operating system on which native applications107are executed. The operating system emulator120instantiates an instance122of a native application for each deep link109. During instantiation, a load detector130receives data from a request monitor124, an activity monitor125, and a memory monitor126, and, using the received data, determines whether the native application instance122is sufficiently instantiated for a crawling and indexing operation. When the load detector determines the native application instance122is sufficiently instantiated for the crawling and indexing operation, the load detector130generates a load signal. A data extractor128receives the load signal, and in response crawls the content of the native application instance122. The crawled content is provided to the indexer140, which then indexes the content of the native application in the application index114.

While the examples below are described in the context of an emulator120, other devices and environments can be used for monitoring the status of an application. For example, a virtual machine or even an instrumented mobile device can be used.

Generation of the load signal is described in more detail with reference toFIG. 2, which is a flow diagram of an example process200for determining whether an application is loaded. The process200can be implemented in a data processing apparatus, such as one or more computers in data communication.

The process200instantiates an instance of a native application (202). For example, the OS emulator120selects a deep link109to instantiate a native application. The OS emulator120is configured to instrument the instance122of the native application so that the request monitor124, activity monitor125, and memory monitor126can monitor the status of requests, activities, and memory related to the instantiation of the native application, respectively. Each of the request monitor124, activity monitor125, and memory monitor126may include a process that is loaded in the same application process space or loaded entirely separate from the application instance122.

The process200monitors constituent load signal sources, which in the current implementation may include requests for content sent from the native application instance to serving entities that are external to the native application instance, activity lifecycle of the native application instance, and the memory footprint of the native application instance (204). In the current implementation, the constituent load signals are not required to be monitored in a particular or defined order, and the constituent load signals may be monitored simultaneously. In other implementations, the monitoring of constituent load signals may be dependent on each other, e.g., activity lifecycle events are monitored until a constitute activity lifecycle load signal is generated, and then the memory footprint of the native application is monitored.

In some implementations, the constituent load signal sources are not monitored until a launch timeout has occurred. For example, after instantiation of the instance of the native application, a launch timeout may occur prior to monitoring the crawling operation parameters.

The request monitor124may monitor requests for content sent from the native application instance to serving entities that are external to the native application instance (204a). For example, the request monitor124may be configured to act as a proxy that intercepts requests, logs the requests, and then sends the requests to the external services. The time the request was sent is monitored by the request monitor124and the content received in response to the request is also monitored. When content is received in response to a request, the request monitor124provides the content to the application instance122. In some implementations, a determination may be made as to whether each monitored request is fulfilled. For each request, the request monitor124determines, for example, whether content has been received for the request. If content has been received for a request, the request monitor124may determine whether the content is responsive to the request. Additionally, the request monitor124may also determine if a request has timed out, e.g., a response has not been received within a predefined timeout period.FIG. 3below describes in more detail an example process300of determining whether a request is fulfilled.

When the request monitor124determines, based on the monitoring requests for content, that the native application instance is sufficiently instantiated to be subject to the crawling operation, it generates a request load signal. The request load signal is a constituent indication that the native application is sufficiently loaded to be crawled.

The activity monitor125may monitor activity lifecycle events of the native application instance (204b). An activity lifecycle event is an event that describes a transition between different states in an application lifecycle. For example, during a splash screen, an application may be in a first lifecycle event, and then the transition from the splash screen to a main menu may be indicated by a second lifecycle event. The two events that occur in sequence may be the same, or may be different.

The OS emulator120implementing the application instance122may be instrumented to monitor the lifecycle events and determine an activity lifecycle event state of the native application. For example, states of an activity may be running, paused, background, or stopped, among others. Operations performed by the native application may result in change of an activity lifecycle state. Example activity lifecycle events include OnCreate( ), OnStart ( ), OnResume ( ), OnPause ( ), OnStop ( ), OnRestart ( ), and OnDestroy ( ), among others. The activity lifecycle, in some implementations, may be the collection of methods called by the OS emulator120for each activity of the application instance122, and an activity lifecycle event may occur when a method is called by the OS emulator120for an activity of the application instance122.

In some implementations, the activity monitor125may monitor, e.g., by intercepting, the OS emulator120calls to the activities of the application instance122in order to determine if an activity lifecycle event has occurred for an activity of the application instance122. In some implementations, the monitoring of the activity lifecycle may be performed by sandboxing, or otherwise isolating, the application instance122.FIG. 4below describes in more detail an example process400of determining whether an activity lifecycle of the native application indicates sufficient instantiation.

When the activity monitor125determines, based on monitored activity lifecycle events, that the native application instance is sufficiently instantiated to be subject to the crawling operation, it generates an activity lifecycle load signal. The activity lifecycle load signal is a constituent indication that the native application is sufficiently loaded to be crawled.

The memory monitor126may monitor the operation parameter of the memory footprint of the native application instance (204c). For example, the memory monitor126may monitor the memory footprint or amount of memory the application instance122is consuming. During operation of the application instance122, memory of the OS emulator120will be consumed by the application instance122, and when the application instance122is launched, the amount of memory consumed by the application instance122will increase. In some implementations, after launching the application instance122, a steady memory footprint of the application instance122may be reached. The memory footprint of the application instance122may be determined by the memory monitor126continuously or at different points in time, which may be at regular intervals, irregular intervals, or at different transition points of the application. For example, the memory monitor126may determine the memory footprint of the application instance122when the application instance122is launched, and then determine the memory footprint when a new application instance122activity is initiated.FIG. 5below describes in more detail an example process500of determining whether a memory footprint of the native application indicates sufficient instantiation.

When the memory monitor126determines, based on monitored memory footprint values, that the native application instance is sufficiently instantiated to be subject to the crawling operation, it generates a memory footprint load signal. The memory footprint load signal is a constituent indication that the native application is sufficiently loaded to be crawled.

Based on monitoring the constituent load signal sources and any resulting constituent load signals that are generated, the system determines whether to generate a load signal (206). For example, the load detector130may receive the data from the request monitor124, the activity monitor125, and the memory monitor126, and, using the received data, determine if the native application instance122is sufficiently instantiated for a crawling and indexing operation.

In some implementations, each monitored load factor must have a constituent load signal generated before the load signal for the native application is generated, e.g., the load signal is logical AND of the constituent load signals. In other implementations, the constituent load signals are tallied as votes by the load detector130, and the load signal for the native application is generated when a majority of constituent load signals is generated.

In still other implementations, any given constituent load signal may be dependent on another constituent load signal, e.g., a constituent load signal for the memory footprint may not be generated until a constituent load signal for the activity lifecycle events is generated, or vice-versa.

Other appropriate ways of processing the constitute load signals to determine whether to generate the load signal can also be used.

When the load detector determines the native application instance122is sufficiently instantiated for the crawling and indexing operation, the load detector130generates the load signal (208), and in response the data extractor128receives the load signal and crawls the content of the native application instance122. The indexer140then indexes the crawled data. Otherwise, if the process200determines, based on monitoring the constituent load signal sources, that the application instance122is not sufficiently instantiated to be subject to the crawling process, then the process200returns to monitoring the constituent load signal sources (204).

FIG. 3is a flow diagram of an example process300for determining whether requests have been fulfilled. The process300monitors requests (302). For example, as described above, the request monitor124monitors for content to be returned for requests.

The process300determines whether content is returned for the requests (304). If content is returned for each of the requests, then the process may determine that the requests are fulfilled and generates a constituent request load signal (306), depending on the content returned. For example, in some implementations, a request is deemed fulfilled only if the content received is responsive to the request, and does not indicate an incomplete response or an error. An error may be a notification that an address to which the request was sent is unresolvable or a requested resource no longer exits. In some implementations, the failure of the request being fulfilled will preclude crawling and indexing of the native application instance122. Such a result may be desirable to ensure that the search system110provides search results for only deep links for which content is available.

In other implementations, a request is deemed fulfilled even if the content received indicates an incomplete response or an error. This can occur when it is desired to index a native application using “best efforts.” Thus, even if all the requested content is not available, at least the content received will be crawled and indexed.

If the process300determines content is not returned for all the request, then the process300determines if timeouts for the remaining requests have occurred (308). This stage may be optional, and can be implemented when it is desired to index a native application using best efforts as described above. The request timeout can be a time period that is selected so that at the expiration of the time period the request is likely to have been fulfilled but for an error. The time can be selected based on historical observations, or can be a fixed time period, e.g., five seconds. The time period is measured from the time the request handler124sent the request.

If the process300determines the request timeouts have occurred, then the process300determines the request is fulfilled and generates a constituent request load signal (306). Otherwise, the process300determines the request is not fulfilled and continues to monitor requests.

FIG. 4is a flow diagram of an example process400for determining whether activity lifecycle events of the native application indicates sufficient instantiation. As previously described, the activity monitor125may monitor the activity lifecycle of the native application instance (402). The activity monitor125may monitor (e.g., intercept) the OS emulator120calls to the activities of the application instance122in order to determine if an activity lifecycle event has occurred for an activity of the application instance122.

The activity monitor125determines whether a lifecycle event has occurred within a time period (404). If it is determined there has been a new activity lifecycle event in the period of time, then the activity monitor125resets the time period and monitors the activity lifecycle events, returning to step402. The activity lifecycle timeout may be a same or different time compared to a launch timeout, a timeout request, or any timeout associated with the memory monitor126. The time period of the activity lifecycle timeout may be a time that is determined to be sufficient for the application instance122to instantiate, and may be set by system administrators or learned by a machine learning system.

When there is not an activity lifecycle event within the activity lifecycle timeout (406), the activity monitor125generates a constituent activity lifecycle load signal (406). The load detector130may then use this information, along with other constituent load signals, to determine if the application instance122has sufficient instantiation for the crawling operation.

FIG. 5is a flow diagram of an example process500for determining whether a memory footprint of the native application indicates sufficient instantiation. In the process500, the memory footprint of the application instance122may be determined at a first time (502). The memory monitor126may monitor the memory footprint or amount of memory the application instance122is consuming. As previously described, during operation of the application instance122, memory of the OS emulator120will be consumed by the application instance122, and when the application instance122is launched, the amount of memory consumed by the application instance122will increase. In some implementations, after launching the application instance122, a steady memory footprint of the application instance122may occur after the application is fully loaded. The memory footprint may be the application instance's122memory footprint, which may be the amount of main memory of the user device108the application instance122is using or referencing at a particular time. In some implementations, the application instance's122memory footprint may be determined from a heap size associated with the native application.

The first time for determining the memory footprint of the application instance122may be at the time the application is launched. However, there can also be a memory footprint timeout after the application instance122is launched before the first memory footprint is obtained. The timeout may be a same or different time compared to the timeouts previously described. Alternatively, the first memory footprint may be obtained when the constituent activity lifecycle load signal is generated.

The memory footprint of the application instance122is determined at a second time (504). From the first time, the second time may be a regular interval (e.g., 50 milliseconds), an irregular interval (e.g., a range between two seconds and ten seconds), or after some other native application event.

The process500determines whether the memory footprint at the second time is greater than the memory footprint at the first time (506). When the application instance122is launched, the amount of memory consumed by the application instance122will increase, and after launching of the application instance122is complete, a steady, unchanging memory footprint of the application instance122may be reached. If the memory footprint at the second time is not greater than the memory footprint at the first time (508), then there is an indication, based on the memory footprint determined by the memory monitor126, that the application instance122has reached a point of sufficient instantiation for the crawling operation. The memory monitor then generates the constituent memory footprint load signal (508).

However, if the memory footprint at the second time is greater than the memory footprint at the first time, then process500may return to step502. Alternatively, the process500, after the first determination that the memory footprint at the second time is greater than the memory footprint at the first time, may instead return to step504to compare a current footprint value collected at another iteration of step504to a prior footprint value collected at a prior iteration of step504. As previously described, if the memory footprint is greater at the second time than the first time (or greater at current time than at a prior time), then there is an indication that the application instance122has not reached a point of sufficient instantiation for the crawling operation to take place.