CN115136564A - 用户设备中应用和应用内的内容的预加载 - Google Patents

Abstract

一种方法包括，在运行操作系统(OS‑48)的用户设备(24)中，决定预加载用户应用(26)的至少用户界面(UI)显示。以模拟前台模式预加载至少UI显示，在该模拟前台模式中，该UI显示(i)由用户应用以前台模式处理，但(ii)由OS保持在后台模式中并对用户设备的用户隐藏。

Description

用户设备中应用和应用内的内容的预加载

相关申请的交叉引用

本申请要求2020年2月13日提交的美国临时专利申请62/975,789号、2020年3月9日提交的美国临时专利申请62/986,807号、2020年8月16日提交的美国临时专利申请63/066,271号、2020年11月25日提交的美国临时专利申请63/118,068号和2020年12月21日提交的美国临时专利申请63/128,220号的权益，这些专利申请的公开内容通过引用并入本文。

发明领域

本发明总体上涉及通信系统，特别涉及用于在用户设备中预加载应用和内容的方法和系统。

发明背景

在用户设备(诸如智能手机)上运行的应用(“app”)中，影响用户体验的主要因素之一是用户界面(UI)的延迟。已经提出了用于减少延迟并提供更具响应性的UI的各种技术。一些技术涉及内容的预取(prefetch)。其他技术涉及app的后台预加载。另外的其他技术涉及app的UI的预渲染。例如，在标题为“An Optimized CDN for the Wireless LastMile”的PCT国际公布WO 2018/055506中描述了此类技术，该国际公布通过引用并入本文。

标题为“Application Preloading in the Presence of User Actions”的PCT国际公布WO 2019/171237描述了一种在用户设备的处理器中的方法，该PCT国际公布的公开内容通过引用并入本文。该方法包括以后台模式预加载一个或更多个用户应用。检测在处理器中被调用并与给定预加载的用户应用相关联的活动。处理器评估活动是否是由于给定用户应用的预加载而调用的预加载发起的活动，或者活动是否是由于用户的动作而调用的用户发起的活动。如果该活动被评估为预加载发起的活动，则使用第一处理方案处理该活动。如果该活动被评估为用户发起的活动，则使用不同于第一处理方案的第二处理方案来处理该活动。

发明概述

本文描述的本发明的实施例提供了一种方法，该方法包括在运行操作系统(OS)的用户设备中决定预加载用户应用的至少用户界面(UI)显示。以模拟前台模式预加载至少UI显示，其中(i)UI显示由用户应用以前台模式处理，但(ii)由OS以后台模式保持并对用户设备的用户隐藏。

在一些实施例中，该方法还包括由OS维护(i)用于存储非预加载的UI显示的一个或更多个第一数据结构和(ii)用于存储预加载的UI显示的一个或更多个第二数据结构，并且预加载UI显示包括最初将UI显示分配给第二数据结构中的一个，随后响应于满足标准，将UI显示重新分配给第一数据结构中的一个。

在实施例中，在决定UI显示的预加载成功完成时，或者在用户与用户应用交互时，执行UI显示到第一数据结构中的一个的重新分配。在示例实施例中，一个或更多个第一数据结构包括非预加载的UI显示的一个或更多个第一堆栈，并且一个或更多个第二数据结构包括预加载的UI显示的一个或更多个第二堆栈。在另一实施例中，一个或更多个第一数据结构包括与非预加载的UI显示相关联的目标显示，以及一个或更多个第二数据结构包括与预加载的UI显示相关联的一个或更多个虚拟显示。

在公开的实施例中，预加载UI显示包括应用为活动的前台处理指定的OS的生命周期事件(lifecycle event)。

在一些实施例中，该方法包括根据完成标准决定UI显示的预加载成功完成，以及作为响应，将UI显示转换到其中OS和用户应用都认为UI显示在后台中的预加载的后台状态。决定预加载成功完成可以包括检测为模拟前台模式设置的最大持续时间的到期。附加地或替代地，决定预加载成功完成可包括从用户应用接收预加载成功完成的通知。

在另一实施例中，该方法包括响应于检测到在模拟前台模式中发生的错误而丢弃预加载的UI显示。在又一实施例中，预加载至少UI显示包括防止预加载影响以下中的一个或更多个：(i)用户设备的最近列表、(ii)用户设备的使用度量和(iii)与进入省电状态有关的决策。

在实施例中，预加载至少UI显示包括经由应用编程接口(API)通知用户应用正在预加载至少UI显示。附加地或替代地，预加载至少UI显示可以包括经由应用编程接口(API)通知用户应用检测到用户与预加载的用户应用的交互。

在一些实施例中，预加载至少UI显示包括预加载从用户应用的入口点UI显示启动的用户应用的至少一部分。在示例实施例中，预加载用户应用包括根据用户应用的启动序列预加载入口点UI显示和一个或更多个附加UI显示。在另一实施例中，预加载用户应用包括仅在验证对给定UI显示的调用是预加载发起的而不是用户发起的时预加载给定UI显示。

在另一实施例中，预加载用户应用包括通过检测最大定义持续时间的到期来决定用户应用的预加载成功完成。在又一实施例中，预加载用户应用包括通过从用户应用接收预加载成功完成的通知来决定用户应用的预加载成功完成。在再一实施例中，预加载用户应用排除预加载以下内容中的一个或更多个：(i)以超过预定义速率的速率变化的内容，和(ii)其预加载需要通过网络获取的内容。

在一些实施例中，预加载至少UI显示包括预加载与用户应用相关联、但在启动用户应用时不立即显示的一个或更多个app内(in-app)的UI显示。在实施例中，当用户应用以前台模式运行时执行对app内的UI显示的预加载。在另一实施例中，当用户应用以后台模式运行时执行对app内的UI显示的预加载。

在一些实施例中，预加载app内的UI显示包括将预加载的app内的UI显示缓存在用户设备的存储器中，以及响应于来自用户应用的请求，提供来自存储器的预加载的app内的UI显示。在公开的实施例中，缓存app内的UI显示包括为每个app内的UI显示分配相应的到期时间，以及仅响应于验证到期时间尚未到期，提供来自存储器的app内的UI显示。

在一些实施例中，该方法包括维护管理UI显示的预加载的预加载策略。维护预加载策略可以包括在用户设备中运行维护预加载策略的系统app。在实施例中，维护预加载策略包括通过系统app和网络侧服务器之间的通信来设置预加载策略。

在一些实施例中，预加载至少UI显示包括用不同于用户设备的当前显示取向的目标取向预加载UI显示。在示例实施例中，目标取向是预测用户以其访问用户应用的取向。

在实施例中，预加载至少UI显示包括通过网络获取UI显示的内容，内容的质量高于用于内容的实时获取的质量。在另一实施例中，决定预加载至少UI显示包括从用户接收预加载用户应用的显式请求。在另一实施例中，该方法包括向用户呈现指示预加载至少UI显示的进度的信息。

根据本发明的实施例，另外提供了包括显示屏和处理器的用户设备。显示屏被配置成向用户显示用户应用的用户界面(UI)显示。处理器被配置成运行用户设备的操作系统(OS)，决定预加载用户应用的至少UI显示，并以模拟前台模式预加载至少UI显示，其中UI显示(i)由用户应用以前台模式处理，但(ii)由OS保持在后台模式中并对用户设备的用户隐藏。

根据结合附图进行的对本发明的实施例的以下详细描述，本发明将得到更充分的理解，附图中：

附图简述

图1是根据本发明的实施例示意性地示出采用预加载的通信系统的框图；

图2和图3是根据本发明的实施例示意性地示出用于处理预加载的和非预加载的活动的数据结构的图；

图4是根据本发明的实施例示意性地示出活动的预加载的状态图；以及

图5A和图5B是根据本发明的实施例分别示意性地示出前台加载活动和后台预加载的活动的生命周期状态的状态图。

具体实施方式

定义

本公开提及诸如应用(“app”)和诸如用户界面(UI)显示的app组件的预加载和预渲染的操作和过程。

在本上下文中，术语“预加载”指的是在对用户不易察觉的后台模式中不响应于用户对app的调用(并且通常在此之前)而加载、启动和至少部分运行app的过程。可以被预加载的app组件包括例如app的主订阅源(main feed)、app的其他UI显示和/或app内的内容(即在启动app时用户不立即可见的app内容)。在本上下文中，术语“UI显示”指的是逻辑UI元素——由app使用以与用户实现交互的视图或窗口。例如，在安卓操作系统(OS)中，UI显示被称为视图或活动。

术语“预渲染”是指在后台模式中构建app的UI显示的过程。在本文，预渲染被认为是预加载操作的组成部分。预渲染可以涉及修改UI显示的UI任务，和/或不直接修改UI显示却是这种修改的先决条件或同步于后台中的UI显示的修改的UI任务。因此，例如，当预加载app并准备初始化或修改app的UI显示时执行的初始化或准备的任务在本文也被视为预渲染任务。

综述

本文描述的本发明的实施例提供了用于在用户设备中预加载用户应用(“app”)及其内容的改进的方法和系统。所公开的预加载方案减少了用户在与app交互时感知的延迟，并因此提供了增强的用户体验。

在一些实施例中，用户设备运行操作系统(OS)，除其他功能外，该操作系统预加载用户app的UI显示。所公开的技术可以被用于预加载个体的UI显示、相互关联的UI显示组或整个app。为了清楚起见，举例来说，下面的描述主要涉及安卓OS和安卓活动。然而，所公开的技术适用于任何其他合适的OS和任何其他合适类型的UI显示。

在一些公开的实施例中，OS使用本文称为“前台模拟”或“模拟前台”的新颖操作模式预加载活动。在这种模式中，app以前台模式处理活动，但OS以后台模式保持对用户隐藏的活动。换句话说，正在进行前台模拟的活动从app的角度来看是在前台中，而从OS的角度来看是在后台中。在一些实施例中，app不知道活动在后台中被预加载而在前台未按常规加载的事实。在其他实施例中，OS通知app该活动在后台中被预加载，使得app能够使用旨在用于前台模拟的不同程序代码。

所公开的前台模拟模式使得活动能够被预加载，包括预渲染和其他合适的与预加载相关的操作，可选地使用现有的app程序代码，同时仍然将活动保持在用户不易察觉的后台中。

本文描述前台模拟的各个方面，包括预加载活动、app和app内的内容的实现示例、用于终止前台模拟的标准、以及使用OS的现有前台生命周期状态/事件的实现。在一些实施例中，使用由OS提供给用户app的应用编程接口(API)来实现所公开的技术。

在一些实施例中，OS通过将预加载的活动与非预加载的活动隔离来保持预加载操作对用户透明。特别地，OS可以将预加载的活动和非预加载的活动存储在单独的数据结构(例如，单独的任务、任务堆栈和/或显示)中。当需要向用户显示预加载的活动时，OS通常将活动从专用于预加载活动的数据结构移动到专用于非预加载的活动的数据结构。

其它公开的实施例涉及通过显式的用户请求触发预加载，以及涉及提供指示预加载的进度的用户信息。

系统描述

图1是根据本发明的实施例示意性地示出采用预加载的通信系统20的框图。

系统20包括运行一个或更多个用户应用(“app”)26的用户设备24。设备24可以包括任何合适的无线或有线设备，诸如例如蜂窝电话或智能手机、支持无线的膝上型或平板计算机、台式个人计算机、视频游戏控制台、智能TV、可穿戴设备、汽车用户设备或能够向用户呈现内容的任何其他合适类型的用户设备。为了清楚起见，该图示出了单个用户设备24。现实生活中的系统通常包括大量各种类型的用户设备。

