CN104503918A - 异常信息的处理方法及装置 - Google Patents

Abstract

本发明公开了一种异常信息的处理方法及装置。其中，该方法包括：采集应用程序运行过程中出现的异常信息，其中，应用程序运行于Android系统，在应用程序的线程中注册有未处理异常的处理类；通过未处理异常处理类将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块，其中，多个匹配处理模块预先定义对应的编程用户的异常模式信息；在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将异常信息发送至异常信息对应的编程用户进行处理。本发明解决了现有技术中Android应用程序发生异常时，要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。

Description

异常信息的处理方法及装置

技术领域

本发明涉及计算机软件领域，具体而言，涉及一种异常信息的处理方法及装置。

背景技术

在应用程序(APP)的开发过程中，APP开发人员会使用到软件开发包(SDK)，比如在开发Android APP的时候，SDK的开发人员会提供Android SDK给APP开发人员使用，从而完成Android APP的开发。Android APP在运行的过程中偶尔会意外崩溃即发生异常，那么就需要开发人员对上述异常问题进行分析和解决。

这里需要说明的是，在Android APP出现异常时，无法区分上述异常是源于软件开发包(SDK)还是APP本身，现有技术要将异常信息同时发送给软件开发包(SDK)的开发人员和APP开发人员，而SDK的开发人员和APP开发人员需要同时对上述异常信息进行分析从而解决问题(尽管上述异常的发生可能与其中一方无关)，导致了在解决异常问题时耗时长、APP开发人员和SDK开发人员容易对某些问题产生分歧、对异常信息的解决效率低的问题。

针对现有技术中Android应用程序发生异常时，要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。

发明内容

本发明的主要目的在于提供一种异常信息的处理方法及装置，以解决现有技术中Android应用程序发生异常时，要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。

为了实现上述目的，根据本发明实施例的一个方面，提供了一种异常信息的处理方法，该方法包括：采集应用程序运行过程中出现的异常信息，其中，应用程序运行于Android系统，在应用程序的线程中注册有未处理异常的处理类；通过未处理异常处理类将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块，其中，多个匹配处理模块预先定义对应的编程用户的异常模式信息；在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将异常信息发送至异常信息对应的编程用户进行处理。

为了实现上述目的，根据本发明实施例的另一方面，提供了一种异常信息的处理装置，该装置包括：采集模块，用于采集应用程序运行过程中出现的异常信息，其中，应用程序运行于Android系统，在应用程序的线程中注册有未处理异常的处理类；分发模块，用于通过未处理异常处理类将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块，其中，多个匹配处理模块预先定义对应的编程用户的异常模式信息；处理模块，用于在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将异常信息发送至异常信息对应的编程用户进行处理。

在本发明实施例中，采用采集应用程序运行过程中出现的异常信息，其中，应用程序运行于Android系统，在应用程序的线程中注册有未处理异常的处理类；通过未处理异常处理类将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块，其中，多个匹配处理模块预先定义对应的编程用户的异常模式信息；在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将异常信息发送至异常信息对应的编程用户进行处理，解决了现有技术中Android应用程序发生异常时，要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。

附图说明

构成本申请的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例一的一种异常信息的处理方法的流程图；以及

图2是根据本发明实施例二的一种异常信息的处理装置的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例一

本发明实施例提供了一种异常信息的处理方法。该方法包括步骤如下：

步骤S12，采集应用程序运行过程中出现的异常信息，其中，应用程序运行于Android系统，在应用程序的线程中注册有未处理异常的处理类。

这里需要说明的是，在一种优选的实施例中，本方案可以适用于运行在Android操作系统中的应用程序的场景，具体的，在Android操作系统中应用程序运行的过程中，可以调用未处理异常的处理类，并将未处理异常的处理类注册至应用程序的线程中。可选的，可以利用Android API注册全局的未处理异常的处理类，部分实现代码如下：

Thread.setDefaultUncaughtExceptionHandler(CrashHandler)；

具体的，在本方案中，上述线程在发生未捕获异常后会主动调用CrashHandler的uncaughtException函数，这样就是实现了异常信息的采集工作。

步骤S14，通过未处理异常处理类将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块，其中，多个匹配处理模块预先定义对应的编程用户的异常模式信息。

