CN114756406A - 应用程序崩溃的处理方法、装置及电子设备 - Google Patents

Abstract

本申请实施例提供了一种应用程序崩溃的处理方法、装置、电子设备及计算机可读存储介质，涉及终端领域。该方法包括：根据检测到目标应用程序在当前时刻发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；若确定第一历史次数和第一时差均符合第一展示条件，则展示提示界面，提示界面中包括修复控件；响应于触发修复控件，清除目标应用程序的本地缓。本申请实施例能够有效识别应用程序发送连续崩溃，并引导用户通过清除缓存修复应用程序，避免连续闪退。

Description

应用程序崩溃的处理方法、装置及电子设备

技术领域

本申请涉及终端技术领域，具体而言，本申请涉及一种应用程序崩溃的处理方法、装置及电子设备。

背景技术

随着科技的发展，终端设备在人们的生活中有着不可或缺的用处，而每个终端设备中均安装有各种应用程序，在应用程序发生崩溃(crash)时，例如点击进入应用程序出现乱码显示，或者页面错误等，需要对崩溃的应用程序进行修复，以保证应用程序对应的功能的执行。

在iOS系统中，当应用程序发生连续崩溃时，由于用户无法顺利对补丁进行下载，而应用程序的版本更新需要较长的时间周期，因此无法及时对应用程序进行修复，从而降低了应用程序的修复效率。

发明内容

本申请实施例提供了一种应用程序崩溃的处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品，可以解决现有技术的上述问题。技术方案如下：

根据本申请实施例的一个方面，提供了一种应用程序崩溃的处理方法，该方法包括：

根据检测到目标应用程序在当前时刻发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；

若确定第一历史次数和第一时差均符合第一展示条件，则展示提示界面，提示界面中包括修复控件；

响应于触发修复控件，清除目标应用程序的本地缓存。

作为一种可选的实施例，处理方法还包括：

若确定第一历史次数和第一时差中的至少一种不符合第一展示条件，则确定目标应用程序在第二目标生命周期阶段发生崩溃的第二历史次数、最近一次在第二目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第二时差以及与第二目标生命周期阶段对应的第二展示条件；

若确定第二历史次数和第二时差均符合第二展示条件，则展示提示界面，提示界面中包括修复控件；

响应于触发修复控件，清除目标应用程序的本地缓存。

作为一种可选的实施例，第一目标生命周期阶段为启动阶段，第二目标生命周期阶段为运行阶段。

作为一种可选的实施例，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件，之前还包括：

将目标应用程序在当前时刻所处的生命周期阶段，作为第一目标生命周期阶段。

作为一种可选的实施例，当第一目标生命周期阶段为运行阶段时，展示提示界面，包括：

确定第二历史时段内提示界面的展示次数，若展示次数未超过预设数值，则展示提示界面。

作为一种可选的实施例，提示界面中包括用于指示目标应用程序出现连续崩溃已被检测的提示信息。

作为一种可选的实施例，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数，包括：

获取目标应用程序在第一历史时段内的各生命周期信息；

确定各生命周期信息中的目标生命周期信息的数量，将数量作为目标应用程序在第一目标生命周期阶段发生崩溃的历史次数；

其中，目标生命周期信息包括预设标记且预设标记对应第一目标生命周期阶段。

作为一种可选的实施例，根据检测到目标应用程序发生崩溃，之前还包括：

在目标应用程序开始进入新的生命周期时，在对应的生命周期信息中设置预设标记；

确定目标应用程序在第一目标生命周期阶段发生崩溃的历史次数，之前还包括：

若确定目标应用程序发生崩溃前的第一预设时长内，系统未发出内存不足告警，则在相应的生命周期信息中记录目标应用程序发送崩溃时所处的生命周期阶段。

作为一种可选的实施例，确定目标应用程序在第一目标生命周期阶段发生崩溃的历史次数，之前还包括：