在本上下文中，术语“用户应用”、“应用(application)”和“app”可互换使用，并且指的是在用户设备上运行并可由用户调用(激活)的任何合适的计算机程序。一些app 26可以是专用的特殊用途应用，诸如游戏app。其他app 26可以是通用应用，诸如Web浏览器。

在一些实施例中(然而不是必须的)，app 26由一个或更多个网络侧服务器(例如，门户28)提供和/或通过网络32与一个或更多个网络侧服务器通信。网络32可以包括例如广域网(WAN)(诸如互联网)、局域网(LAN)、无线网络(诸如蜂窝网络或无线LAN(WLAN))或任何其他合适的网络或网络的组合。

在本示例中，用户设备24包括执行用户设备的各种处理任务的处理器44。除其他任务外，处理器44运行操作系统(OS)48，操作系统(OS)48继而运行app 26。本文描述的实施例主要涉及安卓OS。然而，所公开的技术适用于可以在用户设备上运行的任何其他合适的OS，例如，iOS、Windows、Linux等。OS 48包括被称为预加载代理50的软件部件，其处理app的预加载。App 26、OS 48和预加载代理50被示意性地绘制在处理器44内部，以指示它们包括在处理器上运行的软件。

另外，用户设备24包括非易失性存储器(NVM)54，例如闪存。NVM 54可以尤其用于存储高速缓存存储器52，以用于缓存与app相关联的内容。在一些实施例中，用户设备使用单个高速缓存52。在图中同样示意性描绘的其他实施例中，可以为每个app定义单独的高速缓存存储器52。混合实现也是可能的，其中高速缓存52的一部分是集中的，而一些是app特定的。为了清楚起见，下面的描述将简单涉及“高速缓存52”，意指任何合适的高速缓存配置。

用户设备24还包括用于向用户呈现视觉内容的显示屏56、以及用于连接到网络32的合适的网络接口(未在图中示出)。该网络接口可以是有线的(例如，以太网网络接口控制器NIC)或无线的(例如，蜂窝调制解调器或Wi-Fi调制解调器)。典型地，用户设备24还包括一些内部存储器，例如用于存储相关代码和/或数据的随机存取存储器(RAM)(未在图中示出)。

在图1的示例实施例中(然而不是必须的)，系统20还包括在网络侧执行预加载相关任务的预加载服务器60。服务器60包括用于通过网络32通信的网络接口64、以及执行预加载服务器的各种任务的处理器68。在本示例中，处理器68运行执行网络侧预加载相关任务的预加载控制单元72。

网络侧预加载相关的任务可以包括，例如，决定预加载哪些app以及何时预加载，选择是否预加载以及预加载哪些app内的内容，决定预加载多少app组件(例如，仅执行一些初始可执行代码，或者app的用户界面的预渲染和/或关于前台模拟的持续时间的决定)。另一个可能的网络侧预加载相关的任务可以包括，例如，决定适用的预加载模式(例如，其中限制或禁止对网络的访问的离线预加载，或其中允许网络访问的在线预加载)。例如，在PCT申请PCT/IB2020/057046中论述了预加载模式，该PCT申请的公开内容通过引用并入本文。又一示例是如下所述的允许进行预加载的app的“白名单”。在实施例中，预加载服务器60可以被实现为基于云的应用。

在本文描述的实施例中，为了清楚起见，预加载任务被描述为由用户设备24的处理器44执行。然而，一般来说，预加载任务可以由设备24的处理器44、服务器60的处理器68或两者来执行。

预加载app 26可以涉及预加载任何app元素，诸如与app相关联的可执行代码，例如启动代码、app馈送、app登陆页面、与app相关联的各种UI元素、与app相关联的内容、与app相关联的app数据、和/或通过诸如点击的用户动作使用app可获得的代码或内容(“app内的内容”)。内容的预渲染可以涉及任何合适类型的UI显示或其一部分的后台处理。例如，在安卓术语中，预渲染可以包括一个或更多个安卓活动的后台处理。在后台模式中，与app相关联的UI元素不在显示屏56上呈现给用户，即对用户隐藏。当用户调用先前预加载的app时，用户设备切换到以用户可见的前台模式运行该app。(为了简洁起见，术语“后台模式”和“前台模式”在本文简称为“后台”和“前台”。)

图1中所示出的系统20及其各个元素的配置是示例配置，选定它们仅出于概念清晰的目的。在替代的实施例中，能够使用任何其它合适的配置。例如，在一些实施例中，预加载任务可以完全在用户设备24的处理器44中实现，在这种情况下，子系统60可以被完全消除。

预加载代理50可以在处理器44上运行的软件模块中、在处理器44上运行的应用中、在嵌入在处理器44上运行的应用中的软件开发工具包(SDK)中、作为在处理器44上运行的OS的一部分(可能由用户设备供应商或其他方添加到OS)、在处理器44上运行的代理服务器中、使用上述两种或更多种的组合或以任何其他合适的方式来实现。在接下来的大部分描述中，假设预加载代理50是用户设备24的OS 48的一部分。

虽然本文中所描述的实施例主要指人类用户，但术语“用户”还指机器用户。例如，机器用户可包括使用无线通信的各种主机系统，诸如在各种物联网(IoT)应用中的主机系统。

系统20的不同元素可使用合适的软件、使用合适的硬件(例如，使用一个或更多个专用集成电路(ASIC)或现场可编程门阵列(FPGA))、或使用硬件和软件元素的组合来实现。高速缓存52可以使用一个或更多个任何合适类型的存储器或存储设备来实现。在一些实施例中，可以使用在软件中编程以执行本文描述的功能的一个或更多个通用处理器来实现预加载代理50和/或预加载服务器60。例如，可通过网络以电子形式将软件下载到处理器，或者软件可以可替代地或附加地被提供和/或存储在非暂时性有形介质上，诸如磁存储器、光学存储器或电子存储器。

活动的预加载、以及预加载的和非预加载的活动之间的隔离

在本发明的一些实施例中，用户设备24的OS 48中的预加载代理50预加载一个或更多个app的一个或更多个UI显示，以减少用户经历的延迟。本文的描述主要指作为UI显示的示例的安卓活动，但是所公开的技术可用于预加载任何其他合适类型的UI显示。所公开的技术可以经某些变化适用于个体活动、app和app内的内容的预加载。

OS 48通常维护一个或更多个活动的“任务”。术语“任务”是指用于存储用户在执行某项工作时与其交互的活动的容器。存储在某个任务中的活动可能属于单个app或多个不同的app(例如，当一个app打开另一个app的活动时)。

在一些实施例中，OS 48将每个任务与“任务堆栈”相关联。术语“任务堆栈”指的是以某种逻辑顺序(诸如堆栈顺序(后进先出))保存不同的任务的容器。顺序涉及被显示的活动的顺序，例如，哪个活动被显示在其顶部。OS 48还可以在不同任务堆栈之间应用逻辑顺序。在安卓OS中，“任务堆栈”有时被称为“活动堆栈”。

当应用预加载时，OS 48采取各种措施来保持预加载操作不易被用户察觉。因此，例如，OS确保预加载的活动对用户是不可见的，并且预加载操作不影响OS的“最近”屏幕(也称为“总览屏幕”、“最近任务列表”、“最近app”、“最近的视图”或“最近使用的app”)。

在一些实施例中，OS 48通过将预加载的活动和非预加载的活动隔离在单独的数据结构(例如，单独的任务和任务堆栈)中，来保持预加载操作不易被用户察觉。当需要向用户显示预加载的活动时，OS将活动从专用于预加载的活动的数据结构移动到专用于非预加载的活动的数据结构。

图2是根据本发明的实施例示意性地示出由OS 48用来处理预加载的和非预加载的活动的数据结构的图。

如所见，OS 48被配置成处理多个非预加载的活动80。非预加载的活动与一个或更多个“非预加载的任务”84相关联。每个非预加载的任务84是以特定逻辑顺序存储一些非预加载的活动的堆栈。非预加载的任务84与一个或更多个非预加载的任务堆栈88相关联(为了清楚起见，在图中仅看到一个任务堆栈)。每个非预加载的任务84与非预加载的任务堆栈88中的一个相关联。

OS 48为预加载的活动92维护类似但独立的层次结构。预加载的活动92与一个或更多个“预加载任务”96相关联。每个预加载的任务96是以特定逻辑顺序存储一些预加载的活动的堆栈。预加载的任务96继而与一个或更多个预加载的任务堆栈100相关联(同样，为了清楚起见，在图中仅看到一个预加载的任务堆栈)。每个预加载的任务96与预加载的任务堆栈100中的一个相关联。

因此，在一些实施例中，OS 48将非预加载的活动存储在数据结构的层次结构(非预加载的活动、非预加载的任务和非预加载的任务堆栈)中。OS 48将预加载的活动存储在另一个单独的数据结构的层次结构(预加载的活动、预加载的任务和预加载的任务堆栈)中。

预加载的和非预加载的活动的处理之间的隔离或分离的典型特征在于：

■非预加载的任务只保存非预加载的活动，而不保存预加载的活动。非预加载的任务堆栈只保存非预加载的任务，而不保存预加载的任务。类似地，预加载的任务只保存预加载的活动，而不保存非预加载的活动；以及预加载的任务堆栈只保存预加载的任务，而不保存非预加载的任务。

■非预加载的活动、任务和任务堆栈不受预加载的活动、任务和任务堆栈的影响。例如，预加载的任务和非预加载的任务之间没有堆叠或其他顺序；并且在预加载的任务堆栈和非预加载的任务堆栈之间没有堆叠或其他顺序。

■活动的预加载和/或预加载任务和任务堆栈的创建不影响OS 48的“最近”屏幕。因此，如果某个任务在最近的屏幕上，则即使对预加载的活动、预加载的任务或预加载的任务堆栈应用了任何操作，该任务仍将保留在最近的屏幕上。出于同样的原因，如果任务不在最近的屏幕上，那么由于一些预加载相关的操作，它将不会被添加到最近的屏幕上。此外，任务在最近的视图中的出现顺序不受预加载操作的影响。

上面描述的数据结构以及由OS 48对它们的处理简化了预加载操作的实现，并确保预加载操作对用户是不易察觉的。

图3是根据本发明的另一实施例示意性地示出用于处理预加载的和非预加载的活动的数据结构的图。在该实施例中，OS 48支持在图2的层次结构之上的附加层级的层次结构，即“显示”的层次结构。

在本上下文中，术语“显示”指的是用于存储活动的逻辑构建，例如容器。每个显示都有属性和状态。属性是表征显示的固定属性，诸如高度、宽度、密度、颜色模式、支持的刷新率以及特殊功能，诸如高动态范围(HDR)。状态包括显示的可变属性，例如，显示取向(纵向或横向)。显示可以被定义为虚拟显示，即，不与物理硬件相关联的显示，并且其内容因此不显示给用户。相反，虚拟显示允许将内容渲染到虚拟表面，其中表面是保持像素的对象。

在一些实施例中，OS 48定义默认显示104(其内容实际上在显示屏56上显示给用户)和一个或更多个专用于预加载的虚拟显示108(称为“预加载的虚拟显示”)。所有非预加载的任务堆栈88都与默认显示104相关联。每个预加载的任务堆栈100与预加载的虚拟显示108中的一个相关联。在示例实现中，在预加载的任务堆栈100和预加载的虚拟显示108之间存在一对一的对应关系，即，每个预加载的任务堆栈100与单个相应的预加载的虚拟显示108相关联。

