CN116701134A - 一种数据处理方法和电子设备 - Google Patents

Abstract

本申请实施例公开了一种数据处理方法和电子设备，涉及数据处理领域，可以结合前台应用的标记识别，实现对前台应用异常退出的日志获取和存储。具体方案为：电子设备将第一应用程序的预设标识标记为第一值，第一应用程序包括在至少一个应用程序中，第一应用程序是当前运行在前台的应用程序，标记为第一值的预设标识用于指示第一应用程序为前台应用。电子设备在生成退出指令的情况下，确定预设标识为第一值。退出指令包括以下中的至少一项：signal 9，signal 15，exit指令，_exit指令。退出指令用于指示退出第一应用程序。电子设备生成并记录退出指令对应的退出日志文件。

Description

一种数据处理方法和电子设备

技术领域

本申请实施例涉及数据处理领域，尤其涉及一种数据处理方法和电子设备。

背景技术

电子设备通过运行其中的应用程序向用户提供各种不同的功能。在应用程序运行过程中可能会出现异常退出的情况。特别是在前台应用异常退出时，可能会对用户的使用造成较大影响。

基于现有机制无法完整的获取所有异常退出情况下的退出详情。这也就对优化改进应用程序(特别是前台应用)异常退出的工作变得更加困难。

发明内容

本申请实施例提供一种数据处理方法和电子设备，可以结合前台应用的标记识别，实现对前台应用异常退出的日志获取和存储。

为了达到上述目的，本申请实施例采用如下技术方案：

第一方面，提供一种数据处理方法，该方法应用于电子设备中，该电子设备中运行有至少一个应用程序，该方法包括：该电子设备将第一应用程序的预设标识标记为第一值，该第一应用程序包括在该至少一个应用程序中，该第一应用程序是当前运行在前台的应用程序，该标记为第一值的预设标识用于指示该第一应用程序为前台应用。该电子设备在生成退出指令的情况下，确定该预设标识为第一值。该退出指令包括以下中的至少一项：signal 9，signal15，exit指令，_exit指令。该退出指令用于指示退出该第一应用程序。该电子设备生成并记录该退出指令对应的退出日志文件。

这样，通过预设标记来动态记录当前的前台应用，由此筛除后台应用的处理机制。在后续执行过程中，电子设备可以针对异常退出场景下的退出指令进行识别和抓包，由此获取退出指令对应的退出日志文件。可以理解的是，通过对该退出日志文件进行分析，可以获取前台应用退出过程中的详细信息，由此通过针对性优化避免前台应用的异常闪退。

可选的，该预设标识设置在该预设节点中，该预设节点中的信息可以同时被该电子设备在框架层以及该电子设备在内核层读取。由于该预设节点的信息可以被框架层以及内核层读取，因此该预设节点上标识的设置，就可以使得电子设备可以在框架层或者内核层进行前台应用的判断。示例性的，该预设节点可以为die_catch节点。第一值可以为8。

可选的，在该确定该预设标识为第一值之前，该方法还包括：该电子设备判断该退出指令是否与第一接口相关。在另一些实现中，第一接口也可以为用于实现应用退出的类。本示例中，电子设备可以根据退出指令是否与第一接口相关，执行不同的日志获取机制。比如，在退出指令与第一接口相关的情况下，电子设备在框架层即可实现日志的获取。又如，在退出指令与第一接口不相关的情况下，电子设备在内核层即可实现日志的获取。例如，第一接口可以包括Process类。

可选的，该电子设备根据该退出指令，生成抓栈指示，该抓栈指示用于该电子设备在内核层执行抓栈操作。该确定该预设标识为第一值，包括：该电子设备在框架层确定该预设标识为第一值。由此使得电子设备可以在内核层中执行对当前退出过程的抓栈操作。比如，退出指令可以与第一接口不相关。

可选的，该电子设备生成并记录该退出指令对应的退出日志文件，包括：该电子设备在框架层中收集针对该第一应用程序的退出指令的第一日志信息。该第一日志信息包括：携带有当前退出逻辑的调用栈信息。该电子设备在框架层根据该第一日志信息，获取该退出日志文件。

可选的，该第一日志信息还包括以下中的至少一项：第一应用程序的pid，第一应用程序的uid，第一应用程序的包名。

可选的，该第一日志信息为android log。

