具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
图1是现有技术中补丁修复的场景示意图。如图1所示,现有技术的一种补丁修复方案可包括如下步骤:
第一步,向客户端推送补丁包。
第二步,补丁包运行。补丁包会在客户端后台运行之后生效。
第三步,补丁包发生闪退,向监控平台上报闪退信息。
第四步,监控平台通知开发人员。
第五步,开发人员查看分析闪退信息。
第六步,开发人员向客户端发送回滚指令。
第七步,客户端收到回滚指令之后,删除客户端运行的补丁包,恢复到原始状态。
在图1所示的补丁修复场景中,开发人员需要实时关注监控补丁包的稳定性,手动控制回滚指令来实现补丁包的回退机制,不够自动化,无法实现自动容灾机制,不能及时响应补丁包导致的客户端闪退问题。
本申请实施例提供一种客户端补丁修复方法、装置和系统,能够及时响应补丁导致的客户端闪退问题,修复客户端,为用户提供更好的体验。
图2是本申请的一个实施例客户端补丁修复方法流程图。图2的方法由客户端补丁修复装置执行。应理解,本申请实施例的方案可适用于移动终端的补丁修复。当然,也不排除将本申请实施例的方法应用于PC机的操作系统或其它计算机操作系统中的补丁修复。
S201,在安装客户端的补丁包时,将补丁包中的修复类对应的文件存储在第一存储路径中,并将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的被修复类前面。
其中,第一存储路径不同于该修复类对应的被修复类的第二存储路径。
应理解,将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的被修复类前面,是指将该修复类在该客户端的类加载列表中的加载顺序,排在与该修复类同名的所有被修复类的前面,或者说,排在加载顺序最靠前的第一个同名被修复类的前面。
应理解,本申请实施例的客户端,是指运行在移动终端上的应用。应理解,本申请实施例的补丁包,是指运行于移动终端上的客户端的补丁包,例如,基于Dex机制的补丁包等。
应理解,本申请实施例中,补丁包中可包含修复类的信息列表。客户端补丁修复装置可从该信息列表中获取补丁包的修复类的信息。具体地,例如,在Android系统中,客户端补丁修复装置可从补丁包中的info.cfg文件获取修复类信息,等等。
在得到修复类的信息后,客户端补丁修复装置需要根据修复类修复客户端中对应的类。例如,补丁包中有一个a.class的类,则客户端补丁修复装置需要用这个类修复客户端中对应的a.class的类。修复类的信息,可包括修复类的类名称。当然,应理解,在具体的应用中,一个完整的类名称应包括包名和类的路径。
为保留修复类在客户端中对应的同名被修复类,并使得修复类生效,可将补丁包中的修复类存储于不同于该修复类对应的被修复类的存储路径,并将补丁包中的修复类排在该客户端的类加载列表中对应的被修复类前面,以在被修复类之前被客户端的类加载器优先加载。
具体地,例如,作为被修复类的a.class的原有路径是path1,作为修复类的a.class的存储路径可修改为path2,其中path1和path2不同。或者,可将作为被修复类的a.class移动到path2,然后将作为修复类的a.class的存储到path1。此时,可保证客户端中的被修复类的文件不被覆盖。
另外,根据类加载机制,同名的类中,只有先加载的类生效,后加载的类不会生效。
可选地,作为一个实施例,将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的被修复类前面,具体可实现为:将所有修复类在该客户端的类加载列表中的加载顺序排在该客户端的其它所有类的前面。例如,可以将补丁包中的修复类放到该客户端的类加载列表的开头,使得补丁包中的修复类作为客户端的类加载器优先加载的类存储在该客户端的类加载列表中。此时,可以使得修复类在客户端中生效,而被修复类不再起作用。
在一个具体的例子中,假设原有的类加载列表中可如表1所示:
表1:
类名 |
路径 |
序号 |
b.class |
path1 |
1 |
c.class |
path2 |
2 |
a.class |
path3 |
3 |
d.class |
path4 |
4 |
当补丁包中包括修复类a.class和c.class时,可将a.class和c.class的信息加入到类加载列表的开头,形成表2:
表2:
类名 |
路径 |
序号 |
a.class |
path5 |
1 |
c.class |
path6 |
2 |
b.class |
path1 |
3 |
c.class |
path2 |
4 |
a.class |
path3 |
5 |
d.class |
path4 |
6 |
此时,位于类加载列表前面的a.class和c.class生效,位于类加载列表后面的a.class和c.class不起作用。
可选地,作为另一个实施例,将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的第一个被修复类前面,具体可实现为:将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的第一个被修复类的前一个位置。应理解,一个修复类可能存在多个同名的被修复类,其中,第一个被修复类是指所有的同名被修复类中最先被加载的被修复类。
具体地,还是以表1为例,当补丁包中包括修复类a.class和c.class时,可将a.class和c.class的信息加入到类加载列表对应的被修复类的前一个位置,形成表3:
表3:
类名 |
路径 |
序号 |
b.class |
path1 |
1 |
c.class |
path6 |
2 |
c.class |
path2 |
3 |
a.class |
path5 |
4 |
a.class |
path3 |
5 |
d.class |
path4 |
6 |
当然,应理解,上述类加载列表的形式仅仅是为了举例说明,在具体的应用中,可能存在其它的表示形式,其所包含内容也可能不同与上述表格所示的内容,本申请实施例对此不作限制。
应理解,在移动终端的操作系统中,特别是Android系统中,可包括多种类加载器。本申请实施例中,可通过如Bootstrap类加载器之类的加载器加载修复类。当然,也不排除使用其它类加载器加载修复类的可能。
可选地,在安装客户端的补丁包时,该方法还包括:将该修复类的信息记录到该客户端的补丁包列表中,该补丁包列表用于记录该客户端的补丁的修复类信息。
客户端补丁修复装置可将该修复类记录到补丁包类列表中,以便在发生闪退时判断是否是修复类导致的闪退。具体地,该补丁包类列表,例如,可以命名为patchClassList。当然,也不排除使用其它的名字。
当然,应理解,将修复类记录到补丁包类列表的步骤是可选地。客户端补丁修复装置还可通过其它方式记录修复类的信息。例如,根据客户端的类加载列表中的类名称,可推定具有多个相同类名称的类中被客户端的类加载器第一个加载的类为补丁的修复类,等等。
S202,监控该客户端的运行状态。
当客户端的补丁包安装完毕后,客户端补丁修复装置需要在客户端运行时,监控客户端的运行状态。
例如,客户端补丁修复装置可通过闪退报告(CrashReporter)模块等捕获客户端的闪退堆栈信息,等等。
S203,如果监控到该客户端发生闪退,获取该客户端的闪退堆栈信息。
客户端补丁修复装置通过如闪退报告(CrashReporter)模块等监控到该客户端发生闪退时,可获取该客户端的闪退堆栈信息。
其中,该闪退堆栈信息中可包括导致闪退的类的全路径、方法及错误类型等。下面示出了闪退堆栈信息的一个具体例子:
************************************************************
java.lang.NullPointerException:Attempt to invoke virtual method'java.lang.Object
android.content.Context.getSystemService(java.lang.String)'on a nullobject reference
at com.app.A.<init>(A.java:19)
at
com.antfortune.wealth.common.ui.view.sharecomponent.AFShareComponent.<init>(AFSh
areComponent.java:79)
at
com.antfortune.wealth.mywealth.asset.adapter.ImageShareManager.<init>(ImageShareMan
ager.java:46)
at
com.antfortune.wealth.mywealth.asset.adapter.InvestAnalysisAdapter.<init>(InvestAnalysis
Adapter.java:54)
************************************************************
S204,如果该闪退堆栈信息中携带该补丁包的修复类中的第一修复类的信息,则将第一修复类从该类加载列表中删除。
不妨假设客户端当前的补丁包类列表patchClassList中包括com.antfortune.wealth.common.ui.view.sharecomponent.AFShareComponent类和com.antfortune.wealth.mywealth.asset.adapter.InvestAnalysisAdapter类,则此时该客户端补丁修复装置可删除这两个类在类加载列表中对应的列表项信息。
可选地,如果在安装客户端的补丁包时,该方法还包括:将修复类的信息记录到该客户端的补丁包列表中;则,在将第一修复类从该类加载列表中删除时,该方法还包括:将第一修复类从该补丁包列表中删除。
也就是说,如果安装补丁包时将修复类的信息记录到该客户端的补丁包列表中,则在发生闪退时,可将闪退堆栈信息中携带的第一修复类的信息从该客户端的补丁包列表中删除。当然,也可选择不删除该信息,但可能会给后续的补丁维护工作造成一定的问题。
应理解,在本申请实施例中,将第一修复类从该类加载列表中删除的步骤,与将第一修复类从该补丁包列表中删除的步骤,可以并行执行,或者先执行其中一个步骤,再执行另一个步骤,本申请实施例在此不做限制。
可选地,该方法还可包括:在将第一修复类从该类加载列表中删除时,删除第一修复类对应的文件。
应理解,删除第一修复类对应的文件,可避免产生过多的垃圾文件,节省移动终端的存储空间。当然,也可选择不删除第一修复类对应的文件。
在本申请实施例中,通过在安装补丁包时将修复类存储在不同于被修复类的路径中以保留被修复类,并将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的第一个被修复类前面以实现修复类的优先加载,进而在监控到闪退堆栈信息中包括修复类时,基于保留的被修复类还原客户端,从而使得客户端能够在发生闪退后及时恢复,缩短了修复补丁包导致的闪退问题的反应时间,为用户提供更好的体验。
可选地,作为一个实施例,该方法还包括:将该闪退堆栈信息中携带的第一修复类的信息发送至该客户端的监控平台中,该监控平台用于监控该客户端在补丁包安装后的运行情况。
例如,在步骤S203所示的闪退堆栈信息中,客户端补丁修复装置可将com.antfortune.wealth.common.ui.view.sharecomponent.AFShareComponent类和com.antfortune.wealth.mywealth.asset.adapter.InvestAnalysisAdapter类对应的闪退堆栈信息发送至监控平台,使得开发人员能够根据该闪退堆栈信息分析问题所在,以进行下一步的开发修复。
本申请实施例中,通过将客户端的闪退堆栈信息中关于补丁包中的修复类对应的内容发送至监控平台,能够使得开发人员根据补丁包中指定的类出现的问题进行分析,大大提高了开发人员的开发效率。
可选地,作为一个实施例,在安装客户端的补丁包时,该方法还包括:如果该客户端的类加载列表中与第二修复类对应的同名被修复类的列表项多于N个,则在该客户端的类加载列表中保留第二修复类的前N个同名被修复类,并删除第二修复类的同名被修复类中该前N个同名被修复类以外的被修复类,其中N为预设的正整数值。一般情况下,N取值为1。
例如,假设原有的类加载列表中可如表4所示:
表4
类名 |
路径 |
序号 |
a.class |
path5 |
1 |
c.class |
path6 |
2 |
b.class |
path1 |
3 |
c.class |
path2 |
4 |
a.class |
path3 |
5 |
d.class |
path4 |
6 |
当补丁包中包括修复类a.class,可将a.class信息加入到类加载列表的开头,并只保留与修复类a.class对应的第1个同名被修复类a.class,即路径为path5的a.class,并删除其余同名被修复类a.class,即路径为path3的a.class,从而得到表5:
表5
可选地,作为一个实施例,该方法还包括:在安装客户端的补丁包时,删除距离该补丁包的版本个数差在M个以上的补丁包在该补丁包类列表中对应的修复类信息,M为预设的正整数值。具体地,例如,可以将当前补丁包将之前3个版本以上的补丁包在该补丁包类列表中对应的修复类信息删除,或者将当前补丁包将之前5个版本以上的补丁包在该补丁包类列表中对应的修复类信息删除,等等。本申请实施例对M的取值不做限定。
应理解,距离补丁包的当前版本个数相差超过预定个数的,可以认为是运行比较稳定的补丁包版本。本申请实施例中,通过将这些信息从补丁包类列表中删除,可以减小补丁包类列表的大小,提高运行效率。
可选地,作为一个实施例,该方法还包括:删除第一修复类所在的第一补丁包中其它修复类在该类加载列表中对应的列表项信息。
当补丁包中某个类出现问题时,可以同时删除补丁包中其它修复类的信息,以实现版本的协调管理。
当然,应理解,在本申请实施例中,还可删除第一修复类所在的第一补丁包其它修复类对应的文件,和/或第一修复类在补丁包类列表中的修复类信息。
进一步地,该方法还包括:删除第一补丁包之后的版本的补丁包中各修复类在该类加载列表中对应的列表项信息。
类似地,在删除第一补丁包之后的版本的补丁包中各修复类在该类加载列表中对应的列表项信息时,还可删除第一补丁包之后的版本的补丁包中各修复类对应的文件,和/或第一补丁包之后的版本的补丁包在补丁包类列表中的修复类信息。
例如,假设客户端先后发布了补丁包A、B和C。如果补丁包B中的类导致闪退,则此时客户端补丁修复装置除了删除补丁包B所涉及的修复类信息外,还可将补丁包B之后的补丁包C所涉及的修复类信息删除。
由于补丁包之间往往存在一定的关联关系,之后发布的补丁包往往是在之前发布的补丁包的基础上进行完善的,如果先发布的补丁包被回滚,有很大的概率导致后发布的补丁包出错。因此,通过将导致闪退的补丁包之后的版本的补丁包对应的修复类信息删除,从而将补丁包回滚到出错的补丁包之前的一个版本,能够减少客户端闪退的概率。
可选地,该客户端的闪退堆栈信息包括发生闪退的类的包名和类名。
图3是本申请的一个实施例电子设备的结构示意图。请参考图3,在硬件层面,该电子设备包括处理器,可选地还包括内部总线、网络接口、存储器。其中,存储器可能包含内存,例如高速随机存取存储器(Random-Access Memory,RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少1个磁盘存储器等。当然,该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接,该内部总线可以是ISA(Industry Standard Architecture,工业标准体系结构)总线、PCI(PeripheralComponent Interconnect,外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture,扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图3中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
存储器,用于存放程序。具体地,程序可以包括程序代码,所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器,并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成客户端补丁修复装置。处理器,执行存储器所存放的程序,并具体用于执行以下操作:
在安装客户端的补丁包时,将补丁包中的修复类对应的文件存储在第一存储路径中,并将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的被修复类前面,其中,第一存储路径不同于该修复类对应的被修复类的第二存储路径;
监控该客户端的运行状态;
如果监控到该客户端发生闪退,则获取该客户端的闪退堆栈信息;
如果该闪退堆栈信息中携带该补丁包的修复类中的第一修复类的信息,则将第一修复类从该类加载列表中删除。
上述如本申请图2所示实施例揭示的客户端补丁修复装置执行的方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
该电子设备还可执行图2的方法,并实现客户端补丁修复装置在图2所示实施例的功能,本申请实施例在此不再赘述。
当然,除了软件实现方式之外,本申请的电子设备并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
本申请实施例还提出了一种计算机可读存储介质,该计算机可读存储介质存储一个或多个程序,该一个或多个程序包括指令,该指令当被包括多个应用程序的电子设备执行时,能够使该电子设备执行图2所示实施例的方法,并具体用于执行以下方法:
在安装客户端的补丁包时,将补丁包中的修复类对应的文件存储在第一存储路径中,并将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的被修复类前面,其中,第一存储路径不同于该修复类对应的被修复类的第二存储路径;
监控该客户端的运行状态;
如果监控到该客户端发生闪退,则获取该客户端的闪退堆栈信息;
如果该闪退堆栈信息中携带该补丁包的修复类中的第一修复类的信息,则将第一修复类从该类加载列表中删除。
图4是本申请的一个实施例客户端补丁修复装置的结构示意图。请参考图4,在一种软件实施方式中,客户端补丁修复装置可包括:补丁包安装单元401、监控单元402、获取单元403和修复单元404,其中
补丁包安装单元401,在安装客户端的补丁包时,将补丁包中的修复类对应的文件存储在第一存储路径中,并将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的被修复类前面,其中,第一存储路径不同于该修复类对应的被修复类的第二存储路径;
监控单元402,监控该客户端的运行状态;
获取单元403,如果监控单元402监控到该客户端发生闪退,则获取该客户端的闪退堆栈信息;
修复单元404,如果该闪退堆栈信息中携带该补丁包的修复类中的第一修复类的信息,则将第一修复类从该类加载列表中删除。
在本申请实施例中,通过在安装补丁包时将修复类存储在不同于被修复类的路径中以保留被修复类,并将该修复类在该客户端的类加载列表中的加载顺序排在该修复类对应的第一个被修复类前面以实现修复类的优先加载,进而在监控到闪退堆栈信息中包括修复类时,基于保留的被修复类还原客户端,从而使得客户端能够在发生闪退后及时恢复,缩短了修复补丁包导致的闪退问题的反应时间,为用户提供更好的体验。
可选地,作为一个实施例,该客户端补丁修复装置400还包括发送单元405,将该闪退堆栈信息中携带的第一修复类的信息发送至该客户端的监控平台中,该监控平台用于监控该客户端在补丁包安装后的运行情况。
可选地,作为一个实施例,补丁包安装单元401还在安装客户端的补丁包时,如果该客户端的类加载列表中与第二修复类对应的同名被修复类的列表项多于N个,则在该客户端的类加载列表中保留第二修复类的前N个同名被修复类,并删除第二修复类的同名被修复类中该前N个同名被修复类以外的被修复类,其中N为预设的正整数值。
可选地,作为一个实施例,补丁包安装单元401还在安装客户端的补丁包时,删除距离该补丁包的版本个数差在M个以上的补丁包在该补丁包类列表中对应的修复类信息,M为预设的正整数值。
可选地,作为一个实施例,修复单元404还删除第一修复类所在的第一补丁包中其它修复类在该类加载列表中对应的列表项信息。
进一步地,修复单元404还删除第一补丁包之后的版本的补丁包中各修复类在该类加载列表中对应的列表项信息。
可选地,该客户端的闪退堆栈信息包括发生闪退的类的包名和类名。
客户端补丁修复装置400还可执行图2所示实施例的方法,并实现客户端补丁修复装置在图4所示实施例的功能,本申请实施例在此不再赘述。
总之,以上所述仅为本申请的较佳实施例而已,并非用于限定本申请的保护范围。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。