CN117063156A - 具有准确的用户体验的稳健应用预加载 - Google Patents

Abstract

一种用户设备(24)包括显示屏(56)和一个或更多个处理器(44)。处理器被配置为：运行操作系统(OS‑48)，OS运行用户应用(26)，包括向用户应用发送流，每个流包括随时间被发送到给定用户应用并确定给定用户应用的生命周期的一系列输入；预加载启动用户应用，包括以在显示屏上不可见的后台模式预加载用户应用，以及在用户访问预加载的用户应用时，将用户应用转移到在显示屏上可见的前台模式；以及响应于识别用户应用的预加载启动包括被预定义为不常见流的流，用未被定义为不常见流的一个或更多个替代流替换该流。

Description

具有准确的用户体验的稳健应用预加载

相关申请的交叉引用

本申请要求2021年2月24日提交的美国临时专利申请63/152,878、2021年3月10日提交的美国临时专利申请63/158,914、2021年3月14日提交的美国临时专利申请63/160,836和2021年5月27日提交的美国临时专利申请63/193,644的权益。

本申请也是2020年8月10日提交的美国专利申请16/968,652的部分延续，该美国专利申请是在2019年3月4日提交的PCT申请PCT/IB2019/051707的国家阶段提交的，该PCT申请要求2018年3月5日提交的美国临时专利申请62/638,321和2019年2月5日提交的美国临时专利申请62/801,145的权益。

这些相关申请的公开内容通过引用并入本文。

发明领域

本发明总体上涉及用户设备中的用户应用的处理，且尤其涉及用于预加载应用和内容的方法和系统。

发明背景

在用户设备(诸如智能手机)上运行的应用(“app”)中，影响用户体验的主要因素之一是用户界面(UI)的延迟。已经提出了用于减少延迟并提供更具响应性的UI的各种技术。一些技术涉及内容的预取(prefetch)。其他技术涉及app的后台预加载。另外的其他技术涉及app的UI的预渲染。

发明概述

本文描述的本发明的实施例提供了一种包括显示屏和一个或更多个处理器的用户设备。该一个或更多个处理器被配置为：运行操作系统(OS)，OS运行用户应用，包括向用户应用发送流(flow)，每个流包括随时间被发送到给定用户应用并确定给定用户应用的生命周期的一系列输入；预加载启动(preload-launch)用户应用，包括以在显示屏上不可见的后台模式预加载用户应用，以及在用户访问预加载的用户应用时，将用户应用转移到在显示屏上可见的前台模式；以及响应于识别出用户应用的预加载启动包括被预定义为不常见流的流，用未被定义为不常见流的一个或更多个替代流来替换该流。

在一些实施例中，该一个或更多个处理器被配置为通过识别用户访问在预加载发起的动作之后的预定义时间段内来识别用户应用的预加载启动中的不常见流。在实施例中，预加载发起的动作是预加载用户应用的开始。在所公开的实施例中，该一个或更多个替代流包括将用户应用无声地移动到前端而不触发用户应用的回调的流。

在一些实施例中，该一个或更多个替代流包括以下流序列：启动用户应用的第一流；将用户应用移动到后台模式的第二流；以及在用户进入(user entry)时将用户应用从后台模式移动到前台模式的第三流。

在一些实施例中，该一个或更多个处理器被配置为通过识别用户在以下之一之后访问用户应用来识别用户应用的预加载启动中的不常见流：OS杀死(kill)用户应用的进程；以及OS销毁用户应用的用户界面(UI)显示。在示例实施例中，该一个或更多个处理器被配置为用结束用户应用和用户应用的一个或更多个用户界面(UI)显示的替代流来替换不常见流。在实施例中，响应于识别到不常见流，该一个或更多个处理器被配置为终止用户应用的预加载。

根据本发明的实施例，还提供了一种包括显示屏和一个或更多个处理器的用户设备。该一个或更多个处理器被配置为：在后台模式下预加载一个或更多个用户应用，其中与预加载的用户应用相关联的用户界面(UI)显示在显示屏上是不可见的；检测与给定预加载的用户应用相关联的UI显示的启动；评估该UI显示是否是由于给定用户应用的预加载而调用的预加载发起的UI显示(preload-initiated UI display)，或者评估UI显示是否是由于用户的动作而调用的用户发起的UI显示(user-initiated UI display)；如果该UI显示被评估为预加载发起的UI显示，则使用第一处理方案来处理该UI显示；以及，如果该UI显示被评估为用户发起的UI显示，则使用不同于第一处理方案的第二处理方案来处理该UI显示。

在实施例中，一个或更多个处理器被配置成根据用户是否在预定义的最近时间段内与用户应用交互来评估该UI显示是预加载发起的UI显示还是用户发起的UI显示。

在示例实施例中，用户设备的操作系统(OS)包括根据用户最近是否与用户应用交互来判定是否限制用户应用启动UI显示的逻辑，并且一个或更多个处理器被配置为通过模仿OS的逻辑的至少一部分来评估UI显示是预加载发起的UI显示还是用户发起的UI显示。

在实施例中，该一个或更多个处理器被配置为通过以下方式来评估该UI显示是预加载发起的UI显示还是用户发起的UI显示：评价标准序列，并且当该序列中的给定标准产生该UI显示是预加载发起的UI显示还是用户发起的UI显示的确定的判定时终止该序列。在实施例中，该一个或更多个处理器被配置为响应于确定启动不受用户设备的操作系统(OS)中定义的UI显示启动限制的限制，来判定UI显示是用户发起的UI显示。

在公开的实施例中，该一个或更多个处理器被配置为响应于确定启动是由用户设备中的预加载机制直接执行的，来判定UI显示是预加载发起的UI显示。在示例实施例中，该一个或更多个处理器被配置为：检查启动是否被另一UI显示执行；响应于确定另一UI显示是预加载发起的来判定该UI显示是预加载发起的UI显示；以及，响应于确定该另一UI显示是用户发起的来判定该UI显示是用户发起的UI显示。

在另一实施例中，该一个或更多个处理器被配置为响应于确定启动是由不同于给定用户应用的另一用户应用执行的，来判定UI显示是用户发起的UI显示。在又一实施例中，该一个或更多个处理器被配置为响应于确定给定用户应用不具有预加载的任务来判定UI显示是用户发起的UI显示。在又一个实施例中，该一个或更多个处理器被配置为响应于确定UI显示的目标任务已经存在并且不是预加载的任务来判定UI显示是用户发起的UI显示。

根据本发明的实施例，还提供了一种包括显示屏和一个或更多个处理器的用户设备。该一个或更多个处理器被配置为：以在显示屏上不可见的后台模式预加载用户应用；以及，在用户访问预加载的用户应用时，在显示屏上显示预加载开启窗口，在显示预加载开启窗口时，执行用于准备用户应用以与用户交互的用户进入动作，以及，在用户进入动作完成时，移除预加载开启窗口并使用户能够与用户应用交互。

在一些实施例中，在用户进入动作完成时，一个或更多个处理器被配置为用显示屏上用户应用的顶部用户界面(UI)显示来替换预加载开启窗口。在示例实施例中，该一个或更多个处理器被配置为确定顶部UI界面或用户应用的主题，并使用所确定的主题构建预加载开启窗口。

在实施例中，一个或更多个处理器被配置为在预加载期间获取用户应用的快照映像(snapshot image)，并将该快照映像用作预加载开启窗口。在另一实施例中，该一个或更多个处理器被配置为构建预加载开启窗口，该预加载开启窗口具有与用于非预加载用户应用的开启窗口相同的用户体验。在所公开的实施例中，该一个或更多个处理器被配置为构建预加载开启窗口，该预加载开启窗口具有与在不预加载的情况下启动用户应用时用户会看到的第一用户界面(UI)显示相同的用户体验。

