CN114880159B - 数据处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开一种数据处理方法、装置、设备及存储介质，方法包括：获取目标应用的多种无响应现象中的各种无响应现象的现场信息，任一种无响应现象是在基于操作系统的系统代码运行目标应用的过程中产生的；现场信息用于描述在产生相应的无响应现象时系统代码的执行情况；对各种无响应现象的现场信息进行共性分析，得到共性分析结果，并根据共性分析结果从系统代码中确定产生无响应现象的故障点；根据故障点对系统代码进行修复处理，以基于修复后的系统代码运行目标应用。本申请可由云服务器执行，能够从操作系统层面有效解决目标应用的无响应现象，降低发生任一种无响应现象的概率，通用性强，可提高整体稳定性。

Description

数据处理方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据处理方法、装置、设备及存储介质。

背景技术

随着计算机技术的发展，一些操作系统的开源性得以让操作系统被二次开发、定制，操作系统所提供的越来越多有趣且实用的功能不断的给人们带来便捷的体验。

在操作系统上支持各种应用程序的运行，但是如果应用程序响应不够灵敏时，可能会发生ANR（Application Not Responding，应用无响应）的现象，这种ANR现象的存在会影响使用体验。然而目前解决ANR的方案大多是基于他人的分析经验来定位自己所遇到的ANR问题，针对具体ANR的问题进行具体分析，这样受限于操作系统版本、应用程序版本等具体的场景，并不一定就能保证解决本次ANR之后不因为其他原因再次发生ANR，通用性不强。

发明内容

本申请实施例提供一种数据处理方法、装置、设备及存储介质，能够从操作系统层面有效解决目标应用的无响应现象，降低发生任一种无响应现象的概率，通用性强，可提高整体稳定性。

一方面，本申请实施例提供了一种数据处理方法，包括：

获取目标应用的多种无响应现象中的各种无响应现象的现场信息，任一种无响应现象是在基于操作系统的系统代码运行目标应用的过程中产生的；且任一种无响应现象的现场信息用于描述：在产生相应的无响应现象时，系统代码的执行情况；

对各种无响应现象的现场信息进行共性分析，得到共性分析结果，并根据共性分析结果从系统代码中确定产生无响应现象的故障点；其中，所述共性分析结果包括：所述各种无响应现象的现场信息中的共有信息；

根据故障点对系统代码进行修复处理，以基于修复后的系统代码运行目标应用。

一方面，本申请实施例提供了一种数据处理装置，包括：

获取模块，用于获取目标应用的多种无响应现象中的各种无响应现象的现场信息，任一种无响应现象是在基于操作系统的系统代码运行目标应用的过程中产生的；且任一种无响应现象的现场信息用于描述：在产生相应的无响应现象时，系统代码的执行情况；

处理模块，用于对各种无响应现象的现场信息进行共性分析，得到共性分析结果，并根据共性分析结果从系统代码中确定产生无响应现象的故障点；其中，所述共性分析结果包括：所述各种无响应现象的现场信息中的共有信息；

处理模块，用于根据故障点对系统代码进行修复处理，以基于修复后的系统代码运行目标应用。

相应地，本申请实施例提供了一种计算机设备，包括：处理器、存储器以及网络接口；处理器与存储器、网络接口相连，其中，网络接口用于提供网络通信功能，存储器用于存储程序代码，处理器用于调用程序代码，以执行本申请实施例中数据处理方法。

相应地，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序包括程序指令，程序指令当被处理器执行时，执行本申请实施例中数据处理方法。

相应地，本申请实施例提供了一种计算机程序产品，计算机程序产品包括计算机程序或计算机指令，计算机程序或计算机指令被处理器执行时实现本申请实施例的数据处理方法。

在本申请实施例中，可获取到目标应用的多种无响应现象的现场信息，任一种无响应现象可在基于操作系统的系统代码运行目标应用的过程中产生的，且对应的现场信息可用于描述产生该无响应现象时系统代码的执行情况。通过对获取到的各种无响应现象的现场信息进行共性分析，可以从操作系统层面对系统代码的执行情况进行分析，从底层寻找目标应用产生各种无响应现象的共同特性，得到共性分析结果，进而基于该共性分析结果可以从系统代码中确定出产生无响应现象的故障点，并基于故障点对系统代码进行修复，基于修复后的系统代码运行目标应用可以从操作系统侧对应用无响应现象（即目标应用的无响应现象）可能发生的情况进行拦截，尽可能地避免应用无响应现象的发生。可见，此种方式是从操作系统层面着手，对实际发生的各种无响应现象的现场信息进行收集、共性分析，并基于分析得到的结果对原生的操作系统的系统代码进行修复，可以根本上解决操作系统上应用无响应现象的问题，通用性强，能够减少在操作系统上目标应用发生任一种无响应现象的情况，从而有效提高系统或应用的稳定性。

附图说明

图1a是本申请实施例提供的一种应用无响应的分类示意图；

图1b是本申请实施例提供的一种触发应用无响应现象的过程示意图；

图1c是本申请实施例提供的一种启动服务的流程示意图；

图1d是本申请实施例提供的一种服务类型的无响应现象的产生过程示意图；

图1e是本申请实施例提供的一种广播类型的无响应现象的产生过程示意图；

图1f是本申请实施例提供的一种内容提供类型的无响应现象的产生过程示意图；

图1g是本申请实施例提供的一种输入分发类型的无响应现象的产生过程示意图；

图2a是本申请实施例提供的一种云游戏系统的架构图；

图2b是本申请实施例提供的一种云游戏中无响应现象的提示示意图；

图2c是本申请实施例提供的一种云游戏场景下服务器中系统的底层交互逻辑示意图；

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

图3b是本申请实施例提供的一种云游戏场景下产生的无响应现象的现场信息的示意图；

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

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

图6a是本申请实施例提供的一种父进程调用栈的结果示意图；

图6b是本申请实施例提供的一种目标函数的逻辑代码的示意图；

图7是本申请实施例提供的一种数据处理装置的结构示意图；

图8是本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

为了更好地理解本申请实施例的方案，下面先对本申请实施例可能涉及的相关术语和概念进行介绍。

操作系统：英文全称Operating System，简称OS。操作系统是管理计算机硬件和软件资源的计算机程序。是计算机系统中最基本的系统软件。操作系统具备处理机管理（例如进程控制、进程同步）、存储器管理（例如内存分配与回收、地址映射）、设备管理（例如文件存储空间管理、文件读写管理）和文件管理（例如缓冲管理、虚拟设备）等功能。操作系统种类很多，比如常见的Android（或称为Android系统）、Linux、Windows、IOS等等。

内核：内核是操作系统的核心。内核可以将输入的命令转换成计算机硬件能够理解的机器语言，且内核直接和硬件联系，并可以告知硬件应用程序发起的请求。内核的功能包括但不限于：进程管理、任务调度、内存管理，等等。其中，文件管理是指内核使用文件系统来组织文件，并通过文件系统保持对文件数据存储、文件状态、访问设置的监测；进程管理是指在多进程环境下，内核决定哪一道进程被CPU（Central Processing Unit，中央处理器）优先运行，以及分配的运行时间片长度是多少；内存管理是指内核可以检测内存空间，生成或销毁内存，以确保应用程序被正确执行。

硬编码：是指将数据直接嵌入到程序或者其他可执行对象的源代码中的应用开发实践。与从外部获取数据或在运行时生成数据不同，硬编码通常只能通过编辑源代码和重新编译可执行文件来修改。在计算机程序或文本编辑中，硬编码是指将可变变量用一个固定值来代替的方法。

ANR：英文全称为Application Not Responding，中文为应用无响应（可简称无响应）。ANR是在操作系统（例如Android系统）中十分常见的现象，对于开发者来说可能是代码上的bug（错误），但是对于使用者来说，可能会造成不好的使用体验。操作系统对于一些事件需要在一定时间内完成，如果超过预定时间未能得到有效响应或者响应时间过长，都会造成ANR。一般来说，系统界面会弹出一个提示框，告知对象当前应用未响应，对象可以选择继续等待（Wait）或者强制关闭（Force close），是操作系统的一种自我保护机制。此外，也可以在发生应用无响应时直接关闭发生应用无响应的进程而不弹出提示框以提示对象。

目标应用：本申请中目标应用是指计算机设备中运行的任一应用，例如终端中的应用程序或者是服务器中的服务程序。按照应用的安装方式划分，目标应用可以是免安装应用（例如小程序、网页应用（如购物网站）），或者是安装于计算机设备中的第三方应用程序；按照应用功能划分，目标应用具体可以是游戏类应用、音视频类应用、社交类应用、购物类应用等等中的任一种。

目标应用可以基于操作系统所提供的环境运行，在基于操作系统的系统代码运行目标应用的过程中，目标应用可能会发生无响应的情况（即ANR）。在本申请实施例中，目标应用产生的ANR可包括如下几类：服务类型的无响应现象、广播类型的无响应现象、内容提供类型的无响应现象、输入事件分发类型的无响应现象。以Android操作系统为例，服务类型的无响应现象是指服务在预定时长（例如20s）内未执行完成（Service Timeout）而触发的无响应现象；广播类型的无响应现象是指广播在预定时长（例如10s）内未执行完成（BroadcastQueue Timeout）而触发的无响应现象；内容提供类型的无响应现象是指内容提供者在发布（publish）后超时（ContentProvider Timeout）而触发的无响应现象；输入事件分发类型的无响应现象是指输入事件分发超时（InputDispatching Timeout）而触发的无响应现象。以上四类ANR可以归为如图1a所示的应用无响应的分类示意图。对于以上提及的应用的各类无响应现象的产生过程（或者说触发机制）将在下述一一介绍。

从操作系统的系统源码角度来说，触发ANR的过程具体可以分为3个步骤，如图1b所示，包括：设置时长阈值、解除应用无响应（即应用的无响应现象，简称ANR）的触发条件、触发应用无响应（即ANR）。通过设置时长阈值可以判断相应事件的实际处理时长是否超时（即实际处理时长大于设置的时长阈值），时长阈值可以依据相应ANR进行设置，不同ANR的时长阈值可能相同或不同。若超时则触发ANR，若没有超时则不会触发ANR，并且解除ANR触发条件，此处解除ANR触发条件是指取消原有设置的时长阈值。

下面对各种ANR的产生过程进行详细介绍。在此，先对以下应用无响应现象中所涉及的共同的概念以及一些术语进行介绍。

目标应用是指计算机设备中当前运行的任一应用程序。目标应用的应用进程可与操作系统底层的进程（例如系统服务进程）进行交互，完成相应的事件。

系统服务进程用于启动、管理整个Javaframework，系统中重要的服务都可以在系统服务进程中开启，例如组件管理服务AMS（ActivityManagerService）、窗口管理服务WMS（WindowManagerService）等。在Android操作系统中，可以通过Zygote进程（用于孵化新进程的进程，在此称为孵化进程）孵化出系统服务进程和目标应用的应用进程。以下内容具体是以操作系统中的系统服务进程作为执行主体进行描述。

Android操作系统四大组件：Activity、Service、BroadCast Receiver、ContentProvider。①Activity（组件）是对象操作的可视化界面，可以为对象提供完成操作指令的窗口。② Service（服务）是一个可以在后台执行长时间运行操作而没有对象界面的应用组件。由于Service通常在后台运行，一般不需与对象交互，因此Service组件没有图形对象界面，Service组件通常用于为其他组件提供后台服务或检测其他组件的运行状态。③BroadCast Receiver（广播接收器）可用于过滤出应用感兴趣的外部事件（例如电话呼入、数据网络可用时），并对其做出响应。BroadCast Receiver可以启动一个Activity或Service来响应它们收到的信息，或者用NotificationManager（通知管理者）来通知对象，例如播放声音的通知，或者是显示在状态栏的消息。④ContentProvider（内容提供者）使一个应用程序的指定数据集提供给其他应用程序，其他应用可以通过ContentResolver类从该内容提供者中获取或存入数据。具体地，ContentProvider将数据发布出来，可以通过ContentResolver对象结合Uri（Universal Resource Identifer，通用资源标识符）进行调用。其中，Uri代表数据操作的地址，每一个ContentProvider发布数据时都会有唯一的地址。

（一）服务类型的无响应现象。

服务类型的无响应现象的产生过程包括：响应于目标应用的应用进程发送的服务创建请求，设置服务时长阈值；向服务进程发送服务创建消息，以使得服务进程基于服务创建消息，通知服务进程调用一个或多个其他进程执行服务创建工作，并在成功创建服务后返回反馈信息；若在服务时长阈值内未接收到服务进程返回的反馈信息，则产生服务类型的无响应现象。

