一种硬件组件的修复方法、装置、系统和存储介质与流程

本发明涉及信息技术领域，具体涉及一种硬件组件的修复方法、装置、系统和存储介质。

背景技术：

随着信息技术的发展，各类设备的使用越来越普及，而由于设备的硬件组件(即硬件中软件层的应用)迭代往往不及纯软件使用频繁，因此，设备的硬件组件每一次新版本的发布，都需要经过十分严谨的测试，并下发给设备进行修复，以解决设备的硬件组件的缺陷(即bug)，避免硬件出现严重问题，甚至是被毁灭。

现有技术中，针对设备的硬件组件出现bug的修复方案中，例如，当的硬件组件的软件开发工具包(softwaredevelopmentkit，sdk)出现bug时，应用提供商需要将bug发给硬件厂商，并与硬件厂商进行沟通及修改，在硬件厂商修改并测试完成，并生成新版本的sdk后，一般是基于空中下载技术(over-the-airtechnology，ota)升级的解决方案对设备进行修复，该ota升级方案中，当设备的硬件组件有新版本的sdk发布时，服务器后台通过长链接通道下发最新版本的sdk安装包(androidpackage，apk)给设备，设备接收到新版本的sdk安装包后，会根据新版本的sdk安装包进行强制安装，并通过安装后的新版本的sdk覆盖当前版本的sdk，以对设备的硬件组件进行修复。

由于该方案中在应用提供商需与硬件厂商沟通并完成测试后，需要服务器下发sdk安装包给设备，设备强制升级应用的sdk版本，此时需要消耗设备较大的流量资源，使得sdk安装包下载或安装失的概率非常大，可能导致设备无法及时通过ota更新到新的版本，无法修复硬件组件的bug而无法使用，因此硬件组件的修复非常不便捷；并且，设备需要重新安装sdk，会使得设备在使用过程中产生极为严重的影响，降低了设备进行修复的可靠性。

技术实现要素：

本发明实施例提供一种硬件组件的修复方法、装置、系统及和存储介质，旨在提高设备对硬件组件进行修复的可靠性及便捷性。

为解决上述技术问题，本发明实施例提供以下技术方案：

一种硬件组件的修复方法，包括：

获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；

根据所述关键路径及所述sdk创建所述硬件组件对应的代理应用类；

当接收到服务器发送的关于所述硬件组件的补丁包时，调用所述代理应用类；

基于所述代理应用类，利用所述补丁包对所述sdk进行更新，以对所述硬件组件进行修复。

一种硬件组件的修复装置，包括：

获取单元，用于获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；

创建单元，用于根据所述关键路径及所述sdk创建所述硬件组件对应的代理应用类；

调用单元，用于当接收到服务器发送的关于所述硬件组件的补丁包时，调用所述代理应用类；

修复单元，用于基于所述代理应用类，利用所述补丁包对所述sdk进行更新，以对所述硬件组件进行修复。

一种硬件组件的修复系统，所述硬件组件的修复系统包括服务器和设备，所述设备包括上述的硬件组件的修复装置，其中，

所述服务器，用于接收客户端上传的关于设备的硬件组件的sdk修改版本，以及获取所述设备的硬件组件对应的sdk当前版本；根据所述sdk修改版本及sdk当前版本生成关于所述设备的硬件组件的补丁包；将所述补丁包发送给所述设备。。

一种存储介质，所述存储介质存储有多条指令，所述指令适于处理器进行加载，以执行上述的硬件组件的修复方法中的步骤。

本发明实施例通过获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；然后，根据关键路径及sdk创建硬件组件对应的代理应用类；当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类；基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。该方案中由于该代理应用类集成了硬件组件的关键路径及sdk功能等，因此，可以通过该代理应用，根据接收到的补丁包对设备的硬件组件进行修复，而无需通过安装包对sdk进行升级，提高了设备对硬件组件进行修复的可靠性及便捷性。

附图说明

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

图1是本发明实施例提供的硬件组件的修复系统的场景示意图；

图2是本发明实施例提供的硬件组件的修复方法的流程示意图；

图3是本发明实施例提供的硬件组件的修复方法的另一流程示意图；

图4是本发明实施例提供的硬件组件的修复方法的另一流程示意图；

图5是本发明实施例提供的硬件组件的修复装置的结构示意图；

图6是本发明实施例提供的硬件组件的修复装置的另一结构示意图；

图7是本发明实施例提供的硬件组件的修复装置的另一结构示意图；

图8是本发明实施例提供的硬件组件的修复装置的另一结构示意图；

图9是本发明实施例提供的设备的结构示意图；

图10是本发明实施例提供的服务器的结构示意图。

具体实施方式

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

在以下的说明中，本发明的具体实施例将参考由一部或多部计算机所执行的步骤及符号来说明，除非另有述明。因此，这些步骤及操作将有数次提到由计算机执行，本文所指的计算机执行包括了由代表了以一结构化形式中的数据的电子信号的计算机处理单元的操作。此操作转换该数据或将其维持在该计算机的内存系统中的位置处，其可重新配置或另外以本领域测试人员所熟知的方式来改变该计算机的运作。该数据所维持的数据结构为该内存的实体位置，其具有由该数据格式所定义的特定特性。但是，本发明原理以上述文字来说明，其并不代表为一种限制，本领域测试人员将可了解到以下所述的多种步骤及操作亦可实施在硬件当中。

本发明实施例提供一种硬件组件的修复方法、装置、系统和存储介质。

请参阅图1，图1为本发明实施例所提供的硬件组件的修复系统的场景示意图，该硬件组件的修复系统可以包括硬件组件的修复装置，该硬件组件的修复装置具体可以集成在机器人、电脑、及电视等具备储存单元并安装有微处理器而具有运算能力的设备中，主要用于获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk，其中，该硬件组件可以是设备中硬件的软件层上的应用(即application)，硬件组件的关键路径可以包括设备中关键场景的sdk的调用路径，例如，设备连接网络、设备的电量过低、设备音量变大或会变小等场景的sdk的调用路径。然后，根据关键路径及sdk创建硬件组件对应的代理应用类，即将硬件组件的关键路径迁移至代理应用类，以及将sdk的功能集成在代理应用类中等。当硬件组件出现bug等需要修复的情况时，服务器将会生成关于硬件组件的补丁包，并将该补丁包发送给设备；当接收到服务器发送的关于硬件组件的补丁包时，设备调用代理应用类；基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复；等等。

例如，以硬件组件的修复装置集成在机器人中为例，该机器人可以包括音箱及显示器等，该机器人的硬件组件中设置有sdk，其中，机器人可以获取自身硬件组件(即机器人中硬件的软件层上的应用)的关键路径，以及加载软件开发工具包sdk，其中，关键路径可以是机器人连接网络控制路径、机器人电量调节路径、机器人中音箱的音量调节路径等场景的sdk的调用路径。然后，机器人根据关键路径及sdk创建硬件组件对应的代理应用类，使得硬件组件的关键路径及sdk的功能集成在该代理应用类中。当机器人的硬件组件出现bug时，若机器人接收到服务器发送的关于硬件组件的补丁包，则调用代理应用类；基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。

