一种业务逻辑更新方法和装置与流程

本申请涉及计算机技术，特别涉及一种业务逻辑更新方法和装置。

背景技术：

当前互联网公司为了推广自己的服务，可以对外提供SDK(Software Development Kit，软件开发工具包)，以供第三方将该SDK集成在自己的应用APP中，SDK作为一种业务执行逻辑，可以辅助或配合应用实现应用的特定功能。例如，一个购物应用可以集成支付功能的SDK，使得用户在使用该购物应用的过程中可以调用SDK完成支付。

SDK的业务逻辑也是有可能变化的，比如，需要增加新的业务功能，或者修改原有功能等，对于SDK的更新，当前仍然是由SDK提供方推出新版本的SDK，第三方将该新版本SDK集成到自己的应用中，不断升级应用的版本，较为繁琐，这种方式也使得第三方应用不能及时修复SDK的业务问题。

技术实现要素：

有鉴于此，本申请提供一种业务逻辑更新方法和装置，以提高SDK业务逻辑的更新效率。

具体地，本申请是通过如下技术方案实现的：

第一方面，提供一种业务逻辑更新方法，包括：

向服务端发送更新请求，所述更新请求用于获取更新的业务逻辑对应的逻辑指示信息，并接收所述服务端返回的所述逻辑指示信息；

根据所述逻辑指示信息，执行所述更新的业务逻辑。

第二方面，提供一种业务逻辑更新装置，包括：

信息更新模块，用于向服务端发送更新请求，所述更新请求用于获取更新的业务逻辑对应的逻辑指示信息，并接收所述服务端返回的逻辑指示信息；

逻辑执行模块，用于根据所述逻辑指示信息，执行所述更新的业务逻辑。

本申请提供的业务逻辑更新方法和装置，通过主动向服务端请求更新的业务逻辑，使得可以及时的获取并执行更新的业务逻辑，实现业务逻辑的动态更新，提高了SDK业务逻辑的更新效率。

附图说明

图1是本申请一示例性实施例示出的一种应用APP集成SDK的例子；

图2是本申请一示例性实施例示出的一种业务逻辑更新方法的流程；

图3是本申请一示例性实施例示出的一种SDK的结构；

图4是本申请一示例性实施例示出的SDK执行业务逻辑更新的流程；

图5是本申请一示例性实施例示出的一种业务逻辑更新装置的结构；

图6是本申请一示例性实施例示出的另一种业务逻辑更新装置的结构。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

图1示例了一种应用APP集成SDK的例子，如图1所示，假设应用11是一个购物类型的应用，其中集成了具有支付功能的SDK12，这样在用户使用应用11进行购物的过程中，应用11就可以与SDK通信，调用SDK12进行支付，并且通常可以是通过SDK API进行调用。

上述的SDK12需要不断的更新升级，比如，SDK的提供方想要增加一 些新的支付功能，或者对原有功能进行修改，以使得该SDK更加完善。在传统方式中，应用11需要重新集成新版本的SDK，也就是说，被应用集成的SDK是一种静态集成的方式，对于一个版本的应用而言，该SDK的业务逻辑是固化的；当需要变更SDK的业务逻辑时，需要重新集成至应用，发布一个新版本的应用。而本申请提供了一种业务逻辑更新方法，即用于集成在应用中的SDK的业务更新，该方法用于实现SDK的动态更新，不需要新版本应用的集成，SDK自身就可以进行业务逻辑的动态更新。

图2示例了本申请的业务逻辑更新方法的流程，该方法可以是SDK执行，如图2所示，可以包括：

201、向服务端发送更新请求，所述更新请求用于获取更新的业务逻辑对应的逻辑指示信息，并接收所述服务端返回的所述逻辑指示信息；

202、根据所述逻辑指示信息，执行所述更新的业务逻辑。

在步骤201中，集成在应用中的SDK可以向服务端发送更新请求，该服务端可以是用于存储SDK逻辑的服务器，各个版本的SDK的逻辑都可以存储在该服务器；而更新请求相当于由SDK向服务端询问是否有对于该SDK的更新。

