移动终端内存泄漏处理方法和装置与流程

文档序号:14266198阅读:187来源:国知局
移动终端内存泄漏处理方法和装置与流程

本发明涉及计算机技术领域,特别是涉及一种移动终端内存泄漏处理方法和装置。



背景技术:

内存泄漏是指动态存储分配函数动态开辟的空间,在使用完毕后未释放,结果导致一直占据该内存单元。内存泄漏是比较难发现的软件缺陷,危害很大,可能导致系统可用内存不断减少,最终导致系统运行不稳定,甚至崩溃重启。

目前存在的内存泄漏检测工具只能检测到内存泄漏,但对内存泄漏信息的采集、分析、修复和网络上报等后续操作都需要测试人员或者开发人员手动操作完成,需要大量的时间,处理效率较低。



技术实现要素:

基于此,有必要针对上述技术问题,提供一种能提高内存泄漏检测处理效率的移动终端内存泄漏处理方法和装置。

一种移动终端内存泄漏处理方法,包括:

移动终端检测是否发生内存泄漏;

当移动终端检测到发生内存泄漏时,采集内存泄漏相关的现场信息;

移动终端根据现场信息分析获取内存泄漏的调用栈信息;

移动终端将现场信息和调用栈信息上报至服务器;

服务器根据现场信息和调用栈信息生成漏洞单,并根据预设配置信息将漏洞单分配至相应人员。

上述移动终端内存泄漏处理方法,当移动终端检测到发生内存泄漏时,可自动采集到内存泄漏相关的现场信息,分析采集到的现场信息获取到内存泄漏的调用栈信息并一起上报至服务器。服务器可根据现场信息和调用栈信息生成漏洞单,根据预设配置信息将漏洞单分配给相应人员。由于移动终端检测到内存泄漏时会自动上报内存泄漏的现场信息和分析得到的调用栈信息,服务器生成漏洞单后可以自动分配给相应人员进行处理,实现了对内存泄漏检测、采集、分析、上报、分配等过程的自动化操作,提高了检测和处理移动终端内存泄漏的效率。

一种移动终端内存泄漏处理方法,包括:

检测是否发生内存泄漏;

当检测到发生内存泄漏时,采集内存泄漏相关的现场信息;

根据现场信息分析获取内存泄漏的调用栈信息;

将现场信息以及调用栈信上报服务器进行处理。

一种移动终端内存泄漏处理装置,包括:

检测模块,用于检测是否发生内存泄漏;

采集模块,用于当检测到发生内存泄漏时,采集内存泄漏相关的现场信息;

分析模块,用于根据现场信息分析获取内存泄漏的调用栈信息;

上报模块,用于将现场信息以及调用栈信息上报服务器进行处理。

上述移动终端内存泄漏处理方法和装置,当检测到发生内存泄漏时,可自动采集到内存泄漏相关的现场信息,分析采集到的现场信息获取内存泄漏的调用栈信息并一起上报至服务器。服务器可根据收到的现场信息和调用栈信息进行后续处理。由于检测到内存泄漏时会自动上报内存泄漏相关的现场信息和分析得到的调用栈信息,实现了对内存泄漏的检测、采集、分析、上报等过程的自动化操作,提高了检测和处理移动终端内存泄漏的效率。

附图说明

图1为一个实施例中移动终端内存泄漏处理方法的应用环境图;

图2为一个实施例中移动终端内部结构示意图;

图3为一个实施例中移动终端内存泄漏处理方法的流程图;

图4为一个实施例中移动终端内存泄漏处理方法的原理图;

图5为一个实施例中移动终端内存泄漏处理方法的详细流程图;

图6为另一个实施例中移动终端内存泄漏处理方法的流程图;

图7为又一个实施例中移动终端内存泄漏处理方法的流程图;

图8为一个实施例中移动终端内存泄漏处理装置的结构框图;

图9为另一个实施例中移动终端内存泄漏处理装置的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。

本发明实施例提供的移动终端内存泄漏处理方法可以应用在图1所示的应用环境中。参考图1所示,移动终端110与服务器120通过网络进行通信。具体的,移动终端运行客户端的测试版本或者正式版本的过程中会检测是否发生内存泄漏,当移动终端110检测到发生内存泄漏时,将自动采集内存泄漏相关的现场信息,并对现场信息进行分析获得调用栈信息,然后将现场信息以及调用栈信息上报至服务器120。服务器120中预先配置有需监听的客户端的信息表,其中记录了需要监听的客户端的版本信息、进程名称、需要监听的软件模块名称、对应处理相应漏洞单的人员标识等。进一步的,服务器120监听移动终端上报的现场信息和调用栈信息,根据现场信息和调用栈生成漏洞单,并根据预先配置的信息表将漏洞单分配给相应人员进行处理。