根据本发明的实施例，还提供了一种包括显示屏和一个或更多个处理器的用户设备。该一个或更多个处理器被配置为运行操作系统(OS)，该操作系统：支持多个应用容器，该多个应用容器包括：(i)在显示屏上可见的目标容器和(ii)在显示屏上不可见的一个或更多个虚拟容器；管理目标容器和虚拟容器中的每一个的相应焦点状态(focus state)；通过将应用渲染(rendering)到虚拟容器中的一个虚拟容器来对用户不可见地预加载用户应用，包括管理虚拟容器的焦点状态；以及，在用户访问预加载的用户应用时，将用户应用转移到目标容器，包括管理目标容器的焦点状态。

在实施例中，该一个或更多个处理器被配置为使用用于预加载和非预加载用户应用的相同逻辑来将焦点分配给窗口。在实施例中，该一个或更多个处理器被配置为使用相同的逻辑来将给定窗口定义为没有资格接收焦点，而不管该给定窗口是预加载的还是未预加载的。

根据本发明的实施例，还提供了一种方法，该方法包括在用户设备中运行操作系统(OS)，OS运行用户应用，包括向用户应用发送流，每个流包括随时间被发送到给定用户应用并确定给定用户应用的生命周期的一系列输入。预加载启动用户应用，包括以在用户设备的显示屏上不可见的后台模式预加载用户应用，以及在用户访问预加载的用户应用时，将用户应用转移到在显示屏上可见的前台模式。响应于识别用户应用的预加载启动包括被预定义为不常见流的流，该流用未被定义为不常见流的一个或更多个替代流来替换。

根据本发明的实施例，还提供了一种方法，该方法包括在用户设备中以后台模式预加载一个或更多个用户应用，在后台模式中与预加载的用户应用相关联的用户界面(UI)显示在用户设备的显示屏上是不可见的。检测与给定预加载的用户应用相关联的UI显示的启动。评估UI显示是否是由于给定用户应用的预加载而被调用的预加载发起的UI显示，或者UI显示是否是由于用户的动作而被调用的用户发起的UI显示。如果UI显示被评估为预加载发起的UI显示，则使用第一处理方案来处理UI显示。如果UI显示被评估为用户发起的UI显示，则使用不同于第一处理方案的第二处理方案来处理UI显示。

根据本发明的实施例，还提供了一种方法，该方法包括在用户设备中以在用户设备的显示屏上不可见的后台模式预加载用户应用。当用户访问预加载的用户应用时，在显示屏上显示预加载开启窗口。当显示预加载开启窗口时，执行用户进入动作，以准备用户应用以与用户交互。在用户进入动作完成后，预加载开启窗口被移除并且用户与用户应用的交互被启用。

根据本发明的实施例，还提供了一种方法，该方法包括在用户设备中运行操作系统(OS)，该操作系统：支持多个应用容器，该多个应用容器包括：(i)在显示屏上可见的目标容器和(ii)在显示屏上不可见的一个或更多个虚拟容器；以及，管理目标容器和虚拟容器中的每一个的相应焦点状态。使用OS，通过将应用渲染到虚拟容器中的一个虚拟容器，对用户不可见地预加载用户应用，包括管理虚拟容器的焦点状态。在用户访问预加载的用户应用时，将用户应用转移到目标容器，包括管理目标容器的焦点状态。

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

附图简述

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

图2是根据本发明的实施例示意性地示出了用于预加载和启动应用同时避免不常见流的方法的流程图；

图3是根据本发明的实施例示意性地示出了用于区分预加载发起的和用户发起的UI显示的启动的方法的流程图；

图4是根据本发明的实施例示意性地示出了使用预加载开启窗口来预加载启动应用的方法的流程图；以及

图5是根据本发明的实施例示意性地示出了用于预加载应用中的焦点状态管理的方法的流程图。

具体实施方式

综述和定义

本公开涉及应用(“app”)和诸如用户界面(UI)显示的app组件的预加载。在本上下文中，术语“预加载”是指以用户不注意的后台模式加载、启动和至少部分运行app的过程，而不是响应于来自用户的与app交互的请求进行该过程。可以被预加载的app组件包括例如app的主订阅源(main feed)、app的其他UI显示和/或app内的内容(即在启动app时用户不立即可见的app内容)。app预加载可能涉及例如在后台预渲染app的一个或更多个UI显示。

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

预加载和预渲染的某些方面在以下文献中被提出：2017年9月19日提交的题为“AnOptimized CDN for the Wireless Last Mile”的PCT国际公布WO 2018/055506；2020年8月10日提交的题为“Application Preloading in the Presence of User Actions”的美国专利申请16/968,652；2021年2月10日提交的题为“Preloading of Applications andIn-Application Content in User Devices”的PCT国际公布WO 2021/161174；2020年7月26日提交的题为“Pre-Rendering of Application User-Interfaces in User Devices”的PCT国际公布WO 2021/019415；以及2018年10月21日提交的题为“Audio Inhibition ofApplications in Background Mode,Pre-Loading and Refreshing Thereof”的PCT国际公布WO 2019/082042，以上文献的公开内容通过引用并入本文。

在本上下文中，术语“UI显示”指的是逻辑UI元素——由app使用以与用户实现交互的视图或窗口。例如，在Android操作系统(OS)中，UI显示被称为“视图”或“活动”。举例来说，下面的描述将主要涉及Android OS和活动。活动通常以“任务”进行维护。任务通常包括容器，该容器将用户在执行某个作业时与之交互的活动的记录存储为堆栈。

本文描述的本发明的实施例提供了用于在用户设备中预加载用户应用(“app”)及其内容的改进的方法和系统。一些公开的实施例必须与app的预加载和启动有关，同时避免了不常见的及因此容易出错的流。其他实施例涉及区分预加载发起的和用户发起的UI显示的启动。另外其他实施例必须与在预加载期间生成和显示临时窗口有关。其他公开的实施例涉及基于每个显示的“焦点”状态来管理预加载app的“焦点”状态。

系统描述

图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。本文描述的实施例主要涉及Android OS。然而，所公开的技术适用于可以在用户设备上运行的任何其他合适的OS，例如，iOS、Windows、Linux等。除其他组件外，OS 48包括:(i)被称为存储器管理器49的软件组件，其管理存储器的使用；以及(ii)被称为预加载代理50的软件组件，其处理app的预加载。App 26、OS 48、存储器管理器49和预加载代理50被示意性地绘制在处理器44内部，以指示它们包括在处理器上运行的软件。

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

用户设备24还包括用于向用户呈现视觉内容的显示屏56、以及用于向用户响起音频的音频输出设备58(例如，扬声器和/或头戴式装置输出)。屏幕56和音频输出设备中的每一个也通常被称为用户设备24的“输出设备”。用户设备24还包括用于连接到网络32的合适的网络接口(未在图中示出)。该网络接口可以是有线的(例如，以太网网络接口控制器NIC)或无线的(例如，蜂窝调制解调器或Wi-Fi调制解调器)。用户设备24还包括易失性存储器58，例如随机存取存储器(RAM)，以用于存储app、app组件、数据和/或任何其他合适的信息。

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

网络侧预加载相关的任务可以包括，例如，决定预加载哪些app以及何时预加载，选择是否预加载以及预加载哪些app内的内容，决定预加载多少app组件(例如，仅执行一些初始可执行代码，或者app的用户界面的预渲染和/或关于前台模拟的持续时间的决定)。另一个示例是允许预加载app的“白名单”。在实施例中，预加载服务器60可以被实现为基于云的应用。

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

