一种应用程序自修复方法、装置、设备及存储介质与流程

1.本发明涉及应用程序修复领域，尤其涉及一种应用程序自修复方法、装置、设备及存储介质。


背景技术：

2.混合开发模式日渐成为了智能终端市场中应用程序开发的主流模式，相较于传统的原生开发和页面开发，混合开发模式因为可以支持热更新技术进行应用程序的修复而显著提升应用程序的修复速度。
3.然而，若应用程序出现异常，即使使用热更新技术，也需要技术人员参与进行缺陷定位和代码修复，然后生成补丁包，将补丁包下发至智能终端才能实现应用程序的修复，这个过程会产生较大的时延，并且对技术人员的依赖程度高，对网络资源的需求也高，离线状态下无法进行修复。并且，热更新技术在一定程度上受制于操作系统的发布商，也难以自由实现全自主的热更新。


技术实现要素：

4.基于热更新技术修复运行于智能终端的应用程序需要依赖于技术人员进行缺陷定位和代码修复才能够生成补丁包，并且需要依赖互联网将补丁包由服务器下发至智能终端后才能够对运行于智能终端的应用程序进行修复，这个过程人力成本，网络资源成本和时间成本都较高，为了解决这个技术问题，本发明实施例公开一种应用程序自修复方法、装置、设备及存储介质。
5.一方面，本发明提供了一种应用程序自修复方法，所述应用程序包括前端组件和原生端组件，所述方法应用于所述原生端组件，所述方法包括：
6.若前端组件运行出现异常，获取所述前端组件产生的异常信息，所述异常信息包括异常类型信息和异常位置信息；
7.若启动自修复机制修复所述异常，则读取所述异常位置信息指向的目标文件；
8.根据所述异常类型信息获得对应的语法分析匹配器；
9.基于所述语法分析匹配器和所述异常位置信息对所述目标文件进行分析，得到目标异常代码段；
10.根据所述异常类型信息修复所述目标异常代码段，得到补丁文件；
11.基于所述补丁文件修复所述前端组件。
12.另一方面，本发明提供一种应用程序自修复装置，所述应用程序包括前端组件和原生端组件，所述装置包括：
13.异常信息捕获模块，用于获取所述前端组件产生的异常信息，所述异常信息包括异常类型信息和异常位置信息；
14.目标文件读取模块，用于若启动自修复机制修复所述异常，则读取所述异常位置信息指向的目标文件；
15.语法分析匹配器获取模块，用于根据所述异常类型信息获得对应的语法分析匹配器；
16.目标异常代码段定位模块，用于基于所述语法分析匹配器和所述异常位置信息对所述目标文件进行分析，得到目标异常代码段；
17.补丁文件生成模块，用于根据所述异常类型信息修复所述目标异常代码段，得到补丁文件；
18.修复模块，用于基于所述补丁文件修复所述前端组件。
19.另一方面，本发明提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现上述的一种应用程序自修复方法。
20.另一方面，本发明提供了一种应用程序自修复设备，其特征在于，所述设备包括处理器和存储器所述存储器中存储有至少一条指令或至少一段程序所述至少一条指令或至少一段程序由所述处理器加载并执行上述的一种应用程序自修复方法。
21.本发明提供了一种应用程序自修复方法、装置、设备及存储介质。本发明当应用程序前端组件发生异常时，可以由所述应用程序的原生端组件自动对前端组件进行异常定位和异常修正，并且以补丁文件的形式进行前端组件的修复，这个过程并不需要人工参与，可以全自动实施，并且并不强制需要与服务器进行交互，可以显著提升修复速度，降低人力成本和通信成本。
附图说明
22.为了更清楚地说明本发明实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。
23.图1是本发明提供的一种应用程序自修复方法流程图；
24.图2是本发明提供的混合开发模式架构示意图；
25.图3是本发明提供的获取所述前端组件产生的异常信息流程图；
26.图4是本发明提供的自修复机制启动判断流程图；
27.图5是本发明提供的基于所述语法分析匹配器和所述异常位置信息对所述目标文件进行分析，得到目标异常代码段流程图；
28.图6是本发明提供的第一匹配流程图；
29.图7是本发明提供的根据所述异常类型信息修复所述目标异常代码段，得到补丁文件流程图；
30.图8是本发明提供的基于所述补丁文件修复所述前端组件流程图；
31.图9是本发明提供的启动失败处理流程图；
32.图10是本发明提供的现有技术中热更新的产品界面示意图；
33.图11是本发明提供的本发明实施例对应的产品界面示意图；
34.图12是本发明提供的一种应用程序自修复装置框图；
35.图13是本发明提供的一种用于实现本发明实施例所提供的方法的设备的硬件结
构示意图。
具体实施方式
36.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
37.需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
38.为了使本发明实施例公开的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明实施例进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本发明实施例，并不用于限定本发明实施例。
39.以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。为了便于对本发明实施例进行阐述，首先对于本发明实施例相关技术术语进行阐述：
40.混合开发：对于运行于智能终端的应用程序主要有原生开发、html5开发和混合开发三种开发方式。原生开发是在智能操作系统(android、ios)上利用官方提供的开发语言、开发类库、开发工具进行开发。原生开发无法跨平台，只能适用于其对应的操作系统。html5开发是利用页面技术进行的开发，其可以跨平台，但是在功能上具有较大局限性，并且无法与智能终端的硬件资源交互。混合开发是融合原生开发和html5开发的能够实现取长补短效果的开发模式，通常由页面前端开发和客户端开发两部份构成，具有实现功能多，迭代速度快的显著优势。
41.热更新：是一种混合开发模式下常用的更新方式，在应用程序被安装至智能终端后，若被打开即可通过与服务器交互获得补丁文件，进行即时更新。热更新动态下发代码，可以使开发者在不发布新版本的情况下，修复缺陷和发布功能，让开发者得以绕开苹果公司的审核机制，避免长时间的审核等待以及降低多次被拒造成的成本，然而也受到来自苹果公司的掣肘，比如，苹果应用商店可以要求热更新相关的应用程序的发布者移除相关代码，并且接受审核。
42.智能终端：又称移动智能终端，是指一类具备丰富人机交互方式、拥有接入互联网能力、通常搭载各种智能操作系统、具有较强处理能力的设备。移动智能终端包括智能手机、平板电脑、车载终端、掌上游戏主机等。所述智能操作系统包括但不限于android操作系统和ios操作系统。
43.jit：动态编译(dynamiccompilation)译为“在运行时进行编译”，当某段代码即将第一次被执行时进行编译，也可被称之为“即时编译”。jit编译也可以在某些场景中被视为是动态编译的一种特例。
44.reactnative：开源的跨平台移动应用开发框架。
45.weex：是一个使用页面开发体验来开发高性能原生应用的框架。
46.jsbridge：是可以让混合开发中的前端部分方便地使用原生功能的通信接口，是原生组件和非原生组件之间的桥梁，它的核心是构建原生组件和非原生组件间消息通信的通道，而且这个通信的通道是双向的。
47.bundle：是一种google官方新推出的应用资源包，可以有效地减少包体大小,提升启动速度。
48.基于热更新技术修复运行于智能终端的应用程序需要依赖于技术人员进行缺陷定位和代码修复才能够生成补丁包，并且需要依赖互联网将补丁包由服务器下发至智能终端后才能够对运行于智能终端的应用程序进行修复，这个过程人力成本，网络资源成本和时间成本都较高，为了解决这个技术问题，本发明实施例提供一种应用程序自修复方法，所述自修复方法可以使得应用程序在智能终端运行过程中能够自主自动修复自身缺陷，减少对于技术人员和网络资源的依赖，并且显著提升修复效率，缩短修复时间。
49.本发明实施例提供一种应用程序自修复方法，所述应用程序包括前端组件和原生端组件，所述方法应用于所述原生端组件，如图1所示，包括：
50.s101.若前端组件运行出现异常，获取所述前端组件产生的异常信息，所述异常信息包括异常类型信息和异常位置信息。
51.如图2所示，混合开发模式由页面前端开发和客户端开发两部份构成，页面前端开发得到前端组件，客户端开发得到原生端组件，前端组件和原生端组件交互实现应用程序在智能终端的运行。其中，前端组件可以在智能终端上被动态编译然后进行执行，前端组件通常可以是跨平台组件，基于跨平台框架使用跨平台语言编写得到，比如，可以基于reactnative框架或weex框架构建前端组件。原生端组件运行于客户端，其可以是运行于android端的组件或运行于ios端的组件。
52.具体地，所述异常类型信息用于指示异常的类型。事实上，通过对应用程序运行时出现崩溃的场景的分析可知，导致应用程序崩溃的原因可以被归类为有限个，比如，边界问题导致的崩溃，编码不规范导致的崩溃。这些崩溃原因在应用程序崩溃时即可被前端组件捕获，进而生成异常类型信息。
53.在一个实施例中，所述异常位置信息包括出错文件名和出错位置，所述出错位置可以通过在出错文件中的行列号表征。
54.在另一个实施例中，所述异常信息还可以包括附加出错信息，所述附加出错信息可以用于记录跟所述异常有关的其它信息，所述附加出错信息可以是可选项，附加出错信息的内容可以基于第一预设模板进行配置。
55.在一个实施例中，可以由所述前端组件基于所述异常生成异常信息，基于双向通信信道向原生端组件发送所述异常信息。具体地，所述双向通信信道可以是jsbridge。
56.在另一个实施例中，所述获取所述前端组件产生的异常信息，如图3所示，包括：
57.s1011.设置监控线程。
58.s1013.基于所述监控线程捕获异常信息，所述异常信息由所述前端组件基于所述异常生成并抛出。
59.s103.若启动自修复机制修复所述异常，则读取所述异常位置信息指向的目标文件。
60.在一个实施例中，所述自修复机制可以被选择性触发，当所述自修复机制被配置为开启时，可以基于所述自修复机制修复异常，即执行本发明实施例所述的应用程序自修复方法，若所述自修复机制被配置为关闭，则不基于所述自修复机制修复所述异常。在一个可选的实施例中，在所述自修复机制被配置为关闭时，可以由所述原生端组件将所述异常信息上传至服务器，以便于所述服务器基于热更新方法修复所述应用程序。
61.在另一个实施例中，异常类型也可以被选择性设定，只有有限的异常类型可以被设定为支持自修复，只有被设定为支持自修复的异常类型才可以基于本发明实施例的应用程序自修复方法进行修复。
62.在一个实施例中，所述自修复机制的选择性触发可以在第二预设模板进行配置，所述异常类型可以在第三预设模板配置，所述第二预设模板、第三预设模板和所述第一预设模板可以合并。所述第一预设模板、第二预设模板、第三预设模板均可以通过配置表的形式进行记录，所述配置表可以由服务器下发并存储在智能终端本地，所述配置表可以基于map形式进行数据组织，map可以被理解为一种字典数据结构。
63.具体地，在步骤s103之前，如图4所示，还包括：
64.s1.在第二预设模板中判断是否启动自修复机制；
65.s3.若是，则判断所述异常类型信息指向的异常类型是否在第三预设模板中被配置为支持自修复；
66.s5.若是，则判定启动自修复机制修复所述异常。
67.若被判定为不启动自修复机制修复所述异常，则由所述原生端组件将所述异常信息上传至服务器，以便于所述服务器基于热更新方法修复所述应用程序。
68.在一个实施例中，所述读取所述异常位置信息指向的目标文件，包括：
69.s10.根据所述异常位置信息找到资源目录下发生异常的目标文件。
70.s30.对所述目标文件进行文件流读操作，将所述目标文件加载于内存。
71.在一个实施例中，可以通过bundle进行前端组件相关的资源的组织，目标文件以及后续的补丁文件都可以基于bundle形式进行组织。
72.s105.根据所述异常类型信息获得对应的语法分析匹配器。
73.本发明实施例中可以为不同的异常类型配置适配的语法分析匹配器，若所述异常类型为边界溢出异常，则为其获得用于分析边界问题的语法分析匹配器；若所述异常类型为编码不规范异常，则为其获得用于分析编码规范的语法分析匹配器。
74.s107.基于所述语法分析匹配器和所述异常位置信息对所述目标文件进行分析，得到目标异常代码段。
75.具体地，所述基于所述语法分析匹配器和所述异常位置信息对所述目标文件进行分析，得到目标异常代码段，如图5所示，包括：
76.s1071.根据所述异常位置信息确定分析的起始位置。
77.具体地，所述起始位置可以是所述异常位置信息中行列号指向的位置。
78.s1073.调用所述语法分析匹配器，以所述起始位置为起点向前进行第一匹配，向后进行第二匹配。
79.具体地，所述第一匹配和所述第二匹配可以先后执行也可以同时执行，本发明实施例对于执行顺序不进行限定。
80.具体地，所述第一匹配和第二匹配的匹配方法相同，不同之处在于匹配方向，第一匹配用于对位于起始位置之前的代码进行语法分析，第二匹配用于对起始位置之后的代码进行语法分析。
81.具体地，所述第一匹配如图6所示，包括：
82.s10731.根据所述语法分析匹配器获取匹配步长。
83.对于不同的语法分析匹配器，其匹配步长可以不同，这也体现了不同的异常类型的分析粒度是不同的。
84.s10733.初始化当前起始位置为所述起始位置。
85.s10735.根据所述当前起始位置和所述匹配步长确定匹配区间，并且所述当前起始位置为所述匹配区间的右边界。
86.在一个实施例中，若所述当前起始位置接近所述目标文件的起始位置时，则所述当前起始位置与所述目标文件的起始位置的距离可能小于所述匹配区间，这种情况下直接将所述当前起始位置与所述目标文件的起始位置之间的距离确定为匹配区间。
87.s10737.基于所述语法分析匹配器对所述目标文件位于所述匹配区间的当前代码段进行匹配分析，确定所述当前代码段是否为异常代码段。
88.具体地，可以将所述当前代码段的代码与所述语法分析匹配器中的分析规则进行匹配。
89.s10739.判断所述当前代码段是否覆盖所述目标文件的起始位置，若否，则根据所述当前代码段更新所述当前起始位置，重复执行步骤s10735。
90.具体地，所述判断所述当前代码段是否覆盖所述目标文件的起始位置可以为：判断所述当前代码段的左边界是否为所述目标文件的起始位置，若是，则表征第一匹配结束。
91.所述根据所述当前代码段更新所述当前起始位置为：将所述当前代码段的左边界确定为更新后的所述当前起始位置。
92.s1075.将第一匹配中被判定为异常代码段的代码和第二匹配中被判定为异常代码段的代码的并集确定为目标异常代码段。
93.s109.根据所述异常类型信息修复所述目标异常代码段，得到补丁文件。
94.在一个实施例中，为了提升应用程序的安全性，还可以对补丁文件进行混淆处理，得到更为安全的补丁文件，并根据混淆后的补丁文件进行后续的修复，上传服务器等操作。是否混淆所述补丁文件可以在第四预设模板中被配置，所述第四预设模板也可以与所述第一预设模板、第二预设模板和/或第三预设模板进行合并。
95.具体地，可以根据不同的异常类型信息选择不同的修复策略来对目标异常代码段进行修复，所述修复策略可以是删除，增加非空检测以及异常内部捕获，所述非空检测可以根据检测结果进行处理，从而可以避免由于空指针或者空数据导致的异常；所述异常内部捕获可以捕获异常进行处理，从而可以避免前端组件运行时产生这类异常导致的崩溃。
96.具体地，所述根据所述异常类型信息修复所述目标异常代码段，得到补丁文件，如
图7所示，包括：
97.s1091.根据所述异常类型信息修复所述目标异常代码段得到补丁代码段；
98.s1093.以文件流格式进行写操作，将所述补丁代码段写入目标存储位置；
99.s1095.根据所述所述目标存储位置的补丁代码段生成补丁文件。
100.s1011.基于所述补丁文件修复所述前端组件。
101.具体地，所述基于所述补丁文件修复所述前端组件，如图8所示，包括：
102.s10111.重新载入前端组件对应的文件，载入所述补丁文件。
103.具体地，可以将所述补丁文件置于所述前端组件对应文件的目录中，由所述原生端组件将所述目录下的全部文件一起载入，前端组件运行机制决定所述补丁文件可以替换掉前端组件相关的文件中与所述补丁文件相对应的代码，从而成功在所述前端组件中打入补丁。
104.s10113.根据载入结果启动前端组件。
105.若所述前端组件被成功启动，则补丁生效，还可以将所述补丁文件上传至服务器，以使得服务器将所述补丁文件下发至其它智能终端，为所述其它智能终端的前端组件进行热更新。
106.本发明实施例提供的是一种自修复方法，这种修复方法并不依赖于人工进行代码分析，代码修复和代码校验，因此不排除存在修复失败的情况，为了提升自修复的鲁棒性，在一个实施例中，在所述基于所述补丁文件修复所述前端组件之后，还包括：
107.若所述前端组件无法正常启动，则进行启动失败处理。
108.具体地，所述进行启动失败处理，如图9所示，包括：
109.s201.获取启动失败信息。
110.s203.分析所述启动失败信息中的堆栈信息，根据分析的结果判断加载的文件是否存在格式内容错误。
111.s205.若存在，则确定出现格式内容错误的文件。
112.s207.若所述文件为所述补丁文件，则删除所述补丁文件。
113.具体地，所述确定出现格式内容错误的文件可以为：提取出现格式内容错误的文件的名称；相应的，判断所述名称与所述补丁文件的名称是否相同，若相同，则判定所述文件为补丁文件。
114.在一个实施例中，删除所述补丁文件后，可以重新载入前端组件对应的各个文件，以便于重新运行前端组件。
115.既然前端组件无法正常启动，就需要依赖于服务器进行热更新，因此，在一个实施例中，还包括若所述前端组件无法正常启动，则向服务器上报启动失败信息的步骤，以便于服务器通过热更新实现对于前端组件的修复。
116.请参考图10，其示出了现有技术中热更新的产品界面示意图。请参考图11，其示出了本发明实施例对应的产品界面示意图。由图10可知，现有技术需要在联网条件下下载来自服务器的补丁文件后才能够进行热更新，图11中本发明实施例可以在智能终端本地离线自行修复前端组件。
117.本发明实施例公开了一种应用程序自修复方法，当应用程序前端组件发生异常时，可以由所述应用程序的原生端组件自动对前端组件进行异常定位和异常修正，并且以
补丁文件的形式进行前端组件的修复，这个过程并不需要人工参与，可以全自动实施，并且并不强制需要与服务器进行交互，可以显著提升修复速度，降低人力成本和通信成本。事实上，现有技术中的热更新技术的耗时较长，而本发明的自修复方法可以直接将修复速度限定在秒级，对于时间的节省作用是十分明显的。
118.本发明实施例还提供一种应用程序自修复装置，所述应用程序包括前端组件和原生端组件，如图12所示，所述装置包括：
119.异常信息捕获模块301，用于获取所述前端组件产生的异常信息，所述异常信息包括异常类型信息和异常位置信息。
120.目标文件读取模块303，用于若启动自修复机制修复所述异常，则读取所述异常位置信息指向的目标文件。
121.语法分析匹配器获取模块305，用于根据所述异常类型信息获得对应的语法分析匹配器。
122.目标异常代码段定位模块307，用于基于所述语法分析匹配器和所述异常位置信息对所述目标文件进行分析，得到目标异常代码段。
123.补丁文件生成模块309，用于根据所述异常类型信息修复所述目标异常代码段，得到补丁文件。
124.修复模块3011，用于基于所述补丁文件修复所述前端组件。
125.具体地，所述目标异常代码段定位模块307，包括：
126.起始位置确定单元，用于根据所述异常位置信息确定分析的起始位置；
127.匹配单元，用于调用所述语法分析匹配器，以所述起始位置为起点向前进行第一匹配，向后进行第二匹配；
128.目标异常代码段确定单元，用于将第一匹配中被判定为异常代码段的代码和第二匹配中被判定为异常代码段的代码的并集确定为目标异常代码段。
129.其中，所述匹配单元包括第一匹配单元和第二匹配单元，所述第一匹配单元和所述第二匹配单元具备相似逻辑结构，以第一匹配单元为例，所述第一匹配单元包括：
130.匹配步长确定单元，用于根据所述语法分析匹配器获取匹配步长；
131.当前起始位置初始化单元，用于初始化当前起始位置为所述起始位置；
132.匹配区间区间确定单元，用于根据所述当前起始位置和所述匹配步长确定匹配区间，并且所述当前起始位置为所述匹配区间的右边界；
133.匹配分析单元，用于基于所述语法分析匹配器对所述目标文件位于所述匹配区间的当前代码段进行匹配分析，确定所述当前代码段是否为异常代码段；
134.流程控制单元，用于判断所述当前代码段是否覆盖所述目标文件的起始位置，若否，则根据所述当前代码段更新所述当前起始位置，重新调用匹配区间区间确定单元。
135.本发明实施例所公开的一种应用程序自修复装置，与方法实施例基于相同的发明构思，再此不再赘述。
136.本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质可以存储有多条指令。所述指令可以适于由处理器加载并执行本发明实施例所述的一种应用程序自修复方法，所述方法至少包括下述步骤：
137.一种应用程序自修复方法，所述应用程序包括前端组件和原生端组件，所述方法
应用于所述原生端组件，所述方法包括：
138.若前端组件运行出现异常，获取所述前端组件产生的异常信息，所述异常信息包括异常类型信息和异常位置信息；
139.若启动自修复机制修复所述异常，则读取所述异常位置信息指向的目标文件；
140.根据所述异常类型信息获得对应的语法分析匹配器；
141.基于所述语法分析匹配器和所述异常位置信息对所述目标文件进行分析，得到目标异常代码段；
142.根据所述异常类型信息修复所述目标异常代码段，得到补丁文件；
143.基于所述补丁文件修复所述前端组件。
144.进一步地，图13示出了一种用于实现本发明实施例所提供的方法的设备的硬件结构示意图，所述设备可以参与构成或包含本发明实施例所提供的装置或系统。如图13所示，设备10可以包括一个或多个(图中采用102a、102b，
……
，102n来示出)处理器102(处理器102可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图13所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，设备10还可包括比图13中所示更多或者更少的组件，或者具有与图13所示不同的配置。
145.应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到设备10(或移动设备)中的其他元件中的任意一个内。如本技术实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
146.存储器104可用于存储应用软件的软件程序以及模块，如本发明实施例中所述的方法对应的程序指令/数据存储装置，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种应用程序自修复方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至设备10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
147.传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。
148.显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与设备10(或移动设备)的用户界面进行交互。
149.需要说明的是：上述本发明实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一
些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
150.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和服务器实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
151.本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
152.以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。