CN114816587B - 一种基于原生通用型应用的拉起处理方法及系统 - Google Patents

Abstract

本发明提供了一种基于原生通用型应用的拉起处理方法及系统，方法包括：步骤1：获取各渠道原生应用的第一拉起数据，并统一整合到通用型框架页；步骤2：当目标用户为登录状态时，基于从通用型框架页获取的第二拉起数据，来请求服务端接口；当目标用户不为登录状态时，引导目标用户执行登录操作，并返回通用型框架页，获取对应的第二拉起数据，来请求服务端接口；步骤3：服务端根据服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端；步骤4：客户端根据与后续操作配置一致的返回字段，执行相应的后续操作。减少了编码错误风险，实现了可以动态修改拉起后要跳转的目标页面。

Description

一种基于原生通用型应用的拉起处理方法及系统

技术领域

本发明涉及应用拉起技术领域，特别涉及一种基于原生通用型应用的拉起处理方法及系统。

背景技术

目前存在的拉起原生app都是单一的方案，或是用短信链接配置scheme拉起，或是用push定义intent消息拉起，或是用微信SDK获取回调数据拉起，形式多样，接入方式各不相同，且只能跳转到定义好的某个页面，可操作性差，代码量大，还易产生冲突。

因此，本发明提出一种基于原生通用型应用的拉起处理方法及系统。

发明内容

本发明提供一种基于原生通用型应用的拉起处理方法及系统，用以解决上述提出的技术问题。

本发明提供一种基于原生通用型应用的拉起处理方法，包括：

步骤1：获取各渠道原生应用的第一拉起数据，并统一整合到通用型框架页；

步骤2：当目标用户为登录状态时，基于从所述通用型框架页获取的第二拉起数据，来请求服务端接口；

当所述目标用户不为登录状态时，引导所述目标用户执行登录操作，并返回所述通用型框架页，获取对应的第二拉起数据，来请求服务端接口；

步骤3：服务端根据所述服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端；

步骤4：所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作。

优选的，引导所述目标用户执行登录操作，并返回所述通用型框架页，包括：

将所述第二拉起数据保存在本地，并跳转到登录页面；

引导所述目标用户在所述登录页面进行登录；

当登录完成后，跳转到所述通用型框架页。

优选的，服务端根据所述服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端，包括：

获取所述请求信息，并判断所述请求信息对应的当前跳转状态；

基于所述预设查询表，获取与所述当前跳转状态一致的操作配置，并获取与所述操作配置一致的目标字段进行封装；

将封装结果，返回到所述客户端；

其中，所述当前跳转状态与需要跳转页、未完成跳转页以及完成跳转页的操作相关。

优选的，所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作，包括：

所述客户端在获取到返回字段之后，跳转到目标页；

获取基于所述目标页的本地数据，执行页面逻辑，判断是否完成页面所需校验项；

若完成，则跳转到完整跳转页，并清除所述本地数据；

若不需要校验，则上报埋点，并清除所述本地数据，其中，若接收到所述目标用户输入的返回指令，则跳转至返回跳转页，并清除所述本地数据。

优选的，获取各渠道原生应用的第一拉起数据，包括：

确定每个渠道中存在的所有应用，获取对应渠道中第一应用以及每个第二应用的应用状态集合；

基于所述应用状态集合，判断不同应用状态下对应的应用损耗关系，基于损耗-优先原则，从所有应用损耗关系中筛选最佳关系；

建立所述最佳关系的最佳拉起路线；

基于所述最佳拉起路线，向对应渠道发送拉起数据获取请求；

当对应渠道响应于所述拉起数据获取请求时，记录获取对应拉起数据的当下进程，其中，每个渠道均对应一个记录文件，且所述记录文件中包括若干记录节点，且每个记录节段对应一个该渠道涉及的一个原生应用，且每个记录节点包括：上一原生应用的终止记录格以及下一原生应用的起始记录格，且所述记录节点的节点顺序与所述最佳拉起路线的路线顺序一致；

根据所述当下进程，确定按照所述最佳拉起路线的拉起进程，并实时判断所述拉起进程与右侧记录节点之间的剩余进程距离是否大于预设距离；

当所述剩余进程距离大于预设距离时，控制对应渠道的拉起范围按照所述拉起进程的当下范围进行继续拉起；

当所述剩余进程距离等于预设距离时，控制所述拉起进程的当下范围进行扩大处理，并暂停拉起进程；

分析扩大处理后的范围是否合格，若合格，触发暂停的拉起进程，并按扩大处理后的范围在对应渠道进行记录拉起，直到到达所述右侧记录节点的终止记录格与起始记录格的中间间隙点，并将扩大处理后的范围恢复到初始范围；

基于每对对应的初始记录格与终止记录格，完成对一个原生应用的子拉起数据的获取，进而获取得到对应渠道的第一拉起数据；

