CN107515792A - 功能类使用Handler进行消息处理的方法和装置 - Google Patents

Abstract

本发明实施例提供一种功能类使用Handler进行消息处理的方法和装置。本发明功能类使用Handler进行消息处理的方法，包括：所述功能类接收业务处理请求消息；所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理；其中，所述第二Handler类弱引用所述第一Handler类，所述第二Handler类为原生Handler的子类。本发明实施例以简单的方式实现原生Handler到功能类的可达路径为弱可达，有效避免直接使用原生Handler导致功能类内存泄漏的问题，降低APP的崩溃率和OOM问题。

Description

功能类使用Handler进行消息处理的方法和装置

技术领域

本发明实施例涉及计算机技术，尤其涉及一种功能类使用Handler进行消息处理的方法和装置。

背景技术

消息处理程序(Handler)是安卓(Android)开发者进行消息传递的常用应用程序编程接口(Application Programming Interface，API)，其主要用于异步消息的处理，当发出一个消息之后，首先进入一个消息队列，发送消息的函数即刻返回，而另外一个部分在消息队列中逐一将消息取出，然后对消息进行处理。然而随着开发者的使用不当或者不谨慎很容易引起内存泄漏问题，严重时会造成几MB的内存空间被占用，从而提高了内存溢出(Out Of Memory，OOM)的发生概率和应用程序(Application，APP)的崩溃概率。

为了避免在使用Handler引起的内存泄漏问题，可以在用户接口程序(Activity)中避免使用非静态内部类，将Handler声明为静态的，其存活期跟Activity的生命周期就无关了。同时通过弱引用的方式引入Activity，避免直接将Activity作为Context传入Handler，即使用静态内部类加弱引用(WeakReference)的方式。

然而，上述使用静态内部类加WeakReference的实现方式过于复杂，需要在每个使用Handler的地方都要声明一个静态内部类，如果需要多个Handler进行消息传递就需要声明多个，然后逐一进行实例化并且每次使用前判空，失去了原生Handler的简约性。

发明内容

本发明实施例提供一种功能类使用Handler进行消息处理的方法和装置，以简单的方式实现原生Handler到功能类的可达路径为弱可达，有效避免直接使用原生Handler导致功能类内存泄漏的问题，降低APP的崩溃率和OOM问题。

第一方面，本发明实施例提供一种功能类使用Handler进行消息处理的方法，包括：

所述功能类接收业务处理请求消息；

所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理；

其中，所述第二Handler类弱引用所述第一Handler类，所述第二Handler类为原生Handler的子类。

结合第一方面，在第一方面的一种可能的实现方式中，所述功能类接收业务处理请求消息之前，所述方法还包括：

创建所述第一Handler类，所述第一Handler类的属性包括调用所述第二Handler类。

结合第一方面或者第一方面任一种可能的实现方式，在第一方面的另一种可能的实现方式中，所述功能类接收业务处理请求消息之前，所述方法还包括：

创建所述第二Handler类，所述第二Handler类继承所述原生Handler类的所有属性和所有消息处理方法，且所述第二Handler类的属性还包括弱引用所述第一Handler类。

结合第一方面或者第一方面任一种可能的实现方式，在第一方面的另一种可能的实现方式中，所述第一Handler类和所述第二Handler类的可见性均为私有。

结合第一方面或者第一方面任一种可能的实现方式，在第一方面的另一种可能的实现方式中，所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理，包括：

在所述功能类的生命周期内，所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理。

第二方面，本发明实施例提供一种功能类使用Handler进行消息处理的装置，包括：

接收模块，用于接收业务处理请求消息；

处理模块，用于通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理；

其中，所述第二Handler类弱引用所述第一Handler类，所述第二Handler类为原生Handler的子类。

结合第二方面，在第二方面的一种可能的实现方式中，所述装置还包括：预设模块；

所述预设模块用于创建所述第一Handler类，所述第一Handler类的属性包括调用所述第二Handler类。

结合第二方面或者第二方面任一种可能的实现方式，在第二方面的另一种可能的实现方式中，所述预设模块还用于：

创建所述第二Handler类，所述第二Handler类继承所述原生Handler类的所有属性和所有消息处理方法，且所述第二Handler类的属性还包括弱引用所述第一Handler类。

结合第二方面或者第二方面任一种可能的实现方式，在第二方面的另一种可能的实现方式中，所述第一Handler类和所述第二Handler类的可见性均为私有。

结合第二方面或者第二方面任一种可能的实现方式，在第二方面的另一种可能的实现方式中，所述处理模块具体用于：

在所述功能类的生命周期内，所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理。