此外，硬件组件的修复系统还可以包括服务器，该服务器可以包括数据库，该数据库可以用于存储设备的状态信息、及不同版本的sdk等，该服务器主要用于，接收设备上报的状态信息，并对该状态信息进行监测，此时可以将设备的状态信息存储至数据库，其中，该状态信息可以包括设备标识、设备版本号、设备当前的sdk版本号、设备的连网状态、及设备的内存运行状态等信息。当监测到设备的硬件组件存在异常时，输出关于设备的硬件组件的异常提示信息，接收客户端基于异常提示信息上传的sdk修改版本(可以理解的是，服务器也可以是接收客户端主动上传的sdk修改版本)，该客户端可以是开发人员用于编译sdk代码的客户端，可以根据sdk代码生成sdk修改版本。然后，服务器从设备的状态信息中获取设备当前的sdk版本号，从存储sdk的数据库中获取与该sdk版本对应的sdk当前版本。其次，服务器根据sdk当前版本与sdk修改版本获取关于设备的硬件组件的补丁包，例如，服务器可以是通过差异算法(即diff算法)获取sdk当前版本的执行程序文件(即dex文件)及sdk更新版本的执行程序文件，将sdk当前版本的执行程序文件与sdk修改版本的执行程序文件进行对比，得到sdk当前版本的执行程序文件与sdk修改版本的执行程序文件之间的差异信息，以及该差异信息在sdk当前版本的执行程序文件中的偏移信息，根据差异信息及偏移信息生成补丁包，最后将补丁包发送给设备。

需要说明的是，图1所示的硬件组件的修复系统的场景示意图仅仅是一个示例，本发明实施例描述的硬件组件的修复系统以及场景是为了更加清楚的说明本发明实施例的技术方案，并不构成对于本发明实施例提供的技术方案的限定，本领域普通技术人员可知，随着硬件组件的修复系统的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。

以下分别进行详细说明。

在本实施例中，将从硬件组件的修复装置的角度进行描述，该硬件组件的修复装置具体可以集成在机器人、电脑、及电视等具备储存单元并安装有微处理器而具有运算能力的设备中。

一种硬件组件的修复方法，包括：获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；根据关键路径及sdk创建硬件组件对应的代理应用类；当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类；基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。

请参阅图2，图2是本发明一实施例提供的硬件组件的修复方法的流程示意图。该硬件组件的修复方法可以包括：

在步骤s101中，获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk。

本发明实施例中，硬件组件的修复装置对硬件组件进行修复时，可以是对硬件组件进行热修复，该热修复在用户无感知情况下硬件组件使用补丁进行紧急修复，例如，可以是通过修复硬件组件漏洞的一些代码生成补丁包，根据补丁包对硬件组件进行的修复，该热修复是一种快速及低成本修复硬件组件bug的修复方式。此时，不用重新下载一个新的安装包，而是直接下载一个补丁包，通过补丁包来替换一些出现bug的类，由于下载补丁包的过程用户一般是感觉不到的，因此可以在用户无感知情况下直接修复硬件组件的bug。

以下将以硬件组件的修复装置对硬件组件进行热修复为例进行详细说明。

其中，硬件组件可以是硬件的应用，即设备中硬件的软件层上的应用(即application)；硬件组件的关键路径可以包括设备中关键场景的sdk的调用路径，例如，设备连接网络、设备的电量过低、设备音量变大或会变小等场景的sdk的调用路径。硬件组件的修复装置在创建代理应用之前，需要获取设备中硬件组件的关键路径，以及加载sdk，对sdk执行初始化等操作。

在步骤s102中，根据关键路径及sdk创建硬件组件对应的代理应用类。

硬件组件的修复装置在得到硬件组件的关键路径及加载sdk后，可以根据该关键路径及sdk创建硬件组件对应的代理应用类(即application代理类)，即将硬件组件的关键路径迁移至代理应用类，以及将sdk的接口及功能等集成在代理应用类中等。其中，该代理应用类可以包括实例，该实例可以是设备系统为应用的每个进程创建的应用实例，可以通过该实例来进行数据传递、数据共享、及数据缓存等操作。

在创建得到的代理应用类后，硬件组件的修复装置在运行时可以动态加载代理应用类，以及可以通过代理应用类对sdk进行初始化及更新等一系列操作，该代理应用类还可以实现硬件组件的所有功能。

在某些实施方式中，硬件组件的修复装置根据关键路径及sdk创建硬件组件对应的代理应用类的步骤之后，硬件组件的修复方法还可以包括：

当设备的电量低于预设电量阈值时，调用代理应用类，以及通过代理应用类调用硬件组件的关键路径中的电量调节路径；通过电量调节路径释放预设内存。

具体地，由于代理应用类中集成了硬件组件的关键路径及sdk的功能等，因此，当设备的电量低于预设电量阈值时，说明设备的电量过低，此时硬件组件的修复装置针对电量过低的信息，对设备的运行状态进行相应的调度。

例如，为了延长设备的使用时间，硬件组件的修复装置可以调用代理应用类，通过代理应用类调用硬件组件的关键路径中的电量调节路径，通过电量调节路径释放设备的预设内存，以减少单位时间内设备电量的消耗。

需要说明的是，还可以通过电量调节路径调小设备中音响的音量、或关闭设备的显示屏的显示等，来达到减少单位时间内设备电量的消耗的目的。其中，预设电量阈值及预设内存可以根据实际情况进行灵活设置，具体内容在此处不作限定。

可以理解的是，还可以调用代理应用类来执行其他的功能，例如，当设备需要连接网络时，可以通过代理应用类调用硬件组件的关键路径中的网络连接路径，并通过该网络连接路径执行连网操作；当设备需要将设备的音量调大时，可以通过代理应用类调用硬件组件的关键路径中的音量调节路径，并通过该音量调节路径将设备的音量调大，等等。

在步骤s103中，当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类。

硬件组件的修复装置可以是主动向服务器发送补丁包获取请求，然后接收服务器基于补丁包获取请求发送的关于硬件组件的补丁包，以便根据补丁包对硬件组件进行修复。当然，硬件组件的修复装置也可以是被动接收服务器发送的关于硬件组件的补丁包，以便根据补丁包对硬件组件进行修复，此时服务器可以是每隔预设时间向硬件组件的修复装置发送补丁包，也可以是在每次生成补丁包后向硬件组件的修复装置发送该补丁包。

服务器在向硬件组件的修复装置发送补丁包之前，可选地，服务器接收客户端上传的关于设备的硬件组件的sdk修改版本，以及获取设备的硬件组件对应的sdk当前版本；根据sdk修改版本及sdk当前版本生成关于设备的硬件组件的补丁包；然后将该补丁包发送给硬件组件的修复装置。

其中，该客户端可以是开发人员用于编译sdk代码的客户端，该客户端可以根据编译的sdk代码生成sdk修改版本。

可选地，服务器接收客户端上传的关于设备的硬件组件的sdk修改版本的步骤可以包括：服务器接收设备上报的状态信息，并对该状态信息进行监测；当监测到设备的硬件组件存在异常时，输出关于设备的硬件组件的异常提示信息，接收客户端基于异常提示信息上传的sdk修改版本。当然，客户端也可以是根据实际需要向服务器上传的sdk修改版本。

其中，该状态信息可以包括设备标识、设备版本号、设备当前的sdk版本号、设备的连网状态、设备的硬件组件状态及设备的内存运行状态等信息。