其中，所述应用状态集合包括：第一应用与第二应用进行本地运行或者后台运行的组合状态。

优选的，统一整合到通用型框架页，包括：

按照渠道的渠道数量，在初始框架页上建立相应数量的第一空标签；

按照每个第一拉起数据涉及的拉起应用属性以及拉起应用场景，基于属性-场景-组件配置数据库，获取到对应工具组件，并附加在对应第一空标签上；

对每个第一拉起数据进行解析，根据解析结果确定对应渠道的原生应用的拉起过程，并对拉起过程的可操作程度进行确定；

当所述可操作程度大于预设操作程度时，并在附加的第一空标签上创建对应第一拉起数据的任务子标签，并按照所述任务子标签，拉起子功能任务；

按照对应渠道的渠道属性，对每个第一空标签进行优先级设置；

根据优先级设置结果，依次确定对应的工具组件，并启动所述初始框架页的代理服务组件，对对应子功能任务进行整合处理；

基于整合处理结果，对所述初始框架页进行调整，得到通用型框架页。

优选的，当目标用户为登录状态时，基于从所述通用型框架页获取的第二拉起数据之前，还包括：

当所述目标用户为登录状态时，判断是否可以在预设时间段内加载成功通用型框架页；

若可以加载成功，向数据触发单元发送数据拉起请求，并获取得到第二拉起数据；

若不可以加载成功，在所述预设时间段结束后，基于客户端自动发送框架加载指令，并判断所述框架加载指令中是否携带第一加载参数，若携带，对所述通用型框架页进行再次加载；

若未携带，基于预先设置的所述通用型框架页的隐藏加载标识，生成第二加载参数，并基于所述第二加载参数，对所述通用型框架页进行再次加载；

记录再次加载的工作日志，基于日志分析模型，判断所述工作日志中是否存在错误指引；

若存在，确定对应的错误指引值；

其中，Y1表示错误指引值；n表示错误指引次数；

表示第i个错误指引对应的指引权重；d _i 表示第i个错误指引对应的实际指引值；D _i 表示第i个错误指引对应的指引阈值；exp表示指数函数符号；lg表示对数函数符号；

表示n个错误指引中对应的最大指引权重；

表示与最大指引权重匹配的错误指引值，其中，

；

当所述错误指引值大于预设指引值时，获取大于对应阈值的错误指引的指引类型，预测指引结果，并从结果-修正数据库中，获取对应的修正数据；

基于所述修正数据，配置对应的修正控件，并将所述修正控件插接在所述错误指引的错误分叉口，对加载过程进行修正；

按照修正后的加载过程，重新进行通用型框架页的加载；

若不存在错误指引，按照再次加载实现对所述通用型框架页的加载。

优选的，所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作的过程中，还包括：

当不同用户点击同个转跳链接之后，记录不同用户点击之后的跳转时长，同时，获取所述转跳链接中的配置拉起参数并暂存；

分别采集不同用户的跳转介质应用，并基于所述跳转介质应用的应用类型，对所述跳转时长进行分类，并分别剔除同类时长中的离散点，构建同类曲线；

对每个同类曲线进行曲线拟合，得到对应的推荐时长；

其中，F表示对应同类曲线的推荐时长；m表示对应同类曲线上的拟合点个数；t _j 表示对应同类曲线上第j个拟合点的时长；t _max表示对应同类曲线上最大时长；t _zhong 表示对应同类曲线上对应的集中时长；

表示对应同类曲线上所有拟合点的平均时长；

表示基于集中时长与平均时长的微时长调节函数；

判断每个跳转介质应用所对应的推荐时长是否小于预设时长，若是，推荐对应的跳转介质应用作为链接基础应用；

否则，不推荐对应的跳转介质应用作为链接基础应用；

基于推荐的链接基础应用，获取暂存参数，并根据所述暂存参数判断是否需要直接跳转；

若是，调取所述通用型框架页进行直接跳转；

否则，基于暂存参数，匹配二次链接，并基于所述二次链接调取通用型框架页进行跳转。

本发明提供一种基于原生通用型应用的拉起处理系统，包括：

第一获取模块，用于获取各渠道原生应用的第一拉起数据，并统一整合到通用型框架页；

第一请求模块，用于当目标用户为登录状态时，基于从所述通用型框架页获取的第二拉起数据，来请求服务端接口；

第二请求模块，用于当所述目标用户不为登录状态时，引导所述目标用户执行登录操作，并返回所述通用型框架页，获取对应的第二拉起数据，来请求服务端接口；

查询模块，用于服务端根据所述服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端；

执行模块，用于所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明实施例中一种基于原生通用型应用的拉起处理方法的流程图；

图2为本发明实施例中拉起框架的具体流程图；

图3为本发明实施例中拉起框架的详细流程图；