可选的，该电子设备在框架层调用第二接口，该第二接口可以用于阻止电子设备在内核层生成退出指令对应的日志信息。示例性的，第二接口可以包括disable函数。

可选的，在该电子设备确定该退出指令与第一接口不相关的情况下，该确定该预设标识为第一值，包括：该电子设备在内核层确定该预设标识为第一值。

可选的，该电子设备生成并记录该退出指令对应的退出日志文件，包括：该电子设备在内核层中根据该退出指令进行抓栈获取第二日志信息。该第二日志信息携带有该退出指令的来源方pid以及目的方pid。该电子设备在内核层根据该第二日志信息，获取该退出日志文件。

可选的，该第二日志信息为kernel log。

可选的，在生成并记录该退出指令对应的退出日志文件之后，该方法还包括：将该日志文件上传到云端服务器，以便于该云端服务器存储并分析该退出日志文件。在一些实现中，电子设备生成当前退出指令的退出日志文件后，可以与其他已有逻辑获取的退出日志文件进行筛选、合并、去重等操作，一并上传给云端服务器进行存储分析。

第二方面，提供一种电子设备，该电子设备可以用于实现第一方面及其任一种可能的设计中的电子设备的功能。示例性的，电子设备包括一个或多个处理器和一个或多个存储器；一个或多个存储器与一个或多个处理器耦合，一个或多个存储器存储有计算机指令；当一个或多个处理器执行计算机指令时，使得电子设备执行如上述第一方面及其任一种可能的设计中提供的方法。

第三方面，提供一种芯片系统，芯片系统包括接口电路和处理器；接口电路和处理器通过线路互联；接口电路用于从存储器接收信号，并向处理器发送信号，信号包括存储器中存储的计算机指令；当处理器执行计算机指令时，设置在电子设备中的芯片系统执行如上述第一方面及其任一种可能的设计中提供的方法。

第四方面，提供一种计算机可读存储介质，计算机可读存储介质包括计算机指令，当计算机指令运行时，执行如上述第一方面及其任一种可能的设计中提供的方法。

第五方面，提供一种计算机程序产品，计算机程序产品中包括指令，当计算机程序产品在计算机上运行时，使得计算机可以根据指令执行如上述第一方面及其任一种可能的设计中提供的方法。

应当理解的是，上述第二方面至第五方面提供的技术方案，其技术特征均可对应到第一方面及其可能的设计中提供的方法，因此能够达到的有益效果类似，此处不再赘述。

附图说明

图1为一种应用程序异常退出的分类逻辑示意图；

图2为本申请实施例提供的一种电子设备的软件组成示意图；

图3为本申请实施例提供的一种数据处理方法的模块交互示意图；

图4为本申请实施例提供的一种数据处理方法的流程示意图；

图5为本申请实施例提供的一种电子设备的组成示意图；

图6为本申请实施例提供的一种芯片系统的组成示意图。

具体实施方式

电子设备中可以设置有一个或多个应用程序(Application，APP，简称为应用)。通过该一个或多个应用的运行，使得电子设备为用户提供各项功能。

在应用运行过程中，经常会出现闪退的情况。

示例性的，参考图1，导致应用闪退的原因可以包括应用自行退出以及应用被动退出两方面。

其中，应用自行退出可以是应用在运行过程中，通过电子设备中的退出应用程序相关的接口/类发送退出指令导致的。

应用闪退也可能是由于其他组件发送退出指令导致的，即应用被动退出。例如，电子设备的系统服务(system_server)发送的针对应用的退出指令，导致应用异常闪退。

在一些实现中，上述主动退出或者被动退出中涉及的退出指令可以通过signal系统实现。例如，退出指令可以包括：signal 9，或者signal 15。

其中，signal 9即SIGKILL，用于立即结束程序的运行。signal 15即SIGTERM，对应于程序结束(terminate)信号。

在另一些实现中，上述主动退出或者被动退出中涉及的退出指令可以包括exit指令，或者_exit指令。

可以理解的是，上述基于signal 9/15/exit/_exit的应用闪退并非在用户指示下的正常退出。在以下说明中，该基于signal 9/15/exit/_exit的应用闪退也可以称为应用的异常退出，或者异常闪退。

显而易见的，应用的异常退出是电子设备运行过程中需要避免的。例如，如果运行在前台的应用(简称为前台应用)出现异常退出，会对用户对电子设备的正常使用产生显著的影响。