目标应用的应用进程发送的服务创建请求可用于请求系统创建目标应用所需的服务，例如收听服务、通知服务等，在云游戏场景下，该收听服务例如是收听玩家账号是否登录的服务，或者是收听玩家是否在线的服务。系统服务进程可以响应于应用进程发起的服务创建请求设置服务时长阈值，该服务时长阈值可用于检测服务创建是否超时。例如前台服务时长阈值和后台服务时长阈值均为20s。接着，系统服务进程可以向服务进程发送服务创建消息，以使得服务进程调用一个或多个进程执行服务创建工作，通过服务创建工作可以创建目标应用所需的服务。服务进程可以是由系统服务进程中的组件管理服务请求预先创建的。具体地，服务进程中的主线程可以调用一个或多个其他进程（即不同于服务进程之外的进程）执行服务创建工作，这一个或多个进程中可以包括具备父子关系的进程，且父子进程之间可共享地址空间。在服务创建工作执行完成之后，可以由服务进程中的主线程可以向系统服务进程发送反馈信息，此处的反馈信息可以是用于指示服务创建完成的通知消息。若在服务时长阈值内未接收到服务进程返回的反馈信息，则说明服务创建工作所花费的时长大于或等于服务时长阈值，发生服务超时的现象，进而产生服务类型的无响应现象。反之，若在服务时长阈值内接收到服务进程返回的反馈信息，则说明服务创建工作所花费的时长小于服务时长阈值，不会产生服务类型的无响应现象。

以Android操作系统的ANR为例，对上述内容进行示例性介绍。Service Timeout发生于startService（启动服务）的时候，对于Service具体可以包括以下两类：前台服务，超时时间（即服务时长阈值）为20s；后台服务，超时时间为200s。目标应用中启动一个Service，具体可以通过调用API startService一行代码即可实现。从Android操作系统层面来说，过程如下图1c所示的startService的简易流程示意图。服务创建启动的过程，主要是由系统服务进程中的组件管理服务（AMS，ActivityManagerService）来完成。AMS通过socket（套接字，一种通信方式）向Zygote请求创建承载服务的进程（Create Process），其中包括请求创建线程ActivityThread。服务运行于单独的进程中，对于运行本地服务可以不启动服务的过程，ActivityThread扮演者应用程序主线程的角色。之后Zygote通过fork，将Zygote进程复制生成新的进程，并将ActivityThread相关的资源加载到新进程。AMS向新生成的进程中的ActivityThread通过Binder（一种进程间通信机制）的方式发送创建服务的请求。ActivityThread启动运行服务，具体可以由ActivityThread调用onCreate方法创建服务（createservice）。

如图1d所示，当应用进程（即APP进程）发起创建服务的请求（startService）时，系统中的系统服务进程（即system_server进程）会派出一个空闲的线程binder_1（即通讯线程1）来接收该请求，紧接着向组件管理者ActivityManager发送服务超时消息SERVICE_TIMEOUT_MSG设置服务时长阈值；接下来，binder_1通知服务进程（即service进程）的binder_3线程（即通讯线程3）准备干活（调度创建服务scheduleCreateService）；binder_3收到后交给主线程（即main线程，可对应于图1c中的主线程ActivityThread），将服务创建事件加入到main线程的任务队列（即发送消息sendMessage）；接下来main线程会进行一系列工作，此处具体是服务创建工作，可包括图1c中由ActivityThread线程创建服务的过程，完成service生命周期的启动（等待完成waitToFinish）；完成上述工作后，main线程会向system_server进程汇报工作已完成（即完成服务创建工作serviceDoneExecuting），然后system_server进程中的binder_2线程（即通讯线程2）会收到消息，若在服务时长阈值的时间内完成服务创建工作，则可以解除ANR触发条件而不会发生ANR，否则就会发生ANR。

（二）广播类型的无响应现象。

广播类型的无响应现象的产生过程包括：响应于目标应用的应用进程发起的发送广播请求，设置广播时长阈值；向广播接收进程发送广播注册消息，以使得广播接收进程基于广播注册消息，通知广播接收进程调用一个或多个其他进程执行广播工作，并在广播完成后返回反馈信息；若在广播时长阈值内未接收到广播接收进程返回的反馈信息，则产生广播类型的无响应现象。

广播机制用于进程/线程间通信，广播可以分为广播发送和广播接收。广播可以包括并行广播和串行广播。通常应用的无响应现象发生在串行广播的场景下。与服务类型的ANR的产生过程类似，系统服务进程可以响应目标应用的应用进程发起的发送广播请求，设置广播时长阈值。目标应用的应用进程是广播发送端所在的进程。系统服务进程可以向广播接收进程发送广播注册消息，以使得广播接收进程中的主线程可调用一个或多个其他进程执行广播工作。这一个或多个进程中可以包括具备父子关系的进程，且父子进程之间可共享地址空间。

广播接收进程是广播接收端所在的进程，可用于接收来自于其他应用程序或者是系统的广播消息。广播工作具体可以广播各种事件，例如日期发生改变的广播、系统完成启动的广播等，在云游戏场景下，该广播事件例如是网络切换广播、网络故障广播等等。在执行广播工作之前可以基于广播注册消息创建广播接收队列对接收到的广播事件进行有序处理。在主线程对广播工作处理完成之后，可以返回反馈信息，该反馈信息是用于指示广播工作完成的通知消息。若在广播时长阈值内未接收到广播接收进程返回的反馈信息，则广播工作所花费的时长大于或等于广播时长阈值，发生广播超时的现象，进而产生广播类型的无响应现象。反之，若在广播时长阈值内接收到广播进程返回的反馈信息，则说明广播创建工作所花费的时长小于广播时长阈值，不会产生广播类型的无响应现象。

以Android操作系统的ANR为例，对广播类型的ANR进行更详细地介绍。具体可结合图1e所示的广播类型的ANR的产生过程的示意图。当目标应用的应用进程发起发送广播请求（sendBroadcast）时，系统服务进程可以派出一名空闲的线程binder_1（即通讯线程1）来接收该发送广播请求，紧接着向组件管理者ActivityManager发送广播超时消息BROADCAST_TIMEOUT_MSG（sendMessage）设置广播时长阈值，接下来，binder_1通知广播接收进程（即Reciver进程）的binder_3线程（即通讯线程3）准备干活了；binder_3收到后交给主线程（即main线程），将事件加入到main线程的任务队列（通讯线程3向主线程发送消息，sendMessage）；接下来main线程会进行一系列工作，此处为广播工作包括广播接收的生命周期的启动，若发现当前进程还有SP（SharedPreferences，一种数据存储方式）正在写入文件，需等SP数据持久化工作后（即主线程向排队工作循环线程发送消息，sendMessage），由queued-work-looper线程（排队工作循环线程）向system_server进程汇报广播工作已完成，反之，可以直接由主线程汇报广播工作已完成（即finishReceiver）。然后 system_server进程中的binder_2线程（即通讯线程2）会收到消息，若在广播时长阈值的时间内完成所有工作，则可以解除ANR的触发条件而不会发生ANR，否则就会发生ANR。

（三）内容提供类型的无响应现象。

内容提供类型的无响应现象的产生过程包括：响应于目标应用的应用进程发起的获取内容提供对象的请求，检测内容提供对象所对应的内容提供进程的启动状态；若启动状态指示内容提供进程未启动，则创建内容提供进程，并通知内容提供进程调用一个或多个其他进程，安装内容提供对象，以及在安装内容提供对象后返回反馈信息，内容提供对象配置有一个安装时长阈值；若在安装时长阈值内未接收到内容提供进程返回的反馈信息，则产生内容提供类型的无响应现象。

内容提供对象用于不同应用程序之间实现数据共享功能。内容提供进程用于安装并发布内容提供对象以提供内容数据，实现数据共享功能。系统服务进程可以响应于目标应用的应用进程发起的获取内容提供对象的请求，检测内容提供进程的启动状态，若内容提供进程未启动，表示内容提供进程可能未被创建，则可以创建该内容提供进程并启动，内容提供进程在创建之后可以向系统服务进程注册自己，并设置安装时长阈值，之后，通知内容提供进程执行内容提供对象的安装工作，具体可以由内容提供进程中的主线程调用一个或多个其他进程来执行。这一个或多个进程中可以包括具备父子关系的进程，且父子进程之间可共享地址空间。

在安装完成后可以返回反馈信息，该反馈信息是用于指示安装内容提供对象的工作完成的通知消息，还可用于指示发布内容提供对象，以返回获取到的内容提供对象所提供的内容数据。在云游戏场景下，该内容提供对象可以是系统中的通讯录，所提供的内容数据可以是通讯录中的联系人的相关数据。可以理解的是，在本申请的具体实施方式中，涉及到通讯录等相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得对象许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

若安装时长阈值内未接收到内容提供进程返回的反馈信息，则安装工作所花费的时长大于或等于安装时长阈值，发生内容提供超时的现象，进而产生内容提供类型的无响应现象。反之，若在安装时长阈值内接收到内容提供进程返回的反馈信息，则说明内容提供对象的安装工作所花费的时长小于安装时长阈值，不会产生内容提供类型的无响应现象。

以Android操作系统的ANR为例，对内容提供类型的ANR进行更详细地介绍。具体可结合图1f所示的广播类型的ANR的产生过程的示意图。当目标应用的应用线程发起获取内容提供对象ContentProvider的请求（getContentProvider）时，系统服务进程可以派出一名空闲的线程binder_1（即通讯线程1）来接收该获取ContentProvide的请求，若检测到ContentProvider尚未启动则先通过Zygote先fork出新进程（即通过Zygote fork创建新进程），新的ContentProvider进程向系统注册自己（attachapplicationlocked，附加应用程序锁）；system_server进程的通信现场binder_2（即通讯线程2）接收到该注册消息，向system_server进程内部的ActivityManager发送内容提供对象发布超时消息CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG消息，设置安装时长阈值；接下来，binder_2通知provider进程（即内容提供进程）的binder_4线程（即通讯线程4）准备干活了（绑定应用程序，bindApplication）；binder_4收到后交给主线程（即向main线程发送消息，sendMessage），将事件加入到任务队列；接下来main线程会进行一系列工作，此处为内容提供对象的安装工作，可选地，还可以包括发布内容提供对象的工作，然后向system_server进程汇报安装工作已完成，返回获取到的内容提供对象的内容数据（发布内容提供对象，publishContentProvider），然后system_server进程中的binder_3线程（即通讯线程3）收到消息，若在安装时长阈值内完成所有工作就可以解除ANR的触发条件而不会发生ANR，否则就会发生ANR。

（四）输入事件分发类型的无响应现象。

输入事件分发类型的无响应现象的产生过程包括：若接收到一个输入事件，则将当前接收到的输入事件添加至输入队列中，并唤醒输入分发线程，输入分发线程用于将输入队列中的各个输入事件依序分发给目标应用的应用进程进行处理；当当前接收到的输入事件的分发顺序到达时，目标应用的应用进程在处理其他的输入事件，则产生输入事件分发类型的无响应现象。

具体地，系统服务进程中的线程可以收听底层上报的输入事件，并在接收到输入事件时，可以将其添加至输入队列中等待被分发处理，同时，可以唤醒输入分发线程分发该输入队列中的输入事件，此时可以设置分发起始时间。在当前接收到的输入事件的分发顺序到达时，例如到达当前接收到的输入事件的分发时间点时，如果目标应用的应用进程还在处理其他输入事件，说明应用进程无法处理即将分发的当前接收到的输入事件，则会产生输入事件分发类型的无响应现象。在云游戏场景下，该输入事件具体可以是对象在游戏客户端中的操作事件，操作事件以操作流的方式抵达运行云游戏的服务器中，而无法被处理，发生ANR。

在另一种实现方式中，在当前接收到的输入事件的分发顺序到达时，目标应用的应用进程未处理其他的输入事件，则通过输入分发线程将当前接收到的输入事件分发给应用进程，以使应用进程调用一个或多个其他进程对当前接收到的输入事件进行处理，并在处理完成后返回反馈信息；若在处理时长阈值内未接收到应用进程返回的反馈信息，则产生输入事件分发类型的无响应现象。

