SDK检测方法、装置、SDK、应用程序、设备和存储介质

摘要

本发明实施例提供一种SDK检测方法、装置、SDK、应用程序、设备和存储介质，该方法包括：获取目标SDK的启动异常次数阈值和检测时间，目标SDK是应用程序内的任一业务SDK；响应于目标SDK的启动，获取目标SDK的当前启动异常次数；在目标SDK的当前启动异常次数未达到启动异常次数阈值的情况下，根据检测时间，检测目标SDK是否启动异常；根据检测结果，确定目标SDK的更新后的启动异常次数，以便在更新后的启动异常次数达到启动异常次数阈值，则控制业务SDK进行启动异常响应，从而完成业务SDK是否存在启动异常问题的准确检测。

说明书

技术领域

本发明涉及互联网技术领域，尤其涉及一种SDK检测方法、装置、SDK、应用程序、设备和存储介质。

背景技术

诸如智能手机等电子设备已经成为人们生活中不可或缺的工具。为便利人们的生活、工作，服务提供商们研发了各种各样的应用程序(Application，简称APP)，以供人们在自己的电子设备中安装并使用这些应用程序。

应用程序为实现各种功能，内部会包含多种软件开发工具包(SoftwareDevelopment Kit，简称SDK)。比如，购物类的应用程序中可能包含提供商品推送、支付等功能的多个SDK。在应用程序启动时，会依次触发其中的不同SDK的启动。如果某个SDK启动异常，将会导致应用程序无法被正常启动以供用户使用。因此，准确地检测出SDK是否发生了启动异常，以便及时地克服SDK异常问题，对保证应用程序的正常使用至关重要。

发明内容

本发明实施例提供一种SDK检测方法、装置、SDK、应用程序、设备和存储介质，可以对应用程序内安装的业务SDK是否存在启动异常情况进行准确检测。

第一方面，本发明实施例提供一种SDK检测方法，该方法包括：

获取目标SDK的启动异常次数阈值和检测时间，所述目标SDK是应用程序内的任一业务SDK；

响应于所述目标SDK的启动，获取所述目标SDK的当前启动异常次数；

在所述当前启动异常次数未达到所述启动异常次数阈值的情况下，根据检测时间，检测所述目标SDK是否启动异常；

根据检测结果，确定所述目标SDK的更新后的启动异常次数。

第二方面，本发明实施例提供一种SDK检测装置，该装置包括：

第一获取模块，用于获取目标SDK的启动异常次数阈值和检测时间，所述目标SDK是应用程序内的任一业务SDK；

第二获取模块，用于响应于所述目标SDK的启动，获取所述目标SDK的当前启动异常次数；

检测模块，用于在所述当前启动异常次数未达到所述启动异常次数阈值的情况下，根据检测时间，检测所述目标SDK是否启动异常；

确定模块，用于根据检测结果，确定所述目标SDK的更新后的启动异常次数。

第三方面，本发明实施例提供一种SDK，所述SDK用于：

获取目标SDK的启动异常次数阈值和检测时间，所述目标SDK是应用程序内的任一业务SDK；

响应于所述目标SDK的启动，获取所述目标SDK的当前启动异常次数；

在所述当前启动异常次数未达到所述启动异常次数阈值的情况下，根据检测时间，检测所述目标SDK是否启动异常；

根据检测结果，确定所述目标SDK的更新后的启动异常次数。

第四方面，本发明实施例提供一种应用程序，包括：检测SDK和至少一个业务SDK；

所述检测SDK用于：获取目标SDK的启动异常次数阈值和检测时间，所述目标SDK是所述至少一个业务SDK中的任一个；响应于所述目标SDK的启动，获取所述目标SDK的当前启动异常次数；在所述当前启动异常次数未达到所述启动异常次数阈值的情况下，根据检测时间，检测所述目标SDK是否启动异常；根据检测结果，确定所述目标SDK的更新后的启动异常次数。

第五方面，本发明实施例提供一种电子设备，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器实现如第一方面所述的SDK检测方法。

第六方面，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现如第一方面所述的SDK检测方法。