预加载app 26可以涉及预加载任何app元素，诸如与app相关联的可执行代码，例如启动代码、app馈送、app登陆页面、与app相关联的各种UI元素、与app相关联的内容、与app相关联的app数据、和/或通过诸如点击的用户动作使用app可获得的代码或内容(“app内的内容”)。内容的预渲染可以涉及任何合适类型的UI显示或其一部分的后台处理。例如，在Android术语中，预渲染可以包括一个或更多个Android活动的后台处理。在后台模式中，与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。例如，可通过网络以电子形式将软件下载到处理器，或者软件可以可替代地或附加地被提供和/或存储在非暂时性有形介质上，诸如磁存储器、光学存储器或电子存储器。

通过常见启动流进行的APP预加载

预加载app的挑战之一是遇到不常见流的可能性，如将在下面所定义的。

在本上下文中，术语“流”指的是一系列输入，该一系列输入随着时间从OS被发送到app，并确定app的生命周期。app的启动和随后的生命周期可以涉及各种不同的流，这取决于各种方面，例如大体上相对于app或用户设备执行的用户动作的序列、用户设备和环境的状态以及app中发生的先前事件。

通常，OS 48定义需要app支持的一组“可能的”流。例如，在Android OS中，流OnCreate→OnStart→OnResume被定义为可能的。另一方面，流OnCreate→OnResume→OnStart可能被定义为不可能的。

一些流虽然被定义为可能的，但可能是不常见的，而其他可能的流可能是常见的。在本上下文中，术语“常见流”指的是使用正常用户行为可一致地再现的流。出于同样的原因，不常见流是使用正常的用户行为不能一致地再现的流。通常，不常见流是指正式(formally)要求app支持的流，但在实践中可能不被支持、至少不一致地或不完全被支持，因为它很少在正常情况下出现。

例如，从app的角度来看，依赖于看起来意外或随机的OS操作(如杀死app)的流通常被认为是不常见的。依赖于不合理行为的流(例如经历输入启动→返回主界面(home)→在一秒钟内启动的流)也被认为是不常见的。

在实践中，调用不常见流比调用常见流往往更有可能触发app中的缺陷和次优行为。此外，在不常见流中比在常见流中遇到的缺陷或不当行为往往更严重。这种现象有多种原因。在许多情况下，一组可能的流可能非常大，其中一些流被调用的频率远远高于其他流。时间和资源有限的app开发人员可能会投入处理较常见流，而可能会忽略不常见流。在某些情况下，app开发人员甚至可能没有意识到某些不常见流的存在。此外，不常见流可能更难在受控的测试环境中再现。不常见流通常也很少或没有从用户接收到反馈。

一个简单的实现方式将使用任何合适的流预加载app，而不管给定的流是常见的还是不常见的。然而，鉴于上述情况，非常期望的是app的预加载将最大限度地利用常见流，且旨在避免不常见流。否则，一些app可能无法正确预加载，并可能崩溃或行为不当。

在本发明的一些实施例中，预加载代理50以最小化对不常见流的使用的方式控制预加载过程以及对app的用户输入的后续处理。

以下描述将涉及app的“预加载启动”和“预加载启动范围”(Preload LaunchScope，PLS)。这些术语在本文可互换使用，它们指的是以下完整过程：(i)在后台模式下预加载app，包括根据需要预取内容和预渲染UI显示；以及(ii)处理用户对预加载的app的后续访问，包括将app转移到前台模式。

在一些实施例中，一个或更多个流被定义为不常见流。当预加载app时，如果预加载代理50识别出预加载启动过程包括被定义为不常见流的流，则预加载代理用未被定义为不常见流的一个或更多个替代流来替换该流。在其他实施例中，代理50被预编程以用一个或更多个常见流替换不常见流。

在一些实施例中，预加载代理不允许对不常见流的任何使用。例如，如果不可能使用常见流在PLS中执行某个动作，则预加载代理可以完全终止预加载启动过程。在其他实施例中，预加载代理减少了对不常见流的使用，但没有完全消除它们。

例如，考虑以下一组常见的启动流：

1.例如，通过单击app启动器，从头开始启动app。

2.将app的现有任务从后台移动到前台。

3.将app的任务从前台移到后台。

在示例场景中，在预加载完成之后，代理50将预加载的app移动到后台。这种情况下的PLS可以使用三个常见流来实现：

a)预加载app(通过调用上面的流1)。

b)在预加载完成后，将app移到后台(通过调用上面的流3)。

c)在用户进入时，将后台预加载的app移动到前台(通过调用上面的流2)。

避免由于连续的预加载发起的和用户发起的启动而导致的不常见流

考虑其中代理50开始预加载app并且用户在此后不久(例如，预加载开始后一秒钟)进入app的场景。在这种情况下，传统的预加载技术可以强制app处理包括两个紧密间隔的请求的不常见流以启动app，其中，第二请求发生在app已经在前台的时候。当第二请求到达时，app可能处于其加载的初始阶段，例如在其“启动画面(splash screen)”阶段，并且此时可能不期望另一个请求。在常规使用期间，人类用户极不可能发出两个这样的快速请求。在预加载中，这种事件的发生是相当可行的。

这种场景下的常规PLS包括以下两个流，第二个流是不常见的：

1.从头开始启动app。

2.启动一个已经在前台的现有app，其可能处于加载的初始阶段。

注意，预加载操作和用户进入都可以通过意图来实现，就像在Android OS中一样，导致两个快速请求(意图)以启动app。

在多种实施例中，代理50可以以各种方式修改PLS以仅包括常见流。在一个示例中，如果用户在预加载开始后快速进入，代理50将把app移动到后台，并且然后立即移动到前台。

注意，在这种情况下，在用户进入时首先将app移动到后台可能是次优的，例如，因为这将在用户等待时导致延迟和/或导致视听故障或其他不期望的伪像。

因此，在一些实施例中，如果用户在预加载开始之后快速进入，则代理50将用无声操作来替换第二启动请求，以将app移动到前端，而不触发任何app回调。这种解决方案绕过了不常见流，且提高了性能，因为app中发生的事件更少。

注意，通常，在常规使用中，用无声的移动到前端来替换启动请求会被认为是OS的无效行为。在这个特定的情况中，这样的替换是正确的，因为以前的启动发生在最近，且因此正如预期的那样，用户仍然会看到单个的、最近的启动的结果。如果“用户访问”是一个启动app的动作，其参数与预加载操作模拟的正常启动相同，则上述技术背后的基本原理成立。在一些实施例中，代理50可以验证参数确实相同(例如，通过验证用户启动app的意图与用于预加载app的意图具有相同的参数)。

上述场景展示了与预加载相关的许多不常见流中的一个共同点：当用户在预加载相关动作之后不超过预定义的时间段内访问app时，可能会发生不常见流。当用户访问在预加载相关动作之后太接近地(在不超过预定义时间段内)发生时，代理50可以修改PLS以消除不常见流。在本上下文中，术语“用户访问”指的是与app的各种用户交互，例如，点击app启动器图标本身、点击与app相关联的通知等。

可以以各种方式定义预加载相关动作(例如，预加载的开启)和随后的用户访问之间的允许时间段(用常见流替换不常见流是正确的时间段)。在一些实施例中，代理50以两个阶段预加载app，这两个阶段称为“前台模拟”(FS)和“预加载的后台”(PB)。这些过程，包括从FS转换到PB的各种标准，在上面引用的题为“Preloading of Applications and In-Application Content in User Device”的PCT国际公布WO 2021/161174中被提出。在这样的实施例中，如果用户在前台模拟阶段访问app，代理50声明不常见流，并修改PLS以替换不常见流。如果用户在app已经转换到预加载的后台阶段之后访问app，则代理50保留现有的PLS。