若确定目标应用程序发生崩溃前的第一预设时长内，系统发出内存不足告警，则在相应的生命周期信息中删除标记。

作为一种可选的实施例，对应的生命周期信息中设置预设标记，之后还包括：

若目标应用程序在生命周期内的第二预设时长内未发生崩溃，则在相应的生命周期信息中删除标记。

作为一种可选的实施例，展示提示界面，之后还包括：

删除所有生命周期信息中设置的预设标记。

根据本申请实施例的另一个方面，提供了一种应用程序崩溃的处理装置，该装置包括：

信息获取模块，用于根据检测到目标应用程序在当前时刻发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；

界面展示模块，用于若确定第一历史次数和第一时差均符合第一展示条件，则展示提示界面，提示界面中包括修复控件；

缓存清除模块，用于响应于触发修复控件，清除目标应用程序的本地缓存。

根据本申请实施例的另一个方面，提供了一种电子设备，该电子设备包括：存储器、处理器及存储在存储器上的计算机程序，处理器执行计算机程序以实现上述方面的应用程序崩溃的处理方法的步骤。

根据本申请实施例的再一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述应用程序崩溃方法的处理方法的步骤。

本申请实施例提供的技术方案带来的有益效果是：

通过检测到目标应用程序发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；若确定历史次数符合第一展示条件，则展示提示界面，本申请的第一展示条件与目标生命周期阶段相关，从而可以区别性地触发展示提示界面，提示界面中包括修复控件；响应于触发修复控件，清除目标应用程序的本地缓存，本申请实施例能够有效识别应用程序发送连续崩溃，并引导用户通过清除缓存修复应用程序，避免连续闪退。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的iOS生命周期的示意图；

图2为本申请实施例提供的实现应用程序崩溃的处理方法的系统架构示意图；

图3为本申请一个实施例提供的应用程序崩溃的处理方法的流程示意图；

图4为本申请一个实施例提供的展示界面的示意图；

图5为本申请另一个实施例提供的展示界面的示意图；

图6为本申请另一个实施例提供的应用程序崩溃的处理方法的流程示意图；

图7为本申请再一个实施例提供的应用程序崩溃的处理方法的流程示意图；

图8为本申请实施例提供的一种应用程序崩溃的处理装置的结构示意图；

图9为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”可以实现为“A”，或者实现为“B”，或者实现为“A和B”。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

首先对本申请涉及的几个名词进行介绍和解释：

1)iOS系统，是一种与安卓(Andriod)系统存在差异的系统，两者最明显的查意要数内存管理机制，iOS系统的内存管理机制会让那些活动较少的程序尽快退出内存，这样就可以载入更多新的程序。也就是说，当开启很多应用时，系统会判断内存是不是够用，如果不够用的话就会自动帮你清理内存，并不会等到很卡顿的时候再去处理。同时那些在后台开启时间较长的应用，iOS系统也有可能自动关闭它。Android系统的内存管理机制可以理解为终端有多少内存就会消耗多少内存，空闲内存也全部都用于缓存。Android系统会把后台开启的每一个程序都保存在内存中，这样会保证下次开启时速度很快，省去再次从存储设备读取的时间。直到内存已经完全被占满，不够启动下一个新程序时，Android才会清理那些之前开启的部分进程。

2)iOS系统的崩溃类型，分为可以通过(kernel)信号量捕获的崩溃以及不可通过信号量捕获的崩溃。可以通过信号量捕获的崩溃包括：应用代码造成的崩溃异常、升级过程中造成的退出、主动终止(kill)应用程序自身的进程、应用程序的进程在后台被kill、因为CPU、mem等资源原因被kill等等；不可通过信号量捕获的崩溃包括：内存打爆、主线程卡死、栈溢出、启动超时、resume超时以及CPU打爆等等。

3)Abort，计算机术语，表示引发不正常进程的终止。

4)iOS生命周期，如图1所示，包括：

未运行Not running，应用程序没启动；