本发明实施例中提供的方案，用于检测应用程序内包含的任一业务SDK是否存在启动异常的问题。以应用程序中包含的任一业务SDK，称为目标SDK为例，当该目标SDK启动时，获取目标SDK的启动异常次数阈值和检测时间这两个参数。从而，在确定目标SDK的当前启动异常次数未达到该启动异常次数阈值时，根据目标SDK的检测时间对该目标SDK进行检测处理，以确定目标SDK是否启动异常，以根据检测结果确定目标SDK的更新后的启动异常次数。其中，启动异常次数阈值的设置，可以避免用户正常关闭应用程序等操作对检测准确性的影响；检测时间，对应于目标SDK最有可能发生异常的时间段，在该检测时间内检测可以保证检测结果的准确性。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种应用程序的组成示意图；

图2为本发明实施例提供的一种SDK检测方法的流程示意图；

图3为本发明实施例提供的另一种SDK检测方法的流程示意图；

图4为本发明实施例提供的检测SDK的工作原理示意图；

图5为本发明实施例提供的一种SDK检测装置的结构示意图；

图6为与图5所示实施例提供的SDK检测装置对应的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

先简单介绍下为何提出本发明实施例提供的SDK检测方案。应用程序为实现各种功能，内部会包含多种SDK，为与下文中提及的一种新增的SDK(称为检测SDK)相区别，称为业务SDK。在应用程序启动时，如果其中的任一SDK出现启动异常现象，将导致应用程序启动失败，从而用户无法正常使用该应用程序。目前，当应用程序无法正常启动时，往往需要从应用程序整体这个角度来进行解决，比如升级应用程序、重新安装应用程序，等等。从应用程序整体的角度进行解决，一方面，需要用户进行升级、重新安装等操作，用户感受不佳，会导致较高的卸载率，另一方面，并不能准确定位出错误原因，从而不能针对性的解决问题。

为此，本发明实施例提供了一种SDK检测方法，通过该方案可以准确检测出是应用程序内的哪个业务SDK出现了启动异常问题，从而导致应用程序无法正常启动。基于此，可以针对异常的业务SDK提供异常响应方案。

下面，结合以下的一些实施例对该SDK检测方法的实现进行示例性说明。在此之前，先对SDK的含义进行简单介绍。开发应用程序时，需要使用操作系统提供的很多接口(API函数)函数，若要使用API函数，需要有跟API函数对应的声明(.H)文件、导入库(.LIB)文件，而SDK提供了一整套开发应用程序所需的相关文件、范例和工具的工具包。

图1为本发明实施例提供的一种应用程序的组成示意图，如图1所示，该应用程序包括：检测SDK和至少一种业务SDK。其中，该业务SDK是指应用程序中除检测SDK外的任一SDK。在图1中，假设应用程序中除检测SDK外还包括SDKa和SDKb这两个业务SDK，则下文中的目标SDK可以是这两个业务SDK中的任一个。

如图1中所示，SDKa和SDKb可以共享该检测SDK，即由检测SDK管理应用程序中的全部业务SDK)，为这些业务SDK提供启动异常检测功能。

为了实现对业务SDK是否存在启动异常进行检测，概括来说，检测SDK的作用主要体现为：

检测SDK用于：获取目标SDK的启动异常次数阈值和检测时间，目标SDK是应用程序包含的至少一个业务SDK中的任一个；响应于目标SDK的启动，获取目标SDK的当前启动异常次数；在当前启动异常次数未达到启动异常次数阈值的情况下，根据检测时间，检测目标SDK是否启动异常；根据检测结果，确定目标SDK的更新后的启动异常次数。

目标SDK用于：响应于检测SDK的控制，进行启动异常响应。

为便于理解如何对目标SDK进行是否存在启动异常的检测，下面结合图2所示实施例来说明。

值得说明的是，执行对目标SDK进行检测的主体可以是图1中所示的检测SDK，当然，也不限于此，比如，执行主体还可以是操作系统启动的某个进程、线程，或者，也可以是上述应用程序，即在应用程序中集成实现对业务SDK是否存在启动异常问题的检测逻辑，该检测逻辑的实现不限于以SDK的方式实现。

图2为本发明实施例提供的一种SDK检测方法的流程示意图，为便于描述，以该方法由图1所示实施例中的检测SDK来执行为例进行说明。如图2所示，该SDK检测方法可以包括如下步骤：

201、获取目标SDK的启动异常次数阈值和检测时间，目标SDK是应用程序内的任一业务SDK。

202、响应于目标SDK的启动，获取目标SDK的当前启动异常次数。

203、在目标SDK的当前启动异常次数未达到启动异常次数阈值的情况下，根据检测时间，检测目标SDK是否启动异常。