可选地，服务器获取设备的硬件组件对应的sdk当前版本的步骤可以包括：服务器从设备上报的状态信息中或与设备的交互信息中获取设备标识，根据设备标识获取设备的硬件组件当前的sdk版本号，从存储sdk版本的数据库中，获取与该sdk版本号对应的sdk当前版本。

可选地，服务器根据sdk修改版本及sdk当前版本生成关于设备的硬件组件的补丁包的步骤可以包括：服务器获取sdk当前版本的执行程序文件与sdk修改版本的执行程序文件，将sdk当前版本的执行程序文件与sdk修改版本的执行程序文件进行对比，得到sdk当前版本的执行程序文件与sdk修改版本的执行程序文件之间的差异信息，以及该差异信息在sdk当前版本的执行程序文件中的偏移信息；然后根据差异信息及偏移信息生成关于设备的硬件组件的补丁包。

其中，执行程序文件即为dex(dex的英文全称为：dalvikvmexecutes，即androiddalvik执行程序)文件，该dex文件包含了硬件组件用到的所有操作指令和运行时数据等，在程序编译过程中，java源文件先被编译成class文件，然后通过dx工具将多个class文件整合为一个或多个dex文件，这样的文件结构使得各个类能够共享数据，充分减少了存储空间，提升了运行效率。

可选地，服务器将补丁包发送给硬件组件的修复装置的步骤可以包括：服务器从设备上报的状态信息中或与设备的交互信息中获取设备标识，其中，该设备标识即为硬件组件的修复装置所在设备的设备标识，此时可以根据设备标识将补丁包发送给硬件组件的修复装置(即将根据设备标识将补丁包发送给设备)。

或者是，服务器获取从设备上报的状态信息中或与设备的交互信息中获取设备标识，根据设备标识获取设备的硬件组件当前的sdk版本号，然后，从存储所有设备标识的数据库中获取使用该sdk版本号的目标设备标识(上述设备标识包含于目标设备标识)，最后将补丁包发送给与目标设备标识对应的目标设备(上述设备包含于目标设备)。

其中，目标设备标识可以包括一个或多个设备标识，目标设备可以包括一个或多个设备。设备标识可以是用于标志设备唯一性的标号，例如，可以由长度为16位的字符串构成，使得服务器可以根据设备唯一的设备标识，向设备下发补丁包，以便设备根据补丁包对硬件组件进行热修复。

在某些实施方式中，当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类的步骤可以包括：

当接收到服务器发送的补丁包时，判断接收到的补丁包是否完整；若是，则调用代理应用类；若否，则从服务器重新下载关于硬件组件的补丁包，在下载到完整的补丁包后，调用代理应用类。

具体地，在接收到补丁包后，硬件组件的修复装置首先判断接收到的补丁包是否完整，例如，硬件组件的修复装置可以通过检测补丁包接收的过程中是否出现数据传输中断，若出现数据传输中断，则确定接收到的补丁包不完整；若未出现数据传输中断，则确定接收到的补丁包完整。或者是，通过其他方式判断接收到的补丁包是否完整，具体内容在此处不作限定。

当接收到的补丁包为完整时，硬件组件的修复装置可以调用代理应用类，通过代理应用类对硬件组件进行热修复。

当接收到的补丁包不完整时，硬件组件的修复装置可以获取关于硬件组件的补丁包的标识，并向服务器发送与该标识对应的补丁包获取请求，接收服务器基于补丁包获取请求重新发送的补丁包，从而可以从服务器重新下载与补丁包的标识对应的补丁包。在下载到完整的补丁包后，硬件组件的修复装置可以调用代理应用类，以通过代理应用类对硬件组件进行热修复。

或者是，当接收到的补丁包不完整时，硬件组件的修复装置可以向服务器发送补丁包接收失败的信息，以使得服务器基于接收到的信息重新向硬件组件的修复装置发送关于硬件组件的补丁包，从而可以从服务器重新下载与补丁包的标识对应的补丁包。在下载到完整的补丁包后，硬件组件的修复装置可以调用代理应用类，以通过代理应用类对硬件组件进行热修复。

可选地，硬件组件的修复装置从服务器重新下载关于硬件组件的补丁包的步骤可以包括：

判断当前的下载次数是否达到预设次数；若是，则结束对关于硬件组件的补丁包执行的重新下载操作；若否，则从服务器重新下载关于硬件组件的补丁包。其中，预设次数可以根据实际情况进行灵活设置，具体取值在此处不作限定。

可选地，硬件组件的修复装置从服务器重新下载关于硬件组件的补丁包的步骤可以包括：

获取当前时间戳与首次未接收到完整的补丁包的时间戳之间的时间间隔；判断时间间隔是否大于预设时间间隔；若是，则结束对关于硬件组件的补丁包执行的重新下载操作；若否，则从服务器重新下载关于硬件组件的补丁包。其中，预设时间间隔可以根据实际情况进行灵活设置，具体取值在此处不作限定。

在步骤s104中，基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。

硬件组件的修复装置在调用代理应用类后，可以基于代理应用类，利用接收到的关于硬件组件的补丁包对sdk进行更新，以实现对硬件组件进行修复，即以实现对硬件组件进行热修复。其中，热修复可以通过补丁包对硬件组件进行修复，该热修复的过程是一种在用户无感知的情况下修复硬件组件存在的bug的过程。并且，避免了通过ota更新安装包的方式来修复bug，使得每次修复只需要接收服务器下发的补丁包包即可，极大程度缓解了服务器与设备之间的通道资源占用大的问题。

在某些实施方式中，硬件组件的修复装置基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复的步骤可以包括：

(1)通过代理应用类获取sdk当前版本，以及通过代理应用类调用sdk的修复接口；

(2)通过修复接口，根据补丁包更新sdk当前版本，得到sdk更新版本；

(3)通过代理应用类加载sdk更新版本，以对硬件组件进行修复。

硬件组件的修复装置在调用代理应用后，可以通过代理应用对硬件组件进行热修复，具体地，硬件组件的修复装置首先通过代理应用类获取设备中当前使用的sdk版本号，并获取与sdk版本号对应的sdk当前版本。由于代理应用类集成了sdk的所有接口，因此可以通过代理应用类调用sdk的修复接口，然后，通过sdk的修复接口，根据接收到的关于硬件组件的补丁包更新sdk当前版本，得到sdk更新版本。最后，通过代理应用类加载sdk更新版本，以对硬件组件进行热修复。

需要说明的是，现有技术中，硬件组件的sdk需要对外开放给各个硬件厂商进行接入的接口，因而硬件组件的实现控制是在各个硬件厂商侧，导致sdk的调用范围对于应用提供商侧的sdk开发人员是不可控的。而本发明实施例中，通过创建代理应用，可以将硬件组件的sdk的关键路径从硬件厂商侧收归回sdk对应的应用提供商持有，保证sdk的调用范围对于应用提供商侧的sdk开发人员是可控的，应用提供商侧的sdk开发人员可以直接编译sdk代码生成sdk修改版本，而无需与硬件厂商沟通，可以在出现紧急bug时，避免与硬件厂商进行沟通，更不需要硬件厂商参与修改及测试，提高了sdk的更新效率，即提高了硬件组件的热修复效率及热修复范围。

可选地，硬件组件的修复装置通过修复接口，根据补丁包更新sdk当前版本，得到sdk更新版本的步骤可以包括：