具体的，在本方案中，可以通过上述全局未处理异常的处理类来将上述异常信息同时分发至多个匹配处理模块，可选的，在上述多个匹配处理模块中预先定义异常模式信息具体为，每个编程用户可能发生何种异常，例如：在匹配处理模块A中预先定义的是编程用户01的原因导致的应用程序发生的异常信息，在匹配处理模块B中预先定义的是编程用户02的原因导致的应用程序发生的异常信息。

在一种可选的实施例中，上述编程用户01为Android SDK的开发人员，上述编程用户02为Android APP的开发人员。

步骤S16，在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将异常信息发送至异常信息对应的编程用户进行处理。

具体的，在本方案中，在将上述异常信息发送至多个匹配处理模块时，可以将上述异常信息和上述多个匹配处理模块中的异常模式信息进行匹配，以上述编程用户01为Android SDK的开发人员为例，如果，匹配处理模块A中的信息与上述异常信息相匹配的话，则说明，上述异常信息为Android SDK的开发人员的原因导致的，在本方案中的一种可选的实施例中，可以将上述异常信息发送至编程用户01，即发送至Android SDK的开发人员进行处理。

此处需要说明的是，在本方案中，不但可以初步区分异常原因是出自Android SDK的开发人员或Android APP的开发人员，在本方案提供的又一种可选的实施例中，在确定具体的异常类型后，例如异常的原因出自Android SDK的开发团队后，还可以通过本申请提供的方案将异常信息进行进一步的判断，从而将异常信息发送至具体的某一个Android SDK的开发人员。

基于上述对异常信息的处理方法，可以实现当应用程序发生异常时，通过本方案可以自动分辨该异常是由于哪个具体的编程用户的原因造成的，从而将上述异常信息发送给相关的软件开发人员，可以提高应用程序异常处理的效率，从而解决了现有技术中Android应用程序发生异常时，要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。

可选的，步骤S14，通过未处理异常处理类将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块的步骤可以包括：

步骤S141，在未处理异常的处理类中调用分发功能函数，通过分发功能函数将异常信息分发至多个匹配处理模块。

具体的，在本方案中，可以在未处理异常的处理类中的uncaughtExption方法中调用主题类中的notify功能函数即notify方法，通过上述notify方法将异常信息分发至多个匹配处理模块。

可选的，实现上述功能的部分代码如下；

public void uncaughtException(Thread thread,Throwable ex){

uncaughtExceptionSubject.Notify(ex)

}

结合上述代码，在本方案中，可以调用上述uncaughtException方法中的Notify功能函数来实现上述异常信息的分发。

可选的，上述分发类在本方案中可以为全局异常主题类UncaughtExceptionSubjectImpl，上述全局异常主题类为IUncaughtExceptionSubject接口的具体实现类，上述IUncaughtExceptionSubject接口为全局异常的主题接口，在上述主题接口中定义了上述notify方法。

在一种可选的实施例中，可以采用观察者模式的方式完成异常信息的分发与处理。这里，观察者模式为软件设计模式之一，分为主题和观察者，观察者订阅主题，当主题发生变化时通知相应的观察者。具体的，首先，定义全局异常的主题接口IUncaughtExceptionSubject，在该主题接口定义有notify方法，而UncaughtExceptionSubjectImpl为对主题接口IUncaughtExceptionSubject的具体实现类即全局异常主题类。关于上述创建主题接口和主题类的部分代码如下：

IUncaughtExceptionSubject uncaughtExceptionSubject＝newUncaughtExceptionSubjectImpl()；

然后，定义全局异常的处理接口IUncaughtExceptionobserver，即观察者接口，通过该接口，开发人员可以实现自己的全局异常处理，比如，检查当前的异常是否是自己的代码问题引起的。而IUncaughtExceptionobserverImpl为对接口的具体实现类即观察者类。关于上述创建观察者接口和观察者类的部分代码如下：

IUncaughtExceptionObserver uncaughtExceptionObserver＝newUncaughtExceptionObserverImpl()；

这里需要说明的是，上述步骤S14中多个匹配处理模块的功能可以通过上述观察者接口和观察者类来实现，即当异常发生时，可以调用上述主题接口中的notify方法来将异常信息通知给相关观察者，相关观察者则负责对上述异常信息进行进一步的处理。

可选的，步骤S16在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将异常信息发送至异常信息对应的编程用户进行处理的步骤包括：

S161，提取异常信息中的异常特征，其中，异常特征包括如下至少一个：异常包特征、异常类名称、异常函数名称。

可选的，上述异常包特征、异常类名称、异常函数名称可以为：PackageName＝”X”,ClassName＝”Y”,Method＝”Z”。

