Abstract:
The subject disclosure is directed towards a technology in which a mobile device maintains an application in a dormant state in which the application&#39;s process is not terminated and remains in memory, but the application cannot execute code. Further, state and execution context are maintained for the application, allowing the application to be quickly and efficiently resumed into the running state. To prevent the application from executing code while dormant, thread activity is suspended, requests canceled, completed or paused, resources detached, and so forth. Resource usage may be monitored for dormant applications, to remove a misbehaving dormant application process from memory if improperly using resources.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    The present application claims priority to U.S. provisional patent applications Ser. Nos. 61/442,701, 61/442,713, 61/442,735, 61/442,740 and 61/442,753, each filed Feb. 14, 2011 and hereby incorporated by reference. The present application is related to U.S. patent applications attorney docket nos. 332296.02, 332297.02, 332339.02 and 332340.02, assigned to the assignee of the present invention, and hereby incorporated by reference. 
     
    
     BACKGROUND 
       [0002]    On a contemporary mobile device, if an application is running and is subsequently replaced in the foreground by another application or experience, the first application is deactivated and the application&#39;s process is terminated by the operating system. An application may be deactivated if the user presses the Start button or if the device timeout causes the lock screen to be engaged, for example. 
         [0003]    In one system, the user may return to the application to continue an application task/experience from where the user left it. However, when returning to an application that was terminated by the operating system, the user needs to wait for the device application framework to initialize, and for the application itself to load saved state and to resume the previous experience. Resuming in this way can seem relatively slow and thus provide a somewhat undesirable user experience. 
       SUMMARY 
       [0004]    This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter. 
         [0005]    Briefly, various aspects of the subject matter described herein are directed towards a technology by which an application is moved from a running (e.g., foreground) state into a dormant state in which the application process is retained in memory. Further, state data and execution context information are maintained in association with the application, which allows the application to be activated to the running state, e.g., in a rapid, efficient manner. In one aspect, moving the application from the running state into the dormant state includes pausing for a time duration to allow the application to prepare for the dormant state, e.g., persist data from memory, close any open files, and so forth. 
         [0006]    In one aspect, moving the foreground application from a running state into the dormant state includes detaching at least one resource from the application, pausing at least one update notification provided by a resource to the application, canceling at least one cancellable request, pausing at least one non-cancellable request, stopping at least one thread, and/or freeing at least one application resource (e.g., memory allocated to the application). 
         [0007]    To activate the application back from the dormant state to a foreground application in the running state, the state data and the execution context information is accessed, and at least one resource is attached to the application. Also described is resuming at least one update notification provided by a resource to the application, running a failure path for at least one cancellable request, resuming at least one non-cancellable request, firing at least one notification, recreating an resuming at least one thread, and/or recreating at least one application resource. 
         [0008]    In one aspect, a resource monitor is configured to evaluate whether the application, when in the dormant state, is using at least one resource (e.g., CPU) beyond an allowed threshold. If so, the shell is configured to move the application from the dormant state into another state in which the process of the application is not retained in memory. 
         [0009]    Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which: 
           [0011]      FIG. 1  is a block diagram representing example applications in different states hosted by an operating system shell, including applications in a dormant state. 
           [0012]      FIG. 2  is state diagram showing example states for applications, including a dormant state, and transitions between the states. 
           [0013]      FIG. 3A  is a sequence/control diagram representing an example flow of events/control among components when launching an application. 
           [0014]      FIG. 3B  is a sequence/control diagram representing an example flow of events/control among components when deactivating an application. 
           [0015]      FIG. 4A  is a sequence/control diagram representing an example flow of events/control among components when resuming a deactivated application from a dormant state. 
           [0016]      FIG. 4B  is a sequence/control diagram representing an example flow of events/control among components when closing an application. 
           [0017]      FIG. 5  is a block diagram representing an exemplary non-limiting computing system or operating environment, e.g., in the example of a mobile phone device, in which one or more aspects of various embodiments described herein can be implemented. 
       
    
    
     DETAILED DESCRIPTION 
       [0018]    Various aspects of the technology described herein are generally directed towards a technology in which a mobile device or the like maintains an application in a dormant state, generally corresponding to an application that cannot execute any code when in the background. To this end, the shell component/framework that comprises the (e.g., Windows® phone) application platform retains the application process in memory, and maintains state and execution context for the application, but does not allow the process to run. For example, the shell may suspend thread activity within background applications. The dormant background application regains the ability to execute code when the user brings the application to foreground. 
         [0019]    In one implementation, the operating system does not terminate the application&#39;s process when deactivating an application. Instead, applications may go in the background and remain resident in memory. This eliminates the need to reinitialize the application and reload state, which implicitly means faster application resume time. 
         [0020]    It should be understood that any of the examples herein are non-limiting. For one, example implementations and dormant applications are described in the context of a Windows® mobile device operating environment, however this is only for purposes of explanation, and other operating environments may benefit from the concept of a dormant application state as described herein. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing and application/task switching in general. 
         [0021]      FIG. 1  is a generalized block diagram showing various example components in a mobile device environment. A plurality of applications are controlled by a shell  102  (application framework), which provides access to device resources, including exclusive resources  104  (e.g., the display) that only one application, usually only the foreground application  106 , typically can access, and shared resources  108  (e.g., memory, networking and so forth) that the foreground application  106  and other applications may use. 
         [0022]    As exemplified in  FIG. 1 , one or more applications are tombstoned applications  110   1 - 110   m . More particularly, in conventional mobile devices, applications are terminated shortly after they are no longer the foreground application. In previous devices, the application remained terminated (e.g., block  112 ) and had to be fully re-launched as a new instance. In some more contemporary mobile devices, if the UX (user experience, including user interface components) provides mechanisms for the user to navigate back to application instances, each application instead may be tombstoned in contrast to terminated, meaning that the application is given a chance to save state, after which the process is torn down and a marker of its prior existence is kept on an application stack. 
         [0023]    The technology described herein is directed towards maintaining one or more applications as dormant applications  114   1 - 114   n , in which a dormant application (e.g., its process) is retained as resident in memory, in conjunction with maintaining the application&#39;s associated state and execution context. This allows a dormant application to be more rapidly activated (relative to tombstoned applications) to the foreground running state. 
         [0024]      FIG. 2  is a state diagram showing example states of an application once the user launches the application (block  222 ) and the application enters the running state  224 . In this example, the application remains in the running state  224  until the user takes a user interaction, navigation-related action, namely a backward navigation action (block  226 , e.g., back past the application in the stack, or a close the application action), which in response closes the application, or a forward navigation action (block  228 ), such as pressing the Start button, which deactivates the application. 
         [0025]    When deactivated, the shell/framework notifies the application and pauses for a duration (e.g., for up to ten seconds) to give the application time to prepare for becoming a dormant application. For example, the application is given time to persist memory, close any open files, and so forth. 
         [0026]    Pausing is represented in  FIG. 2  by the pausing state  230 , which when pausing completes (block  234 ) enters the dormant state  236 . In the event the user returns to the application (activated, block  240 ) before the full pause time is reached, the application returns to the running state  224 . 
         [0027]    The shell  102  detects when an application is deactivated, and moves it into the dormant state  236 . When detected, the shell  102  performs certain operations to ensure that the dormant application is not able to interfere with the new foreground application. For example, the shell  102  cancels any cancellable requests, may block API utilization, releases exclusive hardware resources attached to the deactivated application, and suspends threads created by the application or on behalf of the application. The shell suspends the application&#39;s thread activity and prevents the background application from consuming CPU cycles. By doing so, dormant background applications act as if the process was terminated by the operating system and do not continue using the device&#39;s battery or slow down the device foreground activity. 
         [0028]    Note that for performance/perceived performance, some of these operations may be in parallel with preparing the new foreground application. For example, the shell may give the new application the display resource during the pause time so that the user does not have to wait the full ten seconds to perceive the change to the new foreground application. The foreground application may not be given the camera resource right away, e.g., in case the user inadvertently pressed the Start button, for example, and wants to return to the application that was running. 
         [0029]    The shell detaches resources from deactivated applications. Examples of such resources include the vibration controller, sound and media player, photo/video camera, location services, sensors, networking and so forth. By doing so, in the dormant state  236 , dormant background applications act as if the process was terminated by the operating system and does not continue using device resources or prevent the application in the foreground from using these resources. 
         [0030]    The shell may release memory resources from dormant background applications to minimize the memory footprint in the operating system. The smaller the application memory footprint, the greater the number of dormant background applications that are able to reside in memory, and thus be quickly resumed. 
         [0031]    The shell  102 , e.g., via a resource monitor component  120  ( FIG. 1 , incorporated therein or coupled thereto) also may monitor usage of at least one resource (e.g., CPU usage) by the dormant application. More particularly, a general goal is that a dormant application performs no significant activity, including that no code runs; however some code (e.g., first party native applications) may continue to run code. Thus, after the ten second duration to allow preparation for becoming dormant, the shell may enforce resource non-usage. To this end, periodically (e.g., every five minutes) or according to some other event, each dormant application&#39;s CPU usage is checked. If still dormant and there is some CPU usage, (e.g., CPU usage&gt;0 or some other allowed threshold), the dormant application is moved to the tombstoned state  238  ( FIG. 2 ). This may checked regardless of other state (e.g., not just when the device/phone is idle). Further, a progressive tightening policy may be used, e.g., the threshold may be non-zero and decrease over time. 
         [0032]    If necessary, such as when the operating system reaches out-of-memory conditions, the shell may terminate the processes of dormant background applications, e.g., by tombstoning or fully terminating by not maintaining state/a marker. This frees up memory resources (and any other shared resources) for the application in the foreground. 
         [0033]    To summarize, when paused, the system shell operates to detach exclusive use resources from underneath the application, and detach shared use resources from underneath the application. The shell pauses update notifications provided by a resource to the application. For cancellable requests that are pending, the shell cancels them; any non-cancellable requests are paused or given a completion notification. In process (in-proc) native threads created on behalf of the application are stopped, and if possible, any out of process (out-of-proc) native threads created on behalf of the application are stopped. Any application resources that can be easily and quickly recreated are freed. 
         [0034]    Turning to activating/resuming the application from the dormant state, upon application activation, the framework resumes the application threads and runs the normal failure paths for cancelled requests, and attaches resources on behalf of the application. More particularly, when resuming, the system shell operates to reattach exclusive use resources and restore their state. If possible, shared use resources are reattached and their state restored. Update notifications provided by a resource to the application are resumed. For cancellable requests that were cancelled, the normal failure path in the application is run. Any non-cancellable requests are resumed, and any pending completion notifications are fired. The shell recreates/resumes any in-proc native threads created on behalf of the application, and any out-of-proc native threads created on behalf of the application as needed. Freed resources are also recreated as needed. 
         [0035]      FIGS. 3A-4B  are sequence diagrams directed towards a Windows® mobile device environment, generally showing how events trigger various components to participate in deactivating an application to the dormant state, and activating an application from the dormant state.  FIG. 3A  illustrates example combined control flows for a forward navigation scenario where an application is launching while an application (previously in the foreground) is deactivated ( FIG. 3B ).  FIGS. 4A and 4B  are sequence diagrams illustrating example combined control flows for resuming an activated application ( FIG. 4A ), and closing an application ( FIG. 4B ). 
         [0036]    In  FIGS. 3A-4B , the shell  102  comprises a server that hosts one or more client processes, e.g., the taskhost.exe  330  for each application. To start a launched task ( FIG. 3A ), a shell execution manager  331  communicates with a client execution manager  332 , which in turn signals a task host component  334 . In  FIGS. 3A-4D , the task host component  334  communicates with a frame component  336  that handle pages exposed by application navigation, e.g., puts previous pages on a stack for navigation, manages buffers (including using an internal splash application to allocate image buffers) and so forth. As the user interacts via pages, the frame component generates events. The SLM/XNA and CLR components  338  and  340  refer to Silverlight®-based and common language runtimes, respectively, used in this example environment. The application code is represented via the app component  342 . 
       Exemplary Operating Environment 
       [0037]      FIG. 5  illustrates an example of a suitable mobile device  500  on which aspects of the subject matter described herein may be implemented. The mobile device  500  is only one example of a device and is not intended to suggest any limitation as to the scope of use or functionality of aspects of the subject matter described herein. Neither should the mobile device  500  be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary mobile device  500 . 
         [0038]    With reference to  FIG. 5 , an exemplary device for implementing aspects of the subject matter described herein includes a mobile device  500 . In some embodiments, the mobile device  500  comprises a cell phone, a handheld device that allows voice communications with others, some other voice communications device, or the like. In these embodiments, the mobile device  500  may be equipped with a camera for taking pictures, although this may not be required in other embodiments. In other embodiments, the mobile device  500  may comprise a personal digital assistant (PDA), hand-held gaming device, notebook computer, printer, appliance including a set-top, media center, or other appliance, other mobile devices, or the like. In yet other embodiments, the mobile device  500  may comprise devices that are generally considered non-mobile such as personal computers, servers, or the like. 
         [0039]    Components of the mobile device  500  may include, but are not limited to, a processing unit  505 , system memory  510 , and a bus  515  that couples various system components including the system memory  510  to the processing unit  505 . The bus  515  may include any of several types of bus structures including a memory bus, memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures, and the like. The bus  515  allows data to be transmitted between various components of the mobile device  500 . 
         [0040]    The mobile device  500  may include a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the mobile device  500  and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the mobile device  500 . 
         [0041]    Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, Bluetooth®, Wireless USB, infrared, WiFi, WiMAX, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media. 
         [0042]    The system memory  510  includes computer storage media in the form of volatile and/or nonvolatile memory and may include read only memory (ROM) and random access memory (RAM). On a mobile device such as a cell phone, operating system code  520  is sometimes included in ROM although, in other embodiments, this is not required. Similarly, application programs  525  are often placed in RAM although again, in other embodiments, application programs may be placed in ROM or in other computer-readable memory. The heap  530  provides memory for state associated with the operating system  520  and the application programs  525 . For example, the operating system  520  and application programs  525  may store variables and data structures in the heap  530  during their operations. 
         [0043]    The mobile device  500  may also include other removable/non-removable, volatile/nonvolatile memory. By way of example,  FIG. 5  illustrates a flash card  535 , a hard disk drive  536 , and a memory stick  537 . The hard disk drive  536  may be miniaturized to fit in a memory slot, for example. The mobile device  500  may interface with these types of non-volatile removable memory via a removable memory interface  531 , or may be connected via a universal serial bus (USB), IEEE 5394, one or more of the wired port(s)  540 , or antenna(s)  565 . In these embodiments, the removable memory devices  535 - 537  may interface with the mobile device via the communications module(s)  532 . In some embodiments, not all of these types of memory may be included on a single mobile device. In other embodiments, one or more of these and other types of removable memory may be included on a single mobile device. 
         [0044]    In some embodiments, the hard disk drive  536  may be connected in such a way as to be more permanently attached to the mobile device  500 . For example, the hard disk drive  536  may be connected to an interface such as parallel advanced technology attachment (PATA), serial advanced technology attachment (SATA) or otherwise, which may be connected to the bus  515 . In such embodiments, removing the hard drive may involve removing a cover of the mobile device  500  and removing screws or other fasteners that connect the hard drive  536  to support structures within the mobile device  500 . 
         [0045]    The removable memory devices  535 - 537  and their associated computer storage media, discussed above and illustrated in  FIG. 5 , provide storage of computer-readable instructions, program modules, data structures, and other data for the mobile device  500 . For example, the removable memory device or devices  535 - 537  may store images taken by the mobile device  500 , voice recordings, contact information, programs, data for the programs and so forth. 
         [0046]    A user may enter commands and information into the mobile device  500  through input devices such as a key pad  541  and the microphone  542 . In some embodiments, the display  543  may be touch-sensitive screen and may allow a user to enter commands and information thereon. The key pad  541  and display  543  may be connected to the processing unit  505  through a user input interface  550  that is coupled to the bus  515 , but may also be connected by other interface and bus structures, such as the communications module(s)  532  and wired port(s)  540 . Motion detection  552  can be used to determine gestures made with the device  500 . 
         [0047]    A user may communicate with other users via speaking into the microphone  542  and via text messages that are entered on the key pad  541  or a touch sensitive display  543 , for example. The audio unit  555  may provide electrical signals to drive the speaker  544  as well as receive and digitize audio signals received from the microphone  542 . 
         [0048]    The mobile device  500  may include a video unit  560  that provides signals to drive a camera  561 . The video unit  560  may also receive images obtained by the camera  561  and provide these images to the processing unit  505  and/or memory included on the mobile device  500 . The images obtained by the camera  561  may comprise video, one or more images that do not form a video, or some combination thereof. 
         [0049]    The communication module(s)  532  may provide signals to and receive signals from one or more antenna(s)  565 . One of the antenna(s)  565  may transmit and receive messages for a cell phone network. Another antenna may transmit and receive Bluetooth® messages. Yet another antenna (or a shared antenna) may transmit and receive network messages via a wireless Ethernet network standard. 
         [0050]    Still further, an antenna provides location-based information, e.g., GPS signals to a GPS interface and mechanism  572 . In turn, the GPS mechanism  572  makes available the corresponding GPS data (e.g., time and coordinates) for processing. 
         [0051]    In some embodiments, a single antenna may be used to transmit and/or receive messages for more than one type of network. For example, a single antenna may transmit and receive voice and packet messages. 
         [0052]    When operated in a networked environment, the mobile device  500  may connect to one or more remote devices. The remote devices may include a personal computer, a server, a router, a network PC, a cell phone, a media playback device, a peer device or other common network node, and typically includes many or all of the elements described above relative to the mobile device  500 . 
         [0053]    Aspects of the subject matter described herein are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with aspects of the subject matter described herein include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microcontroller-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. 
         [0054]    Aspects of the subject matter described herein may be described in the general context of computer-executable instructions, such as program modules, being executed by a mobile device. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. Aspects of the subject matter described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices. 
         [0055]    Furthermore, although the term server may be used herein, it will be recognized that this term may also encompass a client, a set of one or more processes distributed on one or more computers, one or more stand-alone storage devices, a set of one or more other devices, a combination of one or more of the above, and the like. 
       Conclusion 
       [0056]    While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.