例如，SDK可以在请求中携带SDK标识，以使得服务端根据该SDK标识查询是否有关于该标识对应的SDK的业务逻辑更新(比如，新增业务功能或修改原业务功能等)。如果有更新，则服务端可以向SDK返回逻辑指示信息，该指示信息用于告知有关于如何获取更新的业务逻辑的指示，比如，可以包括更新的业务逻辑在服务端的存储地址、逻辑的版本信息等，使得SDK可以根据该信息获取到更新的业务逻辑。

在步骤202中，SDK可以根据逻辑指示信息，执行所述更新的业务逻辑；比如可以包括：根据逻辑指示信息获取到更新的业务逻辑，并根据应用APP对该SDK的调用执行更新的业务逻辑。

由上述图2的流程可以看到，本例子中集成在应用中的SDK可以进行动态更新，并且SDK可以主动向服务端获取更新的业务逻辑，实现SDK的自 动更新，从而提高SDK业务逻辑的更新效率。

如下举例再次说明本申请中的SDK对逻辑更新效率的提高：假设SDK的提供方更新了SDK的业务逻辑，即在服务端存储的SDK的业务逻辑已经发生了变化。当SDK请求更新信息时，服务端就可以将该更新的业务逻辑的指示信息发送给应用中的SDK，使得SDK根据指示信息尽快的获取到更新后的业务逻辑，从而快速实现SDK的更新，相对于传统方式中应用需要重新集成更新的SDK的方式，将可以提高SDK更新的速度。并且，对于线上SDK问题需要修复的情况，也可以通过上述的主动更新方式尽快得到解决，从而不依赖于集成SDK的应用的新版发布，SDK的升级更新非常方便。

图3示例了一种SDK的结构，本实施例将SDK内部划分为两个模块，一个是SDK Framework和一个是SDK Implementation，其中，SDK Framework可以包括对外的SDK API和本申请中的业务逻辑更新装置，SDK API用于与APP调用通信，业务逻辑更新装置用于执行本申请的业务逻辑更新方法。SDK Implementation为具体的SDK的业务逻辑实现，该SDK Implementation可以被动态的更新，并且可以包括多次更新的逻辑版本，例如初始化版本(即SDK被应用集成时的最初状态逻辑)以及更新版本(即功能更改后的逻辑)。

如下结合图4描述上述图3结构的SDK执行业务逻辑更新的过程：

401、SDK接收应用的业务调用请求；

例如，应用APP可以通过SDK Framework中的SDK API，调用SDK，这就相当于SDK接收到了应用的业务调用请求。

402、SDK获取逻辑指示信息；

例如，在本步骤中SDK获取的逻辑指示信息，可以是上一次SDK由服务端获取的。可以参见图4中的408，SDK可以在每次应用调用之后，即向应用返回了调用结果之后，由服务端获取逻辑指示信息，比如，向服务端发送更新请求，接收服务端返回的逻辑指示信息。安排在SDK调用之后向服务端请求更新，可以不影响SDK的调用过程，比如SDK向服务端的信息请求过程对网络的占用不会影响调用SDK执行的过程对网络的占用；当然，也可 以设定为定期请求更新等其他的更新方式。

上述的逻辑指示信息例如包括业务逻辑在服务端的地址等信息，在由服务端获得逻辑指示信息后，SDK可以暂时保存该信息，并在本例子中的步骤401接收到应用的调用请求后，再在本步骤402中获取该信息执行后续流程。

403、SDK根据逻辑指示信息，由服务端获取更新的业务逻辑；

例如，SDK可以根据逻辑指示信息中的地址、版本号等信息，由服务端下载更新的SDK业务逻辑，该逻辑可以包含在一个SDK文件中。

在步骤404至406中，SDK可以加载并执行更新的业务逻辑，得到逻辑执行结果。例如，SDK Framework可以加载从服务端下载的SDK文件，并且由SDK Framework向加载后的SDK Implementation发送业务调用请求，请求SDK Implementation按照更新后的业务逻辑执行，得到执行结果。在步骤407中，SDK Framework可以向调用SDK的应用返回业务调用结果。

在另一个例子中，SDK在向服务端请求更新时，服务端返回的逻辑指示信息中还可以包括：用于表示该更新的业务逻辑的更新类型的标识，该更新类型比如可以包括如下几种：

