1.本技术涉及计算机技术领域，尤其涉及一种启动时长异常的判定方法和装置、电子设备和存储介质。
背景技术：
2.用户使用产品的第一个感受就是启动时长，所有的产品几乎都会追求启动优化。android应用的大型项目一般都是功能多、参与的开发人员多、用到的sdk多，在追求启动时长优化的道路上不可避免的运用了很多手段。优化启动时长的手段包括应用层常规的懒加载、页面插件化、异步初始化等，还有系统层通过baseline profile等方式的优化。项目的复杂度高和优化手段多样，监控启动时长的变化就显得重要，也给发现启动时长异常，比如出现时长陡增或陡减之后的排查工作增加了难度。
3.现有的监控启动时长最常见方法有两种：第一种是在工程中埋点；第二种是通过编译插桩技术(比如aop技术)统计应用冷启动的耗时。但是埋点技术需要与业务代码耦合在一起，解耦性较差；第二种插桩技术虽然实现了无侵入性，修改方便，但是其在很多中大型项目也只是监控启动时长变化，当面对启动时长异常的问题时，无法精确定位问题。
4.因此，相关技术中存在无法定位启动时长产生异常的具体问题。
技术实现要素：
5.本技术提供了一种启动时长异常的判定方法和装置、电子设备和存储介质，以至少解决相关技术中存在无法定位启动时长产生异常的具体问题。
6.根据本技术实施例的一个方面，提供了一种启动时长异常的判定方法，该方法包括：
7.获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件；
8.在接收到目标应用对应的应用页面可见的情况下，获取冷启动的启动时长；
9.根据所述启动时长获取对应的所述日志文件；
10.根据所述日志文件判定产生启动时长异常的原因。
11.根据本技术实施例的另一个方面，还提供了一种启动时长异常的判定装置，该装置包括：
12.第一获取模块，用于获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件；
13.第二获取模块，用于在接收到目标应用对应的应用页面可见的情况下，获取冷启动的启动时长；
14.第三获取模块，用于根据所述启动时长获取对应的所述日志文件；
15.判定模块，用于根据所述日志文件判定产生启动时长异常的原因。
16.可选地，该装置还包括：
17.分配模块，用于在所述获取多个实验用户对应的实验设备在处于冷启动下对应的
日志文件之前，利用目标实验将所述实验用户分为实验组，将目标用户分为对照组，其中，所述目标实验用于根据所述实验组和对照组实现效果评估；
18.开启模块，用于在确定所述目标实验处于开启状态下，开启所述实验组内每个所述实验用户的所述实验设备。
19.可选地，判定模块包括：
20.获取单元，用于在所述启动时长大于第一预设阈值或小于第二预设阈值的情况下，获取当下的时间点；
21.定位单元，用于根据所述时间点定位所述日志文件中的日志信息的目标位置；
22.分析单元，用于分析所述目标位置处产生启动时长异常的原因。
23.可选地，第二获取模块包括：
24.第一记录单元，用于对目标应用的注解进行拦截，记录冷启动开始时间；
25.第二记录单元，用于在所述目标应用的应用页面首次获取到焦点时，记录冷启动结束时间；
26.第一得到单元，用于根据所述冷启动开始时间和所述冷启动结束时间，得到所述启动时长。
27.可选地，第三获取模块包括：
28.结束记录单元，用于在接收到应用页面触发页面可见性事件时，结束记录所述日志文件；
29.第二得到单元，用于结合所述启动时长，得到处于所述启动时长内的所有所述日志文件。
30.可选地，该装置还包括：
31.第四获取模块，用于每间隔预设时长获取冷启动的所述启动时长；
32.确定模块，用于确定多个所述启动时长的平均值；
33.发送模块，用于在所述平均值大于所述第一预设阈值或小于所述第二预设阈值的情况下，发送告警信息。
34.可选地，该装置还包括：
35.显示模块，用于将所述日志文件中与冷启动相关的关联信息发送至可视化服务平台，使得所述可视化服务平台将所述关联信息进行显示。
36.根据本技术实施例的又一个方面，还提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器、通信接口和存储器通过通信总线完成相互间的通信；其中，存储器，用于存储计算机程序；处理器，用于通过运行所述存储器上所存储的所述计算机程序来执行上述任一实施例中的方法步骤。
37.根据本技术实施例的又一个方面，还提供了一种计算机可读的存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一实施例中的方法步骤。
38.在本技术实施例中，通过获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件；在接收到目标应用对应的应用页面可见的情况下，获取冷启动的启动时长；根据启动时长获取对应的日志文件；根据日志文件判定产生启动时长异常的原因。由于本技术实施例利用指定人员，即实验用户的冷启动日志文件用以分析冷启动时长异常问题，可
以在不影响普通用户体验的前提下及时发现启动时长异常并定位导致异常的原因，进而解决了相关技术中存在无法定位启动时长产生异常的具体问题。
附图说明
39.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
40.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
41.图1是根据本技术实施例的一种可选的启动时长异常的判定方法的流程示意图；
42.图2是根据本技术实施例的一种可选的启动时长异常的判定方法的整体流程示意图；
43.图3是根据本技术实施例的一种可选的启动时长异常的判定装置的结构框图；
44.图4是根据本技术实施例的一种可选的电子设备的结构框图。
具体实施方式
45.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本技术保护的范围。
46.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
47.在中大型项目中，随着app整体迭代次数增多，app也逐渐集成了比较多的三方sdk，同时在可能持续多年的业务需求迭代中，项目用到的组件也越来越多；各项目都面对优化启动时长的问题，但是优化的手段在市场中是否真实有效，启动时长是否有抖动或者已经出了问题，都没有一个具体可量化和可视化的监控手段。监控启动时长现有的最常见方法有两种：第一种是在工程中埋点，在工程中自定义埋点的工具类或者埋点组件，在项目的application中记录启动，在显示出应用内容的页面记录启动结束，然后通过和后台约定好自定义的埋点流程，请求后台的接口把数据记录下来达到监控启动时长的目的；第二种是通过编译插桩技术统计应用冷启动的耗时，aop(aspect oriented programming，面向切面编程)技术是一种高效实现插桩的模式，aop是在编译完成后生成dex文件之前的时候，直接通过修改.class文件的方式，来直接添加或者修改代码逻辑的。aop不同于oop(object oriented programming，面向对象程序设计)将问题划分到单个模块之中，它把涉及到众多
模块的同一类问题进行了统一处理，无侵入性且修改方便。通过将项目的application的attachbasecontext方法作为切入点记录启动时间，在应用页面第一次获取焦点的onwindowfocuschanged方法中计算冷启动时间上传给服务器，更好的监控应用的启动时长。
48.现有方案通过插桩aop监控冷启动时间实现了无侵入性，修改方便；但是实际上目前很多中大型项目也只是监控启动时长变化，当面对启动时长异常，比如陡增、陡减的问题时，不会给开发者或者平台管理者报警，也由于没有历史的日志文件作为依据，没法分析出具体是哪里出了问题。
49.为了解决上述问题，本技术实施例提出一种启动时长异常的判定方法，如图1所示，该方法可以应用于设备服务器侧，该方法包括：
50.步骤s101，获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件。
51.可选地，在本技术实施例中，通过指定一些公司内部用户(即实验用户)获取这些实验用户对应的实验设备，比如手机设备id为01在处于冷启动(即电源开启)状态下对应的日志文件。也即是，当前要做的是获取一定数量的实验用户，让他们实时传输冷启动下的启动日志文件。
52.步骤s102，在接收到目标应用对应的应用页面可见的情况下，获取冷启动的启动时长。
53.可选地，利用实验用户的实验设备去表征普通用户(即目标用户)的设备在启动时出现异常的原因。进一步地，在实验用户的设备内的目标应用在冷启动时其应用页面显示画面或显示一焦点(代表可见即可)，则获取到冷启动的整个启动时长。其中，目标应用可以是当前处于冷启动下的任一应用。
54.需要说明的是，由于实验用户的实验设备与普通用户的设备只要是同一个设备id，比如xx型号，或者实验用户的实验设备与普通用户的设备应用版本相同，这时利用实验用户的实验设备获取到在冷启动时影响启动时长的异常原因，是完全可以代表普通用户的设备异常原因的，因同一设备如果出现异常通常是同一个项目的问题，所以获取到实验设备对应的冷启动启动时长即可。
55.步骤s103，根据启动时长获取对应的日志文件。
56.可选地，在本技术实施例中，获取冷启动的日志文件是从实验用户那边得到的，所以在确定了冷启动的启动时长之后，根据启动时长获取对应的日志文件即可。
57.步骤s104，根据日志文件判定产生启动时长异常的原因。
58.可选地，在有了日志文件后，定位出现异常的文件位置，然后分析当前文件位置处引起时长异常的原因。需要说明的是，这里的异常包括时长陡增或时长陡减，只要出现启动时长突然变化较大，均可以理解为出现了异常现象。
59.在本技术实施例中，通过获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件；在接收到目标应用对应的应用页面可见的情况下，获取冷启动的启动时长；根据启动时长获取对应的日志文件；根据日志文件判定产生启动时长异常的原因。由于本技术实施例利用指定人员，即实验用户的冷启动日志文件用以分析冷启动时长异常问题，可以在不影响普通用户体验的前提下及时发现启动时长异常并定位导致异常的原因，进而解决了相关技术中存在无法定位启动时长产生异常的具体问题。
60.作为一种可选实施例，在获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件之前，方法还包括：
61.利用目标实验将实验用户分为实验组，将目标用户分为对照组，其中，目标实验用于根据实验组和对照组实现效果评估；
62.在确定目标实验处于开启状态下，开启实验组内每个实验用户的实验设备。
63.可选地，在本技术实施例中，利用目标实验，比如ab实验，将外部普通用户和内部公司员工用户进行分组，将内部公司员工用户，比如测试人员、研发人员作为实验用户，放到实验组；将除公司之外的普通使用用户作为目标用户，放到对照组，利用实验组和对照组实现效果评估。在本技术实施例中，主要是利用实验用户的实验设备去评估普通用户的设备启动异常问题。
64.其中，在进行分组时，可以依据各个用户的用户id、设备的设备id来进行精确分组；另外，如图2，还可以根据目标应用的版本将外部普通用户和内部公司员工用户进行分组，得到实验组和对照组。
65.如图2，在设备的目标应用启动后，确定目标实验是否开启，在确定目标实验处于开启状态下，开启实验组内每个实验用户的实验设备。然后开启记录启动日志。
66.在本技术实施例中，依据用户id、设备id、imei聊天记录等来精准选择作为开启记录和上传冷启动日志的用户，可以确保这些用户是公司内部人员，不会给普通外部用户带来不好的体验。
67.作为一种可选实施例，根据日志文件判定产生启动时长异常的原因，包括：
68.在启动时长大于第一预设阈值或小于第二预设阈值的情况下，获取当下的时间点；
69.根据时间点定位日志文件中的日志信息的目标位置；
70.分析目标位置处产生启动时长异常的原因。
71.可选地，服务器在得到冷启动的启动时长后，若启动时长大于第一预设阈值(比如5分钟)或小于第二预设阈值(比如1秒)的情况下，说明启动时长出现了陡增或陡减的现象，这都是不正常的。这时基于发生异常的时间点，定位出日志文件中对应的日志信息，比如有50条日志信息，然后把该日志信息对应的目标位置都定位出来，然后分析在该目标位置处产生启动时长异常的原因即可。
72.本技术实施例可以及时的发现冷启动异常问题，配合保存下来的启动日志，可以快速的定位和解决冷启动时长异常的问题。
73.作为一种可选实施例，获取冷启动的启动时长，包括：
74.对目标应用的注解进行拦截，记录冷启动开始时间；
75.在目标应用的应用页面首次获取到焦点时，记录冷启动结束时间；
76.根据冷启动开始时间和冷启动结束时间，得到启动时长。
77.可选地，如图2，在方法应用application的attachbasecontext加注解，在应用启动后通过aspectj(面向切面的框架)用插桩的方式对注解拦截，记录冷启动开始时间，之后利用jionpoint.proceed()函数使attachbasecontex方法继续执行，然后监听页面可见(也即是应用页面首次获取到焦点时，说明页面可见)，记录冷启动结束时间，然后根据冷启动开始时间和冷启动结束时间，计算冷启动时长(或图2中的计算冷启动时间)，然后将该冷
启动时间上传至后台服务器。
78.本技术实施例通过aspectj用插桩的方式实现启动开始时间和结束时间的获取，没有侵入性，使业务逻辑各部分之间的耦合性降低。
79.作为一种可选实施例，根据启动时长获取对应的日志文件，包括：
80.在接收到应用页面触发页面可见性事件时，结束记录日志文件；
81.结合启动时长，得到处于启动时长内的所有日志文件。
82.可选地，如图2所示，在ab实验开启后，开始记录启动日志，然后在页面可见时，接收到应用页面触发页面可见性事件，结束记录冷启动日志。
83.将冷启动日志上传至后台服务器，这时后台服务器接收到的有冷启动日志和冷启动时间，并且服务器接收到的冷启动日志是处于整个冷启动时间期间的所有日志文件，这样只要启动时长发生异常，即可通过后台服务器去分析这些日志文件，得到异常原因即可。
84.作为一种可选实施例，该方法还包括：
85.将日志文件中与冷启动相关的关联信息发送至可视化服务平台，使得可视化服务平台将关联信息进行显示。
86.该方法还包括：
87.每间隔预设时长获取冷启动的启动时长；
88.确定多个启动时长的平均值；
89.在平均值大于第一预设阈值或小于第二预设阈值的情况下，发送告警信息。
90.可选地，在本技术实施例中，后台服务器可以将日志文件中与冷启动相关的关联信息发送至可视化服务平台，通过可视化服务平台展示出来，这样可视化服务平台也不再只是简单地展示冷启动时间，与冷启动相关的所有记录，不管是用户的还是设备的都可以显示出来。
91.设备服务器或如图2所示的可视化服务平台会每间隔预设时长，比如24小时就会获取冷启动的启动时长，计算这些启动时长的平均值，得到平均冷启动时长，当平均冷启动时长陡增(即平均值大于第一预设阈值)，或者平均冷启动时长陡减(即平均值小于第二预设阈值)的时候，会发告警通知给开发或者维护人员的工作台。
92.本技术实施例可以及时的发现冷启动异常问题，配合保存下来的启动日志，可以快速的定位和解决冷启动时长异常的问题。
93.需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本技术所必须的。
94.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom(read-only memory，只读存储器)/ram(random access memory，随机存取存储器)、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或
者网络设备等)执行本技术各个实施例的方法。
95.根据本技术实施例的另一个方面，还提供了一种用于实施上述启动时长异常的判定方法的启动时长异常的判定装置。图3是根据本技术实施例的一种可选的启动时长异常的判定装置的结构框图，如图3所示，该装置可以包括：
96.第一获取模块301，用于获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件；
97.第二获取模块302，用于在接收到目标应用对应的应用页面可见的情况下，获取冷启动的启动时长；
98.第三获取模块303，用于根据启动时长获取对应的日志文件；
99.判定模块304，用于根据日志文件判定产生启动时长异常的原因。
100.需要说明的是，该实施例中的第一获取模块301可以用于执行上述步骤s101，该实施例中的第二获取模块302可以用于执行上述步骤s102，该实施例中的第三获取模块303可以用于执行上述步骤s103，该实施例中的判定模块304可以用于执行上述步骤s104。
101.通过上述模块，利用指定人员，即实验用户的冷启动日志文件用以分析冷启动时长异常问题，可以在不影响普通用户体验的前提下及时发现启动时长异常并定位导致异常的原因，进而解决了相关技术中存在无法定位启动时长产生异常的具体问题。
102.作为一种可选的实施例，该装置还包括：
103.分配模块，用于在获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件之前，利用目标实验将实验用户分为实验组，将目标用户分为对照组，其中，目标实验用于根据实验组和对照组实现效果评估；
104.开启模块，用于在确定目标实验处于开启状态下，开启实验组内每个实验用户的实验设备。
105.作为一种可选的实施例，判定模块包括：
106.获取单元，用于在启动时长大于第一预设阈值或小于第二预设阈值的情况下，获取当下的时间点；
107.定位单元，用于根据时间点定位日志文件中的日志信息的目标位置；
108.分析单元，用于分析目标位置处产生启动时长异常的原因。
109.作为一种可选的实施例，第二获取模块包括：
110.第一记录单元，用于对目标应用的注解进行拦截，记录冷启动开始时间；
111.第二记录单元，用于在目标应用的应用页面首次获取到焦点时，记录冷启动结束时间；
112.第一得到单元，用于根据冷启动开始时间和冷启动结束时间，得到启动时长。
113.作为一种可选的实施例，第三获取模块包括：
114.结束记录单元，用于在接收到应用页面触发页面可见性事件时，结束记录日志文件；
115.第二得到单元，用于结合启动时长，得到处于启动时长内的所有日志文件。
116.作为一种可选的实施例，该装置还包括：
117.第四获取模块，用于每间隔预设时长获取冷启动的启动时长；
118.确定模块，用于确定多个启动时长的平均值；
119.发送模块，用于在平均值大于第一预设阈值或小于第二预设阈值的情况下，发送告警信息。
120.作为一种可选的实施例，该装置还包括：
121.显示模块，用于将日志文件中与冷启动相关的关联信息发送至可视化服务平台，使得可视化服务平台将关联信息进行显示。
122.根据本技术实施例的又一个方面，还提供了一种用于实施上述启动时长异常的判定方法的电子设备，该电子设备可以是服务器、终端、或者其组合。
123.图4是根据本技术实施例的一种可选的电子设备的结构框图，如图4所示，包括处理器401、通信接口402、存储器403和通信总线404，其中，处理器401、通信接口402和存储器403通过通信总线404完成相互间的通信，其中，
124.存储器403，用于存储计算机程序；
125.处理器401，用于执行存储器403上所存放的计算机程序时，实现如下步骤：
126.获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件；
127.在接收到目标应用对应的应用页面可见的情况下，获取冷启动的启动时长；
128.根据启动时长获取对应的日志文件；
129.根据日志文件判定产生启动时长异常的原因。
130.可选地，在本实施例中，上述的通信总线可以是pci(peripheral component interconnect，外设部件互连标准)总线、或eisa(extended industry standard architecture，扩展工业标准结构)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
131.通信接口用于上述电子设备与其他设备之间的通信。
132.存储器可以包括ram，也可以包括非易失性存储器(non-volatile memory)，例如，至少一个磁盘存储器。可选地，存储器还可以是至少一个位于远离前述处理器的存储装置。
133.作为一种示例，如图4所示，上述存储器403中可以但不限于包括上述启动时长异常的判定装置中的第一获取模块301、第二获取模块302、第三获取模块303、判定模块304。此外，还可以包括但不限于上述启动时长异常的判定装置中的其他模块单元，本示例中不再赘述。
134.上述处理器可以是通用处理器，可以包含但不限于：cpu(central processing unit，中央处理器)、np(network processor，网络处理器)等；还可以是dsp(digital signal processing，数字信号处理器)、asic(application specific integrated circuit，专用集成电路)、fpga(field－programmable gate array，现场可编程门阵列)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
135.此外，上述电子设备还包括：显示器，用于显示启动时长异常的判定结果。
136.可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。
137.本领域普通技术人员可以理解，图4所示的结构仅为示意，实施上述启动时长异常的判定方法的设备可以是终端设备，该终端设备可以是智能手机(如android手机、ios手机等)、平板电脑、掌上电脑以及移动互联网设备(mobile internet devices，mid)、pad等终
端设备。图4其并不对上述电子设备的结构造成限定。例如，终端设备还可包括比图4中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图4所示的不同的配置。
138.本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、rom、ram、磁盘或光盘等。
139.根据本技术实施例的又一个方面，还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行启动时长异常的判定方法的程序代码。
140.可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。
141.可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：
142.获取多个实验用户对应的实验设备在处于冷启动下对应的日志文件；
143.在接收到目标应用对应的应用页面可见的情况下，获取冷启动的启动时长；
144.根据启动时长获取对应的日志文件；
145.根据日志文件判定产生启动时长异常的原因。
146.可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例中对此不再赘述。
147.可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、rom、ram、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
148.根据本技术实施例的又一个方面，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中；计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一个实施例中的启动时长异常的判定方法步骤。
149.上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
150.上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本技术各个实施例启动时长异常的判定方法的全部或部分步骤。
151.在本技术的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
152.在本技术所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
153.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元
上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例中所提供的方案的目的。
154.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
155.以上仅是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。