那么，电子设备可以通过监控上述应用的异常退出，由此在出现异常退出时，获取异常退出时的相关信息。这样，通过分析该异常退出时的相关信息，就能够知晓异常退出的根因，从而使得从根源上避免应用的异常退出成为可能。

本申请实施例提供的技术方案，通过在电子设备中设置异常退出的监控、信息抓取等机制，实现对应用(如前台应用)异常退出的监控以及信息获取。

以下将结合附图对本申请实施例提供的技术方案进行详细说明。

需要指出的是，本申请实施例提供的技术方案可以应用于电子设备中。该电子设备中可以设置有至少一个应用程序。示例性的，该电子设备可以包括手机、可折叠电子设备、平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、蜂窝电话、个人数字助理(personaldigital assistant，PDA)、增强现实(augmented reality，AR)设备、虚拟现实(virtualreality，VR)设备、人工智能(artificial intelligence,AI)设备、可穿戴式设备、车载设备、智能家居设备、或智慧城市设备中的至少一种。本申请实施例对该电子设备的具体类型不作特殊限制。

在不同实现中，本申请实施例涉及的电子设备可以具有不同的组成。

示例性的，从硬件组成的角度，本申请实施例涉及的电子设备可以包括：处理器，外部存储器接口，内部存储器，通用串行总线(universal serial bus，USB)接头，充电管理模块，电源管理模块，电池，天线1，天线2，移动通信模块，无线通信模块，音频模块，扬声器，受话器，麦克风，耳机接口，传感器模块，按键，马达，指示器，摄像头，显示屏，以及用户标识模块(subscriber identification module，SIM)卡接口等。其中传感器模块可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备的具体限定。在本申请另一些实施例中，电子设备可以包括比上述示例说明的更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。

在另一些实施例中，本申请实施例还提供一种电子设备的软件组成。

在本示例中，电子设备中可以包括软件系统。该软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。以下说明中，以该软件系统包括具有分层架构的安卓系统为例。请参考图2，为本申请实施例提供的一种电子设备的软件组成示意图。

在如图2的示例中，该电子设备的分层架构可以将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，电子设备中运行的系统可以分为五层。从上至下分别为应用程序层(简称为应用层)，应用程序框架层(Framework层，简称为框架层)，以及内核层(kernel)。在本申请的另一些实施例中，在框架层以及内核层之间还可以设置有安卓运行时(Android runtime，ART)和原生C/C++库、硬件抽象层(Hardware Abstract Layer，HAL)等。

应用层可以包括一系列应用程序包。例如，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。基于不同应用的来源，应用层中运行的应用可以包括电子设备的系统应用，以及三方应用。

通过本申请实施例提供的技术方案，能够有效地监控应用层中的应用(如三方应用)运行过程中的异常退出，并获取异常退出的相关信息进行保存，以便于后续对该异常退出的原因的分析。

框架层可以为应用层的应用程序提供应用编程接口(application programminginterface，API)和编程框架。框架层中可以包括一些预先定义的函数。

示例性的，框架层可以包括窗口管理器，内容提供器，视图系统，资源管理器，通知管理器,活动管理器，输入管理器等。

窗口管理器提供窗口管理服务(Window Manager Service，WMS),WMS可以用于窗口管理、窗口动画管理、surface管理以及作为输入系统的中转站。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。该数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。输入管理器可以提供输入管理服务(Input Manager Service，IMS)，IMS可以用于管理系统的输入，例如触摸屏输入、按键输入、传感器输入等。IMS从输入设备节点取出事件，通过和WMS的交互，将事件分配至合适的窗口。

活动管理器可以提供活动管理服务(Activity Manager Service，AMS)，AMS可以用于系统组件(例如活动、服务、内容提供者、广播接收器)的启动、切换、调度以及应用进程的管理和调度工作。

如图2所示，在本示例中，框架层中还可以设置有应用检测模块、应用信息跟踪模块(简称为信息跟踪模块)，以及日志处理模块。

其中，应用检测模块，可以用于进行前台应用的标识以及对应退出指令的监听。