在当前接收到的输入事件到达分发顺序时，例如基于分发起始时间点和处理时长阈值确定到达该输入事件的分发时间点，则可以通过输入分发线程将当前接收到的输入事件分发给应用进程，具体是分发至应用进程的目标窗口中，应用进程可以调用一个或多个其他进程对当前接收到的输入事件进行处理，并在处理完成后返回反馈信息，该反馈信息是用于指示输入事件完成的通知消息。其中调用的一个或多个进程中可以包括具备父子关系的进程，且父子进程之间可共享地址空间。

若在处理时长阈值内未接收到应用进程返回的反馈信息，并且接收到新的输入事件，说明当前接收到的输入事件未在规定的处理时长阈值内处理完，而下一个输入事件则会等待当前接收到的输入事件的处理，从而会产生输入事件分发类型的无响应现象。反之，在处理当前接收到的输入事件时只要没有接收新的输入事件，无论在处理时长阈值内未接收到应用进程返回的反馈信息，或者是在处理时长阈值内接收到应用进程返回的反馈信息，都不会发生输入事件分发类型的无响应现象。

以Android操作系统的ANR为例，对输入事件分发类型的ANR进行更详细地介绍。具体可结合图1g所示的输入事件分发类型的ANR的产生过程的示意图。首先，InputReader线程（即输入读取线程）通过EventHub（事件中心）收听底层上报的输入事件，一旦收到输入事件就将其放入mInBoundQueue队列（输入队列，用于存储将分发的输入事件）并唤醒InputDispatcher线程（输入分发线程）；InputDispatcher线程开始输入事件分发，设置分发起点时间，先检测是否有正处理的事件，若没有则取出mInBoundQueue队头的事件，然后检查窗口是否就绪；当窗口就绪，则将事件移到outBoundQueue队列（输出队列，用于存储即将要分发给目标窗口的输入事件）；此时，若应用管道对端连接正常则将数据从outBoundQueue取出，放入waitQueue队列（等待队列，用于存储等待目标窗口处理的输入事件），然后InputDispatcher发消息告知目标应用准备干活了；此时目标应用的main线程（即主线程）接收输入事件，并将接收到的输入事件层层转发到目标窗口处理；完成上述工作，会发消息向system_server进程汇报工作完成（即发送完成信号），接下来系统会将该事件从waitQueue队列中移除；若当前输入系统中正在处理某个耗时操作（例如文件操作），后续的每一次输入事件都会检测前一个输入事件是否超时，若超时就ANR。

基于以上对ANR的具体原理介绍，并对发生ANR的操作系统的源码（即系统代码）进行分析可知，Service、BroadcastQueue、ContentProvider、Input等场景下的ANR中应用进程都会与system_server进程进行交互，且都会与Zygote发请求创建新的进程（部分未示出，可以理解为新进程的创建都可以通过Zygote进程实现）。这些都是底层操作系统中的内容。

为解决ANR问题，本申请提供了一种对系统代码进行修复以解决应用的无响应现象的方案。具体而言，可以收集目标应用的各种无响应现象的现场信息，基于该现场信息可以得知目标应用产生无响应现象时系统代码的执行情况，通过对收集到的各种无响应的现场信息进行共性分析，可确定共性分析结果，所谓共性分析，是指寻找共同要素的分析，基于共性分析得到的共性分析结果，可以从操作系统的系统代码中确定产生无响应现象的故障点，从而基于故障点对系统代码进行修复，这样，基于修复后的系统代码运行目标应用就可以有效降低无响应现象发生的概率，减少因发生无响应现象导致目标应用或操作系统崩掉的情况，有利于系统和应用的稳定运行。本方案从底层系统角度出发，在操作系统层面通过修复操作系统的系统代码，实现从根本上解决了操作系统上应用无响应的问题，这是一种根源性的解决方法，具备通用性。

可见，从操作系统层面出发，深入研究操作系统中ANR的产生过程，得知ANR触发原理，并从操作系统的源码分析几类ANR发生时的底层架构逻辑，可以通过更改系统调用函数实现对操作系统中ANR触发的架构逻辑的改造，从根源上解决操作系统上的ANR问题，可以减少应用程序或者系统崩掉的情况，提高系统和应用的兼容性和稳定性。由于改造的是原生的操作系统，且没有硬编码的使用，因此，与特定平台没有强绑定，可以适用于云游戏、终端以及模拟器等各种场景，场景通用性强，并且能够应对多种ANR，有效规避各种ANR问题。

可以理解的是，本方案可以应用于各种产生应用无响应的场景中，例如终端、模拟器以及云游戏场景。当应用于云游戏场景中时，可以解决云游戏场景中的ANR问题，提高云游戏平台的兼容性和稳定性，提高使用体验。其中，目标应用可以是云游戏应用。所谓云游戏是指一种以云计算技术为基础的在线游戏技术。

云计算技术属于一种云技术，所谓云技术（Cloud technology）是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。其中，云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。本申请中，对于现场信息的共性分析也可以采用云计算技术。

在云游戏场景下，可以将游戏运行于云端服务器中，对于游戏中高消耗的渲染计算可以放置在云端服务器中进行，并以音视频流将画面和声音通过网络传输给玩家游戏终端，以操作流的方式将用户操作指令传输给云端服务器执行相应的计算。受益于当前移动通信技术，如5G（5th Generation Mobile Communication Technology，第五代移动通信技术，简称5G）高速发展，更高的传输带宽、更强的并发能力，带来了更低的网络延时，也为云游戏带来更多发展机会和更大的想象空间。

运行云游戏的环境可称为云游戏环境。在该云游戏环境下，可通过运行系统容器的方式，将多个操作系统运行在一个或多个独立的服务器（如采用ARM /x86等架构的服务器）上，并通过视频流的方式将相关图像传递至远端接收程序进行处理。其中，ARM架构是一种32位/或64位精简指令集的处理器架构，x86架构（The X86 architecture）是微处理器执行的计算机语言指令集。容器是指操作系统级虚拟化的一种类型，容器可用于承载操作系统；其通过隔离机制（例如namespace（命名空间））可实现：在内核态，多个操作系统（即服务器操作系统和设备操作系统）共用同一内核；在用户态，多个操作系统保持相互独立。此处的服务器操作系统是指服务器内的通用操作系统，如Linux操作系统、Android操作系统等等；设备操作系统是指容器内的操作系统，如Android（安卓）操作系统、IOS操作系统等。

相应的，系统容器是指容器的一种实例，其可基于服务器操作系统（如Linux操作系统）运行；例如该系统容器可以是在Linux操作系统之上运行的Android容器，Android容器加载的是Android镜像，所谓的镜像是一种文件存储形式；通过镜像将多个文件合并成一个镜像文件，可便于文件的分发和使用。应理解的是，本申请实施例所提及的系统容器并不局限于Android容器；例如，若IOS操作系统支持开源研发，则该系统容器还可以是IOS容器，等等。可见，在本申请实施例所提出的云游戏环境下，可通过在一个独立的服务器上部署大量的系统容器，充分利用服务器端强大的CPU（Central Processing Unit，中央处理器）能力以及GPU（Graphics Processing Unit，图形处理器）能力，实现高并发地执行系统操作，提升云游戏的运行速度。

云游戏环境可以由云游戏系统中的设备提供相应的运行资源支撑。请参见图2a所示的云游戏系统的架构示意图，云游戏系统可以包括至少一个边缘服务器11、多个游戏客户端12以及至少一个分析服务器13。其中，边缘服务器是运行有云游戏的服务器，如图2a中所示的各个边缘服务器内可部署至少一个系统容器，并在系统容器内安装一个或多个游戏APP（Application，应用程序），通过这些游戏APP可以运行一个或多个云游戏，这样，通过系统容器就可以运行云游戏。每个系统容器可以与至少一个游戏客户端12相连接，从而将云游戏的游戏画面以及声音传输相连接的游戏客户端12中。此外，在边缘服务器11运行云游戏的过程中发生ANR时，可以在游戏客户端12进行显示提示，如图2b所示。

分析服务器13是用于分析应用发生无响应现象的服务器。在至少一个边缘服务器11中的系统容器中的云游戏应用在运行过程中，可能存在一个或多个边缘服务器中的应用发生不同类型的无响应现象，此时分析服务器13可以收集边缘服务器11中某个云游戏应用的至少两种无响应现象发生时产生的现场信息，并对各种无响应现象的现场信息进行共性分析，基于共性分析结果找出产生无响应现象的共有的故障点，通过该共有的故障点修复操作系统的系统代码，并基于修复后的系统代码运行云游戏应用，解决应用无响应的问题。在另一个实施例中，上述工作也可以由一个目标边缘服务器执行，即至少一个边缘服务器11中的任一个边缘服务器可以获取多种无响应现象的现场信息，基于上述相同的原理修复操作系统的系统代码，以解决和规避应用无响应现象。

需要说明的是，边缘服务器和分析服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN（ContentDelivery Network，内容分发网络）、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。

游戏客户端12可以提供流媒体播放能力、人机交互能力以及通信能力等基本能力的终端设备，也可以是运行于终端设备中的应用程序。其中，终端设备包括但不限于：手机、电脑、智能语音交互设备、智能家电、车载终端、飞行器等等设备，本申请对此不作限制。可以理解的是，图2a只是示例性的表征云游戏系统的系统架构，并不对云游戏系统的具体架构进行限定；例如在其他实施例中，云游戏系统中还可包括用于调度的后台服务器，等等。

基于上述所介绍的云游戏环境以及云游戏系统，对于部署在服务器一侧的云游戏，其底层可以基于容器化技术、系统与内核技术，并在此基础上还可以联合音视频技术、网络优化、计算资源管理等方面，打造出相应的云游戏平台（可为云游戏提供运行环境和服务），在该云游戏平台中可运行多种云游戏。下面以云游戏底层基于Android原生操作系统和Linux内核为例，对云游戏运行过程系统层面相关的交互逻辑进行示例性地说明。参见图2c所示，在服务器中系统的底层交互逻辑，具体涉及系统容器、Linux内核以及服务器所提供的硬件之间的交互。

在系统容器运行云游戏的过程中，系统容器或者是系统容器中的游戏APP可以向操作系统发送操作请求，并由操作系统与其中的Linux内核进行交互，由Linux内核接收该操作请求，基于该操作请求Linux内核可以调用相关的硬件（例如中央处理器、图形处理器、内存等中的一种或多种）完成该操作请求对应的操作，当硬件按照操作请求执行完之后，可以将操作请求对应的操作结果通过Linux内核返回给系统容器。举例来说，当操作请求是渲染请求时，可以基于渲染请求调用服务器所提供的图形处理器（GPU，Graphics ProcessingUnit）执行该渲染请求对应的渲染事件，得到渲染完成的游戏画面，并通过Linux内核返回渲染完成的游戏画面。在一种实现方式中，还可以调用系统容器中的编码模块对返回的游戏画面进行图像压缩处理，得到压缩后的图像，在图像压缩过程中，可以通过Linux内核调用底层的硬件资源进行编码，得到编码数据（即压缩后的图像），并将压缩后的图像通过Linux内核返回至操作系统，得到编码数据之后再以视频流的方式将压缩后的图像传输至游戏客户端中。

由于云游戏底层也是基于操作系统，而ANR是操作系统中常见的现象，因此，在运行云游戏的过程中，也会面临ANR的问题。可以采用上述所提及的对系统代码进行修复以解决应用无响应现象的方案加以解决。

基于上述所提及的对系统代码进行修复以解决应用无响应现象的方案，本申请提供了一种数据处理方法，该数据处理方法可以由计算机设备执行，计算机设备可以是终端或者服务器。当目标应用为云游戏应用时，此处的计算机设备可以例如是图2a所示的云游戏系统中的任一分析服务器13。当然，该数据处理方法也可由终端和服务器共同执行，对此不作限定；为便于理解，以该数据处理方法由计算机设备执行为例进行如下说明。

可以理解的是，终端可以是手机、电脑、智能语音交互设备、智能家电、车载终端、飞行器等等设备，本申请对此不作限制。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN（Content DeliveryNetwork，内容分发网络）、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。

请参见图3a，图3a是本申请实施例提供的一种数据处理方法的流程示意图，该数据处理方法可包括以下步骤S301-S303：

S301，获取目标应用的多种无响应现象中的各种无响应现象的现场信息。

目标应用的多种无响应现象是指目标应用的至少两种无响应现象，例如前述介绍的服务类型的无响应现象、广播类型的无响应现象、内容提供类型的无响应现象以及输入事件分发类型的无响应现象中的至少两种。