204、根据检测结果，确定目标SDK的更新后的启动异常次数。

实际应用中，当用户比如通过点击应用程序的图标而启动应用程序时，检测SDK首先被启动，而在应用程序的启动过程中，可能还会依次启动不同的业务SDK。从而，以任一业务SDK作为目标SDK来说，可以在目标SDK被启动时，检测SDK获取该目标SDK对应的启动异常次数阈值和检测时间这两个参数，比如3次、6秒钟。

其中，可选地，目标SDK的启动异常次数阈值和检测时间可以是研发者预先配置给该目标SDK的。或者，可选地，目标SDK的启动异常次数阈值和检测时间也可以是通过自动分析数据的方式确定的，其中，所谓自动分析数据的方式可以是：收集目标SDK在应用程序以往的多次启动过程中发生异常的时间信息以及循环启动的次数，由此统计分析得到该目标SDK的启动异常次数阈值和检测时间。而实际应用中，上述统计分析的过程可以是检测SDK执行的，也可以不是由该检测SDK执行的。

可选地，目标SDK可以在启动时主动向检测SDK提供自己对应的启动异常次数阈值和检测时间。

被启动的目标SDK向检测SDK提供自己的启动异常次数阈值和检测时间，相当于向检测SDK注册自己的启动异常次数阈值和检测时间。检测SDK接收到目标SDK的启动异常次数阈值和检测时间后，存储该目标SDK的启动异常次数阈值和检测时间。

可选地，目标SDK也可以在启动时向检测SDK提供自己的标识信息，以供检测SDK根据该标识信息在已经存储的参数集中查询该目标SDK对应的启动异常次数阈值和检测时间。其中，可以理解的是，目标SDK被首次启动时，向检测SDK注册自己对应的启动异常次数阈值和检测时间，以使检测SDK将该目标SDK的启动异常次数阈值和检测时间存储在参数集中。后续该目标SDK再被启动时，检测SDK便可以根据目标SDK的标识信息查询该参数集以获得该目标SDK对应的启动异常次数阈值和检测时间。实际应用中，目标SDK的标识信息比如可以是其名称或者为其分配的编号，等等。

概括来说，在对目标SDK是否存在启动异常问题进行检测的过程中，目标SDK对应的启动异常次数阈值和检测时间这两个参数的作用都是为了保证检测结果的准确性。这两个参数对检测结果准确性的影响分别体现为：

启动异常次数阈值：在实际应用中，有时候目标SDK不能成功启动可能并非是因为目标SDK本身存在问题导致的，可能是由于用户的操作行为而导致的。比如，用户在点击应用程序的图标而出发应用程序的启动后，随即触发了导致应用程序关闭的行为或者安装该应用程序的电子设备(比如手机、智能穿戴设备、智能家居设备、笔记本电脑等等)关机，此时正在被启动的目标SDK将无法正常启动。也就是说，此时目标SDK启动异常是正常的。为了避免这种情况对目标务SDK启动异常检测结果的干扰，设定了启动异常次数阈值，从而认为只有在目标SDK连续不能成功启动的次数达到该阈值时，才认为目标SDK确实存在启动异常问题。

检测时间：实际应用中，目标SDK启动异常的现象所发生的时机并不固定，可能会在刚刚启动目标SDK的时刻就发生，也可能在目标SDK启动的过程中发生，还可能在目标SDK成功启动后很快又因为某些原因而导致目标SDK又处于未启动状态。因此，为了覆盖目标SDK的启动异常的多种发生时机，设定了该检测时间，以便在目标SDK被触发启动后计时达到该检测时间的情况下执行目标SDK是否启动异常的检测。

实际应用中，启动异常次数阈值比如为3、5等数值，检测时间比如为2秒、3秒等数值。不同目标SDK对应的启动异常次数阈值和检测时间可以是不同的。

值得说明的是，目标SDK首次启动不成功后，会重复多次启动。因此，本实施例中所说的目标SDK的启动应该理解为是重复多次启动中的每次启动。

实际应用中，可以设置一个计数变量，以用于累计目标SDK连续出现的启动异常次数。该计数变量比如表示为happ_num。可以理解的是，初始时，该计数变量的值为0，之后目标SDK每发生一次异常启动，该计数变量的值加一。

