CN108491245A - 用于提高弹框容错率的模块和相关电子设备 - Google Patents

Abstract

本发明提供了一种用于提高弹框容错率的模块，该模块包括用于处理弹框调用组件中的异常事件的第一容错处理单元。该第一容错处理单元可被用于执行以下步骤：判断弹框调用组件是否为空；判断弹框调用组件是否正在处于销毁阶段以及判断弹框调用组件是否已经被销毁。该模块还可以包括用于反馈异常事件的反馈单元以及用于处理弹框逻辑的异常事件的第二容错处理单元和/或用于处理弹框的内存泄漏事件的第三容错处理单元。本发明提供的模块所包括的三个容错处理单元所处理的异常事件是逐级递增的，实现了在应用层面、系统层面和空间内存层面的异常事件处理，大大增强了弹框的容错能力。本发明还涉及包括上述模块的电子设备。

Description

用于提高弹框容错率的模块和相关电子设备

技术领域

本发明涉及计算机领域，具体涉及一种用于提高弹框容错率的模块以及相关电子设备。

背景技术

在Android的开发过程中，经常会使用到对话框的开发业务逻辑，对话框通常是一个悬浮在最顶层的页面。传统的开发中对话框的初始化时需要依赖一个activity对象，其中activity对象就是对话框弹出时所在的页面。

传统的这种引用关系和弹框关系在某些极端情况下可能会出现一些异常的问题，例如当activity因为某些原因已经被系统销毁了，但是系统此时又调度到弹出对话框的元素，此时由于activity实际上已经为空，这样会导致弹框失败，从而引起空指针异常的问题。另外，存在一种情况就是当对话框弹出来了，但是对话框一直没有被销毁掉，由于对话框持有了activity的引用，所以会导致页面无法释放，从而引起内存泄漏的问题发生。

而且弹框逻辑的真正底层实现是在系统层面实现的，但是由于Android系统的版本的多样性及平台设备的不确定性(每个厂商都会对自己的系统进行裁剪和修改)等可能会导致系统自带的显示函数出现异常。

因此，有必要设计一种能够增强弹框容错率的模块。

发明内容

有鉴于此，为了克服上述问题的至少一个方面，本发明的实施例提出一种用于提高弹框容错率的模块，该模块包括：

用于处理弹框调用组件中的异常事件的第一容错处理单元，

所述第一容错处理单元用于执行以下步骤：

判断所述弹框调用组件是否为空；

判断所述弹框调用组件是否正在处于销毁阶段；以及

判断所述弹框调用组件是否已经被销毁

进一步地，所述模块还包括反馈单元，用于反馈所述弹框调用组件中的异常事件。

进一步地，若判定所述弹框调用组件为空，则通过所述第一容错处理单元处理，并通过所述反馈单元进行反馈。

进一步地，若判定所述弹框调用组件不为空，则判断所述弹框调用组件是否正处于销毁阶段，若判定所述弹框调用组件正处于销毁阶段，则通过所述第一容错处理单元处理，并通过所述反馈单元进行反馈。

进一步地，若判定所述弹框调用组件未处于销毁阶段，则判断所述弹框调用组件是否已经被销毁，若判定所述弹框调用组件已经被销毁，则通过所述第一容错处理单元处理，并通过所述反馈单元进行反馈。

进一步地，所述模块还包括第二容错处理单元，所述第二容错处理单元用于处理由系统版本引起的显示函数出错而导致的弹框逻辑的异常事件。

进一步地，所述第二容错处理单元包括用于捕获所述弹框逻辑的异常事件的异常捕获函数。

例如，所述模块还包括用于处理弹框的内存泄漏事件的第三容错处理单元，当所述弹框调用组件不可见时，所述第三容错处理单元通过调用内存释放函数，以便及时释放所述弹框调用组件。

进一步地，在所述内存释放函数中，通过将所述弹框调用组件的引用设置为空，以及时释放所述弹框调用组件。

根据本发明的另一个方面，提供一种电子设备，所述电子设备包括如上所述的任一种用于提高弹框容错率的模块。

与现有技术相比，本发明具有以下优点：

(1)能够有效的提高弹框的容错率，极大的提高用户体验并且降低错误发生的概率；

(2)加强了由于平台差异化的因素引起的系统本身的bug的捕获，避免了因为平台差异化的原因引起的系统崩溃等问题。

(3)能够有效解决由于弹框页面引用未被释放占用内存而导致的内存泄漏问题。