其中,移动终端110可以是但不仅限于是各种能运行客户端的智能手机、平板电脑、便携式可穿戴设备等。服务器120可以是网络服务器,如云端服务器。

如图2所示,提供了一种移动终端,该移动终端包括通过系统总线连接的处理器、非易失性存储介质、内存储器和网络接口、输入装置。其中,移动终端的非易失性存储介质中存储有操作系统,还包括一种移动终端内存泄漏处理装置,该内存泄漏处理装置用于实现一种移动终端内存泄漏处理方法。该处理器用于提供计算和控制能力,支撑整个移动终端的运行。移动终端中的内存储器为非易失性存储介质中的内存泄漏处理装置的运行提供环境,该内存储器中可储存有计算机可读指令,该计算机可读指令被所述处理器执行时,可使得所述处理器执行一种移动终端内存泄漏处理方法。网络接口用于与服务器进行网络通信,如发送内存泄漏相关的现场信息和调用栈信息至服务器,接收服务器返回的内存泄漏解决方案数据等。移动终端的显示屏可以是液晶显示屏或者电子墨水显示屏等,输入装置可以是显示屏上覆盖的触摸层,也可以是移动终端外壳上设置的按键、轨迹球或触控板,也可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解,图2中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的移动终端的限定,具体的移动终端可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。

如图3所示,提供了一种移动终端内存泄漏处理方法,该方法以应用于如图1所示的环境中进行举例说明,包括以下步骤:

步骤310,移动终端检测是否发生内存泄漏。

本实施例中,移动终端在不同的系统中,利用不同的工具和方法检测是否发生内存泄漏,如在安卓系统中通过检测activity的内存释放情况,检测安卓系统中是否发生内存泄漏;在linux系统中可以使用重载new和delete的方法,记录分配点,定期打印;或者使用微软的detours库,hook分配内存的系统api:heapalloc/heaprealloc/heapfree(new/malloc的底层调用),记录分配点,定期打印检测内存泄漏;使用vs检测内存泄漏,如在入口函数中包含_crtdumpmemoryleaks()。

步骤320,当移动终端检测到发生内存泄漏时,采集内存泄漏相关的现场信息。

本实施例中,当移动终端检测到发生内存泄漏时,采集内存泄漏相关的现场信息,现场信息可用于分析内存泄漏的原因,包括但不限于客户端进程运行信息、相关的代码类名称、日志信息等。

步骤330,移动终端根据现场信息分析获取内存泄漏的调用栈信息。

本实施例中,现场信息中包括代码类名称,在移动终端运行客户端的过程中,一般都是从一个代码类调用另一个代码类,另一个代码类再调用其他代码类,这种调用关系就是调用栈。根据现场信息得到调用栈之后可以分析获取调用栈信息,调用栈信息一般通过代码类名称的形式展示。调用栈信息能够反映出代码执行逻辑,从而根据调用栈信息可以分析出导致内存泄漏的原因。

步骤340,移动终端将现场信息和调用栈信息上报至服务器。

本实施例中,移动终端将采集的现场信息和分析获取的调用栈信息上传至服务器,以使服务器对内存泄漏进行后续处理。

进一步的,为了提高传输效率,可以将现场信息和调用栈信息进行压缩打包之后再上传至服务器。

本实施例中,移动终端可通过客户端来采集内存泄漏相关的现场信息,并对现场信息分析得到调用栈信息,以及能够将采集的内存泄漏相关的现场信息以及根据现场信息分析获取的调用栈信息上传至服务器,该客户端不仅可以是内部测试版本也可以是正式发布的版本,应用范围更加广泛。

步骤350,服务器根据现场信息和调用栈信息生成漏洞单,并根据预设配置信息将漏洞单分配至相应人员。

本实施例中,服务器预先配置需要监听的客户端的信息表,其中记录了需要监听的客户端的版本信息、进程名称、需要监听的软件模块名称、对应处理相应漏洞单的人员标识等。当服务器监听到运行有需监听的客户端的移动终端上报的现场信息和调用栈信息后,根据现场信息和调用栈信息在对应的软件模块生成相应的漏洞单。服务器根据预设配置的软件模块名称、对应处理相应漏洞单的人员标识,将生成的漏洞单分配至相应的人员。进一步的,相应人员在收到漏洞单之后,可根据漏洞单对内存泄漏进行处理。