未激活Inactive，应用程序在前台运行，不过没有接收到事件。在没有事件处理情况下应用程序通常停留在这个状态；

激活Active，应用程序在前台运行而且接收到了事件。这也是前台的一个正常的模式；

后台Backgroud，应用程序在后台而且能执行代码，大多数应用程序进入这个状态后会停留一段时间，时间到之后会进入挂起状态；

挂起Suspended，应用程序在后台不能执行代码。系统会自动把应用程序变成这个状态而且不会发出通知。当挂起时，应用程序还是停留在内存中的，当系统内存低时，系统就把挂起的应用程序清除掉，为前台应用程序提供更多的内存。

本申请实施例所指的启动阶段，是指从进入在active状态至首屏渲染完前的阶段，运行阶段是指在active状态下的、首屏渲染完后的阶段。

随着科技的发展，终端设备在人们的生活中有着不可或缺的用处，而每个终端设备中均安装有各种应用程序，在应用程序发生崩溃(crash)时，例如点击进入应用程序出现乱码显示，或者页面错误等，需要对崩溃的应用程序进行修复，以保证应用程序对应的功能的执行。

当应用程序发生连续崩溃时，由于用户无法顺利对补丁进行下载，而应用程序的版本更新需要较长的时间周期，因此无法及时对应用程序进行修复，从而降低了应用程序的修复效率。并且，用户对应用程序连续崩溃的敏感性是很高的，如果没有及时对崩溃做出响应，用户有很大可能卸载应用程序，也就造成了用户的不必要流失。

本申请提供的应用程序崩溃的处理方法、装置、电子设备、计算机可读存储介质以及计算机程序产品，旨在解决现有技术的如上技术问题。

下面通过对几个示例性实施方式的描述，对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。

图2为本申请实施例提供的实现应用程序崩溃的处理方法的系统架构示意图，系统中包括服务器以及终端设备，且应用程序部署于终端设备上。本申请涉及的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、掌上电脑、个人电脑等，但并不局限于此。

具体地，应用程序A部署在终端设备，根据检测到目标应用程序在当前时刻发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；若确定第一历史次数和第一时差均符合第一展示条件，则展示提示界面，提示界面中包括修复控件；响应于触发修复控件，清除目标应用程序的本地缓存。

终端设备和服务器之间可以通过无线网络、有线网络或可移动存储介质进行通信。其中，上述的无线网络使用标准通信技术和/或协议。无线网络通常为互联网(Internet)、但也可以是任何网络，包括但不限于蓝牙、局域网(Local Area Network，LAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、移动、专用网络或者虚拟专用网络的任何组合)。在一些实施例中，可以使用定制或专用数据通信技术取代或者补充上述数据通信技术。可移动存储介质可以为通用串行总线(Universal Serial Bus，USB)闪存盘、移动硬盘或其他可移动存储介质等，本申请在此不做限制。

请参阅图3，图3为本申请实施例的应用程序崩溃的处理方法的一个实施例示意图，如图所示，本申请实施例中应用程序崩溃的处理方法一个实施例包括：

S101、根据检测到目标应用程序发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件。

本申请实施例的崩溃可以包括显示乱码、页面错误、闪退、无响应等崩溃情况。具体的，以应用于终端设备为手机，且系统为iOS系统作为实例进行说明，在应用程序中接入第三方的crash收集工具或者自建crash收集报告平台检测应用程序发生的崩溃，并且记录崩溃报告，也称之为崩溃日志，崩溃日志上有很多有用的信息，包括应用程序是什么情况下崩溃的、在什么时候崩溃的和在什么生命周期阶段崩溃的。本申请实施例的第一目标生命周期阶段可以是启动阶段，也可以是运行阶段。