任一种无响应现象是在基于操作系统的系统代码运行目标应用的过程中产生的。目标应用的无响应现象是指目标应用程序未响应的现象，具体是一些事件在预定时间内未能得到有效响应或者响应时间过长的现象。为便于描述，目标应用的无响应现象可简称为应用无响应（ANR）或者ANR现象。

操作系统(Operation System, OS)用于控制和管理整个计算机系统的硬件和软件资源，并合理的组织和调度计算机的工作和资源的分配，以提供给对象和其它软件方便的接口和环境。操作系统的类别包括但不限于：Android操作系统、Windows操作系统、Linux操作系统、iOS操作系统等等。

操作系统可以为应用程序提供运行环境，应用程序可以通过调用操作系统提供的函数（即系统调用）完成一些事件。因此，基于操作系统的系统代码运行目标应用是指在运行目标应用的过程中，操作系统的系统代码可以被调用。在此过程中，目标应用有可能发生无响应现象，例如调用Android操作系统的系统代码运行目标应用时，目标应用所需的收听服务在预定时间内未创建完成而引起的无响应现象。目标应用是指运行在计算机设备中的任一应用。例如在终端中运行的应用，或者在服务器中运行的服务程序。目标应用具体可以是游戏类应用、音视频类应用、社交类应用、购物类应用等等中的任一种，以云游戏场景为例，该目标应用可以是指部署在服务器的系统容器中的云游戏应用或者云游戏服务程序。

目标应用的无响应现象可以在不同场景下产生，一种场景下产生的无响应现象可以对应一类无响应现象。以Android操作系统为例，具体会在以下场景下产生无响应现象：①服务超时（Service Timeout），具体包括前台服务超时和后台服务超时，比如前台服务在20s内未执行完成；②广播超时（Broadcast Timeout），包括前台广播超时和后台广播超时，例如前台广播在10s内未执行完成；③内容提供者超时（ContentProvider Timeout），例如内容提供者在publish（发布）后超时10s发生无响应现象；④输入事件分发超时（InputDispatching Timeout），包括按键和触摸事件，具体地，包括按键响应分发超时（KeyDispatch Timeout）和触摸事件分发超时，例如在按键响应分发时长默认为5s，超过则会发生无响应现象。

每种无响应现象发生时都可以自动产生并收集现场信息，一种无响应现象可对应于一类现场信息。任一种无响应现象的现场信息用于描述：在产生相应的无响应现象时，系统代码的执行情况。

任一种无响应现象的现场信息是指在任一种无响应现象产生时操作系统所抓取的相关信息。该现场信息可用于描述产生该种无响应现象时，操作系统的系统代码的执行情况。系统代码的执行情况例如是系统代码执行到哪一步发生无响应现象，在哪个进程或者线程中事件响应超时等内容。由前述图1d至图1g所介绍的ANR的产生过程可知，在ANR发生时会运行很多进程，例如在服务类型的ANR中运行的进程有：系统服务进程、服务进程以及其他未示出的进程，因此，现场信息可以包括在系统代码中被运行的进程的相关信息，例如进程的进程标识。可选地，现场信息可以包括但不限于以下内容：ANR的发生时间、用于记录发生ANR前后进程的各个线程的栈（stack）的溯源（trace）文件、ANR类型、产生ANR时各个进程的信息（例如进程号、进程名称、进程执行开始时间和结束时间）等等。各种无响应的现场信息可以记录于相关日志中，在具体分析时，可以获取全部或者部分现场信息进行进一步地分析。

示例性地，以云游戏场景为例，在一个云游戏上应用无响应的现场可以如图3b所示。其中，docker exec –it b2343985639e sh表示进入到容器名称为b2343985639e的容器中，查找对应镜像的配置文件所在位置。ps -ef | grep Sgame则表示在容器名为b2343985639e的容器中将查找到含有sgame关键字的进程并显示出来。如图3b所示的云游戏平台产生应用无响应现象的现场，获取到的现场信息包括在容器中各个进程（仅展示部分）的进程信息。以显示的第一行信息为例，包括进程的进程ID（PID，ProcessIdentifiction）1910，该进程的父进程的ID（PPID，Parent Process Identifiction）110，cpu使用的资源百分比16，系统启动时间12:54:18，使用掉的CPU时间00:03:15，以及进程名称“com.ten.tmgp.sgame”等。

通过对各种无响应现象的现场信息进行收集，可以得到在各种无响应现象发生时，操作系统的系统代码的执行情况，这样有利于后续分析发生这些无响应现象的共同特性，以有效避免操作系统之上的应用无响应现象。具体可以参见S302和S303的介绍。

S302，对各种无响应现象的现场信息进行共性分析，得到共性分析结果，并根据共性分析结果从系统代码中确定产生无响应现象的故障点。

共性分析是指寻找共同特性的分析方法，此处对各种无响应现象的现场信息进行共性分析，即是指寻找产生各种无响应现象的共同特性，得到共性分析结果。共性分析结果包括各种无响应现象的现场信息中的共有信息，例如各种无响应现象的现场信息中都有相同的进程号。

基于共性分析结果可以从系统代码中确定出产生无响应现象的故障点，该故障点是各种无响应现象发生的共同的故障点。故障点可以是系统代码中导致各种无响应现象产生的故障代码。例如都是在使用系统调用函数时发生的无响应现象。通过该故障点能够进一步得知导致应用无响应现象产生的共同原因，从而便于确定对系统代码的修复方式。

由于导致产生ANR的原因有非常多，例如死锁导致ANR、I/O资源不足导致ANR以及主线程死循环导致ANR等等，若针对具体ANR具体分析的方法会受限于具体场景（例如操作系统版本、应用版本、终端等），可能换一个场景解决ANR的方案就不适用，因此，对于各种场景通用性并不高。而本方案中所提供的分析机制是一种共性分析机制，通过寻找各种无响应现象的现场信息之间的共同特性，得到共性分析结果，并基于共性分析结果获知各种无响应现象发生的故障点。进而通过后续修复处理可以克服目标应用的多种无响应现象中的任一种无响应现象，有效降低应用无响应现象的发生概率，对于各种场景下都具备通用性和稳定性。

S303，根据故障点对系统代码进行修复处理，以基于修复后的系统代码运行目标应用。

由于故障点是从底层的系统代码中确定的，因此基于故障点可以对操作系统的系统代码进行修复处理，得到修复后的系统代码。此处的修复处理可以是指对系统代码的修改，修复后的系统代码是基于故障点对原有系统代码的优化。基于修复后的系统代码运行目标应用，可以在目标应用运行的过程中，调用修复后的系统代码，由于系统代码优化了发生无响应现象的故障点，因此可以在应用程序运行过程中有效避免产生无响应现象。

这样，通过对操作系统的系统代码的修复实现了对原生操作系统的改造，由于是对系统代码的修改，可以从原理上解决多种ANR发生时的问题，而操作系统可以部署在任何设备或平台中。这样，本方案不仅可以应用于云游戏平台，有效解决云游戏平台因发生ANR的不稳定现象，提高云游戏平台的稳定性。还可以应用于真实的终端（例如手机）、模拟器（例如Android模拟器）产品以及操作系统平台（例如其他Android平台）等等，场景通用性强，可以有效规避各种ANR现象。

通过本申请实施例提供的数据处理方案，支持对目标应用的多种无响应现象的现场信息进行收集，由于现场信息是用于描述对应产生该无响应现象时系统代码的执行情况，通过对多种ANR的现场信息进行共性分析，可以从操作系统层面对系统代码的执行情况进行分析，从底层寻找产生各种无响应现象的共同特性，得到共性分析结果，基于共性分析结果确定出产生无响应现象的故障点，进而基于故障点修复操作系统的系统代码，并可基于修复后的系统代码运行目标应用。这样，在运行目标应用的过程中，修复后的系统操作可以从操作系统侧对无响应现象可能发生的情况进行拦截，可以很好地应对绝大多数ANR场景，避免绝大多数ANR问题。可见，本方案可以从操作系统的底层系统代码出发，从根源上解决操作系统上ANR的问题，通用性强，能够减少操作系统或者是目标应用发生任一种无响应现象的情况，从而有效提高系统或应用的稳定性。当应用于云游戏平台时，可以提高云游戏平台的兼容性和稳定性，提高玩家的游戏体验。

请参见图4，图4是本申请实施例提供的另一种数据处理方法的流程示意图，该数据处理方法可包括以下步骤S401-S406：

S401，获取目标应用的多种无响应现象中的各种无响应现象的现场信息。

S402，对各种无响应现象的现场信息进行共性分析，得到共性分析结果。

在一个实施例中，系统代码包括多个进程以及每个进程所执行的代码片段；任一种无响应现象的现场信息包括：在产生相应的无响应现象时，系统代码中被运行的各个进程的进程标识。

系统代码中可以有多个进程，进程是程序的一次执行过程，可执行程序运行起来后就是进程。进程可以在运行环境中执行代码。系统代码中包括多个进程中每个进程所执行的代码片段，代码片段是系统代码中由进程执行的部分系统代码。具体地，当系统代码被编译之后再运行，该系统代码可以运行成多个进程实例，每个进程实例执行对应的代码片段。

由于无响应现象是在运行目标应用的过程中产生的，而目标应用的运行会调用操作系统的系统代码。系统代码中包括的各个进程可以被运行，以执行对应的代码片段。因此，现场信息可以包括被运行的进程对应的进程标识。进程标识是用于标记进程的信息，该进程标识可以是进程名称或者进程名称的关键字等等。

基于以上内容，共性分析可以基于现场信息中包含的进程标识进行。S402的可选实现方式可以是：针对各种无响应现象的现场信息中的任一现场信息，遍历任一现场信息中的各个进程标识；在除任一现场信息以外的各个现场信息中，查找当前遍历的进程标识；若查找到当前遍历的进程标识，则将当前遍历的进程标识添加至共性分析结果中；若未查找到当前遍历的进程标识，则继续遍历任一现场信息中的各个进程标识。

任一现场信息是指获取到的各种无响应现象的现场信息中的任一种无响应现象的现场信息。可以遍历任一现场信息中的各个进程标识，在遍历过程中，针对当前正在遍历的进程标识，可以在其他无响应现象中的现场信息中查找当前遍历的进程标识。当前遍历的进程标识是在任一现场信息中正在遍历的进程标识。若查找到当前遍历的进程标识，则说明其他现场信息中存在与当前遍历的进程标识相同的进程标识，该进程标识对应的进程在产生其他无响应现象时同样被运行，查找到的当前遍历的进程标识是各种无响应现象共有的进程标识，可以将当前遍历的进程标识添加至共性分析结果中，若未查找到当前遍历的进程标识，则说明其他现场信息中不存在与当前遍历的进程标识相同的进程标识，进而可以继续遍历任一种无响应现场信息中的各个其他进程标识。

举例来说，获取到的多种无响应现象的现场信息包括4种无响应现象的现场信息，4种无响应现象的现场信息分别为：A类无响应现象的a现场信息、B类无响应现象的b现场信息、C类无响应现象的c现场信息以及D类无响应现象的d现场信息。假设现场信息中包含进程标识是进程名，当前正在遍历a现场信息中的进程名game，可以在b现场信息、c现场信息以及d现场信息中查找在a现场信息中正在遍历的进程名game，当b现场信息、c现场信息以及d现场信息中都找到该进程名，可以将查找到的进程名添加至分析结果中。可以理解的是，以上共性分析的具体实现方式是一种可选的方式，也可以采用其他方式进行共性分析，例如基于线程进行共性分析，在此不做限制。

可见，通过任一种无响应现象的现场信息中正在遍历的进程标识为基准，查找其他各个现场信息中相同的进程标识，可以实现对系统代码中共有特性的分析，通常进程标识是简洁的表示，例如数字或简单的字符，可以高效地查找相同的进程标识时，提高共性分析的效率。

在一种实现方式中，共性分析结果中包括各种无响应现象的现场信息之间共有的进程标识。在此基础上，基于共性分析结果从系统代码中确定故障点的方式可以采用以下S403~305的实现方式。其中，共有的进程标识可以采用上述介绍S402的可选实现方式实现，也可以采用其他方式。

S403，基于共性分析结果中的各个进程标识确定M个目标进程。

由于进程标识用于标记进程，因此，可以将共性分析结果中每个进程标识对应的进程都可以确定为目标进程，从而得到M个目标进程。其中，M为大于1的正整数，M的取值等于共性分析结果中的进程标识的数量。举例来说，共性分析结果中包括2个进程标识：process1和process2，那么process1对应的进程以及process2对应的进程均可以作为目标进程，这样基于共性分析结果中的2个进程标识就可以确定出2个目标进程了。