上述移动终端内存泄漏处理方法,当移动终端检测到发生内存泄漏时,可自动采集到内存泄漏相关的现场信息,分析采集到的现场信息获取到内存泄漏的调用栈信息并一起上报至服务器。服务器可根据现场信息和调用栈信息生成漏洞单,根据预设配置信息将漏洞单分配给相应人员。由于移动终端检测到内存泄漏时会自动上报内存泄漏的现场信息和分析得到的调用栈信息,服务器生成漏洞单后可以自动分配给相应人员进行处理,实现了对内存泄漏检测、采集、分析、上报、分配等过程的自动化操作,提高了检测和处理移动终端内存泄漏的效率。

在一个实施例中,上述移动终端内存泄漏处理方法中现场信息包括客户端进程运行信息、相关代码类名称和日志信息中的至少一种。

本实施例中,客户端进程运行信息可以用来分析得到内存泄漏的调用栈信息。对于不同操作系统的移动终端,记录客户端进程运行信息的文件格式有所不同。例如,对于android系统,可使用hprof文件来记录客户端进程运行信息。

代码类是面向对象程序设计中的概念,是从某一特征的事物抽象出来的数据类型。客户端运行时,一般都是从一个代码类调用另一个代码类,另一个代码类再调用其他的代码类;这个调用关系就是调用栈,内存泄漏时的调用栈一般都是通过代码类名称的形式展示。

日志信息是程序开发人员根据代码的执行逻辑自行添加的打印信息,一般是能够表示程序执行阶段逻辑的信息。例如,“已经创建解码器对象”、“开始播放视频”等。具体的,可在移动终端的存储空间中创建文件保存日志信息,生成日志文件。本实施例中,移动终端内存泄漏相关的现场信息可用来进行分析以得到导致发生内存泄漏的原因,从而对客户端版本进行改进。

在一个实施例中,上述移动终端内存泄漏处理方法还包括:当移动终端检测到发生内存泄漏时,对发生内存泄漏的页面中占据内存资源的数据进行释放。

本实施例中,当移动终端检测到发生内存泄漏时,对发生内存泄漏的页面中的图片等占据内存资源的数据进行释放,尽可能减少内存泄漏对系统内存造成的影响。

如图4所示,提供了一种移动终端内存泄漏处理方法的原理图,具体过程如下:

步骤410,检测到内存泄漏。

具体的,当用户或者测试人员正常操作移动终端中的客户端的过程中,例如,用户操作客户端的正式版本,或者测试人员操作客户端的测试版本,客户端会检测是否发生内存泄漏。如果检测到内存泄漏,会自动进入后续步骤420-470。

步骤420,采集内存泄漏相关的现场信息。具体的,移动终端自动采集分析内存泄漏相关的现场信息,这里所说的现场信息包括客户端进程运行信息、日志信息、相关的代码类名称等。

步骤430,分析内存泄漏的调用栈。具体的,移动终端自动分析现场信息,分析获取移动终端发生内存泄漏时的内部代码的调用栈信息。

步骤440,修复移动终端内存泄漏。具体的,移动终端自动根据解析出的调用栈信息,对发生内存泄漏的页面中占据内存泄漏的资源释放掉,尽量减少内存泄漏对系统内存的影响。

步骤450,信息上传网络服务器。具体的,移动终端在修复移动终端内存泄漏的同时自动将采集的内存泄漏相关的现场信息和分析得到的调用栈信息上报到对应的网络服务器。

步骤460,网络服务器创建漏洞单。具体的,网络服务器接收到上报的内存泄漏相关的现场信息和调用栈信息后,首先查询漏洞单中是否有相同的漏洞单信息,如果有,则不创建漏洞单,而是在对应的漏洞单中增加内存泄漏相关的现场信息和调用栈信息;如果没有,则自动创建该内存泄漏的漏洞单,并把上报的内存泄漏相关的现场信息和调用栈信息添加到漏洞单中。

步骤470,把漏洞单分配给对应的开发人员。具体的,网络服务器会根据之前设置好的开发人员与软件模块对应表以及内存泄漏的调用栈,把漏洞单自动分配给对应的开发人员。

步骤480,开发人员分析解决内存泄漏问题。具体的,开发人员根据服务器分配的漏洞单,处理解决对应的内存泄漏问题。