应当理解的是，当应用程序结束一个生命周期的最后阶段后，就进入了一个新的生命周期的开始阶段，也即应用程序的生命周期是不断演进的，在确定第一目标生命周期阶段后，就可以确定一定时间内产生的所有生命中，确定在第一目标生命周期阶段发生崩溃的目标生命周期，进而统计出目标生命周期的次数，应当理解的是，当应用程序发生崩溃后，意味着当前的生命周期结束，并开始新一轮的生命周期。所以目标生命周期的次数也即目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数。

具体地，本申请实施例可以统计第一历史时段的所有崩溃日志，确定每一次崩溃时目标应用程序所处的生命周期阶段，统计处于第一目标生命周期阶段发生崩溃的崩溃日志的数量，获得该第一历史次数。类似地，本申请还可以统计出最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差，以及与第一目标生命周期阶段对应的第一展示条件。

本申请实施例的第一展示条件可以包括与崩溃次数相关的条件，也可以包括与时差相关的条件，这动态取决于优先针对崩溃次数进行判断，还是优先对时差进行判断，例如，如果优先对崩溃次数进行判断，那么第一展示条件必须包括与崩溃次数相关的条件，但如果确定第一历史次数不符合第一展示条件，也就无需再获得与时差相关的条件。

S102、若确定第一历史次数和第一时差均符合第一展示条件，则展示提示界面，提示界面中包括修复控件。

本申请实施例的第一展示条件随目标生命周期阶段的不同而不同，例如，当目标生命周期阶段为启动阶段时，第一展示条件为历史次数达到1且第一时差小于1小时，当目标生命周期阶段为运行阶段时，第一展示条件为历史次数达到4，且第一时差小于24小时。

本申请实施例若确定该历史次数符合第一展示条件，则展示提示界面，引导用户自助完成应用程序的修复，这样更有利于用户感知到应用程序故障的修复，提高用户的参与感，也可以降低用户对应用程序出现连续崩溃的负面情绪。

作为一种可选实施例，如果确定第一历史次数或者第一时差中的至少一个不符合第一展示条件，那么就不需要展示提示界面，避免提升用户针对崩溃提示的疲劳度。

S103、响应于触发修复控件，清除目标应用程序的本地缓存；

本申请实施例通过前期分析应用程序的异常，发现多数情况下，连续闪退导致的不可用是由于本地缓存了脏数据，因此本申请创新性地将本地连续闪退归因为本地脏数据的产生，并通过引导用户通过触发修复控件清除本地缓存，自助完成应用程序避免连续闪退的动作。

本申请实施例的应用程序崩溃的处理方法，通过检测到目标应用程序发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；若确定历史次数符合第一展示条件，则展示提示界面，本申请的第一历史时段的时长和第一展示条件与目标生命周期阶段相关，从而可以区别性地向用户展示提示界面，提示界面中包括修复控件；响应于触发修复控件，清除目标应用程序的本地缓存，本申请实施例能够有效识别应用程序发送连续崩溃，并引导用户通过清除缓存修复应用程序，避免连续闪退。

在上述各实施例的基础上，作为一种可选实施例，提示界面中包括用于指示目标应用程序出现连续崩溃已被检测的提示信息。

本申请实施例通过告知用户目标应用程序出现连续崩溃已被检测到，为用户提供了心理预期，降低了因为连续闪退而导致的投诉。

请参见图4，图4为本申请实施例的展示界面的一个实施例示意图，如图所示，该展示界面中包括修复控件101和提示信息102，修复控件101上展示了相关提示，告知用户触发该控件后会执行的动作，使用户自己决定是否清理缓存，提示信息则明确地告诉用户“您的App在之前发生了连续闪退导致了严重的不可用”，为用户提供了心理预期。

需要注意的是，图4所示实施例是同时展示了修复控件和提示信息，本申请对于展示修复控件和提示信息的顺序不作具体限定，在一个实施例中，可以先显示提示信息，在提示信息显示一定时长后再显示修复控件。