附加层次结构保留了上述预加载的和非预加载的活动之间的分离。例如，默认显示104仅包括非预加载的任务堆栈而没有预加载的任务堆栈；预加载的虚拟显示只包括预加载的任务堆栈，而不包括非预加载的任务堆栈。

图3中所描绘的显示的配置纯粹是作为示例来选择的。在替代的实施例中，可以使用任何其它合适的配置。例如，在预加载的任务堆栈100和预加载的虚拟显示108之间不一定需要严格的一对一对应关系，即，某个虚拟显示108可以包括两个或更多个预加载的任务堆栈100。作为另一示例，OS可以同时维护多个常规(非虚拟)显示。使用虚拟显示的预加载的附加方面在下面的“附加实施例和变型”部分中进一步论述。

使用前台模拟预加载活动

在一些实施例中，预加载代理50使用称为“前台模拟”或“模拟前台”的特殊操作模式预加载一个或更多个用户app 26的一个或更多个活动。在该模式中，app 26以前台模式处理活动，但OS 48以后台模式保持对用户隐藏的活动。换句话说，正在进行前台模拟的活动从app的角度来看是在前台中，从OS的角度来看是在后台中。

前台模拟模式使得活动能够被预加载，包括预渲染和其他合适的与预加载相关的操作，可选地使用现有的app程序代码，同时仍然将活动保持在用户不易察觉的后台中。

在各种实施例中，OS 48可以使用各种技术来将活动保持在后台，即使app处理活动就好像它在前台一样。例如，预加载代理50可以覆盖(override)使活动窗口显示在用户设备24的显示屏56上的一个或更多个最终系统调用。作为另一示例，预加载代理50可将该活动与未链接到实际物理显示的虚拟显示相关联。下面将详细解释使用虚拟显示来进行预加载。

在一些实施例中，活动的预加载包括可能按照不同的顺序的以下步骤或其子集：

■OS 48决定某个app 26的某个活动将被预加载。

■OS授予app权限，让app仿佛运行在与可能更受限制的后台状态相对的前台中，但实际上OS将app保持在后台中。例如，OS可能会授予app启动活动的权限。

■如果讨论的app的进程不活跃(alive)，则OS将为该app创建app进程。

■如果该活动尚未与任务相关联，则OS为该活动创建预加载的任务96。

■OS将活动标记为预加载的活动92。例如，可以通过标记活动本身、通过标记保存活动的预加载的任务、或隐含地例如通过将预加载的任务放置在照此被标记的预加载的任务堆栈100中，和/或通过将预加载的任务放置在预加载的堆栈100中来执行该标记，预加载的任务堆栈100本身通过将预加载的任务堆栈放置在预加载的虚拟显示108中而被显式地或隐含地标记为预加载。

■如果预加载任务96尚未与预加载的任务堆栈100相关联，则OS创建预加载的任务堆栈并将预加载的任务与该任务堆栈相关联，或者可替代地将预加载的任务与现有预加载的任务堆栈相关联。在一些实施例中，OS可以维护按需或提前创建的单个预加载的任务堆栈，或者多个任务堆栈。例如，OS可以为每个app或每个预加载的任务创建预加载的任务堆栈。

■在一些实施例中，如果预加载的任务堆栈100尚未与预加载的虚拟显示108相关联，则OS创建预加载的虚拟显示并将预加载的任务堆栈与该预加载的虚拟显示相关联，或者可替代地将预加载的任务堆栈与现有预加载的虚拟显示相关联。在一些实施例中，OS可以维护按需或提前创建的固定数量的预加载的虚拟显示，或者维护动态数量的预加载的虚拟显示。例如，OS可以为每个app、或每个预加载的任务堆栈或每个预加载的任务创建预加载的虚拟显示。

■在一些实施例中，OS使用活动的正常生命周期事件(例如，在安卓中，使用app的OnCreate()方法)启动和初始化app。在替代实施例中，OS使用专用于由于预加载而初始化app的事件例如OnCreateForPreload()来启动和初始化app。

■在一些实施例中，OS在后台中创建预加载的活动，即，不向用户显示活动，并使用活动的正常生命周期回调调用app的初始化代码，例如OnCreate()。替代地，OS可以在后台中创建预加载的活动，并使用专用于由于预加载而初始化活动的事件例如OnCreateForPreload()来调用其初始化代码。

■OS模拟活动转换到前台，但实际上使用“前台模拟”模式，保持活动对用户隐藏(活动好像是在后台)。在一些实施例中，但不是必须的，前台模拟允许活动在后台时完全渲染。

■在一段时间的前台模拟之后，OS将活动的状态改变为正常的后台活动。

在某些情况下，用户可以例如通过调用app来进入预加载的活动(而不知道活动是预加载的事实)。在这种情况下，活动应该退出预加载的状态。用户对预加载的活动的进入可包括以下步骤或其子集：

■OS将活动标记为正常的、非预加载的活动(如果当前以其他方式标记的话)。

■OS验证保存活动的任务不是非预加载的任务。如果适用，可以通过将活动的先前的任务(预加载的任务)重新指定为非预加载任务，或者通过将活动移动到不同的、可能是新的、非预加载的任务来执行该验证。

■OS验证现在保存活动的非预加载的任务与非预加载的任务堆栈相关联。在一些实施例中，OS从预加载的任务堆栈中移除非预加载的任务，并将该任务重定父级(re-parent)到现有或新的非预加载的任务堆栈中。在一些实施例中，OS仅将保存非预加载的任务的现有任务堆栈标记为非预加载的。这可以通过将现有任务堆栈重定父级到非预加载的目标显示来显式地或隐含地完成。

■在一些实施例中，OS验证保存非预加载的任务堆栈的显示与非预加载的显示相关联。在一些实施例中，这包括将任务堆栈重定父级到非预加载的目标显示中。

■OS使预加载的活动对用户可见，并将其移动到常规的前台状态。

■OS调用任何相关的回调函数，这些函数可与活动或app从预加载的状态退出有关。

图4是示意性示出根据本发明的实施例的预加载过程的状态图。该状态图可以由OS 48可能以某些变化来使用，用于预加载属于某个app的活动，或者用于预加载app本身。使用该状态图预加载的活动可以是例如app的启动活动或作为app内的内容的一部分的活动。然而，为了简单和清楚，下面的描述主要是指单独活动的预加载。app的预加载将在下面更详细地论述。

预加载操作以预加载触发——即，使OS 48决定预加载活动的事件——开始。响应于预加载触发，预加载代理50将活动转换到“前台模拟”状态110。如上所述，在这种状态下，app将活动视为前台活动，而OS将活动视为后台活动。当活动处于前台模拟状态时，代理50在后台中启动活动并至少部分地预渲染活动。

在某个阶段，代理50决定结束前台模拟。下面进一步讨论用于结束前台模拟的若干示例完成标准。假设在前台模拟期间没有发生错误，预加载代理50将活动从台模拟状态110转换到“预加载的后台”状态114。如果在前台模拟期间发生错误，预加载代理50可以终止(“扼杀(kill)”)该活动。

在预加载的后台状态下，OS和app都将该活动视为后台活动。在该状态下，活动是静态的，并在后台中等待。在一些实施例中，当活动处于预加载的后台状态114时，预加载代理50可以决定在后台中刷新活动。在这种情况下，代理50将活动转换回前台模拟状态110。

在用户进入时，例如，当用户通过点击app的图标启动app时，代理50将活动从预加载的后台状态114转换到“前台”状态118。在该状态下，活动对用户可见。借助于在前台模拟状态下执行的准备和预渲染操作，到前台状态118的转换是快速的。如图所示，在前台模拟期间用户进入的情况下，从前台模拟状态110直接转换到前台状态118也是可能的。

图4中的状态图是示例状态图，该图仅仅是出于概念清晰的目的而被描绘的。在替代实施例中，OS 48可以使用状态和转换的任何其他合适配置来执行所公开的技术。下面给出了附加的实现细节和可能的变型。

在一些实施例中，在安卓实现中，在进入前台模拟状态110时，代理50将活动设置为“恢复”状态，将活动及其窗口标记为“可见”，并将活动标记为“焦点(focus)”。然而，从用户的角度来看，活动被渲染到后台，因此对用户来说是不可见的。在从前台模拟状态110转换到预加载的后台状态114时，代理50改变活动的“可见”和“焦点”信号，以指示活动不可见和非焦点，并调用任何相关回调，并且另外将活动状态改变为“暂停”和/或“停止”。

在一些实施例中，代理50使用与进入和退出前台有关的安卓OS的现有生命周期事件来使活动转换进入前台模拟状态110和从前台模拟状态110转换出来。这些生命周期事件可以包括，例如，用于进入前台模拟的OnStart()和/或OnResume()，以及用于退出前台模拟的OnPause()和/或OnStop()。这种实现简化了app与预加载特征的集成，因为app能够使用其正常的、非预加载的、与活动相关的代码流。

在替代实施例中，代理50使用新的专用事件来将活动转换进入前台模拟状态110中和从前台模拟状态110中转换出来。这些新的生命周期事件专用于预加载操作，与用于正常活动处理的事件不同。例如，这种专用事件可以包括OnSimulatedStart()、OnSimulatedResume()、OnSimuatedPause()、OnSimulatedStop()等。

在一些实施例中，OS 48向app通知活动被预加载的事实。例如，可以使用由OS提供给app的合适的应用编程接口(API)来执行这样的通知。例如，可以例如通过软件开发工具包(SDK)对app提供形式为“boolean isPreloaded(Activity activity)”的API。该方法允许app检查某个活动是否被预加载。当省略活动参数时，查询/通知被解释为关于app本身是否被视为预加载的一般查询/通知。

在一些实施例中，当预加载app或活动时，app不执行某些动作，只有当用户实际使用该app/活动时app才愿意执行这些动作。这样的推迟动作可以包括，例如，运行分析代码，获取并渲染某些内容，获取和渲染在进入时不立即显示给用户的内容，等等。在一些实施例中，OS 48(例如，通过SDK)向app提供API，该API允许app注册一个或更多个回调函数，以便在预加载之后在用户进入时使用。在用户进入预加载的活动或预加载的app时，OS调用这些函数。该特征使app能够完成预加载期间跳过的任何动作，例如，运行相关分析代码，刷新之前预加载的UI，开始视频回放等。

如上所述，预加载代理50可以使用各种完成规则来决定结束某一活动的前台模拟，并转换到预加载后台状态114。在一个实施例中，代理50继续前台模拟，直到活动在后台中被完全渲染，并且仅在那时转换到预加载的后台状态114。在其他实施例中，前台模拟阶段在时间上被限制为不超过定义的超时持续时间。例如，可以通过使用编程定时器和/或通过使用(例如，通过SDK)提供给app的API来实现时间限制。

在一个实施例中，不使用API，并且超时到期指示预加载成功完成。在成功完成时，代理50认为预加载的活动适于将来的显示，并从“前台模拟”转换到“预加载后台”。如上所述，如果app指示在预加载期间发生错误，代理50可以例如通过破坏活动/app来终止预加载过程。

在另一实施例中，除了超时机制之外，OS 48向app提供API，该API使app能够指示预加载是成功还是失败。如果app指示预加载成功，则OS就像定时器已经到期一样，停止定时器并转换到“预加载的后台”。如果app指示预加载失败(例如，由于在获取要渲染的内容时的网络问题)，则OS可以例如通过破坏正在被预加载的活动/app来终止预加载过程。在实施例中，如果超时在app指示成功预加载之前到期，则OS可以将预加载视为失败，并且可以例如通过破坏正在被预加载的活动/app来终止预加载过程。

