CN110399246A - 程序修复方法和装置 - Google Patents

Abstract

本申请公开了一种程序修复方法和装置，属于计算机技术领域。所述方法包括：每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件中；程序再次运行时，检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本；当加载路径中的目标组件的版本为崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换加载路径中的目标组件；加载加载路径中替换后的目标组件。本申请通过有针对性的对程序中引起崩溃的组件进行了热更新，而无需更新整个程序，解决了相关技术中程序修复方法较为复杂，修复效率较低的问题。达到了提高程序修复的效率的效果。

Description

程序修复方法和装置

技术领域

本申请涉及计算机技术领域，特别涉及一种程序修复方法和装置。

背景技术

终端中的程序在运行的过程中可能由于各种原因发生崩溃，在程序发生崩溃时，通常需要对程序进行修复。

相关技术中的一种程序修复方法中，通常是在程序运行崩溃后，由工作人员对整个程序进行修复，得到更新版本的程序。之后将更新版本的程序发送至终端进行程序版本的更新。

在实现本申请的过程中，申请人发现相关技术至少存在以下问题：上述程序修复方法较为复杂，修复效率较低。

发明内容

本申请实施例提供了一种程序修复方法和装置。所述技术方案如下：

根据本申请的第一方面，提供了一种程序修复方法，所述方法包括：

每当运行的程序的软件开发工具包中目标组件引起所述程序崩溃时，将所述目标组件的版本信息记录在崩溃文件中；

所述程序再次运行时，检测加载路径中的目标组件的版本是否为所述崩溃文件中记录的版本；

当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换所述加载路径中的目标组件；

加载所述加载路径中替换后的目标组件。

可选地，所述每当运行的程序中的目标组件引起所述程序的崩溃时，记录所述目标组件的奔溃版本的信息之后，所述方法还包括：

向服务器发送所述目标组件引起所述程序崩溃时的崩溃日志；

接收所述服务器根据所述奔溃日志反馈的更新版本的目标组件；

以所述更新版本的目标组件替换所述加载路径中的目标组件。

可选地，所述指定路径包括资源路径和备份路径中的任意一个，所述加载所述加载路径中替换后目标组件之后，所述方法还包括：

当加载所述加载路径的目标组件后，所述程序运行时长到达时长阈值且与所述备份路径中的目标组件的版本不一致时，将所述加载路径的目标组件存储在备份路径中；

所述当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换所述加载路径中的目标组件，包括：

检测所述备份路径中的目标组件的版本是否为所述崩溃文件中记录的版本；

当所述备份路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述备份路径中的目标组件替换所述加载路径中的目标组件；

当所述备份路径中的目标组件的版本是所述崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是所述崩溃文件中记录的版本；

当所述资源路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述资源路径中的目标组件替换所述加载路径中的目标组件。

可选地，所述当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换所述加载路径中的目标组件，包括：

当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是所述崩溃文件中记录的版本；

当所述资源路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述资源路径中的目标组件替换所述加载路径中的目标组件。

可选地，所述方法还包括：

当所述资源路径中的目标组件的版本是所述崩溃文件中记录的版本时，检测服务器是否存在更新的目标组件；

当所述服务器存在更新的目标组件时，以所述更新的目标组件替换所述在目标中的目标组件。

根据本申请的第二方面，提供一种程序修复装置，其特征在于，所述装置包括：

记录模块，用于每当运行的程序的软件开发工具包中目标组件引起所述程序崩溃时，将所述目标组件的版本信息记录在崩溃文件中；

版本检测模块，用于所述程序再次运行时，检测加载路径中的目标组件的版本是否为所述崩溃文件中记录的版本；

替换模块，用于当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换所述加载路径中的目标组件；

加载模块，用于加载所述加载路径中替换后的目标组件。

可选地，所述程序修复装置还包括：

日志发送模块，用于向服务器发送所述目标组件引起所述程序崩溃时的崩溃日志；

组件接收模块，用于接收所述服务器根据所述奔溃日志反馈的更新版本的目标组件；