通过修复接口，获取补丁包中的偏移信息及差异信息，以及获取sdk当前版本的执行程序文件；根据偏移信息确定在执行程序文件中待更新的位置；将差异信息替换待更新的位置对应的内容，得到sdk更新版本。

具体地，硬件组件的修复装置可以通过调用修复接口对sdk进行更新，首先，从补丁包中提取偏移信息及差异信息等，以及取设备的硬件组件当前的sdk版本号，根据sdk版本号获取sdk当前版本，并获取该sdk当前版本的执行程序文件。其中，差异信息可以是得到sdk当前版本的执行程序文件与sdk修改版本的执行程序文件之间的差异信息，偏移信息可以是差异信息在sdk当前版本的执行程序文件中的偏移信息。

需要说明的是，偏移信息与差异信息之间存在对应关系，偏移信息与差异信息可以是一个或多个，即补丁包中可以是包括一个偏移信息与一个差异信息之间的对应关系，也可以包括多个偏移信息分别与多个差异信息之间的对应关系。

然后，硬件组件的修复装置根据偏移信息确定在sdk当前版本的执行程序文件中待更新的位置，将差异信息替换待更新的位置对应的内容，得到sdk更新版本。例如，当偏移信息a为在sdk当前版本的执行程序文件中的第100行，且偏移信息a对应差异信息a时，硬件组件的修复装置将sdk当前版本的执行程序文件中的第100行的内容替换为差异信息a。使得硬件组件的修复装置可以通过补丁包合成sdk更新版本的方式修复硬件组件的bug，用户无感知修复过程，提升了用户体验。

在某些实施方式中，将差异信息替换待更新的位置对应的内容时，该硬件组件的修复方法还包括：

若未能成功将差异信息替换待更新的位置对应的内容，则将当前的sdk恢复至sdk当前版本，生成硬件组件的修复状态，并将修复状态上报至服务器。

具体地，硬件组件的修复装置在将差异信息替换待更新的位置对应的内容的过程中，判断是否能成功将差异信息替换待更新的位置对应的内容。若能成功将差异信息替换待更新的位置对应的内容，则可以得到sdk更新版本。若未能成功将差异信息替换待更新的位置对应的内容，则说明补丁包中包含的差异信息及偏移信息等信息可能存在异常，无法正常进行修复，即热修复失败，此时，为了保持当前的sdk与接收到补丁包之前的状态一致，可以将当前的sdk恢复至sdk当前版本。

当未能成功将差异信息替换待更新的位置对应的内容时，硬件组件的修复装置还可以生成硬件组件的修复状态，并将修复状态上报至服务器，其中，修复状态可以是sdk当前的更新状态，例如可以是sdk修复失败的状态。以便sdk开发人员从服务器获取硬件组件的修复状态，进一步确定修复失败的原因，并采取下一步修改策略。

由上可知，本发明实施例通过获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；然后，根据关键路径及sdk创建硬件组件对应的代理应用类；当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类；基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。该方案中由于该代理应用类集成了硬件组件的关键路径及sdk的功能等，因此，可以通过该代理应用类，根据接收到的补丁包对设备的硬件组件进行修复，而无需通过安装包对sdk进行升级，节省了设备的流量资源，以及提高了设备对硬件组件进行修复的可靠性及便捷性。

根据上述实施例所描述的方法，以下将举例作进一步详细说明。

上述设备以机器人为例，上述硬件组件的修复装置具体可以集成在该机器人，该机器人可以包括音箱及显示器等，机器人的硬件组件中设置有sdk，机器人可以通过sdk及硬件组件的关键路径等创建代理应用类，并在接收到服务器发送的关于硬件组件的补丁包时，可以通过代理应用利用补丁包对sdk进行更新，以对硬件组件进行热修复。

请参阅图3，图3为本发明实施例提供的硬件组件的修复方法的另一流程示意图。该方法流程可以包括：

s201、机器人获取硬件组件的关键路径，以及加载软件开发工具包sdk。

其中，机器人的硬件组件为机器人中硬件的软件层上的应用，例如，机器人的音箱硬件的软件层上的应用。硬件组件的关键路径可以包括机器人中关键场景的sdk的调用路径，例如，机器人连接网络、机器人的电量过低、机器人的音箱的音量变大或会变小等场景的sdk的调用路径。机器人在创建代理应用之前，需要获取硬件组件的关键路径以及加载sdk。

s202、机器人根据关键路径及sdk创建硬件组件对应的代理应用类。

机器人在得到硬件组件的关键路径及加载sdk后，可以根据硬件组件的关键路径及sdk创建硬件组件对应的代理应用类，从而可以将硬件组件的关键路径迁移至代理应用类，以及将sdk的接口及功能等集成在代理应用类中。

在创建得到的代理应用类后，机器人在运行时可以动态加载代理应用类，通过代理应用类对sdk进行初始化及更新等，还可以通过代理应用类执行其他的功能，例如，当机器人的音箱的音量大于预设音量阈值时，可以通过代理应用类调用硬件组件的关键路径中的音量调节路径；通过音量调节路径将音箱的音量调小。

s203、机器人通过代理应用类向服务器上报状态信息，以及接收服务器基于状态信息发送的关于硬件组件的补丁包。

在创建代理应用类后，机器人在运行时可以动态加载代理应用类，可以通过代理应用类向服务器上报状态信息，其中，该状态信息可以包括机器人的标识、机器人当前的sdk版本号、机器人的连网状态、机器人的硬件组件状态及内存运行状态等信息。

服务器对接收到的状态信息进行监测，当监测到机器人的硬件组件存在异常时，可以输出关于机器人的硬件组件的异常提示信息，使得开发人员可以根据异常提示信息在客户端上修改sdk代码，该客户端可以根据编译的sdk代码生成sdk修改版本，并将sdk修改版本上传至服务器。服务器根据机器人的硬件组件对应的sdk当前版本，以及接收到的sdk修改版本生成关于机器人的硬件组件的补丁包。例如，服务器将sdk当前版本的执行程序文件与sdk修改版本的执行程序文件进行对比，得到sdk当前版本的执行程序文件与sdk修改版本的执行程序文件之间的差异信息，以及该差异信息在sdk当前版本的执行程序文件中的偏移信息；然后，根据差异信息及偏移信息生成关于机器人的硬件组件的补丁包，最后将该补丁包发送给机器人。

例如，若机器人在进行语音交互时，例如询问天气、收听音乐以及进行闲聊等场景下，硬件组件的sdk内部出现了需要紧急修复的严重bug，导致影响业务体验甚至系统崩溃，此时开发人员可以修改sdk代码生成sdk修改版本，并将sdk修改版本发给服务器，由服务器根据sdk修改版本及sdk当前版本生成补丁包，以及将补丁包有针对性地下发给使用sdk当前版本的机器人，机器人可以根据接收到的补丁包更新sdk，以对硬件组件的进行热修复，即可保证在机器人处于正常运行的状态。

需要说明的是，当接收到服务器发送的补丁包时，机器人可以判断接收到的补丁包是否完整；若是，则调用代理应用类，以通过代理应用类对硬件组件进行热修复；若否，则从服务器重新下载关于硬件组件的补丁包，在下载到完整的补丁包后，调用代理应用类，以通过代理应用类对硬件组件进行热修复。