图4为本发明实施例中一种基于原生通用型应用的拉起处理系统的结构图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

本发明提供一种基于原生通用型应用的拉起处理方法，如图1所示，包括：

步骤1：获取各渠道原生应用的第一拉起数据，并统一整合到通用型框架页；

步骤2：当目标用户为登录状态时，基于从所述通用型框架页获取的第二拉起数据，来请求服务端接口；

当所述目标用户不为登录状态时，引导所述目标用户执行登录操作，并返回所述通用型框架页，获取对应的第二拉起数据，来请求服务端接口；

步骤3：服务端根据所述服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端；

步骤4：所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作。

该实施例中，如图2所示，从短信链接，推送消息，微信等渠道拉起App后，加载通用拉起框架页并获取拉起数据，因App数据与用户强绑定，所以为了判断当前用户是否需强制性进行安全校验，需先判断用户是否登录，若登录则直接使用拉起数据请求接口获取跳转信息，若非登录状态，则需先将拉起数据保存在本地，待登录成功后，返回到通用拉起框架页，再获取本地缓存的拉起数据并请求服务端接口，服务端会根据当前的code查询表，并获取目标页面及未完成跳转页及完成跳转页等字段封装并返回给客户端，客户端拿到数据后，再次缓存到本地并跳转目标页，在目标页获取缓存的数据，执行页面逻辑，判断是否完成页面所需校验项，若完成则跳转到完成跳转页并清除本地逻辑，若无须校验，则直接上报埋点并清除本地数据，若用户点击返回，则跳转至返回跳转页，并清除本地数据。

如图3所示，详细区分了原生各个目标页面及标明了服务端的此方案涉及到的微服务，业务逻辑与概设一致。

上述技术方案的有益效果是：整合了各个拉起场景，通过框架进行统一的数据处理及分发，减少了开发及后续更新及维护的工作量，较好的减少了编码错误风险，且可以根据服务端配置及不同原生逻辑，实现了不用发版不用更改配置就可以动态修改拉起后要跳转的目标页面。

本发明提供一种基于原生通用型应用的拉起处理方法，引导所述目标用户执行登录操作，并返回所述通用型框架页，包括：

将所述第二拉起数据保存在本地，并跳转到登录页面；

引导所述目标用户在所述登录页面进行登录；

当登录完成后，跳转到所述通用型框架页。

上述技术方案的有益效果是：此操作是因为App登录场景较复杂，可切换页面较多，数据保存在本地，以免页面跳转层级较多，发生数据丢失，无法保证可以确实到达目标页面的情况的发生。

本发明提供一种基于原生通用型应用的拉起处理方法，服务端根据所述服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端，包括：

获取所述请求信息，并判断所述请求信息对应的当前跳转状态；

基于所述预设查询表，获取与所述当前跳转状态一致的操作配置，并获取与所述操作配置一致的目标字段进行封装；

将封装结果，返回到所述客户端；

其中，所述当前跳转状态与需要跳转页、未完成跳转页以及完成跳转页的操作相关。

上述技术方案的有益效果是：通过执行后续操作，实现了目标页及校验项的动态配置，实现了原生端不发版也可以动态更改营销目标页的需求。

本发明提供一种基于原生通用型应用的拉起处理方法，所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作，包括：

所述客户端在获取到返回字段之后，跳转到目标页；

获取基于所述目标页的本地数据，执行页面逻辑，判断是否完成页面所需校验项；

若完成，则跳转到完整跳转页，并清除所述本地数据；

若不需要校验，则上报埋点，并清除所述本地数据，其中，若接收到所述目标用户输入的返回指令，则跳转至返回跳转页，并清除所述本地数据。

上述技术方案的有益效果是：通过清除本地数据，可以有效实现原生端不发版也可以动态更改营销目标页的需求。

本发明提供一种基于原生通用型应用的拉起处理方法，获取各渠道原生应用的第一拉起数据，包括：

确定每个渠道中存在的所有应用，获取对应渠道中第一应用以及每个第二应用的应用状态集合；

基于所述应用状态集合，判断不同应用状态下对应的应用损耗关系，基于损耗-优先原则，从所有应用损耗关系中筛选最佳关系；

建立所述最佳关系的最佳拉起路线；

基于所述最佳拉起路线，向对应渠道发送拉起数据获取请求；

当对应渠道响应于所述拉起数据获取请求时，记录获取对应拉起数据的当下进程，其中，每个渠道均对应一个记录文件，且所述记录文件中包括若干记录节点，且每个记录节段对应一个该渠道涉及的一个原生应用，且每个记录节点包括：上一原生应用的终止记录格以及下一原生应用的起始记录格，且所述记录节点的节点顺序与所述最佳拉起路线的路线顺序一致；

根据所述当下进程，确定按照所述最佳拉起路线的拉起进程，并实时判断所述拉起进程与右侧记录节点之间的剩余进程距离是否大于预设距离；

