首页> 中国专利> 基于字节码插桩技术的应用程序故障诊断方法和装置

基于字节码插桩技术的应用程序故障诊断方法和装置

摘要

本公开提供了基于字节码插桩技术的应用程序故障诊断方法,包括:在应用程序的运行过程中,获取一级容器对应的界面的运行结果和一级容器中的二级容器的基础信息,所述基础信息包括二级容器的名称、方法的类、方法类型、方法的输入参数信息和方法的输出参数信息;响应于当前一级容器对应的界面发生故障,将所述当前一级容器中的二级容器的基础信息和故障信息关联,生成故障报警信息;将所述故障报警信息上报至后台服务器。以此方式,能够提升应用程序页面的获取粒度,有效降低应用程序故障分析和修复周期,节约人力成本和时间成本,提高用户体验。

著录项

  • 公开/公告号CN113010415A

    专利类型发明专利

  • 公开/公告日2021-06-22

    原文格式PDF

  • 申请/专利权人 北京每日优鲜电子商务有限公司;

    申请/专利号CN202110209993.3

  • 发明设计人 赵欢欢;

    申请日2021-02-24

  • 分类号G06F11/36(20060101);

  • 代理机构11664 北京华专卓海知识产权代理事务所(普通合伙);

  • 代理人王一

  • 地址 100102 北京市朝阳区望京街9号商业楼3层1-302号076室

  • 入库时间 2023-06-19 11:32:36

说明书

技术领域

本公开的实施例一般涉及互联网技术领域,并且更具体地,涉及基于字节码插桩技术的应用程序故障诊断方法和装置。

背景技术

随着智能终端的日益普及、网络宽带化的高速发展,以移动应用与服务不断丰富为标志的移动互联网时代为人们带来了更便捷与智能的数字生活。在这种大环境下,线上商城应用而生,用户可有通过线上商城应用程序(移动APP)购买物品。在用户使用应用程序中,难以避免的会存在一些故障,例如卡顿、程序崩溃等。

现有技术中,当应用程序发生故障时,通常是由开发人员程序的行为日志进行分析,进而确定应用程序发生故障的原因,在确定应用程序的故障原因后,对应用程序的代码进行修改。

现有技术中开发人员分析的行为日志是针对应用程序的页面进行的,粒度较大,造成的分析周期较长,精度低,造成了人力成本和时间成本的浪费,同时由于故障分析和修复周期较长,影响了用户体验。

发明内容

根据本公开的实施例,提供了一种能够有效降低应用程序故障分析和修复周期,节约人力成本和时间成本,提高用户体验的基于字节码插桩技术的应用程序故障诊断方案。

在本公开的第一方面,提供了一种基于字节码插桩技术的应用程序故障诊断方法,包括:

在应用程序的运行过程中,获取一级容器对应的界面的运行结果和一级容器中的二级容器的基础信息,所述基础信息包括二级容器的名称、方法的类、方法类型、方法的输入参数信息和方法的输出参数信息;

响应于当前一级容器对应的界面发生故障,将所述当前一级容器中的二级容器的基础信息和故障信息关联,生成故障报警信息;

将所述故障报警信息上报至后台服务器。

如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述获取一级容器对应界面的运行结果和一级容器中的二级容器的基础信息,包括:

基于字节码插桩技术对所述应用程序的底层代码进行修改,并在所述应用程序的运行过程中,获取一级容器对应界面的运行结果和一级容器中的二级容器的基础信息。

如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,在所述响应于当前一级容器对应的界面发生故障,将当前一级容器中的二级容器的基础信息和故障信息关联,生成故障报警信息之后,所述方法还包括:

获取故障信息,将所述故障信息与预设故障类型进行匹配,确定所述故障信息对应的故障类型。

如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述预设故障类型包括应用程序崩溃,和/或,应用程序页面性能下降,和/或,应用程序网络错误。

如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述将当前一级容器中的二级容器的基础信息和故障信息关联,生成故障报警信息,包括:

获取后台的行为日志,基于所述行为日志确定所述故障信息,将当前一级容器中的二级容器的基础信息和故障信息关联,生成故障报警信息。

如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述生成故障报警信息,包括:

获取当前一级容器中的二级容器的名称及运行日志,将当前一级容器对应的界面的名称和故障信息关联,以及添加各二级容器的名称和对应的运行日志后,生成故障报警信息。

如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,在所述生成故障报警信息后,还包括:

获取当前时间点信息,根据所述当前时间点信息将所述故障报警信息添加到故障信息列表中。

在本公开的第二方面,提供了一种基于字节码插桩技术的应用程序故障诊断装置,包括:

信息获取模块,用于在应用程序的运行过程中,获取一级容器对应的界面的运行结果和一级容器中的二级容器的基础信息,所述基础信息包括二级容器的名称、方法的类、方法类型、方法的输入参数信息和方法的输出参数信息;

故障报警信息生成模块,用于响应于当前一级容器对应的界面发生故障,将所述当前一级容器中的二级容器的基础信息和故障信息关联,生成故障报警信息;

故障报警信息上报模块,用于将所述故障报警信息上报至后台服务器。

在本公开的第三方面,提供了一种电子设备,包括存储器和处理器,所述存储器上存储有计算机程序,所述处理器执行所述程序时实现如以上所述的方法。

在本公开的第四方面,提供了一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时实现如以上所述的方法。

应当理解,发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征,亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。

通过本公开的基于字节码插桩技术的应用程序故障诊断方法,通过提升应用程序页面的获取粒度,有效降低应用程序故障分析和修复周期,节约人力成本和时间成本,提高用户体验。

附图说明

结合附图并参考以下详细说明,本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中,相同或相似的附图标记表示相同或相似的元素,其中:

图1示出了本公开实施例一的基于字节码插桩技术的应用程序故障诊断方法的流程图;

图2示出了本公开实施例二的基于字节码插桩技术的应用程序故障诊断方法的流程图;

图3示出了本公开实施例三的基于字节码插桩技术的应用程序故障诊断装置的功能结构示意图;

图4示出了本公开实施例四的基于字节码插桩技术的应用程序故障诊断设备的结构示意图。

具体实施方式

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

另外,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。

本公开实施例的基于字节码插桩技术的应用程序故障诊断方法,通过在应用程序开发前期,利用字节码插桩技术在底层代码中插入监听字节码,使得在应用程序运行的过程中能够输出类参数,或者对已有应用程序的底层代码进行修改,利用字节码插桩技术插入监听字节码,使得在应用程序运行的过程中能够输出类参数,相对于现有技术中的应用程序在运行过程中只能够输出活动页面(Activity)的类参数而言,本公开实施例的方法可以输出活动页面中元素(Fragment)的类参数,从而提升应用程序页面的获取粒度,当应用程序发生故障时,通过上报细粒度的故障信息能够有效降低应用程序故障分析和修复周期,节约人力成本和时间成本,提高用户体验。

字节码插桩技术即通过某种策略将一段代码插入到另一段代码中,或替换另一段代码。本公开利用字节码插桩技术对应用程序的代码进行修改,使得能够输出二级容器(即活动页面中元素)的类参数(包括名称等),从而提升应用程序页面的获取粒度。

具体地,如图1所示,为本公开实施例一的基于字节码插桩技术的应用程序故障诊断方法的流程图。从图1中可以看出,本实施例的方法,可以包括以下步骤:

S101:在应用程序的运行过程中,获取一级容器对应的界面的运行结果和一级容器中的二级容器的基础信息,所述基础信息包括二级容器的名称、方法的类、方法类型、方法的输入参数信息和方法的输出参数信息。

本实施例的应用程序是指经过字节码插桩技术处理过底层代码的应用程序。通常情况下,应用程序的底层代码中包括多个一级容器,每个一级容器中又包含多个二级容器。本实施例中的一级容器是指Activity,即用户操作的可视化界面,用于为用户提供一个完成操作指令的窗口。本实施例中的二级容器是指Fragment,即Activity界面的一个组成部分,Activity界面可以由多个Fragment组成。

现有技术中,应用程序的底层代码只能调用一级容器的类函数输出一级容器的参数,而本实施例对应用程序的底层代码进行字节码插桩,在应用程序的运行过程中,调用二级容器的类函数输出对应二级容器的参数,本实施例及后续实施例中的参数一般是指名称,此外,在其他实施例中,根据实际需要,还可以输出其他参数。具体地,可以利用字节码插桩技术在二级容器对应的界面的程序的运行过程中,获取该程序的基础信息,包括程序中方法的类、方法类型、方法的输入参数信息和方法的输出参数信息,例如,可以通过以下代码获取方法的类:

ClassPool pool=ClassPool.getDefault();

//获取类

CtClassctClass=pool.get(org.itstack.demo.javassist.ApiTest.class.getName());

ctClass.replaceClassName("ApiTest","ApiTest02");