s204、机器人通过代理应用类获取sdk当前版本，以及通过代理应用类调用sdk的修复接口。

机器人在接收到服务器发送的补丁包后，调用代理应用后，可以通过代理应用对获取设备中当前使用的sdk版本号，以及获取与该sdk版本号对应的sdk当前版本。由于代理应用类集成了sdk的所有接口，因此可以通过代理应用类调用sdk的修复接口。

s205、机器人基于修复接口，利用补丁包更新sdk当前版本，得到sdk更新版本。

机器人可以通过代理应用类基于sdk的修复接口，获取补丁包中的偏移信息及差异信息，以及获取sdk当前版本的执行程序文件；根据偏移信息确定在执行程序文件中待更新的位置；将差异信息替换待更新的位置对应的内容，得到sdk更新版本。例如，当偏移信息b为在sdk当前版本的执行程序文件中的第50行，且偏移信息b对应差异信息b时，可以将sdk当前版本的执行程序文件中的第50行的内容替换为差异信息b。

需要说明的是，机器人在更新sdk当前版本的过程中，可以判断sdk当前版本是否更新成功，若是，则可以得到sdk更新版本；若否，则说明更新失败，此时可以将当前的sdk恢复至sdk当前版本，生成硬件组件的修复失败状态，并将修复失败状态上报至服务器，以便开发人员从服务器获取硬件组件的修复失败状态，进一步确定修复失败的原因，并采取下一步修改策略。

例如，当补丁包中有6个差异信息需要在sdk当前版本中的6处位置进行更新时，若第一个差异信息和第二个差异信息分别在sdk当前版本中的第一个位置和第二个位置更新成功，而在利用第三个差异信息更新第三个位置时，更新失败，此时将已经更新的内容恢复至未更新的之前的状态，使得当前的sdk恢复至sdk当前版本。

s206、机器人通过代理应用类加载sdk新版本，以对硬件组件进行热修复。

机器人在更新得到sdk新版本，可以通过代理应用类加载sdk新版本，以对硬件组件进行热修复。

例如，如图4所示，机器人在根据硬件组件的关键路径及sdk创建代理应用类后，可以将硬件组件中的关键路径迁移至代理应用类中，在接入硬件组件的sdk的后，可以通过代理应用类实现硬件组件中的关键路径对应的关键逻辑，并且在机器人加载硬件组件时，可以动态加载代理应用类。当硬件组件出现bug时，机器人在通过消息推送通道(即push通道)接收服务器下发的关于硬件组件的补丁包，调用代理应用类，基于代理应用类利用将补丁包对sdk进行更新，生成sdk更新版本，然后加载sdk更新版本，对硬件组件进行热修复。

本发明实施例中，机器人可以创建集成硬件组件的关键路径及sdk等的代理应用，通过该代理应用，可以根据接收到的补丁包对硬件组件进行热修复，而无需通过安装包对sdk进行升级，每次修复只需要接收服务器下发的补丁包即可，节省了机器人的流量资源，以及提高了机器人对硬件组件进行热修复的可靠性及便捷性。

为便于更好的实施本发明实施例提供的硬件组件的修复方法，本发明实施例还提供一种基于上述硬件组件的修复方法的装置。其中名词的含义与上述硬件组件的修复方法中相同，具体实现细节可以参考方法实施例中的说明。

请参阅图5，图5为本发明实施例提供的硬件组件的修复装置的结构示意图，其中该硬件组件的修复装置可以包括获取单元301、创建单元302、调用单元303及修复单元304等。

其中，获取单元301，用于获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk。

本发明实施例中，硬件组件的修复装置对硬件组件进行修复时，可以是对硬件组件进行热修复，该热修复在用户无感知情况下硬件组件使用补丁进行紧急修复，例如，可以是通过修复硬件组件漏洞的一些代码生成补丁包，根据补丁包对硬件组件进行的修复，该热修复是一种快速及低成本修复硬件组件bug的修复方式。此时，不用重新下载一个新的安装包，而是直接下载一个补丁包，通过补丁包来替换一些出现bug的类，由于下载补丁包的过程用户一般是感觉不到的，因此可以在用户无感知情况下直接修复硬件组件的bug。

以下将以硬件组件的修复装置对硬件组件进行热修复为例进行详细说明。

其中，硬件组件可以是硬件的应用，即设备中硬件的软件层上的应用(即application)；硬件组件的关键路径可以包括设备中关键场景的sdk的调用路径，例如，设备连接网络、设备的电量过低、设备音量变大或会变小等场景的sdk的调用路径。在创建代理应用之前，获取单元301需要获取设备中硬件组件的关键路径，以及加载sdk，对sdk执行初始化等操作。

创建单元302，用于根据关键路径及sdk创建硬件组件对应的代理应用类。

在得到硬件组件的关键路径及加载sdk后，创建单元302可以根据该关键路径及sdk创建硬件组件对应的代理应用类(即application代理类)，即将硬件组件的关键路径迁移至代理应用类，以及将sdk的接口及功能等集成在代理应用类中等。其中，该代理应用类可以包括实例，该实例可以是设备系统为应用的每个进程创建的应用实例，可以通过该实例来进行数据传递、数据共享、及数据缓存等操作。

在创建得到的代理应用类后，硬件组件的修复装置在运行时可以动态加载代理应用类，以及可以通过代理应用类对sdk进行初始化及更新等一系列操作，该代理应用类还可以实现硬件组件的所有功能。

在某些实施方式中，如图8所示，硬件组件的修复装置还包括：

路径调用单元305，用于当设备的电量低于预设电量阈值时，调用代理应用类，以及通过代理应用类调用硬件组件的关键路径中的电量调节路径；

释放单元306，用于通过电量调节路径释放预设内存。

具体地，由于代理应用类中集成了硬件组件的关键路径及sdk的功能等，因此，当设备的电量低于预设电量阈值时，说明设备的电量过低，此时硬件组件的修复装置针对电量过低的信息，对设备的运行状态进行相应的调度。

例如，为了延长设备的使用时间，硬件组件的修复装置可以调用代理应用类，通过代理应用类调用硬件组件的关键路径中的电量调节路径，通过电量调节路径释放设备的预设内存，以减少单位时间内设备电量的消耗。

需要说明的是，还可以通过电量调节路径调小设备中音响的音量、或关闭设备的显示屏的显示等，来达到减少单位时间内设备电量的消耗的目的。其中，预设电量阈值及预设内存可以根据实际情况进行灵活设置，具体内容在此处不作限定。

可以理解的是，还可以调用代理应用类来执行其他的功能，例如，当设备需要连接网络时，可以通过代理应用类调用硬件组件的关键路径中的网络连接路径，并通过该网络连接路径执行连网操作；当设备需要将设备的音量调大时，可以通过代理应用类调用硬件组件的关键路径中的音量调节路径，并通过该音量调节路径将设备的音量调大，等等。

调用单元303，用于当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类。

调用单元303可以是主动向服务器发送补丁包获取请求，然后接收服务器基于补丁包获取请求发送的关于硬件组件的补丁包，以便修复单元304根据补丁包对硬件组件进行修复。当然，调用单元303也可以是被动接收服务器发送的关于硬件组件的补丁包，以便修复单元304根据补丁包对硬件组件进行热修复，此时服务器可以是每隔预设时间向调用单元303发送补丁包，也可以是在每次生成补丁包后向调用单元303发送该补丁包。