本发明实施例功能类使用Handler进行消息处理的方法和装置，功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理，其中，所述第二Handler类弱引用(WeakReference)所述第一Handler类，所述第二Handler类为原生Handler的子类，使得该原生Handler的子类(第二Handler)弱可达(Weakly Reachable)第一Handler，从而实现原生Handler到功能类的可达路径为弱可达，可以有效避免直接使用原生Handler导致功能类内存泄漏的问题，降低APP的崩溃率和OOM问题。并且，在实现过程中，无需在每个使用原生Handler的地方声明静态内部类，并逐一进行实例化和使用前的判空，本发明实施例的实现方法操作简单，其实施方式与使用原生Handler方法一致，可以有效提升开发效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明功能类使用Handler进行消息处理的方法实施例一的流程图；

图2为本发明功能类使用Handler进行消息处理的方法中第一Handler类的类图；

图3为本发明功能类使用Handler进行消息处理的方法中第一Handler类的可达性图；

图4为本发明功能类使用Handler进行消息处理的方法实施例二的流程图；

图5为本发明功能类使用Handler进行消息处理的装置实施例一的结构示意图；

图6为本发明功能类使用Handler进行消息处理的装置实施例二的结构示意图。

具体实施方式

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

Activity是Android组件中最基本、也是最为常见用的四大组件(Activity，服务Service，内容提供者Content Provider，广播接收器BroadcastReceiver)之一。Activity是一个应用程序组件，提供一个屏幕，用户可以用来交互为了完成某项任务。Activity中所有操作都与用户密切相关，是一个负责与用户交互的组件，可以通过setContentView(View)来显示指定控件。

在一个Android应用中，一个Activity通常就是一个单独的窗口，它上面可以显示一些控件也可以监听并处理用户的事件做出响应。不同Activity之间通过Intent进行通信。其中，该应用可以是各种业务类型的APP，例如，即时通信、招聘服务、二手车服务等等。每个APP中的Activity用于在终端上通过屏幕提供给用户进行交互的界面。每个APP中的Activity均可以使用本发明实施例的方法使用Handler进行消息处理。

本发明实施例的功能类使用Handler进行消息处理的方法，通过对原生的Handler进行改进，使得该原生Handler的子类(第二Handler)弱可达第一Handler，从而实现原生Handler到功能类(Activity)的可达路径为弱可达，可以有效避免直接使用原生Handler导致功能类(Activity)内存泄漏的问题，降低APP的崩溃率和OOM问题。其具体实现方式可以参见下述实施例的具体解释说明。

需要说明的是，本发明实施例所涉及的“第一Handler”、“第二Handler”仅为一个名字，用于指代不同的程序类，其可以称之为其他名称，例如第一Handler也可以称之为WubaHandler，第二Handler也可以称之为UnLeakHandler，本发明实施例对此不作限制。

图1为本发明功能类使用Handler进行消息处理的方法实施例一的流程图，如图1所示，本实施例的方法可以包括：

步骤101、功能类接收业务处理请求消息。

其中，该功能类具体可以是一种特定功能类型的程序类，该功能类需要使用Handler进行消息处理，例如，该功能类可以是Activity。

步骤102、所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理。

其中，所述第二Handler类弱引用所述第一Handler类，所述第二Handler类为原生Handler的子类。

具体的，本发明实施例对原生的Handler进行包装改进，即如上述方式，在原生Handler的基础上，引入该原生Handler的子类，并且该原生Handler的子类弱引用第一Handler类，该第一Handler类向该功能类提供访问接口。从而实现原生Handler到功能类(Activity)的可达路径为弱可达，可以有效避免直接使用原生Handler导致功能类(Activity)内存泄漏的问题，降低APP的崩溃率和OOM问题。

并且，本发明实施例在实现过程中，无需在每个使用原生Handler的地方声明静态内部类，并逐一进行实例化和使用前的判空，本发明实施例的实现方法操作简单，其实施方式与使用原生Handler方法一致，可以有效提升开发效率。

一种可实现方式，在功能类接收业务处理请求消息之前，可以预先创建所述第一Handler类，所述第一Handler类的属性包括调用所述第二Handler类。

可以预先创建所述第二Handler类，所述第二Handler类继承所述原生Handler类的所有属性和所有消息处理方法，且所述第二Handler类的属性还包括弱引用所述第一Handler类。

可选的，所述第一Handler类和所述第二Handler类的可见性均可以为私有(Private)。

可选的，步骤102的具体实现方式可以为：在所述功能类的生命周期内，所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理。

本实施例，功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理，其中，所述第二Handler类弱引用所述第一Handler类，所述第二Handler类为原生Handler的子类，使得该原生Handler的子类(第二Handler)弱可达第一Handler，从而实现原生Handler到功能类的可达路径为弱可达，可以有效避免直接使用原生Handler导致功能类内存泄漏的问题，降低APP的崩溃率和OOM问题。