在一些实施例中，如果用户在离预加载开始后限定的短间隔内访问app，代理50声明不常见流。该间隔通常独立于其他超时(如前台模拟超时(如果存在的话))进行配置。例如，前台模拟超时可以被设置为60秒，而允许的间隔(低于该间隔不常见流被替换)被设置为5秒。可替代地，可以使用任何其他合适的值。

在一些实施例中，代理50根据用户进入时app的加载进度，例如，根据app是否已经达到某个状态，来判定是否声明不常见流。例如，在一个实施例中，在用户进入时，如果app还没有启动其启动序列中的最后一个活动，或者如果app仍处于其“启动画面”阶段，代理50就声明不常见流。

在一些实施例中，在识别出用户已经在预加载开始后不久访问了app(使用上述任何标准或任何其他合适的标准)，代理50终止了预加载操作，并且然后恢复正常启动app(即，如同其没有被预加载)。

在一些实施例中，预加载的终止可以涉及清除(例如，结束)预加载的任务和/或杀死预加载的app的进程。在本上下文中，术语“清除”和“结束”可互换使用，并意味着(i)销毁预加载的任务的活动和(ii)从存储器中移除被销毁的活动的记录。在这些实施例中，修改后的PLS包括从头启动app的单个常见流。

在启动序列期间避免由于杀死和恢复app活动而导致的不常见流

对于不常见流的另外的一个示例，请考虑以下场景：

1.开始预加载app。

2.预加载的进程很快被OS杀死，和/或某个活动被OS销毁(但不是由于被app结束)。

3.用户访问app。

在这种场景下，不常见流包括恢复在加载的初始阶段(例如，在其“启动画面”阶段)被杀死的app(或活动)。在正常使用中(即不涉及预加载)，鉴于OS不太可能在前台加载app时杀死app，用户很难或甚至不可能导致这样的流。另一方面，在预加载的情况下，app的进程可能优先级较低，且因此随着条件的变化，可能不得不被OS杀死。

因此，在一些实施例中，一旦预加载的app的进程被杀死，或者预加载的app被OS销毁(但不是由于被app结束)，代理50清除(例如，结束)相关联的app及其活动。在一些实施例中，只要检测到对app的杀死/销毁，代理50就清除app及其活动。在一些实施例中，代理50在从前台模拟阶段转换到预加载的后台阶段时清除app及其活动。

在一些实施例中，代理50在对app的下一个用户进入时清除app及其活动，使得如果需要的话，首先执行清除，然后系统才执行对用户进入请求的常规处理。以这种方式，对用户进入的处理将被正常执行，并且处于app没有任何现有活动和活动记录的情况下。

在一些实施例中，如果app的进程在离预加载开始后的限定的短间隔内被杀死，则代理50清除app及其活动。这里，间隔通常也独立于其他超时(例如前台模拟超时(如果存在的话))进行配置。例如，前台模拟超时可以被设置为60秒，而由于app的进程被杀死，被允许清除的间隔被设置为5秒。然而，可替代地，可以使用任何其他合适的值。

在一些实施例中，代理50根据app被杀死时其加载进度，例如，根据app在用户进入时是否已经达到某个状态，来判定是否清除app及其活动。例如，如果在用户进入时，app尚未启动其启动序列中的最后一个活动，或者如果app仍处于其“启动画面”阶段，则可以执行清除。

图2是根据本发明的实施例示意性地示出了用于预加载和启动应用同时避免不常见流的方法的流程图。该方法开始于流定义阶段80，在该流定义阶段80中代理50将一个或更多个可能的流定义为常见的，并且将一个或更多个其他的流定义为可能的但不常见的。在触发阶段84，代理50判定预加载某个app 26。在发起阶段88，代理50开始app的预加载启动。

在不常见流检查阶段92，代理50检查到目前为止在预加载启动期间是否发生了不常见流。如果没有，代理50在预加载启动阶段100继续预加载启动过程。如果已经检测到不常见流，则代理50在PLS修改阶段96用一个或更多个常见流替换不常见流，且然后进行到阶段100。

在存在基于最近与app交互的用户动作情况下的app预加载

在后台或在前台运行用户设备24中的app，无论是预加载的还是用户发起的，通常涉及由处理器44启动一个或更多个UI显示。下面的描述将参考Android活动，作为UI显示的非限制性示例。活动的示例包括app的主活动、“闪屏(Splash)”屏幕(在加载或准备主活动时显示的初始屏幕)、在屏幕之间转换时显示的间隙广告、由用户点击来自app门户的通知触发的屏幕或任何其他合适类型的活动。

在一些实际场景中，当一个或更多个预加载发起的活动正在处理器44上运行时，可以调用用户发起的活动。类似地，当一个或更多个用户发起的活动正在处理器44上运行时，可以调用预加载发起的活动。当一个或更多个其他预加载发起的活动正在运行时，也可以调用预加载发起的活动。

例如，考虑一个正在后台运行的预加载的app。作为运行预加载的app的一部分，预加载代理50可以例如调用加载app的启动活动(Splash activity)。启动活动可以调用app的主活动，例如登陆页面，并且主活动可以调用间隙广告活动。作为另一示例，预加载代理50可以直接调用主活动，该主活动又调用间隙广告活动。所有这些活动都是预加载发起的活动。

当一个或更多个这样的预加载发起的活动正在运行时，用户设备24的用户可以例如点击相同app的与预加载操作无关的通知窗口。通知可以例如来自门户28。该用户动作可以调用相同app的与预加载无关的一个或更多个用户发起的活动。例如，用户点击可能会在单独的活动中打开app中的一些内容项目。作为另一示例，用户可以点击app的小部件，这触发与预加载无关的app活动的创建。作为又一示例，用户可以从另一app内进入所讨论的app，以便再次调用与预加载无关的app活动。

以上场景纯粹通过示例的方式来描述，以展示处理器44可能需要如何同时处理相同app的预加载发起的活动和用户发起的活动。本文描述的技术可应用于这些示例场景和任何其他合适的场景中。

在一些实施例中，为了适当地处理各种活动，区分预加载发起的活动和用户发起的活动(也分别称为“预加载激活的”活动和“用户激活的”活动)是重要的。然而，在实践中，预加载代理50并不总是能够或直接获得两种活动类型之间的明确区别。在某些情况下，app本身可能也没有这些信息，或者可能无法直接获得这种信息。在某些情况下，确定区别是复杂的，因为app能够使用其自己的操作代码来启动活动(而且经常这样做)。此外，app通常可以被允许在它们不在前台时运行代码。

在本发明的一些实施例中，预加载代理50使用各种测试或标准(这两个术语在本文可互换地使用)来评估新调用的活动是预加载发起的还是用户发起的。根据评估的不同，预加载代理会以不同的方式处理活动。

为了清楚起见，下面的描述将代理50称为使用所公开的技术来区分预加载发起的活动和用户发起的活动的实体。然而，在替代实施例中，这种评估或区分可以由运行在处理器44中的任何其他合适的软件来执行，例如由app本身来执行。

区分预加载发起的活动和用户发起的活动的另外的方面在上面引用的题为“Application Preloading in the Presence of User Actions”的美国专利申请16/968,652中被提出。在一些实施例中，除了上述专利申请中描述的一个或更多个标准之外，或者与上述专利申请中描述的一个或更多个标准相结合，可以评价本文描述的一个或更多个标准。

在一些实施例中，代理50根据用户最近(例如，在预定义的最近时间段期间)是否与app交互来判定app的某个活动是预加载发起的还是用户发起的。如果用户最近与app交互，代理50得出结论，该活动最有可能是用户发起的。如果用户最近没有与app交互，代理50得出结论，该活动很可能是预加载发起的。