上述步骤410-470都是客户端和网络服务器自动完成的,不需要任何人工操作。实现了对内存泄漏的检测、采集现场信息、分析调用栈、修复、网络上报、创建漏洞单、分配开发人员等流程的自动化处理,对内存泄漏检测处理效率更高,并且应用的场景更广泛,可以适用于内部测试版本客户端和正式发布版本客户端。

而传统的技术中,在操作客户端时只能检测到内存泄漏,后续的内存泄漏相关现场信息的采集、分析调用栈、修复、网络上报、创建漏洞单、分配开发人员等流程均需要相应人员手动操作完成,内存泄漏问题的解决效率较低;并且只能在内部测试版本客户端中使用,开发人员无法获取用户在使用发布版本客户端过程中遇到的内存泄漏问题,适用范围较小。

如图5所示,以安卓系统为例,提供一种移动终端内存泄漏处理方法,该方法以应用于如图1所示的环境中进行举例说明,包括以下步骤:

步骤501,启动客户端,注册所有activity的生命周期监听。

本实施例中,activity是安卓系统的基础组件之一,简单的描述activity就是每个用户看到的界面,每一屏就是一个activity,activity里面包含着各种控件,比如文本框、按钮等。

本实施例中,在application初始化的时候调用安卓系统的接口registeractivitylifecyclecallbacks,注册客户端中所有activity的生命周期监听回调。上述application是安卓系统中客户端的代码基本类,用来保存全局变量,在客户端开始在安卓系统中创建运行的时候就已经存在了。

步骤502,正常操作客户端的过程中检测是否发生activity销毁回调,若是,执行步骤503,若否,执行步骤508。

本实施例中,activity销毁回调是指一个名称为onactivitydestroyed的安卓系统通知客户端的接口。当activity开始销毁时,安卓系统通过调用该接口通知客户端。当客户端application监听到该activity回调时,将开始执行内存泄漏的检测流程。

步骤503,检测activity是否存在弱引用,若是,则执行步骤505,若否,则执行步骤508。

本实施例中,弱引用是指安卓系统中指向程序对象,又不影响系统对程序对象回收的代码类;可以用于安卓客户端activity内存泄漏的检测。当检测到activity发生销毁回调时,意味着安卓系统要销毁该activity,即正常销毁该activity内部的各种资源。如果存在某个资源无法被正常释放,该activity就不会被销毁,表明发生了内存泄漏。

具体的,当检测到一个activity发生销毁回调时,根据该activity创建一个对应的弱引用对象(例如:可以命名为ref),弱引用对象不影响activity的销毁和资源的释放,如果该activity能够被正常释放,则弱引用对象的指向内容就为空,即ref.get()==null,说明该activity没有内存泄漏;如果activity未被正常销毁,弱引用对象指向的内容就不为空,说明该activity存在内存泄漏。

步骤504,采集内存泄漏相关现场信息。

本实施例中,当客户端检测到内存泄漏时,采集内存泄漏的相关现场信息。这里所说的现场信息包括进程的hprof文件信息、相关的代码类名称、开发人员提前埋置的log日志信息、设备型号信息、客户端版本信息等。

其中,hprof文件信息是一种安卓系统中用于记录客户端进程运行信息的文件格式,主要存储的是特定时间点,安卓客户端进程的内存快照、堆栈信息、cpu使用情况、不同线程的调用等。可以用于分析安卓客户端发生内存泄漏时的代码调用栈信息。

代码类是面向对象程序设计中的概念,是从某一特征的事物抽象出来的数据类型。客户端运行时,一般都是从一个代码类调用另一个代码类,另一个代码类再调用其他的代码类;这个调用关系就是调用栈,内存泄漏时的调用栈一般都是通过代码类名称的形式展示。

log日志信息是程序开发人员根据代码的执行逻辑自行添加的打印信息,一般是能够表示程序执行阶段逻辑的信息。

设备型号信息、客户端版本信息便于开发人员分析解决内存泄漏问题,因为不同的客户端版本对应的程序源代码是不一样的,开发人员需要同时根据调用栈和源代码来分析解决内存泄漏问题。

步骤505,根据现场信息分析调用栈。

本实施例中,根据现场信息分析获取内存泄漏的调用栈信息主要是根据采集的内存泄漏相关现场信息中的hprof进程文件信息分析获取内存泄漏的调用栈信息。

步骤506,对内存泄漏进行修复。

本实施例中,当移动终端检测到发生内存泄漏时,对相关的activity内部所有占用内存的资源进行遍历,把图片资源等一些占内存的数据释放掉,保证内存泄漏只会泄漏一个空壳。即对内存泄漏进行修复,保证内存泄漏占用较小的系统内存。