S162，将异常特征同多个匹配处理模块中的预先定义的异常模式信息进行匹配。

S163，在与第一匹配处理模块中的预先定义的异常模式信息匹配成功的情况下，将异常信息发送至第一匹配处理模块对应的编程用户。

具体的，由于在每个匹配处理模块中都分别预先存储了不同的异常模式信息，例如，在匹配处理模块A中预先定义的是编程用户01的原因导致的应用程序发生的异常模式信息，匹配处理模块A中的异常模式信息也包括：异常包特征、异常类名称以及异常函数名称，观察者类接收通过主题接口发送的异常信息进行提取，提取出实际发生异常的异常参数，即异常包特征、异常类名称以及异常函数名称，将上述实际发送的异常参数同匹配模处理块中预先定义的异常参数即上述异常模式信息进行匹配，如果匹配成功的话，说明上述应用程序发生的异常即为编程用户01的问题所造成。

在一种可选的实施例中，上述匹配处理模块的提取、匹配功能可通过如下方式实现，即通过调用上述观察者类中的HandleUncaughtException(Throwable)方法中检测提取异常的相关信息，如：在异常的堆栈中提取异常包名称，异常类名称，异常函数名称，根据这些信息判断相关信息是否与当前观察者定义的模式匹配，如果匹配，相关观察者实现类将该信息发送给相应的编程用户。

这里需要说明的是，上述HandleUncaughtException方法的实现还可以通过相关SDK或者APP中定义的预设命名规则加以鉴别匹配，例如：SDK实现了预设的命名空间命名或者预设的类命名规则或者预设的函数命名规则。

可选的，上述分发记录包括多个匹配处理模块的地址，上述未处理异常处理类依照上述地址将异常信息分发至不同的匹配处理模块，即发送至不同的观察者类。

步骤S163，在与第一匹配处理模块中的预先定义的异常模式信息匹配成功的情况下，将异常信息发送至第一匹配处理模块对应的编程用户之后，本发明实施例可以提供如下两个方案：

方案一：

将任意一条新的匹配处理模块的地址增加至分发记录，形成新的分发记录，使得未处理异常处理类将应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。

具体的，在一种可选的实施例中，在上述主题接口中还可以定义Add方法，通过调用该方法，一个IUncaughtExceptionObserver观察者可以实现对上述主题的订阅，即当异常信息发生时，调用主题类中的notify方法将异常信息发送至该观察者，所以在本方案中可以通过调用上述Add方法对上述分发记录中增加一条新的匹配处理模块的地址，上述新的匹配处理模块中预先定义有新的编程用户可能造成的异常的异常模式信息，当新的异常发生时，则本方案将异常信息同样发送至新的匹配处理模块，以便将异常信息发送至相应的编程用户。例如，在本方案的上述例子中，应用程序的开发人员主要分为Android SDK开发人员和Android APP的开发人员，当然一个应用程序可以由新的开发团队加入，当新的开发团队加入时，则可以调用上述Add方法增加一个新的匹配处理模块的地址。

方案二：

将分发记录任意一条匹配处理模块的地址移除，形成新的分发记录，使得未处理异常处理类将应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。

具体的，在一种可选的实施例中，在上述主题接口中还可以定义Remove方法，通过调用该方法，一个IUncaughtExceptionObserver观察者可以实现对上述主题的退阅，即当异常信息发生时，则不将上述异常信息发送至该观察者，所以在本方案中可以通过调用上述Remove方法对上述分发记录中移除一条新的匹配处理模块的地址，当新的异常发生时，则本方案不将异常信息同样发送至该匹配处理模块。例如，在本方案的上述例子中，应用程序的开发人员主要分为Android SDK开发人员和AndroidAPP的开发人员，如果提前确认上述Android SDK的开发人员提供的开发包不可能使应用程序出现异常时，则可以调用上述Remove方法移除该Android SDK对应的匹配处理模块的地址。

下面本方案结合具体应用场景详细描述：

首先，本发明技术方案的技术原理为首先实现一个异常处理与分发的接口，该接口实现设计模式中的主题方面的接口，观察者类实现观察者模式中观察者方面的接口，当异常发生时，主题类通知该观察者类，本申请利用了观察者模式中的分发和处理的解耦，方便以后扩展。