为了确保OS 48不显示其预加载失败的活动，并因此确保向用户显示的预加载的内容是完好的，考虑上述失败场景是重要的。例如，如果在预加载app时发生网络错误，则失败场景避免稍后向用户显示错误，而错误条件可能不再有效。

使用前台生命周期事件对活动进行后台预加载

图5A和图5B是根据本发明的实施例分别示意性地示出前台加载的活动和后台预加载的活动的生命周期状态(也被称为生命周期事件)的状态图。在一些实施例中，图5A和图5B说明了如何可以使用为活动的传统前台处理而设计的现有OS生命周期事件/状态来实现活动的后台预加载。

如图5A所示，前台活动的生命周期在活动启动时开始。然后，活动穿过onCreate()、onStart()和onResume()状态，这些状态随着活动的运行而结束。

如果另一活动进入前台，最初的活动转换到onPause()状态。在一定时间之后，当活动变得不再可见时，它进行到onStop()状态。如果活动执行完毕或被OS破坏，则活动传递到onDestroy()状态，然后关闭。

当处于onPause()状态时，如果用户返回到最初的活动，则活动返回到onResume()状态，然后继续运行。同样在onPause()状态下，如果具有更高优先级的app竞争存储器资源，OS可能会扼杀该活动的app进程。稍后，如果用户导航到活动，活动将从onCreate()状态开始。

当处于onStop()状态时，如果用户导航到活动，活动传递到onRestart()状态，然后传递到onStart()状态。同样在onStop()状态下，如果具有更高优先级的app竞争存储器资源，OS可能会扼杀该活动的app进程。稍后，如果用户导航到活动，活动将从onCreate()状态开始。

图5B示出了根据本发明的实施例的在预加载活动中对图5A的安卓前台生命周期状态的可能使用。在该示例中，预加载的活动的生命周期以预加载触发开始。响应于预加载触发，预加载代理50将活动转换到前台模拟状态110(如在上面的图4中)。在本示例中，使用onCreate()、onStart()和onResume()状态来实现前台模拟过程的流程。然而，对于与图5A中的前台活动相对的预加载的活动，OS 48例如通过覆盖在用户设备24的显示屏56上显示活动的系统调用来将活动保持在后台。

从“活动运行”到onPause()状态的转换条件在前台活动(图5A)和预加载的活动(图5B)之间也不同。对于预加载的活动，代理50在前台模拟成功完成时将活动转换到onPause()状态。如果前台模拟失败，例如由于网络问题，则OS可能除了完成预加载的活动之外，还可以破坏如上所述的活动的app进程。

从onPause()状态，预加载的活动进行到预加载的后台状态114，在本示例中，其是使用onStop()生命周期状态来实现的。

当处于onStop()状态时，如果OS(通常是代理50)决定刷新活动，则该活动传递到onRestart()状态，然后到onStart()状态。如果活动已被OS扼杀，OS稍后可能决定再次预加载活动。在这种情况下，活动传递回到onCreate()状态。

为了清楚起见，图5B没有示出由用户导航到活动而触发的转换。这样的触发使活动传递到前台模式，而不是前台模拟。例如，当处于onStop()状态时，用户导航到活动将使活动传递到onRestart()状态，但处于前台模式；当处于onPause()状态时，用户导航到活动将使活动传递到onResume()状态，但处于前台模式；以及在活动处于被扼杀状态后，用户导航到活动将使活动传递到onCreate()状态，但处于前台模式。

上面描述的生命周期状态/事件和转换条件仅仅是通过示例的方式来描述的。在替代实施例中，可以使用生命周期事件/状态的任何其他合适的布置。在上面引用的美国临时专利申请63/128,220中论述了使用OS生命周期事件来实现预加载的另外的方面。

预加载用户应用

到目前为止的描述主要涉及单独活动的预加载。在一些实施例中，OS48的预加载代理50使用所公开的技术，用于在用户请求激活app之前将用户app 26作为整体预加载。预加载app(在本文称为“AppPreload”)通常包括预加载app的活动的选定子集，从而显著减少app启动延迟。

在一些实施例中，在预加载app中，代理50通过预加载app的入口点活动(有时称为启动器活动或启动屏幕(splash screen))来遵循并模拟正常的app启动序列。然后，代理50可以可选地预加载一个或更多个附加活动，app通常启动这些活动作为其正常启动序列的一部分。代理50通常使用上述技术例如使用前台模拟预加载每个选定的活动、入口点或其他内容。

在一些实施例中，如果app在app正在被预加载时调用活动，代理50验证调用是预加载发起的，而不是用户发起的。如果是，代理50预加载该活动。在一些实施例中，如果这样的活动通常需要新任务，则代理50为该活动创建新的预加载的任务，并将该活动与新的预加载的任务相关联。在上文引用的PCT国际公布WO 2019/171237中论述了与区分预加载发起或用户发起活动有关的另外的方面。

在一些实施例中，代理50将在启动序列期间预加载的各种活动放置在同一预加载的任务中。在一些实施例中，代理50根据app的正常启动序列创建预加载的任务，其中对于将正常创建的每个任务，代理50创建匹配的预加载的任务。在一些实施例中，每个预加载的app被分配单独的预加载的任务堆栈，其包含该app的各种预加载的任务和预加载的活动。在一些实施例中，每个预加载的app被分配单独的预加载的虚拟显示，其包含app的预加载的任务堆栈。

在一些实施例中，当用户进入预加载的app时，代理50确保app将以其初始状态显示。在一些实施例中，当准备预加载app时，代理50检查app是否已经具有一个或更多个存活(living)的活动。如果是这样，代理50在开始预加载之前扼杀app的存活的活动和任务。例如，代理50可以破坏保存存活的活动和任务的app进程。在一些实施例中，在预加载app时，如果app已经具有一个或更多个存活的进程，则代理50在开始预加载之前破坏和/或完成它们。

在一些实施例中，代理50仅响应于验证app当前不在前台中而预加载app。

在一些实施例中，代理50将仅响应于验证app不具有任何存活的进程而预加载app。在一些实施例中，代理50将仅响应于验证在正常app启动期间正常启动的所有进程都不是活跃的而预加载app。在一些实施例中，代理50将仅响应于验证某些特定进程不是活跃的而预加载app。这种特定进程的选择可以依赖于定义的配置。

在一些实施例中，代理50将仅响应于验证app不具有含有一个或更多个指定类型的任何活动(live)的app组件的进程而预加载app。这样的类型可以包括例如活动、广播接收器、服务、内容提供商、小部件(widget)、通知或任何其他合适类型的app组件。

在一些实施例中，代理50将仅响应于验证app不具有任何活动的活动而预加载app。在一些实施例中，代理50将仅响应于验证app不具有特定活跃的活动(在本文称为目标活动)而预加载app。目标活动可以例如经由API而针对每个app进行配置。在一些实施例中，app精确地配置一个目标活动(被称为其“主活动”)，其通常在app的预加载期间被预加载。

在其他实施例中，即使app具有活动组件，但只有当该app被视为“最近未使用”(NRU)时，代理50也可以预加载app。例如，如果自用户上次使用app以来所经过的时间超过了定义的值，则该app将被视为NRU。

通常，如上所述，OS 48的最近屏幕不受app的预加载的影响。因此，当最近屏幕请求用预加载的任务替换的任务时，OS 48向最近屏幕提供最新的任务，而不是试图将先前的任务带到前台(可能会失败，因为先前的任务不再存在)或创建新的任务。在一些实施例中，通过维护由最近屏幕保存的最新任务与每个用户每个app(例如，每个app包)的最新预加载的任务之间的映射来实现该特征。在其他实施例中，通过维护{app包，用户}和针对{app包，用户}的最新预加载的任务之间的映射来实现该特征。

在一些实施例中，由OS 48维护的app使用度量不受app的预加载的影响。在该上下文中，app使用度量可包括，例如，每个app或app包的最后使用时间戳、通常基于最近使用时间的进程优先级排序(例如，最近最少使用的顺序)、先前使用的进程等。

在一些实施例中，代理50根据最近最少使用的使用度量预加载app。在一些实施例中，代理50在用户从app退出之后预加载app。在一些实施例中，代理50在用户从app退出之后预加载app，以防这种退出使app的一个或更多个活动被扼杀。例如，这种场景可能由于app从最近屏幕上扫除(swiped-off)或通过使用后退按钮退出而出现。

在一些实施例中，预加载app不影响OS 48关于启动省电状态的决策，例如，是否以及何时启动App待机。因此，例如，为了省电决策的目的，app的预加载不被视为app使用。

在一些实施例中，在app的预加载期间，OS 48临时关闭节电状态，例如，以便允许app下载和/或渲染内容。

在一些实施例中，当app的预加载完成时，app及其所有活动被移动到正常后台状态，例如暂停或停止状态。

在一些实施例中，预加载代理50设置预加载app的总持续时间的上限。该上限可以被设置为代替或附加于每个单独活动的预加载的时间限制(在图4中从前台模拟状态110转换到预加载的后台状态114之前的超时)。例如，可以使用编程定时器和/或使用(例如，通过SDK)提供给app的API来实现时间限制，类似于与个体活动有关的超时实现。在示例实施例中，API可以允许app声明app的预加载成功完成，而不是个体活动的成功预加载。

在一些实施例中，当用户进入预加载的app时，OS 48在显示预加载的一个或多个活动之前呈现一些初步UI动画和/或启动窗口。在一个实施例中，该动画和/或启动窗口与没有预加载app时将显示的动画和/或启动窗口相同。在另一实施例中，当预加载app时，OS呈现某个动画和/或启动窗口，而当没有预加载app时，OS呈现不同的动画和/或启动窗口。在后一种情况下，OS可以使用专门特别地用于预加载之后用户进入的情况的动画和/或启动窗口，例如，作为向用户指示正在进入的app是预加载的。

在一些实施例中，app的预加载支持用户设备24中的多用户环境。例如，在一些实施例中，OS 48确保一个用户的预加载的任务不能被另一个用户访问或以其他方式使用。在一些实施例中，OS为每个用户维护不同的预加载策略。

在一些实施例中，OS 48给予预加载的处理优先级比UI前台相关作业的处理优先级低。在一些实施例中，分配给预加载的处理资源被限制在对UI前台相关的作业优先化之后的可用处理资源的一小部分。在一些实施例中，预加载在安卓的后台Cgroup下被执行。

在一些实施例中，OS 48为app开发人员提供测试工具，以便模拟app的预加载。在app的预加载可以以多种模式进行的一些实施例中，例如，如在上述PCT申请PCT/IB2020/057046中所述，预加载的模拟支持所有可能的模式。

在一些实施例中，app预加载被用于加速app(诸如游戏)的启动时间，其中在app启动时发生大量处理工作。

在一些实施例中，app预加载以这样的方式执行，即在预加载期间执行的处理在相当长的持续时间内保持与用户相关。例如，预加载可以排除例如以超过预定义速率快速变化的内容项。一个示例是预加载app(例如，游戏)的登陆页面的至少一部分，该app的登陆页面很少随时间改变。这允许OS仅偶尔并且可能在优选时间时期(例如，当用户设备连接到电源时)预加载这样的app(例如游戏)，并且仍然维持预加载的app按原样被用户使用的高可能性，而不需要(例如在用户进入时)刷新预加载的内容。

在一些实施例中，app预加载被用于加速需要特定设备资源(例如，GPU资源)的app(诸如游戏)的启动时间。在一些实施例中，当设备资源可用/丰富时执行这样的app的预加载。