图3是根据本发明的实施例示意性地示出了用于区分预加载发起的和用户发起的UI显示的启动的方法的流程图。该方法开始于标准定义阶段110，定义用于区分用户发起的活动和预加载发起的活动的标准序列(也称为“测试”)。通常，序列中的每个测试能够返回三个可能的结果：(i)活动启动是用户发起的，(ii)活动启动是预加载发起的，以及(iii)不确定。标准序列通常在预加载代理50中被预定义和编程。

在启动识别阶段114，代理50识别新活动的启动。响应于识别活动启动，代理50开始评价序列中的标准。

在标准评价阶段118，代理50针对新启动的活动评价来自序列的标准。在结果检查阶段122，代理50检查测试结果是否是确定的，并且如果是确定的，则活动启动是被评估为用户发起的还是预加载发起的。

如果测试结果指示活动启动是用户发起的，则代理50在用户发起的处理阶段126将活动作为用户发起的活动来处理。如果测试结果指示活动启动是预加载发起的，则代理50在预加载发起处理阶段130将活动作为预加载发起的活动来处理。

如果测试结果是不确定的，代理50前进到序列中的下一个标准(如果存在的话)。在完成检查阶段134，代理50检查序列中的所有标准是否已经被评价。如果不是，该方法循环回到上面的阶段118，用于评价序列中的下一个标准。

如果整个序列已经被详尽地评价，则在默认处理阶段138，代理50返回到使用针对不确定的情况定义的默认方案来处理活动。默认方案可以与用户发起的处理方案(阶段126的方案)相同，与预加载发起的处理方案(阶段130的方案)相同，或者与这两个方案不同。

在多种实施例中，代理50可以评价各种测试序列。一些测试可能依赖于OS 48实施的“活动启动限制”。在一些OS中，如Android 10OS，“活动启动限制”意味着OS根据各种情况标准，且特别是根据用户当前是否期望看到app的活动，来限制app在前台启动活动的能力。例如，如果用户当前没有与app交互，则OS可能会禁止该app在前台启动活动。

一个非限制性示例测试序列如下：

1.检查活动是否由预加载机制直接启动的测试。如果是，则该活动被视为预加载发起的。例如，预加载机制可能会启动app的进入点活动(有时称为启动器活动或启动画面)。

2.检查活动是否从另一个活动启动的测试。例如，在Android OS中，可以通过检查启动请求的上下文是否是活动来确定该属性。如果启动源自另一个活动，则基于该其他活动(“调用活动”)的预加载状态来确定启动类型(用户发起的或预加载发起的)。如果调用活动是预加载的，则当前启动被视为预加载发起的。如果调用活动是非预加载的，则启动将被视为用户发起的。在其他情况，例如，如果启动请求不是来自另一个活动，则测试结果被设置为“不确定”。

3.检查启动是否由一个app代表另一个app执行的测试。如果是，则确定启动是由用户发起的。例如，当点击系统通知并直接启动活动时，或者当用户通过系统快捷方式启动app时，可能会发生这种情况。在Android OS中，可以通过比较启动请求中涉及的两个调用用户Id(UID)来检测这种情况。

4.检查调用方app(请求活动启动的app)是否有预加载的任务的测试。如果不是，则确定启动是用户发起的(假设一个app在前一个app的启动序列期间通常不启动另一个app的活动)。

5.检查目标任务(启动的活动所属的任务)是否是预加载的任务(如果这样的任务在启动之前已经存在)的测试。如果不是，则确定启动是用户发起的。

6.检查活动启动是否被确定为受到OS 48的活动启动限制的测试。如果不受限制，则确定启动是用户发起的。

在上述测试#6中，启动的限制可基于例如以下任一项：

代理50可以检查与启动相关联的OS状态，例如指示“该启动被限制”的标志。

代理50可以全部或部分地执行相同的逻辑(“模仿”该逻辑)，OS通常使用该逻辑来确定启动是否受到限制。例如，代理50可以仅执行与用户动作直接相关的逻辑部分，例如检查用户最近是否与app的元素交互，而不执行检查app是否具有允许app绕过限制的特殊权限的逻辑部分。

在为该app发起当前预加载之后，并且在离当前时间的短时间间隔内，代理50可以检查该app是否启动了OS认为不受限制的先前用户发起的活动。如果是，启动被认为是不受限制的。作为此检查的动机，请考虑以下场景：

a.app具有预加载的任务。

b.app以不受限制启动打开了一个单独的非预加载的任务。此时，该app具有两个任务。注意，此时预加载的任务可能保持预加载状态。

c.在很短的时间间隔内，app会在预加载的任务中打开一个附加活动。此时，代理50可以使用最近的不受限制启动的信息来将该启动也视为不受限制的。

在一些实施例中，时间间隔是固定的，例如几秒钟。在一些实施例中，当OS在用户激活的启动之后具有“宽限期(grace period)”时(在此期间它忽略app的活动启动限制)，可以基于宽限期来选择时间间隔，例如与宽限期相同。

在一些实施例中，序列中标准的顺序被设置成使得最有可能产生确定的结果的测试首先出现。在示例实施例中，上面的测试#2被放置在序列中的第一位，使得后续测试仅用于与调用者活动无关的启动。可替代地，可以设置任何其他合适的顺序。

在对预加载的app进行用户进入时使用临时开启窗口

当用户例如通过点击用户设备24的启动器屏幕中的app图标来进入预加载的app26时，app的顶部活动(或者更一般地，顶部UI显示)必须在其可以被显示给用户之前恢复。尽管顶部活动可能已经部分或甚至完全被预加载，但是app可能需要额外的时间来完全准备顶部活动以供显示，例如，处理正在恢复的顶部活动的相关活动生命周期事件。因此，除非采取适当的措施，否则显示屏56将不显示由于用户点击而引起的任何活动，直到顶部活动完全被恢复。这个时间间隔很可能导致用户很容易注意到的不期望的响应延迟。

在本发明的一些实施例中，从用户点击进入预加载的app的那一刻开始，直到显示app顶部活动为止，OS 48(通常是预加载代理50)在屏幕56上显示临时窗口，在本文称为“预加载开启窗口”。预加载开启窗口通常包括静态显示，该静态显示可以由OS以最小的努力(且因此快速)呈现，其桥接从用户点击到预加载的app顶部活动被恢复并且可以被显示为止的可能的延迟。当顶部活动被恢复并且可以被显示时，OS 48从屏幕56移除预加载开启窗口并且代替地显示顶部活动。

在一些实施例中，OS 48基于app主题，即，根据app的一般外观和样式，构建预加载开启窗口的图形。在一些实施例中，OS 48基于正在被恢复的顶部活动的主题，即，根据顶部活动的一般外观和样式，构建预加载开启窗口的图形。例如，在Android OS中，app的主题和/或顶部活动是可以被查询并被用于预加载开启窗口的现有的属性。

在一些实施例中，在预加载过程期间，OS 48构建正在被预加载的app的快照映像，并使用该快照映像作为预加载开启窗口。在一些实施例中，如上所述，当从前台模拟(FS)阶段转换到预加载后台(PB)阶段时，OS构建快照映像。可替代地，OS可以在任何其他合适的时间获取快照映像。

在一些实施例中，在用户进入正常启动(非预加载的)的app时，OS呈现临时窗口。例如，在Android OS中，这个临时窗口有时被称为“开启窗口”。在一些实施例中，OS 48以保留用于正常启动app的临时窗口的用户体验的方式构建和呈现预加载开启窗口。