请参见图5，图5为本申请实施例的展示界面的另一个实施例示意图，如图所示，在目标应用程序发生连续崩溃后，首先在终端的主界面上显示第一弹窗201，第一弹窗201包括提示信息2011和倒计时2012，当倒计时2012归零时，第一弹窗201消失，弹出第二弹窗202，第二弹窗202包括写着“去修复”字样的修复控件2021，当用户点击修复控件2021，第二弹窗202消失，弹出第三弹窗203，第三弹窗203上显示清除缓存的进度条2031，该进度条的变化情况可以根据清除缓存的实际进度进行显示，从而供用户直观地看到缓存清理的进度，为用户提供心理预期。当缓存完成或，第三弹窗上进一步显示“已修复，请重新启动APP”的控件2032，用户通过点击该控件，可直接启动目标应用程序，而无需从应用程序界面中找到目标应用程序再手动启动，在用户点击上述控件后，如果应用程序已正常，则会直接跳转至目标应用程序的首页。

在上述各实施例的基础上，作为一种可选实施例，本申请实施例还包括：

若确定第一历史次数和第一时差中的至少一种不符合第一展示条件，则确定目标应用程序在第二目标生命周期阶段发生崩溃的第二历史次数、最近一次在第二目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第二时差以及与第二目标生命周期阶段对应的第二展示条件；

若确定第二历史次数和第二时差均符合第二展示条件，则展示提示界面，提示界面中包括修复控件；

响应于触发修复控件，清除目标应用程序的本地缓存。

本申请通过设置第一目标生命周期阶段和第二目标生命周期阶段之间的相对优先级，在第一目标生命周期阶段的崩溃信息不符合第一目标生命周期阶段的第一展示条件后，进一步确定目标应用程序在第二目标生命周期阶段发生崩溃的第二历史次数、最近一次在第二目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第二时差以及与第二目标生命周期阶段对应的第二展示条件，如果第二历史次数和第二时差均符合第二展示条件，也会展示提示界面。

考虑到在启动阶段就发生崩溃意味着应用程序完全不可用，因此本申请的启动阶段的优先级高于运行阶段的优先级，也即第一目标生命周期阶段为启动阶段，第二目标生命周期阶段为运行阶段。本申请实施例先判断启动阶段的历史崩溃的情况是否符合展示条件，如果不符合，则继续判断运行阶段的历史崩溃的情况是否符合展示条件。

请参见图6，其示例性地示出了本申请一个实施例的应用程序崩溃的处理方法的流程示意图，如图所示，包括：

S201、根据检测到目标应用程序在当前时刻发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；

S202、判断第一历史次数是否符合第一展示条件(第一历史次数不小于3)，若符合，则执行步骤S203，若不符合，则执行步骤S204；

S203、判断第一时差是否符合第一展示条件(第一时差小于1小时)，若符合，则执行步骤S207，若不符合，则结束流程；

S204、确定目标应用程序在第二目标生命周期阶段发生崩溃的第二历史次数、最近一次在第二目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第二时差以及与第二目标生命周期阶段对应的第二展示条件；

S205、判断第二历史次数是否符合第二展示条件(第二历史次数不小于2)，若符合，则执行步骤S206，若不符合，则结束流程；

S206、判断第二时差是否符合第二展示条件(第二时差小于24小时)，若符合，则执行步骤S207，若不符合，则结束流程；

S207、展示提示界面，提示界面中包括修复控件；

S208、响应于触发修复控件，清除目标应用程序的本地缓存，结束流程。

在上述各实施例的基础上，作为一种可选实施例，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件，之前还包括：

将目标应用程序在当前时刻所处的生命周期阶段，作为第一目标生命周期阶段。

本申请实施例在目标应用程序出现崩溃后，将当前时刻所处的生命周期阶段作为第一目标生命周期阶段，这样就可以结合目标应用程序当前所出现的崩溃，针对性获取历史过程中同样在第一目标生命周期阶段出现的故障的次数和时间，判断是否有必要展示提示界面，用户感知上更加友好。

在上述各实施例的基础上，作为一种可选实施例，确定目标应用程序在第一目标生命周期阶段发生崩溃的历史次数，包括：