String clazzName=ctClass.getName();

通过以下代码获取方法类型:

boolean isStatic=(methodInfo.getAccessFlags()&AccessFlag.STATIC)!=0;

通过以下代码获取方法的输入参数信息:

CodeAttribute codeAttribute=methodInfo.getCodeAttribute();

LocalVariableAttributeattr=(LocalVariableAttribute)

codeAttribute.getAttribute(LocalVariableAttribute.tag);

CtClass[]parameterTypes=ctMethod.getParameterTypes();

通过以下代码获取方法的输出参数信息:

CtClass returnType=ctMethod.getReturnType();

String returnTypeName=returnType.getName()。

在应用程序的运行过程中,当用户切换界面时,其在底层实际切换的是一级容器,即显示的一级容器中的函数和堆栈。

本实施例中的应用程序可以是线上商城APP,用户可以通过该应用程序实现支付和购买商品。在本实施例中,通过字节码插桩技术,在应用程序的运行过程中,获取一级容器的运行结果的同时,获取一级容器中包括的二级容器的基础信息。二级容器例如可以是应用程序的某个页面的图标、按钮、显示框或者文字信息等。

S102:响应于当前一级容器对应的界面发生故障,将所述当前一级容器中的二级容器的基础信息和故障信息关联,生成故障报警信息。

在本实施例中,当当前一级容器对应的界面发生故障时,将当前二级容器对应的界面的名称和故障信息关联,生成故障报警信息,例如,生成报文,报文的内容包括二级容器对应的界面的名称和故障信息。即通过生成报文的形式可以实现将当前二级容器对应的界面的名称和故障信息关联,进而生成故障报警信息。

S103:将所述故障报警信息上报至后台服务器。

在生成故障报警信息后,将生成的故障报警信息上报至后台服务器。例如,可以将生成包括二级容器对应的界面的名称和故障信息的报文上报至后台服务器。后台的运维人员可以根据上报的故障报警信息对发生的故障进行处理。由于上报的故障报警信息对应的是二级容器的粒度,相对于现有技术中的故障报警信息对应一级容器的粒度而言,故障的定位和类型更加准去,有助于运维人员快速修复故障。

通过本公开的基于字节码插桩技术的应用程序故障诊断方法,通过提升应用程序页面的获取粒度,有效降低应用程序故障分析和修复周期,节约人力成本和时间成本,提高用户体验。

如图2所示,为本公开实施例二的基于字节码插桩技术的应用程序故障诊断方法的流程图。从图2中可以看出,本实施例的方法,可以包括以下步骤:

S201:基于字节码插桩技术对所述应用程序的底层代码进行修改。

需要说明的是,在应用程序开发时直接基于字节码插桩技术对应用程序的底层代码进行编写或者是基于字节码插桩技术对已有应用程序的底层代码进行修改,都能够取得本公开的技术方案的效果。本实施针对利用基于字节码插桩技术对应用程序的底层代码进行修改的技术方案对本公开的技术方案的原理进行说明。

对于已有的应用程序,基于字节码插桩技术对所述应用程序的底层代码进行修改。

S202:在应用程序的运行过程中,获取一级容器对应的界面的运行结果和一级容器中的二级容器的基础信息,所述基础信息包括二级容器的名称、方法的类、方法类型、方法的输入参数信息和方法的输出参数信息。

当上述的应用程序在运行过程中,对于每一个一级容器对应的界面,获取该界面的运行结果。例如,一级容器对应的界面可以是APP中的个人中心界面,该界面的运行结果可以是用户点击界面中的控件返回的数据,例如点击控件后界面之间的跳转,二级容器例如可以是界面中的控件,包括图标、按钮、显示框或者文字信息等,二级容器的基础信息,可以是指界面中控件的基础信息。

S203:响应于当前一级容器对应的界面发生故障,确定所述故障对应的类型。

当当前一级容器对应的界面发生故障时,确定所述故障对应的类型。具体地,可以将所述故障信息与预设故障类型进行匹配,确定所述故障对应的类型。

在本实施例中,所述故障分为三种类型,分别为应用程序崩溃、应用程序页面性能下降(例如应用程序页面卡顿)和应用程序网络错误。当发生上述故障时,二级容器对应的界面的参数会发生变化,根据当前二级容器对应的界面的参数数字可以确定故障的类型。例如发生应用程序页面卡顿时,页面的响应时间会边长等。

S204:将所述当前一级容器中的二级容器的基础信息和故障信息关联,生成故障报警信息。