步骤507,将内存泄漏相关信息上报服务器。

本实施例中,客户端将内存泄漏的现场信息和调用栈信息上报至服务器。以使服务器对内存泄漏进行后续处理。为了方便上传可以先将现场信息和调用栈信息压缩打包之后再上传至服务器。

步骤508,继续运行客户端。

本实施例中,若客户端没有检测到activity销毁回调,则说明此时客户端运行过程中没有需要销毁的activity,即没有需要销毁的内部资源,则继续运行客户端。

本实施例中,若客户端检测到发生activity销毁回调,说明客户端需要销毁该activity内部的各种资源。在发生activity销毁回调时,根据该activity创建一个对应的弱引用对象,该弱引用对象对activity中资源是否能够正常释放具有指向作用。当检测到activity中不存在弱引用时,说明该activity对应的弱引用指向为空,即activity中的内存资源被正常释放,即没有发生内存泄漏,继续运行客户端。

本实施例中,当客户端检测到发生内存泄漏后,对内存泄漏进行采集、分析及上报处理。完成一系列处理过程之后,因为内存泄漏不会直接导致客户端崩溃,所以客户端会继续运行并重复上述操作过程,继续对内存泄漏进行检测处理。

步骤509,服务器监听客户端上报的内存泄漏相关信息。

本实施例中,在步骤509之前,还包括步骤509a,服务器配置相关信息表。

具体的,服务器预先配置需要监听的客户端的信息表,其中记录了需要监听的客户端的版本信息、进程名称、需要监听的软件模块名称、对应处理相应漏洞单的人员标识、软件模块与相应人员的对应表等。

步骤509b,启动服务。

具体的,信息表配置完成之后,在网络服务器上启动服务,以使服务器对需要监听的客户端上报的内存泄漏相关的现场信息和调用栈信息进行监听。

本实施例中,服务器根据预设配置信息对需要监听的客户端进行监听,接收运行有客户端的移动终端上传的内存泄漏相关信息,包括调用栈信息、hprof文件、log日志文件、客户端版本信息等。

步骤510,服务器创建漏洞单。

本实施例中,根据上报的内存泄漏信息,并调用bug系统的接口,创建内存泄漏的bug单(漏洞单)。具体的,服务器接收到上报的内存泄漏相关的现场信息和调用栈信息后,首先查询漏洞单系统中是否存在相同的漏洞单信息,这里所说的相同的漏洞单信息是指调用栈和版本信息一样。如果存在,则不创建漏洞单,在对应的漏洞单中增加内存泄漏相关的现场信息和调用栈信息;如果不存在,则自动创建该内存泄漏的漏洞单,并把上报的内存泄漏相关的现场信息和调用栈信息添加到漏洞单中。

步骤511,服务器分配漏洞单给相应的人员。

本实施例中,服务器生成漏洞单之后,根据预先配置的软件模块与相应人员的对应信息将漏洞单分配给相应的人员。

具体的,一个相应开发人员对应一个软件模块,一个软件模块可以包括多个漏洞单,服务器根据生成的漏洞单获取对应的预先配置的软件模块名称,然后再根据软件模块与相应人员的对应表,将生成的漏洞信息分配给相应的开发人员。

进一步的,开发人员可根据服务器接收到的调用栈信息以及版本信息分析解决内存泄漏问题。具体的,在安卓系统中,不同的客户端版本对应的程序源代码是不一样的,开发人员根据版本信息获取源代码并结合调用栈信息分析代码逻辑,以分析解决内存泄漏问题。

进一步的,当开发人员解决处理内存泄漏问题后,将更新后的版本上传,客户端可通过下载更新后的版本解决内存泄漏问题。

本实施例中,安装有安卓系统的移动终端,可自动检测内存泄漏,并在检测到内存泄漏后自动上报内存泄漏的现场信息和分析得到的调用栈信息,并在上报服务器的同时自动对内存泄漏进行修复;服务器根据内存泄漏相关信息生成漏洞单并根据漏洞单自动分配给相应人员。实现了内存泄漏检测、采集、分析、修复、上报及分配等过程的自动化操作,不仅提高检测和处理移动终端内存泄漏效率,还可以在正式发布的版本中使用,应用更加广泛。

如图6所示,提供了一种移动终端内存泄漏处理方法,该方法以应用于如图1和图2所示的移动终端中进行举例说明,包括以下步骤:

步骤610,检测是否发生内存泄漏。