当所述剩余进程距离大于预设距离时，控制对应渠道的拉起范围按照所述拉起进程的当下范围进行继续拉起；

当所述剩余进程距离等于预设距离时，控制所述拉起进程的当下范围进行扩大处理，并暂停拉起进程；

分析扩大处理后的范围是否合格，若合格，触发暂停的拉起进程，并按扩大处理后的范围在对应渠道进行记录拉起，直到到达所述右侧记录节点的终止记录格与起始记录格的中间间隙点，并将扩大处理后的范围恢复到初始范围；

基于每对对应的初始记录格与终止记录格，完成对一个原生应用的子拉起数据的获取，进而获取得到对应渠道的第一拉起数据；

其中，所述应用状态集合包括：第一应用与第二应用进行本地运行或者后台运行的组合状态。

该实施例中，获取各渠道对应的第一拉起数据的过程中，比如各渠道指的是搜索渠道、聊天渠道、定位渠道等，且每个渠道中都包含若干个应用，比如聊天渠道包括：微信、QQ、飞信等。

该实施例中，应用状态集合指的是同个渠道中不同应用的运行状态的组合，比如：微信和QQ处于本地运行状态，飞信处理后台运行状态等，因为不同的组合状态下，对应后续得到的损耗关系是不一样的。

比如：微信与QQ为状态1，飞信为状态2，此时，对应的应用损耗关系为11 12 22，损耗-优先原则，是基于损耗-优先数据库确定的，且损耗-优先数据库中包含各种损耗关系以及不同损耗关系下对应的优先标识，基于优先标识，来从该渠道对应的所有损耗关系中筛选最佳关系，比如筛选的最佳关系为112所对应的，此时的最佳拉起路线指的是：微信-飞信-QQ，可以有效的降低拉起数据获取的资源损耗，提高效率。

该实施例中，拉起数据获取请求也是按照对应的最佳拉起路线中的应用顺序，来依次拉起的。

该实施例中，比如：渠道1对应记录文件1，记录文件1中包括：节点1、节点2和节点3，其中，节点1到节点2构成一个节点段，节点2到节点3构成一个节点段，且每个节点都存在起始记录格以及终止记录格。

该实施例中，当下进程指的是按照最佳拉起线路在对应渠道进行数据拉起的一个进程，也就是获取第一拉起数据的进程。

该实施例中，当当下进程在节点1和节点2之间时，此时的右侧记录节点是节点2，剩余进程距离，也就是指的当下进程点到节点2的距离。

该实施例中，由于节点位置处的数据是重要的，因此，在剩余进程距离与预设距离相等的情况下，需要对当下范围进行扩大处理，也就是需要将该部分的全部数据都采集到，比如，在未到达预设距离内时，该部分的节点段在采集的过程中一般时处于稳定采集状态，因此，保持正常采集范围进行采集即可，但是，由于节点不仅包括上一节点数据还包含下一节点数据，所以，按照一般常识而言，节点本身在进行数据采集的过程中，因此，当到达预设距离内时，需要对全部数据都进行采集，来获取拉起子数据。

该实施例中，在进行扩大处理之后进行暂停是为了判断后续是否完全采集，若是，则视为合格，此时，继续进行数据采集。

该实施例红，中间间隙点也就是为了确定不同节点的进程。

该实施例中，比如存在节点1和节点2，其中，节点1中的初始记录格与节点2中的终止记录格视为一对，且也就是对应一个原生应用，进而来获取该应用的子拉起数据，最后，获得该渠道的第一拉起数据。

上述技术方案的有益效果是：通过对每个渠道中存在应用进行损耗分析，来获取得到最佳拉起路线，并按照顺序进行拉起数据的获取，可以提高数据获取效率，提高获取整合拉起场景的效率，且通过对拉起范围进行扩大，便于保证数据采集的完整性，更加方便后续通用型框架页的构造通用性，较好的减少了编码错误风险。

本发明提供一种基于原生通用型应用的拉起处理方法，统一整合到通用型框架页，包括：

按照渠道的渠道数量，在初始框架页上建立相应数量的第一空标签；

按照每个第一拉起数据涉及的拉起应用属性以及拉起应用场景，基于属性-场景-组件配置数据库，获取到对应工具组件，并附加在对应第一空标签上；

对每个第一拉起数据进行解析，根据解析结果确定对应渠道的原生应用的拉起过程，并对拉起过程的可操作程度进行确定；

当所述可操作程度大于预设操作程度时，并在附加的第一空标签上创建对应第一拉起数据的任务子标签，并按照所述任务子标签，拉起子功能任务；

按照对应渠道的渠道属性，对每个第一空标签进行优先级设置；

根据优先级设置结果，依次确定对应的工具组件，并启动所述初始框架页的代理服务组件，对对应子功能任务进行整合处理；