附图说明

通过下文中参照附图对本发明所作的描述，本发明的其它目的和优点将显而易见，并可帮助对本发明有全面的理解。

图1为根据本发明实施例的增强弹框容错率的模块的结构示意图。

具体实施方式

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

除非另外定义，本发明使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。

根据本发明的一个方面，本发明的实施例提供了一种用于提高弹框容错率的模块100，如图1所示，该模块100可以包括第一容错处理单元101、第二容错处理单元102和第三容错处理单元103中的任意一个或多个，并且还可以包括反馈单元104。以下对每个单元作简要说明。

第一容错处理单元101可以用于处理弹框调用组件中的异常事件，该单元主要是处理应用级别的异常事件，例如处理APP上弹框调用组件的异常事件。

在具体实施过程中，弹框调用组件可以是Activity组件，下面详细描述第一容错处理单元101是如何有效执行Activity组件与弹框页面中的容错处理。

第一容错处理单元101可以是通过对show方法的重载来实现对原始show方法的容错处理。该重载方法相对于原始的show方法多出了一个faultTolerant参数，当该参数为true的时候，就会调用重载的show方法，当该参数为false的时候，就会直接调用原始的非重载的show方法。

第一容错处理单元101可以做三个方面的容错处理，例如，可以判断弹框调用组件是否为空、也可以判断弹框调用组件是否正在处于销毁阶段、还可以判断弹框调用组件是否已经被销毁。主要目的就是避免Activity的异常销毁导致弹框崩溃的情况发生。

为了方便描述可以将Activity页面对象标记为Activity，在进行显示之前首先判断Activity是否为空，具体的实现方式是if(Activity＝＝null)。如果该条件成立，表示需要显示弹框逻辑的时候Activity已经销毁了，此时需要通过反馈单元104将异常信息进行反馈。例如可以通过调用return语句终止显示流程，并将异常信息输出到控制台中。

如果上述条件判断不通过，说明Activity不为空，此时需要进一步判定Activity页面是否正处在销毁阶段。因为当Activity页面正处在销毁阶段的时候可能判定Activity不为空，但是在显示页面的时候Activity已经销毁完成了，此时再显示对话框就会出现异常情况了。为了避免该问题的出现，就需要对当前Activity的状态进行判定，具体的判定方法是if(Activity.isFinishing())，如果该判定条件成立，说明不能显示弹框，此时需要通过反馈单元104将异常信息进行反馈，例如可以通过return终止流程并将错误信息输出到控制台进行查看。

如果上述条件依旧为假，此时还需要做进一步的判定，需要判定当前的Activity是不是已经被销毁了。如果Activity此时已经被销毁了，也是不能够弹出对话框的。具体的判定逻辑是if(Activity.isDestroyed())，如果该判定条件成立，则说明Activity已经被销毁掉了，此时需要通过反馈单元104将异常信息进行反馈，例如可以通过调用return语句终止流程并将错误信息输出到控制台页面。

当上述条件均判定不通过后，说明已经满足了显示对话框的前提条件，也就是当前Activity的状态能够满足对话框的弹出条件。此时，就可以调用显示对话框的业务逻辑来实现对话框的显示了。

第二容错处理单元102可以用于处理弹框逻辑的异常事件。该单元主要是处理系统级别的异常事件，例如，处理由于Android系统的版本的多样性及平台设备的不确定性(每个厂商都会对自己的系统进行裁剪和修改)等可能会导致系统自带的显示函数出现的异常事件。

例如，第二容错处理单元102可以包括用于捕获弹框逻辑的异常事件的异常捕获函数，用于处理由系统版本引起的显示函数出错而导致的弹框逻辑的异常事件。

在具体实施过程中，可以通过在系统的显示函数外层套一层try-catch代码块，然后通过该代码块来捕获系统的显示函数的异常逻辑。一旦执行流程执行到了catch代码块中，说明系统自带的显示逻辑中出现了一些异常情况，此时需要通过反馈单元104将异常信息进行反馈，例如，可以通过终止程序的执行并通过控制台打印出相应的异常信息，方便开发人员对异常问题进行定位处理。

第二容错处理单元102主要是对容错处理进行进一步的加强并实现了平台差异化的因素引起的系统本身的bug的捕获，避免了因为平台差异化的原因引起的系统崩溃等问题。