强制更新(force update)：在SDK接收到应用的调用请求时，SDK需要首先完成更新，更新成新的业务逻辑后再执行，得到新的业务逻辑对应的执行结果。即逻辑更新在执行逻辑之前进行。可以用第一标识表示该强制更新的类型。

静默更新(background update)：在SDK获得更新的业务逻辑的逻辑指示信息后，可以进行后台更新，即SDK进行逻辑更新的过程可以不与SDK的调用过程同时进行，而是在调用过程之外完成SDK的逻辑更新，包括根据逻辑指示信息由服务端下载更新的业务逻辑，或者获取逻辑指示信息指示的业务逻辑(比如，可以指示采用初始化逻辑，而初始化逻辑可以存储在SDK)。可以用第二标识表示该静默更新的类型。

强制重置(force reset)：即使用初始化逻辑，初始化逻辑是应用集成至应用的最初状态，相当于对SDK做降级。可以用第三标识表示该类型。

结合图4的示例，SDK在由服务端获取到更新的业务逻辑对应的逻辑指示信息后，可以判断该逻辑的更新类型。如果更新类型为第三标识，则SDK可以在403中由本地获取初始化逻辑即可，即在SDK不断升级更新的过程中，SDK Implementation可以保存最初集成时的初始化逻辑，也可以存储更新后的新业务逻辑，当服务端指示采用第三标识对应的更新类型时，SDK可以由本地获取初始化逻辑后加载执行。

又例如，如果更新类型为第二标识对应的静默更新，那么SDK可以在408获取到逻辑指示信息后，就根据该指示信息由服务端下载更新的业务逻辑到SDK本地。或者，再例如，如果更新类型为第一标识对应的强制更新，那么即使SDK在408中获取到逻辑指示信息，也可以暂时存储，等到下次接收到APP的业务调用请求时，再根据存储地址等信息由服务端获取新业务逻辑加载。或者，还例如，如果更新类型为第三标识，也可以在408中获取到逻辑指示信息后暂时存储，等到下次接收到APP的业务调用请求时再加载第三标识对应的初始化逻辑。

由上述的流程可以看到，SDK不仅能够主动的更新业务逻辑，并且还可以根据服务端指示的更新类型，采用不同的更新方式，可以在不同的时间执行不同类型的更新业务逻辑，提高了SDK业务逻辑更新的效率和灵活性。

图5示例了一种业务逻辑更新装置的结构，该装置用于执行上述实施例中的业务逻辑更新方法，如图5所示，该装置可以包括：信息更新模块51和逻辑执行模块52；其中，

信息更新模块51，用于向服务端发送更新请求，所述更新请求用于获取更新的业务逻辑对应的逻辑指示信息，并接收服务端返回的逻辑指示信息；

逻辑执行模块52，用于根据所述逻辑指示信息，执行更新的业务逻辑。

进一步的，信息更新模块51，具体用于在根据应用的业务调用请求向所述应用返回业务调用结果之后，向所述服务端发送所述更新请求。

进一步的，信息更新模块51，接收的所述逻辑指示信息包括：所述更新的业务逻辑在所述服务端的存储地址，或者所述业务逻辑的版本信息。

例如，所述逻辑指示信息还包括：第一标识或第二标识；所述第一标识，用于表示所述更新的业务逻辑的更新类型为强制更新；所述第二标识，用于表示所述更新的业务逻辑的更新类型为静默更新。

又例如，所述逻辑指示信息，包括：用于表示所述更新的业务逻辑为初始化逻辑的第三标识。

进一步的，如图6所示，当所述逻辑指示信息包括所述第一标识时，所述逻辑执行模块52，可以包括：逻辑获取单元521和逻辑执行单元522。

逻辑获取单元521，用于在接收到应用的业务调用请求时，根据所述逻辑指示信息，由所述服务端获取所述更新的业务逻辑；

逻辑执行单元522，用于加载并执行所述更新的业务逻辑，并向所述应用返回业务调用结果。

本实施例的业务逻辑更新装置，通过信息更新模块主动向服务端获取更新的业务逻辑的指示信息，并由逻辑执行模块执行更新的业务逻辑，实现了SDK的逻辑的主动更新，加快了SDK的更新效率。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。