从而，每当目标SDK启动后，获取目标SDK的当前启动异常次数，进而判断目标SDK的当前启动异常次数是否达到启动异常次数阈值，若达到，则判定目标SDK确实发生了启动异常问题；若未达到，说明此时还不能确定目标SDK是否发生了启动异常问题，需进行后续的检测处理，以便最终判定目标SDK是否发生了启动异常问题。其中，在目标SDK的当前启动异常次数达到启动异常次数阈值的情况下，可以控制目标SDK进行启动异常响应。

举例来说，假设当前一次目标SDK的启动是首次启动，此时，happ_num＝0，假设启动异常次数阈值为3，未达到该启动异常次数阈值，则进行步骤203的检测处理。假设经过步骤203的检测处理确定本次目标SDK启动异常，则根据该检测结果确定目标SDK的更新后的启动异常次数为1，即更新happ_num为1。之后，目标SDK再次重新启动，此时，happ_num＝1，仍小于启动异常次数阈值3，继续执行步骤203的检测处理。以此类推，直到happ_num更新为3时，再次重新启动目标SDK，此时happ_num的值达到启动异常次数阈值，最终确定目标SDK确实发生了启动异常问题，控制目标SDK进行启动异常响应。

其中，控制目标SDK进行启动异常响应，可以是向目标SDK发送通知，以使目标SDK执行启动异常对应的回调函数，该回调函数中描述了目标SDK需要进行哪些处理，比如下述的降级处理。

其中，目标SDK的启动异常响应主要是对目标SDK进行降级处理，这里的降级处理是指避免目标SDK再处于启动异常的状态。该降级处理比如为：目标SDK将自己置于无需启动的状态，从而后续应用程序再启动的时候，不需要启动该目标SDK。再比如，目标SDK将与自身有关的数据清除掉。如此，通过避免目标SDK发生启动异常的现象，以避免应用程序会出现循环闪退而无法正常启动的现象。

其中，如前文举例所示，可选地，目标SDK的当前启动异常次数未达到启动异常次数阈值的情况下，根据目标SDK的检测时间，检测目标SDK是否启动异常，可以实现为：

对目标SDK的当前启动异常次数进行加一处理；在目标SDK启动后计时达到所述检测时间的情况下，清除目标SDK的启动异常次数；若未成功清除目标SDK的启动异常次数，则确定目标SDK启动异常。当然，可以理解的是，若成功清除目标SDK的启动异常次数，则确定目标SDK启动正常。

基于此，根据检测结果确定目标SDK的更新后的启动异常次数，可以实现为：在检测到目标SDK启动异常的情况下，确定目标SDK的更新后的启动异常次数为所述加一处理的结果。在检测到目标SDK启动正常的情况下，确定目标SDK的更新后的启动异常次数为零。

举例来说，假设目标SDK的当前启动异常次数happ_num＝1，小于启动异常次数阈值3，则先对该当前启动异常次数加一，即happ_num＝2，之后，在计时达到检测时间的情况下，尝试清除目标SDK的启动异常次数。若此时能够成功清除目标SDK的启动异常次数，那么此时happ_num＝0，说明目标SDK此次被成功启动。反之，若此时不能够成功清除目标SDK的启动异常次数，说明目标SDK此次启动不成功，此时保持happ_num＝2的更新结果。

其中，可选地，检测SDK可以启动一个线程，以使该线程在计时达到检测时间的情况下，执行清除目标SDK的启动异常次数的操作。

为便于理解通过清除目标SDK的启动异常次数来确定目标SDK是否存在启动异常的问题，下面结合应用程序启动过程的实现原理来说明。

当应用程序启动时，会请求操作系统启动一个或多个进程，针对其中的任一进程来说，该进程上可能承载一个或多个业务SDK的启动任务。当其中某业务SDK(称为目标SDK)需要被启动时，该进程可以触发某个线程来执行该目标SDK的启动，可以将该线程称为前台线程。其中，上文提到的检测SDK获取该目标SDK的上述两种参数，目标SDK的当前启动异常次数是否大于启动异常次数阈值的判断，以及启动异常次数加一的操作，都是在该前台线程中执行的。当目标SDK的启动异常次数被执行加一操作后，该进程再触发另一个线程来执行确定目标SDK本次启动是否发生异常的检测，可以将该线程称为后台线程。该后台线程在计时达到上述检测时间的情况下，执行清除该目标SDK的启动异常次数的操作。由于该后台线程是承载于上述进程的，如果目标SDK发生了启动异常问题，将会导致应用程序启动失败。如果应用程序启动失败，那么上述进程也将被关闭，从而，承载于该进程的上述后台线程也将会关闭，那么该后台线程将无法再执行清除操作，从而目标SDK的启动异常次数将不会被清除。