在其中预加载开启窗口基于活动主题的实施例中，保留(如用于非预加载的app的)正常临时窗口的用户体验的目的引入了选择预加载开启窗口基于哪个活动的问题。

如果选择了(在预加载之后)进入活动，则当进入预加载的app时，该活动可以是例如app的“主”活动，而不是当app通常从头启动时进入的通常活动(例如，“启动”活动)。在这种情况下，预加载开启窗口将基于不同于用于从头启动的通常活动(即，在没有预加载的情况下的活动)的活动。此外，在Android OS中，当用户通常启动之前的后台app时，OS在大多数情况下会显示一个快照映像作为临时窗口。然而，在某些情况下，使用快照映像作为预加载开启窗口是不可能的或不期望的。

因此，如果OS基于正在进入的活动构建预加载开启窗口(就像简单的解决方案(solution)可能做的那样)，预加载中临时窗口的用户体验可能与通常的、非预加载启动的用户体验显著不同。这种不同是有问题的，例如，因为app开发人员投入较少的精力来确保非初始活动(除了启动之外的活动)的临时窗口的高质量用户体验，因为用户获得基于这些活动的临时窗口的体验被认为是不常见的。

为了克服上述问题，在一些实施例中，OS 48基于用户在没有预加载app的情况下从头开始启动时会看到的第一活动来构建预加载开启窗口。这个活动(或者更一般地，UI显示)在本文被称为第一查看的活动(FVA)。在一些实施例中，OS 48基于FVA构建预加载开启窗口的图形。在一些实施例中，FVA是通常由app创建的第一不透明活动。在一些实施例中，FVA是app在预加载期间创建的第一个不透明活动。

在一些实施例中，OS 48在预加载过程期间保存FVA的开启窗口用户体验数据(例如，图形)，并且在用户进入预加载的app时使用它来合成相同的开启窗口体验。

图4是根据本发明的实施例示意性地示出使用预加载开启窗口来预加载启动应用的方法的流程图。该方法由OS 48执行，通常但不一定由预加载代理50执行。该方法开始于OS 48在预加载阶段140开启预加载某个app 26。在FVA启动阶段142，代理50在后台启动app的启动活动(FVA)。在保存阶段144，代理50将启动活动的开启窗口数据保存在代理50的存储器中。在主活动启动阶段146，代理50启动app的主活动。在启动结束阶段148，代理50结束启动活动。在预加载结束阶段150，代理50终结预加载操作。

在某个时间点，在用户进入阶段152，用户访问app 26。当检测到用户进入时，代理50基于在上述阶段144保存的数据，在开启窗口显示阶段154，在屏幕56上生成并显示预加载开启窗口。在顶部活动显示阶段156，代理50显示app的主活动。在这个阶段，app已经为用户交互做好了准备。

基于每个容器(例如，每个显示)焦点管理预加载的app的焦点

在一些OS(例如Android)中，app 26的状态的一部分是其“焦点”状态。在预加载期间正确处理焦点状态有助于完整准确地预加载app，同时最大限度地减少每个app的集成工作。在一些OS中，Android 11就是一个示例，OS包括app容器，如Android的显示，每个容器都有“焦点”状态。

在下面描述的一些实施例中，预加载代理50基于由OS定义的现有每个容器的“焦点”来预加载app，同时为预加载的app和所有其他app保持适当的“焦点”状态。在本文描述的实施例中，基本的“焦点单元”(为其定义焦点的app内的实体)是窗口。然而，可替代地，所公开的技术可以与任何其他合适的焦点单元一起使用，例如整个app。

下面的描述主要是指每个显示的焦点，例如每个容器焦点。然而，这样的选择仅仅是为了清楚起见。所公开的技术不限于显示，并且可以与任何其他合适类型的容器一起使用。

在一些实施例中，OS支持多个显示。OS为每个显示定义了一个“聚焦窗口”(聚焦的窗口)。显示的聚焦窗口displayId被表示为perDisplayFocusedWindow(displayId)。当聚焦窗口从显示A转移到显示B时，首先在显示B内处理窗口焦点，然后将窗口设置为perDisplayFocusedWindow(B)，以及然后在显示A中处理窗口焦点——删除窗口perDisplayFocusedWindow(A)。OS通常还为每个窗口维护一个“焦点”状态。窗口的焦点状态windowId被表示为isWindowInFocus(windowId)。例如，这种状态可以通过获得或失去焦点的事件发送到窗口或app。

在一些实施例中，当预加载app时，预加载代理50模拟对预加载的app的窗口的焦点状态管理，就如同它们被正常启动一样。

在实施例中，当预加载app时，预加载代理50执行与app正常启动时相同的焦点决策逻辑。例如，代理50可以确保被标记为“不可聚焦”的窗口(即，当正常启动时没有资格接收焦点的窗口)将没有资格接收焦点，即使当其属于预加载的app时。

在一些实施例中，被OS支持的多个显示包括“默认显示”(也称为目标显示——链接到被用户看到的物理显示屏56的显示)和一个或更多个“虚拟显示”(它们是逻辑结构，例如容器，对用户不可见，但能够渲染窗口)。代理50在虚拟显示中渲染预加载的app，这被称为“预加载显示”。使用虚拟显示的预加载的另外的方面在上面引用的PCT国际公布WO2021/161174中被提出了。

在一些实施例中，在预加载app时，代理50将该app定义为有资格在预加载显示中接收焦点，例如通过考虑该app可见且可聚焦。因此，在预加载操作开始时，perDisplayFocusedWindow(preloadDisplay)将由代理50设置为预加载窗口，并且窗口的isWindowInFocus将由代理50设置为“真”。

在一些实施例中，在预加载操作的前台模拟阶段完成之后，代理50移除窗口接收焦点的资格，例如通过认为该app是不可见的和/或不可聚焦的。因此，代理50将perDisplayFocusedWindow(preloadDisplay)设置为none(例如，空/空值)，并将窗口的isWindowInFocus设置为“假”。

在一些实施例中，在将预加载的app转移到目标显示(通常是物理显示，用于用户对内容的消费)时，基于转移时的前台模拟状态来管理焦点状态：

如果预加载的app不处于前台模拟状态，而是处于预加载后台状态，OS将正常处理焦点——按预期改变状态。例如，如果app被带到前台，app的窗口将接收焦点，目标显示中的先前前台app将失去焦点，并且perDisplayFocusedWindow(targetDisplay)将被设置为先前预加载的窗口。

如果预加载的app处于前台模拟状态，则该app被视为聚焦。在一些实施例中，app的焦点状态在预加载的显示内被改变为非聚焦，且然后app被转移到目标显示，并且其状态被改变为聚焦。在一些实施例中，app将不会接收焦点丢失消息，并且将从目标显示接收另一个焦点获得消息。为此，在预加载显示内发送焦点丢失消息之前，OS检查窗口是否已经被标记为perDisplayFocusedWindow(targetDisplay)。如果是这样，OS将跳过发送焦点丢失消息。在一些实施例中，app此时将不会接收任何额外的焦点消息，并且将保持聚焦。为此，除了可能避免如上所述的焦点丢失消息之外，在目标显示内发送焦点获得消息之前，对于任何预加载显示，OS检查窗口是否已经被标记为perDisplayFocusedWindow，且如果是，则跳过发送焦点获得消息。

图5是根据本发明的实施例示意性地示出了用于预加载应用中的焦点状态管理的方法的流程图。该方法开始于触发阶段160，预加载代理50决定预加载某个app 26。在预加载阶段164，代理50在虚拟显示(也称为预加载显示)中预加载app。