基于整合处理结果，对所述初始框架页进行调整，得到通用型框架页。

该实施例中，渠道数量，比如是10，此时，就需要在初始框架页上设置10个第一空标签。

该实施例中，拉起应用属性以及拉起应用场景指的是第一拉起数据包含的应用的应用属性以及对应应用一般情况下的应用场景。

该实施例中，属性-场景-组件配置数据库中包括：不同属性不同场景，以及与属性和场景对应的组件在内，因此，可以获取都工作组件。

该实施例中，对第一拉起数据解析，主要是为了确定拉起过程，也就是获取第一拉起数据的过程，进而对该过程的可操作程度进行确定，也就是是否可以基于该第一拉起数据对初始框架页进行一个通用性处理，也就是通用性处理的一个可操作程度，如果是，该通用性处理结果针对通用型框架页无效果，此时，就可以任务可操作程度差。

该实施例中，任务子标签是按照拉起过程中涉及到的拉起指标确定的，且不同的拉起指标可以对应一个任务子标签，且一个任务子标签可以对应一个子功能任务。

该实施例中，渠道属性，指的是渠道类型，根据类型进行优先级设置。

该实施例中，按照工具组件以及代理服务组件，来综合对对应的子功能任务进行整合处理，也就是使其具备通用性，进而后续得到通用型框架页。

上述技术方案的有益效果是：通过按照应用属性、应用场景，便于获取工具组件，通过对数据进行解析，便于创建子功能任务，进而通过优先级设置，可以基于工具组件以及代理服务组件，来综合对子功能任务进行整合处理，最后实现对框架页的调整，保证获取的通用型框架的通用性以及可靠性，减少开发错误率。

本发明提供一种基于原生通用型应用的拉起处理方法，当目标用户为登录状态时，基于从所述通用型框架页获取的第二拉起数据之前，还包括：

当所述目标用户为登录状态时，判断是否可以在预设时间段内加载成功通用型框架页；

若可以加载成功，向数据触发单元发送数据拉起请求，并获取得到第二拉起数据；

若不可以加载成功，在所述预设时间段结束后，基于客户端自动发送框架加载指令，并判断所述框架加载指令中是否携带第一加载参数，若携带，对所述通用型框架页进行再次加载；

若未携带，基于预先设置的所述通用型框架页的隐藏加载标识，生成第二加载参数，并基于所述第二加载参数，对所述通用型框架页进行再次加载；

记录再次加载的工作日志，基于日志分析模型，判断所述工作日志中是否存在错误指引；

若存在，确定对应的错误指引值；

其中，Y1表示错误指引值；n表示错误指引次数；

表示第i个错误指引对应的指引权重；d _i 表示第i个错误指引对应的实际指引值；D _i 表示第i个错误指引对应的指引阈值；exp表示指数函数符号；lg表示对数函数符号；

表示n个错误指引中对应的最大指引权重；

表示与最大指引权重匹配的错误指引值，其中，

；

当所述错误指引值大于预设指引值时，获取大于对应阈值的错误指引的指引类型，预测指引结果，并从结果-修正数据库中，获取对应的修正数据；

基于所述修正数据，配置对应的修正控件，并将所述修正控件插接在所述错误指引的错误分叉口，对加载过程进行修正；

按照修正后的加载过程，重新进行通用型框架页的加载；

若不存在错误指引，按照再次加载实现对所述通用型框架页的加载。

该实施例中，在获取第二拉起数据之前，通过判断是否可以加载成功通用型框架页进行详细分析。

该实施例中，比如：错误指引存在1个，但是只有该错误指引的实际指引值大于对应的预设指引值时，可以视为需要获取该错误指引的修正控件，错误指引指的是可能导致加载出现错误的一些信息，因此，需要对所有的错误指引进行一个综合计算，来确定是否有必要对错误指引进行修正，来保证加载的成功性。

该实施例中，错误分叉口指的是在加载框架页的过程中可能会按照该分叉口加载出来其他内容，导致对框架页加载失败，此时，在错误分叉口设置修正控件，可以有效的避免该情况的发生。

上述技术方案的有益效果是：通过对未成功加载通用型框架页的错误指引值进行计算，可以有效的获取得到修正控件，来防止错误指引的出现，保证通用型框架页加载的有效性，提高加载成功率，保证后续页面跳转的高效性。

本发明提供一种基于原生通用型应用的拉起处理方法，所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作的过程中，还包括：

当不同用户点击同个转跳链接之后，记录不同用户点击之后的跳转时长，同时，获取所述转跳链接中的配置拉起参数并暂存；

分别采集不同用户的跳转介质应用，并基于所述跳转介质应用的应用类型，对所述跳转时长进行分类，并分别剔除同类时长中的离散点，构建同类曲线；

对每个同类曲线进行曲线拟合，得到对应的推荐时长；