服务器在向调用单元303发送补丁包之前，可选地，服务器接收客户端上传的关于设备的硬件组件的sdk修改版本，以及获取设备的硬件组件对应的sdk当前版本；根据sdk修改版本及sdk当前版本生成关于设备的硬件组件的补丁包；然后将该补丁包发送给调用单元303。

其中，该客户端可以是开发人员用于编译sdk代码的客户端，该客户端可以根据编译的sdk代码生成sdk修改版本。

可选地，服务器接收客户端上传的关于设备的硬件组件的sdk修改版本的步骤可以包括：服务器接收设备上报的状态信息，并对该状态信息进行监测；当监测到设备的硬件组件存在异常时，输出关于设备的硬件组件的异常提示信息，接收客户端基于异常提示信息上传的sdk修改版本。当然，客户端也可以是根据实际需要向服务器上传的sdk修改版本。

其中，该状态信息可以包括设备标识、设备版本号、设备当前的sdk版本号、设备的连网状态、设备的硬件组件状态及设备的内存运行状态等信息。

可选地，服务器获取设备的硬件组件对应的sdk当前版本的步骤可以包括：服务器从设备上报的状态信息中或与设备的交互信息中获取设备标识，根据设备标识获取设备的硬件组件当前的sdk版本号，从存储sdk版本的数据库中，获取与该sdk版本号对应的sdk当前版本。

可选地，服务器根据sdk修改版本及sdk当前版本生成关于设备的硬件组件的补丁包的步骤可以包括：服务器将sdk当前版本的执行程序文件与sdk修改版本的执行程序文件进行对比，得到sdk当前版本的执行程序文件与sdk修改版本的执行程序文件之间的差异信息，以及该差异信息在sdk当前版本的执行程序文件中的偏移信息；然后根据差异信息及偏移信息生成关于设备的硬件组件的补丁包。

其中，执行程序文件即为dex(dex的英文全称为：dalvikvmexecutes，即androiddalvik执行程序)文件，该dex文件包含了硬件组件用到的所有操作指令和运行时数据等，在程序编译过程中，java源文件先被编译成class文件，然后通过dx工具将多个class文件整合为一个或多个dex文件，这样的文件结构使得各个类能够共享数据，充分减少了存储空间，提升了运行效率。

可选地，服务器将补丁包发送给调用单元303的步骤可以包括：服务器从设备上报的状态信息中或与设备的交互信息中获取设备标识，其中，该设备标识即为调用单元303所在设备的设备标识，此时可以根据设备标识将补丁包发送给调用单元303。

或者是，服务器获取从设备上报的状态信息中或与设备的交互信息中获取设备标识，根据设备标识获取设备的硬件组件当前的sdk版本号，然后，从存储所有设备标识的数据库中获取使用该sdk版本号的目标设备标识(上述设备标识包含于目标设备标识)，最后将补丁包发送给与目标设备标识对应的目标设备(上述设备包括调用单元303，上述设备包含于目标设备)。

其中，目标设备标识可以包括一个或多个设备标识，目标设备可以包括一个或多个设备。设备标识可以是用于标志设备唯一性的标号，例如，可以由长度为16位的字符串构成，使得服务器可以根据设备唯一的设备标识，向设备下发补丁包，以便设备根据补丁包对硬件组件进行热修复。

在某些实施方式中，调用单元303具体用于：

当接收到服务器发送的补丁包时，判断接收到的补丁包是否完整；若是，则调用代理应用类；若否，则从服务器重新下载关于硬件组件的补丁包，在下载到完整的补丁包后，调用代理应用类。

具体地，在接收到补丁包后，调用单元303首先判断接收到的补丁包是否完整，例如，调用单元303可以通过检测补丁包接收的过程中是否出现数据传输中断，若出现数据传输中断，则确定接收到的补丁包不完整；若未出现数据传输中断，则确定接收到的补丁包完整。或者是，通过其他方式判断接收到的补丁包是否完整，具体内容在此处不作限定。

当接收到的补丁包为完整时，调用单元303可以调用代理应用类，以便修复单元304通过代理应用类对硬件组件进行热修复。

当接收到的补丁包不完整时，调用单元303可以获取关于硬件组件的补丁包的标识，并向服务器发送与该标识对应的补丁包获取请求，接收服务器基于补丁包获取请求重新发送的补丁包，从而可以从服务器重新下载与补丁包的标识对应的补丁包。在下载到完整的补丁包后，调用单元303可以调用代理应用类，以便修复单元304通过代理应用类对硬件组件进行热修复。

或者是，当接收到的补丁包不完整时，调用单元303可以向服务器发送补丁包接收失败的信息，以使得服务器基于接收到的信息重新向调用单元303发送关于硬件组件的补丁包，从而可以从服务器重新下载与补丁包的标识对应的补丁包。在下载到完整的补丁包后，调用单元303可以调用代理应用类，以便修复单元304通过代理应用类对硬件组件进行热修复。

可选地，调用单元303从服务器重新下载关于硬件组件的补丁包的步骤可以包括：

判断当前的下载次数是否达到预设次数；若是，则结束对关于硬件组件的补丁包执行的重新下载操作；若否，则从服务器重新下载关于硬件组件的补丁包。其中，预设次数可以根据实际情况进行灵活设置，具体取值在此处不作限定。

可选地，调用单元303从服务器重新下载关于硬件组件的补丁包的步骤可以包括：

获取当前时间戳与首次未接收到完整的补丁包的时间戳之间的时间间隔；判断时间间隔是否大于预设时间间隔；若是，则结束对关于硬件组件的补丁包执行的重新下载操作；若否，则从服务器重新下载关于硬件组件的补丁包。其中，预设时间间隔可以根据实际情况进行灵活设置，具体取值在此处不作限定。

修复单元304，用于基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。

在调用代理应用类后，修复单元304可以基于代理应用类，利用接收到的关于硬件组件的补丁包对sdk进行更新，以实现对硬件组件进行修复，即以实现对硬件组件进行热修复。其中，热修复可以通过补丁包对硬件组件进行修复，该热修复的过程是一种在用户无感知的情况下修复硬件组件存在的bug的过程。并且，避免了通过ota更新安装包的方式来修复bug，使得每次修复只需要接收服务器下发的补丁包包即可，极大程度缓解了服务器与设备之间的通道资源占用大的问题。

在某些实施方式中，如图6所示，修复单元304可以包括：

获取子单元3041，用于通过代理应用类获取sdk当前版本，以及通过代理应用类调用sdk的修复接口；

更新子单元3042，用于通过修复接口，根据补丁包更新sdk当前版本，得到sdk更新版本；

加载子单元3043，用于通过代理应用类加载sdk更新版本，以对硬件组件进行修复。

修复单元304在调用代理应用后，可以通过代理应用对硬件组件进行热修复，具体地，首先由获取子单元3041通过代理应用类获取设备中当前使用的sdk版本号，并获取与sdk版本号对应的sdk当前版本。由于代理应用类集成了sdk的所有接口，因此可以通过代理应用类调用sdk的修复接口，然后，由更新子单元3042通过sdk的修复接口，根据接收到的关于硬件组件的补丁包更新sdk当前版本，得到sdk更新版本。最后，加载子单元3043通过代理应用类加载sdk更新版本，以对硬件组件进行热修复。

