本申请是2016年8月12日提交的美国专利申请编号15/235,859的pct国际申请，其要求2015年12月31日提交的美国临时申请编号62/274,155以及2015年11月6日提交的美国临时申请编号62/252,367的优先权。以上引用的申请的全部公开内容通过引用并入本文。
本公开总体来说涉及移动应用开发，并且更具体地涉及到移动应用的特定状态的深度链接。
背景技术：
本部分提供与本公开相关的背景信息，其不一定是现有技术。
应用(在本公开中可互换地被称为“应用程序”)(诸如移动应用)可以包括多个深度状态。例如，在基于社交媒体观点数据对餐厅质量进行评级的应用中，每家餐厅的详细页面都将被视为深度状态。可以通过一系列用户操作从应用内达到深度状态，这些用户动作能够通过多个菜单画面(或视图)以及选择用户界面元素来涉及浏览。这些菜单画面和用户界面元素中的每一个都可以由与所显示的画面相关联的唯一视图控制器来介导。
通常，这些深度状态只能从应用本身内部访问。在应用之外运行的网络搜索引擎例如无法达到应用内的深度状态。这意味着，当用户对餐厅进行传统的网络搜索并想要在专门的餐厅评级应用中浏览所返回的选择之一时，用户将不得不将所选择的搜索结果的名称手动复制并粘贴到餐厅评级应用的搜索字段中并命令餐厅排名应用以访问其与所选择的餐厅对应的内部深度状态。这需要大量的用户交互。
如果应用的深度状态可以暴露给外部应用和计算机进程，则用户可以享受增强的功能，例如，能够使用基于互联网的搜索服务器开始搜索合适的餐厅，然后搜索结果中的一个会自动导向到专门的餐厅排名应用的适当的深度链接页面。
然而，实现这样的功能需要开发者的努力，并且需要开发者可能并不具备的深度链接专业知识。当应用开发受到时间、预算或专业知识的限制时，应用的某些甚至全部状态的深度链接功能可能不能优先实现。
在图1中，对假设应用程序100示出了各种视图的图形表示。应用程序100包括视图a104-1、视图b104-2以及视图c104-3(统称为视图104)。在各种实施方式中，视图104可以由一个或更多个视图控制器来管理，该视图控制器可以根据模型-视图-控制器(mvc)软件体系结构模式来开发。
在图1的示例中，在a处的用户动作调用视图a104-1。例如，视图a104-1可以为缺省状态，因此调用应用程序100将首先导向视图a104-1。在b处的用户动作转换到视图b104-2。在c处的用户动作转换到视图c104-3。在d处的用户动作从视图c104-3返回到视图b104-2。可以认为视图a104-1和视图b104-2是深度状态，在调用应用程序100之后经由一个或更多个用户动作是可获得的。
仅作为示例，应用程序100可以是餐厅评论应用程序，其中针对视图a104-1，缺省状态是具有允许用户搜索餐厅的文本搜索框的搜索状态。视图a104-1也可能包括固定查询，如按特定菜肴搜索和按特定位置搜索。响应于用户在视图a104-1(在b处的用户活动)中执行搜索而显示的视图b104-2可以是搜索引擎结果页面，其显示符合搜索标准的餐厅列表以及关于每家餐厅的选择信息。
如果用户选择视图b104-2中的一个结果(在c处的用户动作)，则视图c104-3显示所选择的结果的信息。视图控制器(未示出)可以从模板来实例化视图c104-3，该模板包括用于显示餐厅的名称、餐厅的代表性图片和餐厅的评论的用户界面以及用于执行诸如在餐厅预订餐桌、撰写评论之类的动作的用户界面元素。该模板可以用来自所选择的餐厅的数据存储器的餐厅信息来填充。用户可以从视图c104-3返回到视图b104-2(在d处的用户动作)以选择另一结果。
应用程序100可以不包括用于任何内部请求或外部请求(诸如来自浏览器或来自操作系统的搜索功能)的机制，以直接获得视图b104-2。换句话说，深度链接不适用于视图b104-2或视图c104-3。此外，即使开发者已经实现内部深度链接以允许应用程序100直接访问视图b104-2或视图c104-3，应用程序100也可能未公开该深度链接能力，从而深度链接指令能够从外部源提交到应用程序100。
技术实现要素：
移动应用开发系统包括开发者门户，所述开发者门户被配置为：从第一开发者接收第一应用的副本；以及在所述第一开发者经由数字发布平台发布所述第一应用之前，将路由库提供给所述第一开发者以并入所述第一应用中。所述移动应用开发系统包括离线分析系统，所述离线分析系统被配置为运行所述第一应用，并且在运行期间监视由操作者所启动的用户界面(ui)事件序列，该ui事件序列从初始状态开始并进行到第一状态。所述离线分析系统将所述ui事件序列存储为与所述第一状态对应的第一数据结构。所述路由库包括在安装用户设备中的所述第一应用的副本之后执行以下操作的指令：从标识了所述第一状态的用户设备的操作系统接收链接，并且基于与所述第一状态对应的所述第一数据结构，按顺序将所述ui事件序列中的每个ui事件重放至第一应用。
在其他特征中，通过并入所述路由库，所述第一应用被配置为向所述操作系统注册第一统一资源标识符(uri)模板。在其他特征中，第一uri模板是包括以冒号和两个正斜杠结尾的文本字符串的唯一方案。在其他特征中，文本字符串是与所述开发者门户相关联的文本标识符和所述第一应用的名称的串联。
在其他特征中，所述链接选择性地包括序列化数据。所述路由库包括从所述链接内的序列化数据解码出所述第一数据结构的指令。在其他特征中，第一数据结构被格式化为用base64编码的json(javascript对象表示法)。在其他特征中，所述链接选择性地包括唯一标识符。所述路由库包括基于所述唯一标识符来检索所述第一数据结构的指令。在其他特征中，所述移动应用开发系统包括数据服务器，所述数据服务器被配置为存储由所述离线分析系统确定的所述第一数据结构。所述路由库包括响应于所述链接使用所述唯一标识符来查询所述数据服务器的指令。所述数据服务器以所述第一数据结构来响应所述查询。
在其他特征中，所述移动应用开发系统包括数据服务器，所述数据服务器被配置为存储由包括所述第一数据结构的所述离线分析系统确定的多个数据结构。所述路由库包括在所述第一应用首次运行时，从所述数据服务器下载所述多个数据结构中的至少一个，以存储在所述路由库本地的数据存储器中的指令。所述路由库包括响应于所述唯一标识符从所述数据存储器中检索所述第一数据结构的指令。在其他特征中，所述开发者门户被配置为从所述第一开发者接收所述第一应用的调试版本。
一种系统，包括：上述移动应用开发系统；以及搜索系统，所述搜索系统被配置为响应于所述用户设备委托的搜索，将结果返回给所述用户设备。返回的结果中的第一结果包括所述链接。响应于所述用户设备的用户对所述第一结果的选择，由操作系统将所述连接发送到所述路由库。
一种对移动应用开发系统进行操作的方法包括：从第一开发者接收第一应用的副本。所述方法包括在所述第一开发者经由数字发布平台发布所述第一应用之前，将路由库提供给所述第一开发者以并入所述第一应用中。所述方法包括在处理系统上运行所述第一应用，并且在运行期间监视由操作者启动的用户界面(ui)事件序列，该ui事件序列从初始状态开始并进行到第一状态。所述方法包括将所述ui事件序列存储为与所述第一状态对应的第一数据结构。所述路由库包括在将所述第一应用的副本安装在与所述移动应用开发系统不同的用户设备中之后执行如下操作的指令：从标识了所述第一状态的所述用户设备的操作系统接收链接，并基于与所述第一状态对应的所述第一数据结构，按顺序将所述ui事件序列中的每个ui事件重放至所述第一应用。
在其他特征中，通过并入所述路由库，所述第一应用被配置为向所述操作系统注册第一统一资源标识符(uri)模板。所述第一uri模板是包括以冒号和两个正斜杠结尾的文本字符串的唯一方案。所述文本字符串是与所述移动应用开发系统和所述第一应用的名称相关联的文本标识符的串联。在其他特征中，所述链接选择性地包含序列化数据。所述路由库包括从所述链接内的所述序列化数据解码出所述第一数据结构的指令。在其他特征中，所述链接选择性地包括唯一标识符。所述路由库包括基于所述唯一标识符从所述移动应用开发系统检索所述第一数据结构的指令。
在其他特征中，所述方法包括将所述第一数据结构存储在所述移动应用开发系统的数据存储器中。所述路由库包括响应于所述链接，使用所述唯一标识符来查询所述数据服务器的指令。所述方法包括根据所述唯一标识符通过在所述数据存储器中查找所述第一数据结构来响应所述查询。
在其他特征中，所述方法包括：将包括所述第一数据结构的多个数据结构存储在所述移动应用开发系统的数据存储器中。所述路由库包括在所述第一应用首次运行时，从所述移动应用开发系统下载所述多个数据结构中的至少一个，以存储在所述用户设备本地的数据存储器中的指令。所述路由库包括响应于所述唯一标识符，从所述用户设备本地的所述数据存储器中检索所述第一数据结构。
在其它特征中，接收所述第一应用的所述副本包括从所述第一开发者接收所述第一应用的调试版本，以在所述处理系统上运行。在其他特征中，所述方法包括接收由所述用户设备委托的搜索，以及响应于所述搜索，识别并向所述用户设备返回结果。识别出的结果中的第一结果包括所述链接。
非暂时性计算机可读介质存储指令，所述指令包括：从第一开发者接收第一应用的副本。所述指令包括在所述第一开发者经由数字发布平台发布所述第一应用之前，将路由库提供给所述第一开发者以并入所述第一应用中。所述指令包括在处理系统上运行所述第一应用，并且在运行期间监视由操作者启动的用户界面(ui)事件序列，该ui事件序列从初始状态开始并进行到第一状态。所述指令包括将所述ui事件序列存储为与所述第一状态对应的第一数据结构。所述路由库包括在与所述处理系统不同的用户设备中安装所述第一应用的副本之后执行如下操作的指令：从标识了所述第一状态的所述用户设备的操作系统接收链接，并且基于与所述第一状态对应的所述第一数据结构，按顺序将所述ui事件序列中的每个ui事件重放至所述第一应用。
根据详细描述、权利要求书和附图，本公开的其他应用领域将变得显而易见。详细描述和具体示例仅用于说明的目的，并不意图限制本公开的范围。
附图说明
根据详细描述和附图，将更加充分地理解本公开。
图1是在示例应用程序中的视图之间用户所启动的转换的图形表示。
图2是根据本公开的原理的移动应用环境的高级功能框图。
图3a是路由库的示例实施方式的功能框图。
图3b是路由库的另一示例实施方式的功能框图。
图4是离线分析系统的示例实施方式的功能框图。
图5是根据本公开的原理的移动应用生态系统的示例总体操作的流程图。
图6是根据本公开的原理的深度链接创建和提供给用户设备的示例操作的流程图。
图7是作为离线分析的一部分的应用程序的指南创建的示例操作的流程图。
图8是识别作为离线分析的一部分的另外的感兴趣状态的示例推断的流程图。
图9是开发者的应用程序内的示例路由操作的流程图。
图10是根据示例格式的示例统一资源标识符的图形表示。
在附图中，可以再次使用附图标记来标识相似和/或相同的元素。
具体实施方式
介绍
对于没有时间、资源或专业知识来实现用于其应用程序的状态的更多子集的深度链接功能的开发者来说，本公开描述了开发者如何能够以最小的努力来增强他们的应用程序。具体而言，根据本公开的原理的开发者门户向应用程序开发者提供了用于并入开发者的应用程序中的路由库。
该路由库可以被称为动态链接库(dll)、dylib或软件开发工具包(sdk)。可以将路由库提供给开发者的集成开发环境(ide)，如xcode。在某些实施方式中，开发者只需将路由库与开发中的应用程序相关联，并且不需要对应用程序或应用程序的代码进行其他修改。在其他实施方式中，开发者也可能不得不执行修改配置文件的步骤，诸如通过将与路由库对应的行添加到开发中的应用的信息属性列表(info.plist)文件中。
同时，开发者门户将该应用程序提供给离线分析系统，该离线分析系统确定如何访问感兴趣的状态。感兴趣的状态可以由应用程序开发者指定或由开发者门户确定。简言之，开发者门户的离线分析系统确定为达到感兴趣的状态用户将采取什么样的用户界面(ui)动作序列。该ui动作序列能够由用户设备上的应用程序内的路由库重放，以达到感兴趣的状态。换句话说，路由库模拟用户自己为达到深度状态而执行的用户界面动作。
通过模拟ui动作，路由库消除了用户的需要以执行每个ui动作，并且通常比用户手动执行ui动作序列快得多。当路由库导航到感兴趣的深度状态时，用户可能甚至不会看到一些中间状态，或者这些中间状态可能仅简单可见。然而，具有长的或复杂的ui序列的一些状态可能比当用户(特别是有经验的用户)在导航应用程序时需要更多时间，从而达到使用路由库的目的。
应用程序的深度状态的ui动作序列可以与路由库一起集成到应用程序中，或者一旦安装应用程序，就可以由路由库下载。在一些实施方式中，ui动作序列能够被编码为链接或uri(统一资源标识符)的一部分，该链接或uri指定应用程序并由路由库提供服务。
无需开发者的进一步努力，应用程序现在具有可以从外部源访问的深度链接功能。例如，搜索系统可以提供直接导向应用程序深度状态的结果。或者第三方应用程序可以轻松地将用户引导至应用程序的深度状态。这可能会增加应用程序的可见性，并允许与应用程序更紧密的整合以及更好的整体用户体验。
此外，既然开发者门户负责深度链接，则无需请求软件程序员的协助就能够添加或修改深度链接，该软件程序员可能正在处理其他项目并具有其他优先处理的事。换句话说，商业人士(诸如为应用程序开发者工作的广告或营销专业人员)可以使用开发者门户来确定应用程序的哪些状态应当是深度链接的。商业人士甚至可以从深度链接状态列表中删除所有无需软件程序员的协助的状态。
概述
在图2中，提供了另外的细节。如上所述，开发者204向开发者门户208提供了应用程序(称为“appa”)。开发者门户208向开发者204提供了路由库的副本以并入appa中，这创建了增强版本的appa。
开发者204向数字发布平台212提供了增强的appa(为简单起见仍称之为appa)以发布给最终的用户。数字发布平台212向用户设备提供本地应用程序，并且可以专用于操作系统。示例数字发布平台包括谷歌公司的googleplay数字发布平台、苹果公司的appstore数字发布平台以及微软公司的windowsphone数字发布平台。如果开发者204在appa由路由库增强之前已将该appa提供给数字发布平台212，则开发者204能够将增强的appa作为appa的新版本来发布。
用户设备220的用户从数字发布平台212安装appa。在用户设备220中，一个或更多个处理器(其可以包括通用处理器以及另外的协处理器，诸如物理传感器处理器和图形处理器)执行来自存储器的指令。
这些指令中的一些对应于操作系统224、浏览器228和所安装的appa的副本232(称为appa232)。操作系统224包括所安装的应用程序注册表240和链接处理程序244。链接处理程序244接收诸如url(统一资源定位符)和uri(统一资源标识符)之类的链接，并确定如何处理这些链接。
通常，链接处理程序244通过将链接转发给已注册的接收器来处理链接。链接处理程序244检查所安装的应用程序注册表240，以确定应用程序是否声明了与该链接相匹配的特定方案、域或其他滤波器。如果不是，则链接可以被传递给浏览器228，该浏览器可能已经注册了诸如http(超文本传输协议)、https(http安全)、ftp(文件传输协议)、telnet和gopher之类的协议的一组方案。
路由库260使得appa232向所安装的应用程序注册表240注册特定的方案或域。该方案可以基于开发者门户208的标识符以及appa的标识符。例如，与开发者门户208(诸如“portal”)相关联的测试字符串可以与对应于appa的文本字符串(诸如“appa”)级联。作为特定示例，由appa232注册的方案可以是“portal-appa://”。在其他实施方式中，与开发者门户208相关联的文本字符串可能不是人类可读的。
当链接处理程序244接收到其中方案匹配“portal-appa://”的链接(诸如来自浏览器228)时，链接处理程序244将该链接转发到应用程序a232，其中链接由路由库260进行接收和处理。路由库260解析链接并导航到由链接所指示的深度状态。
仅为了说明，在图2中，示出了视图a268-1、视图b268-2和视图c268-3(统称为视图268)。在许多应用程序中，将出现超过三个视图。在各种实施方式中，可以由单个视图控制器来控制多个或全部视图。在其他实施方式中，可以由单独的视图控制器来控制每个视图。
仅为了说明，路由库260被示出为模拟来自由示例链接所标识的预定ui事件序列的事件。链接由路由库260接收并且对应于深度状态，具体而言是视图c2683。ui事件序列包括：第一ui事件，其使得appa232从视图a268-1转变为视图b268-2；第二ui事件，其中appa保留在视图b2682；第三ui事件，其使得appa232从视图b268-2转变为视图c268-3。路由库260以串行方式模拟这些ui事件。
从开发者门户208向开发者204并行地提供路由库，开发者门户208将appa提供给离线分析系统280。提供给开发者门户208的appa的副本可以是标准发布版本，诸如iosappstore包(ipa文件)。
在其他实施方式中，提供给开发者门户208的appa的副本可以是允许appa在模拟器中运行的特殊版本，并且可以包括符号、调试信息和/或源代码，这通常不会出现在由数字发布平台212发布的应用程序中。这可以允许离线分析系统280更高效或准确地分析appa。例如，appa的副本可以是被设计为在osx操作系统上的apple公司的模拟器应用中运行的调试版本。与之相比，由数字发布平台212发布的appa的版本是标准发布版本。
如下面更详细所描述的，离线分析系统280确定ui事件序列，该ui事件序列能够由路由库260使用以获得appa232的特定视图。ui事件序列可以被称为面包屑路径，该面包屑路径由各个面包屑(即ui事件)的有序序列组成。为了简单起见，在本公开的其余部分中，术语面包屑将被用于指面包屑路径。
离线分析系统280可以将所确定的面包屑提供给数据服务器282。数据服务器282包括数据存储器(诸如关系数据库、分类图或键值存储器)，该数据存储器存储由离线分析系统280所处理的每个应用程序的面包屑。应用程序的每个深度状态都与相应的面包屑相关联。在一些实施方式中，数据服务器282可以被实现为基于云的块存储服务，诸如从亚马逊网络服务可获得的s3(简单存储服务)服务。
访问机制定义了为了诸如显示广告和深度搜索结果之类的目的能够达到多深的状态。例如，搜索结果可以与应用程序的特定深度状态对应。搜索结果可以是具有包括或指示与深度状态对应的面包屑的链接的深度查看卡(dvc，参见下文)。搜索结果的其他潜在访问机制可能包括由应用开发者自己准备的本地深度链接，或指向应用程序的网页版的标准url。
可用的访问机制中的一个可以由搜索系统来选择，并与搜索结果一起提供给搜索客户端。在其他实施方式中，可以在搜索结果内提供多个访问机制，并且搜索客户端响应于用户对搜索结果的选择来确定要使用哪个访问机制。例如，当商业规则指示在本地应用程序中而不是在这些应用程序的网页版中呈现优选的结果时，可以在基于网络的访问机制上选择基于面包屑的访问机制。
然而，基于面包屑的访问机制仅可以在应用程序已被安装时才可用。在一些实施方式中，搜索客户端可以并入或接收作为搜索结果的一部分的下载和安装应用程序的脚本，并且随后启动深度链接。深度链接可以通过向新安装的应用程序发送基于面包屑的uri来启动。
搜索系统284从合并了面包屑标识符或面包屑本身的数据服务器282接收访问机制。搜索系统284可能已经具有关于appa的感兴趣状态的信息，然后能够将访问机制与相应的状态相关联。在其他实施方式中，搜索系统284可以搜寻(crawl)并调取(scrape)appa以获得感兴趣状态的元数据，并且可以跟随访问机制来查找状态的内容。
在一个使用模型中，用户设备220的用户执行针对特定功能和/或针对特定实体的搜索，诸如针对感兴趣的餐厅的评论。用户可以使用独立的搜索应用程序来执行该搜索，或者如图2所示，经由浏览器228执行网络搜索。如下面更详细描述的，搜索系统284将搜索结果提供给浏览器228。
这些结果可以包括与appa232对应的结果，并且可以包括指示appa232中的特定深度状态的链接。如果用户选择与appa232对应的链接，则链接被转发给链接处理程序244然后传递给appa232的路由库260。然后appa232由路由库260控制以使用相应的面包屑显示所指示的深度状态。
在各种实施方式中，路由库260从链接自身内编码的参数处接收面包屑的内容。例如，链接(在这种情况下为uri)可以包括方案(“portal-appa://”)，接着是导致期望视图的连续的面包屑的每个ui事件的序列化编码。例如，可以在使用base64编码的json(javascript对象表示法)数据结构中指定面包屑。
因此，搜索系统284能够提供将用户直接带到appa232内的相关内容的链接。搜索系统284可以将搜索结果提供给其他应用程序。例如，酒店应用程序可以向搜索系统284查询用户选择的酒店附近的餐厅，并且搜索系统284可以将餐厅搜索结果提供给酒店应用程序。在appa232是餐厅评论应用程序的情况下，酒店应用程序能够直接链接到与感兴趣的餐厅对应的appa232的深度状态。搜索系统284可以以dvc的形式提供搜索结果。
应用程序或应用程序状态的dvc在仅显示应用程序或应用程序状态的标识外，还显示另外的信息。例如，该信息可以包括应用程序状态的标题或应用程序状态的描述，其可以是来自应用程序状态的文本的片段。其他元数据可以从应用程序状态提供，包括图像、位置、评论数量、平均评论和状态指示符。例如，依据当前时间是否在业务的运行时间内，可以将“立即打开”或“关闭”状态指示符应用于该业务。
一些dvc可能会强调导致dvc被选为搜索结果的信息。例如，dvc中与用户查询匹配的文本可以以粗体或斜体显示。dvc也可以包括允许直接动作的元素，诸如立即呼叫机构或直接转换到地图应用程序以得到机构导航指示的功能。
与dvc的其他交互(诸如轻拍或点击dvc的任何其他区域)可以将用户带到所指示的状态或应用。如下面更详细描述的，这可以通过打开相关应用程序来实现，或者如果应用程序未安装，则打开与所期望的应用程序状态相关的网站。在其他实施方式中，未安装的应用程序可以被下载、安装然后被运行，以达到所期望的应用状态。
换句话说，dvc包括应用程序或状态的识别信息以及来自应用程序或状态自身的另外的内容。另外的内容允许用户做出更明智的关于选择哪个结果的选择，甚至可以允许用户直接执行动作而无需导航到应用程序状态。如果用户想要采取的行动是获取信息，则在某些情况下，dvc本身可以提供必要的信息以完成此类动作。
在各种实施方式中，路由库对于每个应用程序可以是相同的，唯一的例外是路由库在安装时将注册的自定义方案的名称。该方案可以通过将开发者门户的文本与应用程序名称的文本进行连接来形成，并且可以包括诸如连字符或下划线的分隔符。应用程序的名称可以随着时间而改变，但该方案可以在首次设置后被修复，以便用较早版本的应用程序(其路由库只能识别原始方案)提供向后兼容。
在各种实施方式中，可以在保持向后兼容的同时使用安全更新、错误修复和功能添加来更新路由库。诸如开发者204之类的开发者可以在每次向数字发布平台212发布他们的应用程序的新版本时下载并合并最新版本的路由库。在一些实施方式中，构建/编译过程可以在解决链接器依赖性时自动地下载最新版本的路由库。
每当开发者204为数字发布平台212准备新版本的appa时，可能需要调用离线分析系统280。另外，随着开发者204向appa添加更多内容，离线分析系统280可以被调用以确定访问所添加的内容需要的面包屑。离线分析系统280的调用可以在开发者204的请求下执行或者可以以周期为基础来进行执行。数据服务器282存储针对面包屑的任何更新或添加，并且能够将其提供给搜索系统284，使得搜索结果内的链接具有最新的访问机制。
在一些实施方式中，可以使用机制将面包屑传送到路由库260而不是直接包括在uri中。例如，当最大长度链接比编码面包屑可能需要的字符数短时，这可能是必要的。
因此，在一些实施方式中，路由库260可以从数据服务器282下载面包屑的包。来自搜索系统284或其他链接的搜索结果然后可以引用路由库260映射到面包屑的唯一标识符。仅作为示例，唯一标识符可以由功能和实体形成，诸如“restaurant_reviews”和“amarin_thai”。在一个特定示例中，uri“portal-appa://restaurant_reviews/amarin_thai”可以由路由库260解析为面包屑，该面包屑从appa232的缺省状态到达amarinthai餐厅的餐厅评论状态。然而，并未要求唯一标识符是人类可读的。
在其他实施方式中，路由库260可以响应于接收深度链接而咨询数据服务器282。通过提供唯一标识符，路由库260能够从数据服务器282下载必要的面包屑。在这样的实施方式中，路由库260可以缓存面包屑，使得不需要网络访问来解析最近访问的深度链接。诸如当appa232首先在用户设备220上运行时，也可以执行一些或全部面包屑的预先缓存。
预先缓存甚至可以更早地发生，诸如当开发者204正在准备发布appa时。换句话说，面包屑的全集或子集可以与appa一起被包括，使得当经由链接接收到唯一标识符时，路由库260能够毫无延迟地选择适当的面包屑。预先缓存可以通过路由库260与面包屑的定期验证相结合，诸如通过以定期日历间隔(诸如每月一次)检查面包屑的包的版本号。在其他实施方式中，数据服务器282可以向路由库260发送指示新的面包屑可用的推送通知。
就开发者204已经在appa中实现了一些深度链接而言，appa232中的开发者实现的路由器(未示出)将从链接处理程序244接收链接。开发者的路由代码不会注册“portal-appa://”，而是独立于开发者门户208的方案，诸如“appa.com://”。在各种实施方式中，开发者指定的uri可能不是公众可用的，或者可能仅对于具有与开发者204建立了的关系的公司可用。
某些操作系统(包括ios操作系统)具有沙箱基础结构，以限制应用程序能够访问超出专门分配给应用程序的范围的资源或内存区域的范围。沙箱增强了安全性，使恶意软件更难以破坏用户系统。因为路由库260在appa232的上下文内运行，所以沙箱应当对路由库260与appa232的用户界面元素之间的交互没有造成任何困难。
路由库
在图3a中，路由库260的示例实施方式包括uri处理器304，其例如从图2中的链接处理程序244接收链接。uri处理器304可以挂钩到操作系统方法中，以检查该应用是否被启动来作为深度链接访问的外部请求的结果。例如，在ios环境中，此方法可以是“application:didfinishlaunchingwithoptions:”。在各种实施方式中，uri处理器304可以挂钩objc_msgsendc函数以查看对所有类及其方法的调用。然后，能够识别和处理对“application:didfinishlaunchingwithoptions:”方法的调用。
如果应用响应于深度链接请求而启动，则uri处理器304从接收到的链接提取面包屑并向状态机308提供面包屑。否则，uri处理器304可以保持休眠状态并将控制权返回到“application:didfinishlaunchingwithoptions:”方法的应用程序中的缺省处理程序。挂钩到方法可以使用方法混合来执行。在各种实施方式中，链接中所编码的数据结构可以包括除面包屑之外的另外的信息。例如，数据结构可以包括指示状态机308的配置参数以挂钩某些方法来测试对ui事件的响应。
针对由路由库260应当处理的深度链接产生的应用启动是否可以使用以下伪代码来完成的测试，该伪代码测试所注册的方案(再次使用假设的“portal-appa://”方案)是否匹配所收到的链接的方案。nslog调试命令是处理所识别的深度链接的代码的占位符。
uri处理器304也可以挂钩入另一种方法，该另一种方法在ios环境内被称为涉及视图相关通知的“viewdidappear:”。在各种实施方式中，依据应用程序的操作模式，深度链接可以导致所调用的“viewdidappear:”或“application:didfinishlaunchingwithoptions:”方法，并且因此uri处理器304挂钩到两者。在ios环境中，视图能够在“正在出现”、“已出现过”、“正在消失”和“已消失”之间切换。“viewdidappear:”方法与从正在出现状态变换到已出现过状态的视图相关联。
状态机308使用ui重放致动器312以连续的方式从面包屑重放每个ui事件。ui事件可以包括模拟轻拍、按压、键盘输入和手势。这些事件可以完成ui动作，诸如按下按钮、填充文本字段、选择图标以及制作菜单选项。
在一些实施方式中，可以使用来自操作系统的内置可访问性功能(其可以被称为可访问性框架)来实施ui重放致动器312。例如，应用程序开发者通常使用apple提供的xcode编程工具来开发用于apple公司的ios操作系统的应用程序。包括在这些工具中的是名为uiautomation框架的实用程序，开发者能够使用该实用程序来模拟与应用程序的用户交互来作为应用程序开发过程的一部分。
然而，uiautomation框架是一个私有框架(仅在开发过程中使用)，并且可能会被禁止并入发布给最终用户的应用程序中。除非uiautomation框架变得可用于正常发布的应用程序，否则ui重放致动器312可以用自定义软件来实现。
ui重放致动器312可以使用uicontrol类的iossendactionsforcontrolevents:方法来将界面操纵事件(例如，轻拍、按压、点击)发送到指定的ui元素。为了将这些界面操纵事件引导至适当的ui元素，可以由如下面更详细描述的离线分析系统280确定用于ui元素的唯一标识符。
离线分析系统280提取或调取与每个元素相关联的文本值，并将该文本值(例如，文本字符串)用作唯一标识符。典型地，每个ui元素的文本值将是包括在所显示的菜单项或列表项中的文本。作为使用文本值的替代方案，也可以使用与ui元素相关联的序号。在一些情况下，在文本值本身并不代表唯一标识符的情况下，离线分析系统280可以将所提取的或者所调取的文本与所提取的序号进行组合(诸如通过级联)，从而生成唯一标识符。
面包屑包括有序的一系列ui事件，每个ui事件包括指示了要被致动的ui元素的唯一标识符。状态机308按顺序将每个ui事件发送到ui重放致动器312。ui重放致动器312可以使用sendactionsforcontrolevents:方法向由唯一标识符指示的ui元素发送诸如模拟轻拍的事件。
在一些实施方式中，状态机308在每个ui事件之间等待预定的时间段。在其他实施方式中，状态机308等待来自ui重放致动器312的指示，该指示为主机应用程序准备好接收另外的输入。对于一些ui事件，主机应用程序可能准备好立即接收另外的输入，而对于其他ui事件，例如在ui事件导致加载并显示了新视图时，可能会有延迟，直到主机应用程序再次准备好接收ui事件。
在各种实施方式中，状态机308也可以验证在每个ui事件之后存在正确的视图。如果所预期的视图未被显示，则状态机308可以等待另外的超时时间。如果所期望的视图仍未被显示，则状态机308可以中止ui重放以避免将ui事件发送到错误的视图以及可能将主机应用程序置于未知状态。
在中止ui重放之后，状态机308可以将主机应用程序恢复到缺省状态并且尝试在另外的超时时间遍历面包屑。如果第二次尝试也未能按预期遍历主机应用程序的视图，则状态机308可以返回到主机应用程序的缺省状态并显示指示无法达到所链接的深度状态的错误消息。
方案注册声明316标识要由路由库260注册的方案(例如“portal-appa://”)。在各种实施方式中，方案注册声明316位于应用程序的配置文件中，如info.plist。
在图3b中，路由库350包括与图3a的方案注册声明316、ui重放致动器312和状态机308相似或相同的元素。在路由库350中，uri处理器354诸如从安装了路由库350的用户设备的操作系统接收链接。链接可以是符合在方案注册声明316中指定的方案的uri。
uri处理器354从链接中提取唯一id，这可以简单地通过将uri的文本置于uri中的一对正斜杠的右侧来执行。唯一id用于索引面包屑数据存储器358。面包屑数据存储器358为每个唯一id存储包括一系列ui事件的面包屑，以重放来达到应用程序的相应状态。
如果面包屑数据存储器358不包括用于唯一id的面包屑，则面包屑数据存储器358可以经由网络接口362访问面包屑来源，诸如图2的数据服务器282。
在一些实施方式中，当包括路由库350的应用程序首先在用户设备上运行时，面包屑数据存储器358经由网络接口362检索所有可用面包屑的完整包。在一些实施方式中，每次启动包括路由库350的应用程序时，面包屑数据存储器358可以查询数据服务器282以检索新的和更新过的面包屑。
动态分析
在图4中，离线分析系统280的示例实施方式包括允许操作者与感兴趣的应用程序(诸如appa)交互的指南创建系统400。指南创建系统400允许操作者指定应用程序的哪些状态应当是可深度链接的，并且可以使用来自操作者的输入来确定如何到达那些深度状态。在各种实施方式中，操作者是离线分析系统280的管理员，其作用于应用程序的离线处理的标准操作过程或者作用于来自应用程序的开发者的指令。另外地或可选地，应用程序开发者的代理可以充当操作者。代理可以指定哪些状态或哪些类型的状态应当作为深度状态来访问。
在初始的离线分析之后，代理可以使用开发者门户208来请求应用程序的被添加为深度状态的另外的状态，并且请求将现有的深度链接状态移除。这可以经由开发者门户208来完成，而无需代理修改应用程序的代码或者甚至请求来自应用程序的软件开发者的协助。换句话说，营销人员或用户体验设计师可以自己控制应用程序内的深度链接的范围，甚至无需发布新版本的应用程序。对于所增加的状态，离线分析系统280将重新处理应用程序以将面包屑确定为所添加的状态。
对于由离线分析系统280处理的应用程序，操作者控制在模拟器404内运行的感兴趣的应用程序的副本。在各种其他实施方式中，感兴趣的应用程序可以被安装在物理设备上或运行在仿真环境中。在各种实施方式中，模拟器404可以在云托管操作者处实例化，该云托管操作者可以提供在其内运行仿真器/仿真器代码的计算设施，或者可以为一个或更多个移动设备操作系统直接提供仿真器或模拟器。有关更多信息，请参见2015年9月28日提交的标题为“operator-guidedapplicationcrawlingarchitecture”的美国专利申请编号14/868,294，第一发明人为kalyandesineni，代理人案卷号为17100-000006-us-02。本申请的全部公开通过引用并入本文。
在一些实施方式中，可以使用运行操作系统的物理设备而不是模拟器404，诸如用于没有合适的模拟器或仿真器的操作系统。物理设备可以使用无线或有线接口(诸如usb(通用串行总线))连接到指南创建系统400。可以在物理设备上安装根级别控制应用以跟踪用户输入。安装根级应用可能需要绕过关于已安装的应用程序的特权的固件或操作系统的安全限制，并可能需要设备越狱。越狱涉及绕过或移除由操作系统和/或设备固件所应用的各种软件限制，并且可以使用特权升级技术来完成。在某些实施方式中，可以在越狱了的手机上安装专用工具，诸如saurikit的cydia软件包管理工具。
可以记录操作者与应用程序的交互，以形成指示如何达到状态的指南。该指南定义了用于达到最终状态的面包屑，并且该指南的子集定义了中间状态的面包屑。该指南也可用于推断其他感兴趣的状态并确定导向这些状态的面包屑。每个ui事件可以与特定的ui元素相关联，通过唯一的id根据预定的标题来识别。
例如，唯一id可以由在呈现视图时如何以编程方式创建ui元素来指示。在其他实施方式中，唯一id可以由如何实际看到ui元素来指示，其中ui元素按递增顺序从左到右和从上到下进行编号。在其他实施方式中，即使操作者的动作偏离了中心，x-y坐标也可以用于识别用户交互的位置或者被致动的ui元素的边界或者被致动的ui元素的中心。
在各种实施方式中，可以使用静态分析来分析应用程序的各种状态的ui元素。静态分析涉及分析应用程序的代码，而无需观察正在运行的应用程序。在执行静态分析之前，应用程序包(诸如ipa文件)被下载、解密以及反汇编。可以在比静态分析或动态分析本身更高性能的机器上执行反汇编。
在一些实施方式中，静态分析器(未示出)可以识别每个视图的ui元素并且将唯一标识符分配给视图内的每个ui元素。然后，当涉及与任何ui元素的用户交互时，动态分析将具有预定的名称。
另外地或可选地，静态分析器可以分析应用程序的方法和视图以确定如何最好地测量应用程序。利用这些信息，动态分析器可以挂钩正确的方法，并监听正确的事件，以准确跟踪用户与应用程序的交互，并丢弃与用户交互无关的方法调用。有关静态分析的更多信息，请参见2015年9月2日提交的标题为“staticanalysis-assisteddynamicapplicationcrawlingarchitecture”的美国专利申请编号14/843,929，第一发明人为kalyandesineni，代理人案卷号为17100-000006-us。本申请的全部公开通过引用并入本文。
当应用程序在模拟器404中运行时，指南创建系统400可以监视模拟器404(或者当在仿真器或物理设备中运行时实际操作系统)的消息队列，并且监听指示用户操作应用程序的消息。这种操作包括例如点击、按压、捏或轻扫用户界面。
除捕获与操作者交互的每个ui元素的唯一标识符之外，指南创建系统400也可以根据由操作系统指定的定义类型来提取每个元素的类型，并且进一步提取所关联的视图控制器的标识。
例如，可以诸如通过使用方法混合来挂钩以下方法：
-(void)sendevent:(uievent*)eventmethodintheuiapplicationclass
-(void)sendaction:(sel)actionto:(id)targetforevent:(uievent*)eventinuicontrolclass
-(void)viewdidappear:(bool)animatedforallthecontrollersthatwereloaded
处理程序可以被实现为记录每种类型的ui元素。作为示例，用于记录按钮按压的代码能够如下实现：
其他类型的ui元素可以通过相似的处理程序代码来记录。在各种实施方式中，在挂钩objc_msgsend函数之后，指南跟踪器模块408可以监听appdelegate类和(bool)application:(id)application
操作者能够帮助将分析重点放在所期望的深度链接的状态上-通常是最有趣或最重要的状态，而不是试图通过应用程序的非指导的搜寻来穷尽性地发现应用程序的每个状态。操作者可以从应用程序的主页状态开始，并且针对所期望的深度链接的状态的每种类型进行到感兴趣的一个状态。离线分析系统280然后可以推断以发现相似/并行的动作，其中的每一个可以对应于另一感兴趣的状态。能将这些平行状态添加到状态列表中，该列表定义了哪些状态将具有所存储的相应的面包屑。
例如，如果应用程序包括关于餐厅的信息，则操作者可以浏览列出餐厅的状态，然后选择餐厅中的一个。操作者可以在找到显示关于第一家餐厅的细节的状态后停止。基于操作者在浏览期间所采取的一系列动作，离线分析系统280能够以相似的方式查找已经得到的其他餐厅细节状态。
例如，在从列表中选择具有特定布局和特定属性(例如，具有属性x的图像比邻具有属性y的文本框)的餐厅项目之后，离线分析系统280可以在操作可能选择的视图内检测(具有相同的布局和/或属性的)多个另外的餐厅项目。然后，可以预测的是，选择其他餐厅列表将导致查找另外的餐厅信息状态。有关推断的其他信息，请参阅2015年9月29日提交的标题为“stateextrapolationforautomatedandsemi-automatedcrawlingarchitecture”的美国专利申请编号14/869,127，第一发明人kalyandesineni，代理人案卷号17100-000006-us-03。其全部公开通过引用并入。
在指南创建系统400内，指南跟踪器模块408在模拟器404中记录操作者与应用程序的交互，以创建操作者指定的指南。例如，指南可以包括在应用程序的主页(或默认)状态开始的由操作者执行的每个用户界面交互。在各种实施方式中，目标状态跟踪器412可以允许操作者将在模拟器404中当前可见的状态标记为感兴趣的状态。例如，目标状态跟踪器412可以在模拟器404内提供用户界面元素(诸如按钮)或者将用户界面元素提供为操作者通过其控制模拟器404的软件的一部分。
对于每个感兴趣的状态，链接提取控制器416生成指定导致感兴趣的状态的ui事件序列的面包屑。链接提取控制器416明确地(诸如经由目标状态跟踪器412)或隐含地(诸如经由指南跟踪器模块408)了解到操作者感兴趣的状态。链接提取控制器416可以尝试识别类似的状态-例如，使用相似的ui(用户界面)元素到达的状态。
目标状态可以由操作者使用目标状态跟踪器412来明显地识别。如果目标状态不是由操作者指定的，则链接提取控制器416可以假设当操作者正在创建指南时所达到的最终状态就是目标状态。或者，链接提取控制器416可以假设操作者导航到的每个状态应当是目标状态。删除重复过程可以在操作者循环浏览时用于检测，从而避免记录重复和/或非最短路径指南。如果操作者明确标记目标状态，则删除重复可能不太必要。
链接提取控制器416操作模拟器420，该模拟器420如上所述可以替换为仿真器或物理设备。对于规模，链接提取控制器416可以控制多个仿真器、模拟器和/或物理设备，从而分析相同或不同的应用。仅作为示例，一组物理智能电话可以全部经由usb连接到由链接提取控制器416控制的接口卡。仅为了便于说明，图4中仅示出单个模拟器(模拟器420)。在各种实施方式中，模拟器420和模拟器404可以是由指南创建系统400和链接提取控制器416共享的单个模拟器。
感兴趣的应用在模拟器420内执行。在各种实施方式中，由模拟器420运行的应用程序可以补充有诸如在图3a或图3b中描述的路由库。利用路由库，链接提取控制器416能够使模拟器420中的应用程序重放ui事件以遵循指南并识别另外的感兴趣的状态。在其他实施方式中，因为模拟器420中的应用程序不必是应用程序的公开发布的版本，所以可以使用可访问性或自动化框架来执行ui控制。路由库可以保留用于公开发布的应用程序的版本。
链接提取控制器416识别与由指南跟踪器模块408所指定的每个指南对应的感兴趣的状态。为了达到应用程序内的状态，链接提取控制器416将由指南跟踪器模块408所指定的最短路径发送到模拟器420以被重放。链接提取控制器416识别与由指南跟踪器模块408所指定的每个指南对应的感兴趣状态。
在各种实施方式中，离线分析系统280可以包括从每个感兴趣的状态提取内容的调取器(scraper)(未示出)。内容可以包括文本、图像和元数据，诸如位置、格式、界面提示等。该内容可以由图2的搜索系统284使用以确定应用程序的哪些深度状态与搜索查询相关。在其他实施方式中，搜索系统284可以分别搜寻并调取应用程序，但可以使用来自离线分析系统280的面包屑以导航到各种状态。
如果存在需要输入文本的ui字段，则操作者可以向指南创建系统400标识需要键入什么类型的文本输入。例如，类型可以是城市名称、美食名称等。链接提取控制器416查阅知识库以获得这种类型的可能值的列表(对于城市，该列表可以包括“西雅图”、“圣何塞”等)，然后将这些值中的每一个重放到文本输入字段中。
链接提取控制器416可以通过跟随不同的面包屑检测到已达到的潜在的感兴趣状态。链接提取控制器416然后可以选择面包屑中的一个以便与该状态相关联。例如，可以选择具有最少数量的ui事件的面包屑。或者，可以选择具有最少视图改变的面包屑，而ui事件的总数可以被用作决胜属性(tiebreaker)。
为了识别已经到达的状态，链接提取控制器416可以存储针对每个状态的指纹以及面包屑。指纹可以是状态组件的简化表示。例如，可见对象的表示可以例如通过枚举xml数据结构中的对象来创建，然后(例如用md5)计算数据结构的数学散列。散列就是指纹，如果新状态的散列与现有状态的散列相匹配，则状态被认为是相同的。
当链接提取控制器416组合感兴趣的状态集合时，链接提取控制器416可以将状态的标识符存储到配置数据存储器424中。对于每个感兴趣的状态，链接提取控制器416确定面包屑以到达该状态并将面包屑存储在配置数据存储器424中。另外，来自状态的内容或指纹被存储在配置数据存储器424中。来自配置数据存储器424的数据可以被提供给图2的搜索系统284。
整体操作
在图5中，本公开的操作的概述开始于504处。开发者开发应用程序(“appa”)，但没有实现用于所有状态的深度链接功能，并且可能没有实现用于任何状态的深度链接功能。在508处，也许几年之后，开发者确定深度链接功能对于appa的用户可能是有价值的，同时可以增加appa的可见性，因此开发者将appa提供给开发者门户。在512处，控制开始appa的离线分析。
在516处，开发者门户向开发者提供路由库。在520处，开发者将路由库集成到appa中。该集成可以如同通过导入头文件和目标文件那样简单的将路由库添加到集成开发环境。在524处，开发者将用路由库增强过的appa提供给数字发布平台。
在528处，用户在用户设备上安装appa，导致专有appa链接被注册到用户设备。在532处，appa内的路由库处理由用户设备的操作系统提供的专有appa链接。例如，这些链接可能来自浏览器、搜索应用程序或了解了深度链接的其他应用程序。路由库确定由链接指定的面包屑，并根据面包屑重放ui事件以达到指定的状态。在532处控制保持针对appa的安装，其中直到应用从用户设备卸载，appa中的路由库继续处理专有appa链接。
服务器侧控制
在图6中，服务器侧组件的操作可以由单个设备执行，或者可以在图2的开发者门户208、离线分析系统280、数据服务器282和搜索系统284上执行。在各种实施方式中，开发者门户208、数据服务器282和搜索系统284可以处于同一实体的控制之下。离线分析系统280可以采用有助于静态分析和/或动态分析的操作者来确保从每个应用程序提取准确和完整的参数。
控制开始于602处，其中路由库可用于应用程序开发者。随着时间的推移，路由库可能会被更新，最新的版本可能是应用程序开发者可用的唯一版本。在604处，如果已收到对面包屑的请求，则控制转换到606处；否则，控制转换到608处。在606处，控制确定自请求者接收到最新的请求起改变的面包屑的子集。然后能够在610处提供该子集以在请求来源处带来最新数据。然后控制返回到604处。
在608处，如果应用程序的离线处理已经启动，则控制转换到612处；否则，控制转换到616处。在616处，如果从搜索系统接收到搜索查询，则控制转换到620处；否则，控制返回到604处。在620处，控制确定与搜索查询对应的结果的考虑集合。此考虑集合可以包括对搜索查询开放的应用程序以及与搜索查询相关的应用程序的特定状态(深度状态)。
在624处，控制基于它们与所理解的搜索查询的意图的匹配程度来对考虑集合中的元素进行评分。评分结果能够根据最相关到最不相关来排名。在628处，排名最高的结果被设置为深度查看卡，该深度查看卡与结果内的特定状态的深度链接相关联。在632处，控制将深度查看卡返回给查询的请求者。
深度查看卡可以不完全呈现，而是包括图像、文本和指令，该指令关于如何针对特定画面大小、方向和请求应用或操作系统的其他要求来呈现深度查看卡。对于根据本公开的原理的由路由库服务的深度链接的应用，与相应搜索结果一起返回的访问机制可以包括具有经编码数据结构的uri。
经编码数据结构可以包括从应用程序内调用该特定状态所必需的面包屑。作为字符串的uri包括该数据结构的序列化版本，并以方案为前缀。该方案(例如“portal-appa://”)将导致uri被转发到应用程序的路由库并被其识别。控制然后返回到604处。
在612处，控制例如在模拟器中运行appa。在appa正在运行时，控制监视由操作者对appa的使用而导致的ui事件。在636处，控制允许操作者与appa交互以达到感兴趣的深度状态，从而记录每个ui交互以形成面包屑。在各种实施方式中，控制可以监视appa响应特定ui事件需要多长时间。这些响应时间或基于响应时间的延迟可以与相应的ui事件一起编码在面包屑中。例如，一些操作可以要求appa从服务器获取数据，这导致网络通信延迟。当重放面包屑中的ui事件时，在ui事件导致网络访问之后，在下一个ui事件重放之前应当有更长的延迟时间。在640处，如果存在另外的感兴趣的深度状态，则控制返回到636处；否则，控制在644处继续。
在644处，控制确定与由操作者所识别的状态并行的状态。例如，如果操作者从外观类似项目的列表中选择一个链接，并且所选择的链接导向了感兴趣的状态，则控制可以假设列表中的其他项目也是感兴趣的。这些并行状态以及用于访问它们的面包屑(在列表示例中，面包屑只会在最新的ui事件中有所不同)被添加到深度可链接状态列表中。
在各种实施方式中，可以使用搜寻算法(crawlingalgorithm)来运用appa以达到appa的一些或全部深度状态。关于搜寻的另外的信息，参见2015年9月9日提交的美国专利申请编号14/849,540，其标题为“unguidedapplicationcrawlingarchitecture”，第一发明人kalyandesineni。本申请的全部公开通过引用并入本文。
在648处，控制向搜索系统提供用于索引的深度可链接状态的列表。在652处，对于每个可深度链接状态，控制向数据服务器提供包括面包屑的数据结构，以在uri中用作访问深度状态的访问机制。控制然后返回到604处。
面包屑创建
在图7中，操作者创建面包屑的示例操作开始于704处，其中控制将仿真器或模拟器中的主题应用程序打开到应用的主页状态。在708处，控制开始跟踪用户与应用程序的交互，包括跟踪操作者与之交互的用户界面元素。在712处，如果用户将当前状态标记为目标状态，则控制转换到716处；否则，控制转换到720处。在716处，控制将状态添加到目标状态的列表并且在720处继续。
在720处，控制继续跟踪用户与应用程序的交互。在724处，控制确定用户是否已经发信号通知将要创建新的面包屑。用户可以通过使用应用程序本身内的控件或仿真器所提供的控件将应用程序重置为主页状态来发信号。如果用户已将应用程序重置为主页状态，则控制转换到728；否则，控制返回到712。在728处，控制将所跟踪的用户交互存储为面包屑，该面包屑用于结束状态的面包屑。控制在732处继续，如果用户完成创建面包屑，则控制结束；否则，控制返回到704处。
面包屑推断
参照图8，操作者可能已经建立了一系列面包屑但没有将任何特定状态标记为目标状态。例如，在一些实施方式中，可以不向操作者呈现指定目标状态的选项。然而，操作者所创建的面包屑通常从主页状态开始并以终结(或最终)状态结束。这个最终状态可以假设为深度链接的感兴趣的状态。换句话说，只有终结状态被假定为目标状态。在其他实施方式中，将面包屑所经过的每个状态假设为目标状态。
例如，当操作者为餐厅评论应用程序创建面包屑时，操作者可以通过从主页状态导航到包括餐厅信息和评论的状态来创建一个面包屑。这将被假定为所期望的目标状态，并且链接提取控制器将试图寻找具有用于搜寻的相似数据的另外的状态。面包屑创建被认为是离线(或“新手启动(onboarding)”)过程，在面包屑可用于导航到用户设备上的特定状态之前执行。
控制开始于804处，其中选择操作者所创建的面包屑列表的第一个面包屑。在808处，控制将应用程序打开到仿真器中的主页状态。在812处，控制跟随所选择的面包屑，该面包屑在紧接最终状态之前的状态下停止。在816处，控制执行推断以识别与最终状态相似的状态。例如，控件在根据所选择的面包屑进行跟随时，识别与将达到最终状态的ui小部件并行的ui小部件。
在820处，控制将最终状态以及从被标识为并行的ui小部件所到达的状态添加到状态列表。所添加的状态中的每一个都使用基于所选择的面包屑的面包屑进行注释。除最终状态之外的状态的面包屑将在每个面包屑的最终ui事件与最终状态的面包屑分开。在824处，控制确定面包屑列表中是否存在另外的面包屑。如果是这样，则控制转换到828；否则，控制结束。在828处，控制从面包屑列表中选择下一个面包屑，并返回到808处。
路由库操作
在图9中，集成到应用程序(在本示例中为“appa”)中的路由库的示例操作在安装appa时开始。在904处，路由库向操作系统注册专有方案。专有方案专用于appa，并由提供了路由库的系统来定义。在各种实施方式中，该注册可以由操作系统在安装应用程序时来执行，其中专有方案可以在应用程序内的属性文件中被指定。换句话说，由于路由库已经被并入appa中，所以904可以基于由appa指定的参数通过用户设备的操作系统来执行。
如上所述，允许路由库导航到特定深度状态的面包屑可以在链接中被接收，或者可以由链接中的唯一id来指示。当由唯一id指示时，路由库可能不得不从数据服务器请求面包屑。在一些实施方式中，路由库因此将预先缓存一些或所有面包屑。如果始终在链接中接收面包屑，则此操作可能会被忽略。
在一些实施方式中，编码时的特定面包屑比链接的最大允许长度更长。此最大长度可能由浏览器、操作系统或其他技术或业务限制来决定。因此，这些面包屑可以从数据服务器获得，而较短的面包屑被包括在uri中。这样，当不超过最大链接长度时，uri的生成器(诸如搜索系统)准备包括了面包屑数据本身的uri，否则仅包括面包屑的唯一标识符。
在908处，控制从数据服务器请求面包屑的包。该操作可以在设备上运行appa时进行第一次执行。该面包屑的包可以包括可用于appa的深度状态的所有面包屑。在各种实施方式中，面包屑的包可以仅包括与appa的更受欢迎的状态相关的那些面包屑。如果在深度链接中请求appa的不太受欢迎的状态，则路由库能够单独请求该深度链接的面包屑。
在912处继续控制，其中如果从操作系统接收到与专有appa方案匹配的uri，则控制转换到916处；否则，控制转换到920处。在920，控制确定来自数据服务器的最新数据更新是否在过去发生了超过预定时间。仅作为示例，该预定时间可以被指定为天数。如果数据更新在遥远的过去，则控制转换到924处；否则，控制返回到912处。在924处，控制从数据服务器更新由路由库维护的面包屑数据存储器。控制在912处继续。在以uri接收面包屑并且面包屑未被路由库缓存的实施方式中，可以省略920、924和908。
在916处，控制确定面包屑是否包括在uri中。如果是这样的，则控制转换到928处；否则控制转换到932处。在928处，控制对从uri保存面包屑的数据结构进行解码，并且控制在936处继续。在932处，由于面包屑未被包括在uri中，所以控制确定面包屑是否已经存储在面包屑数据存储器中。如果是这样，则控制使用来自面包屑数据存储器的面包屑并在936处继续；否则，控制转换到940处。在940处，控制从数据服务器请求面包屑，并且当面包屑被返回时，控制在936处继续。
在936处，控制选择由面包屑指定的序列中的第一ui事件。在944处，控制从面包屑重放所选择的ui事件。在948处，控制确定重放所选择的ui事件是否成功地导致下一个视图或如预期的那样更新当前视图。在各种实施方式中，控制可以在检查成功之前等待预定的时间段。该预定时间段允许应用程序响应于ui事件。
在各种实施方式中，面包屑数据结构可以包括指定的等待时间，该指定的等待时间可以应用于所有ui事件，或者可以具有用于每个ui事件的单独的等待时间。作为面包屑确定过程的一部分，离线分析系统可以检测到针对要响应的应用程序特定ui事件花费更长时间。在这种情况下，离线分析系统可以指示在重放另一ui事件之前应当执行另外的延迟时间段。
在948处，当路由库检测到已经用与重放事件对应的特定参数调用了方法时，可以标识成功。换句话说，作为离线分析的一部分，可以记录应用程序对ui事件的预期响应。当看到该预期响应时，可以推断成功。如果在948处ui事件显示已被成功处理，则控制转换到952处；否则，控制转换到956处。
在956处，控制等待另一预定时间段。该另外的时间段可以允许对ui事件的意外地缓慢响应。控制在960处继续，其中控制再次试图验证重放所选择的ui事件已成功地导致预期的行为。如果是这样，则控制在952处继续；否则，控制转换到964处。在964处，如果所选择的ui事件已被重放两次以试图获得成功的响应，则控制转换到968处。在968处，进行错误声明。例如，错误的处理可能会导致应用程序恢复到主页状态，并向用户显示深度链接不成功的通知消息。另外，可以向数据服务器发送指示深度链接不成功的消息。然后，控制返回到912处。在964处，如果所选择的ui事件仅被重放一次，则还没有发生第二次失败，因此控制返回到944处以便尝试对所选择的ui事件进行第二次重放。
在各种实施方式中，不对成功进行评估，并且以与预期一致地顺序重放ui事件，在大多数情况下，将达到所期望的深度链接。结果，元素948、956、960、964和968可以用简单的等待步骤来替换。等待步骤可以等待经验所确定的预定延迟以允许应用程序响应于用户输入。等待步骤可以在系统中被使用，在该系统中ui事件被应用程序处理时无法如其由路由库所能重放的那么快。在其他实施方式中，等待步骤可以涉及观察由ui事件产生的方法调用。一旦诸如通过观察特定方法调用检测到应用程序对ui事件的响应，控制可以允许重放以下ui事件。在952处，如果有另外的ui事件，则控制转换到972处；否则，控制返回到912处。在972处，控制选择面包屑中的下一个ui并返回到944处。
示例面包屑数据
每个面包屑可以根据预定义的数据结构进行组织。数据结构可以诸如用base64进行串行化，其示例如图10中所例示。uri1000包括:方案(“portal-appa://”)；功能标识符，其指示了以下数据表示要被重放的ui事件；以及面包屑数据。面包屑数据对有序数据结构进行编码，该有序数据结构包括要按顺序重放的ui事件。面包屑数据也可以包括标记(未示出)，该标记能够用于验证导致预期的结果的ui事件的重放。此外，面包屑可以包括预期状态的指纹(未示出)，以验证在跟踪面包屑结束时达到了正确的最终状态。
结论
前面的描述本质上仅仅是说明性的，并且决不意图限制本公开、其应用或用途。本公开的广泛教导能够以各种形式来实施。因此，虽然本公开包括特定示例，由于在研究附图、说明书和以下权利要求时，其他修改将变得很明显，所以本公开的真实范围不应当受到如此限制。应当理解的是，在不改变本公开的原理的情况下，方法内的一个或更多个步骤可以以不同顺序(或同时)运行。此外，尽管以上将每个实施例描述为具有特定特征，但是关于本公开的任何实施例描述的那些特征中的任何一个或更多个能够以任何其他实施例的特征和/或与任何其他实施例的特征组合来实现，即使该组合没有明确描述。换句话说，所描述的实施例不是相互排斥的，并且一个或更多个实施例相互之间的排列仍然在本公开的范围内。
如上所使用的术语代码可以包括软件、固件和/或微代码，并且可以指程序、例程、函数、类、数据结构和/或对象。共享处理器硬件包括单个微处理器，该单个微处理器用于执行多个模块的部分或全部代码。组处理器硬件包括微处理器，该微处理器与其他微处理器一起运行一个或更多个模块的一些或全部代码。对多个微处理器的引用包括离散管芯上的多个微处理器、单个管芯上的多个微处理器、单个微处理器的多个内核、单个微处理器的多个线程或以上的组合。
共享的存储器硬件包括存储来自多个模块的一些或全部代码的单个存储器设备。组存储器硬件包括存储器设备，该存储器设备结合其他存储器设备存储来自一个或更多个模块的一些或全部代码。
术语存储器硬件是术语计算机可读介质的子集。本文使用的术语计算机可读介质不包括通过介质(诸如在载波上)传播的瞬态电信号或电磁信号；术语计算机可读介质因此被认为是有形的和非暂时性的。非暂时性计算机可读介质的非限制性示例是非易失性存储器设备(诸如闪存设备、可擦除可编程只读存储设备或掩模只读存储设备)、易失性存储设备(诸如静态随机存取存储器设备或动态随机存取存储器设备)、磁存储介质(诸如模拟或数字磁带或硬盘驱动器)以及光存储介质(诸如cd、dvd或蓝光光盘)。
本申请中描述的装置和方法可以由专用计算机来部分地或全部地实现，该专用计算机是通过配置通用计算机来运行一个或更多个在计算机程序中实现的特定功能而创建的。上述功能块和流程图元素用于软件说明书，其能够由熟练的技术人员或程序员的日常工作将其翻译成计算机程序。
计算机程序包括存储在至少一个非暂时性计算机可读介质上的处理器可执行指令。计算机程序也可以包括或依赖于所存储的数据。计算机程序可以包括与专用计算机的硬件交互的基本输入/输出系统(bios)、与专用计算机的特定设备交互的设备驱动程序、一个或更多个操作系统、用户应用、后台服务、背景应用等。
计算机程序可以包括：(i)要被解析的描述性文本，诸如html(超文本标记语言)或xml(可扩展标记语言)、(ii)汇编代码、(iii)由编译器从源代码生成的目标代码、(iv)由解释器运行的源代码、(v)由即时编译器进行编译和运行的源代码等。仅作为示例，源代码可以使用包括了以下项的语言的语法来编写：c、c++、c#、objective-c、swift、haskell、go、sql、r、lisp、