S301、获取目标应用程序在第一历史时段内的各生命周期信息。

需要说明的是，本申请实施例可以在目标应用程序开始每一次生命周期时，在相应的生命周期信息内记录该生命周期的开始时刻、结束时刻以及目标应用程序在该生命周期是否出现崩溃等信息。

当一个生命周期的开始时刻在第一历史时段内，则视为该生命周期在第一历史时段内，当然，也可以以生命周期的结束时刻或者中间时刻位于第一历史时段内，则视为该生命周期在第一历史时段内，本申请实施例不作具体的限定。

如果一个生命周期内没有发生崩溃，那么相应的生命周期信息自然也没有用于表征出现崩溃的标记；反之，相应的生命周期信息中记录用于表征出现崩溃的标记以及崩溃时目标应用程序所处的生命周期阶段。

S302、确定各生命周期信息中的目标生命周期信息的数量，将数量作为目标应用程序在第一目标生命周期阶段发生崩溃的历史次数；

本申请实施例的目标生命周期信息包括预设标记且预设标记对应目标生命周期阶段，因此通过统计目标生命周期信息的数量，将数量作为目标应用程序在第一历史时段内的目标生命周期阶段发生崩溃的历史次数。

在上述各实施例的基础上，作为一种可选实施例，根据检测到目标应用程序发生崩溃，之前还包括：

在目标应用程序开始进入新的生命周期时，在对应的生命周期信息中设置预设标记。

也就是说，本申请实施例的目标应用程序每次进入新的生命周期，都会生成对应的生命周期信息，并在生命周期信息中设置标记。具体可以在应用程序的生命周期的启动入口设置标记。

确定目标应用程序在第一历史时段内的目标生命周期阶段发生崩溃的历史次数，之前还包括：

若确定目标应用程序发生崩溃前的第一预设时长内，系统未发出内存不足告警，则在相应的生命周期信息中记录与标记对应的目标生命周期阶段。

需要强调的是，本申请需要解决的场景是线上版本连续发生崩溃导致的不可用，故先要识别出应用程序在运行过程中发生了异常，iOS崩溃可以包括：

1、应用代码造成的崩溃异常；

2、升级过程中造成的退出；

3、主动kill自己；

4、应用在后台被kill；

5、因为CPU、mem等资源原因被kill。

上述5种情况可以通过kernel的信号量捕获到时机，但是对于内存打爆、主线程卡死、栈溢出、启动超时、resume超时以及CPU打爆等情况，是无法通过kernel的信号量捕获的，因此本申请采用了检测内存不足的方法，如果应用程序崩溃时没有检测到内存不足警告，则说明该崩溃不是内存不足导致的，基于此可解决上述几种不能通过信号捕获的问题。

具体地，本申请实施例可以持续检测系统是否发出内存不足警告(MemWarning)，当系统发出内存不足警告时，将内存不足警告写footPrint到预设文件，通过定期检测footPrint判断目标应用程序发生崩溃前的第一预设时长内系统是否发出内存不足告警。

本申请实施例在检测到目标应用程序崩溃后，若确定目标应用程序发生崩溃前的第一预设时长内，系统未发出内存不足告警，可确定本次崩溃不是由于内存不足kill进程导致的，因此可以认为是abort情况的崩溃，在相应的生命周期信息中记录与标记对应的目标生命周期阶段。

在上述各实施例的基础上，作为一种可选实施例，确定目标应用程序在第一目标生命周期阶段发生崩溃的历史次数，之前还包括：

若确定目标应用程序发生崩溃前的第一预设时长内，系统发出内存不足告警，则在相应的生命周期信息中删除标记。

也就是说，当目标应用程序发生崩溃时，如果在此前的第一预设时长内系统发出了内存不足告警，说明该目标应用程序是因为系统内存不足被强行杀进程导致的闪退，并不属于本申请讨论的崩溃的范畴，因此需要在相应的生命周期信息中删除标记。由于删除了标记，因此后续在统计历史出现的崩溃时将忽略掉该生命周期。