当当前一级容器对应的界面发生故障并确定故障类型时,会进一步生成故障信息,同时,将生成的故障信息和在先获取的当前一级容器中的二级容器的基础信息进行关联,例如同时在故障信息中和当前一级容器中的二级容器的基础信息后加入当前的时间点,或者与实施例一中的方法一样,生成报文,报文的内容包括二级容器对应的界面的名称和故障信息。

S205:将所述故障报警信息上报至后台服务器。

在生成故障报警信息后,可以立即上报至后台服务器,或者也可以利用存储器对所述故障报警信息进行缓存,并按照预设时间间隔上报至后台服务器。

S206:获取当前时间点信息,根据所述当前时间点信息将所述故障报警信息添加到故障信息列表中。

后台服务器在接收到上报的故障报警信息后,获取当前时间点信息,并按照时间的先后顺序将所述故障报警信息添加到已有的故障信息列表中,生成新的故障信息列表。

后台的运维人员可以根据上报的故障报警信息对发生的故障进行处理。由于上报的故障报警信息对应的是二级容器的粒度,相对于现有技术中的故障报警信息对应一级容器的粒度而言,故障的定位和类型更加准去,有助于运维人员快速修复故障。

通过本公开的基于字节码插桩技术的应用程序故障诊断方法,通过提升应用程序页面的获取粒度,有效降低应用程序故障分析和修复周期,节约人力成本和时间成本,提高用户体验。

此外,作为本公开的一个实施例,在上述实施例中,将当前二级容器对应的界面的名称和故障信息关联,生成故障报警信息,可以通过后台的行为日志,基于所述行为日志确定所述故障的故障信息,将当前二级容器对应的界面的名称和故障信息关联,生成故障报警信息。

作为本公开的另一个实施例,获取当前二级容器对应的界面的子控件的名称及行各子控件的运行日志,将当前二级容器对应的界面的名称和故障信息关联,以及添加各子控件名称和对应的运行日志后,生成故障报警信息,通过这种方式,使得生成的故障报警信息的说明更加详细。

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

以上是关于方法实施例的介绍,以下通过装置实施例,对本公开所述方案进行进一步说明。

如图3所示,为本公开实施例三的基于字节码插桩技术的应用程序故障诊断装置,包括:本实施例的基于字节码插桩技术的应用程序故障诊断装置,包括:

信息获取模块301,用于在应用程序的运行过程中,获取一级容器对应的界面的运行结果和一级容器中的二级容器的基础信息,所述基础信息包括二级容器的名称、方法的类、方法类型、方法的输入参数信息和方法的输出参数信息;

故障报警信息生成模块302,用于响应于当前一级容器对应的界面发生故障,将所述当前一级容器中的二级容器的基础信息和故障信息关联,生成故障报警信息;

故障报警信息上报模块303,用于将所述故障报警信息上报至后台服务器。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,所述描述的模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

图4示出了本公开实施例四的基于字节码插桩技术的应用程序故障诊断设备的结构示意图。图4示出的终端设备仅仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。

如图4所示,计算机系统包括中央处理单元(CPU)401,其可以基于存储在只读存储器(ROM)402中的程序或者从存储部分408加载到随机访问存储器(RAM)403中的程序而执行各种适当的动作和处理。在RAM403中,还存储有系统操作所需的各种程序和数据。CPU 401、ROM 402以及RAM 403通过总线404彼此相连。输入/输出(I/O)接口405也连接至总线404。

以下部件连接至I/O接口405:包括键盘、鼠标等的输入部分406;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分407;包括硬盘等的存储部分408;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分409。通信部分409经由诸如因特网的网络执行通信处理。驱动器410也基于需要连接至I/O接口405。可拆卸介质411,诸如磁盘、光盘、磁光盘、半导体存储器等等,基于需要安装在驱动器410上,以便于从其上读出的计算机程序基于需要被安装入存储部分408。

特别地,基于本公开的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,所述计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分409从网络上被下载和安装,和/或从可拆卸介质411被安装。在该计算机程序被中央处理单元(CPU)401执行时,执行本申请的方法中限定的上述功能。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如,非限制性地,可以使用的示范类型的硬件逻辑部件包括:场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)等等。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器,使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行,作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外,虽然采用特定次序描绘了各操作,但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行,或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下,多任务和并行处理可能是有利的。同样地,虽然在上面论述中包含了若干具体实现细节,但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地,在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题,但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反,上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号