其中，F表示对应同类曲线的推荐时长；m表示对应同类曲线上的拟合点个数；t _j 表示对应同类曲线上第j个拟合点的时长；t _max表示对应同类曲线上最大时长；t _zhong 表示对应同类曲线上对应的集中时长；

表示对应同类曲线上所有拟合点的平均时长；

表示基于集中时长与平均时长的微时长调节函数；

判断每个跳转介质应用所对应的推荐时长是否小于预设时长，若是，推荐对应的跳转介质应用作为链接基础应用；

否则，不推荐对应的跳转介质应用作为链接基础应用；

基于推荐的链接基础应用，获取暂存参数，并根据所述暂存参数判断是否需要直接跳转；

若是，调取所述通用型框架页进行直接跳转；

否则，基于暂存参数，匹配二次链接，并基于所述二次链接调取通用型框架页进行跳转。

该实施例中，由于不同的用户在针对同个链接进行点击的过程中，对应点击的载体不同，也就是跳转应用介质不同，比如，有的用户点击同个链接，从微信跳转到拼多多，有的用户点击同个链接，从浏览器跳转到拼多多，此时，对应的不同类型的跳转介质应用所对应的同个链接的跳转时长可能是不同的，因此，进行分类，且通过对离散点的剔除，便于对曲线进行拟合，提高拟合效率以及后续计算的准确性。

该实施例中，t _zhong 与

的取值是相近的，且

可以是获取的t _zhong 与

的差值绝对值，进而，对之前计算的时长进行微调。

该实施例中，跳转介质应用指的是，比如微信上存在跳转链接，此时，且需要点击微信上的链接进行跳转，此时，微信就为跳转介质应用。

该实施例中，预设时长都是预先设置好的，比如是1s。

该实施例中，暂存参数是包括拉起参数以及相关的拉起标识在内的，通过按照暂存参数进行二次链接匹配，便于基于二次链接，来调取框架页。

上述技术方案的有益效果是：通过获取同个类型应用的跳转时长，可以有效的对每个类型的应用进行基础应用的推荐与否，保证跳转的高效性，且通过基于暂存参数匹配二次链接，可以保证框架页的有效调取，方便跳转的合理性。

本发明提供一种基于原生通用型应用的拉起处理系统，如图4所示，包括：

第一获取模块，用于获取各渠道原生应用的第一拉起数据，并统一整合到通用型框架页；

第一请求模块，用于当目标用户为登录状态时，基于从所述通用型框架页获取的第二拉起数据，来请求服务端接口；

第二请求模块，用于当所述目标用户不为登录状态时，引导所述目标用户执行登录操作，并返回所述通用型框架页，获取对应的第二拉起数据，来请求服务端接口；

查询模块，用于服务端根据所述服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端；

执行模块，用于所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作。

上述技术方案的有益效果是：整合了各个拉起场景，通过框架进行统一的数据处理及分发，减少了开发及后续更新及维护的工作量，较好的减少了编码错误风险，且可以根据服务端配置及预埋进原生的逻辑，实现了不用发版不用更改配置就可以动态修改拉起后要跳转的目标页面及业务需要进行的安全性或业务性校验。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (7)

1.一种基于原生通用型应用的拉起处理方法，其特征在于，包括：

步骤1：获取各渠道原生应用的第一拉起数据，并统一整合到通用型框架页；

步骤2：当目标用户为登录状态时，基于从所述通用型框架页获取的第二拉起数据，来请求服务端接口；

当所述目标用户不为登录状态时，引导所述目标用户执行登录操作，并返回所述通用型框架页，获取对应的第二拉起数据，来请求服务端接口；

步骤3：服务端根据所述服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端；

步骤4：所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作；

其中，获取各渠道原生应用的第一拉起数据，包括：

确定每个渠道中存在的所有应用，获取对应渠道中第一应用以及每个第二应用的应用状态集合；

基于所述应用状态集合，判断不同应用状态下对应的应用损耗关系，基于损耗-优先原则，从所有应用损耗关系中筛选最佳关系；

建立所述最佳关系的最佳拉起路线；

基于所述最佳拉起路线，向对应渠道发送拉起数据获取请求；

当对应渠道响应于所述拉起数据获取请求时，记录获取对应拉起数据的当下进程，其中，每个渠道均对应一个记录文件，且所述记录文件中包括若干记录节点，且每个记录节段对应一个该渠道涉及的一个原生应用，且每个记录节点包括：上一原生应用的终止记录格以及下一原生应用的起始记录格，且所述记录节点的节点顺序与所述最佳拉起路线的路线顺序一致；

根据所述当下进程，确定按照所述最佳拉起路线的拉起进程，并实时判断所述拉起进程与右侧记录节点之间的剩余进程距离是否大于预设距离；