示例性的，该应用检测模块可以用于确定运行中的应用程序为前台应用或后台应用。应用检测模块还可以用于检测以正在运行过程中的应用程序为目标应用的退出指令。例如，该退出指令可以包括异常退出对应的指令，如signal 9/15/exit/_exit。应用检测模块还可以用于在该退出指令为基于第一接口的退出指令时，获取退出指令指向的目标应用的退出信息。在另一些实施例中，应用检测模块还可以用于在退出指令并非基于第一接口时，向内核层转发退出指令，以便于在内核层中，获取应用程序闪退的退出信息。其中，第一接口可以对应到退出应用程序相关的接口/类。例如，第一接口可以包括Process类。

信息跟踪模块，可以用于从AMS获取应用闪退的详情信息，如称为退出信息。

日志处理模块，可以用于根据退出信息，生成对应的日志进行存储。其中，在异常退出的退出信息是基于第一接口的情况下，该退出信息可以是由应用检测模块发送给日志处理模块的。在异常退出的退出信息并非基于第一接口的情况下，该退出信息可以是在内核层生成并发送的。在一些实施例中，日志处理模块在生成退出日志后，可以存储在电子设备本地(如电子设备的存储器)中的固定位置，以便于后续读取。在另一些实施例中，日志处理模块在生成退出日志后，可以将该退出日志发送给云端服务器，以便于云端服务器对来自一个或多个电子设备的退出日志进行分析处理。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

在本申请实施例中，内核层中还可以设置有信息采集模块。该信息采集模块可以用于支持内核层中相关逻辑的实现。例如，有应用异常退出时，该信息采集模块可以采集该异常退出对应的退出信息。在一些实施例中，该退出系信息可以被发送给日志处理模块，以便日志处理模块对退出信息进行系统性处理。

如前述示例，在另一些实施例中，如图2所示的电子设备中还可以包括安卓运行时、原生C/C++库、硬件抽象层等。

安卓运行时包括核心库和安卓运行时。安卓运行时负责将源代码转换为机器码。安卓运行时主要包括采用提前(ahead or time，AOT)编译技术和及时(just in time，JIT)编译技术。核心库主要用于提供基本的Java类库的功能，例如基础数据结构、数学、IO、工具、数据库、网络等库。核心库为用户进行安卓应用开发提供了API。

原生C/C++库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体框架(Media Framework)，libc，OpenGL ES、SQLite、Webkit等。

其中，表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体框架支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。OpenGL ES提供应用程序中2D图形和3D图形的绘制和操作。SQLite为电子设备100的应用程序提供轻量级关系型数据库。

硬件抽象层运行于用户空间(user space)，对内核层驱动进行封装，向上层提供调用接口。

本申请实施例提供的技术方案均可以应用于前述电子设备中。以下示例中，将结合图2的电子设备的软件构成，对本申请实施例提供的数据处理方法进行详细说明。

示例性的，请参考图3，为本申请实施例提供的一种数据处理方法的模块间交互示意图。如图3所示，该方案可以包括：

S301、在电子设备开机后，活动管理器启动。

在电子设备开机上电后，系统中的原生(native)进程zygote进程被拉起。此后，zygote进程可以对应拉起其他支持电子设备正常运行的进程。例如，zygote进程可以拉起AMS对应进程，也即实现AMS的启动。

S302、活动管理器向应用检测模块发送运行指令。

S303、应用检测模块根据运行指令进行初始化。

在本示例中，AMS被配置为启动后自动拉起应用检测模块。示例性的，AMS可以在启动后发送运行指令，以便于应用检测模块开始运行，即执行应用检测模块的初始化操作。

在初始化完成后，应用检测模块可以开始执行监听。该监听功能可以用于监听应用程序在前后台的切换，以及针对应用程序的退出指令。

示例性的，应用检测模块可以通过注册系统服务中的进程变更相关接口(如AMS的regi sterProcessObserver接口)，实现上述监听功能。在另一些实施例中，该监听功能还可以通过调用生命周期变更接口，窗口切换接口等接口实现。

需要说明的是，在本申请的一些实施例中，还可以结合handler机制实现本申请所涉及方案的实现。例如，应用检测模块可以在执行初始化之后，绑定handler到原生机制中的拥有独立handler的线程。如将handler绑定到android.bg。这样可以便于后续与AMS交互过程中的异步实现。

S304、应用检测模块对运行中的应用进行标识。

其中，每个运行中的应用可以对应设置有一个用于标识该应用是否为前台应用的标识。在一些实施例中，该标识可以设置在节点中。该节点可以用于进行用户空间和内核空间的数据传递。也即，该节点上设置的信息可以同时被用户空间以及内核空间查看。