在一些实施例中，app预加载排除通过网络获取内容。在一些实施例中，在预加载期间，OS禁止访问网络。在一些实施例中，app预加载限于渲染已经存在于用户设备中(例如，在闪存中)的内容，例如，嵌入在app本身中或驻留在临时高速缓存(例如，先前通过网络获取的项目的高速缓存，诸如图1的高速缓存52)中的内容。

在一些实施例中，app预加载功能中的至少一些被集成到app开发框架或第三方SDK(例如游戏框架(也称为游戏引擎)或分析SDK)中。这样的app开发框架在本文被称为App预加载集成框架。在一些实施例中，这样的集成是通过为这样的框架或SDK提供合适的插件来实现的。在一些实施例中，使用App预加载集成框架替换一些或全部app预加载API集成步骤(这些步骤在其他方面被app需要，以便利用或更好地利用app预加载)。在一些实施例中，使用App预加载集成框架减少或简化了app与app预加载API的集成努力。在一些实施例中，app预加载API被给予app作为集成框架的一部分。

在一些实施例中，当决定是否预加载app时，OS 48考虑要预加载的app的类型，例如，该app是游戏。在一些实施例中，当决定是否预加载app时，OS 48可以考虑app使用的一个或多个框架的种类，以及其是否是App预加载集成框架。

预加载app内的内容

在一些实施例中，OS 48的预加载代理50使用所公开的活动预加载技术，例如与前台模拟有关的技术，用于预加载app内的内容(例如app内活动)。app内的内容的预加载在本文被称为“InAppPreload”。在本上下文中，术语“app内的活动”是指在app启动时不立即显示给用户的活动，而是可能基于诸如用户与app的交互的事件稍后显示的活动。

注意，app内的活动的预加载可以针对保持在后台的app(例如，预加载的app)和运行在前台的app(例如，被启动并且当前被用户使用的app)两者执行。在一些实施例中，在app本身已被预加载之后、当app在后台时执行app内的活动的预加载。在任何一种情况下，app内的活动的预加载都允许显著减少用户经历的延迟。由于当app需要显示活动时，例如响应于用户点击app内的链接，活动在存储器中至少部分就绪，所以延迟被减小。

在一些实施例中，OS 48中的代理50维护预加载的app内的活动的高速缓存。该高速缓存通常在用户设备RAM中实现。OS预加载的每个活动都被保存到该高速缓存中。可以预加载的活动或创建这样的活动的意图由OS分配相应的唯一和稳定的标识符(ID)，这些标识符被用作它们的高速缓存键。通常，虽然不是必须的，但app最初通过在意图创建活动时计算ID来分配ID。当app请求启动app内的活动时，代理50计算该活动的唯一ID，并将其与被缓存在app内的活动高速缓存中的活动的唯一ID进行比较。如果找到匹配，OS 48显示被缓存的活动，而不是创建新的活动。如果没有找到匹配，OS 48以通常在没有预加载的情况下创建活动的方式来创建活动。

在一些实施例中，app使用(例如，通过SDK)由OS提供的API将活动或创建活动的意图映射到唯一且稳定的ID。

在一些实施例中，代理50为app内的活动高速缓存中的每个活动分配到期时间戳。在这样的实施例中，OS 48仅在被缓存的活动的到期时间尚未到期时才从高速缓存提供预加载的活动(而不是创建新活动)。在一些实施例中，在活动到期时，该活动被破坏。代理50通常在预加载活动时分配到期时间戳，并将到期时间设置为预加载时间加上一定的生存时间(TTL)持续时间。在一些实施例中，TTL在所有app内的活动上和在所有app上是固定的。在一些实施例中，TTL在同一app的所有活动上是固定的。在一些实施例中，TTL是动态设置的。在一些实施例中，基于由app设置的配置(例如，通过API)，动态地设置TTL。

在一些实施例中，保持在app内的活动高速缓存中的活动的数量是有限的。在一些实施例中，代理50限制可驻留在用于给定app的存储器中的活动的总数，包括预加载的活动和非预加载的活动，该非预加载的活动是由app定期启动的活动。在一些实施例中，对缓存的活动的数量的限制是固定的。在其他实施例中，限制是动态设置的，并且可以取决于用户设备的当前状态(例如，取决于可用资源)、硬件类型(例如，总RAM和/或CPU功率)、app类型、app使用频率、app使用模式或任何其他合适的因素。

在一些实施例中，代理50为每个预加载的app内的活动分配其自己的单独的预加载任务96。在其他实施例中，代理50将预加载的app内的活动分组(例如，堆叠)在多个预加载任务96中。在另外的其他实施例中，代理50将所有预加载的活动分组(例如，堆叠)在单个预加载任务96中。在一些实施例中，每个预加载的任务96驻留在其自己的预加载的任务堆栈100中。在一些实施例中，所有预加载的任务96驻留在相同预加载的任务堆栈100内。在又一些实施例中，同一app的所有预加载任务驻留在相同预加载的任务堆栈内。在一些实施例中，用于app内的活动的预加载的任务堆栈驻留在预加载的虚拟显示108内，如下文将详细解释的。

在一些实施例中，预加载代理50基于要预加载的潜在目标活动的建议和排序(优先级化)来选择要预加载的app内的活动。在一些实施例中，OS 48向app提供用于建议和对要被预加载的潜在目标活动进行排序的API。在一些实施例中，app可以在app运行时的各个时间点调用API，以便例如根据对用户当前可达到和/或可见的内容项，例如根据app的暂时状态调整所建议的和已排序的潜在目标活动。

在一些实施例中，当具有预加载的app内活动的app被OS从前台移动到后台时，在app处于前台时，被预加载的app内的活动被保持限定的持续时间。该特征允许合理使用RAM，同时仍然允许用户切换到不同的app并返回，而不丢失预加载的活动。在一些实施例中，限定的持续时间在所有活动和所有app上是固定的。在其他实施例中，限定的持续时间在同一app的所有活动中是固定的。在另外的其他实施例中，动态地设置限定的持续时间。在一些实施例中，基于由app例如通过API设置的配置，动态地设置限定的持续时间。

在一些实施例中，代理50逐个预加载app内的活动，即，不是并发地预加载活动。在一些实施例中，代理50并发地预加载app内的活动，并可能维护并发限制。该限制定义了OS将在任何给定点执行的并发预加载的数量。OS可以根据当前条件将此限制设置为固定大小或动态设置该限制。设置更高的并发限制可能有助于活动高速缓存命中率，还可能减少由于预加载动作的捆绑的电池消耗。另一方面，更高的并发限制可能会消耗更多的设备资源，诸如CPU和GPU处理。因此，并发限制(动态或静态)设置可取决于诸如当前设备状态(例如，可用资源)、硬件类型(例如，总的RAM、CPU类型)、app输入(例如，预加载所需或分配的预计处理)和/或app是运行在前台模式还是后台模式中的因素。

在一些实施例中，当用户进入预加载的app内的活动时，OS 48在显示预加载的活动之前显示初步UI动画。这样的UI动画可以是在用户进入非预加载的活动时就会显示的相同动画，或者是不同的动画(例如，特别专用于预加载之后的用户进入的情况的动画)。专用动画可以包括，例如，针对用户的他或她正在进入被预加载的活动的指示。

在一些实施例中，app内的活动预加载功能被集成到app开发框架或第三方SDK(例如游戏框架(也称为游戏引擎)或分析SDK)中。这样的app开发框架在本文被称为InAppPreload集成框架。在一些实施例中，这样的集成是通过为这样的框架或SDK提供InAppPreload插件来实现的。在一些实施例中，使用InAppPreload集成框架替换一些或全部InAppPreload API集成步骤(这些步骤在其他方面被app需要，以便利用或更好地利用InAppPreload)。使用InAppPreload集成框架减少或简化了app与InAppPreload API的集成工作。在一些实施例中，InAppPreload API被给予app作为集成框架的一部分。

在一些实施例中，当决定是否预加载app内活动时，代理50考虑预加载活动所需的资源。这样的资源可以包括例如功率消耗、蜂窝数据的使用、存储器、CPU资源、GPU资源或任何其他相关资源。在一些实施例中，代理50例如通过测量预加载期间被消耗的资源来随时间学习该信息。在一些实施例中，app(例如，通过API)至少部分地声明其对这种设备资源的至少一部分的要求。

在一些实施例中，OS 48为app开发人员提供工具，以便模拟app内的活动的预加载。

附加实施例和变型

使用虚拟显示进行预加载

上面关于图3描述了预加载虚拟显示108的概念。在各种实施例中，OS 48的预加载代理50可以以各种方式使用预加载的虚拟显示108来预加载活动。

在一些实施例中，当预加载app或活动时，预加载代理50在预加载的虚拟显示108内创建app或活动。在显示给用户之前，例如，响应于用户进入app，代理50将app或活动转移到常规显示并在那里显示它。在本文，预加载的内容被转移到其的常规显示称为“目标显示”。

在一些实施例中，OS 48仅维护一个常规显示(例如，图3的默认显示104)，其用作为所有预加载app和活动的目标显示。在其他实施例中，OS 48维护多个常规显示。在这样的实施例中，代理50通常基于用户请求的语义来确定目标显示。例如，app或活动可以被转移到常规显示，在常规显示中app或活动通常已经启动而没有预加载。在一些实施例中，在用户请求查看app的内容时，例如，在用户点击app的图标时，app或活动从预加载的虚拟显示被转移到常规显示。

当使用如上所述的前台模拟时，当前台模拟完成时，代理50可以将app或活动从预加载的虚拟显示108转移到常规显示(例如，默认显示104)。在常规显示中，代理50将app或活动置于后台状态，准备稍后由用户使用。

在一些实施例中，OS 48维护用于所有预加载的操作的单个预加载的虚拟显示108。在这样的实施例中，代理50将预加载操作(例如，前台模拟的持续时间，或处于预加载状态的app的整个持续时间)限制为一次一个预加载操作，以避免不同预加载app之间的交叉影响。单个预加载虚拟显示108可以被创建为系统初始化的一部分，或者在第一次请求预加载操作时按需被创建。

在替代实施例中，OS 48针对例如每个预加载的任务堆栈100、每个预加载的app、每个预加载的任务96或每个预加载的活动92创建并维护多个预加载虚拟显示108。在示例实施例中，代理5甚至对于一个预加载操作也可以创建预加载的虚拟显示108，并且在预加载的内容被转移到常规显示之后破坏预加载的虚拟显示。多个预加载的虚拟显示可以并行存在，每个用于不同的预加载操作。这种精细的粒度有助于避免预加载操作对预加载的或以其他方式的其他任务、任务堆栈、app或活动的交叉影响。作为破坏预加载的虚拟显示108的替代方案，预加载的虚拟显示可由代理50缓存在存储器中，用于以后由不同的预加载的操作使用。

在一些实施例中，代理50可以维护预加载的虚拟显示108的池(pool)，这些预加载的虚拟显示108以不同的属性和/或状态创建。在这样的实施例中，代理50在与其期望的目标属性和状态相匹配的预加载的虚拟显示中执行每个预加载操作。例如，代理50可以维护两个预加载的虚拟显示108——一个用于横向取向，另一个用于纵向取向。实施横向方向的app将在前者中被预加载，而可以使用任何取向并期望在纵向中被使用的app将在后者中被预加载。当使用预加载的虚拟显示的池时，可以允许在同一预加载的虚拟显示内同时执行几个预加载操作，因为这些操作共享相同的目标属性和状态。

作为另一示例，当OS使用用户可以在其中启动app的几个可行的常规显示时，每个显示具有其自己的不同属性，代理50可以创建对应的预加载的虚拟显示，该预加载的虚拟显示与处于其预期状态中每个状态的每个常规显示匹配。例如，在虚拟显示例如由于构造或维护成本而受到限制或资源昂贵的情况下，后一实施例是有用的。