需要说明的是，现有技术中，硬件组件的sdk需要对外开放给各个硬件厂商进行接入的接口，因而硬件组件的实现控制是在各个硬件厂商侧，导致sdk的调用范围对于应用提供商侧的sdk开发人员是不可控的。而本发明实施例中，通过创建代理应用，可以将硬件组件的sdk的关键路径从硬件厂商侧收归回sdk对应的应用提供商持有，保证sdk的调用范围对于应用提供商侧的sdk开发人员是可控的，应用提供商侧的sdk开发人员可以直接编译sdk代码生成sdk修改版本，而无需与硬件厂商沟通，可以在出现紧急bug时，避免与硬件厂商进行沟通，更不需要硬件厂商参与修改及测试，提高了sdk的更新效率，即提高了硬件组件的热修复效率及热修复范围。

可选地，更新子单元3042具体用于：

通过修复接口，获取补丁包中的偏移信息及差异信息，以及获取sdk当前版本的执行程序文件；根据偏移信息确定在执行程序文件中待更新的位置；将差异信息替换待更新的位置对应的内容，得到sdk更新版本。

具体地，更新子单元3042可以通过调用修复接口对sdk进行更新，首先，更新子单元3042从补丁包中提取偏移信息及差异信息等，以及取设备的硬件组件当前的sdk版本号，根据sdk版本号获取sdk当前版本，并获取该sdk当前版本的执行程序文件。其中，差异信息可以是得到sdk当前版本的执行程序文件与sdk修改版本的执行程序文件之间的差异信息，偏移信息可以是差异信息在sdk当前版本的执行程序文件中的偏移信息。

需要说明的是，偏移信息与差异信息之间存在对应关系，偏移信息与差异信息可以是一个或多个，即补丁包中可以是包括一个偏移信息与一个差异信息之间的对应关系，也可以包括多个偏移信息分别与多个差异信息之间的对应关系。

然后，更新子单元3042根据偏移信息确定在sdk当前版本的执行程序文件中待更新的位置，将差异信息替换待更新的位置对应的内容，得到sdk更新版本。例如，当偏移信息a为在sdk当前版本的执行程序文件中的第100行，且偏移信息a对应差异信息a时，硬件组件的修复装置将sdk当前版本的执行程序文件中的第100行的内容替换为差异信息a。使得硬件组件的修复装置可以通过补丁包合成sdk更新版本的方式修复硬件组件的bug，用户无感知修复过程，提升了用户体验。

在某些实施方式中，如图7所示，修复单元304还包括：

上报子单元3044，用于若未能成功将差异信息替换待更新的位置对应的内容，则将当前的sdk恢复至sdk当前版本，生成硬件组件的修复状态，并将修复状态上报至服务器。

具体地，更新子单元3042在将差异信息替换待更新的位置对应的内容的过程中，判断是否能成功将差异信息替换待更新的位置对应的内容。若能成功将差异信息替换待更新的位置对应的内容，则可以得到sdk更新版本。若未能成功将差异信息替换待更新的位置对应的内容，则说明补丁包中包含的差异信息及偏移信息等信息可能存在异常，无法正常进行修复，即热修复失败，此时，为了保持当前的sdk与接收到补丁包之前的状态一致，上报子单元3044可以将当前的sdk恢复至sdk当前版本。

当未能成功将差异信息替换待更新的位置对应的内容时，上报子单元3044还可以生成硬件组件的修复状态，并将修复状态上报至服务器，其中，修复状态可以是sdk当前的更新状态，例如可以是sdk修复失败的状态。以便sdk开发人员从服务器获取硬件组件的修复状态，进一步确定修复失败的原因，并采取下一步修改策略。

由上可知，本发明实施例通过获取单元301获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；然后，创建单元302根据关键路径及sdk创建硬件组件对应的代理应用类；当接收到服务器发送的关于硬件组件的补丁包时，由调用单元303调用代理应用类；修复单元304基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。该方案中由于该代理应用类集成了硬件组件的关键路径及sdk的功能等，因此，可以通过该代理应用类，根据接收到的补丁包对设备的硬件组件进行修复，而无需通过安装包对sdk进行升级，节省了设备的流量资源，以及提高了设备对硬件组件进行修复的可靠性及便捷性。

相应的，本发明实施例还提供一种设备，如图9所示，该设备可以包括射频(rf，radiofrequency)电路401、包括有一个或一个以上计算机可读存储介质的存储器402、输入单元403、显示单元404、传感器405、音频电路406、无线保真(wifi，wirelessfidelity)模块407、包括有一个或者一个以上处理核心的处理器408、以及电源409等部件。本领域技术人员可以理解，图9中示出的设备结构并不构成对设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

rf电路401可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器408处理；另外，将涉及上行的数据发送给基站。通常，rf电路401包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(sim，subscriberidentitymodule)卡、收发信机、耦合器、低噪声放大器(lna，lownoiseamplifier)、双工器等。此外，rf电路401还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(gsm，globalsystemofmobilecommunication)、通用分组无线服务(gprs，generalpacketradioservice)、码分多址(cdma，codedivisionmultipleaccess)、宽带码分多址(wcdma，widebandcodedivisionmultipleaccess)、长期演进(lte，longtermevolution)、电子邮件、短消息服务(sms，shortmessagingservice)等。

存储器402可用于存储软件程序以及模块，处理器408通过运行存储在存储器402的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器402可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据设备的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器402还可以包括存储器控制器，以提供处理器408和输入单元403对存储器402的访问。

输入单元403可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，在一个具体的实施例中，输入单元403可包括触敏表面以及其他输入设备。触敏表面，也称为触摸显示屏或者触控板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面上或在触敏表面附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触敏表面可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器408，并能接收处理器408发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触敏表面。除了触敏表面，输入单元403还可以包括其他输入设备。具体地，其他输入设备可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元404可用于显示由用户输入的信息或提供给用户的信息以及设备的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元404可包括显示面板，可选的，可以采用液晶显示器(lcd，liquidcrystaldisplay)、有机发光二极管(oled，organiclight-emittingdiode)等形式来配置显示面板。进一步的，触敏表面可覆盖显示面板，当触敏表面检测到在其上或附近的触摸操作后，传送给处理器408以确定触摸事件的类型，随后处理器408根据触摸事件的类型在显示面板上提供相应的视觉输出。虽然在图9中，触敏表面与显示面板是作为两个独立的部件来实现输入和输入功能，但是在某些实施例中，可以将触敏表面与显示面板集成而实现输入和输出功能。

设备还可包括至少一种传感器405，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板的亮度，接近传感器可在设备移动到耳边时，关闭显示面板和/或背光。作为运动传感器的一种，重力加速度传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于设备还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路406、扬声器，传声器可提供用户与设备之间的音频接口。音频电路406可将接收到的音频数据转换后的电信号，传输到扬声器，由扬声器转换为声音信号输出；另一方面，传声器将收集的声音信号转换为电信号，由音频电路406接收后转换为音频数据，再将音频数据输出处理器408处理后，经rf电路401以发送给比如另一设备，或者将音频数据输出至存储器402以便进一步处理。音频电路406还可能包括耳塞插孔，以提供外设耳机与设备的通信。