当所述剩余进程距离大于预设距离时，控制对应渠道的拉起范围按照所述拉起进程的当下范围进行继续拉起；

当所述剩余进程距离等于预设距离时，控制所述拉起进程的当下范围进行扩大处理，并暂停拉起进程；

分析扩大处理后的范围是否合格，若合格，触发暂停的拉起进程，并按扩大处理后的范围在对应渠道进行记录拉起，直到到达所述右侧记录节点的终止记录格与起始记录格的中间间隙点，并将扩大处理后的范围恢复到初始范围；

基于每对对应的初始记录格与终止记录格，完成对一个原生应用的子拉起数据的获取，进而获取得到对应渠道的第一拉起数据；

其中，所述应用状态集合包括：第一应用与第二应用进行本地运行或者后台运行的组合状态；

其中，统一整合到通用型框架页，包括：

按照渠道的渠道数量，在初始框架页上建立相应数量的第一空标签；

按照每个第一拉起数据涉及的拉起应用属性以及拉起应用场景，基于属性-场景-组件配置数据库，获取到对应工具组件，并附加在对应第一空标签上；

对每个第一拉起数据进行解析，根据解析结果确定对应渠道的原生应用的拉起过程，并对拉起过程的可操作程度进行确定；

当所述可操作程度大于预设操作程度时，并在附加的第一空标签上创建对应第一拉起数据的任务子标签，并按照所述任务子标签，拉起子功能任务；

按照对应渠道的渠道属性，对每个第一空标签进行优先级设置；

根据优先级设置结果，依次确定对应的工具组件，并启动所述初始框架页的代理服务组件，对对应子功能任务进行整合处理；

基于整合处理结果，对所述初始框架页进行调整，得到通用型框架页。

2.如权利要求1所述的基于原生通用型应用的拉起处理方法，其特征在于，引导所述目标用户执行登录操作，并返回所述通用型框架页，包括：

将所述第二拉起数据保存在本地，并跳转到登录页面；

引导所述目标用户在所述登录页面进行登录；

当登录完成后，跳转到所述通用型框架页。

3.如权利要求1所述的基于原生通用型应用的拉起处理方法，其特征在于， 服务端根据所述服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端，包括：

获取所述请求信息，并判断所述请求信息对应的当前跳转状态；

基于所述预设查询表，获取与所述当前跳转状态一致的操作配置，并获取与所述操作配置一致的目标字段进行封装；

将封装结果，返回到所述客户端；

其中，所述当前跳转状态与需要跳转页、未完成跳转页以及完成跳转页的操作相关。

4.如权利要求1所述的基于原生通用型应用的拉起处理方法，其特征在于，所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作，包括：

所述客户端在获取到返回字段之后，跳转到目标页；

获取基于所述目标页的本地数据，执行页面逻辑，判断是否完成页面所需校验项；

若完成，则跳转到完整跳转页，并清除所述本地数据；

若不需要校验，则上报埋点，并清除所述本地数据，其中，若接收到所述目标用户输入的返回指令，则跳转至返回跳转页，并清除所述本地数据。

5.如权利要求1所述的基于原生通用型应用的拉起处理方法，其特征在于，当目标用户为登录状态时，基于从所述通用型框架页获取的第二拉起数据之前，还包括：

当所述目标用户为登录状态时，判断是否可以在预设时间段内加载成功通用型框架页；

若可以加载成功，向数据触发单元发送数据拉起请求，并获取得到第二拉起数据；

若不可以加载成功，在所述预设时间段结束后，基于客户端自动发送框架加载指令，并判断所述框架加载指令中是否携带第一加载参数，若携带，对所述通用型框架页进行再次加载；

若未携带，基于预先设置的通用型框架页的隐藏加载标识，生成第二加载参数，并基于所述第二加载参数，对所述通用型框架页进行再次加载；

记录再次加载的工作日志，基于日志分析模型，判断所述工作日志中是否存在错误指引；

若存在，确定对应的错误指引值；

其中，Y1表示错误指引值；n表示错误指引次数；

表示第i个错误指引对应的指引权 重；d _i 表示第i个错误指引对应的实际指引值；D _i 表示第i个错误指引对应的指引阈值；exp表 示指数函数符号；lg表示对数函数符号；

表示n个错误指引中对应的最大指引权重；

表示与最大指引权重匹配的错误指引值，其中，

；

当所述错误指引值大于预设指引值时，获取大于对应阈值的错误指引的指引类型，预测指引结果，并从结果-修正数据库中，获取对应的修正数据；

基于所述修正数据，配置对应的修正控件，并将所述修正控件插接在所述错误指引的错误分叉口，对加载过程进行修正；

按照修正后的加载过程，重新进行通用型框架页的加载；

若不存在错误指引，按照再次加载实现对所述通用型框架页的加载。

6.如权利要求1所述的基于原生通用型应用的拉起处理方法，其特征在于，所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作的过程中，还包括：