S404，确定M个目标进程中的各个目标进程之间的关联关系，并从系统代码中获取各个目标进程所执行的代码片段。

各个目标进程之间的关联关系可用于描述M个目标进程中至少两个进程之间的层级关系。该关联关系包括但不限于：父子关系、兄弟关系等。一个进程可以与其他一个或多个进程之间存在关联关系，比如，进程process1为process2的父进程，而process1又为process4的子进程，也即process1和process2为父子关系，且process1和process4也为父子关系，只是在父子关系中进程process1所扮演的角色不同。

在一个实施例中，M个目标进程包括第一进程和第二进程，即2个目标进程。第一进程和第二进程是各种无响应现象产生时的共有进程，具体是指无响应现象产生前都会被运行的进程。

确定M个目标进程中各个目标进程之间的关联关系的具体实现方式，可以包括以下内容：从各种无响应现象的现场信息中，获取第一进程的属性信息以及第二进程的属性信息；任一进程的属性信息包括：任一进程的进程号以及调用任一进程的进程的进程号；若第二进程的属性信息中包括第一进程的进程号或者第一进程的属性信息中包括第二进程的进程号，则确定第一进程和第二进程之间的关联关系为父子关系。

任一种无响应现象的现场信息中可以包括：产生该种无响应现象时，系统代码中被运行的进程对应的属性信息。可以从各种无响应现象的现场信息中，获取共性分析结果中的进程标识所对应的进程（即目标进程）的属性信息。此处，目标进程包括第一进程和第二进程，从现场信息中获取到的进程的属性信息具体包括第一进程的属性信息和第二进程的属性信息。进程的属性信息是用于描述进程的特征的信息，任一进程的属性信息包括该进程的进程号以及调用任一进程的进程的进程号。例如任一进程为进程A，若进程B调用了进程A，则进程A的属性信息便可包括进程A的进程号（即任一进程的进程号）以及进程B的进程号（即调用任一进程的进程的进程号）。通过属性信息，可以得知进程本身的进程号以及具体是哪个进程调用当前进程。进程号（process Identification，PID）可以是在操作系统创建进程时为进程分配的唯一标识号，进程号可以通过自然数表示，例如123、605，也可以通过二进制表示，例如001、010，在此对进程号的表示不做限制。

第一进程的属性信息包括第一进程的进程号以及调用第一进程的进程的进程号，第二进程的属性信息包括第二进程的进程号以及调用第二进程的进程的进程号。接着可以选择任一进程的属性信息进行分析，具体包括以下几种情况：

（1）若第二进程的属性信息中包括第一进程的进程号，说明第二进程的属性信息中调用第二进程的进程的进程号为第一进程的进程号，即第二进程被第一进程调用或者说第一进程调用第二进程，则可以确定第一进程和第二进程之间的关联关系为父子关系，并且第一进程为第二进程的父进程，第二进程为第一进程的子进程。

（2）若第一进程的属性信息中包括第二进程的进程号，说明第一进程的属性信息中调用第一进程的进程的进程号为该第二进程的进程号，即第一进程被第二进程调用或者说第二进程调用第一进程，则也可以确定第一进程和第二进程之间的关联关系为父子关系，且第一进程为第二进程的子进程，第二进程为第一进程的父进程。

示例性地，如前述图3b所示云游戏ANR的现场是各种无响应都会产生该现场，并收集现场信息。因此，共性分析结果中可以包括图3b所示的进程的相关内容。如图3b可知，操作系统同时有2个sgame进程，分别为进程号为1910的进程以及进程号为4697的进程。根据进程号可以发现第2个进程（即进程号为4697的进程）的父进程号为1910，也就是第1个sgame进程。由此可以得知这2个进程之间是父子关系，且第2个进程为第1个进程的子进程，而第1个进程又是进程号为110的进程的子进程。

（3）若第二进程的属性信息中不包括第一进程的进程号，第一进程的属性信息也不包括第二进程的进程号，说明调用第二进程的进程不是第一进程而是其他进程，调用第一进程的进程也不是第二进程而是另外的进程，则可以确定第一进程与第二进程之间的关联关系不是父子关系，而是其他关系，例如兄弟关系，即第一进程和第二进程都为某个相同进程的子进程，举例来说，假设进程号为1910的第一进程以及进程号为4906的第二进程都是sgame进程，但是第一进程和第二进程的父进程号都是110，也就是说，第一进程和第二进程都为进程号为110的进程的子进程。可以判断出这两个进程为兄弟关系。

可见，通过进程的属性信息中包括的进程本身的进程号与调用该进程的进程的进程号，可以确定出与其他进程的进程号之间的关系，从而十分方便地确定出进程之间的关联关系。

由于进程在运行时会执行系统代码中对应的代码片段，因此，可以从系统代码中获取到各个目标进程所执行的代码片段，由于目标进程有M个，具体可以获取到M个代码片段，以便于后续从各个代码片段中确定产生无响应现象的故障点，具体可参见下述S405。

S405，基于关联关系，从获取到的M个代码片段中确定产生无响应现象的故障点。

M个代码片段中每个代码片段由M个进程中对应进程所执行。通过M个目标进程中各个进程之间的关联关系，可以从获取到的M个代码片段中确定产生无响应现象的故障点。该故障点可能是M个代码片段中某个代码片段中的一个代码语句或者是一段代码。由于代码片段是各种无响应现象发生时都会执行的，因此，该故障点是对于各种无响应现象而言共有的故障点，由于该故障点的存在，任一种无响应现象都有可能被触发，具体触发的是哪种无响应现象，可以结合其他信息进行判断，如进程执行的事件类型，例如进程执行输入分发事件，则可以判定是输入分发超时的ANR。

以上S403~S405的步骤中，通过共性分析结果中包括的进程标识可以确定目标进程，进一步可以确定各个目标进程之间的关联关系，从系统代码中获取各个目标进程所执行的代码片段，并基于关联关系和获取到的代码片段分析出产生无响应现象的故障点。此种方式从底层的操作系统的系统代码着手，基于对各种无响应现象进行共性分析之后，将共性分析结果用于确定出各种无响应现象产生时都被执行的系统代码，从系统代码中确定出故障点，进而能够从系统层面确定出导致ANR的共同原因，以便于从根本上修复以解决ANR的问题。

S406，根据故障点对系统代码进行修复处理，以基于修复后的系统代码运行目标应用。

本申请实施例所提供的方案，可以对获取到的多种无响应现象的现场信息进行共性分析，查找出目标应用发生无响应现象时被运行的共有进程（例如共有的进程标识对应的进程），这些共有进程可以作为目标进程被进一步分析，具体可以回归到操作系统的系统代码中，基于关联关系和目标进程所执行的代码片段中确定产生无响应现象的故障点，该故障点具体是从目标进程所执行的代码片段中确定，这样，就能够从系统底层确定应用无响应现象产生的根本原因，以便于从根源上解决应用无响应的问题，在基于故障点对系统代码进行修复之后，修复后的系统代码可以有效减少目标应用的运行过程中产生无响应现象的情况，提高应用运行以及系统的整体稳定性。

请参见图5，图5是本申请实施例提供的再一种数据处理方法的流程示意图，该数据处理方法可包括以下步骤S501-S507：

S501，获取目标应用的多种无响应现象中的各种无响应现象的现场信息。

S502，对各种无响应现象的现场信息进行共性分析，得到共性分析结果。

S503，基于共性分析结果中的各个进程标识确定M个目标进程。

S504，确定M个目标进程中的各个目标进程之间的关联关系，并从系统代码中获取各个目标进程所执行的代码片段。

S505，基于关联关系，从获取到的M个代码片段中确定产生无响应现象的故障点。

在一个实施例中，M个目标进程包括第一进程和第二进程，且第一进程和第二进程之间的关联关系为父子关系；其中，第一进程是第二进程的父进程。第二进程是第一进程的子进程。对于第一进程和第二进程之间的关联关系的确定，可以采用上述实施例中所介绍的根据进程的属性信息中所包含的进程号确定出关联关系。

在基于图4对应的实施例中相关部分介绍的内容的基础之上，S505的具体实现方式可以包括以下内容：基于父子关系，将获取到的第一进程所执行的代码片段确定为基准代码片段；并从基准代码片段中确定第一代码语句，第一代码语句是指：在发生无响应现象之前，第一进程所执行的代码语句；当第一代码语句是用于实现函数调用操作的语句时，在第一进程执行的代码片段中沿着第一代码语句分析出第一进程的调用栈，调用栈包括第一进程调用的各种函数；若调用栈中存在调用失败的目标函数，则从基准代码片段中确定目标函数的逻辑代码；基于第二进程所执行的代码片段，从目标函数的逻辑代码中确定产生无响应现象的故障点。

第一进程所执行的代码片段中包含许多代码语句，在发生无响应现象的时刻之前，第一进程可能执行了代码片段中的部分代码语句就停止执行了。第二进程也是类似的原理。由于第一进程和第二进程之间是父子关系，第一进程作为父进程，其所执行的代码可能存在创建第二进程的代码，因此首先可以对第一进程所执行的代码片段确定为基准代码片段进行分析，基准代码片段是用于作为分析基准的代码片段。可以从基准代码片段中确定第一代码语句，该第一代码语句是在发生无响应现象之前，第一进程所执行的代码语句。可以对第一代码语句进行判断，确定是否满足分析条件，再执行进一步地分析。具体地：

（1）当第一代码语句是用于实现函数调用操作的语句时，可以在第一进程执行的代码片段中沿着第一代码语句分析出第一进程的调用栈。

基于第一代码语句可调用相关可执行程序或系统命令，实现函数调用操作。示例性地，作为父进程的第一进程执行的第一代码具体可以是执行Runtime.getRuntime().exec( “xxx.exe”)的语句。其中，Runtime.getRuntime().exec()用于调用外部可执行程序或者是系统命令，Runtime.getRuntime() 返回当前应用程序的Runtime对象，该对象的exec() 方法指示创建一个子进程执行指定的可执行程序（此处即为名为“xxx.exe”的可执行程序，“xxx.exe”表示要执行的程序名），并返回与该子进程对应的Process对象实例，通过Process可以控制该子进程的执行或获取该子进程的信息。

父进程在发生ANR之前执行的最后一条代码语句为第一代码语句，可以对第一代码语句进一步分析：在第一进程所执行的代码片段中，沿着第一代码语句可分析出第一进程的调用栈，该调用栈包括第一进程调用的各种函数。对于调用栈的分析可以根据第一进程执行的代码片段的类型采用相应的调试工具，例如第一进程执行的代码片段为Java代码，则可以使用printStackTrace（一种在命令行打印异常信息在程序中出错的位置及原因的调试工具），第一进程执行的代码片段为Native C代码，则可以使用strace（一种用来拦截和记录进程所执行的系统调用，以及进程所收到的信号的调试工具），这些调试工具都可以分析出相应进程的调用栈。调用栈也可以理解为是解释器（比如浏览器中的JavaScript解释器）跟进函数执行流的一种机制，通过这种机制，能够得知哪个函数正在执行，执行的函数体中又调用了哪个函数。

下面以云游戏场景下发生ANR为例，根据云游戏平台上ANR的现场信息进行分析，确定操作系统同时有2个sgame的进程，并且这两个进程为父子关系，通过调试工具抓取出现场的调用栈，通过调用栈确定出父进程在ANR之前是在为执行Runtime.getRuntime().exec()的语句（即执行第一代码语句），沿着Runtime.getRuntime().exec()可以发现父进程调用栈如图6a所示。具体地，Runtime类调用exec方法，通过exec方法创建ProcessBuilder类，并且通过ProcessBuilder.start()方法创建ProcessImpl类，然后使用start()方法创建Unix进程，通过new Unixprocess创建Unix进程对象，再基于Unix进程对象fork出一个新进程，新进程执行和Unix进程不同的程序代码，得到UnixProcess_md.c，然后基于UNIX进程fork出一个新进程并执行和UNIX进程不同的程序代码，最后调用startChild函数。以上即为父进程的调用栈，父进程调用栈中最后一个函数调用startChild函数则是程序出错的大致位置。