下面采用几个具体的实施例，对图1所示方法实施例的技术方案进行详细说明。

图2为本发明功能类使用Handler进行消息处理的方法中第一Handler类的类图，本实施例以第一Handler类为WubaHandler，第二Handler类为UnLeakHandler，原生Handler为Handler为例做举例说明，如图2所示，WubaHandler强引用UnLeakHandler，UnLeakHandler弱引用WubaHandler，UnLeakHandler继承Handler。

具体的如图2所示的类图，每一个大的矩形框代表一个类，一个类通常包括3个组成部分。第一个是类名；第二个是属性(attributes)；第三个是该类提供的方法(类的性质可以放在第四部分；如果类中含有内部类，则会出现第五个组成部分)。各组成部分分别位于一个大的矩形框内的不同行中。类名部分是不能省略的，其他组成部分可以省略。

如图2所示，Handler提供的方法包括调度消息()(+dispatchMessage())和处理消息()(+handleMessage())，该消息具体可以是上述步骤101接收到的消息。本发明实施例的方法并非将步骤101中的消息直接输入至Handler，而是通过WubaHandler接入，再通过UnLeakHandler实现使用Handler进行消息处理。

具体的，如图2所示，WubaHandler的属性包括调用UnLeakHandler(-mHandler：UnLeakHandler)，WubaHandler提供的方法包括调度消息()(+dispatchMessage())和处理消息()(+handleMessage())。该WubaHandler使用UnLeakHandler，如图2所示的实线实心箭头。UnLeakHandler继承Handler，如图2所示的实线空心箭头，该UnLeakHandler的所有属性和所有消息处理方法，且UnLeakHandler的属性还包括弱引用WubaHandler(-ref：WeakReference<WubaHandler>)。

其中，WubaHandler的属性和UnLeakHandler的属性的可见性均为Private(-)。

图3为本发明功能类使用Handler进行消息处理的方法中第一Handler类的可达性图，如图3所示，该可达性图中包括根类(Root)、功能类(some class(Activity))、循环类(Looper)、消息队列类(Message Queue)、消息体(Message)、上述实施例的UnLeakHandler以及上述实施例的WubaHandler。

其中，Message用于描述一个消息体，包含两个整型域和一个对象域，可以通过UnLeakHandler来发送。

Message Queue底层保存Message的队列，通常以链表的方式串联起来的，从属于特定Looper，在Looper的构造过程中会去创建一个MessageQueue，通过Looper来调度。Message不是以直接的方式添加到Message Queue中，而是通过和Looper相关联的UnLeakHandler来实现消息进入队列。

Looper线程的消息泵，不断地从Message Queue中抽取Message执行。

UnLeakHandler的作用就是把消息加入Looper的MessageQueue中，并分发和处理该消息队列中的消息。构造UnLeakHandler的时候可以指定一个Looper对象，如果不指定则利用当前线程的Looper。比如UnLeakHandler对象以主线程的Looper创建，那么调用UnLeakHandler的send Message等接口，将会把消息放入主线程的消息队列。并且将会在UnLeakHandler主线程中调用该UnLeakHandler的handleMessage接口来处理消息。这样在主线程中便可以更新用户界面(User Interface，UI)。

其中，如上述实施例所述的UnLeakHandler继承Handler类的所有属性和所有消息处理方法，且弱引用WubaHandler。

具体的，举例而言，当一个Android应用APP启动的时候，会自动创建一个供应用主线程使用的Looper实例。Looper的主要工作就是一个一个处理消息队列中的消息对象。在Android中，所有Android框架的事件，比如Activity的生命周期方法调用和按钮点击等，都是放入到消息中，然后加入到Looper要处理的消息队列中，由Looper负责一条一条地进行处理。主线程中的Looper生命周期和当前应用的生命周期一样长。

本发明实施例通过设置UnLeakHandler和WubaHandler，实现如图3所示的UnLeakHandler到WubaHandler的弱可达。具体的，如图3所示，功能类(some class(Activity))强引用WubaHandler，WubaHandler强引用UnLeakHandler，即在该功能类的生命周期内，WubaHandler到UnLeakHandler强可达。通过UnLeakHandler的属性：弱引用WubaHandler，实现如图3所示的UnLeakHandler到WubaHandler的弱可达。在使用该类后，该功能类只被生命周期管理类(未示出)强可达，而UnLeakHandler的父类Handler到该功能类的可达路径为弱可达，从而可以避免Handler导致的内存泄漏问题。

需要说明的是，如图3所示的WubaHandler指向功能类(some class(Activity))的匿名内部，具体指，由于Handler为异步消息的处理方式，当功能类(some class(Activity))的生命周期结束时，WubaHandler中仍会存在匿名内部类使用该功能类(someclass(Activity))，而在这种情况下，由于本发明实施例设置有弱引用该WubaHandler的UnLeakHandler，从而使得UnLeakHandler的父类Handler到该功能类的可达路径为弱可达，从而可以避免Handler导致的内存泄漏问题。