更新模块，用于以所述更新版本的目标组件替换所述加载路径中的目标组件。

可选地，所述指定路径包括资源路径和备份路径中的任意一个，所述程序修复装置还包括：

备份模块，用于当加载所述历史版本的目标组件后，所述程序运行时长到达时长阈值且与所述备份路径中的目标组件的版本不一致时，将所述加载路径的目标组件存储在备份路径中；

所述替换模块，用于：

检测所述备份路径中的目标组件的版本是否为所述崩溃文件中记录的版本；

当所述备份路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述备份路径中的目标组件替换所述加载路径中的目标组件；

当所述备份路径中的目标组件的版本是所述崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是所述崩溃文件中记录的版本；

当所述资源路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述资源路径中的目标组件替换所述加载路径中的目标组件。

可选地，所述替换模块，用于：

当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是所述崩溃文件中记录的版本；

当所述资源路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述资源路径中的目标组件替换所述加载路径中的目标组件。

可选地，所述程序修复装置还包括：

更新检测模块，用于当所述资源路径中的目标组件的版本是所述崩溃文件中记录的版本时，检测服务器是否存在更新的目标组件；

更新替换模块，用于当所述服务器存在更新的目标组件时，以所述更新的目标组件替换所述在目标中的目标组件。

本申请实施例提供的技术方案带来的有益效果至少包括：

通过每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件，在之后程序运行时，可以检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本，如果是的话可以将指定路径中的历史版本的目标组件替换进加载在目录中，并记载该历史版本的目标组件，以保证程序能够正常运行。如此便有针对性的对程序中引起崩溃的组件进行了热更新，而无需更新整个程序，解决了相关技术中程序修复方法较为复杂，修复效率较低的问题。达到了提高程序修复的效率的效果。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例涉及的一种实施环境的结构示意图；

图2是本申请实施例示出的一种程序修复方法的流程图；

图3是本申请实施例提供的另一种程序修复方法的流程图；

图4是本申请实施例提供的另一种程序修复方法的流程图；

图5是本申请实施例提供的一种程序修复装置的结构框图；

图6是本申请实施例提供的另一种程序修复装置的结构框图；

图7是本申请实施例提供的另一种程序修复装置的结构框图；

图8是本申请实施例提供的一种终端的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

软件开发工具包(Software Development Kit，SDK)是基于安卓(Android)平台的软件开发工具包，为使用方提供相关开发接口。

SDK中可以包括多个组件，每个组件可以用于实现各种的功能，每个组件的表现形式为dex文件。

SDK的版本更新通常比较频繁，且一些SDK(例如定位SDK)是运行在宿主程序(APP)上的，目前，想要更新SDK，通常需要推动宿主APP的升级才能使SDK得到升级。此外，SDK在频繁更新的过程中，难免会遇到由于测试不够充分导致隐藏的未知缺陷，这个缺陷运行在线上时就可能导致整个APP崩溃。

图1是本申请实施例涉及的一种实施环境的结构示意图。该实施环境可以包括服务器11以及终端12。

服务器11可以为一个服务器或服务器集群。

终端12可以为手机、平板电脑、笔记本电脑、智能可穿戴设备等。终端12可以通过有线或无线的方式(图1示出的是以无线的方式进行联系的情况)与服务器连接。

图2是本申请实施例示出的一种程序修复方法的流程图，本实施例以该程序修复方法应用于图1所示实施环境的终端中来举例说明。该程序修复方法可以包括如下几个步骤：

步骤201、每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件中。

步骤202、程序再次运行时，检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本。

步骤203、当加载路径中的目标组件的版本为崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换加载路径中的目标组件。

步骤204、加载加载路径中替换后的目标组件。

综上所述，本申请实施例提供的程序修复方法，通过每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件，在之后程序运行时，可以检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本，如果是的话可以将指定路径中的历史版本的目标组件替换进加载在目录中，并记载该历史版本的目标组件，以保证程序能够正常运行。如此便有针对性的对程序中引起崩溃的组件进行了热更新，而无需更新整个程序，解决了相关技术中程序修复方法较为复杂，修复效率较低的问题。达到了提高程序修复的效率的效果。