在本示例中，基于前述S303中的说明，应用检测模块可以具有监听应用程序在前后台的切换的能力。

以运行中的应用包括应用1和应用2为例。在应用1被切换到前台时，则应用检测模块可以监听到该应用1被切换到前台，那么应用检测模块就可以将该应用1的标识设置为第一值，用于标示该应用1被切换到前台。即，该标识为第一值的应用1为当前的前台应用。

对应的，在应用2被切换到前台时，则应用检测模块可以监听到该应用2被切换到前台，那么应用检测模块就可以将该应用2的标识设置为第一值，用于标示该应用2被切换到前台。即，该标识为第一值的应用2为当前的前台应用。

可以理解的是，在一些实现中，在应用2被切换到前台的情况下，应用1被切换到后台运行。那么，在将应用2的标识设置为第一值的同时，应用检测模块还可以将应用2的标识设置为第二值，以便标识该应用2为后台应用。

作为一种可能的实现，应用检测模块可以监听前后台变更的事件回调。应用检测模块可以根据flag更新前后台的列表<pid,uid>。基于该更新的前后台<pid,uid>，应用检测模块可以执行对应前台和/或后台应用的标识设置。比如，该用于标示应用是否为前台应用的标识可以设置在die_catch节点中。第一值可以为8，第二值可以为0。也即，对于切换到前台运行的应用，应用检测模块将该前提应用的die_catch节点中的标识设置为8。对于切换到后台运行的应用，应用检测模块将该前提应用的die_catch节点中的标识设置为0。

结合S303中的说明，在将handler绑定在android.bg的情况下，在该步骤S304中，应用检测模块识别到应用的前后台变更时，也可以将该变更消息关联到android.bg的handler进行处理。

S305、应用检测模块监控退出指令。

其中，该退出指令可以包括异常退出对应的指令，如signal 9/15/exit/_exit。

在监控到前台应用的退出指令后，应用检测模块就可以根据该退出指令与第一接口的关系，进行后续的退出信息的获取操作。

S306、在监听到退出指令的情况下，应用检测模块判断退出指令是否基于第一接口。

可以理解的是，退出指令可以包括基于第一接口的退出指令，以及非第一接口的退出指令。示例性的，为了确定退出指令与第一接口的关系，应用检测模块可以在AMS中注册与第一接口相关的事件回调。对应的，在退出指令是基于第一接口时，则应用检测模块可以对应监听到与第一接口相关的事件回调的回调通知。也即，在监听到退出指令，以及该退出指令对应的与第一接口相关的事件回调的回调通知的情况下，则应用检测模块可以确定该退出信息为基于第一接口的。反之，在仅监听到退出指令的情况下，则应用检测模块可以确定该退出指令为非第一接口的退出执行令。

在本示例中，对于基于第一接口的退出指令，电子设备可以在框架层执行对应的退出信息的获取。如执行如下S307-S309。

S307、应用检测模块确定退出指令指向的目标应用为前台应用。

其中，目标应用的标识可以包括以下中的至少一种：进程ID(pid)，用户ID(uid)标识，包名(package name)。以下以通过pid和uid标识目标应用为例。

如S305中的说明，对于第一接口的退出指令，应用检测模块可以通过在AMS中注册与第一接口相关的事件回调，获取退出指令指向的目标应用的pid以及uid。

那么，应用检测模块可以识别确定该pid以及uid对应的目标应用的标识是否为第一值，由此判断该目标应用是否为前台应用。

例如，应用检测模块可以识别该目标应用在die_catch节点中的标识为8，对应于确定该目标应用为前台应用。

在本申请的一些实施例中，在应用检测模块确定当前指令为第一接口的退出指令时，可以调用disable函数，用于屏蔽在kernel中再次抓取调用栈的逻辑。

S308、应用检测模块通过信息跟踪模块获取目标应用的第一日志信息。

示例性的，如图3所示，应用检测模块可以向信息跟踪模块发送目标应用信息。其中，目标应用信息可以包括目标应用的pid以及uid。

对应的，信息跟踪模块可以从AMS获取该目标应用相对应的第一日志信息。