若调用栈中存在调用失败的目标函数，说明第一进程执行的代码片段中出错，并且出错的位置是在目标函数处，如上述图6a示出的父进程调用栈中的函数调用只显示到startChild函数，说明第一进程执行到startChild函数为调用时程序崩溃。因此，可以进一步对目标函数进行分析：从第一进程所执行的代码片段中确定出目标函数的逻辑代码，该逻辑代码是第一进程所执行的代码片段中的部分代码，基于第二进程所执行的代码片段，从目标函数对应的逻辑代码中确定产生无响应现象的故障点。此时，故障点具体是目标函数对应的逻辑代码中的代码语句。

（2）当第一代码语句不是用于实现函数调用操作的语句时，例如第一代码语句为其他代码语句时，则可以根据该代码语句的执行情况分析与其相关的代码语句。

可见，对具备父子关系的进程所执行的代码片段进行分析，具体通过分析父进程的第一进程的调用栈，可以大致地获知父进程对代码片段的实际执行情况，从而可以基于实际执行情况，确定具体将从执行崩掉的目标函数的逻辑代码中定位产生无响应现象的故障点，进一步缩小定位范围。

在一种实现方式中，目标函数的逻辑代码中包括进程创建语句，该进程创建语句是用于创建子进程的语句，且通过进程创建语句所创建的子进程与相应的父进程之间共享同一个地址空间。

示例性地，基于图6a的父进程调用栈中的目标函数，提供如图6b所示为目标函数的逻辑代码，其中包含进程创建语句。目标函数是基于图6a的父进程调用栈所分析出来的startChild函数，如图6b所示的startChild函数的具体逻辑为：如果START_CHILD使用vfork（if START_CHILD_USE_VFORK），则可以通过进程创建语句Volatile pid_tresultPid = vfork()创建进程。对于采用此种方式的解释如下：将对vfork的调用分离到一个单独的startChild函数中，可以确保防止子堆栈破坏父堆栈，正如gcc警告所建议的那样，其中，gcc警告具体为：变量“foo”可能被“longjmp”或“vfork”破坏，foo表示数据、功能或命令的变量，longjmp是一种跳转方式。其中，vfork是Linux的一个系统调用，其创建的进程，父子进程的地址空间共享。也就是说，通过系统调用vfork创建的子进程，和其对应的父进程之间的共享同一个地址空间，这样，子进程是完全运行在父进程的地址空间上的，若子进程修改了某个变量，会直接影响到父进程。

对于具备父子关系的第一进程和第二进程，第二进程为第一进程的子进程，即第一进程为父进程，第二进程为子进程。第一为进程通过执行目标函数中的进程创建语句可以创建出第二进程，这样，第一进程和第二进程之间就共享同一个地址空间。其中，地址空间是所有可用资源的集合，此处共享的地址空间可以是物理地址空间或者是虚拟地址空间。

基于第二进程所执行的代码片段，从目标函数的逻辑代码中确定产生无响应现象的故障点的实现方式可以包括以下内容：从第二进程执行的代码片段中确定第二代码语句；当第二代码语句是用于实现数据读取操作的语句时，根据第二代码语句确定第二进程所需读取的目标资源；若目标资源被第一进程持有，则将目标函数的逻辑代码中的进程创建语句，确定为产生无响应现象的故障点；其中，第二进程是第一进程的子进程；若目标资源被第一进程持有，则第二进程被阻塞；且当第二进程被阻塞的时长大于时长阈值时，无响应现象被触发。

首先可以从第二进程执行的代码片段中确定第二代码语句，该第二代码语句是指：在发生无响应现象之前，第二进程所执行的代码语句。由于在发生ANR之前，第二进程可能执行对应代码片段中的多条代码语句，一些代码语句可能并不适合采用后续的分析方式进行分析，因此，可以对第二代码语句进行判断确定该代码语句是否符合分析条件。具体地：

（1）当第二代码语句是用于实现数据读取操作的语句时，说明第二代码语句符合分析条件，可以对第二代码语句进行进一步地分析：第二代码语句执行数据读取操作时会对读取的数据进行上锁，即其他进程无法访问该数据，可以确定出第二进程执行数据读取操作所需的目标资源。该数据读取操作的语句例如可以是读取文件资源的代码语句，示例性地，第二进程执行readdir()函数以读取/proc/self/fd，其中，readdir()常用来遍历文件夹下的文件，/proc/self/fd表示当前进程目录中的文件描述符。

第二进程执行读取数据操作所需的目标资源可以是地址空间中的可用资源，例如CPU、内存等硬件资源。若目标资源被第一进程持有，说明第一进程持有第二进程读取数据所需的目标资源，而第一进程和第二进程之间的地址空间又共享，那么第二进程就会被阻塞并等待第一进程释放该目标资源，在第二进程被阻塞的时长大于时长阈值的时，例如第二进程被阻塞的时长为10s，而时长阈值为8s，被阻塞的时长大于时长阈值，就会产生无响应现象。基于上述分析，这是由于创建进程的方式所导致的，因此，可以将目标函数的逻辑代码中的进程创建语句确定为产生无响应现象的故障点。反之，若目标资源未被第一进程持有，说明第二进程可以使用目标资源，那么就不会产生无响应现象。

（2）当第二代码语句不是用于实现数据读取操作的语句时，则可以根据该第二代码语句所指示的具体内容，进行其他内容的分析。

可见，对于目标函数的分析是结合第二进程执行的代码片段实现的，对于第二进程执行的代码片段由于存在数据读取操作的语句，数据读取操作所需的目标资源被第一进程持有时，由于两个进程之间的地址空间共享，从而会触发目标应用的无响应现象，基于此逻辑，可以确定出产生无响应现象是由于目标函数的逻辑代码中的进程创建语句导致的，进而可以将其确定为故障点。

根据以上对产生无响应现象的故障点的确定方式的介绍，可以明确故障点包括第一进程所执行的代码片段的目标函数，具体是目标函数中的进程创建语句。因此，可以在操作系统中修改目标函数的实现，在一个实施例中，根据故障点对系统代码进行修复的方式可以采用如下S506至S507介绍的内容。

S506，确定用于创建子进程的目标语句。

创建子进程的目标语句是不同于进程创建语句的代码语句，虽然和进程创建语句有类似的功能，即都能创建子进程。但是，目标语句所创建的子进程与相应的父进程独立使用不同的地址空间。相应的父进程是调用目标语句所创建的子进程的进程，子进程与相应的父进程之间的地址空间不共享，这样，子进程在执行数据读取操作时，所需的目标资源不会被第一进程持有，而是在独立的地址空间中，从而可以有效避免应用的无响应现象的产生。

在一个实施例中，进程创建语句中包括函数字段，且函数字段存储第一系统调用函数，进程创建语句是通过第一系统调用函数创建子进程的。进程创建语句中包括的函数字段可存储第一系统调用函数，该第一系统调用函数可以由操作系统提供。在操作系统的系统代码中，进程创建语句可以通过第一系统调用函数创建子进程。举例来说，如前述的进程创建语句Volatile pid_t resultPid = vfork()，其中，函数字段为resultPid，vfork()为第一系统调用函数。

基于以上内容，S506的具体实现内容，包括：将进程创建语句中的函数字段中的第一系统调用函数，修改为第二系统调用函数，得到用于创建子进程的目标语句；其中，目标语句通过第二系统调用函数创建子进程。

第二系统调用函数是不同于第一系统调用函数的系统调用函数，也是由操作系统提供。在第二系统调用函数下，通过第二系统调用函数创建的子进程和对应的父进程之间的地址空间是相互独立的。由于系统调用函数是操作系统提供的一种内核函数，因此对系统调用函数的修改是从内核层面执行的修改，这样可以从系统内核层面解决操作系统上ANR的问题，能够提高平台的兼容性和稳定性，对ANR现象进行有效预防和规避。

S507，在系统代码中采用目标语句替换进程创建语句，以修复系统代码。

确定出目标语句之后，可以将原始的系统代码中的进程创建语句替换为目标语句，这样，可以禁掉第一系统调用函数，而改成第二系统调用函数，在内核层面实现对系统代码的修复，在第一进程为父进程，第二进程为子进程的情况下，通过目标语句创建的第二进程由于和第一进程独立使用不同的地址空间，基于修复后的系统代码运行目标应用时可顺利地利用目标资源进行数据读取操作，而不会发生阻塞，从而避免发生无响应现象。

举例来说，进程代码创建语句：Volatile pid_t resultPid = vfork()可以修改为目标语句：Volatilepid_tresultPid=fork()，if START_CHILD_USE_VFORK也可以修改为if START_CHILD_USE_FORK。从而实现禁掉vfork()，改成fork()的方式。

可以理解的是，鉴于操作系统的整体性，对目标函数中进程代码创建语句的修改，可能会影响操作系统的系统代码中除目标函数之外的其他部分代码，因此，对于系统代码的其他内容也可以进行适应性地修改，以适配以上的具体修复内容。通过以上方式可以修复系统代码并得到修复后的系统代码，基于修复后的系统代码运行目标应用。

可见，针对操作系统的系统代码的修复内容，是对系统代码定制化的修改内容，该修改内容涉及对内核的系统调用的更改，可以实现从内核侧以及系统侧对ANR可能发生的情况进行拦截，并应对绝大多数可能发生ANR的场景。此外，修改内容没有与特定平台强绑定的策略，也没有硬编码的部分，因此可以实现与设备或平台本身的松耦合，从而能够将修复后的操作系统应用于任意场景下，例如云游戏、真实的终端设备或者模拟器等等，可以有效规避应用无响应现象，提高平台或者设备的稳定性和兼容性。

在一种实现方式中，对于定制化修改的系统代码还可以：对修复后的系统代码进行质量检查。该质量检查包括：代码评审以及系统代码编写过程中的安全性检测。在编写代码过程中进行安全性检查可以发现定制化的系统代码中存在的安全性问题，保证修复后的系统代码安全性。代码评审（Code Review）也称代码复查，此处是指一种通过阅读代码来检查源代码与编码标准的符合性以及代码质量的操作，通过代码评审可以增进代码质量，找出潜在错误（bug）等。对于安全性检查以及代码评审均可以利用相应的分析工具来执行。这样，可以保证各项数据符合预期的情况，并在保证操作系统的兼容性和稳定性的前提下，解决应用无响应的问题。

通过上述修复方案进行处理，在云游戏场景下，基于运行修复后的代码运行云游戏的测试过程中以及实际的线上服务过程中，云游戏平台均未出现ANR的情况，从而可以减少ANR发生的频率。可以理解的是，由于云游戏平台是操作系统，属于系统侧，系统上会运行其他大量的游戏APP和其他APP，因此，可能还是会存在小部分ANR现象，但是概率极低。

本申请实施例所提供的数据处理方案，可以获取到目标应用的多种无响应现象的现场信息进行收集，由于现场信息是用于描述对应产生该无响应现象时系统代码的执行情况，通过对多种ANR的现场信息进行共性分析，可以从操作系统层面对系统代码的执行情况进行分析，从底层寻找产生各种无响应现象的共同特性，得到共性分析结果。此处共性分析结果包括共有的进程标识，基于共有的进程标识确定出共有的多个目标进程，并对各个目标进程执行的代码片段进行分析，具体可以通过调用栈跟进进程执行代码片段的情况，基于调用栈和其他代码片段的执行逻辑确定出更加具体的故障点，在此过程中，可以利用各种调试工具跟进和调试问题来确定故障点。基于故障点可以对操作系统进行定制化的改造，具体可以从内核层面修改进程创建时所调用的系统函数，从而有效解决应用无响应现象的发生，由于是对系统内核层面的修复来解决的操作系统的应用无响应的问题，可以显著地提高兼容性和稳定性。

请参见图7，图7是本申请实施例提供的一种数据处理装置的结构示意图。上述数据处理装置可以是运行于计算机设备中的一个计算机程序（包括程序代码），例如该数据处理装置为一个应用软件；该数据处理装置可以用于执行本申请实施例提供的方法中的相应步骤。如图7所示，该数据处理装置700可以包括以下至少一种：获取模块701、处理模块702。

获取模块701，用于获取目标应用的多种无响应现象中的各种无响应现象的现场信息，任一种无响应现象是在基于操作系统的系统代码运行目标应用的过程中产生的；且任一种无响应现象的现场信息用于描述：在产生相应的无响应现象时，系统代码的执行情况；

处理模块702，用于对各种无响应现象的现场信息进行共性分析，得到共性分析结果，并根据共性分析结果从系统代码中确定产生无响应现象的故障点；其中，所述共性分析结果包括：所述各种无响应现象的现场信息中的共有信息；