其次，本发明技术方案的整体思路为利用Android API注册全局的未处理异常的处理类，通过该类的uncaughtException函数分发异常信息，接着，通过异常处理的类实现异常的特征的提取与匹配，如匹配将相关信息发送到自己。这里需要说明的是，未处理异常的处理类即上述主题类，异常处理的类即上述观察者类。

具体的，为实现上述功能，在本方案中创建了主题接口，主题类、观察者接口和观察者类，上述类和接口的具体解释如下：

主题接口：IUncaughtExceptionSubject，可以通过调用这个接口的Add或者Remove方法，一个IUncaughtExceptionObserver观察者接口可以实现对该主题的订阅和退阅，同时当异常发生时IUncaughtExceptionSubject接口通过调用Notify通知相关观察者。

在主题接口中定义了三个方法如下：

Add(IUncaughtExceptionObserver)：该接口方法接受一个IUncaughtExceptionSubject参数，表示全局异常处理接口这个接口的订阅。

Remove(IUncaughtExceptionObservr)；该接口方法接受一个IUncaughtExceptionSubject参数，表示全局异常处理接口这个接口的退阅。

Notify(Throwable)：这个接口方法接受一个异常类参数，通过调用该方法将这个异常类通知到所有订阅全局异常主题的订阅者。

主题实现类UncaughtExceptionSubjectImpl：这是一个对上述IUncaughtExceptionSubject接口的具体实现类。

观察者接口：全局异常的处理接口，通过实现该接口，开发人员就可以实现自己的全局异常处理(例如，检查当前的异常是否是自己的代码引起的等)。

在上述观察者接口中定义了如下方法：(bool)HandleUncaughtException(Throwable)。

观察者实现类UncaughtExceptionObserverImpl：是一个对上述IUncaughtExceptionObserver接口的具体实现类。

可选的，结合部分代码描述本方案：

在Android APP启动时调用如下方法：

//这是Android机器中注册全局异常的方法，参数CrashHandler是一个继承自UncaughtExceptionHandler的我们自己实现的类

Thread.setDefaultUncaughtExceptionHandler(CrashHandler)；

//这是我们实现的全局异常主题类

IUncaughtExceptionSubject uncaughtExceptionSubject＝newUncaughtExceptionSubjectImpl()；

//这是我们实现的可以对全局异常进行订阅的订阅者类

IUncaughtExceptionObserver uncaughtExceptionObserver＝newUncaughtExceptionObserverImpl()；

//通过调用全局异常主题类的Add方法，uncaughtExceptionObserver订阅者//类订阅了uncaughtExceptionSubject这个主题。

uncaughtExceptionSubject.Add(uncaughtExceptionObserver)

其中，上述CrashHandler是一个继承自UncaughtExceptionHandler的类，覆盖如下方法：

Override

public void uncaughtException(Thread thread,Throwable ex){

uncaughtExceptionSubject.Notify(ex)

}

通过uncaughtException方法，调用uncaughtExceptionSubject全局异常主题的Notify方法通知注册该主题的所有订阅者。

其中UncaughtExceptionObserverImpl是一个具体的全局异常的订阅者，实现思路如下：在HandleUncaughtException(Throwable)方法中检测提取异常的相关信息，如：在异常的堆栈中提取异常包名称，异常类名称，异常函数名称，根据这些信息判断相关信息是否与当前观察者定义的模式匹配，如果匹配相关观察者类实现者将该信息发送给自己。

本申请提供的方案的关键点在于，在全局的未捕获异常处理器中处理相关异常。通过观察者模式跟踪异常发生的相关情况。在观察者中提取相关特征并匹配。匹配成功则通知相关负责人。

这里需要说明的是，本文中所提到的相关负责人可以为软件的开发人员、软件的编程用户，也即本文中的观察者。

综上，本申请提供的方案优点如下：

(1)因为本方案能把不同开发人员开发的代码的异常分发给相关开发人员，所以避免了大家一起对某个异常同时关注而造成的时间损耗，提高了效率。

(2)提高了SDK开发人员发现问题与解决问题的效率。

(3)提高了APP开发人员发现问题与解决问题的效率。

实施例二

采集模块22，用于采集应用程序运行过程中出现的异常信息，其中，应用程序运行于Android系统，在应用程序的线程中注册有未处理异常的处理类。

这里需要说明的是，在一种优选的实施例中，本方案可以适用与运行在Android操作系统中的应用程序，具体的，在Android操作系统中应用程序运行的过程中，可以调用未处理异常的处理类，并将未处理异常的处理类注册至应用程序的线程中。可选的，可以利用Android API注册全局的未处理异常的处理类，部分实现代码如下：