图3是本申请实施例提供的另一种程序修复方法的流程图，本实施例以该程序修复方法应用于图1所示实施环境的终端中来举例说明。该程序修复方法可以包括如下几个步骤：

步骤301、在程序运行时，监测程序的软件开发工具包中的组件是否引起崩溃。执行步骤302。

终端可以在程序运行时，监测程序的软件开发工具包中的组件是否引起崩溃。示例性的，一种实现方式中，在SDK运行开始就注册UncaughtExceptionHandler接口(一种常用的接口)，时刻监控SDK的运行是否发生崩溃。由于UncaughtExceptionHandler是监控整个程序的Crash，在SDK以外造成的崩溃和SDK无关，因此可以在SDK编译打包时添加SDK的专属标志。当SDK中的组件引起程序崩溃时，可以根据奔溃日志来确定是否为SDK中的组件引起的崩溃。

步骤302、每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件中。执行步骤303和304。

终端在检测到运行的程序的软件开发工具包中目标组件引起程序崩溃时，可以将目标组件的版本信息记录在崩溃文件中，该崩溃文件可以是一个Sp(SharePreference)文件。Sp文件是Android中存储轻量级的数据，Android系统的四种数据存取方式之一，Sp文件在程序被卸载时才会丢失，可以保存上次程序运行时的数据。

其中，目标组件为SDK中的任意一个组件。

步骤303、向服务器发送目标组件引起程序崩溃时的崩溃日志。

终端在检测到程序崩溃时，可以向服务器发送目标组件引起程序崩溃时的崩溃日志。服务器接收到该崩溃日志时，可以由脚本通知(例如通过邮件通知)相关开发人员，该相关开发人员可以根据该崩溃日志生成能够正常运行的目标组件，并将该目标组件上传至服务器，后续终端可以在服务器中拉取该组件，以完成目标组件的在线修复。

步骤304、程序再次运行时，检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本。当加载路径中的目标组件的版本是崩溃文件中记录的版本时，执行步骤305；当加载路径中的目标组件的版本不是崩溃文件中记录的版本时，执行步骤311。

终端中的上述程序再次运行时，检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本。其中，加载路径(dexPath)为加载组件时的默认路径。终端会在程序开始运行时，加载该路径中的组件。

步骤305、检测备份路径中的目标组件的版本是否为崩溃文件中记录的版本。当备份路径中的目标组件的版本不是崩溃文件中记录的版本时，执行步骤306；当备份路径中的目标组件的版本是崩溃文件中记录的版本时，执行步骤307。

当加载路径中的目标组件的版本是崩溃文件中记录的版本时，终端可以检测备份路径中的目标组件的版本是否为崩溃文件中记录的版本。其中，备份路径(backupPath)中存储有能够正常运行的历史版本的组件。备份路径中组件的获取过程可以参考后续步骤312，在此不再赘述。

步骤306、以备份路径中的目标组件替换加载路径中的目标组件。执行步骤311。

终端可以将备份路径中的目标组件拷贝进加载路径中，并替换加载路径中原有的目标组件。

步骤307、检测资源路径中的目标组件的版本是否是崩溃文件中记录的版本。当资源路径中的目标组件的版本不是崩溃文件中记录的版本时，执行步骤308；当资源路径中的目标组件的版本是崩溃文件中记录的版本时，执行步骤309。

当备份路径中的目标组件的版本是崩溃文件中记录的版本时，终端可以检测资源路径中的目标组件的版本是否是崩溃文件中记录的版本。资源路径(originalPath)中的组件为originalDex，其为SDK包中自带Dex文件，是原始版本，其一般不会引起程序的崩溃。

步骤308、以资源路径中的目标组件替换加载路径中的目标组件。执行步骤311。

当资源路径中的目标组件的版本不是崩溃文件中记录的版本时，终端可以以资源路径中的目标组件替换加载路径中的目标组件。

通过资源路径或备份路径中的目标组件替换加载路径中的目标组件，是一种离线修复的方式。

步骤309、检测服务器是否存在更新的目标组件。执行步骤310。

当资源路径中的目标组件的版本是崩溃文件中记录的版本时，终端可以检测服务器是否存在更新的目标组件。

步骤310、当服务器存在更新的目标组件时，以更新的目标组件替换加载路径中的目标组件。执行步骤311。

当服务器存在更新的目标组件时，终端可以获取该更新的目标组件，并以更新的目标组件替换加载路径中的目标组件。

以服务器中的更新的目标组件来替换加载路径中的目标组件，是一种在线的修复方式。

步骤311、加载加载路径中的目标组件。执行步骤312。

该加载路径中的目标组件可以为以本地的历史版本的目标组件替换后的目标组件，可以为通过服务器获取的更新的目标组件。终端可以加载该加载路径中的目标组件。

本申请实施例中，终端可以以热更新的方式加载目标组件，其可以包括接口服务部分、反射部分以及文件管理部分。其中的接口(Application Programming Interface，API)服务部分是暴露给外部的公共接口，调用方可以通过公共的API发起连续定位、单点定位、移除定位等等，这些的功能的核心实现是封装在组件的dex文件中的文件管理部分；反射部分用于通过反射的方式在运行时将dex加载到内存中，dex文件成功加载到内存后，该加载路径下的dex文件可以被替换。

步骤312、当加载加载路径中的目标组件后，程序运行时长到达时长阈值且与备份路径中的目标组件的版本不一致时，将加载路径的目标组件存储在备份路径中。执行步骤313。

程序运行时长到达时长阈值可以表明当前加载的目标组件能够正常运行，此时如果该目标组件的版本与备份路径中的目标组件的版本不一致时(即该版本的目标组件还未被备份至备份路径中过)，可以将当前加载路径中的目标组件备份至备份路径，并替换备份路径中的目标组件。

步骤313、当服务器存在更新的目标组件时，以更新的目标组件替换加载路径中的目标组件。

在程序后续运行的过程中，终端可以检测服务器是否存在更新的目标组件，当服务器存在更新的目标组件时，以更新的目标组件替换加载路径中的目标组件。

本申请实施例提供的程序修复方法，整个修复过程均在后台完成，用户对此是无感知的，对用户使用正常使用APP不会造成影响，避免了常规修复技术中影响用户使用的问题，进而大大提高了用户体验。

综上所述，本申请实施例提供的程序修复方法，通过每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件，在之后程序运行时，可以检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本，如果是的话可以将指定路径中的历史版本的目标组件替换进加载在目录中，并记载该历史版本的目标组件，以保证程序能够正常运行。如此便有针对性的对程序中引起崩溃的组件进行了热更新，而无需更新整个程序，解决了相关技术中程序修复方法较为复杂，修复效率较低的问题。达到了提高程序修复的效率的效果。

图4是本申请实施例提供的另一种程序修复方法的流程图，本实施例以该程序修复方法应用于图1所示实施环境的终端中来举例说明。该程序修复方法可以包括如下几个步骤：

步骤401、在程序运行时，监测程序的软件开发工具包中的组件是否引起崩溃。执行步骤402。

终端可以在程序运行时，监测程序的软件开发工具包中的组件是否引起崩溃。

步骤402、每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件中。执行步骤403和404。

终端在检测到运行的程序的软件开发工具包中目标组件引起程序崩溃时，可以将目标组件的版本信息记录在崩溃文件中，该崩溃文件可以是一个Sp(SharePreference)文件。Sp文件是Android中存储轻量级的数据，Android系统的四种数据存取方式之一，Sp文件在程序被卸载时才会丢失，可以保存上次程序运行时的数据。

其中，目标组件为SDK中的任意一个组件。

步骤403、向服务器发送目标组件引起程序崩溃时的崩溃日志。

终端在检测到程序崩溃时，可以向服务器发送目标组件引起程序崩溃时的崩溃日志。服务器接收到该崩溃日志时，可以由脚本通知(例如通过邮件通知)相关开发人员，该相关开发人员可以根据该崩溃日志生成能够正常运行的目标组件，并将该目标组件上传至服务器，后续终端可以在服务器中拉取该组件，以完成目标组件的在线修复。

步骤404、程序再次运行时，检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本。当加载路径中的目标组件的版本是崩溃文件中记录的版本时，执行步骤405；当加载路径中的目标组件的版本不是崩溃文件中记录的版本时，执行步骤409。

终端中的上述程序再次运行时，检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本。其中，加载路径(dexPath)为加载组件时的默认路径。终端会在程序开始运行时，加载该路径中的组件。

步骤405、检测资源路径中的目标组件的版本是否是崩溃文件中记录的版本。当资源路径中的目标组件的版本不是崩溃文件中记录的版本时，执行步骤406；当资源路径中的目标组件的版本是崩溃文件中记录的版本时，执行步骤409。

当备份路径中的目标组件的版本是崩溃文件中记录的版本时，终端可以检测资源路径中的目标组件的版本是否是崩溃文件中记录的版本。

步骤406、以资源路径中的目标组件替换加载路径中的目标组件。执行步骤409。

当资源路径中的目标组件的版本不是崩溃文件中记录的版本时，终端可以以资源路径中的目标组件替换加载路径中的目标组件。

虽然资源路径中的目标组件的版本较旧，但此时仅为临时修复，后续还会通过服务器中的更新的目标组件进行在线修复，因而可以先用资源路径中的目标组件尽快恢复程序的正常运行。

步骤407、检测服务器是否存在更新的目标组件。执行步骤310。

当资源路径中的目标组件的版本是崩溃文件中记录的版本时，终端可以检测服务器是否存在更新的目标组件。

步骤408、当服务器存在更新的目标组件时，以更新的目标组件替换加载路径中的目标组件。执行步骤311。

当服务器存在更新的目标组件时，终端可以获取该更新的目标组件，并以更新的目标组件替换加载路径中的目标组件。

步骤409、加载加载路径中的目标组件。执行步骤312。

该加载路径中的目标组件可以为以本地的历史版本的目标组件替换后的目标组件，可以为通过服务器获取的更新的目标组件。终端可以加载该加载路径中的目标组件

程序运行时长到达时长阈值可以表明当前加载的目标组件能够正常运行，此时如果该目标组件的版本与备份路径中的目标组件的版本不一致时(即该版本的目标组件还未被备份至备份路径中过)，可以将当前加载路径中的目标组件备份至备份路径，并替换备份路径中的目标组件。

步骤410、当服务器存在更新的目标组件时，以更新的目标组件替换加载路径中的目标组件。

在程序后续运行的过程中，终端可以检测服务器是否存在更新的目标组件，当服务器存在更新的目标组件时，以更新的目标组件替换加载路径中的目标组件。

综上所述，本申请实施例提供的程序修复方法，通过每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件，在之后程序运行时，可以检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本，如果是的话可以将指定路径中的历史版本的目标组件替换进加载在目录中，并记载该历史版本的目标组件，以保证程序能够正常运行。如此便有针对性的对程序中引起崩溃的组件进行了热更新，而无需更新整个程序，解决了相关技术中程序修复方法较为复杂，修复效率较低的问题。达到了提高程序修复的效率的效果。

图5是本申请实施例提供的一种程序修复装置的结构框图，该程序修复装置包括：

记录模块510，用于每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件中；

版本检测模块520，用于程序再次运行时，检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本；

替换模块530，用于当加载路径中的目标组件的版本为崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换加载路径中的目标组件；

加载模块540，用于加载加载路径中的历史版本的目标组件。

可选地，如图6所示，其为本申请实施例提供的另一种程序修复装置的结构框图，该程序修复装置还包括：

日志发送模块550，用于向服务器发送目标组件引起程序崩溃时的崩溃日志；

组件接收模块560，用于接收服务器根据奔溃日志反馈的更新版本的目标组件；

更新模块570，用于以更新版本的目标组件替换加载路径中的目标组件。

可选地，指定路径包括资源路径和备份路径中的任意一个，程序修复装置还包括：

备份模块580，用于当加载历史版本的目标组件后，程序运行时长到达时长阈值且与备份路径中的目标组件的版本不一致时，将历史版本的目标组件存储在备份路径中；

替换模块，用于：

检测备份路径中的目标组件的版本是否为崩溃文件中记录的版本；

当备份路径中的目标组件的版本不是崩溃文件中记录的版本时，以备份路径中的目标组件替换加载路径中的目标组件；

当备份路径中的目标组件的版本是崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是崩溃文件中记录的版本；

当资源路径中的目标组件的版本不是崩溃文件中记录的版本时，以资源路径中的目标组件替换加载路径中的目标组件。

可选地，替换模块，用于：

当加载路径中的目标组件的版本为崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是崩溃文件中记录的版本；

当资源路径中的目标组件的版本不是崩溃文件中记录的版本时，以资源路径中的目标组件替换加载路径中的目标组件。

可选地，如图7所示，其为本申请实施例提供的另一种程序修复装置的结构框图，该程序修复装置还包括：

更新检测模块590，用于当资源路径中的目标组件的版本是崩溃文件中记录的版本时，检测服务器是否存在更新的目标组件；

更新替换模块591，用于当服务器存在更新的目标组件时，以更新的目标组件替换在目标中的目标组件。

综上所述，本申请实施例提供的程序修复装置，通过每当运行的程序的软件开发工具包中目标组件引起程序崩溃时，将目标组件的版本信息记录在崩溃文件，在之后程序运行时，可以检测加载路径中的目标组件的版本是否为崩溃文件中记录的版本，如果是的话可以将指定路径中的历史版本的目标组件替换进加载在目录中，并记载该历史版本的目标组件，以保证程序能够正常运行。如此便有针对性的对程序中引起崩溃的组件进行了热更新，而无需更新整个程序，解决了相关技术中程序修复方法较为复杂，修复效率较低的问题。达到了提高程序修复的效率的效果。

图8是本申请实施例提供的一种终端的结构示意图。该终端备800可以是：笔记本电脑或台式电脑。终端800还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。或者，该终端800还可以为服务器。

通常，终端800包括有：处理器801和存储器802。

处理器801可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器801可以采用数字信号处理(digital signal processing，DSP)、现场可编程门阵列(field-programmable gate array，FPGA)或者可编程逻辑阵列(programmable logicarray，PLA)中的至少一种硬件形式来实现。处理器801也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称中央处理器(centralprocessing unit，CPU)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器801可以在集成有图像处理器(graphics processing unit，GPU)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器801还可以包括人工智能(artificial intelligence，AI)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器802可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器802还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器802中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器801所执行以实现本申请中方法实施例提供的程序修复方法。

在一些实施例中，终端800还可选包括有：外围设备接口803和至少一个外围设备。处理器801、存储器802和外围设备接口803之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口803相连。具体地，外围设备包括：射频电路804、触摸显示屏805、摄像头806、音频电路807、定位组件808或电源809中的至少一种。

外围设备接口803可被用于将输入/输出(input/output，I/O)相关的至少一个外围设备连接到处理器801和存储器802。在一些实施例中，处理器801、存储器802和外围设备接口803被集成在同一芯片或电路板上；在一些其他实施例中，处理器801、存储器802和外围设备接口803中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路804用于接收和发射射频(radio frequency，RF)信号，也称电磁信号。射频电路804通过电磁信号与通信网络以及其他通信设备进行通信。射频电路804将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路804包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路804可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或无线保真(wireless fidelity，WiFi)网络。在一些实施例中，射频电路804还可以包括近距离无线通信(near field communication，NFC)有关的电路，本申请对此不加以限定。

显示屏805用于显示用户界面(user interface，UI)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏805是触摸显示屏时，显示屏805还具有采集在显示屏805的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器801进行处理。此时，显示屏805还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏805可以为一个，设置终端800的前面板；在另一些实施例中，显示屏805可以为至少两个，分别设置在终端800的不同表面或呈折叠设计；在再一些实施例中，显示屏805可以是柔性显示屏，设置在终端800的弯曲表面上或折叠面上。甚至，显示屏805还可以设置成非矩形的不规则图形，也即异形屏。显示屏805可以采用液晶显示屏(liquid crystal display，LCD)、有机发光二极管(organic light-emitting diode，OLED)等材质制备。

摄像头组件806用于采集图像或视频。可选地，摄像头组件806包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及虚拟现实(virtual reality，VR)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件806还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路807可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器801进行处理，或者输入至射频电路804以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端800的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器801或射频电路804的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路807还可以包括耳机插孔。

定位组件808用于定位终端800的当前地理位置，以实现导航或基于位置的服务(location based service，LBS)。定位组件808可以是基于美国的全球定位系统(globalpositioning system，GPS)、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源809用于为终端800中的各个组件进行供电。电源809可以是交流电、直流电、一次性电池或可充电电池。当电源809包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端800还包括有一个或多个传感器410。该一个或多个传感器410包括但不限于：加速度传感器411、陀螺仪传感器412、压力传感器413、指纹传感器414、光学传感器415以及接近传感器416。

加速度传感器411可以检测以终端800建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器411可以用于检测重力加速度在三个坐标轴上的分量。处理器801可以根据加速度传感器411采集的重力加速度信号，控制触摸显示屏805以横向视图或纵向视图进行用户界面的显示。加速度传感器411还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器412可以检测终端800的机体方向及转动角度，陀螺仪传感器412可以与加速度传感器411协同采集用户对终端800的3D动作。处理器801根据陀螺仪传感器412采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器413可以设置在终端800的侧边框和/或触摸显示屏805的下层。当压力传感器413设置在终端800的侧边框时，可以检测用户对终端800的握持信号，由处理器801根据压力传感器413采集的握持信号进行左右手识别或快捷操作。当压力传感器413设置在触摸显示屏805的下层时，由处理器801根据用户对触摸显示屏805的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件或菜单控件中的至少一种。

指纹传感器414用于采集用户的指纹，由处理器801根据指纹传感器414采集到的指纹识别用户的身份，或者，由指纹传感器414根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器801授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器414可以被设置终端800的正面、背面或侧面。当终端800上设置有物理按键或厂商Logo时，指纹传感器414可以与物理按键或厂商Logo集成在一起。

光学传感器415用于采集环境光强度。在一个实施例中，处理器801可以根据光学传感器415采集的环境光强度，控制触摸显示屏805的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏805的显示亮度；当环境光强度较低时，调低触摸显示屏805的显示亮度。在另一个实施例中，处理器801还可以根据光学传感器415采集的环境光强度，动态调整摄像头组件806的拍摄参数。

接近传感器416，也称距离传感器，通常设置在终端800的前面板。接近传感器416用于采集用户与终端800的正面之间的距离。在一个实施例中，当接近传感器416检测到用户与终端800的正面之间的距离逐渐变小时，由处理器801控制触摸显示屏805从亮屏状态切换为息屏状态；当接近传感器416检测到用户与终端800的正面之间的距离逐渐变大时，由处理器801控制触摸显示屏805从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图7中示出的结构并不构成对终端800的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

本申请实施例还提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，该至少一条指令、该至少一段程序、该代码集或指令集由处理器加载并执行以实现如上述方法实施例所提供的程序修复方法。

在本申请中，术语“第一”和“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性。术语“多个”指两个或两个以上，除非另有明确的限定。

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

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

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种程序修复方法，其特征在于，所述方法包括：

每当运行的程序的软件开发工具包中目标组件引起所述程序崩溃时，将所述目标组件的版本信息记录在崩溃文件中；

所述程序再次运行时，检测加载路径中的目标组件的版本是否为所述崩溃文件中记录的版本；

当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换所述加载路径中的目标组件；

加载所述加载路径中替换后的目标组件。

2.根据权利要求1所述的方法，其特征在于，所述每当运行的程序中的目标组件引起所述程序的崩溃时，记录所述目标组件的奔溃版本的信息之后，所述方法还包括：

向服务器发送所述目标组件引起所述程序崩溃时的崩溃日志；

接收所述服务器根据所述奔溃日志反馈的更新版本的目标组件；

以所述更新版本的目标组件替换所述加载路径中的目标组件。

3.根据权利要求1所述的方法，其特征在于，所述指定路径包括资源路径和备份路径中的任意一个，所述加载所述加载路径中替换后的目标组件之后，所述方法还包括：

当加载所述加载路径中的目标组件后，所述程序运行时长到达时长阈值且与所述备份路径中的目标组件的版本不一致时，将所述加载路径的目标组件存储在备份路径中；

所述当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换所述加载路径中的目标组件，包括：

检测所述备份路径中的目标组件的版本是否为所述崩溃文件中记录的版本；

当所述备份路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述备份路径中的目标组件替换所述加载路径中的目标组件；

当所述备份路径中的目标组件的版本是所述崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是所述崩溃文件中记录的版本；

当所述资源路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述资源路径中的目标组件替换所述加载路径中的目标组件。

4.根据权利要求1所述的方法，其特征在于，所述当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换所述加载路径中的目标组件，包括：

当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是所述崩溃文件中记录的版本；

当所述资源路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述资源路径中的目标组件替换所述加载路径中的目标组件。

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

当所述资源路径中的目标组件的版本是所述崩溃文件中记录的版本时，检测服务器是否存在更新的目标组件；

当所述服务器存在更新的目标组件时，以所述更新的目标组件替换所述在目标中的目标组件。

6.一种程序修复装置，其特征在于，所述装置包括：

记录模块，用于每当运行的程序的软件开发工具包中目标组件引起所述程序崩溃时，将所述目标组件的版本信息记录在崩溃文件中；

版本检测模块，用于所述程序再次运行时，检测加载路径中的目标组件的版本是否为所述崩溃文件中记录的版本；

替换模块，用于当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，以指定路径中的历史版本的目标组件替换所述加载路径中的目标组件；

加载模块，用于加载所述加载路径中替换后的目标组件。

7.根据权利要求6所述的程序修复装置，其特征在于，所述程序修复装置还包括：

日志发送模块，用于向服务器发送所述目标组件引起所述程序崩溃时的崩溃日志；

组件接收模块，用于接收所述服务器根据所述奔溃日志反馈的更新版本的目标组件；

更新模块，用于以所述更新版本的目标组件替换所述加载路径中的目标组件。

8.根据权利要求6所述的程序修复装置，其特征在于，所述指定路径包括资源路径和备份路径中的任意一个，所述程序修复装置还包括：

备份模块，用于当加载所述加载路径中的目标组件后，所述程序运行时长到达时长阈值且与所述备份路径中的目标组件的版本不一致时，将所述加载路径的目标组件存储在备份路径中；

所述替换模块，用于：

检测所述备份路径中的目标组件的版本是否为所述崩溃文件中记录的版本；

当所述备份路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述备份路径中的目标组件替换所述加载路径中的目标组件；

当所述备份路径中的目标组件的版本是所述崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是所述崩溃文件中记录的版本；

当所述资源路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述资源路径中的目标组件替换所述加载路径中的目标组件。

9.根据权利要求6所述的程序修复装置，其特征在于，所述替换模块，用于：

当所述加载路径中的目标组件的版本为所述崩溃文件中记录的版本时，检测资源路径中的目标组件的版本是否是所述崩溃文件中记录的版本；

当所述资源路径中的目标组件的版本不是所述崩溃文件中记录的版本时，以所述资源路径中的目标组件替换所述加载路径中的目标组件。

10.根据权利要求8或9所述的程序修复装置，其特征在于，所述程序修复装置还包括：

更新检测模块，用于当所述资源路径中的目标组件的版本是所述崩溃文件中记录的版本时，检测服务器是否存在更新的目标组件；

更新替换模块，用于当所述服务器存在更新的目标组件时，以所述更新的目标组件替换所述在目标中的目标组件。