作为一种示例，应用检测模块可以通过信息跟踪模块，获取目标应用在退出过程中的ex it info。例如，可以将该exit info打印到android log。由此使得在该androidlog中可以携带有当前退出逻辑的调用栈信息。在本示例中，该携带有当前退出逻辑的调用栈信息的android log可以称为第一日志信息。在本申请的另一些实施例中，该第一日志信息中还可以包括目标应用的应用信息，如目标应用的pid、uid以及package name等。

在另一些实施例中，应用检测模块可以在第一日志信息时，生成对应的故障编码，将故障事件上报给日志处理模块。以便于日志处理模块可以根据接收到的故障编码，知晓当前故障的类型。

S309、应用检测模块将第一日志信息发送给日志处理模块。在一些实施例中，在S309之后可以跳转执行S314。由此便于日志处理模块根据日志信息，获取相应的退出日志文件。

作为一种示例，在获取第一日志信息之后，将第一日志信息发送给日志处理模块。

应当理解的是，上述示例中，通过S307-S309的说明，对应用检测模块在确定当前退出指令为第一接口的情况下，退出日志的获取方式进行了说明。在另一些实施例中，应用检测模块还可以在确定退出指令为第一接口的情况下，控制第一接口中生成该退出指令的日志信息。应用检测模块还可以根据退出指令，设置目标应用的AppExitInfo，并将退出信息补充到AppExitInfo的描述(description)中。这样，日志处理模块可以通过读取目标应用的AppExitInfo，获取目标应用对应的第一日志信息。

需要说明的是，在本申请的另一些实施例中，在执行上述S309之前，应用检测模块还可以确定退出指令来自系统服务。可以理解的是，考虑到数据的安全性，在退出指令来自于系统服务之外的其他服务(如三方服务)时，则对应的抓栈动作可以退回到内核中执行。示例性的，在应用检测模块确定退出指令来自系统服务时，则可以执行S309。作为一种可能的实现，应用检测模块还可以在确定退出指令来自系统服务的情况下，执行对ApplicationExitI nfo的更新。

对应的，在应用检测模块确定退出指令并非来自系统服务时，则可将流程流转到内核中继续执行。例如，执行以下S311。

S310、应用检测模块向内核层的信息采集模块发送退出指令。

如图3的示例，在本申请的一些实施例中，应用检测模块可以在监听到退出指令之后，生成对应的抓栈指示，将抓栈指示发送给内核层(如信息采集模块)，以便于在内核层中执行对应的抓栈操作。

示例性的，该抓栈指示可以用于指示对目标应用进行退出操作。在一些实现中，该抓栈指示可以携带有目标应用的信息，如目标应用的pid以及uid等。

S311、信息采集模块确定退出指令指向的目标应用为前台应用。

结合S307中的描述，在本示例中，信息采集模块可以根据目标应用的pid以及uid，查询对应的die_catch节点中的标识是否为第一值(如8)。

若该目标应用的标识为8，则确定该目标应用为前台应用。当前对该目标应用的异常退出需要按照以下S312的逻辑执行退出信息的获取。

S312、信息采集模块根据退出指令进行抓栈获取第二日志信息。

示例性的，信息采集模块可以根据抓栈指示，对当前对目标应用的退出过程进行抓栈处理，由此获取第二日志信息。作为一种可能的实现，该第二日志信息可以包括kernellog。在该第二日志信息中可以携带有退出指令的来源方pid以及目的方pid。

此外，在退出指令包括exit/_exit指令的情况下，内核层可以判断die_catch节点的标识是否为第一值(如第一值可以为8)，然后基于判断结果，如确定die_catch节点的标识为第一值，则补充发送signal抓栈信号。在一些实现中，为防止发送signal抓栈信号后电子设备即进入do_group_exit的逻辑，该对signal抓栈信号可以在适当的延时后进行发送。

S313、信息采集模块向日志处理模块发送第二日志信息。

S314、日志处理模块生成目标应用的退出日志文件。

示例性的，日志处理模块可以根据第一日志信息，或者第二日志信息，生成此次目标应用的退出日志文件。例如，日志处理模块可以根据特定目录下的xml文件，生成退出日志文件。

可以理解的是，在一些现有的方案中，电子设备中的安卓操作系统能够提供signal 6/11的抓栈处理机制。该signal 6/11的退出机制可以为应用的正常退出。对应的，本申请实施例应对的则是针对退出指令包括signal 9/15/exit/_exit的异常退出场景。