Thread.setDefaultUncaughtExceptionHandler(CrashHandler)；

具体的，在本方案中，线程在发生未捕获异常后会主动调用CrashHandler的uncaughtException函数，这样就是实现了异常信息的采集工作。

分发模块24，用于通过未处理异常处理类将应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块，其中，多个匹配处理模块预先定义对应的编程用户的异常模式信息。

具体的，在分发模块24中，可以通过上述全局未处理异常的处理类来将上述异常信息同时分发至多个匹配处理模块，可选的，在上述多个匹配处理模块中预先定义异常模式信息具体为，每个编程用户可能发生何种异常，例如：在匹配处理模块A中预先定义的是编程用户01的原因导致的应用程序发生的异常信息，在匹配处理模块B中预先定义的是编程用户02的原因导致的应用程序发生的异常信息。

在一种可选的实施例中，上述编程用户01为Android SDK的开发人员，上述编程用户02为Android APP的开发人员。

处理模块26，用于在异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将异常信息发送至异常信息对应的编程用户进行处理。

具体的，在处理模块26中，在将上述异常信息发送至多个匹配处理模块时，可以将上述异常信息和上述多个匹配处理模块中的异常模式信息进行匹配，以上述编程用户01为Android SDK的开发人员为例，如果，匹配处理模块A中的信息与上述异常信息相匹配的话，则说明，上述异常信息为Android SDK的开发人员的原因导致的，在本方案中的一种可选的实施例中，可以将上述异常信息发送至编程用户01，即发送至Android SDK的开发人员。

此处需要说明的是，在处理模块26中，不但可以初步区分异常原因是出自AndroidSDK的开发人员或Android APP的开发人员，在本方案提供的又一种可选的实施例中，在确定具体的异常类型后，例如异常的原因出自Android SDK的开发团队后，还可以通过本申请提供的方案将异常信息进行进一步的进行判断，从而将异常信息发送至具体的每一个Android SDK的开发人员。

基于上述对异常信息的处理装置，可以实现当应用程序发生异常时，通过本方案可以自动分辨该异常是由于哪个具体的编程用户的原因造成的，从而将上述异常信息发送给相关的软件开发人员，可以提高应用程序异常处理的效率，从而解决了现有技术中Android应用程序发生异常时，要将异常信息发送给所有的开发主体导致解决异常问题效率低的问题。

可选的，分发模块24还可以包括：

子分发模块241，用于在未处理异常的处理类中调用分发功能函数，通过分发功能函数将异常信息分发至多个匹配处理模块。

具体的，在本方案中，可以在未处理异常的处理类中的uncaughtExption方法中调用主题类中的notify功能函数即notify方法，通过上述notify方法将异常信息分发至多个匹配处理模块。

可选的，实现上述功能的部分代码如下；

public void uncaughtException(Thread thread,Throwable ex){

uncaughtExceptionSubject.Notify(ex)

}

结合上述代码，在分发子模块241中，可以调用上述uncaughtException方法中的Notify方法来实现上述异常信息的分发。

可选的，上述分发类在本方案中可以为全局异常主题类UncaughtExceptionSubjectImpl，上述全局异常主题类为IUncaughtExceptionSubject接口的具体实现类，上述IUncaughtExceptionSubject接口为全局异常的主题接口，在上述主题接口中定义了上述notify方法。

在一种可选的实施例中，可以采用观察者模式的方式完成异常信息的分发与处理。这里，观察者模式为软件设计模式之一，分为主题和观察者，观察者订阅主题，当主题发生变化时通知相应的观察者。具体的，首先，定义全局异常的主题接口IUncaughtExceptionSubject，在该主题接口定义有notify方法，而UncaughtExceptionSubjectImpl为对主题接口IUncaughtExceptionSubject的具体实现类即全局异常主题类。关于上述创建主题接口和主题类的部分代码如下：

IUncaughtExceptionSubject uncaughtExceptionSubject＝newUncaughtExceptionSubjectImpl()；

然后，定义全局异常的处理接口IUncaughtExceptionobserver，即观察者接口，通过该接口，开发人员可以实现自己的全局异常处理，比如，检查当前的异常是否是自己的代码问题引起的。而IUncaughtExceptionobserverImpl为对接口的具体实现类即观察者类。关于上述创建观察者接口和观察者类的部分代码如下：

