用于识别、索引和导航至移动应用的深度状态的系统和方法与流程
相关申请的交叉引用
本申请要求2015年12月31日提交的美国临时申请no.62/274,152、2015年11月6日提交的美国临时申请no.62/252,357和2015年8月13日提交的美国临时申请no.62/204,960的权益。上述申请的全部公开内容通过引用被并入。
本公开总体上涉及移动应用开发，并且更具体地，涉及移动应用的特定状态的深度链接。
背景技术：
该部分提供了与本公开相关的背景信息，但并不一定是现有技术。
应用程序(在本公开中被可互换地称为“应用”)(诸如，移动应用)可包含多种深度状态。例如，在基于社交媒体观点数据对餐厅的品质进行评级的应用中，每家餐厅的详细页面将被视为深度状态(deepstate)。深度状态是能通过一系列用户动作在应用内可达到的，这些用户动作能够包括通过多个菜单屏幕(或视图)的导航以及与用户界面元件的交互。这些菜单屏幕和用户界面元件中的每个都能够由与所显示屏幕关联的唯一视图控制器来调解。
通常，只能从应用本身内访问这些深度状态。例如，在应用之外运行的网络搜索引擎不能到达应用内的深度状态。这意味着，当用户对餐厅进行传统网络搜索并且想要在专用餐厅评级应用中探究所返回选择中的一个时，用户将不得不手动将所选搜索结果的名称复制和粘贴到餐厅评级应用的搜索字段中，并且命令餐厅排名应用访问与所选餐厅对应的其内部深度状态。这表示了用户需要不期望的附加交互。
如果应用的深度状态可暴露于外部应用和计算机进程，则用户能够享受额外功能和便利。例如，用户能够使用基于互联网的搜索服务器开始搜索合适的餐厅，然后通过选择该搜索的结果中的一个，被自动导向专用餐厅排名应用的合适深度链接页面。
然而，实现这种功能需要开发商的努力，并且需要开发商可能不具备的深度链接专业知识。当应用开发受到时间、预算或专业知识的限制时，应用的某些或甚至全部状态下的深度链接功能不会有足以被实现的高优先级。
移动操作系统(诸如，来自appleinc.的ios操作系统和来自googleinc.的android操作系统)可允许开发商将数据提供到操作系统以进行索引。在ios操作系统中，这可采取cssearchableitem(其中，cs代表corespotlight)对象的形式。开发商可通过向操作系统提供关于这些状态的信息来实现对应用的某些状态标记书签的代码。在ios操作系统中，这可采取nsuseractivity(其中，ns代表nextstep)对象的形式。
然后，用户能够通过操作系统来执行搜索，从开发商应用识别出相关数据或状态。如果用户从操作系统界面(例如，搜索对话框或最近任务菜单)中选择这些活动中的一个，则开发商的代码能够将应用恢复成与标记书签的活动对应的状态。第一设备上的标记书签的活动甚至可在不同设备上继续(假定应用也安装在其他设备上)。通过设备间通信，第一设备的操作系统将用户最近正与什么状态交互通知给其他设备的操作系统。
另外，开发商可以指定由操作系统进行索引的某些类型的数据(诸如，应用所维护的联系人数据库中的电话号码和名字)。当用户向操作系统指示感兴趣的这些数据对象中的一个(例如，某个联系人)时，开发商的代码能够转变成表示用于查看或编辑的数据对象的应用的状态。
为了利用这些操作系统性能，开发商可以实现能够将应用恢复成基于所指示的活动或数据对象的状态的代码。然而，这些活动和数据对象可以仅由操作系统或操作系统的开发商所维护的搜索系统知道。换句话说，第三方应用和搜索服务可能无法访问该数据并且直接导航至应用内的状态或数据对象。
另外，开发用于显示数据对象、索引数据对象、将活动标记标签和继续活动的代码需要开发商付出努力，不是对于远少于所有应用状态的应用状态中的任意一种都可以被实现。因此，这些增强的操作系统性能不能对于各种应用状态都是可用的，也不能被第三方应用和搜索系统访问。
在图1中，图形描绘了增强的操作系统功能。在用户设备上，操作系统100运行第一应用(被称为“appa”)104。appa104包括代表性视图集，即视图a108-1、视图b108-2、视图c108-3、视图d108-4和视图e108-5(统称为视图108)。视图108可以由一个或更多个视图控制器来管理，视图控制器可以根据模型-视图-控制器(mvc)软件架构模型来开发。
仅作为示例，appa104是餐厅信息应用程序，视图a108-1是appa104的主(或默认)状态，在该状态下，能够通过菜肴、地理位置等来执行餐厅搜索。继续该示例，视图b108-2是示出餐厅位置的二维应用界面，视图c108-3是餐厅详细视图，视图d108-4是按菜肴得到的餐厅列表，视图e108-5是最近被评论的餐厅的列表。在包括该示例的各种实施方式中，单个视图可以是用特定实体数据填充的模板。例如，视图c108-3可以具有餐厅的可视布局，该可视布局指明餐厅照片将放置地点，餐厅名称的位置、大小或正面，将如何总结评论等。可视布局视图将使用用数据存储器中的与特定餐厅对应的数据被实例化。
appa104选择数据对象并且将数据对象提供到操作系统100以进行索引。例如，appa104可以提供appa104所涵盖的每种特定菜肴的名称。然后，操作系统100能够将结果提供到正按该菜肴名称进行搜索的用户。
appa104包括从操作系统100接收持续用户活动信号的活动处理程序112。例如，持续用户活动信号可以指出某个菜肴类型是用户感兴趣的。活动处理程序112然后调用视图d108-4并且使用与指定菜肴相应的结果来填充视图d108-4。appa104关于将哪些菜肴提供到操作系统100以进行索引可以是选择性的，因为提供太多数据对象可以导致降低它们的平均相关性。这会致使操作系统100降低未表现出高相关性的被索引对象的排名或甚至将其从搜索结果中去除。
因此，appa104可以包括对最受欢迎的菜肴或其名称更可能是菜肴所唯一的菜肴的列表进行索引的编程。例如，虽然“美式”可以是菜肴的名称，但是因为该术语适用于许多其他搜索而非仅仅菜肴，所以误报率高。然而，如果用户表明对菜肴感兴趣(诸如，通过一次或更多次查看针对某个菜肴的餐厅清单)，则appa104可以将该菜肴名称添加到由操作系统100索引的对象的列表。
另外，appa104可以使用活动对象向操作系统100指示用户当前正在查看针对具体菜肴的餐厅结果。这允许操作系统100实质地保持用户在appa104内执行的活动的历史。另外，能够将用户参与的最近活动与另一设备共享，从而允许将与该活动的用户交互从一个设备切换到另一设备。在本公开中，将活动对象提交给操作系统从而允许随后在同一或另一设备上恢复(resume)活动被称为活动标记书签。
当用户进入视图b108-2以在地图显示中查看餐厅结果时，活动对象可以被发送到操作系统100。例如，发送到操作系统100的活动对象可以在地图中心包括纬度和经度。如果用户调节地图的中心，则appa104可以向操作系统100提供指示新中心点的更新后的活动对象。appa104还可以将其他数据(诸如，过滤器)包括在活动对象中。例如，用户可以经将所显示的结果限制于仅仅当前开门的餐厅。可以在提供到操作系统100的活动对象中识别该过滤器。
活动处理程序112可以从操作系统100接收持续用户活动信号，该持续用户活动信号指示用户有兴趣使用某一过滤器集持续在某个中心点的餐厅的地图视图。仅作为示例，在ios操作系统中，这可以采用对应用的应用委托进行continueuseractivity(持续用户活动)调用的形式。然后，活动处理程序112使用所提供的参数调用视图b108-2并且并向用户呈现所期望的地图视图。持续用户活动信号可能已经从用户先前正在其上查看该地图显示的另一设备被接收到。如图1中所示的，活动处理程序112被编程为调用视图b108-2、视图d108-4和视图e108-5，但不调用视图a108-1或视图c108-3。
在操作系统100中，搜索索引120从appa104接收数据对象。搜索索引120还从其他应用并且在一些实施方式中从操作系统100本身接收数据对象(诸如经常访问的设备设置的名称)。仅作为示例，在ios操作系统中，搜索索引120可以被称为spotlight，并且提供到搜索索引120的数据对象可以采用cssearchableitem对象的形式。
搜索索引120还可以从活动追踪器124接收活动元数据。活动追踪器124接收活动对象(包括来自appa104的活动对象)。活动对象可以采用nsuseractivity对象的形式。活动跟踪器124接收到的活动对象可以包括与数据对象的元数据相似的元数据。元数据能够由搜索索引120进行索引。元数据可采用cssearchableitemattributeset对象的形式，该对象可以与cssearchableitem对象中使用的形式相同。
可以将被指示为公开的活动与由操作系统100的开发商所维护的云索引共享。云索引接口128将公开活动提供到云索引。这些公开活动通过云索引被选择性进行索引，从而允许其他用户即使未在他们的设备上安装appa104时也可以搜索并且找到appa104所生成的活动。
切换控制器132与其他设备共享最近的活动。在各种实施方式中，其他设备已经被认证到切换控制器132，表明他们已经获得从本设备接收最近活动的许可。因此，这些其他设备能够允许用户在其上运行操作系统100的设备上开始活动，并且在另一设备上恢复该活动。
搜索界面136允许用户诸如通过输入文本查询来执行搜索。搜索索引120将相关搜索结果提供到搜索界面136，并且一旦用户进行了选择，则将用户选择结果提供到活动追踪器124。活动追踪器124识别哪个应用与用户选择结果相对应，并且向相关应用发送持续用户活动信号。持续用户活动信号可以包括持续用户活动信号是否属于数据对象或活动对象的指示符。
技术实现要素：
一种移动应用开发系统包括开发商门户和离线分析系统。所述开发商门户被配置为：从第一开发商接收第一应用的拷贝，并且在所述第一开发商经由数字分发平台分发增强应用之前，向所述第一开发商提供路由库用于合并到所述第一应用中。所述路由库被合并到所述第一应用中以形成所述增强应用。所述离线分析系统被配置为分析所述第一应用，以(i)确定所述第一应用内的处理程序(handler)被编程为响应于来自主机操作系统的各个恢复请求来恢复的活动集合，以及(ii)确定所述活动集合的每个活动的参数。所述离线分析系统被配置为生成链接集合。所述链接集合中的每条链接对应于所述活动集合中的相应活动，所述路由库包括指令，所述指令被配置为在将所述增强应用从所述数字分发平台安装到用户设备上之后，从所述用户设备的操作系统接收链接。所述链接标识第一活动。所述路由库包括指令，所述指令被配置为基于与所述第一活动对应的参数来生成第一恢复请求，并且将所述第一恢复请求发送到所述增强应用的所述处理程序。
在其他特征中，与所述第一活动对应的参数包括活动类型和活动标题。在其他特征中，通过continueuseractivity调用将所述第一恢复请求发送到所述增强应用的应用委托。在其他特征中，所述第一个活动包括nsuseractivity对象。
在其他特征中，所述离线分析系统被配置为(i)分析所述第一应用以确定，所述第一应用内的所述处理程序被编程为响应于来自所述主机操作系统的各个恢复请求来访问的数据对象集合，(ii)确定所述数据对象集合中的每个数据对象的参数，以及(iii)生成第二链接集合。所述第二链接集合中的每条链接对应于所述数据对象集合中的相应数据对象。所述路由库包括指令，所述指令被配置为在将所述增强应用安装到用户设备中之后，从所述用户设备的操作系统接收第二链接。所述第二链接标识第一数据对象。所述指令还被配置为基于与所述第一数据对象对应的参数来生成第二恢复请求，并且将所述第二恢复请求发送到所述增强应用的所述处理程序。
在其他特征中，所述第一数据对象是cssearchableitem对象。在其他特征中，通过合并所述路由库，所述增强应用被配置为在安装时将第一统一资源标识符(uri)模板注册到所述操作系统中。所述链接符合所述第一uri模板。在其他特征中，所述第一uri模板指定包括以冒号和两个正斜杠结尾的文本串的方案。所述方案对所述增强应用是唯一的。所述文本串是与所述开发商门户关联的文本标识符和所述第一应用的名称的串联。所述链接以所述方案开始。
在其他特征中，所述离线分析系统被配置为运行所述第一应用，并且在运行期间，监视由操作者启动的从初始状态开始并且前进至第一状态的用户界面(ui)事件序列。所述离线分析系统被配置为将所述ui事件序列存储作为与所述第一状态对应的第一数据结构。所述路由库包括指令，所述指令被配置为响应于所述用户设备的用户在使用所述增强应用时遇到所述第一状态，向所述操作系统发送书签。所述指令被配置为响应于从所述操作系统接收到指示所述第一状态的恢复请求，重放来自所述第一数据结构的所述ui事件序列。
在其他特征中，所述离线分析系统被配置为运行所述第一应用，并且在运行期间，监视与所述第一数据对象对应的由操作者启动的从初始状态开始并且前进至第一状态的用户界面(ui)事件序列。所述离线分析系统被配置为将所述ui事件序列存储作为与所述第一数据对象对应的第一数据结构。所述路由库包括指令，所述指令被配置为响应于所述增强应用的运行，选择性地将所述第一数据对象发送到所述操作系统。所述指令被配置为响应于从所述操作系统接收到指示所述第一数据对象的恢复请求，重放来自所述第一数据结构的所述ui事件序列。
在其他特征中，所述链接选择性地包括序列化数据。所述路由库包括被配置为从所述链接内的所述序列化数据解码出与所述第一活动对应的参数。在其他特征中，所述链接选择性地包括唯一标识符。所述路由库包括被配置为基于所述唯一标识符检索与所述第一活动对应的参数的指令。
在其他特征中，所述移动应用开发系统包括数据服务器，所述数据服务器被配置为存储与所述离线分析系统所确定的活动对应的多个参数。所述路由库包括指令，所述指令被配置为在首次运行所述增强应用时，从所述数据服务器下载与至少所述第一活动对应的参数，以便存储在所述路由库本地的数据存储器中。所述路由库包括被配置为响应于所述唯一标识符从所述数据存储器检索与所述第一活动对应的参数的指令。
一种系统包括上述移动应用开发系统和搜索系统，所述搜索系统被配置为响应于由所述用户设备的用户委托的搜索，将结果返回所述用户设备。所返回的结果中的第一结果包括所述链接。响应于所述用户选择所述第一结果，所述链接由所述操作系统发送到所述路由库。
一种操作移动应用开发系统的方法包括：从第一开发商接收第一应用的拷贝。所述方法包括在所述第一开发商经由数字分发平台分发增强应用之前，向所述第一开发商提供路由库用于合并到所述第一应用中。所述路由库被合并到所述第一应用中以形成所述增强应用。所述方法包括分析所述第一应用，以(i)确定所述第一应用内的处理程序被编程为响应于来自主机操作系统的各个恢复请求来恢复的活动集合，以及(ii)确定所述活动集合的每个活动的参数。所述方法包括生成链接集合。所述链接集合中的每条链接对应于所述活动集合中的相应活动，所述路由库包括指令，所述指令被配置为在将所述增强应用从所述数字分发平台安装到用户设备上之后，所述指令还被配置为从所述用户设备的操作系统接收链接。所述链接标识第一活动。所述指令还被配置为基于与所述第一活动对应的参数来生成第一恢复请求。所述指令还被配置为将所述第一恢复请求发送到所述增强应用的所述处理程序。
在其他特征中，与所述第一活动对应的参数包括活动类型和活动标题。在其他特征中，通过continueuseractivity调用将所述第一恢复请求发送到所述增强应用的应用委托。在其他特征中，所述方法包括分析所述第一应用以确定，所述第一应用内的所述处理程序被编程为响应于来自所述主机操作系统的各个恢复请求来访问的数据对象集合。所述方法包括确定所述数据对象集合中的每个数据对象的参数。所述方法包括生成第二链接集合。所述第二链接集合中的每条链接对应于所述数据对象集合中的相应数据对象。所述路由库包括指令，所述指令被配置为在将所述增强应用安装到用户设备中之后，所述指令还被配置为从所述用户设备的操作系统接收第二链接。所述第二链接标识第一数据对象。所述指令还被配置为基于与所述第一数据对象对应的参数来生成第二恢复请求。所述指令还被配置为将所述第二恢复请求发送到所述增强应用的所述处理程序。
在其他特征中，所述第一数据对象是cssearchableitem对象。在其他特征中，通过合并所述路由库，所述增强应用被配置为在安装时将第一统一资源标识符(uri)模板注册到所述操作系统中。所述链接符合所述第一uri模板。在其他特征中，所述方法包括运行所述第一应用，并且在运行期间，监视由操作者启动的从初始状态开始并且前进至第一状态的用户界面(ui)事件序列。所述方法包括将所述ui事件序列存储作为与所述第一状态对应的第一数据结构。所述路由库包括指令，所述指令被配置为响应于所述用户设备的用户在使用所述增强应用时遇到所述第一状态，向所述操作系统发送书签。所述指令还被配置为响应于从所述操作系统接收到指示所述第一状态的恢复请求，重放来自所述第一数据结构的所述ui事件序列。
在其他特征中，所述方法包括运行所述第一应用，并且在运行期间，监视与所述第一数据对象对应的由操作者启动的从初始状态开始并且前进至第一状态的用户界面(ui)事件序列。所述方法包括将所述ui事件序列存储作为与所述第一数据对象对应的第一数据结构。所述路由库包括指令，所述指令被配置为响应于所述增强应用的运行，选择性地将所述第一数据对象发送到所述操作系统。
所述指令还被配置为响应于从所述操作系统接收到指示所述第一数据对象的恢复请求，重放来自所述第一数据结构的所述ui事件序列。在其他特征中，所述链接选择性地包括序列化数据。所述路由库包括被配置为从所述链接内的所述序列化数据解码出与所述第一活动对应的参数。在其他特征中，所述链接选择性地包括唯一标识符。所述路由库包括被配置为基于所述唯一标识符检索与所述第一活动对应的参数的指令。
在其他特征中，所述方法包括将与所确定的活动集合对应的多个参数存储在数据存储器中。所述路由库包括指令，所述指令被配置为在首次运行所述增强应用时，从所述数据存储器下载与至少第一活动对应的参数，以存储在所述路由库本地的数据存储器中。所述路由库包括被配置为响应于所述唯一标识符从所述数据存储器检索与所述第一活动对应的参数的指令。
根据具体实施方式、权利要求书和附图，本公开的其他适用领域将变得清楚。具体实施方式和具体示例仅仅是用于说明的目的，而不旨在限制本公开的范围。
附图说明
本文中描述的附图仅仅是出于所选实施例的例示性目的，而非所有可能的实施方式，并且不旨在限制本公开的范围。
图1是与操作系统应用索引功能交互的示例应用的图形例示和功能框图。
图2是根据本公开的原理的移动应用环境的高级功能框图。
图3a是路由库与示例应用的集成的示例实施方式的功能框图。
图3b是路由库与另一个示例应用的示例集成的功能框图。
图4是路由库的示例实施方式的功能框图。
图5是根据本公开的原理的移动应用生态环境的示例整体操作的流程图。
图6是路由库的示例操作的流程图。
图7是路由库内的活动和链接处理的示例操作的流程图。
图8是示例遍历面包屑以达到特定状态的流程图。
图9是图2的搜索系统的示例实施方式的功能框图。
图10是根据本公开的原理的针对用户设备的深度链接创建和提供的示例操作的流程图。
图11是离线分析系统的示例实施方式的功能框图。
图12是作为离线分析的部分的为应用创建面包屑(breadcrum)的示例操作的流程图。
图13是作为离线分析的部分的推断以识别其他感兴趣的状态的流程图。
贯穿附图的若干视图，相应附图标记指示相应部分。
具体实施方式
介绍
应用的开发商可以编写代码来利用操作系统(os)功能，在一个示例中，os功能允许对应用内的随后将为用户返回的活动标记书签，或对要在用户设备中的另一个上恢复的活动标记书签。开发商还可以编写将数据提交给os以进行索引的代码，以便os能够诸如响应于全os搜索来显露数据。
为了实现该功能，开发商编写代码，以允许应用恢复到os所指示的活动或与os所指定的数据对象交互的状态。在一些实施方式中，从os接收的活动对象完全指定应用要恢复的活动，即使应用的该具体拷贝先前还未执行过该活动。
同时，对于数据对象，只有当应用的当前拷贝已经存储了该数据对象时，一些应用才能够示出与某个数据对象对应的应用的状态。在其他实施方式中，或对于某些应用，某些数据对象可完全指定应用应该返回查看该数据对象的状态。这通常意味着，数据对象的数据是应用已知的、可被应用访问的，或在持续用户活动请求内被从os提供到应用。对于没有完全指定应用状态的数据对象，这些数据对象可以专用于创建它们的应用，并且不能被应用的其他拷贝访问。
即使开发商针对一些或所有状态或针对一些或所有数据对象已经实现了恢复活动或导航至该数据对象的能力，也不会准备让第三方(诸如，搜索服务或其他应用)直接链接至应用内的那些活动或数据对象。本公开识别开发商所实现的活动，并且提供了当用合适深度链接示出时能够调用应用的内部活动处理的库。这允许利用开发商与os进行交互的努力来提供对第三方的深度链接访问。
对于一些应用，开发商可能还未对一些状态和一些数据实现os搜索功能。对于一些应用，开发商可能还未对任何状态和任何数据实现该功能。因此，本公开描述了开发商如何能够指定应用的哪些状态应该支持该功能。本公开描述了应用如何能够诸如通过记录能够重放的用户界面事件序列来补充以使能应用的该功能从而达到应用的深度状态。
当根据本公开的原理的路由库被用来使能为活动标记书签和数据索引时，路由库的配置可由开发商人员指定。在各种实施方式中，开发商的代理可能能够做出配置决定，诸如，哪些状态要标记书签以及哪些数据要索引，并且这些配置决定被中继到路由库。在各种实施方式中，路由库可周期性更新该配置，使得即使对于已经安装在设备上的应用，开发商也可改变配置。
开发商门户甚至可允许非程序员与开发商协作来指定业务规则。例如，开发商的市场营销或用户体验专业人员可指定向os提交什么数据进行索引，以优化针对给定os的应用的搜索相关性。
根据本公开的开发商门户向开发商提供要集成到应用中的路由库，并且该路由库实现以上功能。例如，基于配置数据，路由库可将伴随os的某些活动标记书签并且可以将要索引的某些数据对象提交给os。配置数据可以在启动应用时生成，并且可手动地、用人工智能或用操作员补充的人工智能生成。
另外，路由库可为来自os的持续活动请求提供服务，诸如，通过执行用户界面事件序列以返回可选择的活动或显示所选数据。路由库还可处理传入链接(诸如，来自其他应用或浏览器实例)。
路由库可采取动态链接库(dll)、dylib或软件开发工具包(sdk)的形式。路由库可由开发商下载并且导入开发商的集成开发环境(ide)(诸如，来自appleinc.的xcodeide)。在一些实施方式中，路由库要么已经被编译，要么包括生成文件(makefiles)和其他配置文件，从而允许编译路由库。
开发商可简单地通过指示ide将路由库添加到他们的应用项目中来集成路由库，诸如，通过将路由库添加到导入列表或所包括的代码模块的列表中。开发商还会需要更新配置文件，以指示路由库将处理某些统一资源标识符(uri)或活动类型。配置文件可采取信息属性列表(info.plist)文件的形式。在各种实施方式中，可将脚本连同路由库一起提供，从而执行配置文件更新以及将路由库导入当前ide项目中。
同时，开发商门户将应用供应到离线分析系统，以确定如何访问感兴趣状态。感兴趣状态可由应用开发商指定或由开发商门户确定。简言之，开发商门户的离线分析系统确定用户将采用什么样的用户界面(ui)动作序列来达到感兴趣状态。该ui动作序列可由用户设备上的应用内的路由库来重放，以达到所关注的状态。换句话说，路由库模拟用户将自己执行的用于达到深度状态的ui动作。
通过模拟ui动作，路由库避免了用户不得不执行每个ui动作，并且将通常比用户手动执行ui动作序列快。当路由库正导航至感兴趣的深度状态时，用户甚至不会看到一些中间状态，或这些中间状态仅是短暂可见的。
针对应用的深层状态的ui动作序列可连同路由库一起集成到应用中，或一旦安装了应用，就可被路由库下载。在一些实施方式中，ui动作序列能够被编码为指定应用并由路由库服务的链接的部分。
无需开发商进一步付出努力，该应用此时具有可被外部源访问的深度链接功能。例如，搜索系统可提供直接导致应用深度状态的结果。或，第三方应用可轻松地将用户导向应用的深度状态。这会增加应用的可见性，并且允许更紧密的集成和对于应用更好的整体用户体验。
另外，既然开发商门户负责深度链接，则深度链接能够被添加或修改，而无需开发商的软件编程人员的辅助，这些软件编程人员可以正忙于其他项目并且有其他优先事务。换句话说，商业人士(诸如，为应用开发商工作的广告或市场营销专业人员)可使用开发商门户来识别应用的哪些状态应该是能深度链接的。商业人士甚至可从深度链接状态列表中删除状态，这全都不需要软件程序人员的辅助。
框图
在图2中，示出了其他细节。如上所述，开发商204向开发商门户208提供应用(称为“appa”)。开发商门户208向开发商204提供被并入appa中的路由库的拷贝，从而创建appa的增强版本。
开发商204将增强appa(为了简便起见其在下面被称为appa)提供到数字分发平台，以便分发给终端用户。数字分发平台212向用户设备提供本地应用，并且可以专用于os。示例的数字分发平台包括google公司的googleplay数字分发平台、apple公司的appstore数字分发平台和microsoft公司的windowsphone数字分发平台。如果开发商204已经将appa提供到数字分发平台212，则在用路由库增强之前，开发商204能够将增强的appa作为appa新版本来发布。
用户设备220的用户从数字分发平台212安装appa(增强的)。在用户设备220中，一个或更多个处理器(其可涵盖通用处理器以及诸如物理传感器处理器和图形处理器的其他协同处理器)执行来自存储器的指令。
这些指令中的一些对应于操作系统224、浏览器228、appa的安装拷贝(被称为appa232)和第三方app(appb236)。操作系统224包括安装的应用注册表240和链接路由器244。链接路由器244接收诸如url(统一资源定位符)和uri(统一资源标识符)的链接，并且确定如何处理这些链接。
通常，链接路由器244通过将链接转发给注册的接收机来处理链接。链接路由器244检查安装的应用注册表240，以确定应用是否声明了与该链接匹配的特定方案、域或其他过滤器。如果没有，则链接可被传递给浏览器228，浏览器228可能已经注册了诸如http(超文本传输协议)、https(http安全)、ftp(文件传输协议)、telnet和gopher的协议的一组方案。
在一些实施方式中，当链接指定网络服务器地址时，链接路由器244可联系web服务器以获得经授权应用的列表。以这种方式，链接路由器244验证已经注册了某个域的应用被该域授权处理链接。这防止应用强占它们不合乎条件的链接。如果已经注册了域的应用被该域的网络服务器主机授权，则链接路由器244可将链接提供到经注册的应用。
从开发商门户208接收的路由库260致使appa232将特定方案或域注册于安装的应用注册表240。该方案可基于开发商门户208的标识符以及appa的标识符。例如，与开发商门户208(诸如，“门户”)关联的测试串可以与对应于应用程序a(诸如，“appa”)的文本串连接。作为具体示例，由appa232注册的方案可以是“portal-appa://”。在其他实施方式中，与开发商门户208关联的文本串可能不是人可读的。
当链接路由器244接收到诸如来自浏览器228的链接(其中，该方案匹配“-portal-appa://”)时，链接路由器244将该链接转发给appa232，其中，链接被路由库260接收和处理。路由库260解析链接并且导航至由链接所指示的深度状态。
仅为了例示，在图2中，示出了视图a268-1、视图b268-2和视图c268-3(统称，视图268)。在许多应用中，将存在不止三个视图。在各种实施方式中，多个或所有视图可由单个视图控制器来控制。在其他实施方式中，每个视图可由单独的视图控制器来控制。
仅为了例示，路由库260被示出为模拟来自由示例链接所标识的预定ui事件序列的事件。链接被路由库260接收并且对应于深度状态，具体地，视图c268--3。ui事件序列包括致使appa232从视图a268-1转变成视图b268-2的第一ui事件、其中appa保留在视图b268-2中的第二ui事件以及致使appa232从视图b268-2转变成视图c268-3的第三ui事件。路由库260将连续地模拟这些ui事件。
操作系统224的搜索系统272从路由库260接收数据和活动对象。路由库260提供用于索引的数据对象和用于标记书签的活动对象。搜索系统272允许用户用appa232搜索数据和/或活动。当用户选择与appa232对应的活动时，搜索系统272将所选活动的指示发送到路由库260。在图3a和图3b中更详细地示出了搜索系统272。
与从开发商门户208向开发商204提供路由库并行地，开发商门户208将appa提供到离线分析系统280。提供给开发商门户208的appa的拷贝可以是标准发布版本，诸如，iosappstorepackage(ipa文件)。
在其他实施方式中，提供给开发商门户208的appa的拷贝可以是允许appa在模拟器中运行的特殊构建，并且可包括在数字分发平台212所分发的应用中一般不存在的符号、调试信息和/或源代码。这可允许离线分析系统280更高效或准确地分析appa。例如，appa的拷贝可以是被设计成在osx操作系统上的来自apple，inc.的模拟器应用中运行的调试构建。相比之下，由数字分发平台212分发的appa的版本是标准发布版本。
如下面更详细描述的，离线分析系统280确定能够由路由库260使用以达到appa232的特定视图的ui事件序列。ui事件序列可被称为由各个面包屑(即，ui事件)的有序序列构成的面包屑路径。为了简单起见，在本公开的其余部分中，术语面包屑(breadcrumb)将用于指面包屑路径。
离线分析系统280可将所确定的面包屑提供到数据服务器284。数据服务器284包括存储经离线分析系统280处理的每个应用的面包屑的数据存储器(诸如，关系数据库)。应用的每种深度状态都与相应的面包屑关联。在一些实施方式中，数据服务器284可被实现为基于云的块存储服务，诸如，可得自amazonwebservices的s3(简单存储服务)服务。
访问机制定义了深度状态如何能够被达到以用于诸如显示广告和深度搜索结果的目的。例如，搜索结果可对应于应用的特定深度状态。搜索结果可以是包含或指示与该深度状态对应的面包屑的链接的深度视图卡片(dvc，参见下文)。针对搜索结果的其他潜在访问机制可包括由应用开发商自己准备的本地深度链接或指向的应用的网页版的标准url。
可用的访问机制中的一个可由搜索系统选择，并且连同搜索结果一起提供到搜索客户端。在其他实施方式中，可在搜索结果内提供多种访问机制，并且搜索客户端响应于用户对搜索结果的选择而确定要使用哪种访问机制。例如，当业务规则指示在本地应用中而不是在这些应用的网页版中呈现结果的偏好时，可在基于网络的访问机制上选择基于面包屑的访问机制。
然而，基于面包屑的访问机制可能仅在应用已安装时可用。在一些实施方式中，搜索客户端可合并或接收对应用进行脚本下载和安装之后将深度链接致动的代码作为搜索结果的部分。可通过向新安装的应用发送基于面包屑的uri来致动深度链接。
数据服务器284还可存储配置设置(诸如，允许链接到哪种深度状态、哪些深度状态被作为活动标记书签以及要索引哪些数据)。开发商204可使用开发商门户208来指定该配置。数据服务器284还可从路由库260接收索引项。例如，路由库260可将活动对象报告回数据服务器284。
然后，数据服务器284能够分析用户与appa232的交互并且生成关于如何提供更多相关搜索结果的信息。另外，来自数据服务器284的数据可被提供回开发商204，本质上提供了一种简单方式来对appa232进行分析，以分析用户的参与。数据服务器284可将用户设备220上的多个应用上的用户活动进行关联，由此进一步改善搜索结果。
路由库与应用集成
在图3a中，appa232的示例包括路由库260，并且还包括由appa232的开发商创建的appa处理程序300。如在图3a的示例中所见，appa处理器300能够持续进行与视图b268-2、视图d-268-4和视图e-268-5相关的用户活动。appa处理程序300与活动创建器304合作，活动创建器304用指示用户正在用appa232执行的活动的活动对象来更新搜索系统272。
在各种实施方式中，搜索系统272可包括与图1中的操作系统100中示出的元件相似的元件。活动创建器304可基于与视图b268-2、视图d-268-4和视图e-268-5关联的用户活动，将活动对象发送到搜索系统272。appa处理程序300还与数据索引器308通过接口连接，数据索引器308可向与视图b268-2、视图d-268-4和视图e-268-5相关的搜索系统272提供数据对象。
如果appa232的开发商通过开发商门户请求了该功能，则路由库260能够调用视图a268-1和视图c268-3。路由库260会能够通过调用相应的视图控制器来访问视图a268-1和视图c268-3，如在2016年8月12日提交的名称为“monitoringandactuationof视图controllerparameterstoreachdeepstateswithoutmanualintervention”的美国专利申请no.15/235,650中更详细描述的，该专利申请的第一发明人是kalyandesineni并且专利代理案卷号为17100-000029-us。该申请的全部公开内容以引用方式并入。
在其他实施方式中，路由库260可通过重放在离线处理中确定的用户界面事件序列来访问视图a268-1和视图c268-3。有关更多信息，参见2016年8月12日提交的名称为“deeplinkingtomobileapplicationstatesthroughprogrammaticreplayofuserinterfaceevents”的美国专利申请no.15/235,859，该专利申请的第一发明人是kalyandesineni并且专利代理案卷号为17100-000032-us。该申请的全部公开内容以引用方式并入。
当由appa232的开发商所开发的活动创建器304将针对视图268中的一些的活动对象提供到活动跟踪器124时，路由库260能够从视图268中的其他提供活动对象。例如，活动创建器304可创建nsuseractivity对象并且调用becomecurrent()方法来将活动对象提供到活动跟踪器124。路由库或appa处理程序300是否发送活动对象可与活动跟踪器124无关。
当活动跟踪器124向appa232发送持续用户活动信号时，路由库260捕获(诸如，通过过载、重载(override)或调配(swizzling)持续用户活动方法)持续用户活动信号。如果持续用户活动信号与appa处理程序300相关，则持续用户活动信号被传递直至appa处理程序300。否则，路由库260对持续用户活动信号进行处理。
类似地，appa232的开发商所开发的路由库260和数据索引器308可各自创建cssearchableitem对象，并且诸如通过使用indexsearchableitems方法将它们引入搜索索引120。当活动跟踪器124向路由库260提供与数据对象相关的持续用户活动信号时，路由库260基于所选的数据对象将视图实例化并且将持续用户活动信号传递直至appa处理程序300。
nsuseractivity对象可包括唯一标识符(诸如，标题)和活动类型。在持续用户活动信号中，活动类型可以将nsuseractivity对象与cssearchableitem对象区分开来。nsuseractivity对象还可包括允许为对象进行索引的文本关键字的列表nsuseractivity对象还可包括一组元数据(诸如，cssearchableitemattributeset)，该元数据可包括图像和其他信息。当对象被包括在一组搜索结果中时，可显示对象的这组元数据，并且向用户给出关于对象是否满足其查询的信息。
cssearchableitem对象包括唯一标识符和一组元数据，其可采用cssearchableitemattributeset的形式。cssearchableitem对象还可包括到期日期，若超过该日期，操作系统将自动删除对象的索引。另外，cssearchableitem对象可包括用于将相关对象分组的域标识符。
在各种实施方式中，路由库260和appa处理程序300二者能够将一个或更多个视图268实例化。例如，appa处理程序300可被编程为指示活动创建器304将相对于视图b268-2的活动标记书签。同时，路由库260可被编程为从视图b268-2提交要索引的数据。
当路由库260接收到持续用户活动信号时，如果持续用户活动信号与标记书签活动相关，则路由库260将持续用户活动信号传递直至appa处理程序300。同时，如果针对视图b268-2的持续用户活动信号与数据对象相关，则路由库260本身导航至视图b268-2，以便显示与数据对象相关的数据。
尽管在图3a中未示出，但是appa232可包括内部链接路由器，内部链接路由器接收深度链接并且基于那些深度链接将视图实例化。对于包括与appa232的内部链接路由器所注册的方案不同的路由库260所注册的方案的链接，路由库260接收深度链接并且基于该链接将视图268中的一个实例化。例如，链接可指定跟随面包屑，以便到达所期望的状态。
路由库260可重载活动创建器304和数据索引器308所调用的方法，以将活动对象和数据对象传递到搜索系统272。以这种方式，路由库260可首先检查活动对象和数据对象，之后再将活动对象和数据对象传递到搜索系统272。然后，路由库260将获悉活动创建器304已经创建了哪些活动对象，因此可以服务与那些活动对象相关的深度链接。类似地，路由库260将得知数据索引器308已经对哪些数据对象进行了索引，然后能够服务与那些数据对象相关的服务深度链接。
为了允许第三方应用和服务使用那些深度链接来访问应用a232，路由库260可将来自活动对象和数据对象的信息上传到远程服务器。为了服务与来自活动创建器304的活动对象和来自数据索引器308的数据对象相关的深度链接，路由库260可生成连续用户活动信号并且将该信号发送到appa处理程序300。appa处理器300可能不知道是从路由库260而不是从搜索系统272接收到持续用户活动信号。然后，appa处理程序300可恢复活动或将与索引数据相关的评论实例化，就好像该请求是直接来自搜索系统272。
在图3b中，示出了另一个示例应用appb360。在appb360中，为了例示，示出了视图364-1、视图364-2、视图364-3、视图364-4和视图364-5(统称为视图364)。appb360不包括与图3a的appa处理程序300相似的内置处理程序。结果，为了访问视图364中的任一个，路由库260包括用于访问视图364中的每个的机制(诸如，面包屑)。
另外，路由库260仅负责生成要发送到搜索系统272的活动对象和数据对象。当路由库260接收到连续的用户活动信号时，路由库260不能传递持续用户活动信号，而是负责处理与数据对象相关的视图的活动的恢复和视图的创建。
路由库
在图4中，路由库260的示例实施方式包括注册数据404。注册数据404向操作系统指示路由库260将处理具有与路由库260相关的方案的链接，并且还将处理与其中并入路由库260的应用相关的持续用户活动信号。在各种实施方式中，注册数据404被包括在被并入路由库260的应用的配置文件中。
uri(统一资源标识符)处理器408从操作系统接收链接。例如，链接可源自浏览器或源自第三方应用。uri处理器408从链接提取唯一id，其可以简单地是在该方案之后的一对正斜杠右侧的uri内的文本。
内部路由器412咨询索引数据存储器416，以确定来自uri的唯一id是否对应于面包屑或对应于将对appa处理程序300进行的活动调用。换句话说，内部路由器412判定是否存在用于到达唯一id所指示的状态的面包屑，或是否应该对appa处理程序300进行到达唯一id所指示的状态的活动调用。当内部路由器412确定唯一id对应于面包屑时，内部路由器412将面包屑id发送到状态机420。
在各种实施方式中，面包屑id可与唯一id相同，或可以是不同的，如来自索引数据存储器416的映射所定义的。如下面更详细描述的，状态机420从面包屑数据存储器424检索面包屑，并且使用ui重放致动器428来执行面包屑内的每个用户界面动作。状态机420可监视appa232的状态，以确保每个用户界面事件在移动到下一个ui事件之前由appa232进行处理。
如果内部路由器412确定来自uri处理器408的唯一id对应于经appa处理程序300处理的活动或数据对象，则向活动调用创建器432发送信号。活动调用创建器432创建指定与链接相关的活动或数据对象的持续用户活动信号。创建持续用户活动信号所需的参数可得自索引数据存储器416。持续用户活动信号经由处理器接口436被传递到appa处理程序300，处理器接口436可向appa处理器300发送持续用户活动信号，就好像appa处理器300正直接从操作系统接收该信号。
如以上提到的，路由库260捕获操作系统所调用的向应用提供持续用户活动信号的方法。然后，路由库260的活动处理程序440接收持续用户活动信号。活动处理器440确定是否应该由开发商已经实现的appa处理程序300来处理持续用户活动信号。该确定可基于索引数据存储器416进行。在这些情况下，活动处理程序440经由处理器接口436将作为通过的持续用户活动提供到appa处理程序300。
在开发商还未对处理程序(诸如，appa处理程序300)进行编码的应用中，活动处理程序440可能永远不会发送通过活动，并且活动调用创建器432和处理程序接口436会休眠。如果活动处理程序440根据索引数据存储器416确定可使用所存储的面包屑恢复持续用户活动信号，则面包屑id被提供到状态机420，以供执行。
到目前为止，已经描述了与传入的深度链接相关的路由库260的各个方面，无论是来自操作系统的链接还是持续用户活动信号的形式。路由库260还可实现将活动对象和数据对象发送到操作系统的功能。这允许操作系统从应用返回搜索结果。
数据索引器460基于来自业务规则数据存储器464的规则来确定要索引应用的哪些数据对象。仅作为示例，数据索引器460可在应用在设备上成功运行时，响应于应用加载信号来执行。数据索引器460可在应用首次执行时，将预定的数据对象集合经由操作系统接口468发送到操作系统。
仅作为示例，关于数据对象，操作系统接口468可仅仅是对indexsearchableitems()方法的调用。在后续加载应用时，数据索引器460可基于其持续的相关性，基于对应用程序进行的数据更改，或基于来自业务规则数据存储器464的规则改变来更新索引数据对象。
例如，如果正在为菜肴名称进行索引，则当在应用中添加新菜肴名称时，数据索引器460可将附加菜肴名称添加到操作系统索引中。同时，如果业务规则数据存储器464被更新以指示菜肴名称不应再被索引，则数据索引器460可从操作系统索引中删除对应的数据对象。
数据存储更新器472负责更新一个或更多个数据存储器，包括面包屑数据存储器424、索引数据存储器416和业务规则数据存储器464。数据存储更新器472经由网络接口476联系图2的数据服务器284。网络接口476可处理认证和加密，使得可确认数据存储器更新的有效性。
数据存储更新器472可在并入路由库260的应用首次在设备上打开时进行操作，并且以随后周期性间隔进行操作。另外，数据存储更新器472可响应于数据需求(诸如，如果在面包屑数据存储器424中不存在面包屑id)来执行附加的更新。
活动创建器480创建活动对象，以用操作系统为活动标记书签。操作系统接口468可通过在所创建的活动对象上调用becomecurrent()方法来为活动标记书签。活动创建器480可响应视图出现(诸如，viewdidappear信号)，或响应于某个其他事件(诸如，视图加载或即将出现)。
活动创建器480可随着与视图交互的发生而更新活动对象。因此，活动创建器480可捕获向视图提供用户输入的附加方法，使得对应的活动对象可被更新。例如，当用户编辑文本框时，活动创建器480可在每次击键之后更新活动对象。
除了创建活动对象之外，活动创建器480可向数据索引器460指示应该对某些数据对象进行索引。这些决定可以是基于来自业务规则数据存储器464的规则。例如，活动创建器480可基于用户查看特定菜肴的餐厅列表来创建活动对象。通过业务规则数据存储器464来确定是否创建了该活动对象。业务规则数据存储器464还可规定，活动创建器480向数据索引器460发信号，通知应该对搜索得到的头一个或更多个结果进行索引。
例如，如果用户正在查看一组泰国餐厅并且最相关的结果是amarinthai餐厅，则用户可能稍后希望搜索amarinthai。通过索引amarinthai数据对象，操作系统可直接向应用提供针对amarinthai的结果。另外，根据操作系统索引如何识别搜索结果，在操作系统内搜索“泰国”的用户可看到与泰国餐厅列表相关的应用的活动以及特定amarinthai数据对象二者。
当操作系统发送与来自活动创建器480的活动对象或来自数据索引器460的数据对象中的一个相关的持续用户活动信号时，在面包屑数据存储器424中将存在用于到达这些活动对象或数据对象的对应面包屑，因为开发商并没有对应用本身进行编程以适应它们。
由活动创建器480和数据索引器460分别创建的活动对象和数据对象被提供到索引数据存储器416，使得索引数据存储器416获悉哪些活动对象和数据对象可由路由库260处理而不是通过appa处理程序300传递。
远程索引器484可以由业务规则数据存储器464指示以将来自索引数据存储器416的活动对象和/或数据对象与远程索引建立镜像。该远程索引可由路由库260的供应商或通过搜索服务来维护。可用私有标识符来标记(或假定是私有的，除非用公共标识符标记)活动对象和数据对象。该私有标识符可防止对象被上传到远程索引，或可防止对象被公开搜索结果中的远程索引暴露。作为应用向开发商门户的引导过程的部分，开发商可提供该私有指示，并且可随时间推移由开发商来更新该私有指示。
搜索系统288从数据服务器284接收合并面包屑标识符或面包屑本身的访问机制。搜索系统288可能已经具有关于appa的感兴趣状态的信息，然后可将访问机制与相应状态关联。在其他实施方式中，搜索系统288可抓取并刮取appa，以获得感兴趣状态的元数据，并且可遵循访问机制来查找状态的内容。
在一种使用模型中，用户设备220的用户执行针对某种功能和/或针对某个实体(诸如，对感兴趣餐厅的评论)的搜索。用户可用独立的搜索应用执行该搜索，或如图2中所示，经由浏览器228来执行网络搜索。如以下更详细描述的搜索系统288将搜索结果提供到浏览器228。
这些结果可包括与appa232对应的结果，并且可包括指示appa232中的特定深度状态的链接。如果用户选择了与appa232对应的链接，则该链接被转发到链接路由器244，然后被传递到appa232的路由库260。然后，应用a232受到路由库260的控制，以使用对应的面包屑显示所指示的深度状态。
在各种实施方式中，路由库260从链接本身内编码的参数接收面包屑的内容。例如，链接(在这种情况下，uri)可包括得到所期望视图的连续的面包屑的每个ui事件序列化编码所遵循的方案(“portal-appa://”)。例如，可在使用base64编码的json(javascriptobjectnotation)数据结构中指定面包屑。
因此，搜索系统288能够提供将把用户直接带到appa232内的相关内容的链接。搜索系统288可将搜索结果提供到其他应用。例如，宾馆应用可向搜索系统288查询用户所选的宾馆附近的餐厅，并且搜索系统288可将餐厅搜索结果提供到宾馆应用。在appa232是餐厅评论应用的情况下，酒店应用可直接链接到与感兴趣的餐厅对应的appa232的深度状态。搜索系统288可按dvc的形式提供搜索结果。
针对应用或应用状态的dvc示出其他信息，而不仅仅是应用或应用程序状态的识别。例如，该信息可包括应用状态的标题或对应用状态的描述，其可以是来自应用状态的文本的片段。其他元数据可以是由应用状态提供的，包括图像、位置、评论数、平均评论和状态指示符。例如，根据当前时间是否在业务的运行时间内，可将“现在开门”或“关门”的状态指示符应用于该业务。
某些dvc会强调导致dvc被选择为搜索结果的信息。例如，可用粗体或斜体显示dvc内的与用户查询匹配的文本。dvc还可并入允许直接动作的元素(诸如，立即呼叫设施或直接转换到地图应用以检索通向该设施的导航指示的能力)。
与dvc的其他交互(诸如，轻击或点击dvc中的任何其他区域)可将用户带到所指示的状态或应用。如下面更详细描述的，这可通过打开相关应用来实现，或如果未安装该应用，则打开与所期望应用状态相关的网站。在其他实施方式中，未安装的应用可被下载、安装并且然后被执行，以便达到所期望的应用状态。
换句话说，dvc包括针对应用或状态的识别信息以及来自应用或状态本身的附加内容。附加内容允许用户对于选择哪个结果做出更明智的选择，并且甚至可允许用户直接执行动作，而不必导航至应用状态。如果用户想要采取的行动是获得信息，则在某些情形下，dvc本身可提供必要的信息来完成此行动。
在各种实施方式中，对于每个应用而言，路由库可以是相同的，唯一的例外是路由库在安装时将注册的自定义方案的名称。该方案可以是通过将开发商门户的文本与应用名称的文本连接而形成的，并且可包括诸如连字符或下划线的分隔符。应用的名称可随时间推移而改变，但是该方案会在首次设置之后被修复，以提供与其路由库只能识别原始方案的旧版本应用的向后兼容性。
在各种实施方式中，可在维护向后兼容性的同时，用安全更新、错误修复和特征添加来更新路由库。开发商204(诸如，开发商204)可在每次向数字分发平台212发布其新版本的应用时下载并且并入最新版本的路由库。在一些实施方式中，当解析依赖链接(linkerdependencies)时，构建/编译过程可自动下载最新版本的路由库。
每当开发商204为数字分发平台212准备新版本的appa时，会需要调用离线分析系统280。另外，当开发商204将更多内容添加到appa时，可调用离线分析系统280来确定访问所添加内容所需的面包屑。对离线分析系统280的调用可在开发商204请求时执行，或可定期来执行。数据服务器284存储对面包屑进行的任何更新或添加，并且可将其提供到搜索系统288，使得搜索结果内的链接具有最新的访问机制。
在一些实施方式中，面包屑可使用uri中直接包括的机制之外的机制而被传送到路由库260。例如，当最大长度的链接比编码后的面包屑可能需要的字符数更短时，这会是必要的。
因此，在一些实施方式中，路由库260可从数据服务器284下载面包屑的分组。然后，来自搜索系统288或其他链接的搜索结果可引用路由库260映射到面包屑的唯一标识符。仅作为示例，唯一标识符可由功能和实体(诸如，“restaurant_reviews”和“amarin_thai”)形成。在一个具体示例中，uri“portal-appa://restaurant_reviews/amarin_thai”可被路由库260解析为从appa232的默认状态到达对amarinthai餐厅的餐厅评论状态的面包屑。然而，不需要唯一标识符是人可读的。
在其他实施方式中，路由库260可响应于接收深度链接而咨询数据服务器284。通过提供唯一标识符，路由库260可从数据服务器284下载必要的面包屑。在这些实施方式中，路由库260可缓存面包屑，使得不需要进行网络访问来解析最近访问的深度链接。诸如当appa232首先在用户设备220上执行时，也可执行一些或全部面包屑的预先高速缓存。
预先高速缓存甚至可更早地发生，诸如，当开发商204正准备待分发的appa时。换句话说，面包屑的整个集或子集可连同应用a一起被包括，使得当经由链接接收到唯一标识符时，路由库260能够在没有延迟的情况下选择合适面包屑。预先高速缓存可与路由库260对面包屑的定期验证(诸如，通过以定期日历间隔(诸如，一个月一次)检查面包屑包的版本号)相结合。在其他实施方式中，数据服务器284可向路由库260发送指示新面包屑可用的推送通知。
就开发商204已经在appa内实现了一些深度链接而言，appa232中的开发商实现的路由器(未示出)将从链接路由器244接收链接。开发商的路由代码不会注册“portal-appa://”，而是独立于开发商门户208的方案(诸如“appa.com:”)。在各种实施方式中，开发商-指定的uri不能是公众可用的，或可仅是与开发商204建立了一定关系的公司可用的。
一些操作系统(包括ios操作系统)具有沙盒基础结构，用于限制应用超出已经专门分配给应用的资源或内存区域的范围。沙盒增强了安全性，从而使恶意软件更难以连累用户系统。因为路由库260在appa232的背景内执行，所以沙箱应该对路由库260和负责视图268的视图控制器之间的交互没有任何困难。
高级流程图
在图5中，关于一个开发商和一个应用的本公开的操作的概述始于504。开发商首先开发应用(这里被称为“appa”)。appa可能不具有可将深度链接暴露给其所有状态的功能。另外，appa可能针对一些或所有状态，没有索引功能或活动恢复功能。另外，appa拥有的任何深度链接或搜索功能都会需要编程人员干预才能修改。结果，开发商可得益于本发明所描述的路由库。
在508中，开发商将appa的拷贝提供给开发商门户。这可以是标准的构建，诸如，将提供到数字分发平台的内容。事实上，如果appa已经被发布到数字分发平台，则开发商门户会从数字分发平台检索appa的拷贝。虽然标准构建一般限制于在仿真器或硬件设备上运行，但是开发商可替代地提供appa的特殊构件(诸如，针对仿真环境定制的构建)。与应用(可在基于arm架构的用户设备硬件上运行)相比，仿真环境甚至可在不同的架构(诸如，x86架构)上运行。
在512中，控制开始appa的离线分析。离线分析可包括确定appa中已经存在深度链接的状态。离线分析还可包括确定哪些活动可在appa内恢复，其中，可以通过appa基于开发人员编写的代码对数据进行索引。仅作为示例，离线分析可包括appa的静态和动态分析，这在2015年12月30日提交的名称为“staticanalysisandreconstructionofdeeplinkhandlingandcompiledapplications”的美国申请no.14/984,642中有更详细的描述，该申请的第一发明人是kalyandesineni并且专利代理案卷号为17100-000030-us。该申请的全部公开内容以引用方式并入。
在516中，开发商指定appa的业务规则。例如，开发商向开发商门户指定针对appa的哪些状态提供深度链接功能、appa的那些活动要被标记书签以及要索引什么数据。开发商可浏览appa的拷贝，以便指定要针对哪些状态提供深度链接。例如，开发商可以在仿真器中与appa交互，而离线分析平台监视供后续重放的用户界面事件。
可简单地请求开发商导航至感兴趣状态，而不需要理解为了深度链接目的而记录用户界面事件。对于开发商导航至的每种状态，开发商可指定在该状态下正在执行的一个或更多个活动是否应该被标记书签，并且可以识别要从该状态进行索引的一个或更多个数据片段。开发商可指定正被索引的数据包括哪些元数据，并且可将活动或数据标记为公共的或私人的。
在520中，与离线分析并行地，控制提供从开发商门户到开发商的路由库的拷贝。在524中，开发商将路由库集成到appa中。例如，这可包括将配置文件中的引用添加到由路由库的链接能力处理的方案中以及添加将认识路由库的活动的类型。
在一些实施方式中，路由库识别的活动将带有已经被appa识别的活动的冗余，诸如，当appa已经允许进行一些活动恢复或数据索引。开发商还将二进制文件链接到集成开发环境中的appa项目。在各种实施方式中，脚本可被提供给开发商，以执行合并动作524。
在528中，开发商编译此时包括路由库的appa，并且将appa提供到一个或更多个数字分发平台。在532中，用户设备的用户安装来自数字分发平台安装的appa。在536中，作为安装的部分，appa的路由库注册由路由库处理的自定义链接方案以及由路由库处理的活动类型。例如，该注册可以由操作系统基于诸如info.plist的配置文件来执行。
在540中，现在安装的应用的路由库更新了访问机制和业务规则。例如，访问机制可以是用于达到某些状态的面包屑。业务规则识别应该访问哪些状态、哪些活动应该被标记书签、哪些数据应该被索引。
当应用首次运行时，路由库可下载一整套访问机制和业务规则，使得在需要访问机制或业务规则时，不会招致访问等待时间。在其他实施方式中，在首次运行时，路由库仅下载访问机制的子集，诸如，针对最普及状态的访问机制。540中的更新可在每次打开该应用时执行或以预定间隔来执行。另外，如果缺少所需的访问机制(例如，面包屑)或如果访问机制表现为不工作，则路由库可更新访问机制和/或业务规则。
在544中，路由库根据业务规则对开发商所指示的数据进行索引。例如，当应用首次加载时，路由库可对开发商所指示的数据集进行索引。然后，当数据在appa中被修改时，路由库可基于更新后的数据来更新操作系统索引。在548中，路由库书签选择用户参与的活动。例如，当用户执行搜索时，搜索标准和过滤器可被标记书签标记为用户可在该设备上恢复或切换到另一设备的活动。
在552中，appa中的路由库处理从操作系统提供到路由库的专有appa链接(由注册方案指示)。在556中，路由库处理操作系统所发送的活动，包括持续用户活动信号。这些活动可参照标记书签的活动或被索引的数据。然后，控制返回540。虽然串行地显示了540、544、548、552和556，但是它们可异步地并行运行。
路由库操作
在图6中，示出了路由库的示例操作。在604中，在将appa安装到设备上期间，注册路由库中的专有appauri方案和活动类型。这可由操作系统用配置文件(也称为清单文件)来执行，这是安装处理的部分。在608中，控制请求来自数据服务器的面包屑和配置数据。这可在用户设备上首次执行appa时执行。
在612中，控制确定是否已经从操作系统接收到活动或专有appauri。如果是这样，则控制转移到616；否则，控制转移到620。在616中，控制调用用于活动或专有appauri的处理程序。例如，处理程序可如图7所示地实现。仅作为示例，处理程序可响应于操作系统接收到的openurl()调用或操作系统所生成的持续用户活动信号。在处理活动或专有appauri之后，控制返回612。
在620中，控制确定是否已经发生了活动触发事件。如果是这样，则控制转移到624；否则，控制转移到628。活动触发事件可以是状态的加载或在状态内执行的动作。开发商可指定哪个事件有资格成为活动触发器。开发商可建立业务规则，规定在进入某些状态时该状态触发活动，而对于其他状态，在执行某些其他动作(诸如，用户输入)时，为活动标记书签。
在624中，控制确定返回该活动的面包屑是否可用。如果是这样，则控制转移到632；否则，控制转移到636。如果返回该活动的面包屑不可用，则路由库可能不能够在操作系统请求时恢复该活动，因此不会为该活动标记书签。在632中，面包屑是可用的，因此控制向操作系统发送活动对象来为活动标记书签。
在636中，控制确定活动是否已经被开发商指示为是公共的。如果是这样，则控制转移到640；否则，控制继续进行628。在640中，该活动已经被指示为是公共的，因此控制将该活动上传到远程索引。然后，控制继续进行628。在其他实施方式中，控制可将活动上传到远程索引，而不管该活动是否已被指示为是公开的，而替代地使用公开指示符来确定是否向远程索引的任何用户揭示该活动。
在628中，控制确定是否应该根据开发商建立的业务规则对数据进行索引。如果是这样，则控制转移到644；否则，控制转移到648。例如，当首次运行appa时，可能有一组预定数据对象是开发商希望索引的。然后，在某些状态已经被访问之后，开发商可能已经指定了与这些状态相关的数据应该被索引。例如，在音乐流媒体应用中，如果用户已经查看了特定流派的艺术家列表，则可将与艺术家中的每个对应的数据对象添加到操作系统索引中。
在644中，如果开发商已经指示的数据对象的面包屑应该被被索引，则控制转移到652；否则，控制继续进行648。在652中，通向可访问该数据对象的状态的面包屑可用，因此数据对象被发送到操作系统。如果面包屑不可用，则路由库将不能够服务来自操作系统的将数据对象示出给用户的请求。
虽然图6示出了路由库的操作，但是开发商可能已经独立于路由库在appa内实现了将对数据对象进行索引和为书签加活动的逻辑。路由库的操作并没有妨碍索引和标记书签。因此，即使当路由库对数据对象进行索引或为活动标记书签时，appa本身也可能正在执行该任务。为了使appa在操作系统的指示下恢复活动，appa将具有由开发商实现的用于达到适宜状态的逻辑。该逻辑可包括视图控制器的直接致动，或可包括与路由库所使用的用户界面面包屑相似的用户界面面包屑。
控制从652继续到656，其中，如果数据对象被指示为是公共的，则控制转移到660；否则，控制继续进行648。在660中，控制将数据对象上传到远程索引并且继续进行648。同样，在将数据对象上传到远程索引时，可忽略公共标识符，而在确定是否向其他用户揭示数据对象时，可将其考虑在内。
在648中，控制确定过去面包屑和配置数据的最后数据更新是否大于预定时间。如果是这样，则控制转移到664，更新该数据；否则，控制返回612。虽然被示出为预定的时间量，但是可基于应用的使用频率、面包屑或配置数据历史已经改变的频率来动态地执行数据更新，和/或数据更新可基于来自数据服务器的指示数据应该被更新的推送信号。
活动/uri处理
在图7中，示出了用于处理活动和专有uri的示例路由库操作。在各种实施方式中，图7的处理可被图6中的616调用。控制从704开始，在704中，如果已经接收到专有appauri，则控制转移到708；否则，控制转移到712。
在708中，控制确定uri是否对应于预先存在的数据对象，也就是，appa能够独立于路由库进行索引和显示的数据对象。如果uri对应于此预先存在的数据对象，则控制继续进行716；否则，控制转移到720。在716中，路由库将能够使用appa内的预先存在的访问机制来显示与该数据对象相关的状态。为了实现此，控制可准备与操作系统将向应用a提供的活动请求相似或相同的活动请求，是为了显示与该数据对象相关的状态。然后，控制继续进行724，在724中，所准备的活动请求被传递到独立于路由库的开发商所编写的预先存在的appa处理程序。然后，控制继续进行712。
在720中，控制确定uri是否对应于预先存在的活动-也就是，appa能够独立于路由库进行标记书签和恢复的活动。如果是这样，则控制转移到728；否则，控制转移到732。在728中，控制准备识别预先存在的活动的活动请求。活动请求可与操作系统将提供到appa的请求相似或相同，是为了恢复标记书签活动。然后，控制继续进行724。
在732中，控制确定uri是否对应于面包屑。如果是这样，则控制转移到736；否则，控制转移到740。虽然被称为面包屑，但是访问机制可以是路由库用来导航至某种状态的另一种机制。例如，可用一组参数对路由库进行编程，从而允许用特定的输入参数来调用特定的视图控制器，以达到某种状态。在736中，控制重放面包屑(诸如，使用图8中示出的处理)。然后，控制继续进行712。
在740中，专有appauri不能被传递到预先存在的appa处理程序，并且不存在访问机制(诸如，面包屑)。结果，执行错误处理。例如，错误处理可包括向用户显示指示链接失效并且将用户引导到应用的默认状态的消息。在显示消息之前，控制可刷新所下载的面包屑，以确保最新的面包屑可用。作为另一个示例，控制可尝试查找并随后遍历可比较的uri(诸如，通过查询过时的uri与活动的uri的映射)。然后，控制继续进行712。
在712中，如果应用a(例如，通过appa的app代理)接收到活动请求(诸如，持续用户活动方法调用)，则控制转移到744；否则，控制转移到748。在744中，控制确定活动是否已经被开发商处理。如果是这样，则控制转移到752；否则，控制转移到756。
在752中，活动由路由库处理，因为路由库为对应的活动标记书签或对对应的数据对象进行索引。可通过重放与活动请求所识别的状态对应的面包屑来恢复活动。例如，这可如图8中所示地执行。然后，控制返回图6。
在756中，如果路由库获悉appa处理至少一些活动请求，则控制继续进行760。否则，如果路由库确信appa原本不能处理任何活动，则控制转移到764，在764中，执行错误处理。例如，错误处理可包括显示活动请求不能被满足的错误消息。
在760中，活动请求被传递到预先存在的appa处理程序，希望appa处理程序可处理活动请求。然后，控制从图7返回。在748中，执行错误处理，因为既还未收到专有appauri，也还未收到活动请求。除了活动请求或专有appuri之外，控制不能获悉接收到的内容，因此不会向用户显示任何内容，而只是将用户带到应用的默认状态。然后，控制从图7返回。
面包屑遍历
在图8中，示出了当遍历面包屑时路由库的示例操作。控制从804开始，在804中，如果面包屑被内置于uri中，则控制转移到808；否则，控制转移到812。
如上所述，允许路由库导航至某些深度状态的面包屑可在链接中被接收，或可用链接中的唯一id来指示。当用唯一id指示时，路由库可能不得不向数据服务器请求面包屑。在一些实施方式中，路由库因此将预先高速缓存一些或全部面包屑。如果面包屑将总是在链接中被接收到，则可省略该操作。
在一些实施方式中，编码时的某些面包屑比链接的最大允许长度长。该最大长度可由浏览器、操作系统或某种其他技术或业务限制来控制。因此，这些面包屑可得自数据服务器，而较短的面包屑被包含在uri内。以这种方式，当将不超过最大链接长度时，uri的生成器(诸如，搜索系统)准备包括面包屑数据本身的uri，否则仅包括面包屑的唯一标识符。
在808中，控制从uri解码出保持(hold)面包屑的数据结构，并且控制继续进行816。在812中，由于面包屑未被包括在uri中，所以控制确定面包屑是否已经被存储在面包屑数据存储器中。如果是这样，则控制使用面包屑数据存储器中的面包屑并且继续进行816；否则，控制转移到820。在820中，控制向数据服务器请求面包屑，并且当返回了面包屑时，控制继续进行816。
在各种实施方式中，路由库在面包屑之一将用uri指示之前检索面包屑的初始集。例如，路由库可以与面包屑的初始集一起预先打包，或路由库可在在用户设备上安装或首次执行时下载面包屑的初始集。路由库可定期(例如，经由后台进程)接收新的面包屑，以补充功能。在一些实施方式中，因面包屑总是得自数据存储器并且从不从数据服务器检索，用户体验可得到改善。这最大限度地减少了从数据服务器获得面包屑导致的响应延迟，并且避免了源自网络连接问题的可用性问题。
在816中，控制器按面包屑所指定的顺序来选择第一ui事件。在824中，控制用面包屑重放所选的ui事件。在828中，控制确定是否成功重放所选的ui事件导致下一个视图或如预期地更新当前视图。在各种实施方式中，控制可在检查成功之前等待预定的时间段。该预定时间段允许app响应ui事件。
在各种实施方式中，面包屑数据结构可包括可应用于所有ui事件的指定的等待时间，或可具有用于每个ui事件的单独的等待时间。作为面包屑确定处理的部分，离线分析系统可检测到app响应某些ui事件花费更长的时间。在这些情况下，离线分析系统可指示在重放另一个ui事件之前应该实现额外的延迟时间段。
在828中，反而当路由库检测到已经用与重放事件对应的某些参数调用了方法时，可识别成功。换句话说，作为离线分析的部分，可记录app对ui事件的预期响应。当发现该预期反应时，可推断成功。如果在828中ui事件看上去已经被成功处理，则控制转移到832；否则，控制转移到836。
在836中，控制等待另一个预定时间段。该另外的一段时间可允许对ui事件的相应意外地缓慢。控制继续进行840，在840中，控制再次试图验证重放所选的ui事件已经成功地导致预期行为。如果是这样，则控制继续进行832；否则，控制转移到844。在844中，如果所选的ui事件已经被重放两次以尝试获得成功的响应，则控制转移到848。
在848中，声称有错误。例如，错误处理可致使应用恢复主状态，并且向用户显示深度链接不成功的通知消息。另外，可向数据服务器发送指出深度链接不成功的消息。然后，控制从图8返回。在844中，如果所选的ui事件仅仅已经被单次重放，则还没有第二次失败，因此控制返回824，尝试第二次重放所选的ui事件。
在各种实施方式中，成效未被评估，并且ui事件被串行重放，期望在大多数情形下将达到所期望的深度链接。结果，可用简单的等待步骤来取代元素828、836、840、844和848。等待步骤可等待凭经验确定允许应用响应用户输入的预定延迟。等待步骤可在应用不能处理ui事件的系统中，与它们可被路由库重放的一样快。在其他实施方式中，等待步骤可涉及等待由ui事件导致的方法调用。一旦检测到应用对ui事件的响应(诸如，通过观看某些方法调用)，则控制可允许重放以下的ui事件。在832中，如果有另外的ui事件，则控制转移到852；否则，控制从图8返回。在852中，控制选择面包屑中的下一个ui并且返回824。
搜索系统
在图9中，搜索系统288的示例实施方式包括搜索模块900。搜索模块900包括查询分析模块904，查询分析模块904接收查询包装器，查询包装器可采取图2的浏览器228所发送的url内的查询串的形式。查询分析模块904分析来自查询包装器的文本查询。例如，查询分析模块904可对查询文本进行标记，过滤查询文本并执行词干、同义词和停词去除。查询分析模块904还可分析查询包装器内的其他数据。查询分析模块904将标记化查询提供到集合生成模块908。
集合生成模块908基于查询令牌，从搜索数据存储器910中识别应用状态记录的考虑集合。应用程序(等同于应用)状态记录对应于应用的特定状态。在各种实施方式中，搜索数据存储器910还可包括应用记录。在各种实施方式中，应用记录可被存储作为应用状态记录，应用状态记录对于应用的特定状态而言仅仅具有预定值(诸如，零值)。
可通过根据本发明的原理爬行和刮取(crawlandscrape)应用来产生搜索数据存储器910中的应用状态记录。搜索数据存储器910的记录中的一些或全部内容可按倒排索引(invertedindices)被索引。在一些实施方式中，集合生成模块908使用apach软件基金会(apachesoftwarefoundation)的apachelucene软件库来识别来自倒排索引的记录。集合生成模块908可搜索倒排索引，以识别包含一个或更多个查询令牌的记录。当集合生成模块908识别到匹配的记录时，集合生成模块908可将所识别的每个记录的唯一id包括在考虑集合中。例如，集合生成模块908可将查询条目与应用状态记录中的应用状态名称和应用属性(诸如，文本描述和用户评论)进行比较。
另外，在一些实施方式中，集合生成模块908可确定关于搜索查询的记录的初始分数。初始分数可指示记录的内容与查询的匹配程度。例如，初始分数可随各个查询条目的词频-逆文档频率(tf-idf)值的变化而变化。
集合处理模块912接收由集合生成模块908识别的应用状态记录的唯一id，并且确定针对一些或全部id的结果分数。结果分数指示应用状态相对于标记化查询和上下文参数的相关性。在各种实施方式中，较高分数指示较大的感知相关性。
例如，查询包装器中的其他条目可充当上下文参数。地理位置数据可限制与用户设备的位置无关的应用的分数(或仅仅一起删除)。查询包装器中的黑名单会致使集合处理模块912从与黑名单中的标准匹配的考虑集合中去除应用记录和/或应用状态记录，或将它们的分数设置成零值(诸如，零)。
集合处理模块912可基于一个或更多个评分特征(诸如，记录得分特征、查询得分特征和记录查询得分特征)来生成结果分数。示例记录得分特征可以是基于与记录关联的测量，诸如，在搜索期间记录被多久被检索一次以及由用户选择基于记录生成的链接的频率。查询评分特征可包括但不限于搜索查询中的词语的数量、搜索查询的受欢迎程度以及搜索查询中词语的预计频率。记录查询评分特征可包括指示搜索查询的条目与对应id所指示的记录中的条目的匹配程度的参数。
集合处理模块912可包括被配置为接收一个或更多个评分特征的一个或更多个机器学习模型(诸如，监督学习模型)。这一个或更多个机器学习模型可基于记录评分特征、查询评分特征以及记录查询评分特征中的至少一个来生成结果评分。
例如，集合处理模块912可将搜索查询与每个应用状态id配对，并且针对每个{查询，id}对计算特征的向量。特征的向量可包括一个或更多个记录评分特征、一个或更多个查询评分特征以及一个或更多个记录查询评分特征。在一些实施方式中，集合处理模块912对特征向量中的评分特征进行归一化。集合处理模块912可将不相关的特征设置成零值或零。
然后，集合处理模块912可将针对应用状态id之一的特征向量输入机器学习回归模型中，以计算该id的结果分数。在一些示例中，机器学习回归模型可包括一组决策树(诸如，梯度提升的决策树)。另外或另选地，机器学习回归模型可包括逻辑概率公式。在一些实施方式中，机器学习任务可被构建为半监督学习任务，其中，少数训练数据带有人类策划分数的标记，其余的是在没有人类标签的情况下使用的。
机器学习模型输出id的结果分数。集合处理模块912可计算集合处理模块912接收的id中的每个的结果分数。集合处理模块912将结果分数与相应的id关联，并且输出最相关得分的id。
结果生成模块924可从集合处理模块912所选的应用记录和应用状态记录中选择特定的访问机制。结果生成模块924然后准备返回用户设备的结果集。尽管这里被称为“应用状态结果”，但是访问机制中的一些可对应于应用的默认状态(例如，主页)—这些可以是应用状态记录的特例或可以是应用记录。
结果生成模块924可基于应用是否安装在设备上来选择用于应用状态记录的访问机制。如果安装了应用，则选择将应用直接导向指定状态的访问机制。此外，如果未安装应用，则在将应用导向指定状态之前，所选的访问机制首先诸如经由脚本来下载和安装应用。将应用导向指定状态可包括直接启动指定状态的单个命令或数据结构(诸如，android操作系统中的意图)。对于其他应用，可以使用脚本或其他序列将应用导向某个状态(诸如，主或默认状态)，然后导航至指定状态。
结果生成模块924可基于针对正被发送结果的用户设备的操作系统身份和版本来生成或修改访问机制。例如，结果生成模块924可针对特定操作系统完全形成用于下载、安装、导向和导航至指定状态的脚本。
如果结果生成模块924确定本地访问机制中没有一个有可能与用户设备兼容，则搜索模块900可向用户设备发送网络访问机制。如果没有网络访问机制可用，或出于某种原因(例如，如果网络访问机制依赖于未安装在用户设备上的java编程语言)而将与用户设备不兼容，则结果生成模块924可省略结果。
服务器端的控制
在图10中，服务器端组件的操作可在单个设备内执行，或可跨图2的开发商门户208、离线分析系统280、数据服务器284和搜索系统288执行。在各种实施方式中，开发商门户208、数据服务器284和搜索系统288可处于同一实体的控制下。离线分析系统280可采用有助于静态分析和/或动态分析的操作者，以确保从每个应用提取准确和完整的参数。
控制从1002开始，在1002中，使路由库对应用开发商是可用的。随时间推移，路由库会被更新，最新的版本可以是应用开发商可用的唯一版本。在1004中，如果已经接收到专有对面包屑的请求，则控制转移到1006；否则，控制转移到1008。在1006中，控制确定自从请求方接收到最后的请求起已经发生改变的面包屑的子集。然后，可在1010中提供该子集，以使数据在请求来源处被最新。然后，控制返回1004。
在1008中，如果已经启动了对应用的离线处理，则控制转移到1012；否则，控制转移到1016。在1016中，如果已经从搜索系统接收到搜索查询，则控制转移到1020；否则，控制返回1004。在1020中，控制确定与搜索查询对应的结果的考虑集合。该考虑集合可包括对搜索查询开放的应用以及与搜索查询相关的应用的特定状态(深度状态)。
在1024中，控制基于它们匹配所理解的搜索查询意图的程度来对考虑集合中的元素进行评分。然后，可从最相关到最不相关进行评分结果的排名。在1028中，排名最高的结果被格式化为与指向结果内的特定状态的深度链接关联的深视卡(deepviewcard)。在1032中，控制将深视卡返回查询的请求者。
深视卡不会被完全呈现，而是包括图像、文本和关于如何针对特定屏幕大小、取向和请求应用或操作系统的其他要求来呈现深视图卡片的图像、文本和指令。对于路由库根据本公开的原理赋予深度链接的应用而言，与对应搜索结果一起返回的访问机制可包括具有编码后的数据结构的uri。
编码后的数据结构可包括从应用内调用该特定状态所必需的面包屑。作为字符串的uri包括该数据结构的序列化版本，并且以方案为前缀。诸如“portal-appa://”的方案将致使uri被转发到应用的路由库并且被其识别。然后，控制返回1004。
在1012中，控制诸如在仿真器中运行appa。在appa正在运行的同时，控制器监视由于操作者使用appa而导致的ui事件。在1036中，控制允许操作人员与appa交互，以达到感兴趣的深度状态，记录每个ui交互，以形成面包屑。在各种实施方式中，控制可监视应用a响应某些ui事件需要花费多长时间。这些响应时间或基于响应时间的延迟可与对应的ui事件一起编码在面包屑中。例如，一些操作会需要appa从服务器获得数据，从而招致网络通信延迟。当在面包屑导航中重放ui事件时，在重放下一个ui事件之前导致网络访问的ui事件之后应该有更长的延迟。在1040中，如果还有更多的深度状态，则控制返回1036；否则，控制继续进行1044。
在1044中，控制确定与由操作员所识别的状态并行的状态。例如，如果操作员从类似条目列表中选择了一条链接，并且所选的链接通向感兴趣状态，则控制可假定列表中的其他条目也是感兴趣的。这些并行状态以及用于到达它们的面包屑(在列表示例中，面包屑将只在最后一个ui事件中有所不同)被添加到可深度链接状态的列表中。
在各种实施方式中，可使用爬行算法来运用appa，以达到应用程序a的一些或所有深度状态。关于爬行的其他信息，参见2015年9月9日提交的名称“unguidedapplicationcrawlingarchitecture”的美国专利申请no.14/849,540，该专利申请的第一发明人是kalyandesineni并且专利代理案卷号为7100-000006-us-01。该申请的全部公开内容以引用方式并入。
在1048中，控制向搜索系统提供可深度链接状态的列表，以进行索引。在1052中，对于每个可深度链接状态，控制向数据服务器提供包含面包屑的数据结构，以在uri中用作访问深度状态的访问机制。然后，控制返回1004。
在1012中，操作者与应用的拷贝(诸如，在仿真器中)交互，以导航至感兴趣状态。在一些实施方式中，操作者导航至开发商所指定的感兴趣状态；在其他实施方式中，开发商自己导航至感兴趣状态。诸如图12中描述地记录达到各种状态所需的用户界面事件。
控制继续进行1040，在1040中，控制可用操作员所识别的感兴趣状态来推断其他感兴趣状态。在图13中示出了推断的示例操作。在1012中，当操作者正在识别感兴趣状态时，操作者还可将状态标记为要标记书签的活动，并且可将状态内的数据识别为要索引的数据对象。
控制继续进行1056，在1056中，操作者所建立的配置参数被发送到数据服务器。例如，配置参数可以是业务规则，指明哪些状态应该被深度链接，哪些状态应该被作为活动标记书签以及哪些数据应该被索引。
离线分析
在图11中，离线分析系统280的示例实施方式包括允许操作者与感兴趣的应用(诸如，appa)交互的指导创建系统1100。指导创建系统1100允许操作者指定应用的哪些状态应该是可深度链接的，并且可使用来自操作者的输入来确定如何到达那些深度状态。在各种实施方式中，操作者是离线分析系统280的管理员，作用于应用的离线处理的标准操作过程或来自应用开发商的指令。另外或另选地，应用开发商的代理可充当操作者。代理可指定哪些状态或哪些类型的状态应该能作为深度状态来访问。
在最初离线分析之后，代理可使用开发商门户208来请求将应用的附加状态添加作为深度状态并且请求去除现有的深度链接状态。这可经由开发商门户208来进行，而不需要代理修改应用的代码或甚至请求来自应用的软件开发商的辅助。换句话说，营销人员或用户体验设计人员可自己控制应用内的深层链接的范围，甚至在没有发布应用的新版本的情况下。对于增加的状态，离线分析系统280将重新处理应用，以确定通向所添加状态的面包屑。
对于正由离线分析系统280处理的应用，操作方控制在仿真器1104内执行的感兴趣应用的拷贝。在各种其他实施方式中，感兴趣的应用可被安装在物理设备上或在仿真环境中执行。在各种实施方式中，仿真器1104可在云托管运营商处实例化，云托管运营商可提供在其内执行仿真程序/仿真器代码的计算设施，或可直接提供用于一个或更多个移动设备操作系统的仿真程序或仿真器。至于更多信息，参见2015年9月28日提交的名称为“operator-guidedapplicationcrawlingarchitecture”的美国专利申请no.14/868,294，该专利申请的第一发明人是kalyandesineni并且专利代理案卷号为7100-000006-us-02。该申请的全部公开内容以引用方式并入。
在一些实施方式中，诸如针对没有合适的仿真器或仿真程序的操作系统，可使用运行操作系统的物理设备来代替仿真器1104。物理设备可以使用无线或诸如usb(通用串行总线)的有线接口与指导创建系统1100连接。可在物理设备上安装根级控制应用来跟踪用户输入。安装根级应用程序会需要绕过固件或操作系统的安全限制，这与安装的应用的权限有关，会需要破解设备。
破解涉及绕过或去除由操作系统和/或设备固件施加的各种软件限制，并且可使用特权升级技术来完成。可利用预先安装的和特定的设置来进一步修改被破解设备，这些设置支持了本公开的技术，诸如，记录ui交互。仿真器1104基本上已经被破解。然而，仿真器1104也可被修改，以允许进行更好控制，诸如更容易地允许记录ui交互。
操作者与应用的交互可被记录，以形成指示如何到达状态的指导。该指导定义了用于达到最终状态的面包屑，并且该指导的子集定义了中间状态下的面包屑。指导也可用来推断其他感兴趣状态，并且确定导致这些状态的面包屑。每个ui事件可与特定ui元件关联，根据按唯一id根据预定标题来识别。
例如，可由在呈现视图时如何以编程方式创建ui元件来控制唯一id。在其他实施方式中，通过如何实际看到ui元件来控制唯一id，其中，用从左到右从上到下的升序对ui元件进行编号。在其他实施方式中，即使操作者的动作偏离中心，也可使用x-y坐标来识别用户交互的位置、或被致动的ui元件的边界或被致动的ui元件的中心。
在各种实施方式中，可使用静态分析来分析应用的各种状态的ui元件。静态分析涉及分析应用的代码，而没有观察正在执行的应用。在一些实施方式中，静态分析器(未示出)可识别每个视图的ui元件并且将唯一标识符指派给视图内的每个ui元件。然后，当参照用户与任何ui元件的交互时，动态分析将具有预定的命名。例如，可使用得自hex-rayssa的idapro软件所实现的反汇编程序和调试程序来执行静态分析。
另外或另选地，静态分析器可分析应用的方法和视图，以确定如何最好地测试应用。用该信息，动态分析器可挂钩正确的方法并且监听正确的事件，以准确跟踪用户与应用的交互并且丢弃与用户交互无关的方法调用。至于更多信息，参见2015年9月2日提交的名称为“staticanalysis-assisteddynamicapplicationcrawlingarchitecture”的美国专利申请no.14/843,929，该专利申请的第一发明人是kalyandesineni并且专利代理案卷号为17100-000006-us。该申请的全部公开内容以引用方式并入。
当应用正在仿真器1104中运行时，指导创建系统1100可监视仿真器1104(或在仿真程序或实体设备中执行时的实际操作系统)的消息队列，监听指示用户的应用操纵的消息。此操纵包括例如点击、按压、捏合或轻界面。
除了捕获操作人员与之交互的每个ui元件的唯一标识符之外，指导创建系统1100还可根据操作系统所指定的定义类型来提取每个元素的类型，并且还提取关联的视图控制器的识别。
例如，诸如通过使用methodswizzling(方法调配)来勾住(hooked)以下方法：
-(void)sendevent:(uievent*)eventmethodintheuiapplicationclass
-(void)sendaction:(sel)actionto:(id)targetforevent:(uievent*)eventinuicontrolclass
-(void)viewdidappear:(bool)animatedforallthecontrollersthatwereloaded
处理程序可被实现为记录每种类型的ui元件。作为示例，用于记录按钮按压的代码可如下实现：
可用详细的处理程序代码来记录其他类型的ui元件。在各种实施方式中，在勾住objc_msgsend函数之后，引导跟踪器1108可监听appdelegate类和(bool)应用：(id)application～didfinishlaunchingwithoptions：～(nsdictionary*)launchoptions方法。另外，引导跟踪器1108可动态地为控制器创建监听器。
操作者能够帮助把分析重点放在期望深度链接的状态-通常是最感兴趣或最重要的状态上，而不是试图通过非引导性地抓取应用来穷尽性发现应用的每种状态。操作者可从应用的主状态开始，并且针对期望深度链接的每种类别的状态进行到感兴趣的一种状态。然后，离线分析系统280可进行推断，以找到相近/并行的动作，其中的每个可对应于另一种感兴趣状态。这些并行状态可以被添加到状态列表中，状态列表定义哪些状态将存储有对应的面包屑。
例如，如果应用包括关于餐厅的信息，则操作者可浏览列出餐厅的状态，然后选择其中一家餐厅。操作员会在找到示出有关第一家餐厅的细节的状态之后停止。基于操作者在浏览期间采取的一系列动作，离线分析系统280可按相似方式找到可能已经到达的其他餐厅细节状态。
例如，在从列表中选择了具有某个布局和某些属性的餐厅条目(例如，具有在具有属性y的文本框旁边的属性x的图像)之后，离线分析系统280可检测操作人员可能已经选择的该视图内的多个附加餐厅条目(具有相同布局和/或属性)。然后可进行预测，选择其他餐厅列表将导致找到另外的餐厅信息状态。至于关于推断的更多信息，参见2015年9月29日提交的名称为“stateextrapolationforautomatedandsemi-automatedcrawlingarchitecture”的美国专利申请no.14/869,127，该专利申请的第一发明人是kalyandesineni并且专利代理案卷号为17100-000006-us-03。该申请的全部公开内容以引用方式并入。
在指导创建系统1100内，引导跟踪器1108将操作者与应用的交互记录在仿真器1104中，以创建操作者特定的指导。例如，指导可包括从应用的主(或默认)状态开始的操作者执行的每个用户界面交互。在各种实施方式中，目标状态跟踪器1112可允许操作者将仿真器1104中当前可见的状态标记为感兴趣状态。例如，目标状态跟踪器1112可将用户界面元件(诸如，按钮)设置在仿真器1104内或将其设置为操作者通过其控制仿真器1104的软件的部分。
对于每种感兴趣状态，链接提取控制器1116生成指定导致感兴趣状态的ui事件序列的面包屑。链接提取控制器1116明示地(诸如，经由目标状态跟踪器1112)或隐式地(诸如，诸如引导跟踪器1108)获悉操作者感兴趣的状态。链接提取控制器1116可尝试识别类似的状态，例如，使用类似的ui(用户界面)元件到达的状态。
可由操作者使用目标状态跟踪器1112来明确地识别目标状态。如果目标状态不是操作者指定的，则链接提取控制器1116可假定当操作者正在创建指导时达到的最终状态是目标状态。另选地，链接提取控制器1116可假定操作员导航至的每种状态应该是目标状态。可使用重复数据删除过程来检测操作者合适循环浏览，从而避免记录重复性的和/或非最短的路径指导。如果操作者正明确标记目标状态，则重复数据删除会不太必要。
链接提取控制器1116操作仿真器1120，如上所述，仿真器1120可替代地是仿真程序或实体设备。按规模，链接提取控制器1116可控制多个仿真程序、仿真器和/或实体设备，以分析相同或相似的应用。仅作为示例，一组实体智能手机都可经由usb连接到由链接提取控制器1116控制的接口卡。仅仅为了便于例示，在图4中示出单个仿真器(仿真器1120)。在各种实施方式中，模拟器1120和模拟器1104可以是由指导创建系统1100和链接提取控制器1116共用的单个仿真器。
在仿真器1120内执行所关注的应用。在各种实施方式中，由仿真器1120执行的应用可用诸如图3a或图3b中描述的路由库来补充。用路由库，链接提取控制器1116可致使仿真器1120中的应用来重放ui事件，以遵循指导并且识别附加的感兴趣状态。在其他实施方式中，因为模拟器1120中的应用不需要是应用的公开分发版本，所以可使用可访问性或自动化框架来执行ui控制。路由库可保留下来，用于公开分发的应用的版本。
链接提取控制器1116识别与引导跟踪器1108所指定的指导中的每个对应的感兴趣状态。为了到达应用内的状态，链接提取控制器1116将引导跟踪器1108所指定的最短路径发送到仿真器1120进行重放。链接提取控制器1116识别与引导跟踪器1108所指定的指导中的每个对应的感兴趣状态。
在各种实施方式中，离线分析系统280可包括从每种感兴趣状态提取内容的刮取器(未示出)。内容可包括文本、图像和元数据(诸如，位置、格式、界面提示等)。图2的搜索系统288可使用该内容来确定应用的哪些深度状态与搜索查询相关。在其他实施方式中，搜索系统288可分别抓取并刮取应用，但是可使用来自离线分析系统280的面包屑导航至各种状态。
如果存在需要输入文本的ui字段，则操作者可向指导创建系统1100识别需要输入什么类型的文本输入。这些类型可以是例如城市名称、菜肴名称等。然后，链接提取控制器1116咨询知识库，以获得这些类型的可能值的列表(对于城市，列表可包括“seattle”、“sanjose”等)，然后将这些值中的每个重放到文本输入字段中。
链接提取控制器1116可检测因遵循不同的面包屑而已经达到了的潜在的感兴趣状态。然后，链接提取控制器1116可选择面包屑中的一个，将其与该状态关联。例如，可选择具有最少数量的ui事件的面包屑。另选地，可选择具有最少视图变化的面包屑，并且可使用ui事件的总数作为tiebreaker。
为了识别已经达到的状态，链接提取控制器1116可将针对每种状态的指纹连同面包屑一起存储。指纹可以是状态分量的简化表示。例如，诸如，通过枚举xml数据结构中的对象并随后计算数据结构的数学散列(诸如，用md5)来创建可视对象的表示。散列之后作为指纹，并且如果新状态的散列与现有状态的散列匹配，则认为状态是相同的。
当链接提取控制器1116对感兴趣的状态组进行汇编时，链接提取控制器1116可将状态的标识符存储在配置数据存储器1124中。对于每种感兴趣状态，链接提取控制器1116确定面包屑达到该状态并且将面包屑存储在配置数据存储器1124中。另外，来自状态的内容或指纹被存储在配置数据存储器1124中。来自配置数据存储器1124的数据可被提供到图2的搜索系统288。
面包屑产生
在图12中，操作者进行面包屑创建的示例操作从1204开始，在1204中，控制将仿真程序或仿真器中的主题应用导向(open)应用的主状态。在1208中，控制开始跟踪用户与应用的交互，包括跟踪与操作员交互的用户界面元件。
在1212中，如果操作者将当前状态标记为深度链接目标，则控制转移到1216；否则，控制转移到1220。在1216中，将该状态添加到目标状态列表中并且控制继续进行1224。在1224中，控制将导致当前状态的操作者交互作为面包屑保存。控制继续进行1220。在1220中，如果操作者出于标记书签目的将该状态标记为活动，则控制转移到1228；否则，控制转移到1232。
在1228中，控制将状态添加到用于加活动书签的规则中，使得当用户遇到该状态时，通过向操作系统发送活动对象，将与该状态对应的活动标记书签。控制继续进行1236，在1236中，将导致当前状态的操作者交互作为面包屑保存。如果当前状态下在1224中已经存储了面包屑，则可在存储器中省去该面包屑的附加拷贝。控制继续进行1232。
在1232中，控制继续跟踪操作者与应用的交互。在1240中，控制确定操作者是否已经指示应用重置成应用的主状态。如果是这样，则控制转移到1244；否则，控制返回1212。可通过属于应用正在其中运行的仿真器的用户界面元件来完成重置主状态。在其他限制中，应用本身可具有返回到主状态的机制，并且在1240中也被识别到。通过重置成主状态，操作者指示应该跟踪一组新的用户界面事件以导致另一种感兴趣的状态。
在1244中，如果当前状态还未被标记为深度链接目标，则控制将导致当前状态的操作者交互作为面包屑存储并且将当前状态添加到目标状态列表中。控制继续进行1248，在1248中，如果操作者完成，则控制结束。否则，控制返回1208。
面包屑推断
参考图13，操作者可能已经建立了一系列面包屑，但是没有将任何特定状态标记为目标状态。例如，在一些实施方式中，操作者可能没有被提供指定目标状态的选项。然而，操作员创建的面包屑通常从主状态开始，而结束于终端(或最终)状态。该最终状态可被假定是深度链接的感兴趣状态。换句话说，只有终端状态被假定是目标状态。在其他实施方式中，遵循面包屑遇到的每种状态被假定是目标状态。
例如，当操作者正针对餐厅评论应用而创建面包屑时，操作者可通过从主状态导航至包含餐厅信息和评论的状态来创建一个面包屑。这将被假定是所期望的目标状态，并且链接提取控制器将尝试找到具有用于刮取的相似数据的附加状态。
控制从1304开始，在1304中，从操作者创建的面包屑列表中选择第一面包屑。在1308中，控制将该应用导向仿真器中的主状态。在1312中，控制跟随所选的面包屑，停止在紧邻最终状态之前的状态。在1316中，控制执行推断，以识别与最终状态相似的状态。例如，控制识别与跟随所选的面包屑时将到达最终状态的ui小部件并行的ui小部件。
在1320中，控制将最终状态以及识别为并行的ui小部件所到达的状态添加到状态列表中。所添加的状态中的每种都基于所选的面包屑用面包屑进行注释。在每个面包屑的最终ui事件时，除了最终状态以外的状态下的面包屑将与最终状态下的面包屑背道而驰。在1324中，控制确定在面包屑列表中是否存在另外的面包屑。如果是这样，则控制转移到1328；否则，控制结束。在1328中，控制选择面包屑列表中的下一个面包屑并且返回1308。
结论
以上描述本质上仅仅是例示性的，决不是旨在限制本公开、其应用或使用。本公开的广泛教导可按各种形式来实现。因此，虽然本公开包括特定示例，但是本公开的真实范围不应该如此受限制，因为在研究附图、说明书和以下权利要求时，其他修改形式将变得明显。应该理解，在不改变本公开原理的情况下，方法内的一个或更多个步骤可按不同顺序(或同时)执行。另外，虽然以上将实施例中的每个描述为具有某些特征，但是关于本公开的任何实施例描述的那些特征中的任一个或更多个特征可在任何其他实施例的特征中实现和/或与其组合，即使没有明示描述该组合。换句话说，所描述的实施例不是相互排斥的，并且一个或更多个实施例相互之间的置换仍然在本公开的范围内。
使用各种术语，包括“连接”、“接合”、“通过接口连接”和“联接”的各种术语来描述元件之间(例如，模块之间)的空间和功能关系。除非明确描述为“直接”，否则当在以上公开中描述了第一元件和第二元件之间的关系时，该关系涵盖了在第一元件和第二元件之间不存在任何居间元件的直接关系，还涵盖了在第一元件和第二元件之间存在一个或更多个居间元件(空间上或功能上)的间接关系。如本文中使用的，短语“a、b和c中的至少一个”应该被理解为意指使用非排他性的逻辑“或”，并且不应该被理解为意指“至少一个a、至少一个b和至少一个c”。
在本申请中，包括以下的定义，术语“模块”或术语“控制器”可用术语“电路”取代。术语“模块”可指的是执行代码的处理器硬件(共用、专用或成组)和存储处理器硬件所执行的代码的存储器硬件(共用、专用或成组)，作为其部分或包括其。
模块可包括一个或更多个接口电路。在一些示例中，接口电路可包括与局域网(lan)、互联网、广域网(wan)或其组合的有线或无线接口。本公开的任何给定模块的功能可跨经由接口电路连接的多个模块进行分布。例如，多个模块可允许负载平衡。在其他示例中，服务器(也称为远程或云)模块可代表客户端模块完成某种功能。
如上使用的术语代码可包括软件、固件和/或微代码，并且可以指程序、例程、功能、类别数据结构和/或对象。共享处理器硬件包含单个微处理器，该微处理器执行来自多个模块的一些或全部代码。组处理器硬件涵盖微处理器，微处理器与附加微处理器结合起来执行来自一个或更多个模块的一些或全部代码。对多个微处理器的引用包括分立芯片上的多个微处理器、单个芯片上的多个微处理器、单个微处理器的多个核、单个微处理器的多个线程或以上的组合。
共享存储器硬件涵盖单个存储器件，该存储器件存储来自多个模块的一些或全部代码。组存储器硬件涵盖存储器件，存储器件与其他存储器件结合起来存储来自一个或更多个模块的一些或所有代码。
术语存储器硬件是术语计算机可读介质的子集。如本文中使用的术语“计算机可读介质”没有涵盖传播通过介质(诸如，在载波上)的暂态电或电磁信号；术语“计算机可读介质”被视为有形的且非暂态的。非暂态计算机可读介质的非限制示例是非易失性存储器件(诸如，闪存存储器件、可擦除可编程只读存储器件或掩模只读存储器件)、易失性存储器件(诸如，静态随机存取存储器件或动态随机存取存储器件)、磁存储介质(诸如，模拟或数字磁带或硬盘驱动)以及光存储介质(诸如，cd、dvd或蓝光光盘)。
本申请中所描述的设备和方法可部分或完全通过专用计算机来实现，专用计算机是通过将通用计算机配置成执行计算机程序中实施的一个或更多个特定功能而创建的。以上描述的功能块和流程图元件用作软件规范，可通过熟练技术人员或编程人员的日常工作将其翻译成计算机程序。
计算机程序包括存储在至少一个非暂态计算机可读介质上的处理器可执行指令。计算机程序还可包括或依赖于所存储的数据。计算机程序可涵盖与专用计算机的硬件交互的基本输入/输出系统(bios)、与专用计算机的特定设备交互的设备驱动器、一个或更多个操作系统、用户应用、后台服务、后台应用等。
计算机程序可包括：(i)诸如html(超文本标记语言)或xml(可扩展标记语言)的待解析的描述文本、(ii)汇编代码、(iii)编译器用源代码生成的目标代码、(iv)供解释器执行的源代码、(v)供即时编译器编译和执行的源代码等。仅仅作为示例，可使用包括来自包括c、c++、c#、objective-c、swift、haskell、go、sql、r、lisp、
权利要求中列举的元件都不旨在是35u.s.c.§112(f)的含义内的装置+功能元件，除非使用短语“用于...的设备”或在方法权利要求的情况下使用短语“用于...的操作”或“用于...的步骤”来明确地记载的元件。
- 还没有人留言评论。精彩留言会获得点赞！