在本申请实施例提供的方案的一些实现中，可以结合现有的针对signal 6/11的抓栈方案，实现不同场景下退出日志文件的获取。

上述图3的说明中，通过各个模块之间的交互对本申请实施例提供的数据处理方法进行了详细说明。其中，确定退出指令是否针对前台应用的判断(如S301以及S311)可以是在确定退出指令与第一接口的关系(如S306)后，分别在框架层以及内核层执行的。在另一些实现中，电子设备也可以在框架层由应用检测模块判断该退出指令是针对前台应用后，在确定退出指令与第一接口的关系。由此可以使得电子设备中的内核层不需要再判断退出指令是针对前台应用的。以下将从电子设备的角度，继续对本申请实施例提供的数据处理方法的具体执行过程进行示例性说明。

请参考图4，为本申请实施例提供的一种数据处理方法的流程示意图。该方案可以应用于电子设备中，由此使得电子设备可以通过执行该数据处理方法，监听并获取设置在前台的应用程序(如三方应用)在异常退出时的退出日志文件。结合图3，如图4所示，该方案可以包括：

S401、电子设备上电运行。

示例性的，电子设备可以在上电后，运行AMS以及AMS中的应用检测模块对应的进程/线程。该应用检测模块具有监测、标识前台应用，以及确定退出指令是否为第一接口指令等功能。

S402、在电子设备中运行有至少一个应用程序的情况下，电子设备确定并标记第一应用。其中，第一应用为当前电子设备中运行的前台应用。

示例性的，应用检测模块可以将前台应用(如第一应用)的die_catch节点中的标识设置为第一值(如8)，用于指示该第一应用为前台应用。

S403、在生成针对三方应用的退出指令后，电子设备在框架层生成抓栈指示。

在本示例中，电子设备可以在框架层生成与退出指令相对应的抓栈指示，根据该抓栈指示，使得电子设备可以在内核层中执行当前退出过程的抓栈操作。

接着，电子设备可以根据退出指令，在框架层中执行与第一接口相关的退出指令的抓栈操作。如执行S404-S407。此外，电子设备还可以根据抓栈指示，在内核层中执行与退出指令相关的抓栈操作。其中，在退出指令与第一接口不相关的情况下，则可以按照如S408-S410的流程执行对应的抓栈操作。

S404、电子设备在框架层确定该退出指令为第一接口指令。

其中，退出指令包括异常场景下的退出指令。示例性的，退出指令可以包括signal9/15/exit/_exit。

第一接口的退出指令包括：通过第一接口下发的退出指令。对应的，非第一接口的退出指令则包括未通过第一接口下发的退出指令。

在退出指令为第一接口指令的情况下，电子设备在框架层中对该指令对应的退出过程进行日志获取和记录。比如，继续执行以下S404-S406。

S405、电子设备在框架层判断退出指令指向的第一应用为前台应用。

示例性的，电子设备可以根据第一应用相应的die_catch节点中的标识设置为第一值(如8)，确定第一应用为前台应用。

S406、电子设备在框架层中收集针对第一应用的退出指令的第一日志信息。

示例性的，该第一日志信息可以是在第一接口中生成的。该第一日志信息可以包括携带有当前退出逻辑的调用栈信息的android log，以及第一应用的应用信息。其中，第一应用的应用信息可以包括以下中的至少一项：pid，uid，package name。

S407、电子设备根据第一日志信息，获取第一应用异常退出对应的退出日志文件。

S408、电子设备在内核层判断抓栈指示指向的第一应用为前台应用。

示例性的，该过程可以参考上述S404以及图3中的S311中的说明，此处不再赘述。

S409、电子设备在内核层根据抓栈指示进行抓栈获取第二日志信息。

示例性的，第二日志信息可以包括kernel log。在该第二日志信息中可以携带有退出指令的来源方pid以及目的方pid。

S410、电子设备根据第二日志信息，获取第一应用异常退出对应的退出日志文件。

这样，电子设备就可以针对前台应用的异常闪退，获取对应的退出日志文件，由此支持该前台应用闪退的修复等后续优化处理。

上述分别从电子设备以及电子设备中各个模块间交互的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对其中涉及的设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

请参考图5，为本申请实施例提供的又一种电子设备的组成示意图。如图5所示，该电子设备500可以包括：处理器501和存储器502。该存储器502用于存储计算机执行指令。示例性的，在一些实施例中，当该处理器501执行该存储器502存储的指令时，可以使得该电子设备500执行上述实施例中涉及的电子设备的任一种所示的方法。

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