如上所述，预加载的虚拟显示108被设计为用于稍后被转移到常规显示的内容的临时占位符。因此，给定的预加载的虚拟显示应该尽可能接近地类似于对应的常规显示(目标显示)。为此，代理50通常设置预加载的虚拟显示以仿真目标常规显示的一些或全部属性，诸如其高度和宽度。

当预加载的虚拟显示的属性被设置为仿真常规显示时，代理50应该指定要仿真哪个常规显示。如上文所定义的，被仿真的常规显示通常被选择为期望app被转移到其上的目标显示。然而，实际上，在许多情况下，只有一个与用户设备的显示屏56相关联的这样的目标显示(例如，图3的默认显示104)。在这些实施例中，任何预加载的虚拟显示108通常仿真默认物理显示9的属性，并因此仿真显示屏56的属性。

在一些实施例中，目标显示包括某些系统装饰物(decoration)——UI元素，诸如状态栏或导航组件。这些装饰物占据了app可用的一些显示区域。预加载的虚拟显示通常应该镜像这些组件，以确保预加载的app被渲染在与目标显示中可用的区域相同的区域上。因此，在一些实施例中，代理50在预加载的虚拟显示中以类似于为对应的目标显示创建装饰物的方式来创建装饰物。在一些实施例中，代理50实际上并不在预加载的虚拟显示内创建装饰物，而是计算并保留装饰物的尺寸，从而相应地减小预加载的虚拟显示中可用的面积。

在一些OS和用户设备中，取向是显示的状态变量。因此，将预加载操作封装到预加载的虚拟显示中允许OS使用不同的取向预加载app，而不影响常规显示，特别是不改变用户正在与其交互的显示的取向。在一些实施例中，代理50通过与app需求协商，以类似于物理显示的方式确定某个预加载的虚拟显示的取向。例如，对于需要横向取向的app，协商使代理50将预加载的虚拟显示的取向改变为横向，而默认显示可以保持为纵向。在其他实施例中，每个预加载的虚拟显示的取向是固定的。

对于可以在几个不同取向中的一个中使用的app，代理50可以基于例如其中期望预加载的内容被使用的取向来确定目标取向。代理50然后可能考虑app的使用历史、物理设备的当前状态和/或其他合适的因素，来将该取向设置为预加载的虚拟显示的取向。

通过使用意图进行预加载

在一些实施例中，OS 48支持使用“意图”和“意图解析”。术语“意图”指的是对将要执行的操作的预先指示。在各种操作中，操作可能是活动的开始。术语“意图解析”指的是处理意图、将意图解析为所需的操作以及可选地执行所需的操作的OS 48的功能。

在一些实施例中，作为OS 48的意图解析的一部分来执行活动的预加载。在这些实施例中，打开活动的意图可以被标记为预加载意图，在这种情况下，要执行的操作是活动的预加载，而不是活动的常规的、非预加载的启动。在这样的实施例中，OS的意图解析功能可以接收常规意图和预加载意图。在一些实施例中，非预加载意图可以包括响应于用户对现有活动的进入而启动活动的意图，该活动可以被预加载或不被预加载。在一些实施例中，如果针对已经预加载的活动接收到非预加载意图，则意图解析功能检测到该事实，并例如，如上所述，在活动/app从预加载状态退出时触发所需的动作。

在一些实施例中，在预加载意图的意图解析期间，OS 48解析要预加载的目标活动，决定是否预加载它，并相应地动作。在一些实施例中，在系统锁定下执行处理预加载意图的至少一部分，从而以原子方式(atomic manner)执行预加载的决策和实际预加载，避免与系统状态的潜在竞争条件。

在一些实施例中，基于诸如系统事件的若干个输入(例如，从最近屏幕上扫除app、使用后退按钮退出app、接收推送通知等)，在先前阶段中执行预加载意图的创建。

在一些实施例中，创建预加载意图和/或根据该意图实际预加载的决定取决于由OS维护的预加载策略。在一些实施例中，OS 48通过使用系统app来维护预加载策略。例如，预加载策略可以由系统app创建，和/或持续存在于该系统app的数据部分中。

在一些实施例中，至少部分地通过考虑由用户app例如通过提供的API设置的配置设置来定义预加载策略。这样的配置可以由app在任何点设置，例如，在app初始化时进行设置。在一些实施例中，至少部分地通过考虑由设备内部算法(例如，通过代理50)和/或由服务器端算法(例如，通过图1的预加载控制单元72)设置的另外的配置设置来定义预加载策略。这样的算法可以包括例如使用模式分析算法、人工智能、机器学习算法等。

根据从网络侧服务器接收的预加载策略预加载

在一些实施例中，OS 48从预加载控制单元72接收预加载策略，并且预加载代理50根据该策略执行各种预加载操作。如上所述，OS可以使用系统app管理预加载策略。OS 48可以不时地例如从预加载控制单元72通过空中下载(over the air)获得预加载策略的更新。在各种实施例中，预加载策略可以指定以下定义和参数，例如：

■预加载哪些app以及何时预加载的规范。

■是否预加载以及预加载哪些app内的内容的规范。

■预加载多少app组件的规范(例如，仅执行某个初始可执行代码，或预渲染app的用户界面，和/或前台模拟的最大持续时间)。

■预加载模式的使用规范，例如，离线预加载和/或在线预加载，例如，如上文引用的PCT申请PCT/IB2020/057046中所述。

■app的“白名单”——限定的app列表。在一些实施例中，OS 48仅允许预加载出现在白名单上的app。在其他实施例中，OS48允许预加载除了已经集成并调用例如经由SDK向app提供的特定API(例如预加载初始化API)的app以外的出现在白名单上的app。

■对所有app和/或特定于某些app的前台模拟的最大持续时间的规范。

例如，在上面引用的美国临时专利申请63/118,068中论述了使用网络侧服务器管理预加载操作的附加方面。

在期望的设备取向上预加载

在一些实施例中，当预加载活动时，OS 48定义用于活动预加载的目标设备取向(例如，纵向或横向)，其可以不同于用户设备24的当前取向。因此，预加载的活动被预渲染，就像用户设备处于目标取向，而其他的设备功能性正常地以实际取向继续工作。该特征允许预加载被充分使用，即使面对取向变化。例如，用户可能正横向观看视频，然后被预测在视频完成后以纵向打开社交app。在这种情况下，OS 48可以以纵向预加载预测的社交app。在一些实施例中，OS基于app的使用模式、目标活动和/或预加载的app支持的取向来选择目标取向。

在一些实施例中，OS可以在多于一个取向上同时维护预加载的活动，并以与在用户进入时用户设备的取向匹配的取向显示该活动。

在一些实施例中，如果预加载的活动的取向与用户进入时用户设备的取向不匹配，则OS 48破坏预加载的活动。在其他实施例中，OS在进入时重新渲染预加载的活动以匹配当前的取向。

在一些实施例中，OS 48可以通过潜在地破坏具有不同取向的预加载的活动，或者重新渲染这种活动以匹配当前的取向来响应用户设备的取向变化。

在多窗口中预加载

在一些实施例中，OS 48允许在多窗口模式(也称为“分屏”模式)期间预加载活动(甚至对于不支持多窗口的app的活动也能进行预加载)。通常，当(例如，由于用户进入)需要启动不支持多窗口的app的活动时，OS检查用户设备当前是否处于多窗口模式。如果是这样，OS可能会显示错误消息或退出多窗口模式。在本发明的一些实施例中，OS 48可以在预加载活动时忽略该检查，并允许活动在后台启动，就像在全屏中一样，同时将用户设备保持在多窗口模式中。

此外，在一些实施例中，OS 48充分利用预加载的活动用于即时显示，即使在多窗口中，而不管这些活动在多窗口期间是否已经被预加载。在一些实施例中，通过将所有预加载的任务保存在至少一个预加载的任务堆栈中，以及当OS需要显示预加载的活动时将预加载的任务重定父级到系统的多窗口的任务堆栈来实现该特征。

用于预加载的活动的内容丰富

在一些实施例中，与在实时的活动加载期间(即，当由于用户请求而不是由于由OS预加载而创建活动时)所获取的正常内容相比，由app获取的要在预加载的活动上渲染的内容可以具有更高的质量(例如，更高清晰度的图像/视频；3D图像而不是2D图像等)。在一些实施例中，通过使app在预加载活动时请求更高质量的内容来实现对内容的这种丰富。

在实施例中，为了决定内容质量，app可以通过使用API，例如上面提到的isPreloaded()方法来检查其活动是否被预加载。

在一些实施例中，通常应用的内容缩减算法在预加载期间被跳过。例如，当获取内容以进行预加载时，跳过例如由内容传送网络(CDN)在服务器侧应用的图像质量降低算法。在一些实施例中，当app执行内容的获取时，由于app的显式请求，在服务器侧上内容质量降低的跳过被覆盖。在一些实施例中，预加载的app可以向服务器指示其具有良好质量的网络连接，而不管实际的网络连接如何，以便在预加载期间允许更高质量的内容。在一些实施例中，预加载的app可以向服务器指示其在预加载期间获取内容，以允许服务器在预加载期间决定期望的内容质量。

在预加载活动时掩蔽不期望的交互

在一些实施例中，当活动被预加载时，并且可能还当活动由于预加载而处于后台状态时，OS 48掩蔽(隐藏)可使用户知道预加载的活动的不期望的交互。在一些实施例中，这种交互的掩蔽包括掩蔽诸如轻量弹框(toast)(在安卓中)和错误消息的弹出消息。

预加载活动时的用户进入

在一些实施例中，如果用户进入当前正被预加载的app/活动，则OS 48停止预加载并重新创建app/活动，就好像它没有被预加载一样(例如，从头开始)。在替代实施例中，OS完成预加载过程，并同时向用户显示预定义屏幕。预加载完成后，OS移除预定义的屏幕并显示预加载的活动，就像用户进入预加载的活动一样。此外，替代地，OS可执行在用户进入预加载的活动(如先前定义的)时所需的所有动作，使预加载的活动对用户可见，并且活动的加载在前台时继续。

CPU繁忙时避免预加载

在一些实施例中，当用户设备CPU太忙时，例如，根据预定义或动态设置的条件，避免预加载。该特征可以有助于增加及时完成预加载的可能性，并因此可有助于不浪费诸如功率和数据的资源(例如，由于如前所述的自动失败定时器限制)。

电池敏感情况下的预加载

在一些实施例中，在功率消耗为敏感的情况下，预加载由OS分配低优先级，或者甚至完全避免预加载。这样的情况可以包括，例如，用户设备电池过低(例如，剩余能量低于预先配置的阈值)、当用户设备进入由OS控制的节电状态(例如，安卓休眠状态)时、当用户设备进入由用户控制的节电状态(例如，安卓电池节省器状态)、或当特定app进入app特定的节点状态(例如，安卓App待机状态)的情况。

相比之下，在一些实施例中，在功率问题没有以往那么严重的情况下，例如，当用户设备连接到外部电源时，OS 48更自由地(例如，更频繁地)触发预加载。

作为节省功率/节电的工具进行预加载

在一些实施例中，所公开的预加载技术被用作节省功率和/或电池资源的措施。这种节省可以通过使用以下示例方案中的任何一个来实现：

■使用预加载以节省浪费的屏幕时间：在该方案中，预加载被用于减少用户设备屏幕在用户等待要加载的内容时消耗的功率。在示例实施例中，OS根据由在正常(非预加载的)启动时的等待时间期间所呈现的屏幕或内容消耗多少功率而给出合适的优选来预加载。