在预加载显示中预加载app时，代理50执行各种动作，例如预渲染app的一个或更多个窗口。在执行这些动作时，代理50执行用于app的正常预加载的相同焦点状态管理逻辑。该逻辑尤其包括定义每个显示的焦点状态，在该示例中，定义其中预加载app的预加载显示的焦点状态。

在稍后的某个时间点，用户在用户进入阶段168访问app。在检测到用户进入时，代理50在转移阶段172将app转移到默认显示(也称为目标显示)以显示给用户。焦点管理根据目标显示中的相同逻辑继续。

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

Claims (54)

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

显示屏；以及

一个或更多个处理器，所述一个或更多个处理器被配置为：

运行操作系统(OS)，所述操作系统运行用户应用，包括向所述用户应用发送流，每个流包括随时间发送到给定用户应用并确定所述给定用户应用的生命周期的一系列输入；

预加载启动用户应用，包括以在所述显示屏上不可见的后台模式预加载所述用户应用，以及在用户访问所预加载的用户应用时，将所述用户应用转移到在所述显示屏上可见的前台模式；以及

响应于识别所述用户应用的预加载启动包括被预定义为不常见流的流，用未被定义为不常见流的一个或更多个替代流替换该流。

2.根据权利要求1所述的用户设备，其中，所述一个或更多个处理器被配置为通过识别所述用户访问在预加载发起的动作之后的预定义时间段内来识别所述用户应用的预加载启动中的所述不常见流。

3.根据权利要求2所述的用户设备，其中，所述预加载发起的动作是预加载所述用户应用的开始。

4.根据权利要求2所述的用户设备，其中，所述一个或更多个替代流包括将所述用户应用无声地移动到前端而不触发对所述用户应用的回调的流。

5.根据权利要求1所述的用户设备，其中，所述一个或更多个替代流包括以下流的序列：

第一流，所述第一流启动所述用户应用；

第二流，所述第二流将所述用户应用移动到所述后台模式；以及

第三流，所述第三流在用户进入时将所述用户应用从所述后台模式移动到前台模式。

6.根据权利要求1所述的用户设备，其中，所述一个或更多个处理器被配置成通过识别所述用户在以下之一之后访问所述用户应用来识别所述用户应用的预加载启动中的所述不常见流：

所述OS杀死所述用户应用的进程；以及

所述OS销毁所述用户应用的用户界面(UI)显示。

7.根据权利要求6所述的用户设备，其中，所述一个或更多个处理器被配置成用结束所述用户应用和所述用户应用的一个或更多个用户界面(UI)显示的替代流来替换所述不常见流。

8.根据权利要求1所述的用户设备，其中，响应于识别到所述不常见流，所述一个或更多个处理器被配置为终止所述用户应用的预加载。

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

显示屏；以及

一个或更多个处理器，所述一个或更多个处理器被配置为：

在后台模式下预加载一个或更多个用户应用，其中与预加载的用户应用相关联的用户界面(UI)显示在所述显示屏上是不可见的；

检测与给定预加载的用户应用相关联的UI显示的启动；

评估所述UI显示是否是由于所述给定用户应用的预加载而被调用的预加载发起的UI显示，或者所述UI显示是否是由于所述用户的动作而被调用的用户发起的UI显示；

如果所述UI显示被评估为预加载发起的UI显示，则使用第一处理方案来处理所述UI显示；以及

如果所述UI显示被评估为用户发起的UI显示，则使用不同于所述第一处理方案的第二处理方案来处理所述UI显示。

10.根据权利要求9所述的用户设备，其中，所述一个或更多个处理器被配置为根据所述用户在预定义的最近时间段期间是否已经与所述用户应用交互来评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示。

11.根据权利要求9所述的用户设备，其中：

所述用户设备的操作系统(OS)包括根据所述用户最近是否与所述用户应用交互来判定是否限制由所述用户应用对UI显示的启动的逻辑；以及

其中，所述一个或更多个处理器被配置为通过模仿所述OS的逻辑的至少一部分来评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示。

12.根据权利要求9-11中任一项所述的用户设备，其中，所述一个或更多个处理器被配置为通过以下方式来评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示：评价标准序列，并且当所述序列中的给定标准产生所述UI显示是预加载发起的UI显示还是用户发起的UI显示的确定的判定时终止所述序列。

13.根据权利要求9-11中任一项所述的用户设备，其中，所述一个或更多个处理器被配置为响应于确定所述启动不受在所述用户设备的操作系统(OS)中定义的UI显示启动限制的限制而判定所述UI显示是用户发起的UI显示。

14.根据权利要求9-11中任一项所述的用户设备，其中，所述一个或更多个处理器被配置为响应于确定所述启动是由所述用户设备中的预加载机制直接执行的，来判定所述UI显示是预加载发起的UI显示。

15.根据权利要求9-11中任一项所述的用户设备，其中，所述一个或更多个处理器被配置为：

检查所述启动是否是由另一个UI显示执行的；

响应于确定另一个UI显示是预加载发起的，判定所述UI显示是预加载发起的UI显示；以及

响应于确定另一个UI显示是用户发起的，确定所述UI显示是用户发起的UI显示。

16.根据权利要求9-11中任一项所述的用户设备，其中，所述一个或更多个处理器被配置为响应于确定所述启动是由不同于所述给定用户应用的另一用户应用执行的来判定所述UI显示是用户发起的UI显示。

17.根据权利要求9-11中任一项所述的用户设备，其中，所述一个或更多个处理器被配置为响应于确定所述给定用户应用不具有预加载的任务来判定所述UI显示是用户发起的UI显示。

18.根据权利要求9-11中任一项所述的用户设备，其中，所述一个或更多个处理器被配置为响应于确定所述UI显示的目标任务已经存在并且不是预加载的任务来判定所述UI显示是用户发起的UI显示。

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

显示屏；以及

一个或更多个处理器，所述一个或更多个处理器被配置为：

以在所述显示屏上不可见的后台模式预加载用户应用；以及

当用户访问所预加载的用户应用时：

在所述显示屏上显示预加载开启窗口；

当所述预加载开启窗口被显示时，执行用户进入动作以准备所述用户应用以与所述用户交互；以及

在完成所述用户进入动作后，移除所述预加载开启窗口并使所述用户能够与所述用户应用交互。

20.根据权利要求19所述的用户设备，其中，在完成所述用户进入动作时，所述一个或更多个处理器被配置为用所述用户应用在所述显示屏上的顶部用户界面(UI)显示来替换所述预加载开启窗口。

21.根据权利要求20所述的用户设备，其中，所述一个或更多个处理器被配置为确定所述顶部UI界面或所述用户应用的主题，并使用所确定的主题构建所述预加载开启窗口。

22.根据权利要求19所述的用户设备，其中，所述一个或更多个处理器被配置为在预加载期间获取所述用户应用的快照映像，并且将所述快照映像用作所述预加载开启窗口。

23.根据权利要求19所述的用户设备，其中，所述一个或更多个处理器被配置为构建具有与用于非预加载的用户应用的开启窗口相同的用户体验的所述预加载开启窗口。

24.根据权利要求19所述的用户设备，其中，所述一个或更多个处理器被配置为构建所述预加载开启窗口，所述预加载开启窗口具有与所述用户在不预加载的情况下启动所述用户应用时会看到的第一用户界面(UI)显示相同的用户体验。

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

显示屏；以及

一个或更多个处理器，所述一个或更多个处理器被配置为运行操作系统(OS)，所述操作系统：

支持多个应用容器，所述应用容器包括(i)在所述显示屏上可见的目标容器和(ii)在所述显示屏上不可见的一个或更多个虚拟容器；

管理所述目标容器和所述虚拟容器中的每一个容器的相应焦点状态；