在上述各实施例的基础上，作为一种可选实施例，对应的生命周期信息中设置预设标记，之后还包括：

若目标应用程序在生命周期内的第二预设时长内未发生崩溃，则在相应的生命周期信息中删除标记。

需要说明的是，如果目标应用程序在生命周期内的第二预设时长内没有发生崩溃，则认为目标应用程序在该生命周期内是正常运行的，因此也要删掉该标记。通过上述实施例可以发现，只有目标应用程序在生命周期内发生了非内存不足导致的崩溃，相应的生命周期内才会存在标记。

请参见图7，其示例性地示出了本申请另一个实施例的应用程序崩溃的处理方法的流程示意图，如图所示，包括：

一方面，目标应用程序每次进入新的生命周期，则在对应的生命周期信息中设置预设标记；

判断目标应用程序在生命周期内的第二预设时长内是否发生崩溃，若未发生崩溃，则在相应的生命周期信息中删除标记；若发生崩溃，则判断目标应用程序发生崩溃前的第一预设时长内系统是否发出内存不足告警；

若发出内存不足告警，则在相应的生命周期信息中删除标记，若未发出内存不足告警，则在相应的生命周期信息中保留标记；

另一方面，根据检测到目标应用程序发生崩溃，确定目标应用程序发生本次奔溃时所处的目标生命周期阶段；

获取目标应用程序在第一历史时段内的各生命周期信息；

确定各生命周期信息中的目标生命周期信息的数量，将数量作为目标应用程序在第一历史时段内的目标生命周期阶段发生崩溃的历史次数；

若确定历史次数符合第一展示条件，则展示提示界面，提示界面中包括修复控件；

响应于触发修复控件，清除目标应用程序的本地缓存。

在上述各实施例的基础上，作为一种可选实施例，展示提示界面，之后还包括：删除所有生命周期信息中设置的预设标记。

也就是说，每次在展示提示界面后，本申请实施例删除所有生命周期信息中设置的预设标记，那么后续再出现崩溃时，就需要重新对历史的崩溃次数进行计数和标记，这样就相对延长了展示提示界面的周期，降低用户的疲劳度。

本申请实施例提供了一种应用程序崩溃的处理装置，如图8所示，该应用程序崩溃的处理装置可以包括：信息获取模块301、界面展示模块302以及缓存清除模块303，其中，

信息获取模块301，用于根据检测到目标应用程序在当前时刻发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；

界面展示模块302，用于若确定第一历史次数和第一时差均符合第一展示条件，则展示提示界面，提示界面中包括修复控件；

缓存清除模块303，用于响应于触发修复控件，清除目标应用程序的本地缓存。

本申请实施例的装置可执行本申请实施例所提供的方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。

本申请实施例的装置通过检测到目标应用程序发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；若确定历史次数符合第一展示条件，则展示提示界面，本申请的第一展示条件与目标生命周期阶段相关，从而可以区别性地触发展示提示界面，提示界面中包括修复控件；响应于触发修复控件，清除目标应用程序的本地缓存，本申请实施例能够有效识别应用程序发送连续崩溃，并引导用户通过清除缓存修复应用程序，避免连续闪退。

本申请实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行上述计算机程序以实现应用程序崩溃的处理方法的步骤，与相关技术相比可实现：通过检测到目标应用程序发生崩溃，确定目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在第一目标生命周期阶段发生崩溃的崩溃时刻与当前时刻的第一时差以及与第一目标生命周期阶段对应的第一展示条件；若确定历史次数符合第一展示条件，则展示提示界面，本申请的第一展示条件与目标生命周期阶段相关，从而可以区别性地触发展示提示界面，提示界面中包括修复控件；响应于触发修复控件，清除目标应用程序的本地缓存，本申请实施例能够有效识别应用程序发送连续崩溃，并引导用户通过清除缓存修复应用程序，避免连续闪退。

