CN112433877A - 应用启动崩溃的检测方法、装置、电子设备及存储介质 - Google Patents
应用启动崩溃的检测方法、装置、电子设备及存储介质 Download PDFInfo
- Publication number
- CN112433877A CN112433877A CN202011390316.8A CN202011390316A CN112433877A CN 112433877 A CN112433877 A CN 112433877A CN 202011390316 A CN202011390316 A CN 202011390316A CN 112433877 A CN112433877 A CN 112433877A
- Authority
- CN
- China
- Prior art keywords
- application
- identifier
- monitoring
- starting
- startup
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 74
- 238000012544 monitoring process Methods 0.000 claims abstract description 174
- 238000000034 method Methods 0.000 claims abstract description 63
- 230000008859 change Effects 0.000 claims abstract description 11
- 230000006870 function Effects 0.000 claims description 100
- 238000004590 computer program Methods 0.000 claims description 10
- 238000012790 confirmation Methods 0.000 claims description 6
- 238000010200 validation analysis Methods 0.000 claims description 4
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 230000008569 process Effects 0.000 abstract description 25
- 230000015556 catabolic process Effects 0.000 abstract 1
- 238000010586 diagram Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000001419 dependent effect Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000012216 screening Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000007599 discharging Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000005484 gravity Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000010079 rubber tapping Methods 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
- 238000010897 surface acoustic wave method Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明提供了一种应用启动崩溃的检测方法、装置、电子设备及存储介质。所述方法，包括：在应用启动时，获取所述应用是否存在连续多次启动崩溃；如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测；如果所述应用的主线程的运行循环状态超过指定时长未发生变化，抓取所述主线程堆栈的上下文，并基于所述主线程堆栈的上下文获取所述应用的函数调用栈；保存所述函数调用栈，并在下次启动所述应用时将所述函数调用栈上传日志。从而取得了降低启动崩溃检测过程中的额外性能消耗，提高崩溃检测效率的有益效果。
Description
技术领域
本发明涉及计算机技术领域，尤其涉及一种应用启动崩溃的检测方法、装置、电子设备及存储介质。
背景技术
APP(Application，应用)主线程卡顿监测已是业界广泛采用的技术手段。其主要通过在启动时监控主线程的runloop(运行循环)状态来判断主线程是否卡顿。当主线程的runloop的状态超过一定阈值未改变时，则认为是发生了卡顿，并在此时获取主线程的执行上下文，然后获取上下文中的调用栈帧，上传调用栈，进而解析堆栈符号，为解决卡顿提供堆栈线索。
但是上述技术方案缺乏一定的针对性，在每次启动时均进行崩溃检测，容易带来额外的性能消耗。在极端情况下，容易对性能较差的设备造成影响，甚至引起额外的卡顿崩溃。而且，还可能上报大量的卡顿堆栈。使得查找能引起启动崩溃的卡顿时需要额外进行筛选，因此整体方案的崩溃检测效率较低。
发明内容
本发明实施例提供一种应用启动崩溃的检测方法、装置、电子设备及存储介质，以解决现有的应用启动崩溃检测方案容易带来额外的性能消耗且崩溃检测效率较低的问题。
为了解决上述技术问题，本发明是这样实现的：
第一方面，本发明实施例提供了一种应用启动崩溃的检测方法，包括：
在应用启动时，获取所述应用是否存在连续多次启动崩溃；
如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测；
如果所述应用的主线程的运行循环状态超过指定时长未发生变化，抓取所述主线程堆栈的上下文，并基于所述主线程堆栈的上下文获取所述应用的函数调用栈；
保存所述函数调用栈，并在下次启动所述应用时将所述函数调用栈上传日志。
可选地，所述在应用启动时，获取所述应用是否存在连续多次启动崩溃的步骤，包括：
在应用启动时，获取所述应用上次启动的启动标识，所述启动标识表征所述应用的连续启动崩溃次数；
根据所述启动标识，确定所述应用是否存在连续多次启动崩溃。
可选地，在所述读取所述应用上次启动的启动标识的步骤之后，还包括：
将所述应用的启动标识表征的连续启动崩溃次数加1，并保存更新后的启动标识；
如果所述应用成功启动，将所述应用的启动标识所表征的连续启动崩溃次数清零，并保存更新后的启动标识；
所述如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测的步骤，包括：
如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
可选地，在所述通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测的步骤之前，还包括：
获取在所述应用本次启动之前由服务端下发的最新的卡顿监测标识，所述卡顿监测标识用于表征是否需要启动卡顿监测，所述卡顿监测标识由所述服务器在接收到针对卡顿监测的启动询问请求的情况下返回，所述启动询问请求在所述应用启动时发送；
所述如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测的步骤，包括：
如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，且所述应用当前获取的卡顿监测标识表征启动卡顿监测，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
可选地，所述获取所述应用上次启动的启动标识的步骤，包括：
通过在所述应用的最先执行的代码中设置的第一函数，获取所述应用上次启动的启动标识；
所述获取所述应用上一次启动时服务端下发的卡顿监测标识的步骤，包括：
通过在所述应用的最先执行的代码中设置的第二函数，获取所述应用上一次启动时服务端下发的卡顿监测标识。
可选地，所述通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测的步骤，包括：
通过预先注册的主线程的运行循环状态的监听函数，监听所述应用的主线程的运行循环状态；
当所述主线程的运行循环状态发生变化时，读取并保存变化后的运行循环状态；
周期性地循环检测保存的运行循环状态，以针对所述应用进行卡顿检测。
第二方面，本发明实施例提供了一种应用启动崩溃的检测装置，包括：
连续崩溃确认模块，用于在应用启动时，获取所述应用是否存在连续多次启动崩溃；
Runloop状态监听模块，用于如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测；
崩溃栈帧获取模块，用于如果所述应用的主线程的运行循环状态超过指定时长未发生变化，抓取所述主线程堆栈的上下文，并基于所述主线程堆栈的上下文获取所述应用的函数调用栈；
崩溃栈帧上传模块，用于保存所述函数调用栈，并在下次启动所述应用时将所述函数调用栈上传日志。
可选地，所述连续崩溃确认模块，包括：
启动标识获取子模块，用于在应用启动时，获取所述应用上次启动的启动标识，所述启动标识表征所述应用的连续启动崩溃次数；
连续崩溃确认子模块，用于根据所述启动标识，确定所述应用是否存在连续多次启动崩溃。
可选地，所述连续崩溃确认模块，还包括：
启动标识更新子模块，用于将所述应用的启动标识表征的连续启动崩溃次数加1，并保存更新后的启动标识；
启动标识清零子模块，用于如果所述应用成功启动，将所述应用的启动标识所表征的连续启动崩溃次数清零，并保存更新后的启动标识；
所述Runloop状态监听模块，包括：
第一状态监听子模块，用于如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
可选地，所述装置还包括：
卡顿监测标识获取模块，用于获取在所述应用本次启动之前由服务端下发的最新的卡顿监测标识，所述卡顿监测标识用于表征是否需要启动卡顿监测，所述卡顿监测标识由所述服务器在接收到针对卡顿监测的启动询问请求的情况下返回，所述启动询问请求在所述应用启动时发送；
所述Runloop状态监听模块，包括：
第二状态监听子模块，用于如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，且所述应用当前获取的卡顿监测标识表征启动卡顿监测，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
可选地，所述启动标识获取子模块，具体用于：
通过在所述应用的最先执行的代码中设置的第一函数，获取所述应用上次启动的启动标识；
所述卡顿监测标识获取模块，具体用于：
通过在所述应用的最先执行的代码中设置的第二函数，获取所述应用上一次启动时服务端下发的卡顿监测标识。
可选地，所述Runloop状态监听模块，具体用于：
通过预先注册的主线程的运行循环状态的监听函数，监听所述应用的主线程的运行循环状态；
当所述主线程的运行循环状态发生变化时，读取并保存变化后的运行循环状态；
周期性地循环检测保存的运行循环状态，以针对所述应用进行卡顿检测。
第三方面，本发明实施例另外提供了一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第一方面所述的应用启动崩溃的检测方法的步骤。
第四方面，本发明实施例另外提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的应用启动崩溃的检测方法的步骤。
在本发明实施例中，在应用启动时，获取所述应用是否存在连续多次启动崩溃；如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测；如果所述应用的主线程的运行循环状态超过指定时长未发生变化，抓取所述主线程堆栈的上下文，并基于所述主线程堆栈的上下文获取所述应用的函数调用栈；保存所述函数调用栈，并在下次启动所述应用时将所述函数调用栈上传日志。从而取得了降低启动崩溃检测过程中的额外性能消耗，提高崩溃检测效率的有益效果。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例中的一种应用启动崩溃的检测方法的步骤流程图；
图2是本发明实施例中的另一种应用启动崩溃的检测方法的步骤流程图；
图3是本发明实施例中的一种应用启动崩溃的检测装置的结构示意图；
图4是本发明实施例中的另一种应用启动崩溃的检测装置的结构示意图；
图5是本发明实施例中的一种电子设备的硬件结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
参照图1，示出了本发明实施例中一种应用启动崩溃的检测方法的步骤流程图。
步骤110，在应用启动时，获取所述应用是否存在连续多次启动崩溃；
步骤120，如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测；
步骤130，如果所述应用的主线程的运行循环状态超过指定时长未发生变化，抓取所述主线程堆栈的上下文，并基于所述主线程堆栈的上下文获取所述应用的函数调用栈；
步骤140，保存所述函数调用栈，并在下次启动所述应用时将所述函数调用栈上传日志。
本方案通过识别出应用的启动崩溃次数，在多次连续启动崩溃时，才抓取卡顿堆栈。从而保证每次的卡顿都对应一次启动崩溃，提高了日志的识别效率，避免了筛选。也即，在普通用户启动APP时，卡顿监测系统不会自启动，只有在连续多次启动崩溃的APP上才会自启动。
具体地，可以针对手机、电脑等电子设备中的任一应用，在该应用每次启动时，获取该应用是否存在连续多次启动崩溃，如果相应应用存在连续多次启动崩溃，则可以通过监听相应应用的主线程的运行循环状态，启动针对相应应用的卡顿检测。
其中，在本发明实施例中，可以通过任何可用统计应用的连续启动崩溃次数，而且统计应用的连续启动崩溃次数时，由于本次启动刚刚触发，并不可知本次启动是否成功，因此可以不考虑本次启动的启动结果，而仅考虑本次启动之前各次启动的启动结果。
例如，假设应用在本次启动之前的连续两次启动均失败，且本次启动之前的第三次启动成功，那么在本次启动时，相应应用的连续启动崩溃次数为2。
另外，在本发明实施例中，可以通过任何可用方式监听应用的主线程的运行循环(Runloop)状态，对此本发明实施例不加以限定。例如，以iOS操作系统为例，iOS系统提供了监听任意线程Runloop状态的函数，相应地Android等其他操作中也均可以实现监听应用的主线程的运行循环状态，对此本发明实施例不加以限定。
其中，Runloop的中文译为运行循环，其实内部是一个do-while循环，在这个循环中不断地处理各种任务。一个线程对应一个Runloop，主线程的Runloop默认自动启动，子线程的Runloop需要通过调用Runloop的run方法等方式手动启动。
如果监听到当前触发启动的应用的主线程的运行循环状态超过指定时长未发生变化，则说明相应应用出现启动卡顿进而容易导致应用启动崩溃，那么则可以抓取该应用的主线程堆栈的上下文，并基于所述主线程堆栈的上下文获取相应应用的函数调用栈，从而获取函数调用栈中的栈帧。
其中，每个栈帧(Stack Frame)对应着一个未运行完的函数。栈帧中保存了该函数的返回地址和局部变量。而且，在本发明实施例中，可以通过任何可用方式抓取应用的主线程堆栈和堆栈的上下文，以及基于堆栈的上下文获取函数调用栈，对此本发明实施例不加以限定。
例如，iOS提供了相关函数可以获取主线程的上下文以及通过上下文获取函数调用栈。
在获取得到函数调用栈之后，则可以保存相应函数调用栈，并在下次启动相应应用时将之前保存的函数调用栈上传至服务器的日志中。那么相应的维护人员则可以根据需求批量下载服务端的日志，并进行符号化后，即可得知相应应用连续启动崩溃时的卡顿堆栈，从而优化相应应用，以降低相应应用后续启动过程中的崩溃可能性。
其中，对于启动应用的电子设备而言，可以通过任何可用方式保存函数调用栈，例如将函数调用栈保存至本地或者是云端服务器等等，而且为了降低保存函数调用栈时所占用的存储空间，同时提高后续上传至日志时的上传效率，在保存函数调用栈时还可以对相应函数调用栈进行压缩，并保存压缩后的函数调用栈。在本发明实施例中，可以通过任何可用方式对函数调用栈进行压缩，对此本发明实施例不加以限定。
参照图2，在本发明实施例中，所述步骤110进一步可以包括：
步骤111，在应用启动时，获取所述应用上次启动的启动标识，所述启动标识表征所述应用的连续启动崩溃次数；
步骤112，根据所述启动标识，确定所述应用是否存在连续多次启动崩溃。
在本发明实施例中，为了快速且准确获取应用连续启动崩溃次数，可以预先针对需要进行崩溃检测的每个应用分别设置一启动标识，用于表征相应每个应用的连续启动崩溃次数，且在相应应用每次启动过程中，更新相应应用的启动标识。而且，对于电子设备而言，可以将应用的启动标识保存于本地，也可以保存于云端服务器等，对此本发明实施例不加以限定。优选地，为了可以在电子设备无网络的情况下仍然可以读取启动标识，可以将启动标识保存于本地，对此本发明实施例不加以限定。
例如，假设应用在本次启动之前的连续两次启动均崩溃，此时该应用的启动标识则为2，而如果应用在本次启动的前一次启动时启动成功，说明在本次启动的前一次启动时相应应用已不在连续启动崩溃，也即启动标识可以更新为0。
那么对于任一应用而言，为了确定其是否已存在多次启动崩溃，可以在在相应应用启动时，获取其上次启动的启动标识，所述启动标识表征所述应用的连续启动崩溃次数，进而可以根据当前获取的启动标识，确定相应应用是否存在连续多次启动崩溃。
例如，假设启动标识即为应用连续启动崩溃的次数，那么在获取的启动标识为大于2时，则表征相应应用存在连续多次启动崩溃，等等。
或者也可以仅在启动标识表征的连续启动崩溃次数为指定数值的情况下，才针对本次启动过程进行崩溃检测，也即通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。其中，指定数值的具体取值可以根据需求进行自定义设置，对此本发明实施例不加以限定。
可选地，在本发明实施例中，所述步骤111之后，还可以包括：
步骤113，将所述应用的启动标识表征的连续启动崩溃次数加1，并保存更新后的启动标识；
步骤114，如果所述应用成功启动，将所述应用的启动标识所表征的连续启动崩溃次数清零，并保存更新后的启动标识；
在本发明实施例中，为了保证每个应用的启动标识的准确性，可以在应用每次启动时，即将其启动标识表征的连续启动崩溃次数加1，并保存更新后的启动标识，如果应用成功启动，将相应应用的启动标识所表征的连续启动崩溃次数清零，并保存更新后的启动标识。
当然，在本发明实施例中，根据需求也可以设置仅在应用启动崩溃，也即启动失败的情况下才将其启动标识表征的连续启动崩溃次数加一，对此本发明实施例不加以限定。
但是在实际应用中，对启动标识的操作仅包括清零和加一的两种情况，而且如果应用启动成功，则可以将其启动标识表征的连续启动崩溃次数清空，否则即为启动崩溃那么连续启动崩溃次数需要加一。而如果如上述仅在应用启动崩溃的情况下才将其启动标识表征的连续启动崩溃次数加一，还需要另外增加一个判断应用是否发生启动崩溃的过程，而且需要在确定应用启动崩溃的情况下才返回将其启动标识表征的连续启动崩溃次数加一，并更新启动标识，相对于在启动时直接将启动标识表征的连续启动崩溃次数加一的方式，增加了启动标识更新过程的复杂度，因此优选地可以在应用启动时即将其启动标识表征的连续启动崩溃次数加一。
参照图2，在本发明实施例中，所述步骤120进一步可以包括：
步骤121，如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
此外，在实际应用中，在应用连续启动崩溃的情况下，如果同一应用在一段时间内连续启动多次，且连续启动崩溃，那么在该事件段内，该应用在每次启动时都会执行上述的步骤120-140，以使得同一应用在一段时间内多次上传函数调用栈，但是一般而言同一应用在某一时间段内连续出现的启动崩溃可能是由于相同原因导致的，那么如果在该时间段内多次上传函数调用栈，仍然可能会上报大量重复的函数调用栈，而且给电子设备端的APP造成额外的性能消耗。
因此，在本发明实施例中，可以设置仅在应用的连续启动崩溃次数为指定数值时，才启动针对该应用的卡顿检测。其中的指定数值可以根据需求进行自定义设置，对此本发明实施例不加以限定。一般而言，指定数值可以为2、3等单一数值；当然指定数值也可以为满足指定条件的多个数值，其中的指定条件可以根据需求进行自定义设置，例如指定数值可以为偶数，或者是3的整数倍，等等。
假设某一应用的指定数值为2，那么在该应用启动时，可以获取其前一次启动时更新后的启动标识，可以表征该应用当前已有的连续启动崩溃次数，如果本次启动时获取的启动标识表征的连续启动崩溃次数为2，那么则可以启动针对该应用的卡顿检测。如果某次启动时获取的启动标识表征的连续启动崩溃次数为3，则无需启动针对该应用的卡顿检测。
参照图2，在本发明实施例中，在所述步骤120之前，进一步还可以包括：
步骤10，获取在所述应用本次启动之前由服务端下发的最新的卡顿监测标识，所述卡顿监测标识用于表征是否需要启动卡顿监测；
其中，所述卡顿监测标识由所述服务器在接收到针对卡顿监测的启动询问请求的情况下返回，所述启动询问请求在所述应用启动时发送。
另外，为了增加启动的安全性，还可以在服务器端针对卡顿监测添加后台开关控制，如果方案存在明显的性能问题等情况，则可以通过后台接口来屏蔽此卡顿监测功能，提高使用的安全性。
具体地，在每次启动应用时，还可以通过预先设置的数据接口，向服务器端询问下次启动应用是否关闭卡顿监测。而且可以与服务器端进行接口定义，定义表征是否需要启动卡顿监测的具体形式。例如，假设定义字段noTrackLog作为卡顿监测标识用于表征是否需要启动卡顿监测。当服务器端当前下发的noTrackLog为1时，相应应用下次启动时无论任何情况都不启动卡顿监测。否则，在启动标识满足条件的情况下则可以启动卡顿监测。而且当收到新的noTrackLog字段后，为了便于判断，可以将最新的noTrackLog的数据保存到本地，而且为了避免存储空间浪费，可以仅保存最新的noTrackLog的数据，对此本发明实施例不加以限定。
如上述，由于每次启动时向服务器请求询问的是下一次启动是否进行卡顿检测，而且可能出现启动时未向服务器询问或者是服务器未返回卡顿监测标识的情况，那么则可以参照在本次启动之前服务器最新下发的卡顿监测标识。那么在每次启动时，为了获知本次启动是否进行卡顿检测，则可以获取在所述应用本次启动之前由服务端下发的最新的卡顿监测标识，此时获取的卡顿监测标识可以表征本次启动时是否可以进行卡顿检测。
而且，为了方便电子设备端的应用获取服务器下发的卡顿监测标识，可以将卡顿监测标识保存在本地，当然也可以将卡顿监测标识保存在云端服务器等其他存储区域，对此本发明实施例不加以限定。
此外，在本发明实施例中，如果同时对同一电子设备中的多个应用均可以进行启动崩溃检测，那么服务器在下发卡顿监测标识时可以适用于各个应用。也即，同一电子设备中的多个应用可以共用卡顿监测标识，那么针对电子设备中的任一应用，当该应用启动时，则可以通过预先设置的数据接口，向服务器端询问下次启动应用是否关闭卡顿监测，服务器则可以下发卡顿监测标识以指示下次启动应用是否关闭卡顿监测。那么针对同一电子设备中的任一应用启动时，则可以基于相应电子设备在该应用的本次启动之前获取的卡顿监测标识，以确定是否启动针对在该应用的本次启动进行卡顿检测。
当然，在本发明实施例中，也可以设置各个应用的卡顿监测标识互不共享，那么服务器每次下发的即为针对当前启动的应用的卡顿监测标识，以表征该应用下次启动时是否可以进行卡顿检测，对此本发明实施例不加以限定。
可选地，在本发明实施例中，所述步骤121进一步可以包括：如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，且所述应用当前获取的卡顿监测标识表征启动卡顿监测，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
如上述，如果同时通过服务器控制卡顿检测是否启动，那么此时可以设置卡顿检测的启动条件为应用当前的启动标识所表征的连续启动崩溃次数为指定数值，且所述应用当前获取的卡顿监测标识表征启动卡顿监测。相应地，针对任一触发进行启动应用而言，如果当前的获取的该应用的启动标识所表征的连续启动崩溃次数为指定数值，且所述应用当前获取的卡顿监测标识表征启动卡顿监测，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
可选地，在本发明实施例中，获取所述应用上次启动的启动标识的过程，具体可以包括：
通过在所述应用的最先执行的代码中设置的第一函数，获取所述应用上次启动的启动标识；
可选地，在本发明实施例中，获取所述应用上一次启动时服务端下发的卡顿监测标识的过程，具体可以包括：
通过在所述应用的最先执行的代码中设置的第二函数，获取所述应用上一次启动时服务端下发的卡顿监测标识。
在本发明实施例中，为了快速确定是否启动卡顿检测，需要在应用触发启动时快速获取相应应用上次启动的启动标识、相应应用对应的上一次启动时服务端下发的卡顿监测标识等参数。而在实际应用中，应用对应的程序中一般包含很多代码，而且代码的执行过程需要一定时间且代码有一定的执行顺序，那么为了快速获取上述参数，则可以分别在应用的最先执行的代码中设置用于获取启动标识的第一函数、用于获取应用上一次启动时服务端下发的卡顿监测标识的第二函数。进而可以通过在所述应用的最先执行的代码中设置的第一函数，获取所述应用上次启动的启动标识，和/或，通过在所述应用的最先执行的代码中设置的第二函数，获取所述应用上一次启动时服务端下发的卡顿监测标识。
其中，第一函数和第二函数的具体形式可以根据需求进行自定义设置，对此本发明实施例不加以限定。
可选地，在本发明实施例中，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测的过程，具体可以包括：
步骤S1，通过预先注册的主线程的运行循环状态的监听函数，监听所述应用的主线程的运行循环状态；
步骤S2，当所述主线程的运行循环状态发生变化时，读取并保存变化后的运行循环状态；
步骤S3，周期性地循环检测保存的运行循环状态，以针对所述应用进行卡顿检测。
为了针对应用进行卡顿检测，首先可以注册对该应用的主线程的runloop状态的监听函数，其中注册监听为系统方法。以iOS为例，iOS系统提供了监听任意线程runloop的函数，当调用此函数时，可以将监听者注入程序，当应用的主线程的runloop状态发生变化时，iOS系统会回调执行提前约定好的函数。在执行该提前约定好的函数时，可以获知当前所监听的runloop的状态。假设提前约定的回调函数为runloopCallback。当runloop状态变化时，iOS系统会执行runloopCallback函数，以读取并保存变化后的运行循环状态。
通过runloopCallback函数，可以获取当前runloop的状态，并保存到内存中。
另外，在执行上述获取运行循环状态的步骤的同时，还可以周期性地循环检测保存的运行循环状态，以针对所述应用进行卡顿检测。而且在本发明实施例中，可以通过任何可用方式周期性地循环检测保存的运行循环状态，循环周期的时长可以根据需求进行自定义设置，对此本发明实施例不加以限定。进行例如可以开启一个子线程，子线程中定时循环检测内存在保存的runloop状态。如果runloop状态超过指定时长(例如4秒等)未发生变化，则说明该应用的主线程卡顿，也即应用卡顿，进而会导致应用崩溃，此时则可以停止执行步骤S3。
如果应用主线程卡顿，则需要抓取主线程此时的堆栈。此时获取主线程堆栈的上下文，并通过上下文依次获取函数调用栈的栈帧。iOS提供了相关函数可以获取主线程的上下文以及通过上下文获取函数调用栈。
如下所述为本发明实施例一种应用启动崩溃检测过程示例。具体包括以下步骤：
1、在程序最先执行的代码(例如最先执行的一段代码，首行代码)中，在本地磁盘读取上次启动的启动标识。假设启动标识的数据格式为
{“launchTimes”:“1”}
其中，launchTimes字段为累计的连续启动崩溃次数。通过读取launchTimes字段，可以获取上次启动时启动崩溃的次数。
2、获取到launchTimes后，对launchTimes的数据进行+1，然后写入到本地磁盘保存。
3、在启动成功后，将本地保存的启动标识清空，即将launchTimes数据清零，达到清空启动崩溃数据的目的。
4、在应用启动时，请求数据接口，向服务端询问下次启动是否关闭卡顿监测系统。与服务端进行接口定义，假设定义字段noTrackLog用于屏蔽卡顿监测系统。当服务端下发noTrackLog为1时，下次启动时无论任何情况都不启动卡顿监测系统。否则，满足启动条件则启动卡顿监测系统。当收到noTrackLog字段后，将noTrackLog的数据保存到本地。
5、在程序最先执行的代码中进行判断，如果launchTimes满足启动条件(例如launchTimes为2)，并且上次启动时服务端下发的noTrackLog不为1，则说明需要启动卡顿监测系统。
6、启动卡顿监测系统时首先需要注册对主线程的runloop监听。注册监听为系统方法。以iOS为例，iOS系统提供了监听任意线程runloop的函数，当调用此函数时，会将监听者注入程序，当主线程的runloop状态发生变化时，iOS系统会回调执行提前约定好的函数。在执行该函数时，会获知所监听的runloop的状态。假设此时注册的回调函数为runloopCallback。当runloop状态变化时，iOS系统会执行runloopCallback。
7、在runloopCallback中，可以获取当前runloop的状态，并保存到内存中。
8、在执行步骤6的同时，开启一个子线程，子线程中定时循环检测内存在保存的runloop状态。如果runloop状态超过一定时间阈值未发生变化，则说明主线程卡顿。
9、在步骤8中，如果主线程卡顿，则需要抓取主线程此时的堆栈。此时获取主线程堆栈的上下文，并通过上下文依次获取函数调用栈的栈帧。iOS提供了相关函数可以获取主线程的上下文以及通过上下文获取函数调用栈。
10、将函数调用栈保存到本地，进行压缩。假设本次启动崩溃，则在下次启动时上传日志。
11、批量下载服务端的日志，并进行符号化后，即可得知连续启动崩溃时的卡顿堆栈。
在本发明实施例中，在应用多次连续启动崩溃时，抓取卡顿堆栈。从而保证每次的卡顿都对应一次启动崩溃，提高了日志的识别效率，避免了筛选。而且，通过启动标识来识别启动异常并自动启动卡顿监控，避免了额外的性能消耗。此外，通过服务器下发的卡顿监测标识作为接口开关的控制，保证了整个启动崩溃检测系统的安全可控性。
在普通用户启动APP时，不会自启动卡顿监测，只有在连续启动崩溃的APP上才会自启动卡顿监测，当抓取到堆栈后，下次启动不会再进行卡顿监测，具备一定的智能学习能力，避免了对手机性能的消耗。
需要说明的是，在本发明实施例中，应用卡顿则会导致应用崩溃，因此在统计应用启动连续崩溃次数时，可以任务应用启动时如果其主线程的运行循环状态超过指定时长未发生变化，则认为该应用启动崩溃，对此本发明实施例不加以限定。当然，在本发明实施例中，可以通过任何可用方式统计应用启动连续崩溃次数，对此本发明实施例不加以限定。
参照图3，示出了本发明实施例中一种应用启动崩溃的检测装置的结构示意图。
本发明实施例的应用启动崩溃的检测装置包括：连续崩溃确认模块210、Runloop状态监听模块220、崩溃栈帧获取模块230和崩溃栈帧上传模块240。
下面分别详细介绍各模块的功能以及各模块之间的交互关系。
连续崩溃确认模块210，用于在应用启动时，获取所述应用是否存在连续多次启动崩溃；
Runloop状态监听模块220，用于如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测；
崩溃栈帧获取模块230，用于如果所述应用的主线程的运行循环状态超过指定时长未发生变化，抓取所述主线程堆栈的上下文，并基于所述主线程堆栈的上下文获取所述应用的函数调用栈；
崩溃栈帧上传模块240，用于保存所述函数调用栈，并在下次启动所述应用时将所述函数调用栈上传日志。
参照图4，在本发明实施例中，所述连续崩溃确认模块210，进一步可以包括：
启动标识获取子模块211，用于在应用启动时，获取所述应用上次启动的启动标识，所述启动标识表征所述应用的连续启动崩溃次数；
连续崩溃确认子模块212，用于根据所述启动标识，确定所述应用是否存在连续多次启动崩溃。
可选地，在本发明实施例中，所述连续崩溃确认模块210，还可以包括：
启动标识更新子模块，用于将所述应用的启动标识表征的连续启动崩溃次数加1，并保存更新后的启动标识；
启动标识清零子模块，用于如果所述应用成功启动，将所述应用的启动标识所表征的连续启动崩溃次数清零，并保存更新后的启动标识；
可选地，在本发明实施例中，所述Runloop状态监听模块220，进一步可以包括：
第一状态监听子模块，用于如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
参照图4，在本发明实施例中，所述装置还可以包括：
卡顿监测标识获取模块250，用于获取在所述应用本次启动之前由服务端下发的最新的卡顿监测标识，所述卡顿监测标识用于表征是否需要启动卡顿监测，所述卡顿监测标识由所述服务器在接收到针对卡顿监测的启动询问请求的情况下返回，所述启动询问请求在所述应用启动时发送；
可选地，所述Runloop状态监听模块，还可以包括：
第二状态监听子模块，用于如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，且所述应用当前获取的卡顿监测标识表征启动卡顿监测，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
可选地，在本发明实施例中，所述启动标识获取子模块，具体可以用于：通过在所述应用的最先执行的代码中设置的第一函数，获取所述应用上次启动的启动标识；
可选地，在本发明实施例中，所述卡顿监测标识获取模块，具体可以用于：通过在所述应用的最先执行的代码中设置的第二函数，获取所述应用上一次启动时服务端下发的卡顿监测标识。
可选地，在本发明实施例中，所述Runloop状态监听模块，具体可以用于：
通过预先注册的主线程的运行循环状态的监听函数，监听所述应用的主线程的运行循环状态；
当所述主线程的运行循环状态发生变化时，读取并保存变化后的运行循环状态；
周期性地循环检测保存的运行循环状态，以针对所述应用进行卡顿检测。
本发明实施例提供的应用启动崩溃的检测装置能够实现图1至图2的方法实施例中实现的各个过程，为避免重复，这里不再赘述。
优选的，本发明实施例还提供了一种电子设备，包括：处理器，存储器，存储在存储器上并可在处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述应用启动崩溃的检测方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述应用启动崩溃的检测方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random AccessMemory，简称RAM)、磁碟或者光盘等。
图5为实现本发明各个实施例的一种电子设备的硬件结构示意图。
该电子设备500包括但不限于：射频单元501、网络模块502、音频输出单元503、输入单元504、传感器505、显示单元506、用户输入单元507、接口单元508、存储器509、处理器510、以及电源511等部件。本领域技术人员可以理解，图5中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。在本发明实施例中，电子设备包括但不限于手机、平板电脑、笔记本电脑、掌上电脑、车载终端、可穿戴设备、以及计步器等。
应理解的是，本发明实施例中，射频单元501可用于收发信息或通话过程中，信号的接收和发送，具体的，将来自基站的下行数据接收后，给处理器510处理；另外，将上行的数据发送给基站。通常，射频单元501包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外，射频单元501还可以通过无线通信系统与网络和其他设备通信。
电子设备通过网络模块502为用户提供了无线的宽带互联网访问，如帮助用户收发电子邮件、浏览网页和访问流式媒体等。
音频输出单元503可以将射频单元501或网络模块502接收的或者在存储器509中存储的音频数据转换成音频信号并且输出为声音。而且，音频输出单元503还可以提供与电子设备500执行的特定功能相关的音频输出(例如，呼叫信号接收声音、消息接收声音等等)。音频输出单元503包括扬声器、蜂鸣器以及受话器等。
输入单元504用于接收音频或视频信号。输入单元504可以包括图形处理器(Graphics Processing Unit，GPU)5041和麦克风5042，图形处理器5041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元506上。经图形处理器5041处理后的图像帧可以存储在存储器509(或其它存储介质)中或者经由射频单元501或网络模块502进行发送。麦克风5042可以接收声音，并且能够将这样的声音处理为音频数据。处理后的音频数据可以在电话通话模式的情况下转换为可经由射频单元501发送到移动通信基站的格式输出。
电子设备500还包括至少一种传感器505，比如光传感器、运动传感器以及其他传感器。具体地，光传感器包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板5061的亮度，接近传感器可在电子设备500移动到耳边时，关闭显示面板5061和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别电子设备姿态(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；传感器505还可以包括指纹传感器、压力传感器、虹膜传感器、分子传感器、陀螺仪、气压计、湿度计、温度计、红外线传感器等，在此不再赘述。
显示单元506用于显示由用户输入的信息或提供给用户的信息。显示单元506可包括显示面板5061，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板5061。
用户输入单元507可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。具体地，用户输入单元507包括触控面板5071以及其他输入设备5072。触控面板5071，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板5071上或在触控面板5071附近的操作)。触控面板5071可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器510，接收处理器510发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板5071。除了触控面板5071，用户输入单元507还可以包括其他输入设备5072。具体地，其他输入设备5072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。
进一步的，触控面板5071可覆盖在显示面板5061上，当触控面板5071检测到在其上或附近的触摸操作后，传送给处理器510以确定触摸事件的类型，随后处理器510根据触摸事件的类型在显示面板5061上提供相应的视觉输出。虽然在图5中，触控面板5071与显示面板5061是作为两个独立的部件来实现电子设备的输入和输出功能，但是在某些实施例中，可以将触控面板5071与显示面板5061集成而实现电子设备的输入和输出功能，具体此处不做限定。
接口单元508为外部装置与电子设备500连接的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。接口单元508可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到电子设备500内的一个或多个元件或者可以用于在电子设备500和外部装置之间传输数据。
存储器509可用于存储软件程序以及各种数据。存储器509可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器509可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
处理器510是电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器509内的软件程序和/或模块，以及调用存储在存储器509内的数据，执行电子设备的各种功能和处理数据，从而对电子设备进行整体监控。处理器510可包括一个或多个处理单元；优选的，处理器510可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器510中。
电子设备500还可以包括给各个部件供电的电源511(比如电池)，优选的，电源511可以通过电源管理系统与处理器510逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
另外，电子设备500包括一些未示出的功能模块，在此不再赘述。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。
本领域普通技术人员可以意识到，结合本发明实施例中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。
Claims (14)
1.一种应用启动崩溃的检测方法，其特征在于，包括：
在应用启动时，获取所述应用是否存在连续多次启动崩溃；
如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测；
如果所述应用的主线程的运行循环状态超过指定时长未发生变化，抓取所述主线程堆栈的上下文，并基于所述主线程堆栈的上下文获取所述应用的函数调用栈；
保存所述函数调用栈，并在下次启动所述应用时将所述函数调用栈上传日志。
2.根据权利要求1所述的方法，其特征在于，所述在应用启动时，获取所述应用是否存在连续多次启动崩溃的步骤，包括：
在应用启动时，获取所述应用上次启动的启动标识，所述启动标识表征所述应用的连续启动崩溃次数；
根据所述启动标识，确定所述应用是否存在连续多次启动崩溃。
3.根据权利要求2所述的方法，其特征在于，在所述读取所述应用上次启动的启动标识的步骤之后，还包括：
将所述应用的启动标识表征的连续启动崩溃次数加1，并保存更新后的启动标识；
如果所述应用成功启动，将所述应用的启动标识所表征的连续启动崩溃次数清零，并保存更新后的启动标识；
所述如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测的步骤，包括：
如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
4.根据权利要求3所述的方法，其特征在于，在所述通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测的步骤之前，还包括：
获取在所述应用本次启动之前由服务端下发的最新的卡顿监测标识，所述卡顿监测标识用于表征是否需要启动卡顿监测，所述卡顿监测标识由所述服务器在接收到针对卡顿监测的启动询问请求的情况下返回，所述启动询问请求在所述应用启动时发送；
所述如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测的步骤，包括：
如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，且所述应用当前获取的卡顿监测标识表征启动卡顿监测，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
5.根据权利要求4所述的方法，其特征在于，所述获取所述应用上次启动的启动标识的步骤，包括：
通过在所述应用的最先执行的代码中设置的第一函数，获取所述应用上次启动的启动标识；
所述获取所述应用上一次启动时服务端下发的卡顿监测标识的步骤，包括：
通过在所述应用的最先执行的代码中设置的第二函数，获取所述应用上一次启动时服务端下发的卡顿监测标识。
6.根据权利要求1-5中任一项所述的方法，其特征在于，所述通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测的步骤，包括：
通过预先注册的主线程的运行循环状态的监听函数，监听所述应用的主线程的运行循环状态；
当所述主线程的运行循环状态发生变化时，读取并保存变化后的运行循环状态；
周期性地循环检测保存的运行循环状态，以针对所述应用进行卡顿检测。
7.一种应用启动崩溃的检测装置，其特征在于，包括：
连续崩溃确认模块，用于在应用启动时，获取所述应用是否存在连续多次启动崩溃；
Runloop状态监听模块，用于如果所述应用存在连续多次启动崩溃，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测；
崩溃栈帧获取模块，用于如果所述应用的主线程的运行循环状态超过指定时长未发生变化，抓取所述主线程堆栈的上下文，并基于所述主线程堆栈的上下文获取所述应用的函数调用栈；
崩溃栈帧上传模块，用于保存所述函数调用栈，并在下次启动所述应用时将所述函数调用栈上传日志。
8.根据权利要求7所述的装置，其特征在于，所述连续崩溃确认模块，包括：
启动标识获取子模块，用于在应用启动时，获取所述应用上次启动的启动标识，所述启动标识表征所述应用的连续启动崩溃次数；
连续崩溃确认子模块，用于根据所述启动标识，确定所述应用是否存在连续多次启动崩溃。
9.根据权利要求8所述的装置，其特征在于，所述连续崩溃确认模块，还包括：
启动标识更新子模块，用于将所述应用的启动标识表征的连续启动崩溃次数加1，并保存更新后的启动标识；
启动标识清零子模块，用于如果所述应用成功启动，将所述应用的启动标识所表征的连续启动崩溃次数清零，并保存更新后的启动标识；
所述Runloop状态监听模块，包括：
第一状态监听子模块，用于如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
10.根据权利要求9所述的装置，其特征在于，还包括：
卡顿监测标识获取模块，用于获取在所述应用本次启动之前由服务端下发的最新的卡顿监测标识，所述卡顿监测标识用于表征是否需要启动卡顿监测，所述卡顿监测标识由所述服务器在接收到针对卡顿监测的启动询问请求的情况下返回，所述启动询问请求在所述应用启动时发送；
所述Runloop状态监听模块，包括：
第二状态监听子模块，用于如果所述应用当前的启动标识所表征的连续启动崩溃次数为指定数值，且所述应用当前获取的卡顿监测标识表征启动卡顿监测，通过监听所述应用的主线程的运行循环状态，启动针对所述应用的卡顿检测。
11.根据权利要求10所述的装置，其特征在于，所述启动标识获取子模块，具体用于：
通过在所述应用的最先执行的代码中设置的第一函数，获取所述应用上次启动的启动标识；
所述卡顿监测标识获取模块，具体用于：
通过在所述应用的最先执行的代码中设置的第二函数，获取所述应用上一次启动时服务端下发的卡顿监测标识。
12.根据权利要求7-11中任一项所述的装置，其特征在于，所述Runloop状态监听模块，具体用于：
通过预先注册的主线程的运行循环状态的监听函数，监听所述应用的主线程的运行循环状态；
当所述主线程的运行循环状态发生变化时，读取并保存变化后的运行循环状态；
周期性地循环检测保存的运行循环状态，以针对所述应用进行卡顿检测。
13.一种电子设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至6中任一项所述的应用启动崩溃的检测方法的步骤。
14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6中任一项所述的应用启动崩溃的检测方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011390316.8A CN112433877B (zh) | 2020-12-01 | 2020-12-01 | 应用启动崩溃的检测方法、装置、电子设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011390316.8A CN112433877B (zh) | 2020-12-01 | 2020-12-01 | 应用启动崩溃的检测方法、装置、电子设备及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112433877A true CN112433877A (zh) | 2021-03-02 |
| CN112433877B CN112433877B (zh) | 2024-05-17 |
Family
ID=74698898
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011390316.8A Active CN112433877B (zh) | 2020-12-01 | 2020-12-01 | 应用启动崩溃的检测方法、装置、电子设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112433877B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113688048A (zh) * | 2021-08-27 | 2021-11-23 | 北京字节跳动网络技术有限公司 | 一种应用稳定性检测方法、装置、电子设备及存储介质 |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060206873A1 (en) * | 2005-03-11 | 2006-09-14 | Argade Pramod V | Environment for run control of computer programs |
| US20080244331A1 (en) * | 2007-03-28 | 2008-10-02 | Grimes Andrew W | System and Method for In-Band Problem Log Data Collection Between a Host System and a Storage System |
| US20130031462A1 (en) * | 2011-07-26 | 2013-01-31 | Ramiro Calvo | Web application architecture |
| WO2018082176A1 (zh) * | 2016-11-03 | 2018-05-11 | 华为技术有限公司 | 处理终端设备的故障的方法和终端设备 |
| CN110865898A (zh) * | 2019-10-12 | 2020-03-06 | 北京字节跳动网络技术有限公司 | 崩溃调用栈聚合的方法、装置、介质和设备 |
| CN110941551A (zh) * | 2019-11-21 | 2020-03-31 | 腾讯科技（深圳）有限公司 | 一种应用卡顿检测方法、装置、设备及计算机存储介质 |
| US10635519B1 (en) * | 2017-11-30 | 2020-04-28 | Uptake Technologies, Inc. | Systems and methods for detecting and remedying software anomalies |
| CN111381992A (zh) * | 2020-03-06 | 2020-07-07 | 北京五八信息技术有限公司 | 一种崩溃日志处理方法、装置、电子设备及存储介质 |
| CN111625456A (zh) * | 2020-05-26 | 2020-09-04 | 北京达佳互联信息技术有限公司 | 一种卡顿定位方法和装置 |
-
2020
- 2020-12-01 CN CN202011390316.8A patent/CN112433877B/zh active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060206873A1 (en) * | 2005-03-11 | 2006-09-14 | Argade Pramod V | Environment for run control of computer programs |
| US20080244331A1 (en) * | 2007-03-28 | 2008-10-02 | Grimes Andrew W | System and Method for In-Band Problem Log Data Collection Between a Host System and a Storage System |
| US20130031462A1 (en) * | 2011-07-26 | 2013-01-31 | Ramiro Calvo | Web application architecture |
| WO2018082176A1 (zh) * | 2016-11-03 | 2018-05-11 | 华为技术有限公司 | 处理终端设备的故障的方法和终端设备 |
| US10635519B1 (en) * | 2017-11-30 | 2020-04-28 | Uptake Technologies, Inc. | Systems and methods for detecting and remedying software anomalies |
| CN110865898A (zh) * | 2019-10-12 | 2020-03-06 | 北京字节跳动网络技术有限公司 | 崩溃调用栈聚合的方法、装置、介质和设备 |
| CN110941551A (zh) * | 2019-11-21 | 2020-03-31 | 腾讯科技（深圳）有限公司 | 一种应用卡顿检测方法、装置、设备及计算机存储介质 |
| CN111381992A (zh) * | 2020-03-06 | 2020-07-07 | 北京五八信息技术有限公司 | 一种崩溃日志处理方法、装置、电子设备及存储介质 |
| CN111625456A (zh) * | 2020-05-26 | 2020-09-04 | 北京达佳互联信息技术有限公司 | 一种卡顿定位方法和装置 |
Non-Patent Citations (2)
| Title |
|---|
| CAICAINO.1: "iOS开发-App应用崩溃卡顿分析", pages 1 - 4, Retrieved from the Internet <URL:https://blog.csdn.net/shengpeng3344/article/details/105303136/> * |
| WEIXIN_26638123: "ios崩溃分析_在iOS中访问和分析崩溃报告", Retrieved from the Internet <URL:https://blog.csdn.net/weixin_26638123/article/details/108171940> * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113688048A (zh) * | 2021-08-27 | 2021-11-23 | 北京字节跳动网络技术有限公司 | 一种应用稳定性检测方法、装置、电子设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112433877B (zh) | 2024-05-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108459797B (zh) | 一种折叠屏的控制方法及移动终端 | |
| CN109078319B (zh) | 一种游戏界面显示方法和终端 | |
| CN108681498B (zh) | 一种cpu占用率的监测方法、装置以及移动终端 | |
| CN109885323B (zh) | 一种应用程序升级方法、移动终端和可读存储介质 | |
| CN108984066B (zh) | 一种应用程序图标显示方法及移动终端 | |
| CN107977113B (zh) | 一种控制方法及移动终端 | |
| CN109544172B (zh) | 一种显示方法及终端设备 | |
| CN109325334B (zh) | 一种触控终端控制方法和触控终端 | |
| CN111131607A (zh) | 一种信息共享方法、电子设备及计算机可读存储介质 | |
| CN108009031B (zh) | 一种应用程序的控制方法及移动终端 | |
| CN108388400B (zh) | 一种操作处理方法及移动终端 | |
| CN108089935B (zh) | 一种应用程序的管理方法及移动终端 | |
| CN108388459B (zh) | 一种消息显示处理方法及移动终端 | |
| CN114428546A (zh) | 后台应用清理方法、装置、存储介质及终端设备 | |
| CN107872367B (zh) | 黑屏检测方法、移动终端及计算机可读存储介质 | |
| CN107832191B (zh) | 黑屏检测方法、移动终端及计算机可读存储介质 | |
| CN112596980A (zh) | ios性能收集方法及装置、移动终端、计算机可读存储介质 | |
| CN112433877B (zh) | 应用启动崩溃的检测方法、装置、电子设备及存储介质 | |
| CN109508425B (zh) | 一种设置项推荐方法及终端设备 | |
| CN109902232B (zh) | 显示控制方法及终端 | |
| CN109413592B (zh) | 一种广播方法和移动终端 | |
| CN109660657B (zh) | 一种应用程序控制方法及装置 | |
| CN109327605B (zh) | 一种显示控制方法、装置和移动终端 | |
| CN108170360B (zh) | 一种手势功能的控制方法及移动终端 | |
| CN108459796B (zh) | 一种功能键的响应方法及移动终端 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |