CN117056115B - 应用程序的修复方法和装置、存储介质及电子设备 - Google Patents

Abstract

本申请公开了一种应用程序的修复方法和装置、存储介质及电子设备。其中，该方法包括：启动满足预设启动条件的目标应用程序，其中，该目标应用程序的工程架构包括用于启动目标应用程序的框架层，以及用于执行目标应用程序的业务功能的业务层，通过接入一组插件在业务层实现业务功能，以更新目标应用程序的目标业务功能，当确认是目标插件造成的目标应用程序异常，可以对目标插件进行版本替换，将当前异常的目标插件的第二版本回滚为之前预先保存的其中一个目标插件的第一版本。本申请解决了由于通过发布新版本应用程序来修复应用程序异常的耗时较长，升级过程风险大，导致应用程序的修复效率较低的技术问题。

Description

应用程序的修复方法和装置、存储介质及电子设备

技术领域

本申请涉及计算机领域，具体而言，涉及一种应用程序的修复方法和装置、存储介质及电子设备。

背景技术

目前，大多数应用程序由于系统漏洞或者功能节点问题会发生异常，现有技术往往采用发布新版本应用程序的方式来进行旧版本应用程序的更新升级，以修复当前应用程序出现的异常，上述方案无法应对应用程序启动过程中发生异常或者单个功能节点频繁异常的情况，往往修复异常的耗时较长，版本升级也存在较高风险，导致应用程序的修复效率较低，无法满足实际业务需要。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种应用程序的修复方法和装置、存储介质及电子设备，以至少解决由于通过发布新版本应用程序来修复应用程序异常的耗时较长，升级过程风险大，导致应用程序的修复效率较低的技术问题。

根据本申请实施例的一个方面，提供了一种应用程序的修复方法，包括：在目标应用程序满足预设启动条件的情况下，启动所述目标应用程序，其中，所述目标应用程序的工程架构包括框架层和业务层，所述框架层用于启动所述目标应用程序，所述业务层用于执行所述目标应用程序的业务功能，所述业务层被设置为通过接入一组插件实现所述业务功能；在需要更新所述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存所述第一版本对应的第一插件数据，其中，所述目标插件表示所述一组插件中与所述目标业务功能关联的插件；在检测到所述目标应用程序发生异常，且造成异常的插件为所述目标插件的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本。

根据本申请实施例的另一方面，还提供了一种应用程序的修复装置，包括：启动模块，用于在目标应用程序满足预设启动条件的情况下，启动所述目标应用程序，其中，所述目标应用程序的工程架构包括框架层和业务层，所述框架层用于启动所述目标应用程序，所述业务层用于执行所述目标应用程序的业务功能，所述业务层被设置为通过接入一组插件实现所述业务功能；控制模块，用于在需要更新所述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存所述第一版本对应的第一插件数据，其中，所述目标插件表示所述一组插件中与所述目标业务功能关联的插件；处理模块，用于在检测到所述目标应用程序发生异常，且造成异常的插件为所述目标插件的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本。

可选地，所述装置用于通过如下方式在检测到所述目标应用程序发生异常，且造成异常的插件为所述目标插件的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本：在检测到所述目标应用程序发生异常的情况下，确定造成异常的原因是否为所述目标插件；在确定造成异常的原因为所述目标插件，且所述目标插件由所述第一版本更新为所述第二版本的情况下，查找所述第一插件数据；在查找到所述第一插件数据的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本。

可选地，所述装置用于通过如下方式在查找到所述第一插件数据的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本：在所述第一版本不属于预设插件版本集合的情况下，查找所述第一插件数据，其中，所述预设插件版本集合表示造成异常的次数满足预设阈值的插件版本集合；利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本；将所述第二版本添加至所述预设插件版本集合，并保存所述第二版本对应的第二插件数据，其中，所述第一版本对应的所述目标插件允许使用所述第二插件数据中的业务数据。

可选地，所述装置用于通过如下方式在检测到所述目标应用程序发生异常的情况下，确定造成异常的原因是否为所述目标插件：在检测到所述目标应用程序发生异常的情况下，获取异常堆栈信息，其中，所述异常堆栈信息表示所述目标应用程序发生异常时记录的堆栈信息；根据所述异常堆栈信息确定目标异常类，并通过类加载器加载所述目标异常类，其中，所述目标异常类包括造成所述目标应用程序发生异常的代码片段；根据所述目标异常类的加载结果确定造成异常的原因，其中，在所述加载结果表示所述目标异常类加载成功的情况下，所述造成异常的原因与插件相关，在所述加载结果表示所述目标异常类加载失败的情况下，所述造成异常的原因与插件不相关。

可选地，所述装置还用于：在所述加载结果表示所述目标异常类加载失败的情况下，禁止将所述目标插件由所述第二版本回滚为所述第一版本；在所述加载结果表示所述目标异常类加载成功，造成异常的插件为所述目标插件，且所述目标插件由所述第一版本更新为所述第二版本，但未在本地查找到所述第一插件数据的情况下，禁止将所述目标插件由所述第二版本回滚为所述第一版本；在所述加载结果表示所述目标异常类加载成功，造成异常的插件为所述目标插件，所述目标插件由所述第一版本更新为所述第二版本，且所述第一版本属于预设插件版本集合的情况下，禁止将所述目标插件由所述第二版本回滚为所述第一版本，其中，所述预设插件版本集合表示造成异常的次数满足预设阈值的插件版本集合；在禁止将所述目标插件由所述第二版本回滚为所述第一版本的情况下，获取第三版本对应的第三插件数据，其中，所述第一版本对应的所述目标插件由所述第三版本对应的所述目标插件更新得到；利用所述第三插件数据将所述目标插件由所述第二版本回滚为所述第三版本。

可选地，所述装置还用于：所述根据所述异常堆栈信息确定目标异常类，并通过类加载器加载所述目标异常类之后，通过公共类加载器加载所述目标异常类，获取目标类列表，从所述目标类列表中根据所述目标异常类确定所述目标插件，其中，所述公共类加载器与所述目标应用程序相关联，所述目标类列表中的一个列表项与所述目标应用程序接入的一个插件相关联；或者通过独立类加载器加载所述目标异常类，确定所述目标插件，其中，所述独立类加载器与所述目标插件相对应。

可选地，所述装置用于通过如下方式在目标应用程序满足预设启动条件的情况下，启动所述目标应用程序：在目标应用程序满足预设启动条件的情况下，加载所述框架层；利用所述框架层加载所述业务层中的基础层，其中，所述基础层与所述多个插件中的第一组插件对应，所述第一组插件包括内置在所述目标应用程序安装包中的基础插件，所述基础插件与至少两个业务功能相关联，所述基础层的更新频率大于所述框架层。

可选地，所述装置用于通过如下方式利用所述框架层加载所述业务层对应的第一组插件之后，包括：利用所述框架层预加载所述业务层中的第二组插件，其中，所述第二组插件包括预先设置的需要提前加载的业务插件，一个所述业务插件与至少一个业务功能相关联，所述第二组插件的更新频率大于所述框架层；响应于目标业务需求，利用所述框架层加载目标业务插件，其中，所述目标业务插件包括预先设置的首次触发所述目标业务需求所需要加载的业务插件，一个所述目标业务插件与至少一个业务功能相关联，所述目标业务插件的更新频率大于所述框架层。

可选地，所述装置用于通过如下方式响应于目标业务需求，利用所述框架层加载目标业务插件：响应于所述目标业务需求，从所述框架层获取目标网络接口，其中，所述目标网络接口是所述基础层预先在所述框架层注册的网络结构；在确定所述基础层定义了所述目标网络接口的接口能力的情况下，通过所述基础层向目标服务器发送与所述目标业务需求关联的网络请求。

可选地，所述装置用于通过如下方式在需要更新所述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存所述第一版本对应的第一插件数据：获取初始插件记录文件，其中，所述初始插件记录文件记录有所述目标应用程序执行所述目标业务功能所使用的插件为所述第一版本；在检测到需要更新所述目标业务功能的情况下，下载所述第二版本对应的所述目标插件；升级安装所述第二版本对应的所述目标插件；将所述初始插件记录文件修改为第一插件记录文件，并保存所述第一版本对应的第一插件数据，其中，所述第一插件记录文件记录有所述目标应用程序执行所述目标业务功能所使用的插件为所述第二版本。

可选地，所述装置用于通过如下方式在检测到所述目标应用程序发生异常，且造成异常的插件为所述目标插件的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本：在检测到所述目标应用程序发生异常，且造成异常的插件为所述目标插件的情况下，降级安装所述第一版本对应的所述目标插件；将所述第一插件记录文件修改为目标插件记录文件，其中，所述目标插件记录文件记录有所述目标应用程序执行所述目标业务功能所使用的插件为所述第一版本。

根据本申请实施例的又一方面，还提供了一种计算机可读的存储介质，该计算机可读的存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述应用程序的修复方法。

根据本申请实施例的又一方面，提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行如以上应用程序的修复方法。

根据本申请实施例的又一方面，还提供了一种电子设备，包括存储器和处理器，上述存储器中存储有计算机程序，上述处理器被设置为通过所述计算机程序执行上述的应用程序的修复方法。

在本申请实施例中，采用在目标应用程序满足预设启动条件的情况下，启动目标应用程序，其中，目标应用程序的工程架构包括框架层和业务层，框架层用于启动目标应用程序，业务层用于执行目标应用程序的业务功能，业务层被设置为通过接入一组插件实现业务功能，在需要更新目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存第一版本对应的第一插件数据，其中，目标插件表示一组插件中与目标业务功能关联的插件，在检测到目标应用程序发生异常，且造成异常的插件为目标插件的情况下，利用第一插件数据将目标插件由第二版本回滚为第一版本的方式，也即，通过在目标应用程序的业务层采用更新插件版本的方式，对造成目标应用程序的目标插件的版本进行回滚，将当前版本替换为之前预先保存的其中一个插件版本，快速修复应用程序异常，达到了独立更新插件，及时修复应用程序异常的目的，从而实现了提高应用程序修复效率，同时保证了应用程序安全性的技术效果，进而解决了由于通过发布新版本应用程序来修复应用程序异常的耗时较长，升级过程风险大，导致应用程序的修复效率较低的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种可选的应用程序的修复方法的应用环境的示意图；

图2是根据本申请实施例的一种可选的应用程序的修复方法的流程示意图；

图3是根据本申请实施例的一种可选的应用程序的工程架构示意图；

图4是根据本申请实施例的一种可选的应用程序的更新流程示意图；

图5是根据本申请实施例的一种可选的应用程序的插件修改示意图；

图6是根据本申请实施例的一种可选的应用程序的异常检测示意图；

图7是根据本申请实施例的一种可选的应用程序的异常检测的具体流程示意图；

图8是根据本申请实施例的一种可选的应用程序的插件安装示意图；

图9是根据本申请实施例的一种可选的应用程序的网络请求示意图；

图10是根据本申请实施例的一种可选的应用程序的插件类型示意图；

图11是根据本申请实施例的一种可选的应用程序的插件加载流程示意图；

图12是根据本申请实施例的一种可选的应用程序的插件修复示意图；

图13是根据本申请实施例的一种可选的应用程序的本地配置文件示意图；

图14是根据本申请实施例的一种可选的应用程序的修复效果的示意图；

图15是根据本申请实施例的一种可选的应用程序的修复装置的结构示意图；

图16是根据本申请实施例的一种可选的应用程序的修复产品的结构示意图；

图17是根据本申请实施例的一种可选的电子设备的结构示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本申请实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

插件化：将应用程序的一部分模块拆分成子应用程序的形式，可以不经过安装就能被宿主应用程序加载使用的技术。

本地回滚：软件升级过程中如果出现了问题就需要进行回滚操作，本地回滚就是针对升级的软件包，直接在本地设备回滚到上一个版本，而不是再去后台服务器下载前一个版本的软件包来进行回滚。

插件：将应用程序的某一模块单独抽离成一个独立模块，通常以压缩格式打包称一个独立的应用程序包，在该压缩模块不需要安装的情况下，宿主应用程序也能直接调用该模块的代码功能，该模块称之为插件。

程序异常：软件应用启动之后，如果程序的代码存在系统漏洞或者节点问题，将导致程序运行不正常，系统通常会捕获这种软件程序运行不正常的情况，并主动抛出一个终止程序运行的事件动作来终止程序继续运行，这种终止程序运行的动作即程序崩溃。

程序升级：软件程序从一个比较旧的程序版本更新到一个新的程序版本的过程。

程序降级：软件程序从当前的版本回滚到之前某一个旧的版本的过程称之为程序降级，降级和升级是相对的。

插件卸载：通过程序逻辑来使得一个插件失效的过程称之为插件卸载，即将插件从宿主应用程序的运行程序中剥离开。

插件加载：通过程序逻辑来使得一个插件生效并且运行的过程称为插件加载，即针对插件进行解析，并把解析结果保存在内存中，以便插件运行的时候可以随时访问这些数据。

升级安装：在应用程序升级中，对于升级包的解析，并把解析的结果保存到本地，内存中的过程称为安装，升级安装就是只允许程序从低版本过度到高版本。

降级安装：一个程序从发布时间晚的高版本过渡到发布时间早的低版本。

下面结合实施例对本申请进行说明：

根据本申请实施例的一个方面，提供了一种应用程序的修复方法，可选地，在本实施例中，上述应用程序的修复方法可以应用于如图1所示的由服务器101和终端设备103所构成的硬件环境中。如图1所示，服务器101通过网络与终端103进行连接，可用于为终端设备或终端设备上安装的应用程序提供服务，应用程序可以是视频应用程序、即时通信应用程序、浏览器应用程序、教育应用程序、游戏应用程序等。可在服务器上或独立于服务器设置数据库105，用于为服务器101提供数据存储服务，例如，游戏数据存储服务器，上述网络可以包括但不限于：有线网络，无线网络，其中，该有线网络包括：局域网、城域网和广域网，该无线网络包括：蓝牙、WIFI及其他实现无线通信的网络，终端设备103可以是配置有应用程序的终端，可以包括但不限于以下至少之一：手机（如Android手机、iOS手机等）、笔记本电脑、平板电脑、掌上电脑、MID（Mobile Internet Devices，移动互联网设备）、PAD、台式电脑、智能电视、智能语音交互设备、智能家电、车载终端、飞行器、虚拟现实（VirtualReality，简称VR）终端、增强现实（Augmented Reality，简称AR）终端、混合现实（MixedReality，简称MR）终端等计算机设备，上述服务器可以是单一服务器，也可以是由多个服务器组成的服务器集群，或者是云服务器。

结合图1所示，上述应用程序的修复方法可以在终端设备103通过如下步骤实现：

S1，在目标应用程序满足预设启动条件的情况下，在终端设备103上启动目标应用程序，其中，目标应用程序的工程架构包括框架层和业务层，框架层用于启动目标应用程序，业务层用于执行目标应用程序的业务功能，业务层被设置为通过接入一组插件实现业务功能；

S2，在需要更新目标应用程序的目标业务功能的情况下，在终端设备103上将目标插件由第一版本更新为第二版本，并保存第一版本对应的第一插件数据，其中，目标插件表示一组插件中与目标业务功能关联的插件；

S3，在检测到目标应用程序发生异常，且造成异常的插件为目标插件的情况下，在终端设备103上利用第一插件数据将目标插件由第二版本回滚为第一版本。

可选地，在本实施例中，上述应用程序107的修复方法还可以通过服务器实现，例如，图1所示的服务器101中实现；或由终端设备和服务器共同实现。

上述仅是一种示例，本实施例不做具体的限定。

可选地，作为一种可选的实施方式，如图2所示，上述应用程序的修复方法包括：

S202，在目标应用程序满足预设启动条件的情况下，启动上述目标应用程序，其中，上述目标应用程序的工程架构包括框架层和业务层，上述框架层用于启动上述目标应用程序，上述业务层用于执行上述目标应用程序的业务功能，上述业务层被设置为通过接入一组插件实现上述业务功能；

可选地，在本实施例中，上述目标应用程序可以包括但不限于桌面应用程序、移动应用程序、网页应用程序、企业应用程序、嵌入式应用程序、游戏应用程序、云应用程序、社交媒体应用程序、教育应用程序等，可以包括但不限于会议、教育、消息、旅游、听书、广告等会在车上应用的各种应用程序。

可选地，在本实施例中，上述框架层可以包括但不限于活动路由器框架、应用程序启动框架、应用程序插件框架、事件通知框架、模块接口框架等，上述业务层可以包括但不限于应用程序代码基础组件、公共资源组件、识别业务模块、摄像头采集模块、数据库查询组件、用户登录组件、异常处理组件等，上述插件可以包括但不限于数据库插件、操作系统插件、虚拟化插件、文本编辑器插件等，上述业务功能可以包括但不限于刷脸支付、刷掌支付、刷掌门禁、刷掌地铁、数据查询、用户登录、文件处理等。

可选地，在本实施例中，上述预设启动条件可以包括但不限于通过交互操作触发启动了上述目标应用程序，或者，目标应用程序被设置为定时启动，且当前时刻到达了上述预先设定的启动时刻等，换言之，上述预设启动条件可以表示主动触发的启动条件或自动实现的启动条件。

需要说明的是，上述预设启动条件可以理解为某一对象在终端启动上述目标应用程序所需要的信息验证，信息权限验证通过，该目标应用程序允许当前对象进入，分配对应于当前对象权限的上述目标应用程序资源，供当前对象进行操作，反之，对象权限验证未通过，即上述目标应用程序不满足上述预设启动条件，无法正常启动，其中，上述目标应用程序所需要的信息验证可以包括但不限于安装目标应用程序、硬件设备信息、用户账户、授权许可、网络连接等。

示例性地，位于上述目标应用程序的工程架构中的框架层用于启动上述目标应用程序，也就是说，上述目标应用程序满足预设启动条件之后，上述框架层来执行启动该目标应用程序的操作，使得上述目标应用程序在目标终端上运行。

进一步地，上述业务层位于上述目标应用程序的工程架构中，可以通过接入一组插件执行上述目标应用程序所支持的业务功能，例如，上述业务层中包括刷脸支付业务模块插件，在上述目标应用程序启动之后，用户需要进行刷脸支付，也即，处于上述业务层的刷脸支付业务插件调用该目标应用程序的目标识别模块，打开摄像头进行用户面部信息采集，采集成功之后进行图像识别，用户身份信息匹配通过后将支付请求发送给上述目标应用程序的交易支付模块进行交易处理。

在一个示例性的实施例中，图3是根据本申请实施例的一种可选的应用程序的工程架构示意图，如图3所示，目标应用程序的工程框架中包括业务层302和框架层304，其中，业务层302中被划分为业务子层306以及基础层308，在业务子层306中，包括优选模块、秒级识别模块、业务主流模块、摄像头模块，可以支持该目标应用程序的刷脸支付业务、刷掌支付业务、刷掌门禁业务、刷掌地铁业务，在基础层308中，提供目标应用程序的基础代码组件，例如用于数据传输的网络组件、界面UI组件、物联网组件等等，以及公共资源组件，而框架层304则提供活动路由器框架、应用程序启动框架、插件框架等，例如，用户可以通过如下步骤启动上述目标应用程序，包括但不限于：

S1，用户在手机端点击目标应用程序的图标；

S2，目标应用程序检测到步骤S1中来自用户的启动程序请求，并检测到手机支持当前版本，同时该手机已联网；

S3，目标应用程序的框架层执行应用程序启动命令；

S4，目标应用程序成功启动，用户进入该目标应用程序，手机显示程序默认界面；

S5，目标应用程序等待用户的下一步操作，由业务层进行响应，实现具体功能。

S204，在需要更新上述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存上述第一版本对应的第一插件数据，其中，上述目标插件表示上述一组插件中与上述目标业务功能关联的插件；

可选地，在本实施例中，上述第一版本与第二版本可以包括但不限于数据库插件版本、操作系统插件版本、虚拟化插件版本、文本编辑器插件版本等，第一插件数据可以包括但不限于插件名称、插件描述、插件依赖、插件功能、插件配置、插件安装时间、插件更新历史、插件使用情况等。

示例性地，通过更新目标插件的版本，实现上述目标应用程序中的目标业务功能更新，换句话说，上述目标插件与上述目标应用程序的业务功能相关联，在该目标应用程序中可以通过该目标插件实现相应的目标业务功能，上述目标业务功能可以包括但不限于用户登录、文件下载、刷脸支付、刷掌支付、刷掌门禁、刷掌地铁、数据查询等。

需要说明的是，上述目标应用程序表现出以下特征，包括但不限于应用程序无法启动、现有业务新增功能点、应用程序无法退出、界面改进等，将会对上述目标业务功能进行更新，其中，上述第一版本与上述第二版本均能够实现部分相同的目标业务功能，安装在上述目标应用程序中的工程架构的位置也相同，其中，上述第一版本是当前该目标应用程序用于实现上述目标业务功能的插件，而上述第二版本则是用来代替该第一版本，上述第一版本与上述第二版本的区别点可以包括但不限于发布时间、版本作者、版本依赖等。

在一个示例性的实施例中，在对上述目标应用程序的目标插件进行更新时，可以将上述第一版本对应的第一插件数据进行本地保存，或者远程保存，也就是说，利用上述第二版本代替上述第一版本之后，上述目标应用程序不会主动删除上述第一版本对应的插件数据，将同时保存第一版本对应的插件数据和第二版本对应的插件数据。

示例性地，图4是根据本申请实施例的一种可选的应用程序的更新流程示意图，如图4所示：

S402，目标应用程序检测到人脸识别业务功能需要更新，即需要更新对应于人脸识别业务功能的目标插件；

S404，目标应用程序下载新版目标插件；

S406，在目标应用程序内部架构的相同位置将S402对应版本的目标插件更新为S404对应版本的目标插件，也即，将旧版目标插件更新为新版目标插件；

S408，更新目标应用程序的插件记录文件，将人脸识别业务功能的实现插件信息更新为S404中提出的新版目标插件对应的插件信息；

S410，更新结束，继续保留S402中提出的目标插件的插件数据，不主动删除该插件数据；

进一步地，图5是根据本申请实施例的一种可选的应用程序的插件修改示意图，如图5所示，目标应用程序502进行目标插件的版本替换时，可以通过上述S408中提到的插件记录文件504来指定新版插件506，即上述目标应用程序可以随时抹除旧版插件508的信息。

S206，在检测到上述目标应用程序发生异常，且造成异常的插件为上述目标插件的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本。

可选地，在本实施例中，导致上述目标应用程序异常的原因可以包括但不限于内存不足、代码错误、硬件故障、依赖项错误、网络问题等。

具体而言，上述目标应用程序出现如下故障，包括但不限于无法启动、某一功能无法正常使用、无法正常退出时，发生程序异常，无法正常使用，即需要检测该目标应用程序，定位导致上述目标应用程序异常的原因。

在一个示例性的实施例中，上述目标应用程序发生异常，通过根因定位，确定造成上述目标应用程序发生异常的插件为上述目标插件之后，将目标应用程序中的目标插件对应的版本进行替换，也即，将上述第二版本进行回滚，替换成上述第一版本，由上述第一版本实现对应的上述目标业务功能。

示例性地，图6是根据本申请实施例的一种可选的应用程序的异常检测示意图，如图6所示，可以通过如下步骤确定导致目标应用程序发生异常的目标插件：

S602，目标应用程序由于某一插件发生异常，从目标应用程序确定目标异常类（包括造成目标应用程序发生异常的代码片段，图6所示的崩溃类）；

S604-1，通过与目标应用程序关联的公共类加载器，获取目标异常类列表；

S604-2，通过与S602中提到的某一插件关联的独立类加载器，确定目标插件；

S606，通过S604-2中目标异常类中确定的目标插件，获取导致目标应用程序异常的目标插件信息；

S608，通过查询S604-1中目标异常类中列表文件信息，确定导致目标应用程序异常的目标插件所在文件；

S610，提取导致目标应用程序异常的目标插件所在文件路径；

S612，进入S610中目标异常类中确定的目标插件所在文件路径，获取导致目标应用程序异常的目标插件对应的插件信息。

需要说明的是，造成上述目标应用程序发生异常的版本为上述第二版本，上述第一版本是目标插件在第二版本之前的版本，用于在上述目标应用程序更新为第二版本之前，实现上述目标业务功能，可以理解为，使用该目标插件的上述第一版本可能不会引发与上述第二版本相同的目标应用程序异常。

在一个示例性的实施例中，上述应用程序的修复方法可以应用于移动端社交应用软件突发异常的实际场景中，图7是根据本申请实施例的一种可选的应用程序的异常检测的具体流程示意图，如图7所示：

S702，社交应用软件正常使用过程中发生异常（发生Crash崩溃），用户无法打开摄像头进行拍摄；

S704，获取社交应用软件的异常堆栈信息（对应于图7所示的崩溃异常堆栈），解析该异常堆栈信息，进而确定目标异常类（对应于图7所示的目标崩溃类）；

S706，通过该社交应用软件的类加载器加载目标异常类；

S708-1，目标异常类加载成功，确认造成异常的原因与图像采集功能插件相关；

S708-2，目标异常类加载失败，确认造成异常的原因与图像采集功能插件无关；

S710，由S708-1中确认是图像采集功能插件导致的用户无法打开摄像头进行拍摄，在该社交应用软件的数据存储本地进行查找旧版的图像采集功能插件，其中，该旧版的图像采集功能插件支持用户正常拍摄；

S712，在该社交应用软件的数据存储本地未查找到支持用户正常拍摄的旧版的图像采集功能插件，即不进行图像采集功能插件的版本回滚操作；

S714，获取到支持用户正常拍摄的旧版图像采集功能插件之后，对旧版图像采集功能插件进行进一步验证，包括该旧版图像采集功能插件适配于用户使用的当前社交应用软件版本，同时不是异常名单插件中的插件；

S716，如果用户在当前社交应用软件频繁发生无法打开摄像头进行拍摄的问题（对应于图7所示的触发崩溃），则把对应的图像采集功能插件问题版本加入异常名单插件中，在旧版图像采集功能插件通过S714中的验证后，将当前导致社交应用软件异常的图像采集功能插件回滚为旧版图像采集功能插件。

S718，图像采集功能插件版本回滚结束，用户可以暂时按照回滚的版本正常使用摄像头进行拍摄。

在又一个示例性的实施例中，上述应用程序的修复方法还可以应用于网页端游戏突发异常的实际场景中，如图7所示：

S1，网页端游戏正常使用过程中发生异常，玩家无法操纵游戏角色进行换装；

S2，获取网页端游戏的异常堆栈信息，解析该异常堆栈信息，进而确定目标异常类；

S3，通过该网页端游戏的类加载器加载目标异常类；

S4-1，目标异常类加载成功，确认造成异常的原因与角色定制功能插件相关；

S4-2，目标异常类加载失败，确认造成异常的原因与角色定制功能插件无关；

S5，由S4-1中确认是角色定制功能插件导致的玩家无法操纵游戏角色进行换装，在该社交应用软件的数据存储本地进行查找旧版的角色定制功能插件，其中，该旧版角色定制功能插件支持玩家正常操纵游戏角色进行换装；

S6，在该社交应用软件的数据存储本地未查找到支持玩家正常操纵游戏角色进行换装的旧版角色定制功能插件，即不进行角色定制功能插件的版本回滚操作；

S7，获取到支持玩家正常操纵游戏角色进行换装的旧版角色定制功能插件之后，对旧版角色定制功能插件进行进一步验证，包括该旧版角色定制功能插件适配于玩家使用的当前网页端游戏版本，同时不是异常名单插件中的插件；

S8，如果玩家在当前网页端游戏频繁发生无法操纵游戏角色进行换装的问题，则把对应的角色定制功能插件问题版本加入异常名单插件中，在旧版角色定制功能插件通过S7中的验证后，将当前导致网页端游戏异常的角色定制功能插件回滚为旧版角色定制功能插件。

S9，角色定制功能插件版本回滚结束，玩家可以正常操纵游戏角色进行换装。

需要说明的是，上述S714以及上述S7中的异常名单插件，可以理解为，目标插件的某一版本引发上述目标应用程序异常的次数已经达到了预设阈值，将该目标插件对应的版本加入异常名单，禁止上述目标应用程序使用，对于上述预设阈值可以灵活设置，本实施例不做具体限定。

在本申请实施例中，采用在目标应用程序满足预设启动条件的情况下，启动目标应用程序，其中，目标应用程序的工程架构包括框架层和业务层，框架层用于启动目标应用程序，业务层用于执行目标应用程序的业务功能，业务层被设置为通过接入一组插件实现业务功能，在需要更新目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存第一版本对应的第一插件数据，其中，目标插件表示一组插件中与目标业务功能关联的插件，在检测到目标应用程序发生异常，且造成异常的插件为目标插件的情况下，利用第一插件数据将目标插件由第二版本回滚为第一版本的方式，也即，通过在目标应用程序的业务层采用更新插件版本的方式，对造成目标应用程序的目标插件的版本进行回滚，将当前版本替换为之前预先保存的其中一个目标插件版本，快速修复应用程序异常，达到了独立更新插件，及时修复应用程序异常的目的，从而实现了提高应用程序修复效率，同时保证了应用程序安全性的技术效果，进而解决了由于通过发布新版本应用程序来修复应用程序异常的耗时较长，升级过程风险大，导致应用程序的修复效率较低的技术问题。

作为一种可选的方案，上述在检测到上述目标应用程序发生异常，且造成异常的插件为上述目标插件的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本，包括：在检测到上述目标应用程序发生异常的情况下，确定造成异常的原因是否为上述目标插件；在确定造成异常的原因为上述目标插件，且上述目标插件由上述第一版本更新为上述第二版本的情况下，查找上述第一插件数据；在查找到上述第一插件数据的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本。

示例性地，当上述目标应用程序发生异常，例如，上述目标应用程序出现无法支持用户登录，或者无法正常退出的情况，确定造成异常的原因，可以理解为，分析上述目标应用程序发生异常，根据上述目标应用程序表现的特征，确定是否为对应的上述目标插件造成该目标应用程序异常；

需要说明的是，在确认由上述目标插件导致的上述目标应用程序发生异常，且上述目标插件发生异常前为上述第一版本，经过更新后，该目标插件版本为上述第二版本。

在一个示例性的实施例中，查找上述第一版本对应的上述第一插件数据，根据该第一插件数据将上述目标插件当前对应的第二版本回滚为上述第一版本，其中，上述第一插件数据可以通过以下方式获取，包括但不限于查询目标应用程序的本地缓存。

进一步地，上述第一版本与上述第二版本均可以完全或部分实现同一业务功能，也就是说，将上述目标插件由上述第二版本回滚为上述第一版本之后，并不会完全影响目标应用程序的正常使用。

示例性地，图8是根据本申请实施例的一种可选的应用程序的插件安装示意图，如图8所示，在移动端将任意一个APK（Android Package Kit）指示的目标插件从第二版本（当前版本）回滚为第一版本(上一版本)可以通过如下步骤实现：

S1，首先对目标插件的第一版本对应的版本信息进行检验802，解析第一版本对应的版本信息，确认为降级安装插件模式，校验目标插件的第一版本对应的完整性以及安全性，同时卸载目标插件的第二版本；

S2，拷贝目标插件的第一版本804，创建目标插件的版本安装目录，将插件依赖项拷贝至安装目录下；

S3，记录插件806，将目标插件的第二版本对应的版本信息更新为目标插件的第一版本对应的版本信息，在相关配置文件中进行版本号、目标插件包名等相关信息的记录。

通过本实施例，采用在检测到目标应用程序发生异常的情况下，确定造成异常的原因是否为目标插件的方式，在确定造成异常的原因为目标插件，且目标插件由第一版本更新为第二版本之后，查找到第一插件数据，利用该第一插件数据将目标插件由第二版本回滚为第一版本，达到了快速准确地定位目标应用程序发生异常的原因的技术效果，深入了解异常发生的原因和机制，为进一步的目标应用程序优化和升级提供有价值的数据支持。

作为一种可选的方案，上述在查找到上述第一插件数据的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本，包括：在上述第一版本不属于预设插件版本集合的情况下，查找上述第一插件数据，其中，上述预设插件版本集合表示造成异常的次数满足预设阈值的插件版本集合；利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本；将上述第二版本添加至上述预设插件版本集合，并保存上述第二版本对应的第二插件数据，其中，上述第一版本对应的上述目标插件允许使用上述第二插件数据中的业务数据。

可选地，在本实施例中，上述预设插件版本集合中的插件版本可以包括但不限于刷脸支付插件第1至第N个版本、刷掌支付插件第1至第N个版本等，其中，上述预设插件版本集合可以是由上述插件版本集合中部分插件版本组成，也就是说，上述插件版本集合可以理解为上述目标应用程序中的某一业务功能插件的发布过的版本集合，而上述预设插件版本集合为上述目标应用程序中的某一业务功能插件的发布过的部分版本集合，且处于上述预设插件版本集合中的插件版本均会导致上述目标应用程序发生异常，也即，上述预设插件版本集合可以用于表示异常名单插件版本。

此外，上述第二插件数据和上述业务数据可以包括但不限于插件名称、插件描述、插件依赖、插件功能、插件配置、插件安装时间、插件更新历史、插件使用情况等，同时，本申请对上述预设阈值的具体取值不做限定，当上述目标插件的某一版本造成上述目标应用程序异常的次数满足预设阈值时，将目标插件对应的该版本放置在上述预设插件版本集合中。

需要说明的是，采用上述第一版本替换上述第二版本，查找上述第一插件数据，其中，上述第一版本不属于预设插件版本集合，也就是说，上述第一版本的目标插件造成上述目标应用程序异常的次数还未满足上述预设阈值。

在一个示例性的实施例中，将上述第二版本添加至上述预设插件版本集合，也就是说，上述第二版本的目标插件造成上述目标应用程序异常的次数已经满足上述预设阈值，将被禁止使用，同时保存上述第二版本对应的第二插件数据，可以理解为，上述第二插件数据中的业务数据可以被上述目标插件使用，而第一插件数据中的业务数据同样可以被上述目标插件使用，也就是说，上述第一版本与上述第二版本可以实现部分相同的业务功能。

通过本实施例，采用在第一版本不属于预设插件版本集合的情况下，查找第一插件数据，预设插件版本集合表示造成异常的次数满足预设阈值的插件版本集合，利用第一插件数据将目标插件由第二版本回滚为第一版本，将第二版本添加至预设插件版本集合，并保存第二版本对应的第二插件数据，实现了针对性地对异常进行修复，提高异常修复的效率的技术效果。

作为一种可选的方案，在检测到上述目标应用程序发生异常的情况下，确定造成异常的原因是否为上述目标插件，包括：在检测到上述目标应用程序发生异常的情况下，获取异常堆栈信息，其中，上述异常堆栈信息表示上述目标应用程序发生异常时记录的堆栈信息；根据上述异常堆栈信息确定目标异常类，并通过类加载器加载上述目标异常类，其中，上述目标异常类包括造成上述目标应用程序发生异常的代码片段；根据上述目标异常类的加载结果确定造成异常的原因，其中，在上述加载结果表示上述目标异常类加载成功的情况下，上述造成异常的原因与插件相关，在上述加载结果表示上述目标异常类加载失败的情况下，上述造成异常的原因与插件不相关。

可选地，在本实施例中，上述异常堆栈信息可以理解为在目标应用程序运行过程中发生的错误的详细信息，包括但不限于错误类型、出错位置以及调用堆栈等。

示例性地，上述目标应用程序发生异常，需要确定造成异常的原因，判断是否为上述目标插件导致的该目标应用程序异常，对异常堆栈信息进行获取，可以理解为获取上述目标应用程序发生异常的异常类型、异常位置以及异常调用的堆栈等。

具体而言，根据上述异常堆栈信息来确定目标异常类，上述目标异常类可以包括但不限造成异常的底层代码片段等，通过类加载器加载上述目标异常类之后，确定造成上述目标应用程序发生异常的原因，其中，上述类加载器可以包括但不限于根类加载器、扩展类加载器、应用类加载器、自定义类加载器，往往用于根据不同的需求来加载不同的类或资源。

在一个示例性的实施例中，上述目标异常类加载成功，即上述造成异常的原因与插件相关，反之，若上述目标异常类加载失败，即上述造成异常的原因与插件无关。

通过本实施例，采用在检测到目标应用程序发生异常的情况下，获取异常堆栈信息，根据异常堆栈信息确定目标异常类，并通过类加载器加载目标异常类，根据目标异常类的加载结果确定造成异常的原因，达到了快速定位和修复应用程序的异常问题的技术效果，提高应用程序的稳定性和可靠性。

作为一种可选的方案，在上述加载结果表示上述目标异常类加载失败的情况下，禁止将上述目标插件由上述第二版本回滚为上述第一版本；在上述加载结果表示上述目标异常类加载成功，造成异常的插件为上述目标插件，且上述目标插件由上述第一版本更新为上述第二版本，但未在本地查找到上述第一插件数据的情况下，禁止将上述目标插件由上述第二版本回滚为上述第一版本；在上述加载结果表示上述目标异常类加载成功，造成异常的插件为上述目标插件，上述目标插件由上述第一版本更新为上述第二版本，且上述第一版本属于预设插件版本集合的情况下，禁止将上述目标插件由上述第二版本回滚为上述第一版本，其中，上述预设插件版本集合表示造成异常的次数满足预设阈值的插件版本集合；在禁止将上述目标插件由上述第二版本回滚为上述第一版本的情况下，获取第三版本对应的第三插件数据，其中，上述第一版本对应的上述目标插件由上述第三版本对应的上述目标插件更新得到；利用上述第三插件数据将上述目标插件由上述第二版本回滚为上述第三版本。

可选地，在本实施例中，上述第三版本可以包括但不限于数据库插件版本、操作系统插件版本、虚拟化插件版本、文本编辑器插件版本等，第三插件数据可以包括但不限于插件名称、插件描述、插件依赖、插件功能、插件配置、插件安装时间、插件更新历史、插件使用情况等。

需要说明的是，根据上述加载结果，确定上述目标异常类加载失败的也即上述造成异常的原因与上述目标插件无关，禁止将上述目标插件由上述第二版本回滚为上述第一版本，可以理解为，将上述第二版本回滚为上述第一版本也无法修复上述目标应用程序的异常。

此外，当上述目标异常类加载成功，也就是说，上述目标插件造成了上述目标应用程序的异常，同时上述目标插件是由上述第一版本更新为上述第二版本，可以理解为，上述第一版本先于上述第二版本安装在上述目标应用程序中，并且，上述第一版本与上述第二版本对应于同一目标业务功能，未在本地查找到上述第一插件数据，将禁止将上述目标插件由上述第二版本回滚为上述第一版本，即无法将上述第二版本回滚为上述第一版本，另一方面，若在本地查找到上述第一插件数据的情况下，上述第一版本属于预设插件版本集合的情况下，同样禁止将上述目标插件由上述第二版本回滚为上述第一版本，可以理解为，上述第一版本引发上述目标应用程序异常的次数已经达到了上述预设阈值，无法进行使用。

在一个示例性的实施例中，无法将上述目标插件由上述第二版本回滚至上述第一版本，可以获取第三版本对应的第三插件数据，其中，上述第三版本与上述第一版本、上述第二版本对应于同一目标业务功能，可以安装在上述目标应用程序中实现部分相同的功能，可以理解为，上述第三版本引发上述目标应用程序异常的次数未达到上述预设阈值，同时，上述第三版本不会引发上述第二版本引发的上述目标应用程序异常，利用上述第三插件数据将上述目标插件由上述第二版本回滚为上述第三版本，修复上述目标应用程序当前发生的异常。

通过本实施例，采用在加载结果表示目标异常类加载失败的情况下，禁止将目标插件由第二版本回滚为第一版本，在加载结果表示目标异常类加载成功，造成异常的插件为目标插件，且目标插件由第一版本更新为第二版本，但未在本地查找到第一插件数据的情况下，禁止将目标插件由第二版本回滚为第一版本，在加载结果表示目标异常类加载成功，造成异常的插件为目标插件，目标插件由第一版本更新为第二版本，且第一版本属于预设插件版本集合的情况下，禁止将目标插件由第二版本回滚为第一版本，通过获取第三版本对应的第三插件数据，利用第三插件数据将目标插件由第二版本回滚为第三版本，实现了及时发现异常，并采取修复措施的技术效果。

作为一种可选的方案，上述根据上述异常堆栈信息确定目标异常类，并通过类加载器加载上述目标异常类之后，上述方法还包括：通过公共类加载器加载上述目标异常类，获取目标类列表，从上述目标类列表中根据上述目标异常类确定上述目标插件，其中，上述公共类加载器与上述目标应用程序相关联，上述目标类列表中的一个列表项与上述目标应用程序接入的一个插件相关联；或者通过独立类加载器加载上述目标异常类，确定上述目标插件，其中，上述独立类加载器与上述目标插件相对应。

可选地，在本实施例中，上述公共类加载器和上述独立类加载器可以包括但不限于根类加载器、扩展类加载器、应用类加载器、自定义类加载器，上述目标类列表可以包括但不限于用户登录目标类、文件下载目标类、刷脸支付目标类、刷掌支付目标类、刷掌门禁目标类、刷掌地铁目标类、数据查询目标类等。

在一个示例性的实施例中，通过类加载器加载根据上述异常堆栈信息所确定的目标异常类之后，可以通过公共类加载器加载上述目标异常类，进而获取目标类列表，也就是说，加载上述目标异常类之后，可以再次将上述目标异常类输入与上述目标应用程序相关联的公共类加载器，加载之后获取相应的上述目标应用程序中的目标类列表，根据上述目标类列表，进而得知上述目标应用程序可能导致异常的功能插件数据所在文件的位置。

需要说明的是，根据上述功能插件数据所在文件的位置，可以得到导致上述目标应用程序发生异常的上述目标插件的具体信息。

示例性地，还可以通过将上述目标异常类输入与上述目标插件相对应的独立类加载器，加载之后确定上述目标插件。

通过本实施例，通过公共类加载器加载目标异常类，获取目标类列表，从目标类列表中根据目标异常类确定目标插件，或者通过独立类加载器加载目标异常类，确定目标插件，提高了目标应用程序的稳定性和可靠性。

作为一种可选的方案，上述在目标应用程序满足预设启动条件的情况下，启动上述目标应用程序，包括：在目标应用程序满足预设启动条件的情况下，加载上述框架层；利用上述框架层加载上述业务层中的基础层，其中，上述基础层与上述多个插件中的第一组插件对应，上述第一组插件包括内置在上述目标应用程序安装包中的基础插件，上述基础插件与至少两个业务功能相关联，上述基础层的更新频率大于上述框架层。

可选地，在本实施例中，上述基础层可以包括但不限于应用程序代码基础组件、公共资源组件等。

需要说明的是，启动上述目标应用程序，可以加载上述框架层，也就是说，上述框架层的加载早于上述业务层，通过接口通信，利用上述框架层，再对上述业务层中的基础层进行加载，上述内置在上述目标应用程序安装包中的基础插件对应于上述基础层，可以理解为，上述基础插件位于上述基础层，该基础层至少提供上述目标应用程序的基础代码功能以及公共资源的功能插件，其中，位于上述基础层的上述基础插件所实现的功能均是上述目标应用程序所必需的，例如，网络接口实现，获取网络请求，UI界面静态资源等。

在一个示例性的实施例中，上述基础层的更新频率大于上述框架层，可以理解为，位于上述目标应用程序中的插件的更新频率大于上述目标应用程序中的框架层的更新频率。

通过本实施例，采用在目标应用程序满足预设启动条件的情况下，加载框架层，利用框架层，加载业务层中与多个插件中的第一组插件对应的基础层，其中，基础层的更新频率大于框架层，提高了应用程序的灵活性、可扩展性和可维护性，使得应用程序更加适应变化的需求。

作为一种可选的方案，上述响应于目标业务需求，利用上述框架层加载目标业务插件，包括：响应于上述目标业务需求，从上述框架层获取目标网络接口，其中，上述目标网络接口是上述基础层预先在上述框架层注册的网络结构；在确定上述基础层定义了上述目标网络接口的接口能力的情况下，通过上述基础层向目标服务器发送与上述目标业务需求关联的网络请求。

可选地，在本实施例中，上述目标服务器可以包括但不限于物理服务器、虚拟服务器、云服务器、独立服务器等。

示例性地，图9是根据本申请实施例的一种可选的应用程序的网络请求示意图，如图9所示：

S1，目标应用程序启动之后，加载框架层908，其中，包括接口管理模块；

S2，处于902业务层中的906基础层通过请求框架层908，注册网络接口，与服务器通信，进行910网络接口定义，通过接口执行来自网络的图片下载请求；

S3，处于902业务层中的904子业务层通过请求框架层908，获取网络接口，实现图片下载功能。

在一个示例性的实施例中，终端发出上述目标业务需求后，上述目标应用程序将从上述框架层获取目标网络接口，可以理解为，上述基础层请求上述框架层，注册网络结构，获取上述网络接口，进而向目标服务器发送网络请求，该网络请求与上述目标业务需求相对应，即该网络请求用于请求上述目标业务需求所需要的资源。

需要说明的是，图10是根据本申请实施例的一种可选的应用程序的插件类型示意图，如图10所示，对于上述目标应用程序中的插件加载可以按照如下方式进行划分，包括但不限于：

S1，应用程序安装时加载1002的插件，即为处于上述基础层的上述基础组件，例如，支付主流程模块插件，当用户启动目标应用程序的目的是为了进行刷脸支付，或者启动后可能马上进行刷脸支付，不能长时间等待插件下载加载后才能使用，而需要尽快使用；

S2，按需加载1004的插件，可以理解为，某些不影响业务主流程的模块，可以在用到的时候再去加载，例如，性能模块插件，可以等性能组件加载好了才开启性能检测功能；

S3，根据条件加载1006，即根据特定的用户设备需求（硬件特性、接口级别）或者业务场景（无人零售）来选择性下发模块插件，例如，不需要运营能力的无人零售场景，不适合使用视频海报的低端性能设备。

示例性地，图11是根据本申请实施例的一种可选的应用程序的插件加载流程示意图，在上述业务层中除了上述基础层所包括的基础插件，还包括其他插件，如图11所示，可以通过如下步骤进行插件的加载，包括但不限于：

S1102，应用程序启动；

S1104，应用程序加载必需的基础插件；

S1106，应用程序预载非必需的业务插件；

S1108，应用程序在首次用到某一个业务时，加载该某个业务插件。

通过本实施例，采用响应于上述目标业务需求，从上述框架层获取目标网络接口，在确定上述基础层定义了上述目标网络接口的接口能力的情况下，上述基础层向目标服务器发送与上述目标业务需求关联的网络请求，达到了提高应用程序的性能和处理效率的技术效果。

作为一种可选的方案，上述在需要更新上述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存上述第一版本对应的第一插件数据，包括：获取初始插件记录文件，其中，上述初始插件记录文件记录有上述目标应用程序执行上述目标业务功能所使用的插件为上述第一版本；在检测到需要更新上述目标业务功能的情况下，下载上述第二版本对应的上述目标插件；升级安装上述第二版本对应的上述目标插件；将上述初始插件记录文件修改为第一插件记录文件，并保存上述第一版本对应的第一插件数据，其中，上述第一插件记录文件记录有上述目标应用程序执行上述目标业务功能所使用的插件为上述第二版本。

可选的，在本实施例中，上述初始插件记录文件和上述第一插件记录文件记录的内容可以包括但不限于插件名称、插件描述、插件依赖、插件功能、插件配置、插件安装时间、插件更新历史、插件使用情况等。

需要说明的是，根据获取到的初始插件记录文件，可以得知上述目标应用程序正在使用的目标插件的版本，来执行与该目标插件对应的上述目标业务功能。

在一个示例性的实施例中，上述目标应用程序检测到需要更新上述目标业务功能，可以下载上述目标插件的上述第二版本，升级安装上述第二版本对应的上述目标插件，可以理解为，将上述目标版本的上述第一版本替换为上述第二版本。

此外，保存上述第一版本对应的第一插件数据，将上述初始插件记录文件修改为第一插件记录文件，也就是说，上述初始插件记录文件记录的执行上述目标业务功能所使用的插件为上述第一版本，上述第一插件记录的执行上述目标业务功能所使用的插件为上述第二版本。

通过本实施例，采用获取初始插件记录文件，在检测到需要更新目标业务功能的情况下，下载第二版本对应的目标插件，升级安装第二版本对应的目标插件，将初始插件记录文件修改为第一插件记录文件，并保存第一版本对应的第一插件数据，达到了提高应用程序的版本更新效率的技术效果。

作为一种可选的方案，上述在检测到上述目标应用程序发生异常，且造成异常的插件为上述目标插件的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本，包括：在检测到上述目标应用程序发生异常，且造成异常的插件为上述目标插件的情况下，降级安装上述第一版本对应的上述目标插件；将上述第一插件记录文件修改为目标插件记录文件，其中，上述目标插件记录文件记录有上述目标应用程序执行上述目标业务功能所使用的插件为上述第一版本。

在一个示例性的实施例中，上述目标应用程序发生异常，可以将上述第二版本回滚为上述第一版本，其中，上述第一版本发布时间早于上述第二版本发布时间。

在一个示例性的实施例中，上述目标插件文件记录的内容可以包括但不限于插件名称、插件描述、插件依赖、插件功能、插件配置、插件安装时间、插件更新历史、插件使用情况等，在上述第二版本回滚为上述第一版本之后，可以将上述第一插件记录文件修改为上述目标插件记录文件，也即，上述第一插件记录文件记录的执行上述目标业务功能所使用的插件为上述第二版本，上述目标插件文件记录的执行上述目标业务功能所使用的插件为上述第一版本。

通过本实施例，采用在检测到目标应用程序发生异常，且造成异常的插件为目标插件的情况下，降级安装第一版本对应的目标插件，将第一插件记录文件修改为目标插件记录文件，达到了提高应用程序的修复异常的效率的技术效果。

下面结合具体的实施例，对本申请进行进一步的解释说明：

本申请对于整个目标应用程序工程进行插件化改造，将大部分的核心模块都抽离成插件，然后以插件的方式接入到目标应用程序，首先进行工程架构的改造，整个工程架构需要改造成如图3所示，工程至少分为两层：

S1，框架层，这一层一直都在目标应用程序里面的，这部分代码功能都提供了一些必须的基础能力，例如，目标应用程序启动就会跑到的启动逻辑，各个模块接口的管理等，一旦稳定下来，基本不会因为业务变动而需要跟着改变，变更频率很低，如果框架层的代码需要变动，那就需要进行目标应用程序的整包升级；

S2，业务层，其中，包括：基础层和子业务层，基础层还可以分为两部分，一部分是代码基础组件，主要提供一些公共能力，例如，公共UI组件，公共的网络通信能力等；另一部分是公共的资源，主要是把业务层用到的一些公共的资源下沉到这一层；子业务层，实现业务逻辑。

其中，各层之间完全通过接口来通信，每一层都可以通过不同的接口，来对外暴露需要对外提供的能力，外部通过接口来使用相关的接口功能，对于接口的管理，统一放在框架层管理。通过框架层以及业务层中的两个子层来共同组成一个完整的业务目标应用程序。各层之间需要进行数据通信的，为了避免数据通信存在耦合从而影响到插件化的效果，本申请设计一种接口注册的方式来实现模块间直接的接口通信，如图9所示。

S1，通过接口通信的方式可以实现各个层之间的通信最低限度的耦合，保证插件的高内聚，低耦合的特点，让插件加载可以更加高效，低风险的执行，之所以要把工程架构抽离的原因是：从变更频率来讲，子业务层的变更频率远大于基础层，而基础层的变更频率大于框架层，因此将业务层做成以插件的方式接入，其中，基础层的插件属于必要插件（内置插件），起始便内置在应用程序安装包内，随应用程序安装包下发，而子业务层的插件属于非必要插件（外置插件），可以在用到该业务的时候才去加载，因此必要插件在目标应用程序启动的时候加载，非必要插件在目标应用程序启动的时候部分选择预载方式，部分非必要插件在用到的首次才去加载，如图11所示；

S2，基于S1提出的插件特点把插件拆分成几种接入模式，如图10所示；

S3，将业务层都抽离为插件后，整个目标应用程序可以达到50%以上的模块均支持插件升级，而且这50%支持插件升级的模块变更频率可以占到总体变更频率的80%以上；

S4，图12是根据本申请实施例的一种可选的应用程序的插件修复示意图，设计如图12所示的插件安装策略，目标应用程序中至少有一半以上的高频使用模块都是可以支持插件修复升级或者降级的，本地的秒级回滚策略依赖插件的降级安装；

S5，将插件的安装信息记录到本地的xml文件中去，图13是根据本申请实施例的一种可选的应用程序的本地配置文件示意图，如图13所示，其中，versionCode用来控制插件的升级或者降级安装，插件安装模式包括但不限于：

S1，升级安装，常规的安装，不会删除旧版插件，并且会复用旧版插件的数据；

S2，降级安装，会把当前高版本的插件替换安装成低版本的插件，并且会继续沿用高版本的数据；

S3，卸载安装，会先把当前已经安装的插件卸载清除掉，然后再安装新的插件，不会复用原来旧版本的插件数据，正常情况加插件走常规升级安装。

当新版插件成功升级安装后，旧版插件也不删除，依旧保留在内部存储中，新版插件只是更新了插件记录文件，该插件记录文件标记当前宿主使用的插件是新版插件的版本，同时旧版插件的版本信息会从插件记录文件中抹除，因此目标应用程序与新旧版的插件之间关系如图4所示。

基于插件的降级安装能力，整体的本地秒级回滚策略包括目标应用程序使用哪个版本的插件通过插件记录文件来指定，因此，目标应用程序可以在任一时刻选择抹除旧版插件的信息，也可以在任一时刻通过降级安装，重新建立跟旧版插件的联系，解决目标应用程序异常问题，在目标应用程序发生异常的时候，提取发生异常模块关联的插件，提取的策略如图5所示，至此，本地秒级回滚整体的设计结束，总结下主要分为几个步骤：

S1，工程架构插件化改造；

S2，插件安装策略；

S3，插件回滚策略；

S4，异常提取策略。

图14是根据本申请实施例的一种可选的应用程序的修复效果的示意图，如图14所示，由于整个回滚操作都是发生在本地，因此无需联网，即可做到秒级回滚，相较于传统的升级修复具有比较明显的优势。

随着业务的发展，目标应用程序使用的人数，次数都在不断的上涨，因此对于目标应用程序的稳定性的要求也在不断的提升，当目标应用程序在出现问题的时候，如何通过一种手段来实现第一时间修复问题，并恢复目标应用程序业务，进而尽可能小的影响用户使用。传统的升级修复存在时间长，升级慢且风险高的问题，本申请利用插件技术实现的本地秒级回滚方案，实现了在时效内，应用遇到异常问题的第一时间就自动捕获，自动检测，自动触发本地降级回滚策略，在短时间内快速回滚到上一个可用版本，第一时间保证业务可用性，保证了业务的口碑。

通过将目标应用程序工程进行分层架构改造，颠覆了传统模式将不重要的模块打包成插件的方式，将重要核心的模块都打包成插件，并通过基础层，业务层和框架层的分层模式来界定插件升级的边界，支持至少一半以上的高频使用的核心模块进行插件化；同时设计实现了插件降级安装策略，让插件可以在升级的同时，保留老插件的信息和数据，在需要降级的时候重新启用老插件做到了本地降级回滚；最后通过自动捕获异常，自动检测异常堆栈的方式关联异常模块所属的插件，精准计算开启本地回滚操作的时机，将需要进行回滚操作的插件执行回滚，保证了业务的可用性。

可以理解的是，在本申请的具体实施方式中，涉及到用户信息等相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

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

根据本申请实施例的另一个方面，还提供了一种用于实施上述应用程序的修复方法的应用程序的修复装置。如图15所示，该装置包括：

启动模块1502，用于在目标应用程序满足预设启动条件的情况下，启动上述目标应用程序，其中，上述目标应用程序的工程架构包括框架层和业务层，上述框架层用于启动上述目标应用程序，上述业务层用于执行上述目标应用程序的业务功能，上述业务层被设置为通过接入一组插件实现上述业务功能；

控制模块1504，用于在需要更新上述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存上述第一版本对应的第一插件数据，其中，上述目标插件表示上述一组插件中与上述目标业务功能关联的插件；

处理模块1506，用于在检测到上述目标应用程序发生异常，且造成异常的插件为上述目标插件的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本。

作为一种可选的方案，上述装置用于通过如下方式在检测到上述目标应用程序发生异常，且造成异常的插件为上述目标插件的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本：在检测到上述目标应用程序发生异常的情况下，确定造成异常的原因是否为上述目标插件；在确定造成异常的原因为上述目标插件，且上述目标插件由上述第一版本更新为上述第二版本的情况下，查找上述第一插件数据；在查找到上述第一插件数据的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本。

作为一种可选的方案，上述装置用于通过如下方式在查找到上述第一插件数据的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本：在上述第一版本不属于预设插件版本集合的情况下，查找上述第一插件数据，其中，上述预设插件版本集合表示造成异常的次数满足预设阈值的插件版本集合；利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本；将上述第二版本添加至上述预设插件版本集合，并保存上述第二版本对应的第二插件数据，其中，上述第一版本对应的上述目标插件允许使用上述第二插件数据中的业务数据。

作为一种可选的方案，上述装置用于通过如下方式在检测到上述目标应用程序发生异常的情况下，确定造成异常的原因是否为上述目标插件：在检测到上述目标应用程序发生异常的情况下，获取异常堆栈信息，其中，上述异常堆栈信息表示上述目标应用程序发生异常时记录的堆栈信息；根据上述异常堆栈信息确定目标异常类，并通过类加载器加载上述目标异常类，其中，上述目标异常类包括造成上述目标应用程序发生异常的代码片段；根据上述目标异常类的加载结果确定造成异常的原因，其中，在上述加载结果表示上述目标异常类加载成功的情况下，上述造成异常的原因与插件相关，在上述加载结果表示上述目标异常类加载失败的情况下，上述造成异常的原因与插件不相关。

作为一种可选的方案，上述装置还用于：在上述加载结果表示上述目标异常类加载失败的情况下，禁止将上述目标插件由上述第二版本回滚为上述第一版本；在上述加载结果表示上述目标异常类加载成功，造成异常的插件为上述目标插件，且上述目标插件由上述第一版本更新为上述第二版本，但未在本地查找到上述第一插件数据的情况下，禁止将上述目标插件由上述第二版本回滚为上述第一版本；在上述加载结果表示上述目标异常类加载成功，造成异常的插件为上述目标插件，上述目标插件由上述第一版本更新为上述第二版本，且上述第一版本属于预设插件版本集合的情况下，禁止将上述目标插件由上述第二版本回滚为上述第一版本，其中，上述预设插件版本集合表示造成异常的次数满足预设阈值的插件版本集合；在禁止将上述目标插件由上述第二版本回滚为上述第一版本的情况下，获取第三版本对应的第三插件数据，其中，上述第一版本对应的上述目标插件由上述第三版本对应的上述目标插件更新得到；利用上述第三插件数据将上述目标插件由上述第二版本回滚为上述第三版本。

作为一种可选的方案，上述装置还用于：上述根据上述异常堆栈信息确定目标异常类，并通过类加载器加载上述目标异常类之后，通过公共类加载器加载上述目标异常类，获取目标类列表，从上述目标类列表中根据上述目标异常类确定上述目标插件，其中，上述公共类加载器与上述目标应用程序相关联，上述目标类列表中的一个列表项与上述目标应用程序接入的一个插件相关联；或者通过独立类加载器加载上述目标异常类，确定上述目标插件，其中，上述独立类加载器与上述目标插件相对应。

作为一种可选的方案，上述装置用于通过如下方式在目标应用程序满足预设启动条件的情况下，启动上述目标应用程序：在目标应用程序满足预设启动条件的情况下，加载上述框架层；利用上述框架层加载上述业务层中的基础层，其中，上述基础层与上述多个插件中的第一组插件对应，上述第一组插件包括内置在上述目标应用程序安装包中的基础插件，上述基础插件与至少两个业务功能相关联，上述基础层的更新频率大于上述框架层。

作为一种可选的方案，上述装置用于通过如下方式利用上述框架层加载上述业务层对应的第一组插件之后，包括：利用上述框架层预加载上述业务层中的第二组插件，其中，上述第二组插件包括预先设置的需要提前加载的业务插件，一个上述业务插件与至少一个业务功能相关联，上述第二组插件的更新频率大于上述框架层；响应于目标业务需求，利用上述框架层加载目标业务插件，其中，上述目标业务插件包括预先设置的首次触发上述目标业务需求所需要加载的业务插件，一个上述目标业务插件与至少一个业务功能相关联，上述目标业务插件的更新频率大于上述框架层。

作为一种可选的方案，上述装置用于通过如下方式响应于目标业务需求，利用上述框架层加载目标业务插件：响应于上述目标业务需求，从上述框架层获取目标网络接口，其中，上述目标网络接口是上述基础层预先在上述框架层注册的网络结构；在确定上述基础层定义了上述目标网络接口的接口能力的情况下，通过上述基础层向目标服务器发送与上述目标业务需求关联的网络请求。

作为一种可选的方案，上述装置用于通过如下方式在需要更新上述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存上述第一版本对应的第一插件数据：获取初始插件记录文件，其中，上述初始插件记录文件记录有上述目标应用程序执行上述目标业务功能所使用的插件为上述第一版本；在检测到需要更新上述目标业务功能的情况下，下载上述第二版本对应的上述目标插件；升级安装上述第二版本对应的上述目标插件；将上述初始插件记录文件修改为第一插件记录文件，并保存上述第一版本对应的第一插件数据，其中，上述第一插件记录文件记录有上述目标应用程序执行上述目标业务功能所使用的插件为上述第二版本。

作为一种可选的方案，上述装置用于通过如下方式在检测到上述目标应用程序发生异常，且造成异常的插件为上述目标插件的情况下，利用上述第一插件数据将上述目标插件由上述第二版本回滚为上述第一版本：在检测到上述目标应用程序发生异常，且造成异常的插件为上述目标插件的情况下，降级安装上述第一版本对应的上述目标插件；将上述第一插件记录文件修改为目标插件记录文件，其中，上述目标插件记录文件记录有上述目标应用程序执行上述目标业务功能所使用的插件为上述第一版本。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

根据本申请的一个方面，提供了一种计算机程序产品，该计算机程序产品包括计算机程序/指令，该计算机程序/指令包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1609从网络上被下载和安装，和/或从可拆卸介质1611被安装。在该计算机程序被中央处理器1601执行时，执行本申请实施例提供的各种功能。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

图16示意性地示出了用于实现本申请实施例的电子设备的计算机系统结构框图。

需要说明的是，图16示出的电子设备的计算机系统1600仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图16所示，计算机系统1600包括中央处理器1601（Central Processing Unit，CPU），其可以根据存储在只读存储器1602（Read-Only Memory，ROM）中的程序或者从存储部分1608加载到随机访问存储器1603（Random Access Memory，RAM）中的程序而执行各种适当的动作和处理。在随机访问存储器1603中，还存储有系统操作所需的各种程序和数据。中央处理器1601、在只读存储器1602以及随机访问存储器1603通过总线1604彼此相连。输入/输出接口1605（Input /Output接口，即I/O接口）也连接至总线1604。

以下部件连接至输入/输出接口1605：包括键盘、鼠标等的输入部分1606；包括诸如阴极射线管（Cathode Ray Tube，CRT）、液晶显示器（Liquid Crystal Display，LCD）等以及扬声器等的输出部分1607；包括硬盘等的存储部分1608；以及包括诸如局域网卡、调制解调器等的网络接口卡的通信部分1609。通信部分1609经由诸如因特网的网络执行通信处理。驱动器1610也根据需要连接至输入/输出接口1605。可拆卸介质1611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1610上，以便于从其上读出的计算机程序根据需要被安装入存储部分1608。

特别地，根据本申请的实施例，各个方法流程图中所描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1609从网络上被下载和安装，和/或从可拆卸介质1611被安装。在该计算机程序被中央处理器1601执行时，执行本申请的系统中限定的各种功能。

根据本申请实施例的又一个方面，还提供了一种用于实施上述应用程序的修复方法的电子设备，该电子设备可以是图1所示的终端设备或服务器。本实施例以该电子设备为终端设备为例来说明。如图17所示，该电子设备包括存储器1702和处理器1704，该存储器1702中存储有计算机程序，该处理器1704被设置为通过计算机程序执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述电子设备可以位于计算机网络的多个网络设备中的至少一个网络设备。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，在目标应用程序满足预设启动条件的情况下，启动目标应用程序，其中，目标应用程序的工程架构包括框架层和业务层，框架层用于启动目标应用程序，业务层用于执行目标应用程序的业务功能，业务层被设置为通过接入一组插件实现业务功能；

S2，在需要更新目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存第一版本对应的第一插件数据，其中，目标插件表示一组插件中与目标业务功能关联的插件；

S3，在检测到目标应用程序发生异常，且造成异常的插件为目标插件的情况下，利用第一插件数据将目标插件由第二版本回滚为第一版本。

可选地，本领域普通技术人员可以理解，图17所示的结构仅为示意，电子装置电子设备也可以是智能手机（如Android手机、iOS手机等）、平板电脑、掌上电脑以及移动互联网设备（Mobile Internet Devices，MID）、PAD等终端设备。图17其并不对上述电子装置电子设备的结构造成限定。例如，电子装置电子设备还可包括比图17中所示更多或者更少的组件（如网络接口等），或者具有与图17所示不同的配置。

其中，存储器1702可用于存储软件程序以及模块，如本申请实施例中的应用程序的修复方法和装置对应的程序指令/模块，处理器1704通过运行存储在存储器1702内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的修复方法。存储器1702可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1702可进一步包括相对于处理器1704远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。其中，存储器1702具体可以但不限于用于存储目标应用程序资源和目标插件版本资源等信息。作为一种示例，如图17所示，上述存储器1702中可以但不限于包括上述应用程序的修复装置中的启动模块1502、控制模块1504、处理模块1506。此外，还可以包括但不限于上述应用程序的修复装置中的其他模块单元，本示例中不再赘述。

可选地，上述的传输装置1706用于经由一个网络接收或者发送数据。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置1706包括一个网络适配器（Network Interface Controller，NIC），其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置1706为射频（Radio Frequency，RF）模块，其用于通过无线方式与互联网进行通讯。

此外，上述电子设备还包括：显示器1708，用于显示上述目标应用程序；和连接总线1710，用于连接上述电子设备中的各个模块部件。

在其他实施例中，上述终端设备或者服务器可以是一个分布式系统中的一个节点，其中，该分布式系统可以为区块链系统，该区块链系统可以是由该多个节点通过网络通信的形式连接形成的分布式系统。其中，节点之间可以组成点对点网络，任意形式的计算设备，比如服务器、终端等电子设备都可以通过加入该点对点网络而成为该区块链系统中的一个节点。

根据本申请的一个方面，提供了一种计算机可读存储介质，计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述应用程序的修复方面的各种可选实现方式中提供的应用程序的修复方法。

可选地，在本实施例中，上述计算机可读存储介质可以被设置为存储用于执行以下步骤的计算机程序：

S1，在目标应用程序满足预设启动条件的情况下，启动目标应用程序，其中，目标应用程序的工程架构包括框架层和业务层，框架层用于启动目标应用程序，业务层用于执行目标应用程序的业务功能，业务层被设置为通过接入一组插件实现业务功能；

S2，在需要更新目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存第一版本对应的第一插件数据，其中，目标插件表示一组插件中与目标业务功能关联的插件；

S3，在检测到目标应用程序发生异常，且造成异常的插件为目标插件的情况下，利用第一插件数据将目标插件由第二版本回滚为第一版本。

可选地，在本实施例中，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器（Read-Only Memory，ROM）、随机存取器（Random Access Memory，RAM）、磁盘或光盘等。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备（可为个人计算机、服务器或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (12)

1.一种应用程序的修复方法，其特征在于，包括：

在目标应用程序满足预设启动条件的情况下，启动所述目标应用程序，其中，所述目标应用程序的工程架构包括框架层和业务层，所述框架层用于启动所述目标应用程序，所述业务层用于执行所述目标应用程序的业务功能，所述业务层被设置为通过接入一组插件实现所述业务功能；

在需要更新所述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存所述第一版本对应的第一插件数据，其中，所述目标插件表示所述一组插件中与所述目标业务功能关联的插件；

在检测到所述目标应用程序出现异常，且造成异常的插件为所述目标插件的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本；

所述方法还包括：在检测到所述目标应用程序出现异常的情况下，确定造成异常的原因是否为所述目标插件，在确定造成异常的原因为所述目标插件，且所述目标插件由所述第一版本更新为所述第二版本的情况下，查找所述第一插件数据，在查找到所述第一插件数据的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本；

所述在检测到所述目标应用程序出现异常的情况下，确定造成异常的原因是否为所述目标插件，包括：在检测到所述目标应用程序出现异常的情况下，获取异常堆栈信息，其中，所述异常堆栈信息表示所述目标应用程序出现异常时记录的堆栈信息，根据所述异常堆栈信息确定目标异常类，并通过类加载器加载所述目标异常类，其中，所述目标异常类包括造成所述目标应用程序出现异常的代码片段，根据所述目标异常类的加载结果确定造成异常的原因，其中，在所述加载结果表示所述目标异常类加载成功的情况下，所述造成异常的原因与插件相关，在所述加载结果表示所述目标异常类加载失败的情况下，所述造成异常的原因与插件不相关；

所述方法还包括：在根据所述目标异常类的加载结果确定造成异常的原因之后，基于所述目标应用程序的本地配置文件确定所述第一插件数据，根据所述第一插件数据将所述目标插件由所述第二版本自动回滚为所述第一版本，其中，所述本地配置文件用于指示所述目标应用程序执行所述目标业务功能所使用的插件版本。

2.根据权利要求1所述的方法，其特征在于，所述在查找到所述第一插件数据的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本，包括：

在所述第一版本不属于预设插件版本集合的情况下，查找所述第一插件数据，其中，所述预设插件版本集合表示造成异常的次数满足预设阈值的插件版本集合；

利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本；

将所述第二版本添加至所述预设插件版本集合，并保存所述第二版本对应的第二插件数据，其中，所述第一版本对应的所述目标插件允许使用所述第二插件数据中的业务数据。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述加载结果表示所述目标异常类加载失败的情况下，禁止将所述目标插件由所述第二版本回滚为所述第一版本；

在所述加载结果表示所述目标异常类加载成功，造成异常的插件为所述目标插件，且所述目标插件由所述第一版本更新为所述第二版本，但未在本地查找到所述第一插件数据的情况下，禁止将所述目标插件由所述第二版本回滚为所述第一版本；

在所述加载结果表示所述目标异常类加载成功，造成异常的插件为所述目标插件，所述目标插件由所述第一版本更新为所述第二版本，且所述第一版本属于预设插件版本集合的情况下，禁止将所述目标插件由所述第二版本回滚为所述第一版本，其中，所述预设插件版本集合表示造成异常的次数满足预设阈值的插件版本集合；

在禁止将所述目标插件由所述第二版本回滚为所述第一版本的情况下，获取第三版本对应的第三插件数据，其中，所述第一版本对应的所述目标插件由所述第三版本对应的所述目标插件更新得到；

利用所述第三插件数据将所述目标插件由所述第二版本回滚为所述第三版本。

4. 根据权利要求1所述的方法，其特征在于，所述根据所述异常堆栈信息确定目标异常类，并通过类加载器加载所述目标异常类之后，所述方法还包括：

通过公共类加载器加载所述目标异常类，获取目标类列表，从所述目标类列表中根据所述目标异常类确定所述目标插件，其中，所述公共类加载器与所述目标应用程序相关联，所述目标类列表中的一个列表项与所述目标应用程序接入的一个插件相关联；或者

通过独立类加载器加载所述目标异常类，确定所述目标插件，其中，所述独立类加载器与所述目标插件相对应。

5.根据权利要求1所述的方法，其特征在于，所述在目标应用程序满足预设启动条件的情况下，启动所述目标应用程序，包括：

在目标应用程序满足预设启动条件的情况下，加载所述框架层；

利用所述框架层加载所述业务层中的基础层，其中，所述基础层与第一组插件对应，所述第一组插件包括内置在所述目标应用程序安装包中的基础插件，所述基础插件与至少两个业务功能相关联，所述基础层的更新频率大于所述框架层。

6.根据权利要求5所述的方法，其特征在于，所述利用所述框架层加载所述业务层对应的第一组插件之后，所述方法还包括以下至少之一：

利用所述框架层预加载所述业务层中的第二组插件，其中，所述第二组插件包括预先设置的需要提前加载的业务插件，一个所述业务插件与至少一个业务功能相关联，所述第二组插件的更新频率大于所述框架层；

响应于目标业务需求，利用所述框架层加载目标业务插件，其中，所述目标业务插件包括预先设置的首次触发所述目标业务需求所需要加载的业务插件，一个所述目标业务插件与至少一个业务功能相关联，所述目标业务插件的更新频率大于所述框架层。

7.根据权利要求6所述的方法，其特征在于，所述响应于目标业务需求，利用所述框架层加载目标业务插件，包括：

响应于所述目标业务需求，从所述框架层获取目标网络接口，其中，所述目标网络接口是所述基础层预先在所述框架层注册的网络结构；

在确定所述基础层定义了所述目标网络接口的接口能力的情况下，通过所述基础层向目标服务器发送与所述目标业务需求关联的网络请求。

8.根据权利要求1至7中任一项所述的方法，其特征在于，所述在需要更新所述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存所述第一版本对应的第一插件数据，包括：

获取初始插件记录文件，其中，所述初始插件记录文件记录有所述目标应用程序执行所述目标业务功能所使用的插件为所述第一版本；

在检测到需要更新所述目标业务功能的情况下，下载所述第二版本对应的所述目标插件；

升级安装所述第二版本对应的所述目标插件；

将所述初始插件记录文件修改为第一插件记录文件，并保存所述第一版本对应的第一插件数据，其中，所述第一插件记录文件记录有所述目标应用程序执行所述目标业务功能所使用的插件为所述第二版本。

9.根据权利要求8所述的方法，其特征在于，所述在检测到所述目标应用程序出现异常，且造成异常的插件为所述目标插件的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本，包括：

在检测到所述目标应用程序出现异常，且造成异常的插件为所述目标插件的情况下，降级安装所述第一版本对应的所述目标插件；

将所述第一插件记录文件修改为目标插件记录文件，其中，所述目标插件记录文件记录有所述目标应用程序执行所述目标业务功能所使用的插件为所述第一版本。

10.一种应用程序的修复装置，其特征在于，包括：

启动模块，用于在目标应用程序满足预设启动条件的情况下，启动所述目标应用程序，其中，所述目标应用程序的工程架构包括框架层和业务层，所述框架层用于启动所述目标应用程序，所述业务层用于执行所述目标应用程序的业务功能，所述业务层被设置为通过接入一组插件实现所述业务功能；

控制模块，用于在需要更新所述目标应用程序的目标业务功能的情况下，将目标插件由第一版本更新为第二版本，并保存所述第一版本对应的第一插件数据，其中，所述目标插件表示所述一组插件中与所述目标业务功能关联的插件；

处理模块，用于在检测到所述目标应用程序出现异常，且造成异常的插件为所述目标插件的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本；

所述装置还用于：在检测到所述目标应用程序出现异常的情况下，确定造成异常的原因是否为所述目标插件，在确定造成异常的原因为所述目标插件，且所述目标插件由所述第一版本更新为所述第二版本的情况下，查找所述第一插件数据，在查找到所述第一插件数据的情况下，利用所述第一插件数据将所述目标插件由所述第二版本回滚为所述第一版本；

所述装置用于通过如下方式在检测到所述目标应用程序出现异常的情况下，确定造成异常的原因是否为所述目标插件：在检测到所述目标应用程序出现异常的情况下，获取异常堆栈信息，其中，所述异常堆栈信息表示所述目标应用程序出现异常时记录的堆栈信息，根据所述异常堆栈信息确定目标异常类，并通过类加载器加载所述目标异常类，其中，所述目标异常类包括造成所述目标应用程序出现异常的代码片段，根据所述目标异常类的加载结果确定造成异常的原因，其中，在所述加载结果表示所述目标异常类加载成功的情况下，所述造成异常的原因与插件相关，在所述加载结果表示所述目标异常类加载失败的情况下，所述造成异常的原因与插件不相关；

所述装置还用于：在根据所述目标异常类的加载结果确定造成异常的原因之后，基于所述目标应用程序的本地配置文件确定所述第一插件数据，根据所述第一插件数据将所述目标插件由所述第二版本自动回滚为所述第一版本，其中，所述本地配置文件用于指示所述目标应用程序执行所述目标业务功能所使用的插件版本。

11.一种计算机可读的存储介质，其特征在于，所述计算机可读的存储介质包括存储的程序，其中，所述程序可被终端设备或计算机运行时执行所述权利要求1至9任一项中所述的方法。

12.一种电子设备，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为通过所述计算机程序执行所述权利要求1至9任一项中所述的方法。