本实施例中,在不同的操作系统中,利用不同的工具和方法检测是否发生内存泄漏,如在安卓系统中通过检测activity的内存释放情况,检测安卓系统中是否发生内存泄漏;在linux系统中可以使用重载new和delete的方法,记录分配点,定期打印;或者使用微软的detours库,hook分配内存的系统api:heapalloc/heaprealloc/heapfree(new/malloc的底层调用),记录分配点,定期打印检测内存泄漏;使用vs检测内存泄漏,如在入口函数中包含_crtdumpmemoryleaks()。

步骤620,当检测到发生内存泄漏时,采集内存泄漏相关的现场信息。

本实施例中,当检测到发生内存泄漏时,采集内存泄漏相关的现场信息,现场信息可用于分析内存泄漏的原因,包括但不限于客户端进程运行信息、相关代码类名称、日志信息等。

步骤630,根据现场信息分析获取内存泄漏的调用栈信息。

本实施例中,现场信息中包括代码类名称,在移动终端运行客户端的过程中,一般都是从一个代码类调用另一个代码类,另一个代码类再调用其他代码类,这种调用关系就是调用栈。根据现场信息得到调用栈之后可以分析获取调用栈信息,调用栈信息一般通过代码类名称的形式展示。调用栈信息能够反映出代码执行逻辑,从而根据调用栈信息可以分析出导致内存泄漏的原因。

步骤640,将现场信息以及调用栈信息上报服务器进行处理。

本实施例中,将采集的现场信息和分析获取的调用栈信息上传至服务器,以使服务器对内存泄漏进行后续处理。

进一步的,为了提高传输效率,可以将现场信息和调用栈信息进行压缩打包之后再上传至服务器。

本实施例中,能够采集内存泄漏相关的现场信息,并根据现场信息分析得到调用栈信息,以及能够将采集的内存泄漏相关的现场信息以及根据现场信息分析获取的调用栈信息上传至服务器,不仅可以应用在内部测试版本也可以应用在正式发布的版本,应用范围更加广泛。

上述移动终端内存泄漏处理方法,当检测到发生内存泄漏时,可自动采集到内存泄漏相关的现场信息,分析采集到的现场信息获取内存泄漏的调用栈信息并一起上报至服务器。服务器可根据收到的现场信息和调用栈信息进行后续处理。由于检测到内存泄漏时会自动上报内存泄漏相关的现场信息和分析得到的调用栈信息,实现了对内存泄漏的检测、采集、分析、上报等过程的自动化操作,提高了检测和处理移动终端内存泄漏的效率。

在一个实施例中,上述移动终端内存泄漏处理方法中现场信息包括客户端进程运行信息、相关代码类名称和日志信息中的至少一种。

本实施例中,客户端进程运行信息可以用来分析得到内存泄漏的调用栈信息。对于不同操作系统,记录客户端进程运行信息的文件格式有所不同。例如,对于android系统,可使用hprof文件来记录客户端进程运行信息。

代码类是面向对象程序设计中的概念,是从某一特征的事物抽象出来的数据类型。客户端运行时,一般都是从一个代码类调用另一个代码类,另一个代码类再调用其他的代码类;这个调用关系就是调用栈,内存泄漏时的调用栈一般都是通过代码类名称的形式展示。

日志信息是程序开发人员根据代码的执行逻辑自行添加的打印信息,一般是能够表示程序执行阶段逻辑的信息。例如,“已经创建解码器对象”、“开始播放视频”等。具体的,可在移动终端的存储空间中创建文件保存日志信息,生成日志文件。本实施例中,内存泄漏相关的现场信息可用来进行分析以得到导致发生内存泄漏的原因,从而对客户端版本进行改进。

在一个实施例中,上述移动终端内存泄漏处理方法还包括:当检测到发生内存泄漏时,对发生内存泄漏的页面中占据内存资源的数据进行释放。

本实施例中,当检测到发生内存泄漏时,对发生内存泄漏的页面中的图片等占据内存资源的数据进行释放,以尽可能减少内存泄漏对内存造成的影响。

在一个实施例中,客户端进程运行信息为二进制格式的进程文件信息;根据现场信息分析获取内存泄漏的调用栈信息,包括:读取进程文件信息中的二进制流,将二进制流转换成对应的字符串;根据字符串抽取出调用栈,生成调用栈信息。