通过将用户应用渲染到所述虚拟容器中的一个虚拟容器，对用户不可见地预加载所述应用，包括管理所述虚拟容器的焦点状态；以及

在用户访问所预加载的用户应用时，将所述用户应用转移到所述目标容器，包括管理所述目标容器的焦点状态。

26.根据权利要求25所述的用户设备，其中，所述一个或更多个处理器被配置为使用用于预加载的和非预加载的用户应用的相同逻辑来将焦点分配给窗口。

27.根据权利要求25所述的用户设备，其中，所述一个或更多个处理器被配置为使用相同的逻辑将给定窗口定义为没有资格接收焦点，而不管所述给定窗口是预加载的还是非预加载的。

28.一种方法，包括：

在用户设备中，运行操作系统(OS)，所述操作系统运行用户应用，包括向所述用户应用发送流，每个流包括一系列输入，所述一系列输入随时间被发送到给定用户应用并确定所述给定用户应用的生命周期；

预加载启动用户应用，包括以在所述用户设备的显示屏上不可见的后台模式预加载所述用户应用，以及在用户访问所预加载的用户应用时，将所述用户应用转移到在所述显示屏上可见的前台模式；以及

响应于识别所述用户应用的预加载启动包括被预定义为不常见流的流，用未被定义为不常见流的一个或更多个替代流替换该流。

29.根据权利要求29所述的方法，其中，识别所述不常见流包括识别所述用户访问在预加载发起的动作之后的预定义时间段内。

30.根据权利要求29所述的方法，其中，所述预加载发起的动作是预加载所述用户应用的开始。

31.根据权利要求29所述的方法，其中，所述一个或更多个替代流包括将所述用户应用无声地移动到前端而不触发所述用户应用的回调的流。

32.根据权利要求28所述的方法，其中，所述一个或更多个替代流包括以下流的序列：

第一流，所述第一流启动所述用户应用；

第二流，所述第二流将所述用户应用移动到所述后台模式；以及

第三流，所述第三流在用户进入时将所述用户应用从所述后台模式移动到前台模式。

33.根据权利要求28所述的方法，其中，识别所述不常见流包括识别所述用户在以下之一之后访问所述用户应用：

所述OS杀死所述用户应用的进程；以及

所述OS销毁所述用户应用的用户界面(UI)显示。

34.根据权利要求33所述的方法，其中，替换所述不常见流包括用结束所述用户应用和所述用户应用的一个或更多个用户界面(UI)显示的替代流替换所述不常见流。

35.根据权利要求28所述的方法，其中，替换所述流包括响应于识别所述不常见流而终止对所述用户应用的预加载。

36.一种方法，包括：

在用户设备中，以后台模式预加载一个或更多个用户应用，其中与预加载的用户应用相关联的用户界面(UI)显示在所述用户设备的显示屏上是不可见的；

检测与给定预加载的用户应用相关联的UI显示的启动；

评估所述UI显示是否是由于所述给定用户应用的预加载而被调用的预加载发起的UI显示，或者所述UI显示是否是由于所述用户的动作而被调用的用户发起的UI显示；

如果所述UI显示被评估为预加载发起的UI显示，则使用第一处理方案来处理所述UI显示；以及

如果所述UI显示被评估为用户发起的UI显示，则使用不同于所述第一处理方案的第二处理方案来处理所述UI显示。

37.根据权利要求36所述的方法，其中，评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示取决于所述用户是否已经在预定义的最近时间段期间与所述用户应用交互来执行。

38.根据权利要求36所述的方法，其中：

所述用户设备的操作系统(OS)包括根据所述用户最近是否与所述用户应用交互来判定是否限制由所述用户应用对UI显示的启动的逻辑；以及

其中，评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示包括模仿所述OS的逻辑的至少一部分。

39.根据权利要求36-38中任一项所述的方法，其中，评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示包括：评价标准序列，并且当所述序列中的给定标准产生所述UI显示是预加载发起的UI显示还是用户发起的UI显示的确定的判定时终止所述序列。

40.根据权利要求36-38中任一项所述的方法，其中，评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示包括响应于确定所述启动不受在所述用户设备的操作系统(OS)中定义的UI显示启动限制的限制而判定所述UI显示是用户发起的UI显示。

41.根据权利要求36-38中任一项所述的方法，其中，评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示包括响应于确定所述启动是由所述用户设备中的预加载机制直接执行的，来判定所述UI显示是预加载发起的UI显示。

42.根据权利要求36-38中任一项所述的方法，其中，评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示包括：

检查所述启动是否是由另一个UI显示执行的；

响应于确定另一个UI显示是预加载发起的，确定所述UI显示是预加载发起的UI显示；以及

响应于确定另一个UI显示是用户发起的，确定所述UI显示是用户发起的UI显示。

43.根据权利要求36-38中任一项所述的方法，其中，评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示包括响应于确定所述启动是由不同于所述给定用户应用的另一用户应用执行的来判定所述UI显示是用户发起的UI显示。

44.根据权利要求36-38中任一项所述的方法，其中，评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示包括响应于确定所述给定用户应用不具有预加载的任务来判定所述UI显示是用户发起的UI显示。

45.根据权利要求36-38中任一项所述的方法，其中，评估所述UI显示是预加载发起的UI显示还是用户发起的UI显示包括响应于确定所述UI显示的目标任务已经存在并且不是预加载任务来判定所述UI显示是用户发起的UI显示。

46.一种方法，包括：

在用户设备中，以在所述用户设备的显示屏上不可见的后台模式预加载用户应用；以及

当用户访问所预加载的用户应用时：

在所述显示屏上显示预加载开启窗口；

在显示所述预加载开启窗口时，执行用户进入动作以准备所述用户应用以与所述用户交互；以及

在完成所述用户进入动作后，移除所述预加载开启窗口并使所述用户能够与所述用户应用交互。

47.根据权利要求46所述的方法，其中，移除所述预加载开启窗口包括用所述用户应用在所述显示屏上的顶部用户界面(UI)显示来替换所述预加载开启窗口。

48.根据权利要求47所述的方法，包括确定所述顶部UI界面或所述用户应用的主题，以及使用所确定的主题构建所述预加载开启窗口。

49.根据权利要求46所述的方法，包括在预加载期间获取所述用户应用的快照映像，以及使用所述快照映像作为所述预加载开启窗口。

50.根据权利要求46所述的方法，包括构建具有与用于非预加载的用户应用的开启窗口相同的用户体验的所述预加载开启窗口。

51.根据权利要求46所述的方法，包括构建所述预加载开启窗口，所述预加载开启窗口具有与所述用户在不预加载的情况下启动所述用户应用时会看到的第一用户界面(UI)显示相同的用户体验。

52.一种方法，包括：

在用户设备中，运行操作系统(OS)，所述操作系统：

支持多个应用容器，所述应用容器包括(i)在所述显示屏上可见的目标容器和(ii)在所述显示屏上不可见的一个或更多个虚拟容器；以及

管理所述目标容器和所述虚拟容器中的每一个容器的相应焦点状态；

使用所述OS，通过将用户应用渲染到所述虚拟容器中的一个虚拟容器，对用户不可见地预加载所述应用，包括管理所述虚拟容器的焦点状态；以及

在用户访问所预加载的用户应用时，将所述用户应用转移到所述目标容器，包括管理所述目标容器的焦点状态。

53.根据权利要求52所述的方法，其中，管理所述焦点状态包括使用用于预加载的和非预加载的用户应用的相同逻辑将焦点分配给窗口。

54.根据权利要求52所述的方法，其中，管理所述焦点状态包括使用相同逻辑将给定窗口定义为没有资格接收焦点，而不管所述给定窗口是预加载的还是非预加载的。