■使用预加载以节省因不良网络条件而消耗的功率：在该方案中，预加载被用于减少由设备联网硬件(诸如蜂窝调制解调器)消耗的功率。在一些实施例中，在预加载期间由于联网引起的预期功率消耗小于某一阈值的情况下，OS给出优选来预加载。例如，在4G或5G覆盖良好的情况下和/或连接到Wi-Fi时，可能优选预加载。在一些实施例中，在预加载策略估计用户将在比现有网络条件差给定阈值的网络条件下使用预加载的app的可能性足够高的情况下，优选预加载。例如，在预加载策略估计app将在3G覆盖的情况下被使用同时当前情况具有良好的Wi-Fi的可能性足够高的情况下，OS可以决定预加载app。

■使用预加载以节省由于app使用的连续性而消耗的功率：在该方案中，OS并发执行预加载(例如，同时预加载多个app/活动)，以减少由于以串行方式正常运行app而造成的功率浪费。预加载操作的这种捆绑增加了诸如蜂窝调制解调器、Wi-Fi通信硬件、CPU和GPU等设备硬件的功率效率。

■在设备未连接到外部电源时，使用预加载以节省由于app使用的功率消耗：在该方案中，当用户设备连接到外部电源时和/或当预加载策略估计当设备未连接到外部电源时app将被使用的可能性足够高时，OS 48给出优选来预加载。

作为允许改进离线体验的工具的预加载

在一些实施例中，所公开的预加载技术被用于向用户提供改进的离线体验。术语“离线体验”指的是当用户设备离线时用户进入或试图使用app的情况(即，例如由于与互联网断开连接而无法经由网络连接到适当的门户28)。例如，改进的离线体验可指在离线体验期间可提供的以下优点：

■允许app显示内容，而不是不显示任何显示。

■允许app显示的内容比它在没有预加载的情况下显示的内容更新。

■允许app显示对用户来说是新的内容，即用户以前没有消费过的内容。

在一些实施例中，在预加载策略估计用户将在用户设备离线时使用预加载的app的可能性足够高的情况下，OS 48给出优选以预加载。

作为节省蜂窝数据的工具的预加载

在一些实施例中，所公开的预加载技术被用作节省蜂窝数据消耗的措施。例如，可以通过在用户设备连接到Wi-Fi时优选预加载来实现这种节省。在一些实施例中，当连接到Wi-Fi时，主要或专门地进行预加载，并且可以在其他情况禁止预加载。在一些实施例中，当设备连接到Wi-Fi时，在预加载策略估计用户在未连接到Wi-Fi时将使用预加载的app的可能性足够高的情况下，优选预加载。

在蜂窝数据敏感情况下进行预加载

在一些实施例中，在蜂窝数据消耗特别敏感的情况下，OS 48对预加载给出低的优选，甚至到避免预加载的情形。这样的情况可以包括，例如，其中用户设备正在漫游的场景；其中用户设备进入由OS控制的蜂窝数据节省状态(例如，安卓休眠状态)的场景；其中用户设备进入由用户控制的蜂窝数据节省状态(例如，安卓的数据节省器状态)的场景；或者其中特定app进入app特定的蜂窝数据节省状态(例如，安卓App待机状态)的场景。

定义用于预加载的蜂窝数据预算

在一些实施例中，OS 48测量由预加载操作所消耗的蜂窝数据。在一些实施例中，由预加载所消耗的所测量的蜂窝数据包括由app在模拟前台状态下其具有活动期间所消耗的数据。在其他实施例中，所测量的数据包括由app在其具有任何预加载的活动期间(在模拟前台状态或在后台中)所消耗的数据。在另外的其他实施例中，所测量的数据包括由app在其具有预加载的特定活动期间(在模拟前台状态或在后台中)所消耗的数据。此外，替代地，所测量的数据包括由app在其具有指定的预加载的“主要活动”(如上文定义的入口点活动)期间(在模拟前台状态或在后台中)所消耗的数据。在一些实施例中，OS分别对作为AppPreload(app预加载)的一部分预加载的活动以及作为InAppPreload(app内活动的预加载)的一部分预加载的活动进行计数。

在一些实施例中，OS维护用于预加载的数据的数据消耗预算。在一些实施例中，OS为所有app一起设置总体数据消耗预算。在其他实施例中，OS为每个app设置单独的数据消耗预算。在一些实施例中，OS维护每给定持续时间的单独的数据消耗预算，例如，每日预算、每周预算、每月预算等。在一些实施例中，基于用户的使用模式来确定持续时间。

在一些实施例中，OS将数据消耗预算设置为预定义的固定参数(例如，10MB)。在一些实施例中，OS将数据消耗预算设置为动态参数。在一些实施例中，基于对app/设备使用模式的学习来设置动态参数。在一些实施例中，给定app在给定时间段内的预算被设置为在给定时间段内估计的用户对该app的使用的函数(例如，线性函数)。

在一些实施例中，在达到某个数据消耗预算时，OS将避免触发影响该某个预加载预算的另外的预加载。例如，在给定app在给定时段和给定功能集(AppPreLoad/InAppPreLoad)的数据消耗预算耗尽的情况下，OS在该给定时段的剩余时间内不触发对给定功能集的进一步预加载。在一些实施例中，OS跟踪已经消耗的数据消耗预算，并调整预加载策略以减少在下一给定时段内消耗预加载预算的机会。

在一些实施例中，预加载数据消耗预算被定义为更广泛的数据消耗预算(诸如用于后台状态的数据消耗预算)的一部分，无论是每个app还是对于整个用户设备的数据消耗预算一部分。

在一些实施例中，当决定是否预加载时，OS考虑app预加载所需的资源。这样的资源可以包括例如功率消耗、蜂窝数据、存储器、CPU、GPU等。在一些实施例中，OS通过测量预加载期间消耗的资源来随时间学习该信息。在一些实施例中，app(例如，通过API)至少部分地声明其对这种用户设备资源的至少一部分的要求。

用户选择退出/选择进入

在一些实施例中，OS 48向用户提供选择退出预加载和/或选择进入预加载的UI选项。在一些实施例中，选择进入/退出仅与AppPreload功能有关(即，OS将不会为已经选择退出AppPreload的用户触发app预加载，反之亦然)。在一些实施例中，选择进入/退出仅与InAppPreload(即，与app内的活动的预加载)有关。在一些实施例中，选择进入/退出与AppPreload和InAppPreload的两个功能有关。

在一些实施例中，选择进入/退出被给出作为某个设置菜单中的选项。该选项可以是显式的，例如，用户可以显式地选择OS是否应该触发相关预加载功能集。在其他实施例中，选择进入/退出是隐式的，例如，使用与预加载不直接有关的UI选项。例如，强制停止app(例如，通过安卓中的设置菜单，或者通过从iOS的最近菜单中扫除app)将导致隐式选择退出预加载，至少直到该app没有处于强制停止的状态。作为另一示例，由用户将用户设备设置为节点状态(例如，安卓电池节省器状态)将导致隐式选择退出预加载，至少直到用户设备已从节电状态退出为止。

App选择退出/选择进入

在一些实施例中，OS 48例如通过API向app提供选择退出和/或选择进入预加载的选项。在一些实施例中，OS为AppPreload和InAppPreLoad两者提供一个用于选择退出和选择进入的API。在其他实施例中，OS提供允许app选择要选择退出/进入AppPreload、InAppPreload或两者的哪个功能的API。当app选择退出预加载功能时，OS不会触发该功能，直到app再次选择进入。

用户发起的预加载触发

到目前为止所描述的实施例中，响应于各种可能的条件和标准，预加载操作通常由OS 48触发。在替代实施例中，OS 48使用户能够显式地请求预加载。在一些实施例中，OS48提供包括用于使用户显式地请求预加载特定app或一组app的选项的UI。预加载代理50响应于使用该UI选项提供的来自用户的显式请求而预加载app或一组app。

在实施例中，OS 48仅针对支持app预加载的app向用户呈现UI选项。在一些实施例中，该选项被给出作为用户设备主屏幕的UI的一部分(在安卓OS中也被称为“启动器”)。在一些实施例中，UI选项让用户通过主屏幕的某个UI方法访问特定app的额外启动选项，例如，通过按压并按住选定的app图标，而额外启动选项包括用于预加载选定的app的显式的选项。

当由于用户的请求而显式地预加载时，代理50例如使用本文所描述的任何预加载技术或使用任何其他合适的预加载技术在后台预加载app。

在一些实施例中，预加载对用户是完全透明的。在其他实施例中，尽管在后台预加载app(而不显示给用户)，但允许预加载操作对用户体验有一些影响，例如，由于使用诸如CPU和音频的用户设备资源。在一些实施例中，OS 48不播放预加载的app的音频，以防止对用户的干扰。部分透明或不透明的这些种类可以被用户接受，因为app是由于他们的显式请求而被预加载的。

在一些实施例中，app支持由用户显式请求的预加载和不是由于用户的请求(例如，由OS触发)而发生的预加载。在一些实施例中，app对这两种预加载利用相同的逻辑。在其他实施例中，app针对用户发起的预加载和非用户发起的(例如，OS发起的)预加载使用不同的逻辑。

在一些实施例中，app不知道由用户显式地请求的预加载。这意味着app在预加载和正常启动时运行相同的逻辑。具体地，在这些实施例中，app不需要集成特定的API来支持预加载。在由用户显式请求的预加载而不是不因用户请求而发生的预加载(例如用户不知道的预加载)的情况下，该功能可能是可接受的。例如，某些app动作，诸如报告用户已经启动app的分析，在用户显式请求的预加载而不是不因用户请求而发生的预加载的情况下被执行可能是合理的，在不因用户请求而发生的预加载的情况下，这样的动作可能不适用。

向用户报告预加载状态

在一些实施例中，OS 48向用户呈现指示预加载的当前进程状态的信息。任何合适的输出都可以用于该目的。例如，OS 48可以向用户呈现随着预加载的进展而逐渐填充的进度条。例如，这样的进度条可以被显示为app图标的一部分或UI中的其他地方显示。

作为另一示例，在完成app的预加载之后，OS 48向用户指示该app准备好要被使用。该指示在本文称为“预加载完成”。OS可以仅针对其预加载是由用户触发的app、仅针对其预加载是由OS触发而没有用户显式请求的app或者针对两者提供预加载完成指示。在一些实施例中，针对其预加载由OS触发(没有用户的显式请求)的app的预加载完成指示不同于为预加载由用户显式触发其预加载的app而提供的预加载完成指示。

在一些实施例中，OS通过UI通知，例如在正常向用户显示通知的OS UI的窗口中提供预加载完成指示。在一些实施例中，通过在启动器上合适地标记app的图标来提供预加载完成指示。

将理解，上述实施例是通过示例的方式引用的，并且本发明不限于已经在上文具体示出和描述的内容。更确切地，本发明的范围包括上文所描述的各种特征的组合及子组合以及本发明的变型和修改，所述变型和修改将在本领域的技术人员阅读上述描述之后被想到并且在现有技术中未被公开。通过引用并入本专利申请中的文件被视为本申请的组成部分，除了任何术语在这些并入的文件中在某种程度上以与本说明书中显式地或隐含地做出的定义冲突的方式被定义之外，应该仅考虑本说明书中的定义。

Claims (64)

1.一种方法，包括：

在运行操作系统(OS)的用户设备中，决定预加载用户应用的至少用户界面(UI)显示；以及