IUncaughtExceptionObserver uncaughtExceptionObserver＝newUncaughtExceptionObserverImpl()；

这里需要说明的是，上述分发模块24中多个匹配处理模块的功能可以通过上述观察者接口和观察者类来实现，即当异常发生时，可以调用上述主题接口中的notify方法来将异常信息通知给相关观察者，相关观察者则负责对上述异常信息进行进一步的处理。

可选的，处理模块26还可以包括：

提取模块261，用于提取异常信息中的异常特征，其中，异常特征包括如下至少一个：异常包特征、异常类名称、异常函数名称。

可选的，上述异常包特征、异常类名称、异常函数名称可以为：PackageName＝”X”,ClassName＝”Y”,Method＝”Z”。

匹配模块262，用于将异常特征同多个匹配处理模块中的预先定义的异常模式信息进行匹配。

子处理模块263，用于在与第一匹配处理模块中的预先定义的异常模式信息匹配成功的情况下，将异常信息发送至第一匹配处理模块对应的编程用户。

具体的，由于在每个匹配处理模块中都分别预先存储了不同的异常模式信息，例如，在匹配处理模块A中预先定义的是编程用户01的原因导致的应用程序发生的异常模式信息，匹配处理模块A中的异常模式信息也包括：异常包特征、异常类名称以及异常函数名称，观察者类接收通过主题接口发送的异常信息进行提取，提取出实际发生异常的异常参数，即异常包特征、异常类名称以及异常函数名称，将上述实际发送的异常参数同匹配处理模块中预先定义的异常参数即上述异常模式信息进行匹配，如果匹配成功的话，说明上述应用程序发生的异常即为编程用户01的问题所造成。

在一种可选的实施例中，上述匹配处理模块的提取、匹配功能可通过如下方式实现，即通过调用上述观察者类中的HandleUncaughtException(Throwable)方法中检测提取异常的相关信息，如：在异常的堆栈中提取异常包名称，异常类名称，异常函数名称，根据这些信息判断相关信息是否与当前观察者定义的模式匹配，如果匹配，相关观察者实现类将该信息发送给相应的编程用户。

这里需要说明的是，上述HandleUncaughtException方法的实现还可以通过相关SDK或者APP中定义的预设命名规则加以鉴别匹配，例如：SDK实现了预设的命名空间命名或者预设的类命名规则或者预设的函数命名规则。

可选的，上述分发记录包括多个匹配处理模块的地址，上述为处理异常异常处理类依照上述地址将异常信息分发至不同的匹配处理模块，即发送至不同的观察者类。

本发明实施例二提供的异常信息的处理装置还可以包括：

增加模块27，用于将任意一条新的匹配处理模块的地址增加至分发记录，形成新的分发记录，使得未处理异常处理类将应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。

具体的，在一种可选的实施例中，在上述主题接口中还可以定义Add方法，通过调用该方法，一个IUncaughtExceptionObserver观察者可以实现对上述主题的订阅，即当异常信息发生时，调用主题类中的notify方法将异常信息发送至该观察者，所以在本方案中可以通过调用上述Add方法对上述分发记录中增加一条新的匹配处理模块的地址，上述新的匹配处理模块中预先定义有新的编程用户可能造成的异常的异常模式信息，当新的异常发生时，则本方案将异常信息同样发送至新的匹配处理模块，以便将异常信息发送至相应的编程用户。例如，在本方案的上述例子中，应用程序的开发人员主要分为Android SDK开发人员和Android APP的开发人员，当然一个应用程序可以由新的开发团队加入，当新的开发团队加入时，则可以调用上述Add方法增加一个新的匹配处理模块的地址。

本发明实施例二提供的异常信息的处理装置还可以包括：

移除模块28，用于将分发记录任意一条匹配处理模块的地址移除，形成新的分发记录，使得未处理异常处理类将应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。

具体的，在一种可选的实施例中，在上述主题接口中还可以定义Remove方法，通过调用该方法，一个IUncaughtExceptionObserver观察者可以实现对上述主题的退阅，即当异常信息发生时，则不将上述异常信息发送至该观察者，所以在本方案中可以通过调用上述Remove方法对上述分发记录中移除一条新的匹配处理模块的地址，当新的异常发生时，则本方案不将异常信息同样发送至该匹配处理模块。例如，在本方案的上述例子中，应用程序的开发人员主要分为Android SDK开发人员和AndroidAPP的开发人员，如果提前确认上述Android SDK的开发人员提供的开发包不可能使应用程序出现异常时，则可以调用上述Remove方法移除该Android SDK对应的匹配处理模块的地址。