图4为本发明功能类使用Handler进行消息处理的方法实施例二的流程图，本实施例以功能类为Activity做举例说明，如图4所示，本实施例的方法可以包括：

步骤201、在Activity的生命周期内，应用程序的Activity通过第一Handler类和第二Handler类对接收到的业务处理请求消息进行处理。

其中，第一Handler类和第二Handler类的具体解释说明可以参见图1所示实施例的具体解释说明，此处不再赘述。

步骤202、应用程序通过Java垃圾回收机制判断该Activity是否可以被回收掉，若可以被回收，则执行步骤203。

具体的，在Activity的生命周期结束后，应用程序可以确定该Activity可以被回收掉。其判断过程具体可以是可达性分析算法。如图3所示，原生Handler到Activity为弱可达，那么Activity仅被其生命周期管理类强可达，当Activity的生命周期结束，便不存在任何类对该Activity强可达，进而可以通过垃圾回收机制释放Activity占用的内存空间。

步骤203、应用程序释放Activity占用的内存空间。

本实施例，可以实现原生Handler到Activity的可达路径为弱可达，有效避免直接使用原生Handler导致功能类内存泄漏的问题，降低APP的崩溃率和OOM问题。

图5为本发明功能类使用Handler进行消息处理的装置实施例一的结构示意图，如图5所示，本实施例的装置可以包括：接收模块11和处理模块12，其中，接收模块11用于接收业务处理请求消息，处理模块12用于通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理；其中，所述第二Handler类弱引用所述第一Handler类，所述第二Handler类为原生Handler的子类。

本实施例的装置，可以用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图6为本发明功能类使用Handler进行消息处理的装置实施例二的结构示意图，如图6所示，本实施例的装置在图5所示装置结构的基础上，进一步地，还可以包括：预设模块13，该预设模块13用于创建所述第一Handler类，所述第一Handler类的属性包括调用所述第二Handler类。

该预设模块13还用于：创建所述第二Handler类，所述第二Handler类继承所述原生Handler类的所有属性和所有消息处理方法，且所述第二Handler类的属性还包括弱引用所述第一Handler类。

可选的，所述第一Handler类和所述第二Handler类的可见性均为私有。

该处理模块12具体用于：在所述功能类的生命周期内，所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理。

本实施例的装置，可以用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

此外，本发明实施例还提供一种包含指令的计算机程序产品，即软件产品，当其在计算机上运行时，使得计算机执行上述方法实施例中各种可能的功能类使用Handler进行消息处理的方法。其实现原理和技术效果类似，此处不再赘述。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (10)

1.一种功能类使用Handler进行消息处理的方法，其特征在于，包括：

所述功能类接收业务处理请求消息；

所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理；

其中，所述第二Handler类弱引用所述第一Handler类，所述第二Handler类为原生Handler的子类。

2.根据权利要求1所述的方法，其特征在于，所述功能类接收业务处理请求消息之前，所述方法还包括：

创建所述第一Handler类，所述第一Handler类的属性包括调用所述第二Handler类。

3.根据权利要求2所述的方法，其特征在于，所述功能类接收业务处理请求消息之前，所述方法还包括：

创建所述第二Handler类，所述第二Handler类继承所述原生Handler类的所有属性和所有消息处理方法，且所述第二Handler类的属性还包括弱引用所述第一Handler类。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述第一Handler类和所述第二Handler类的可见性均为私有。

5.根据权利要求1至3任一项所述的方法，其特征在于，所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理，包括：

在所述功能类的生命周期内，所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理。

6.一种功能类使用Handler进行消息处理的装置，其特征在于，包括：

接收模块，用于接收业务处理请求消息；

处理模块，用于通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理；

其中，所述第二Handler类弱引用所述第一Handler类，所述第二Handler类为原生Handler的子类。

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

所述预设模块用于创建所述第一Handler类，所述第一Handler类的属性包括调用所述第二Handler类。

8.根据权利要求7所述的装置，其特征在于，所述预设模块还用于：

创建所述第二Handler类，所述第二Handler类继承所述原生Handler类的所有属性和所有消息处理方法，且所述第二Handler类的属性还包括弱引用所述第一Handler类。

9.根据权利要求6至8任一项所述的装置，其特征在于，所述第一Handler类和所述第二Handler类的可见性均为私有。

10.根据权利要求6至8任一项所述的装置，其特征在于，所述处理模块具体用于：

在所述功能类的生命周期内，所述功能类通过第一Handler类和第二Handler类对所述业务处理请求消息进行处理。