在模拟前台模式中预加载至少所述UI显示，其中所述UI显示(i)由所述用户应用在前台模式中处理，但(ii)由所述OS保持在后台模式中并对所述用户设备的用户隐藏。

2.根据权利要求1所述的方法，

所述方法包括由所述OS维护(i)用于存储非预加载的UI显示的一个或更多个第一数据结构和(ii)用于存储预加载的UI显示的一个或更多个第二数据结构，

其中，预加载所述UI显示包括最初将所述UI显示分配给所述第二数据结构中的一个，以及随后响应于满足标准，将所述UI显示重新分配给所述第一数据结构中的一个。

3.根据权利要求2所述的方法，其中，在决定所述UI显示的预加载成功完成时，或者在用户与所述用户应用交互时，执行所述UI显示到所述第一数据结构中的一个的重新分配。

4.根据权利要求2所述的方法，其中，所述一个或更多个第一数据结构包括非预加载的UI显示的一个或更多个第一堆栈，并且其中，所述一个或更多个第二数据结构包括预加载的UI显示的一个或更多个第二堆栈。

5.根据权利要求2所述的方法，其中，所述一个或更多个第一数据结构包括与非预加载的UI显示相关联的目标显示，并且其中，所述一个或更多个第二数据结构包括与预加载的UI显示相关联的一个或更多个虚拟显示。

6.根据权利要求1-5中任一项所述的方法，其中，预加载所述UI显示包括应用为活动的前台处理指定的所述OS的生命周期事件。

7.根据权利要求1-5中任一项所述的方法，所述方法包括根据完成标准决定所述UI显示的预加载成功完成，并且作为响应，将所述UI显示转换到预加载的后台状态，在所述预加载的后台状态中所述OS和所述用户应用都认为所述UI显示在后台中。

8.根据权利要求7所述的方法，其中，决定预加载成功完成包括检测为所述模拟前台模式设置的最大持续时间的到期。

9.根据权利要求7所述的方法，其中，决定预加载成功完成包括从所述用户应用接收所述预加载成功完成的通知。

10.根据权利要求1-5中任一项所述的方法，所述方法包括响应于检测到在所述模拟前台模式中发生的错误而丢弃预加载的UI显示。

11.根据权利要求1-5中任一项所述的方法，其中，预加载至少所述UI显示包括防止所述预加载影响以下项中的一个或更多个：

所述用户设备的最近列表；

所述用户设备的使用度量；以及

与进入省电状态有关的决策。

12.根据权利要求1-5中任一项所述的方法，其中，预加载至少所述UI显示包括经由应用编程接口(API)通知所述用户应用至少所述UI显示正在被预加载。

13.根据权利要求1-5中任一项所述的方法，其中，预加载至少所述UI显示包括经由应用编程接口(API)通知所述用户应用检测到的与预加载的用户应用的用户交互。

14.根据权利要求1-5中任一项所述的方法，其中，预加载至少所述UI显示包括预加载从所述用户应用的入口点UI显示开始的所述用户应用的至少一部分。

15.根据权利要求14所述的方法，其中，预加载所述用户应用包括根据所述用户应用的启动序列预加载所述入口点UI显示和一个或更多个附加UI显示。

16.根据权利要求14所述的方法，其中，预加载所述用户应用包括仅在验证给定UI显示的调用是预加载发起的而不是用户发起的时预加载所述给定UI显示。

17.根据权利要求14所述的方法，其中，预加载所述用户应用包括通过检测最大定义持续时间的到期来决定所述用户应用的预加载成功完成。

18.根据权利要求14所述的方法，其中，预加载所述用户应用包括通过从所述用户应用接收所述预加载成功完成的通知来决定所述用户应用的预加载成功完成。

19.根据权利要求14所述的方法，其中，预加载所述用户应用排除以下项中的一个或更多个的预加载：

以超过预定义速率的速率改变的内容；以及

其预加载需要通过网络获取的内容。

20.根据权利要求1-5中任一项所述的方法，其中，预加载至少所述UI显示包括预加载一个或更多个app内的UI显示，所述app内的UI显示与所述用户应用相关联，但在启动所述用户应用时不立即显示。

21.根据权利要求20所述的方法，其中，当所述用户应用在前台模式中运行时执行所述app内的UI显示的预加载。

22.根据权利要求20所述的方法，其中，当所述用户应用在后台模式中运行时，执行所述app内的UI显示的预加载。

23.根据权利要求20所述的方法，其中，预加载所述app内的UI显示包括将预加载的app内的UI显示缓存在所述用户设备的存储器中，以及响应于来自所述用户应用的请求提供来自所述存储器的所述预加载的app内的UI显示。

24.根据权利要求23所述的方法，其中，缓存所述app内的UI显示包括给每个app内的UI显示分配相应的到期时间，以及仅响应于验证所述到期时间尚未到期，提供来自所述存储器的所述app内的UI显示。

25.根据权利要求1-5中任一项所述的方法，还包括维护预加载策略，所述预加载策略管理UI显示的预加载。

26.根据权利要求25所述的方法，其中，维护所述预加载策略包括在所述用户设备中运行维护所述预加载策略的系统app。

27.根据权利要求26所述的方法，其中，维护所述预加载策略包括通过所述系统app与网络侧服务器之间的通信来设置所述预加载策略。

28.根据权利要求1-5中任一项所述的方法，其中，预加载至少所述UI显示包括用不同于所述用户设备的当前显示取向的目标取向预加载所述UI显示。

29.根据权利要求28所述的方法，其中，所述目标取向是一取向，预测用户以所述取向访问所述用户应用。

30.根据权利要求1-5中任一项所述的方法，其中，预加载至少所述UI显示包括通过网络获取所述UI显示的内容，所述内容的质量高于用于所述内容的实时获取的质量。

31.根据权利要求1-5中任一项所述的方法，其中，决定预加载至少所述UI显示包括从所述用户接收预加载所述用户应用的显式请求。

32.根据权利要求1-5中任一项所述的方法，所述方法包括向所述用户呈现指示预加载至少所述UI显示的进度的信息。

33.一种用户设备，包括：

显示屏，其被配置成向用户显示用户应用的用户界面(UI)显示；以及

处理器，其被配置成：

运行所述用户设备的操作系统(OS)；

决定预加载用户应用的至少UI显示；以及

在模拟前台模式中预加载至少所述UI显示，其中所述UI显示(i)由所述用户应用在前台模式中处理，但(ii)由所述OS保持在后台模式中并对所述用户设备的用户隐藏。

34.根据权利要求33所述的用户设备，其中，所述处理器被配置成：

由所述OS维护(i)用于存储非预加载的UI显示的一个或更多个第一数据结构和(ii)用于存储预加载的UI显示的一个或更多个第二数据结构，

最初将所述UI显示分配给所述第二数据结构中的一个，并且随后响应于满足标准，将所述UI显示重新分配给所述第一数据结构中的一个。

35.根据权利要求34所述的用户设备，其中，所述处理器被配置成在决定所述UI显示的预加载成功完成时，或者在用户与所述用户应用交互时，将所述UI显示重新分配给所述第一数据结构中的一个。

36.根据权利要求34所述的用户设备，其中，所述一个或更多个第一数据结构包括非预加载的UI显示的一个或更多个第一堆栈，并且其中，所述一个或更多个第二数据结构包括预加载的UI显示的一个或更多个第二堆栈。

37.根据权利要求34所述的用户设备，其中，所述一个或更多个第一数据结构包括与非预加载的UI显示相关联的目标显示，并且其中，所述一个或更多个第二数据结构包括与预加载的UI显示相关联的一个或更多个虚拟显示。

38.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成通过应用为活动的前台处理指定的所述OS的生命周期事件来预加载所述UI显示。

39.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成根据完成标准决定所述UI显示的预加载成功完成，并且作为响应，将所述UI显示转换到预加载的后台状态，在所述预加载的后台状态中所述OS和所述用户应用都认为所述UI显示在后台中。

40.根据权利要求39所述的用户设备，其中，所述处理器被配置成通过检测为所述模拟前台模式设置的最大持续时间的到期来决定预加载成功完成。

41.根据权利要求39所述的用户设备，其中，所述处理器被配置成通过从所述用户应用接收所述预加载成功完成的通知来决定预加载成功完成。

42.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成响应于检测到在所述模拟前台模式中发生的错误而丢弃预加载的UI显示。

43.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成防止所述UI显示的预加载影响以下项中一个或更多个：

所述用户设备的最近列表；

所述用户设备的使用度量；以及

与进入省电状态有关的决策。

44.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成经由应用编程接口(API)通知所述用户应用至少所述UI显示正在被预加载。

45.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成经由应用编程接口(API)通知所述用户应用检测到的与预加载的用户应用的用户交互。

46.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成预加载从所述用户应用的入口点UI显示开始的所述用户应用的至少一部分。

47.根据权利要求46所述的用户设备，其中，所述处理器被配置成通过根据所述用户应用的启动序列预加载所述入口点UI显示和一个或更多个附加UI显示来预加载所述用户应用。

48.根据权利要求46所述的用户设备，其中，所述处理器被配置成仅在验证给定UI显示的调用是预加载发起的而不是用户发起的时预加载所述给定UI显示。

49.根据权利要求46所述的用户设备，其中，所述处理器被配置成通过检测最大定义持续时间的到期来决定所述用户应用的预加载成功完成。

50.根据权利要求46所述的用户设备，其中，所述处理器被配置成通过从所述用户应用接收所述预加载成功完成的通知来决定所述用户应用的预加载成功完成。

51.根据权利要求46所述的用户设备，其中，在预加载所述用户应用时，所述处理器被配置为排除以下项中的一个或更多个的预加载：

以超过预定义速率的速率变化的内容；以及

其预加载需要通过网络获取的内容。

52.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成预加载一个或更多个app内的UI显示，所述app内的UI显示与所述用户应用相关联，但在启动所述用户应用时不立即显示。

53.根据权利要求52所述的用户设备，其中，所述处理器被配置成在所述用户应用以前台模式运行时预加载所述app内的UI显示。

54.根据权利要求52所述的用户设备，其中，所述处理器被配置成在所述用户应用以后台模式运行时预加载所述app内的UI显示。

55.根据权利要求52所述的用户设备，其中，所述处理器被配置成将预加载的app内的UI显示缓存在所述用户设备的存储器中，以及响应于来自所述用户应用的请求提供来自所述存储器的所述预加载的app内的UI显示。

56.根据权利要求55所述的用户设备，其中，所述处理器被配置成为每个缓存的app内的UI显示分配相应的到期时间，以及仅响应于验证所述到期时间尚未到期，提供来自所述存储器的所述app内的UI显示。

57.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置为维护预加载策略，所述预加载策略管理UI显示的预加载。

58.根据权利要求57所述的用户设备，其中，所述处理器被配置成运行维护所述预加载策略的系统app。

59.根据权利要求58所述的用户设备，其中，所述处理器被配置成通过在所述系统app和网络侧服务器之间的通信来设置所述预加载策略。

60.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成以不同于所述用户设备的当前显示取向的目标取向预加载所述UI显示。

61.根据权利要求60所述的用户设备，其中，所述目标取向是一取向，预测所述用户以所述取向访问所述用户应用。

62.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成通过网络获取所述UI显示的内容，所述内容的质量高于用于所述内容的实时获取的质量。

63.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成响应于从所述用户接收到预加载所述用户应用的显式请求而决定预加载至少所述UI显示。

64.根据权利要求33-37中任一项所述的用户设备，其中，所述处理器被配置成向所述用户呈现指示预加载至少所述UI显示的进度的信息。

Images