在一个实施例中,将现场信息以及调用栈信息上报服务器进行处理,包括:将现场信息和调用栈信息上报给服务器,现场信息和调用栈信息用于使服务器根据现场信息和调用栈信息生成漏洞单,漏洞单用于使服务器根据预设配置信息分配给相关人员。

在一个实施例中,将漏洞单用于使服务器根据预设配置信息分配给相关人员,包括:根据漏洞单匹配对应的软件模块,使服务器根据预设的软件模块与相关人员对应表将漏洞单分配给相关人员。

本实施例中,采集的现场信息和分析获取的调用栈信息生成漏洞单,不同的漏洞单根据现场信息和调用栈信息的不同,对应不同的软件模块,漏洞单在相应的软件模块中生成,使服务器根据预先设置的软件模块与相应人员对应表,将发生内存泄漏的软件模块的漏洞单分配给相应人员。

如图7所示,以安卓系统为例,提供一种移动终端内存泄漏处理方法,该方法以应用于如图1所示的环境中进行举例说明,包括以下步骤:

步骤701,启动客户端,注册所有activity的生命周期监听。

本实施例中,activity是安卓系统的基础组件之一,简单的描述activity就是每个用户看到的界面,每一屏就是一个activity,activity里面包含着各种控件,比如文本框、按钮等。

本实施例中,在application初始化的时候调用安卓系统的接口registeractivitylifecyclecallbacks,注册客户端中所有activity的生命周期监听回调。上述application是安卓系统中客户端的代码基本类,用来保存全局变量,在客户端开始在安卓系统中创建运行的时候就已经存在了。

步骤702,正常操作客户端的过程中检测是否发生activity销毁回调,若是,执行步骤703,若否,执行步骤708。

本实施例中,activity销毁回调是指一个名称为onactivitydestroyed的安卓系统通知客户端的接口。当activity开始销毁时,安卓系统通过调用该接口通知客户端。当客户端application监听到该activity回调时,将开始执行内存泄漏的检测流程。

步骤703,检测activity是否存在弱引用,若是,则执行步骤705,若否,则执行步骤708。

本实施例中,弱引用是指安卓系统中指向程序对象,又不影响系统对程序对象回收的代码类;可以用于安卓客户端activity内存泄漏的检测。当检测到activity发生销毁回调时,意味着安卓系统要销毁该activity,即正常销毁该activity内部的各种资源。如果存在某个资源无法被正常释放,该activity就不会被销毁,表明发生了内存泄漏。

具体的,当检测到一个activity发生销毁回调时,根据该activity创建一个对应的弱引用对象,弱引用对象不影响activity的销毁和资源的释放,如果该activity能够被正常释放,则弱引用对象的指向内容就为空,即ref.get()==null,说明该activity没有内存泄漏;如果activity未被正常销毁,弱引用对象指向的内容就不为空,说明该activity存在内存泄漏。

步骤704,采集内存泄漏相关现场信息。

本实施例中,当检测到内存泄漏时,采集内存泄漏的相关现场信息。这里所说的现场信息包括进程的hprof文件信息、相关的代码类名称、开发人员提前埋置的log日志信息、设备型号信息、客户端版本信息等。

其中,hprof文件信息是一种安卓系统中用于记录客户端进程运行信息的文件格式,主要存储的是特定时间点,安卓客户端进程的内存快照、堆栈信息、cpu使用情况、不同线程的调用等。可以用于分析安卓客户端发生内存泄漏时的代码调用栈信息。

代码类是面向对象程序设计中的概念,是从某一特征的事物抽象出来的数据类型。客户端运行时,一般都是从一个代码类调用另一个代码类,另一个代码类再调用其他的代码类;这个调用关系就是调用栈,内存泄漏时的调用栈一般都是通过代码类名称的形式展示。

log日志信息是程序开发人员根据代码的执行逻辑自行添加的打印信息,一般是能够表示程序执行阶段逻辑的信息。

设备型号信息、客户端版本信息便于开发人员分析解决内存泄漏问题,因为不同的客户端版本对应的程序源代码是不一样的,开发人员需要同时根据调用栈和源代码来分析解决内存泄漏问题。

步骤705,根据现场信息分析调用栈。

本实施例中,根据现场信息分析获取内存泄漏的调用栈信息主要是根据采集的内存泄漏相关现场信息中的hprof进程文件信息分析获取内存泄漏的调用栈信息。

进一步的,hprof进程文件是一种二进制文件,通过读取hprof进程文件中的二进制流,并将二进制流转化成字符串,根据字符串抽取出调用栈,生成调用栈信息。

步骤706,对内存泄漏进行修复。