当不同用户点击同个转跳链接之后，记录不同用户点击之后的跳转时长，同时，获取所述转跳链接中的配置拉起参数并暂存；

分别采集不同用户的跳转介质应用，并基于所述跳转介质应用的应用类型，对所述跳转时长进行分类，并分别剔除同类时长中的离散点，构建同类曲线；

对每个同类曲线进行曲线拟合，得到对应的推荐时长；

其中，F表示对应同类曲线的推荐时长；m表示对应同类曲线上的拟合点个数；t _j 表示对 应同类曲线上第j个拟合点的时长；t _max表示对应同类曲线上最大时长；t _zhong 表示对应同类 曲线上对应的集中时长；

表示对应同类曲线上所有拟合点的平均时长；

表示基于集中时长与平均时长的微时长调节函数；

判断每个跳转介质应用所对应的推荐时长是否小于预设时长，若是，推荐对应的跳转介质应用作为链接基础应用；

否则，不推荐对应的跳转介质应用作为链接基础应用；

基于推荐的链接基础应用，获取暂存参数，并根据所述暂存参数判断是否需要直接跳转；

若是，调取所述通用型框架页进行直接跳转；

否则，基于暂存参数，匹配二次链接，并基于所述二次链接调取通用型框架页进行跳转。

7.一种基于原生通用型应用的拉起处理系统，其特征在于，包括：

第一获取模块，用于获取各渠道原生应用的第一拉起数据，并统一整合到通用型框架页；

第一请求模块，用于当目标用户为登录状态时，基于从所述通用型框架页获取的第二拉起数据，来请求服务端接口；

第二请求模块，用于当所述目标用户不为登录状态时，引导所述目标用户执行登录操作，并返回所述通用型框架页，获取对应的第二拉起数据，来请求服务端接口；

查询模块，用于服务端根据所述服务端接口接收的请求信息，从预设查询表中查询后续操作配置，并返回给客户端；

执行模块，用于所述客户端根据与所述后续操作配置一致的返回字段，执行相应的后续操作；

其中，所述第一获取模块还用于：

确定每个渠道中存在的所有应用，获取对应渠道中第一应用以及每个第二应用的应用状态集合；

基于所述应用状态集合，判断不同应用状态下对应的应用损耗关系，基于损耗-优先原则，从所有应用损耗关系中筛选最佳关系；

建立所述最佳关系的最佳拉起路线；

基于所述最佳拉起路线，向对应渠道发送拉起数据获取请求；

当对应渠道响应于所述拉起数据获取请求时，记录获取对应拉起数据的当下进程，其中，每个渠道均对应一个记录文件，且所述记录文件中包括若干记录节点，且每个记录节段对应一个该渠道涉及的一个原生应用，且每个记录节点包括：上一原生应用的终止记录格以及下一原生应用的起始记录格，且所述记录节点的节点顺序与所述最佳拉起路线的路线顺序一致；

根据所述当下进程，确定按照所述最佳拉起路线的拉起进程，并实时判断所述拉起进程与右侧记录节点之间的剩余进程距离是否大于预设距离；

当所述剩余进程距离大于预设距离时，控制对应渠道的拉起范围按照所述拉起进程的当下范围进行继续拉起；

当所述剩余进程距离等于预设距离时，控制所述拉起进程的当下范围进行扩大处理，并暂停拉起进程；

分析扩大处理后的范围是否合格，若合格，触发暂停的拉起进程，并按扩大处理后的范围在对应渠道进行记录拉起，直到到达所述右侧记录节点的终止记录格与起始记录格的中间间隙点，并将扩大处理后的范围恢复到初始范围；

基于每对对应的初始记录格与终止记录格，完成对一个原生应用的子拉起数据的获取，进而获取得到对应渠道的第一拉起数据；

其中，所述应用状态集合包括：第一应用与第二应用进行本地运行或者后台运行的组合状态；

其中，所述第一获取模块还用于：

按照渠道的渠道数量，在初始框架页上建立相应数量的第一空标签；

按照每个第一拉起数据涉及的拉起应用属性以及拉起应用场景，基于属性-场景-组件配置数据库，获取到对应工具组件，并附加在对应第一空标签上；

对每个第一拉起数据进行解析，根据解析结果确定对应渠道的原生应用的拉起过程，并对拉起过程的可操作程度进行确定；

当所述可操作程度大于预设操作程度时，并在附加的第一空标签上创建对应第一拉起数据的任务子标签，并按照所述任务子标签，拉起子功能任务；

按照对应渠道的渠道属性，对每个第一空标签进行优先级设置；

根据优先级设置结果，依次确定对应的工具组件，并启动所述初始框架页的代理服务组件，对对应子功能任务进行整合处理；

基于整合处理结果，对所述初始框架页进行调整，得到通用型框架页。

Images