wifi属于短距离无线传输技术，设备通过wifi模块407可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图9示出了wifi模块407，但是可以理解的是，其并不属于设备的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器408是设备的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器402内的软件程序和/或模块，以及调用存储在存储器402内的数据，执行设备的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器408可包括一个或多个处理核心；优选的，处理器408可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器408中。

设备还包括给各个部件供电的电源409(比如电池)，优选的，电源可以通过电源管理系统与处理器408逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源409还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管未示出，设备还可以包括摄像头、蓝牙模块等，在此不再赘述。具体在本实施例中，设备中的处理器408会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器402中，并由处理器408来运行存储在存储器402中的应用程序，从而实现各种功能：

获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；根据关键路径及sdk创建硬件组件对应的代理应用类；当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类；基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。

可选地，基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复的步骤可以包括：

通过代理应用类获取sdk当前版本，以及通过代理应用类调用sdk的修复接口；通过修复接口，根据补丁包更新sdk当前版本，得到sdk更新版本；通过代理应用类加载sdk更新版本，以对硬件组件进行修复。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

由上可知，本发明实施例通过获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；然后，根据关键路径及sdk创建硬件组件对应的代理应用类；当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类；基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。该方案中由于该代理应用类集成了硬件组件的关键路径及sdk的功能等，因此，可以通过该代理应用类，根据接收到的补丁包对设备的硬件组件进行修复，而无需通过安装包对sdk进行升级，节省了设备的流量资源，以及提高了设备对硬件组件进行修复的可靠性及便捷性。

本发明实施例还提供一种服务器，如图10所示，其示出了本发明实施例所涉及的服务器的结构示意图，具体来讲：

该服务器可以包括一个或者一个以上处理核心的处理器501、一个或一个以上计算机可读存储介质的存储器502、电源503和输入单元504等部件。本领域技术人员可以理解，图10中示出的服务器结构并不构成对服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器501是该服务器的控制中心，利用各种接口和线路连接整个服务器的各个部分，通过运行或执行存储在存储器502内的软件程序和/或模块，以及调用存储在存储器502内的数据，执行服务器的各种功能和处理数据，从而对服务器进行整体监控。可选的，处理器501可包括一个或多个处理核心；优选的，处理器501可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器501中。

存储器502可用于存储软件程序以及模块，处理器501通过运行存储在存储器502的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器502可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据服务器的使用所创建的数据等。此外，存储器502可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器502还可以包括存储器控制器，以提供处理器501对存储器502的访问。

服务器还包括给各个部件供电的电源503，优选的，电源503可以通过电源管理系统与处理器501逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源503还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该服务器还可包括输入单元504，该输入单元504可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

尽管未示出，服务器还可以包括显示单元等，在此不再赘述。具体在本实施例中，服务器中的处理器501会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器502中，并由处理器501来运行存储在存储器502中的应用程序，从而实现各种功能，如下：

接收客户端上传的关于设备的硬件组件的sdk修改版本，以及获取设备的硬件组件对应的sdk当前版本；根据sdk修改版本及sdk当前版本生成关于设备的硬件组件的补丁包；将该补丁包发送给设备。

可选地，接收客户端上传的关于设备的硬件组件的sdk修改版本的步骤可以包括：接收设备上报的状态信息，并对该状态信息进行监测；当监测到设备的硬件组件存在异常时，输出关于设备的硬件组件的异常提示信息，接收客户端基于异常提示信息上传的sdk修改版本。

可选地，获取设备的硬件组件对应的sdk当前版本的步骤可以包括：从设备上报的状态信息中或与设备的交互信息中获取设备标识，根据设备标识获取设备的硬件组件当前的sdk版本号，从存储sdk版本的数据库中，获取与该sdk版本号对应的sdk当前版本。

可选地，根据sdk修改版本及sdk当前版本生成关于设备的硬件组件的补丁包的步骤可以包括：sdk当前版本的执行程序文件与sdk修改版本的执行程序文件；将sdk当前版本的执行程序文件与sdk修改版本的执行程序文件进行对比，得到sdk当前版本的执行程序文件与sdk修改版本的执行程序文件之间的差异信息，以及该差异信息在sdk当前版本的执行程序文件中的偏移信息；根据差异信息及偏移信息生成关于设备的硬件组件的补丁包。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可参见上文针对硬件组件的修复方法的详细描述，此处不再赘述。

本发明实施例还提供一种硬件组件的修复系统，该硬件组件的修复系统可以包括本发明实施例所提供的任一种硬件组件的修复装置，其中该硬件组件的修复装置具体可以集成在上述设备中，例如，可以如下：

设备，用于获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；根据关键路径及sdk创建硬件组件对应的代理应用类；当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类；基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。

该设备，还可以用于通过代理应用类获取sdk当前版本，以及通过代理应用类调用sdk的修复接口；通过修复接口，根据补丁包更新sdk当前版本，得到sdk更新版本；通过代理应用类加载sdk更新版本，以对硬件组件进行修复。

可选地，该硬件组件的修复系统还可以包括服务器，具体可以如下：

服务器，用于接收客户端上传的关于设备的硬件组件的sdk修改版本，以及获取设备的硬件组件对应的sdk当前版本；根据sdk修改版本及sdk当前版本生成关于设备的硬件组件的补丁包；将该补丁包发送给设备。

该服务器，还可以用于接收设备上报的状态信息，并对该状态信息进行监测；当监测到设备的硬件组件存在异常时，输出关于设备的硬件组件的异常提示信息，接收客户端基于异常提示信息上传的sdk修改版本。

该服务器，还可以用于根据sdk修改版本及sdk当前版本生成关于设备的硬件组件的补丁包的步骤可以包括：sdk当前版本的执行程序文件与sdk修改版本的执行程序文件；将sdk当前版本的执行程序文件与sdk修改版本的执行程序文件进行对比，得到sdk当前版本的执行程序文件与sdk修改版本的执行程序文件之间的差异信息，以及该差异信息在sdk当前版本的执行程序文件中的偏移信息；根据差异信息及偏移信息生成关于设备的硬件组件的补丁包。

以上设备及服务器的具体实施可参见前面的实施例，在此不再赘述。

由于该硬件组件的修复系统可以包括本发明实施例所提供的任一种硬件组件的修复装置，因此，可以实现本发明实施例所提供的任一种硬件组件的修复装置所能实现的有益效果，详见前面针对硬件组件的修复方法的详细描述的实施例，在此不再赘述。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本发明实施例提供一种存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本发明实施例所提供的任一种硬件组件的修复方法中的步骤。例如，该指令可以执行如下步骤：

获取设备中硬件组件的关键路径，以及加载软件开发工具包sdk；根据关键路径及sdk创建硬件组件对应的代理应用类；当接收到服务器发送的关于硬件组件的补丁包时，调用代理应用类；基于代理应用类，利用补丁包对sdk进行更新，以对硬件组件进行修复。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

其中，该存储介质可以包括：只读存储器(rom，readonlymemory)、随机存取记忆体(ram，randomaccessmemory)、磁盘或光盘等。

由于该存储介质中所存储的指令，可以执行本发明实施例所提供的任一种硬件组件的修复方法中的步骤，因此，可以实现本发明实施例所提供的任一种硬件组件的修复方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本发明实施例所提供的一种硬件组件的修复方法、装置、系统和存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对本领域的技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。