下面本方案结合具体应用场景详细描述：

首先，本发明技术方案的技术原理为首先实现一个异常处理与分发的接口，该接口实现设计模式中的主题方面的接口，观察者类实现观察者模式中观察者方面的接口，当异常发生时，主题类通知该观察者类，本申请利用了观察者模式中的分发和处理的解耦，方便以后扩展。

其次，本发明技术方案的整体思路为利用Android API注册全局的未处理异常的处理类，通过该类的uncaughtException函数分发异常信息，接着，通过异常处理的类实现异常的特征的提取与匹配，如匹配将相关信息发送到自己。这里需要说明的是，未处理异常的处理类即上述主题类，异常处理的类即上述观察者类。

具体的，为实现上述功能，在本方案中创建了主题接口，主题类、观察者接口和观察者类，上述类和接口的具体解释如下：

主题接口：IUncaughtExceptionSubject，可以通过调用这个接口的Add或者Remove方法，一个IUncaughtExceptionObserver观察者接口可以实现对该主题的订阅和退阅，同时当异常发生时IUncaughtExceptionSubject接口通过调用Notify通知相关观察者。

在主题接口中定义了三个方法如下：

Add(IUncaughtExceptionObserver)：该接口方法接受一个IUncaughtExceptionSubject参数，表示全局异常处理接口这个接口的订阅。

Remove(IUncaughtExceptionObservr)；该接口方法接受一个IUncaughtExceptionSubject参数，表示全局异常处理接口这个接口的退阅。

Notify(Throwable)：这个接口方法接受一个异常类参数，通过调用该方法将这个异常类通知到所有订阅全局异常主题的订阅者。

主题实现类UncaughtExceptionSubjectImpl：这是一个对上述IUncaughtExceptionSubject接口的具体实现类。

观察者接口：全局异常的处理接口，通过实现该接口，开发人员就可以实现自己的全局异常处理(例如，检查当前的异常是否是自己的代码引起的等)。在上述观察者接口中定义了如下方法：(bool)HandleUncaughtException(Throwable)。

观察者实现类UncaughtExceptionObserverImpl：是一个对上述IUncaughtExceptionObserver接口的具体实现类。

可选的，结合部分代码描述本方案：

在Android APP启动时调用如下方法：

//这是Android机器中注册全局异常的方法，参数CrashHandler是一个继承自UncaughtExceptionHandler的我们自己实现的类

Thread.setDefaultUncaughtExceptionHandler(CrashHandler)；

//这是我们实现的全局异常主题类

IUncaughtExceptionSubject uncaughtExceptionSubject＝newUncaughtExceptionSubjectImpl()；

//这是我们实现的可以对全局异常进行订阅的订阅者类

IUncaughtExceptionObserver uncaughtExceptionObserver＝newUncaughtExceptionObserverImpl()；

//通过调用全局异常主题类的Add方法，uncaughtExceptionObserver订阅者//类订阅了uncaughtExceptionSubject这个主题。

uncaughtExceptionSubject.Add(uncaughtExceptionObserver)

其中，上述CrashHandler是一个继承自UncaughtExceptionHandler的类，覆盖如下方法：

Override

public void uncaughtException(Thread thread,Throwable ex){

uncaughtExceptionSubject.Notify(ex)

}

通过uncaughtException方法，调用uncaughtExceptionSubject全局异常主题的Notify方法通知注册该主题的所有订阅者。

其中UncaughtExceptionObserverImpl是一个具体的全局异常的订阅者，实现思路如下：在HandleUncaughtException(Throwable)方法中检测提取异常的相关信息，如：在异常的堆栈中提取异常包名称，异常类名称，异常函数名称，根据这些信息判断相关信息是否与当前观察者定义的模式匹配，如果匹配相关观察者类实现者将该信息发送给自己。

本申请提供的方案的关键点在于，在全局的未捕获异常处理器中处理相关异常。通过观察者模式跟踪异常发生的相关情况。在观察者中提取相关特征并匹配。匹配成功交通知相关负责人。

这里需要说明的是，本文中所提到的相关负责人可以为软件的开发人员、软件的编程用户，也即本文中的观察者。

综上，本申请提供的方案优点如下：

(1)因为本方案能把不同开发人员开发的代码的异常分发给相关开发人员，所以避免了大家一起对某个异常同时关注而造成的时间损耗，提高了效率。