处理模块702，用于根据故障点对系统代码进行修复处理，以基于修复后的系统代码运行目标应用。

在一个实施例中，系统代码包括多个进程以及每个进程所执行的代码片段；任一种无响应现象的现场信息包括：在产生相应的无响应现象时，系统代码中被运行的各个进程的进程标识；处理模块702，具体用于：针对各种无响应现象的现场信息中的任一现场信息，遍历任一现场信息中的各个进程标识；在除任一现场信息以外的各个现场信息中，查找当前遍历的进程标识；若查找到当前遍历的进程标识，则将当前遍历的进程标识添加至共性分析结果中；若未查找到当前遍历的进程标识，则继续遍历任一现场信息中的各个进程标识。

在一个实施例中，共性分析结果包括：各种无响应现象的现场信息之间共有的进程标识；处理模块702，具体用于：基于共性分析结果中的各个进程标识确定M个目标进程，M的取值等于共性分析结果中的进程标识的数量；确定M个目标进程中的各个目标进程之间的关联关系，并从系统代码中获取各个目标进程所执行的代码片段；基于关联关系，从获取到的M个代码片段中确定产生无响应现象的故障点。

在一个实施例中，M个目标进程包括第一进程和第二进程；处理模块702，具体用于：从各种无响应现象的现场信息中，获取第一进程的属性信息以及第二进程的属性信息；任一进程的属性信息包括：任一进程的进程号以及调用任一进程的进程的进程号；若第二进程的属性信息中包括第一进程的进程号或者第一进程的属性信息中包括第二进程的进程号，则确定第一进程和第二进程之间的关联关系为父子关系。

在一个实施例中，M个目标进程包括第一进程和第二进程，且第一进程和第二进程之间的关联关系为父子关系；其中，第一进程是第二进程的父进程；处理模块702，具体还用于：基于父子关系，将获取到的第一进程所执行的代码片段确定为基准代码片段；并从基准代码片段中确定第一代码语句，第一代码语句是指：在发生无响应现象之前，第一进程所执行的代码语句；当第一代码语句是用于实现函数调用操作的语句时，在第一进程执行的代码片段中沿着第一代码语句分析出第一进程的调用栈，调用栈包括第一进程调用的各种函数；若调用栈中存在调用失败的目标函数，则从基准代码片段中确定目标函数的逻辑代码；基于第二进程所执行的代码片段，从目标函数的逻辑代码中确定产生无响应现象的故障点。

在一个实施例中，目标函数的逻辑代码中包括进程创建语句，进程创建语句是用于创建子进程的语句，且通过进程创建语句所创建的子进程与相应的父进程之间共享同一个地址空间；处理模块702，具体用于：从第二进程执行的代码片段中确定第二代码语句，第二代码语句是指：在发生无响应现象之前，第二进程所执行的代码语句；当第二代码语句是用于实现数据读取操作的语句时，根据第二代码语句确定第二进程执行数据读取操作所需的目标资源；若目标资源被第一进程持有，则将目标函数的逻辑代码中的进程创建语句，确定为产生无响应现象的故障点；其中，第二进程是第一进程的子进程；若目标资源被第一进程持有，则第二进程被阻塞；且当第二进程被阻塞的时长大于时长阈值时，无响应现象被触发。

在一个实施例中，处理模块702，具体用于：确定用于创建子进程的目标语句，目标语句所创建的子进程与相应的父进程独立使用不同的地址空间；在系统代码中采用目标语句替换进程创建语句，以修复系统代码。

在一个实施例中，进程创建语句中包括函数字段，且函数字段存储第一系统调用函数，进程创建语句是通过第一系统调用函数创建子进程的；处理模块702，具体用于：将进程创建语句中的函数字段中的第一系统调用函数，修改为第二系统调用函数，得到用于创建子进程的目标语句；其中，目标语句通过第二系统调用函数创建子进程。

在一个实施例中，目标应用的多种无响应现象包括服务类型的无响应现象；服务类型的无响应现象的产生过程包括：响应于目标应用的应用进程发送的服务创建请求，设置服务时长阈值；向服务进程发送服务创建消息，以使得服务进程基于服务创建消息，通知服务进程调用一个或多个其他进程执行服务创建工作，并在成功创建服务后返回反馈信息；若在服务时长阈值内未接收到服务进程返回的反馈信息，则产生服务类型的无响应现象。

在一个实施例中，目标应用的多种无响应现象包括广播类型的无响应现象；广播类型的无响应现象的产生过程包括：响应于目标应用的应用进程发起的发送广播请求，设置广播时长阈值；向广播接收进程发送广播注册消息，以使得广播接收进程基于广播注册消息，通知广播接收进程调用一个或多个其他进程执行广播工作，并在广播完成后返回反馈信息；若在广播时长阈值内未接收到广播接收进程返回的反馈信息，则产生广播类型的无响应现象。

在一个实施例中，目标应用的多种无响应现象包括内容提供类型的无响应现象；内容提供类型的无响应现象的产生过程包括：响应于目标应用的应用进程发起的获取内容提供对象的请求，检测内容提供对象所对应的内容提供进程的启动状态；若启动状态指示内容提供进程未启动，则创建内容提供进程，并通知内容提供进程调用一个或多个其他进程，安装内容提供对象，以及在安装内容提供对象后返回反馈信息，内容提供对象配置有一个安装时长阈值；若在安装时长阈值内未接收到内容提供进程返回的反馈信息，则产生内容提供类型的无响应现象。

在一个实施例中，目标应用的多种无响应现象包括输入事件分发类型的无响应现象；输入事件分发类型的无响应现象的产生过程包括：若接收到一个输入事件，则将当前接收到的输入事件添加至输入队列中，并唤醒输入分发线程，输入分发线程用于将输入队列中的各个输入事件依序分发给目标应用的应用进程进行处理；当当前接收到的输入事件的分发顺序到达时，目标应用的应用进程在处理其他的输入事件，则产生输入事件分发类型的无响应现象。

可以理解的是，本申请实施例所描述的数据处理装置的各功能模块的功能可根据上述方法实施例中的方法具体实现，其具体实现过程可以参照上述方法实施例的相关描述，此处不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

请参见图8，图8是本申请实施例提供的一种计算机设备的结构示意图。该计算机设备800可以包含独立设备（例如服务器、节点、终端等等中的一个或者多个），也可以包含独立设备内部的部件（例如芯片、软件模块或者硬件模块等）。该计算机设备800可以包括至少一个处理器801和通信接口802，进一步可选地，计算机设备800还可以包括至少一个存储器803和总线804。其中，处理器801、通信接口802和存储器803通过总线804相连。

其中，处理器801是进行算术运算和/或逻辑运算的模块，具体可以是中央处理器（central processing unit，CPU）、图片处理器（graphics processing unit，GPU）、微处理器（microprocessor unit，MPU）、专用集成电路（Application SpecificIntegratedCircuit，ASIC）、现场可编程逻辑门阵列（Field Programmable Gate Array，FPGA）、复杂可编程逻辑器件（Complex programmable logic device，CPLD）、协处理器（协助中央处理器完成相应处理和应用）、微控制单元（Microcontroller Unit，MCU）等处理模块中的一种或者多种的组合。

通信接口802可以用于为至少一个处理器提供信息输入或者输出。和/或，通信接口802可以用于接收外部发送的数据和/或向外部发送数据，可以为包括诸如以太网电缆等的有线链路接口，也可以是无线链路（Wi-Fi、蓝牙、通用无线传输、车载短距通信技术以及其他短距无线通信技术等）接口。通信接口802可以作为网络接口。

存储器803用于提供存储空间，存储空间中可以存储操作系统和计算机程序等数据。存储器803可以是随机存储记忆体（random access memory，RAM）、只读存储器（read-only memory，ROM）、可擦除可编程只读存储器（erasable programmable read onlymemory，EPROM）、或便携式只读存储器（compact disc read-only memory，CD-ROM）等等中的一种或者多种的组合。

该计算机设备800中的至少一个处理器801用于调用至少一个存储器803中存储的计算机程序，用于执行本申请所示的实施例所描述的数据处理方法。

在一种可能的实施方式中，该计算机设备800中的处理器801用于调用至少一个存储器803中存储的计算机程序，用于执行以下操作：

在一个实施例中，处理器801，具体用于：获取目标应用的多种无响应现象中的各种无响应现象的现场信息，任一种无响应现象是在基于操作系统的系统代码运行目标应用的过程中产生的；且任一种无响应现象的现场信息用于描述：在产生相应的无响应现象时，系统代码的执行情况；对各种无响应现象的现场信息进行共性分析，得到共性分析结果，并根据共性分析结果从系统代码中确定产生无响应现象的故障点；根据故障点对系统代码进行修复处理，以基于修复后的系统代码运行目标应用；其中，所述共性分析结果包括：所述各种无响应现象的现场信息中的共有信息。

在一个实施例中，系统代码包括多个进程以及每个进程所执行的代码片段；任一种无响应现象的现场信息包括：在产生相应的无响应现象时，系统代码中被运行的各个进程的进程标识；处理器801，具体用于：针对各种无响应现象的现场信息中的任一现场信息，遍历任一现场信息中的各个进程标识；在除任一现场信息以外的各个现场信息中，查找当前遍历的进程标识；若查找到当前遍历的进程标识，则将当前遍历的进程标识添加至共性分析结果中；若未查找到当前遍历的进程标识，则继续遍历任一现场信息中的各个进程标识。

在一个实施例中，共性分析结果包括：各种无响应现象的现场信息之间共有的进程标识；处理器801，具体用于：基于共性分析结果中的各个进程标识确定M个目标进程，M的取值等于共性分析结果中的进程标识的数量；确定M个目标进程中的各个目标进程之间的关联关系，并从系统代码中获取各个目标进程所执行的代码片段；基于关联关系，从获取到的M个代码片段中确定产生无响应现象的故障点。

在一个实施例中，M个目标进程包括第一进程和第二进程；处理器801，具体用于：从各种无响应现象的现场信息中，获取第一进程的属性信息以及第二进程的属性信息；任一进程的属性信息包括：任一进程的进程号以及调用任一进程的进程的进程号；若第二进程的属性信息中包括第一进程的进程号或者第一进程的属性信息中包括第二进程的进程号，则确定第一进程和第二进程之间的关联关系为父子关系。

在一个实施例中，M个目标进程包括第一进程和第二进程，且第一进程和第二进程之间的关联关系为父子关系；其中，第一进程是第二进程的父进程；处理器801，具体还用于：基于父子关系，将获取到的第一进程所执行的代码片段确定为基准代码片段；并从基准代码片段中确定第一代码语句，第一代码语句是指：在发生无响应现象之前，第一进程所执行的代码语句；当第一代码语句是用于实现函数调用操作的语句时，在第一进程执行的代码片段中沿着第一代码语句分析出第一进程的调用栈，调用栈包括第一进程调用的各种函数；若调用栈中存在调用失败的目标函数，则从基准代码片段中确定目标函数的逻辑代码；基于第二进程所执行的代码片段，从目标函数的逻辑代码中确定产生无响应现象的故障点。

在一个实施例中，目标函数的逻辑代码中包括进程创建语句，进程创建语句是用于创建子进程的语句，且通过进程创建语句所创建的子进程与相应的父进程之间共享同一个地址空间；处理器801，具体用于：从第二进程执行的代码片段中确定第二代码语句，第二代码语句是指：在发生无响应现象之前，第二进程所执行的代码语句；当第二代码语句是用于实现数据读取操作的语句时，根据第二代码语句确定第二进程执行数据读取操作所需的目标资源；若目标资源被第一进程持有，则将目标函数的逻辑代码中的进程创建语句，确定为产生无响应现象的故障点；其中，第二进程是第一进程的子进程；若目标资源被第一进程持有，则第二进程被阻塞；且当第二进程被阻塞的时长大于时长阈值时，无响应现象被触发。

在一个实施例中，处理器801，具体用于：确定用于创建子进程的目标语句，目标语句所创建的子进程与相应的父进程独立使用不同的地址空间；在系统代码中采用目标语句替换进程创建语句，以修复系统代码。

在一个实施例中，进程创建语句中包括函数字段，且函数字段存储第一系统调用函数，进程创建语句是通过第一系统调用函数创建子进程的；处理器801，具体用于：将进程创建语句中的函数字段中的第一系统调用函数，修改为第二系统调用函数，得到用于创建子进程的目标语句；其中，目标语句通过第二系统调用函数创建子进程。