第三容错处理单元103可以用于处理弹框的内存泄漏事件。该单元主要是解决空间内存出现的异常事件。例如，第三容错处理单元103可以通过调用内存释放函数，以便及时释放弹框调用组件。

在具体实施过程中，由于内存泄漏的根本原因是因为对话框持有了Activity页面，导致Activity页面无法被系统回收掉，从而造成了Activity页面所占用的内存的泄漏。为了避免弹框长期持有Activity的引用，可以在弹框页面的生命周期中调用系统的onPause函数，该函数会在弹框页面不可见的时候调用。也就是说只要弹框页面不可见了，系统就会回调弹框页面的onPause函数，并且这个回调函数的速度非常快。

基于Android系统的弹框生命周期的特性，可以复写弹框生命周期函数中的onPause方法并在该方法中释放Activity的引用关系。具体释放Activity引用关系的方法是将该Activity的引用设置为空，这样系统的垃圾回收器就能够将Activity页面进行回收了。

现有技术中弹框页面资源的销毁通常是在弹框页面的销毁函数中进行资源的释放，该单元并没有按照传统的方式进行处理。因为销毁函数在系统中的调用速度非常慢，这会导致Activity释放的速度变慢，从而导致页面内存占用时间长等问题。并且在某些情况下弹框的销毁函数可能不会触发，这样就无法确保Activity能够被释放。

但是onPause函数是一个与页面显示相关的生命周期函数，只要是弹框不可见了，此时一定会快速的触发onPause函数，这样就可以确保Activity的引用能够被及时释放。从而就能够解决弹框停止显示后出现内存泄漏的问题。

反馈单元104，用于反馈弹框调用组件中的异常事件和/或弹框逻辑的异常事件。具体反馈内容已在上述实施例中详细描述，此处就不再赘述。

本实施例提供的模块100所包括的三个容错处理单元所处理的异常事件是逐级递增的，实现了在应用层面、系统层面和空间内存层面的异常事件处理，大大增强了弹框的容错能力。

基于同一发明构思，本发明实施例还提供一种电子设备，该电子设备可以包括如上所述的任一种用于提高弹框容错率的模块。

对于本发明的实施例，还需要说明的是，在不冲突的情况下，本发明的实施例及实施例中的特征可以相互组合以得到新的实施例。

最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神和范围。

Claims (10)

1.一种用于提高弹框容错率的模块，包括用于处理弹框调用组件中的异常事件的第一容错处理单元，所述第一容错处理单元用于执行以下步骤：

判断所述弹框调用组件是否为空；

判断所述弹框调用组件是否正在处于销毁阶段；以及

判断所述弹框调用组件是否已经被销毁。

2.如权利要求1所述的模块，其特征在于，所述模块还包括：

反馈单元，用于反馈所述弹框调用组件中的异常事件。

3.如权利要求2所述的模块，其特征在于，若判定所述弹框调用组件为空，则通过所述第一容错处理单元处理，并通过所述反馈单元进行反馈。

4.如权利要求2所述的模块，其特征在于，若判定所述弹框调用组件不为空，则判断所述弹框调用组件是否正处于销毁阶段，若判定所述弹框调用组件正处于销毁阶段，则通过所述第一容错处理单元处理，并通过所述反馈单元进行反馈。

5.如权利要求4所述的模块，其特征在于，若判定所述弹框调用组件未处于销毁阶段，则判断所述弹框调用组件是否已经被销毁，若判定所述弹框调用组件已经被销毁，则通过所述第一容错处理单元处理，并通过所述反馈单元进行反馈。

6.如权利要求1所述的模块，其特征在于，所述模块还包括第二容错处理单元，所述第二容错处理单元用于处理由系统版本引起的显示函数出错而导致的弹框逻辑的异常事件。

7.如权利要求6所述的模块，其特征在于，所述第二容错处理单元包括用于捕获所述弹框逻辑的异常事件的异常捕获函数。

8.如权利要求1所述的模块，其特征在于，所述模块还包括用于处理弹框的内存泄漏事件的第三容错处理单元，当所述弹框调用组件不可见时，所述第三容错处理单元通过调用内存释放函数，以便及时释放所述弹框调用组件。

9.如权利要求8所述的模块，其特征在于，在所述内存释放函数中，通过将所述弹框调用组件的引用设置为空，以及时释放所述弹框调用组件。

10.一种电子设备，其特征在于，所述电子设备包括如权利要求1-9中任一项所述的用于提高弹框容错率的模块。