(2)提高了SDK开发人员发现问题与解决问题的效率。

(3)提高了APP开发人员发现问题与解决问题的效率。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、移动终端、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种异常信息的处理方法，其特征在于，所述方法包括：

采集应用程序运行过程中出现的异常信息，其中，所述应用程序运行于Android系统，在所述应用程序的线程中注册有未处理异常的处理类；

通过所述未处理异常处理类将所述应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块，其中，所述多个匹配处理模块预先定义对应的编程用户的异常模式信息；

在所述异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将所述异常信息发送至所述异常信息对应的编程用户进行处理。

2.根据权利要求1所述的方法，其特征在于，通过所述未处理异常处理类将所述应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块的步骤包括：

在所述未处理异常的处理类中调用分发功能函数，通过所述分发功能函数将所述异常信息分发至所述多个匹配处理模块。

3.根据权利要求2所述的方法，其特征在于，在所述异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将所述异常信息发送至所述异常信息对应的编程用户进行处理的步骤包括：

提取所述异常信息中的异常特征，其中，所述异常特征包括如下至少一个：异常包特征、异常类名称、异常函数名称；

将所述异常特征同所述多个匹配处理模块中的预先定义的异常模式信息进行匹配；

在与第一匹配处理模块中的预先定义的异常模式信息匹配成功的情况下，将所述异常信息发送至所述第一匹配处理模块对应的编程用户。

4.根据权利要求3所述的方法，其特征在于，所述分发记录中包括所述多个匹配处理模块的地址，其中，在与第一匹配处理模块中的预先定义的异常模式信息匹配成功的情况下，将所述异常信息发送至所述第一匹配处理模块对应的编程用户之后，所述方法还包括：

将任意一条新的匹配处理模块的地址增加至所述分发记录，形成新的分发记录，使得所述未处理异常处理类将所述应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。

5.根据权利要求3所述的方法，其特征在于，所述分发记录中包括所述多个匹配处理模块的地址，其中，在与第一匹配处理模块中的预先定义的异常模式信息匹配成功的情况下，将所述异常信息发送至所述第一匹配处理模块对应的编程用户之后，所述方法还包括：

将所述分发记录任意一条匹配处理模块的地址移除，形成新的分发记录，使得所述未处理异常处理类将所述应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。

6.一种异常信息的处理装置，其特征在于，包括：

采集模块，用于采集应用程序运行过程中出现的异常信息，其中，所述应用程序运行于Android系统，在所述应用程序的线程中注册有未处理异常的处理类；

分发模块，用于通过所述未处理异常处理类将所述应用程序运行过程中出现的异常信息按照分发记录分发至多个匹配处理模块，其中，所述多个匹配处理模块预先定义对应的编程用户的异常模式信息；

处理模块，用于在所述异常信息与任意一个匹配处理模块中的异常模式信息一致的情况下，将所述异常信息发送至所述异常信息对应的编程用户进行处理。

7.根据权利要求6所述的装置，其特征在于，所述分发模块包括：

子分发模块，用于在在所述未处理异常的处理类中调用分发功能函数，通过所述分发功能函数将所述异常信息分发至所述多个匹配处理模块。

8.根据权利要求7所述的装置，其特征在于，所述处理模块包括：

提取模块，用于提取所述异常信息中的异常特征，其中，所述异常特征包括如下至少一个：异常包特征、异常类名称、异常函数名称；

匹配模块，用于将所述异常特征同所述多个匹配处理模块中的预先定义的异常模式信息进行匹配；

子处理模块，用于在与第一匹配处理模块中的预先定义的异常模式信息匹配成功的情况下，将所述异常信息发送至所述第一匹配处理模块对应的编程用户。

9.根据权利要求8所述的装置，其特征在于，所述分发记录中包括所述多个匹配处理模块的地址，其中，所述装置还包括：

增加模块，用于将任意一条新的匹配处理模块的地址增加至所述分发记录，形成新的分发记录，使得所述未处理异常处理类将所述应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。

10.根据权利要求8所述的装置，其特征在于，所述分发记录中包括所述多个匹配处理模块的地址，所述装置还包括：

移除模块，用于将所述分发记录任意一条匹配处理模块的地址移除，形成新的分发记录，使得所述未处理异常处理类将所述应用程序运行过程中出现的异常信息按照新的分发记录分发至多个匹配处理模块。