综上，为应用程序中的业务SDK设置启动异常次数阈值和检测时间这两个参数，基于这两个参数的设置，可以准确地检测出业务SDK的启动异常现象，以便通过克服业务SDK的启动异常问题来避免应用程序无法正常启动使用的问题。

图3为本发明实施例提供的另一种SDK检测方法的流程示意图，可选地，该SDK检测方法可以由前文中的检测SDK来执行，从而，如图3所示，该SDK检测方法可以包括如下步骤：

301、获取目标SDK的启动异常次数阈值和检测时间，目标SDK是应用程序内的任一业务SDK。

302、响应于目标SDK的启动，获取目标SDK的当前启动异常次数和第一版本号。

303、根据第一版本号和已存储的目标SDK对应的第二版本号，确定目标SDK是否完成升级，若是，则执行步骤304，否则，执行步骤305。

304、清除目标SDK的启动异常次数，向目标SDK发送初始化指令，以使目标SDK进行初始化。

本实施例中，当目标SDK启动时，可以向检测SDK提供自己当前的版本号，称为第一版本号，以便根据该第一版本号以及已经存储的该目标SDK对应的第二版本号确定目标SDK是否发生完成了升级。其中，第二版本号是目标SDK本次启动之前其所对应的版本号。

实际应用中，目标SDK升级的目的往往是克服前一版本中存在的各种缺陷，包括启动异常的问题。因此，如果当前一次目标SDK启动时，目标SDK提供的版本号与此前的版本号不同，为高版本，则认为相比于上一次启动，目标SDK已经升级了，此时可以认为目标SDK不发生启动异常问题。从而，将用于计数目标SDK连续发生的启动异常现象的启动异常次数清除，即清零。另外，此时允许目标SDK执行初始化过程。具体地，可以向目标SDK发送通知，以通知目标SDK可以执行初始化，目标SDK进而执行初始化回调函数，完成初始化。

值得说明的是，假设当前一次目标SDK启动时提供给检测SDK的版本号为V2，此前存储的目标SDK的版本号为V1，由于V2高于V1，则执行上述步骤304。与此同时，将存储的目标SDK的版本号更新为V2。从而，当下一次目标SDK再启动时，如果并未再发生升级，则目标SDK提供给检测SDK的版本号仍旧为V2，那么此时由于已存储的目标SDK的版本号也是V2，步骤303的判断结果将满足否定分支，从而将执行步骤305-310。

305、确定目标SDK的当前启动异常次数是否达到启动异常次数阈值，若是，则执行步骤306，否则，执行步骤307-310。

306、控制目标SDK进行启动异常响应。

307、对目标SDK的启动异常次数进行加一处理。

308、向目标SDK发送初始化指令，以使目标SDK进行初始化。

309、启动一个线程，以使所述线程在计时达到检测时间时，清除目标SDK的启动异常次数。

310、若未成功清除目标SDK的启动异常次数，则目标SDK的启动异常次数更新为所述加一处理的结果。

如前文所述，若不能成功清除目标SDK的启动异常次数，说明目标SDK本次启动发生了异常，从而，目标SDK会重复执行下一次启动。下一次启动过程是再一次从步骤301开始执行的过程，在该执行过程中，当执行到步骤305时，若确定目标SDK更新后的启动异常次数达到启动异常次数阈值，则控制目标SDK进行启动异常响应。

以上步骤的执行参考前述实施例中的说明，在此不赘述。

最后，值得说明的是，本发明实施例提供的上述检测SDK可以支持多个业务SDK的管理，也可以支持多个进程的保护。下面结合图4来说明。

如图4中所示，假设某应用程序启动过程中会启动进程1和进程2，在进程1中承载SDK1和SDK2的启动任务，在进程2中承载SDK3的启动任务。其中，这三个SDK对应于上文中的业务SDK。

在图4中，按照功能，将检测SDK拆分为如下的功能模块：API接口、管理器(Manager)、加载器(Loader)、保存器(Saver)、协调器(Dispatcher)。

其中，API接口：为上层的多个业务SDK提供统一的交互接口，从而可以通过该API接口获得业务SDK的启动异常次数阈值、检测等待时延、版本号等信息。