在一个实施例中，目标应用的多种无响应现象包括服务类型的无响应现象；服务类型的无响应现象的产生过程包括：响应于目标应用的应用进程发送的服务创建请求，设置服务时长阈值；向服务进程发送服务创建消息，以使得服务进程基于服务创建消息，通知服务进程调用一个或多个其他进程执行服务创建工作，并在成功创建服务后返回反馈信息；若在服务时长阈值内未接收到服务进程返回的反馈信息，则产生服务类型的无响应现象。

在一个实施例中，目标应用的多种无响应现象包括广播类型的无响应现象；广播类型的无响应现象的产生过程包括：响应于目标应用的应用进程发起的发送广播请求，设置广播时长阈值；向广播接收进程发送广播注册消息，以使得广播接收进程基于广播注册消息，通知广播接收进程调用一个或多个其他进程执行广播工作，并在广播完成后返回反馈信息；若在广播时长阈值内未接收到广播接收进程返回的反馈信息，则产生广播类型的无响应现象。

在一个实施例中，目标应用的多种无响应现象包括内容提供类型的无响应现象；内容提供类型的无响应现象的产生过程包括：响应于目标应用的应用进程发起的获取内容提供对象的请求，检测内容提供对象所对应的内容提供进程的启动状态；若启动状态指示内容提供进程未启动，则创建内容提供进程，并通知内容提供进程调用一个或多个其他进程，安装内容提供对象，以及在安装内容提供对象后返回反馈信息，内容提供对象配置有一个安装时长阈值；若在安装时长阈值内未接收到内容提供进程返回的反馈信息，则产生内容提供类型的无响应现象。

在一个实施例中，目标应用的多种无响应现象包括输入事件分发类型的无响应现象；输入事件分发类型的无响应现象的产生过程包括：若接收到一个输入事件，则将当前接收到的输入事件添加至输入队列中，并唤醒输入分发线程，输入分发线程用于将输入队列中的各个输入事件依序分发给目标应用的应用进程进行处理；当当前接收到的输入事件的分发顺序到达时，目标应用的应用进程在处理其他的输入事件，则产生输入事件分发类型的无响应现象。

应当理解，本申请实施例中所描述的计算机设备800可执行前文所对应实施例中对该数据处理方法的描述，也可执行前文图7所对应实施例中对该数据处理装置700的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

此外，还应指出，本申请一个示例性实施例还提供了一种存储介质，该存储介质中存储了前述数据处理方法的计算机程序，该计算机程序包括程序指令，当一个或多个处理器加载并执行该程序指令，可以实现实施例中对数据处理方法的描述，这里不再赘述，对采用相同方法的有益效果描述，也在此不再赘述。可以理解的是，程序指令可以被部署在一个或能够互相通信的多个计算机设备上执行。

上述计算机可读存储介质可以是前述任一实施例提供的数据处理装置或者上述计算机设备的内部存储单元，例如计算机设备的硬盘或内存。该计算机可读存储介质也可以是该计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡（smart media card，SMC），安全数字（secure digital，SD）卡，闪存卡（flash card）等。进一步地，该计算机可读存储介质还可以既包括该计算机设备的内部存储单元也包括外部存储设备。该计算机可读存储介质用于存储该计算机程序以及该计算机设备所需的其他程序和数据。该计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。

本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例中一方面提供的方法。

本申请的一个方面，提供了另一种计算机程序产品，该计算机程序产品包括计算机程序或计算机指令，该计算机程序或计算机指令被处理器执行时实现本申请实施例提供的数据处理方法的步骤。

本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。

以上所揭露的仅为本申请的部分实施例而已，当然不能以此来限定本申请之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本申请权利要求所作的等同变化，仍属于发明所涵盖的范围。

Claims (15)

1.一种数据处理方法，其特征在于，所述方法包括：

获取目标应用的多种无响应现象中的各种无响应现象的现场信息，任一种无响应现象是在基于操作系统的系统代码运行所述目标应用的过程中产生的；且任一种无响应现象的现场信息用于描述：在产生相应的无响应现象时，所述系统代码的执行情况；

对所述各种无响应现象的现场信息进行共性分析，得到共性分析结果，并根据所述共性分析结果从所述系统代码中确定产生无响应现象的故障点；其中，所述共性分析结果包括：所述各种无响应现象的现场信息中的共有信息；

根据所述故障点对所述系统代码进行修复处理，以基于修复后的系统代码运行所述目标应用。

2.如权利要求1所述的方法，其特征在于，所述系统代码包括多个进程以及每个进程所执行的代码片段；所述任一种无响应现象的现场信息包括：在产生相应的无响应现象时，所述系统代码中被运行的各个进程的进程标识；

所述对所述各种无响应现象的现场信息进行共性分析，得到共性分析结果，包括：

针对所述各种无响应现象的现场信息中的任一现场信息，遍历所述任一现场信息中的各个进程标识；

在除所述任一现场信息以外的各个现场信息中，查找当前遍历的进程标识；

若查找到所述当前遍历的进程标识，则将所述当前遍历的进程标识添加至共性分析结果中；

若未查找到所述当前遍历的进程标识，则继续遍历所述任一现场信息中的各个进程标识。

3.如权利要求1或2所述的方法，其特征在于，所述共性分析结果包括：所述各种无响应现象的现场信息之间共有的进程标识；所述根据所述共性分析结果从所述系统代码中确定产生无响应现象的故障点，包括：

基于所述共性分析结果中的各个进程标识确定M个目标进程，M的取值等于所述共性分析结果中的进程标识的数量；

确定所述M个目标进程中的各个目标进程之间的关联关系，并从所述系统代码中获取所述各个目标进程所执行的代码片段；

基于所述关联关系，从获取到的M个代码片段中确定产生无响应现象的故障点。

4.如权利要求3所述的方法，其特征在于，所述M个目标进程包括第一进程和第二进程；所述确定所述M个目标进程中的各个目标进程之间的关联关系，包括：

从所述各种无响应现象的现场信息中，获取所述第一进程的属性信息以及所述第二进程的属性信息；任一进程的属性信息包括：所述任一进程的进程号以及调用所述任一进程的进程号；

若所述第二进程的属性信息中包括所述第一进程的进程号或者所述第一进程的属性信息中包括所述第二进程的进程号，则确定所述第一进程和所述第二进程之间的关联关系为父子关系。

5.如权利要求3所述的方法，其特征在于，所述M个目标进程包括第一进程和第二进程，且所述第一进程和所述第二进程之间的关联关系为父子关系；其中，所述第一进程是所述第二进程的父进程；

所述基于所述关联关系，从获取到的M个代码片段中确定产生无响应现象的故障点，包括：

基于所述父子关系，将获取到的第一进程所执行的代码片段确定为基准代码片段；并从所述基准代码片段中确定第一代码语句，所述第一代码语句是指：在发生无响应现象之前，所述第一进程所执行的代码语句；

当所述第一代码语句是用于实现函数调用操作的语句时，在所述第一进程执行的代码片段中沿着第一代码语句分析出所述第一进程的调用栈，所述调用栈包括所述第一进程调用的各种函数；

若所述调用栈中存在调用失败的目标函数，则从所述基准代码片段中确定所述目标函数的逻辑代码；基于所述第二进程所执行的代码片段，从所述目标函数的逻辑代码中确定产生无响应现象的故障点。

6.如权利要求5所述的方法，其特征在于，所述目标函数的逻辑代码中包括进程创建语句，所述进程创建语句是用于创建子进程的语句，且通过所述进程创建语句所创建的子进程与相应的父进程之间共享同一个地址空间；

所述基于所述第二进程所执行的代码片段，从所述目标函数的逻辑代码中确定产生无响应现象的故障点，包括：

从所述第二进程执行的代码片段中确定第二代码语句，所述第二代码语句是指：在发生无响应现象之前，所述第二进程所执行的代码语句；

当所述第二代码语句是用于实现数据读取操作的语句时，根据所述第二代码语句确定所述第二进程执行数据读取操作所需的目标资源；

若所述目标资源被所述第一进程持有，则将所述目标函数的逻辑代码中的进程创建语句，确定为产生无响应现象的故障点；

其中，所述第二进程是所述第一进程的子进程；若所述目标资源被所述第一进程持有，则所述第二进程被阻塞；且当所述第二进程被阻塞的时长大于时长阈值时，无响应现象被触发。

7.如权利要求6所述的方法，其特征在于，所述根据所述故障点对所述系统代码进行修复处理，包括：

确定用于创建子进程的目标语句，所述目标语句所创建的子进程与相应的父进程独立使用不同的地址空间；

在所述系统代码中采用所述目标语句替换所述进程创建语句，以修复所述系统代码。

8.如权利要求7所述的方法，其特征在于，所述进程创建语句中包括函数字段，且所述函数字段存储第一系统调用函数，所述进程创建语句是通过所述第一系统调用函数创建子进程的；

所述确定用于创建子进程的目标语句，包括：

将所述进程创建语句中的函数字段中的第一系统调用函数，修改为第二系统调用函数，得到用于创建子进程的目标语句；

其中，所述目标语句通过所述第二系统调用函数创建子进程。

9.如权利要求1所述的方法，其特征在于，所述目标应用的多种无响应现象包括服务类型的无响应现象；所述服务类型的无响应现象的产生过程包括：

响应于目标应用的应用进程发送的服务创建请求，设置服务时长阈值；

向服务进程发送服务创建消息，以使得所述服务进程基于所述服务创建消息，通知所述服务进程调用一个或多个其他进程执行服务创建工作，并在成功创建服务后返回反馈信息；

若在所述服务时长阈值内未接收到所述服务进程返回的反馈信息，则产生所述服务类型的无响应现象。

10.如权利要求1所述的方法，其特征在于，所述目标应用的多种无响应现象包括广播类型的无响应现象；所述广播类型的无响应现象的产生过程包括：

响应于目标应用的应用进程发起的发送广播请求，设置广播时长阈值；

向广播接收进程发送广播注册消息，以使得所述广播接收进程基于所述广播注册消息，通知所述广播接收进程调用一个或多个其他进程执行广播工作，并在广播完成后返回反馈信息；

若在所述广播时长阈值内未接收到所述广播接收进程返回的反馈信息，则产生所述广播类型的无响应现象。

11.如权利要求1所述的方法，其特征在于，所述目标应用的多种无响应现象包括内容提供类型的无响应现象；所述内容提供类型的无响应现象的产生过程包括：

响应于目标应用的应用进程发起的获取内容提供对象的请求，检测所述内容提供对象所对应的内容提供进程的启动状态；

若所述启动状态指示所述内容提供进程未启动，则创建所述内容提供进程，并通知所述内容提供进程调用一个或多个其他进程，安装所述内容提供对象，以及在安装所述内容提供对象后返回反馈信息，所述内容提供对象配置有一个安装时长阈值；

若在所述安装时长阈值内未接收到所述内容提供进程返回的反馈信息，则产生所述内容提供类型的无响应现象。

12.如权利要求1所述的方法，其特征在于，所述目标应用的多种无响应现象包括输入事件分发类型的无响应现象；所述输入事件分发类型的无响应现象的产生过程包括：

若接收到一个输入事件，则将当前接收到的输入事件添加至输入队列中，并唤醒输入分发线程，所述输入分发线程用于将所述输入队列中的各个输入事件依序分发给所述目标应用的应用进程进行处理；

当所述当前接收到的输入事件的分发顺序到达时，所述目标应用的应用进程在处理其他的输入事件，则产生所述输入事件分发类型的无响应现象。

13.一种数据处理装置，其特征在于，包括：

获取模块，用于获取目标应用的多种无响应现象中的各种无响应现象的现场信息，任一种无响应现象是在基于操作系统的系统代码运行所述目标应用的过程中产生的；且任一种无响应现象的现场信息用于描述：在产生相应的无响应现象时，所述系统代码的执行情况；

处理模块，用于对所述各种无响应现象的现场信息进行共性分析，得到共性分析结果，并根据所述共性分析结果从所述系统代码中确定产生无响应现象的故障点；其中，所述共性分析结果包括：所述各种无响应现象的现场信息中的共有信息；

所述处理模块，用于根据所述故障点对所述系统代码进行修复处理，以基于修复后的系统代码运行所述目标应用。

14.一种计算机设备，其特征在于，包括：处理器、存储器以及网络接口；

所述处理器与所述存储器、所述网络接口相连，其中，所述网络接口用于提供网络通信功能，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行权利要求1-12中任一项所述的数据处理方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时，执行权利要求1-12中任一项所述的数据处理方法。

Images