图6示出了的一种芯片系统600的组成示意图。该芯片系统600可以包括：处理器601和通信接口602，用于支持相关设备实现上述实施例中所涉及的功能。在一种可能的设计中，芯片系统还包括存储器，用于保存终端必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。需要说明的是，在本申请的一些实现方式中，该通信接口602也可称为接口电路。

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

在上述实施例中的功能或动作或操作或步骤等，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包括一个或多个可以用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

尽管结合具体特征及其实施例对本申请进行了描述，显而易见的，在不脱离本申请的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明，且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包括这些改动和变型在内。

Claims (13)

1.一种数据处理方法，其特征在于，所述方法应用于电子设备中，所述电子设备中运行有至少一个应用程序，所述方法包括：

所述电子设备将第一应用程序的预设标识标记为第一值，所述第一应用程序包括在所述至少一个应用程序中，所述第一应用程序是当前运行在前台的应用程序，所述标记为第一值的预设标识用于指示所述第一应用程序为前台应用；

所述电子设备在生成退出指令的情况下，确定所述预设标识为第一值；所述退出指令包括以下中的至少一项：signal 9，signal 15，exit指令，_exit指令；所述退出指令用于指示退出所述第一应用程序；

所述电子设备生成并记录所述退出指令对应的退出日志文件。

2.根据权利要求1所述的方法，其特征在于，所述预设标识设置在所述预设节点中，所述预设节点中的信息可以同时被所述电子设备在框架层以及所述电子设备在内核层读取。

3.根据权利要求1或2所述的方法，其特征在于，

在所述确定所述预设标识为第一值之前，所述方法还包括：

所述电子设备判断所述退出指令是否与第一接口相关，所述第一接口用于执行退出应用程序的操作。

4.根据权利要求3所述的方法，其特征在于，在所述电子设备确定所述退出指令与第一接口相关的情况下，所述确定所述预设标识为第一值，包括：

所述电子设备在框架层确定所述预设标识为第一值。

5.根据权利要求4所述的方法，其特征在于，所述电子设备生成并记录所述退出指令对应的退出日志文件，包括：

所述电子设备在框架层中收集针对所述第一应用程序的退出指令的第一日志信息；所述第一日志信息包括：携带有当前退出逻辑的调用栈信息；

所述电子设备在框架层根据所述第一日志信息，获取所述退出日志文件。

6.根据权利要求5所述的方法，其特征在于，所述第一日志信息还包括以下中的至少一项：第一应用程序的pid，第一应用程序的uid，第一应用程序的包名。

7.根据权利要求5或6所述的方法，其特征在于，所述第一日志信息为android log。

8.根据权利要求4-7中任一项所述的方法，其特征在于，所述电子设备在框架层调用第二接口，所述第二接口用于阻止所述电子设备在内核层生成所述退出指令对应的日志信息。

9.根据权利要求3-8中任一项所述的方法，其特征在于，所述方法还包括：所述电子设备根据所述退出指令，生成抓栈指示，所述抓栈指示用于所述电子设备在内核层执行抓栈操作；

所述确定所述预设标识为第一值，包括：

所述电子设备在内核层确定所述预设标识为第一值。

10.根据权利要求9所述的方法，其特征在于，所述电子设备生成并记录所述退出指令对应的退出日志文件，包括：

所述电子设备在内核层中根据所述退出指令进行抓栈获取第二日志信息；所述第二日志信息携带有所述退出指令的来源方pid以及目的方pid；

所述电子设备在内核层根据所述第二日志信息，获取所述退出日志文件。

11.根据权利要求10所述的方法，其特征在于，所述第二日志信息为kernel log。

12.根据权利要求1-11中任一项所述的方法，其特征在于，在生成并记录所述退出指令对应的退出日志文件之后，所述方法还包括：

将所述日志文件上传到云端服务器，以便于所述云端服务器存储并分析所述退出日志文件。

13.一种电子设备，其特征在于，所述电子设备包括一个或多个处理器和一个或多个存储器；所述一个或多个存储器与所述一个或多个处理器耦合，所述一个或多个存储器存储有计算机指令；当所述一个或多个处理器执行所述计算机指令时，使得所述电子设备执行如权利要求1-12中任一项所述的方法。