管理器：用于做全局的管理，比如通过API接口获取上述信息，控制保存器将上述信息存入到文件系统，控制加载器从文件系统中读取上述信息，控制协调器启动用于检测业务SDK是否存在启动异常的线程。

协调器：为每个业务SDK提供独立的线程，以通过该线程完成相应业务SDK是否启动异常的检测。

以下将详细描述本发明的一个或多个实施例的SDK检测装置。本领域技术人员可以理解，这些SDK检测装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图5为本发明实施例提供的一种SDK检测装置的结构示意图，该装置可以应用于应用程序内的检测SDK，如图5所示，该装置包括：第一获取模块11、第二获取模块12、检测模块13、确定模块14。

第一获取模块11，用于获取目标SDK的启动异常次数阈值和检测时间，所述目标SDK是应用程序内的任一业务SDK。

第二获取模块12，用于响应于所述目标SDK的启动，获取所述目标SDK的当前启动异常次数。

检测模块13，用于在所述当前启动异常次数未达到所述启动异常次数阈值的情况下，根据检测时间，检测所述目标SDK是否启动异常。

确定模块14，用于根据检测结果，确定所述目标SDK的更新后的启动异常次数。

可选地，所述SDK检测方法由检测SDK执行，所述检测SDK设置于所述应用程序。

可选地，所述装置还包括：响应模块，用于在所述目标SDK的更新后的启动异常次数达到所述启动异常次数阈值的情况下，控制所述目标SDK进行启动异常响应。

可选地，所述响应模块，还用于在所述当前启动异常次数达到所述启动异常次数阈值的情况下，控制所述目标SDK进行启动异常响应。

可选地，所述检测模块13具体可以用于：对所述当前启动异常次数进行加一处理；在所述目标SDK启动后计时达到所述检测时间的情况下，清除所述目标SDK的启动异常次数；若未成功清除所述目标SDK的启动异常次数，则确定所述目标SDK启动异常。从而，所述确定模块14具体用于：在检测到所述目标SDK启动异常的情况下，确定所述目标SDK的更新后的启动异常次数为所述加一处理的结果。

可选地，所述检测模块13还用于：若成功清除所述目标SDK的启动异常次数，则确定所述目标SDK启动正常。从而，所述确定模块14具体用于：在检测到所述目标SDK启动正常的情况下，确定所述目标SDK的更新后的启动异常次数为零。

可选地，所述检测模块13具体可以用于：启动一个线程，以使所述线程在计时达到所述检测时间的情况下，清除所述目标SDK的启动异常次数。

可选地，所述检测模块13还用于：对所述目标SDK的当前启动异常次数进行加一处理之后，向所述目标SDK发送初始化指令，以使所述目标SDK进行初始化。

可选地，所述检测模块13还用于：响应于所述目标SDK的启动，获取所述目标SDK对应的第一版本号；根据所述第一版本号和已存储的所述目标SDK对应的第二版本号，确定所述目标SDK是否完成升级；若所述目标SDK未完成升级，则执行所述在所述当前启动异常次数未达到所述启动异常次数阈值的情况下，根据检测时间，检测所述目标SDK是否启动异常的步骤。

可选地，检测模块13还用于：若所述目标SDK完成升级，则清除所述目标SDK的启动异常次数。

可选地，检测模块13还用于：更新已存储的所述第二版本号为所述第一版本号。

图5所示装置可以执行前述实施例中提供的SDK检测方法，详细的执行过程和技术效果参见前述实施例中的描述，在此不再赘述。

在一个可能的设计中，上述图5所示SDK检测装置的结构可实现为电子设备。如图6所示，该电子设备可以包括：处理器21、存储器22。其中，所述存储器22上存储有可执行代码，当所述可执行代码被所述处理器21执行时，使所述处理器21至少可以实现如前述各实施例中提供的SDK检测方法。

可选地，该电子设备中还可以包括通信接口23，用于与其他设备进行通信。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器至少可以实现如前述各实施例中提供的SDK检测方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例提供的SDK检测方法可以由某种程序/软件来执行，该程序/软件可以由网络侧提供，前述实施例中提及的电子设备可以将该程序/软件下载到本地的非易失性存储介质中，并在其需要执行前述SDK检测方法时，通过CPU将该程序/软件读取到内存中，进而由CPU执行该程序/软件以实现前述实施例中所提供的SDK检测方法，执行过程可以参见前述图2至图3中的示意。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。