在一个可选实施例中提供了一种电子设备，如图8所示，图8所示的电子设备4000包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。

存储器4003用于存储执行本申请实施例的计算机程序，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序，以实现前述方法实施例所示的步骤。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”、“1”、“2”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除图示或文字描述以外的顺序实施。

应该理解的是，虽然本申请实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。

以上仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。

Claims (10)

1.一种应用程序崩溃的处理方法，其特征在于，包括：

根据检测到目标应用程序在当前时刻发生崩溃，确定所述目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在所述第一目标生命周期阶段发生崩溃的崩溃时刻与所述当前时刻的第一时差以及与所述第一目标生命周期阶段对应的第一展示条件；

若确定所述第一历史次数和所述第一时差均符合所述第一展示条件，则展示提示界面，所述提示界面中包括修复控件；

响应于触发所述修复控件，清除所述目标应用程序的本地缓存。

2.根据权利要求1所述的处理方法，其特征在于，还包括：

若确定所述第一历史次数和所述第一时差中的至少一种不符合所述第一展示条件，则确定所述目标应用程序在第二目标生命周期阶段发生崩溃的第二历史次数、最近一次在所述第二目标生命周期阶段发生崩溃的崩溃时刻与所述当前时刻的第二时差以及与所述第二目标生命周期阶段对应的第二展示条件；

若确定所述第二历史次数和所述第二时差均符合所述第二展示条件，则展示提示界面，所述提示界面中包括修复控件；

响应于触发所述修复控件，清除所述目标应用程序的本地缓存。

3.根据权利要求2所述的处理方法，其特征在于，所述第一目标生命周期阶段为启动阶段，所述第二目标生命周期阶段为运行阶段。

4.根据权利要求1所述的处理方法，其特征在于，所述确定所述目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在所述第一目标生命周期阶段发生崩溃的崩溃时刻与所述当前时刻的第一时差以及与所述第一目标生命周期阶段对应的第一展示条件，之前还包括：

将所述目标应用程序在当前时刻所处的生命周期阶段，作为所述第一目标生命周期阶段。

5.根据权利要求1所述的处理方法，其特征在于，当所述第一目标生命周期阶段为运行阶段时，所述展示所述提示界面，包括：

确定第二历史时段内所述提示界面的展示次数，若所述展示次数未超过预设数值，则展示所述提示界面。

6.根据权利要求1所述的处理方法，其特征在于，所述提示界面中包括用于指示所述目标应用程序出现连续崩溃已被检测的提示信息。

7.根据权利要求1-4任意一项所述的处理方法，其特征在于，确定所述目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数，包括：

获取所述目标应用程序在第一历史时段内的各生命周期信息；

确定各生命周期信息中的目标生命周期信息的数量，将所述数量作为所述目标应用程序在第一目标生命周期阶段发生崩溃的历史次数；

其中，所述目标生命周期信息包括预设标记且所述预设标记对应所述第一目标生命周期阶段。

8.一种应用程序崩溃的处理装置，其特征在于，包括：

信息获取模块，用于根据检测到目标应用程序在当前时刻发生崩溃，确定所述目标应用程序在第一目标生命周期阶段发生崩溃的第一历史次数、最近一次在所述第一目标生命周期阶段发生崩溃的崩溃时刻与所述当前时刻的第一时差以及与所述第一目标生命周期阶段对应的第一展示条件；

界面展示模块，用于若确定所述第一历史次数和所述第一时差均符合所述第一展示条件，则展示提示界面，所述提示界面中包括修复控件；

缓存清除模块，用于响应于触发所述修复控件，清除所述目标应用程序的本地缓存。

9.一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，其特征在于，所述处理器执行所述计算机程序以实现权利要求1-7任一项所述应用程序崩溃的处理方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-7任一项所述的应用程序崩溃方法的处理。

Images