本实施例中,当检测到发生内存泄漏时,对相关的activity内部所有占用内存的资源进行遍历,把图片资源等一些占内存的数据释放掉,保证内存泄漏只会泄漏一个空壳。即对内存泄漏进行修复,保证内存泄漏占用较小的系统内存。

步骤707,将内存泄漏相关信息上报服务器进行处理。

本实施例中,将内存泄漏的现场信息和调用栈信息上报至服务器。以使服务器对内存泄漏进行后续处理。为了方便上传可以先将现场信息和调用栈信息压缩打包之后再上传至服务器。具体的,将现场信息和调用栈信息上报服务器,现场信息和调用栈信息用于使服务器根据现场信息和调用栈信息生成漏洞单,漏洞单用于使服务器根据漏洞单匹配对应的软件模块,并根据预设的软件模块与相关人员对应表将漏洞单分配给相关人员。

步骤708,继续运行客户端。

本实施例中,若没有检测到activity销毁回调,则说明此时客户端运行过程中没有需要销毁的activity,即没有需要销毁的内部资源,则继续运行客户端。

本实施例中,若检测到发生activity销毁回调,说明需要销毁该activity内部的各种资源,在发生activity销毁回调时,根据该activity创建一个对应的弱引用对象,该弱引用对象对activity中资源是否能够正常释放具有指向作用。当检测到activity中不存在弱引用时,说明该activity对应的弱引用指向为空,即activity中的内存资源被正常释放,即没有发生内存泄漏,继续运行客户端。

本实施例中,当检测到发生内存泄漏后,对内存泄漏进行采集、分析及上报处理。完成一系列处理过程之后,因为内存泄漏不会直接导致客户端崩溃,所以客户端会继续运行并重复上述操作过程,继续对内存泄漏进行检测处理。

本实施例中,启动客户端,监听activity销毁回调检测内存泄漏,采集相关的现场信息并根据现场信息分析获取调用栈信息,并将内存泄漏的现场信息和分析得到的调用栈信息上报至服务器进行处理,同时对内存泄漏进行修复。实现了内存泄漏检测、采集、分析、修复、上报等过程的自动化操作,不仅提高检测和处理移动终端内存泄漏效率,还可以在正式发布的版本中使用,应用场景广泛。

如图8所示,提供了一种移动终端内存泄漏处理装置,包括:

检测模块810,用于检测是否发生内存泄漏。

采集模块820,用于当检测到发生内存泄漏时,采集内存泄漏相关的现场信息。

分析模块830,用于根据现场信息分析获取内存泄漏的调用栈信息。

上报模块840,用于将现场信息以及调用栈信息上报服务器进行处理。

上述移动终端内存泄漏处理装置,当检测到发生内存泄漏时,可自动采集到内存泄漏相关的现场信息,分析采集到的现场信息获取内存泄漏的调用栈信息并一起上报至服务器。服务器可根据收到的现场信息和调用栈信息进行后续处理。由于检测到内存泄漏时会自动上报内存泄漏相关的现场信息和分析得到的调用栈信息,实现了对内存泄漏的检测、采集、分析、上报等过程的自动化操作,提高了检测和处理移动终端内存泄漏的效率。

在一个实施例中,现场信息包括客户端进程运行信息、相关的代码类名称和日志信息中的至少一种。

在一个实施例中,客户端进程运行信息为二进制格式的进程文件信息;分析模块830,用于读取进程文件信息中的二进制信息,将二进制信息转换成对应的字符串,根据字符串抽取出调用栈,生成调用栈信息。

在一个实施例中,上报模块840还用于将现场信息和调用栈信息上报给服务器,现场信息和调用栈信息用于使服务器根据现场信息和调用栈信息生成漏洞单,漏洞单用于使服务器根据预设配置信息分配给相关人员。

如图9所示,提供了一种移动终端内存泄漏处理装置,包括:

检测模块910,用于检测是否发生内存泄漏。

采集模块920,用于当检测到发生内存泄漏时,采集内存泄漏相关的现场信息。

分析模块930,用于根据现场信息分析获取内存泄漏的调用栈信息。

上报模块940,用于将现场信息以及调用栈信息上报服务器进行处理。

修复模块950,用于当检测到发生内存泄漏时,对发生内存泄漏的页面中占据内存资源的数据进行释放。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一非易失性计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(read-onlymemory,rom)等。

以上所述实施例仅表达了本发明的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对本发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进,这些都属于本发明的保护范围。因此,本发明专利的保护范围应以所附权利要求为准。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1