本发明涉及软件技术领域，更具体的说，是涉及一种应用程序的热修复方法及装置。
背景技术：
应用app在正式发布后，往往会出现存在bug(软件缺陷)或版本升级的情况。针对这些情况，app的开发运营商采用的常规解决方法是重新编译相关代码，并经过代码测试后重新发布；app用户终端也需要重新下载bug修复内容或app最新版本，并在下载完成后重启甚至重新安装app应用。这种软件更新或bug修复的方法过程复杂，成本高且用户体验不好，因此近些年出现了应用程序的热修复方案。
热修复是一种无须重新安装app，在应用运行时便能实现bug修复和应用升级功能的新技术。现有的热修复技术中，存在一种类加载器hook技术，该技术基于dex分包方案实现，具体过程是在app启动时将已修复的java类插入到dex加载数组的最前面，使得app加载已修复的java类数据，从而直接运行修复版本或升级版本。然而，这种热修复方法实现bug修复或版本升级需要重启app，这个过程将大大影响用户的使用体验。
技术实现要素：
有鉴于此，本发明提供了一种应用程序的热修复方法及装置，以实现在无需重启app的前提下完成app的bug修复及版本升级，提升用户的使用体验。
一种应用程序的热修复方法，包括：
在app运行过程中，若确定服务器存在插件更新包，下载所述插件更新包并存储至本地；
若检测到插件进程中的应用程序页面满足预设条件，则退出所述插件进程，所述插件进程为独立进程；
接收重启所述插件进程的控制信号，并根据所述控制信号控制重启所述插件进程；
在重启所述插件进程的过程中，将所述插件更新包插入所述插件进程的加载器文件中，以使得所述插件进程加载所述插件更新包。
可选的，还包括：
注册插件服务，所述插件服务运行在插件进程中；
将所有支持热修复的业务组件注册到所述插件进程中。
可选的，还包括：
启动app时，启动插件进程并加载插件模块文件，所述插件模块文件包括类文件和资源文件；
控制所述app的主进程绑定所述插件服务，以使得所述插件进程退出时，自动生成重启所述插件进程的控制信号，并在插件进程重启后自动完成所述主进程与所述插件服务的绑定。
可选的，所述插件更新包包括dex包，所述dex包中包括修复完成的类文件，所述加载器包括类加载器，则所述将所述插件更新包插入所述插件进程的加载器文件中，包括：
将所述插件更新包插入所述插件进程的类加载器的dex数组中。
可选的，所述预设条件包括插件进程中的应用程序页面切入后台和/或插件进程中不包含应用程序页面，则所述若检测到插件进程中的应用程序页面满足预设条件，则退出所述插件进程，包括：
若检测到插件进程中的应用程序页面切入后台或插件进程中不包括应用程序页面，则退出所述插件进程。
一种应用程序的热修复装置，包括：
数据下载模块，用于在app运行过程中，确定服务器存在插件更新包的情况下，下载所述插件更新包并存储至本地；
进程退出模块，用于在插件进程中的应用程序页面满足预设条件的情况下，退出所述插件进程，所述插件进程为独立进程；
进程重启控制模块，用于接收重启所述插件进程的控制信号，并根据所述控制信号控制重启所述插件进程；
更新加载模块，用于在重启所述插件进程的过程中，将所述插件更新包插入所述插件进程的加载器文件中，以使得所述插件进程加载所述插件更新包。
可选的，还包括：
服务注册模块，用于注册插件服务，所述插件服务运行在插件进程中；
组件注册模块，用于将所有支持热修复的业务组件注册到所述插件进程中。
可选的，还包括：
进程启动加载模块，用于启动app时，启动插件进程并加载插件模块文件，所述插件模块文件包括类文件和资源文件；
进程绑定模块，用于控制所述app的主进程绑定所述插件服务，以使得所述插件进程退出时，自动生成启动所述插件进程的控制信号，并在插件进程重启后自动完成所述主进程与所述插件服务的绑定。
可选的，所述插件更新包包括dex包，所述dex包中包括修复完成的类文件，所述加载器包括类加载器，则所述更新加载模块具体用于：
将所述插件更新包插入所述插件进程的类加载器的dex数组中。
可选的，所述预设条件包括插件进程中的应用程序页面切入后台和/或插件进程中不包含应用程序页面，则所述进程退出模块具体用于：
在检测到插件进程中的应用程序页面切入后台或插件进程中不包括应用程序页面的情况下，退出所述插件进程。
本发明实施例公开了一种应用程序的热修复方法及装置，方法包括：在app运行过程中，若确定服务器存在插件更新包，下载所述插件更新包并存储在本地，在检测到插件进程中的应用程序页面满足预设条件，退出所述插件进程，所述插件进程为独立进程，接收重启所述插件进程的控制信号，并根据所述控制信号控制重启所述插件进程，在重启所述插件进程的过程中，将所述插件更新包插入插件进程的加载器文件中，以加载所述加载器文件中的插件更新包。该应用程序的热修复方法及装置采用多进程方式来实现应用程序的热修复，将所有可能需要修复改变的业务组件隔离在一个不影响主进程运行的独立进程，也即插件进程中，从更新包的下载到插件进程的退出、重启并加载更新包的整个过程不需要app重启，在用户无感知的情况下即可完成热修复，极大程度的提升了用户的使用体验。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本发明实施例公开的第一种应用程序的热修复方法的流程图；
图2为本发明实施例公开的第二种应用程序的热修复方法的流程图；
图3为本发明实施例公开的第三种应用程序的热修复方法的流程图；
图4为本发明实施例公开的第一种应用程序的热修复装置的结构示意图；
图5为本发明实施例公开的第二种应用程序的热修复装置的结构示意图；
图6为本发明实施例公开的第三种应用程序的热修复装置的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1为本发明实施例公开的第一种应用程序的热修复方法的流程图，参见图1所示，该方法可以包括：
步骤101：在app运行过程中，若确定服务器存在插件更新包，下载所述插件更新包并存储至本地。
本实施例公开的应用程序的热修复方法，可以在app运行过程中直接执行，且过程中不需要app重启。其中，确定服务器存在插件更新包的具体实现可以有多种方式，如，在服务器有插件更新包时，服务器可以直接将存在插件更新包的消息推送给app，或者所述app根据预设周期自动询问服务器是否存在插件更新包。
在确定所述服务器中存在插件更新包的情况下，下载所述插件更新包，以便于后续根据搜书插件更新包执行相应的热修复操作。
步骤102：若检测到插件进程中的应用程序页面满足预设条件，退出所述插件进程。
其中，所述插件进程为独立进程，和app的主进程运行在不同的进程中。
在下载完所述插件更新包后，可以退出所述插件进程并重启加载所述插件更新包，以使用户及时体验修复完相应bug或更新版本的应用服务。为了保证用户的使用体验，使用户对热更新的过程无感知，本实施例中，在插件进程中的应用程序页面满足预设条件的情况下，才会退出所述插件进程。
本实施例中，所述预设条件可以包括：插件进程中的应用程序页面切入后台和/或插件进程中不包含应用程序页面。则所述若检测到插件进程中的应用程序页面满足预设条件，则退出所述插件进程，可以包括：若检测到插件进程中的应用程序页面切入后台或插件进程中不包含应用程序页面，则退出所述插件进程。例如，用户在玩一个应用游戏，由于其他因素将游戏暂停，并切换到其他应用，如接收到通讯应用消息，并点击打开应用消息，此时，显示屏上原本显示的游戏页面切换至通讯应用消息页面，此时即所述插件进程的应用程序页面切入后台。在上述情况发生或者在所述插件进程中不存在应用程序页面的情况下，可以执行退出插件进程的操作，以保证用户不会感觉正在使用的应用中某种业务或功能突然中断。
步骤103：接收重启所述插件进程的控制信号，并根据所述控制信号控制重启所述插件进程。
可以通过设置相应的程序控制或采用特定方法，在所述插件进程退出后，立即控制所述插件进程重启，以保证插件进程退出到重启过程不会太长，尽早完成热更新，不影响用户的正常使用。
步骤104：在重启所述插件进程的过程中，将所述插件更新包插入所述插件进程的加载器文件中，以使得所述插件进程加载所述插件更新包。
由于本发明实施例实现应用程序的热更新通过插件进程来实现，因此，所述插件更新包需要插入到所述插件进程的加载器文件中。
在一个示例中，所述插件更新包中包含dex包，所述dex包中包括已修复完成的类文件，所述加载器包括类加载器，则所述将所述插件更新包插入所述插件进程的加载器文件中，可以包括：将所述插件更新包中的dex包插入到所述插件进程的类加载器的dex数组中。
具体地，所述插件更新包可以基于安卓dex分包方案实现，将修复后或修改后的程序文件中的类抽取出来，打包成单独的热修复dex包，在热更新时，将所述热修复dex包合入所述插件进程类加载器的dex数组中。上述热更新方式为差量更新，由于数据量比较小，实现起来简便快捷。
当然，不采用从已修复程序文件中抽取类的方式，直接使用完整版本的插件更新包也可以实现相应的应用程序热修复，这种热修复为全量更新，数据量相对较大，实现起来相对较慢。
所述插件进程在重启时会加载所述插件更新包，所述插件更新包中可以包括类文件和资源文件，加载完成后，当app主进程再使用插件资源，或调用插件的业务逻辑时，使用的既是热修复后的版本。这样，app插件进程的重启对用户来说是无感知的，在不影响app主进程的情况下，插件模块在后台即实现的修复更新。
本实施例中应用程序的热修复方法采用多进程方式来实现应用程序的热修复，将所有可能需要修复改变的业务组件隔离在一个不影响主进程运行的独立进程，也即插件进程中，从更新包的下载到插件进程的退出、重启并加载更新包的整个过程不需要app重启，在用户无感知的情况下即可完成热修复，极大程度的提升了用户的使用体验。
图2为本发明实施例公开的第二种应用程序的热修复方法的流程图，如图2所示，所述方法可以包括：
步骤201：注册插件服务，所述插件服务运行在插件进程中。
其中，所述插件进程为独立进程。
本实施例中，可以在宿主的配置文件中注册一个“插件服务”，并设置为独立进程，宿主与插件的所有联系都将通过所述插件服务来分发。
步骤202：将所有支持热修复的业务组件注册到所述插件进程中。
在插件模块中实现上述插件服务，并将所有需要热更新、热修复的业务组件，都注册到与插件服务相同的进程中。因为这些业务组件后期可能需要更新或升级，而本申请的目的是实现热更新，即更新过程用户无感知，本申请是通过将需要更新的进程配置为一个独立于主进程的独立进程实现的，因此，所有需要热更新或修复的业务组件必须注册到这个独立进程中，即插件服务的进程中，才能够实现后续更新时的热更新。
步骤203：在app运行过程中，若确定服务器存在插件更新包，下载所述插件更新包并存储至本地。
步骤204：若检测到插件进程中的应用程序页面满足预设条件，则退出所述插件进程。
其中，所述插件进程为独立进程。
步骤205：接收重启所述插件进程的控制信号，并根据所述控制信号控制重启所述插件进程。
步骤206：在重启所述插件进程的过程中，将所述插件更新包插入所述插件进程的加载器文件中，以使得所述插件进程加载所述插件更新包。
本实施例中，在app运行之前，预先注册了运行在独立进程的插件服务，这样，宿主与插件的所有联系都将通过所述插件服务来分发，而后将需要热修复或热更新的业务组件都注册到所述插件进程中，保证后续热修复进程只在所述插件进程中进行，而不影响app主进程。从而热修复过程不需要重启app，且对用户来说无感知，用户体验大大提升。
图3为本发明实施例公开的第三种应用程序的热修复方法的流程图，，如图3所示，所述方法可以包括：
步骤301：注册插件服务，所述插件服务运行在插件进程中。
其中，所述插件进程为独立进程。
步骤302：将所有支持热修复的业务组件注册到所述插件进程中。
步骤303：启动app时，启动插件进程并加载插件模块文件。
其中，所述插件模块文件包括类文件和资源文件。所述插件模块为需要热更新或需要修复的业务模块。
在app应用启动时，在androidapplication组件中，可以区分主进程与插件进程。当启动的进程为插件进程时，加载(初始化)热修复逻辑，并加载插件模块文件中的类文件和资源文件。
步骤304：控制所述app的主进程绑定所述插件服务。
所述app的主进程绑定所述插件服务后，后续在所述插件进程退出时，系统会自动生成重启所述插件进程的控制信号，并在插件进程重启后自动完成所述主进程与所述插件服务的绑定。
具体地，主进程与插件进程绑定成功后，重启插件进程的一种实现方式可以是：若所述插件进程在热修复时退出，android系统会自动重新启动所述插件进程。另外一种实现方式可以是：主进程监听插件服务的服务断开监听接口，若监听到所述插件进程退出，控制重新启动并自动绑定插件服务。
步骤305：在app运行过程中，若确定服务器存在插件更新包，下载所述插件更新包并存储至本地。
步骤306：若检测到插件进程中的应用程序页面满足预设条件，则退出所述插件进程。
所述插件进程为独立进程。
步骤307：接收重启所述插件进程的控制信号，并根据所述控制信号控制重启所述插件进程。
步骤308：在重启所述插件进程的过程中，将所述插件更新包插入所述插件进程的加载器文件中，以使得所述插件进程加载所述加载器文件中的插件更新包。
本实施例中，所述应用程序的热修复方法在注册插件服务并实现插件进程后，在主进程和插件进程都启动后，将主进程与插件进程绑定，实现了在插件进程热修复自动退出时，迅速控制重启插件进程，并加载热修复更新包，以迅速完成热修复，达到用户无感知的热修复体验效果。
图4为本发明实施例公开的第一种应用程序的热修复装置的结构示意图，参见图1所示，所述应用程序的热修复装置40可以包括：
数据下载模块401，用于在app运行过程中，确定服务器存在插件更新包的情况下，下载所述插件更新包并存储至本地。
本实施例公开的应用程序的热修复装置，可以在app运行过程中直接执行，且过程中不需要app重启。其中，确定服务器存在插件更新包的具体实现可以有多种方式，如，在服务器有插件更新包时，服务器可以直接将存在插件更新包的消息推送给app，或者所述app根据预设周期自动询问服务器是否存在插件更新包。
在确定所述服务器中存在插件更新包的情况下，下载所述插件更新包，以便于后续根据搜书插件更新包执行相应的热修复操作。
进程退出模块402，用于在插件进程中的应用程序页面满足预设条件的情况下，退出所述插件进程。
其中，所述插件进程为独立进程，和app的主进程运行在不同的进程中。
在下载完所述插件更新包后，可以退出所述插件进程并重启加载所述插件更新包，以使用户及时体验修复完相应bug或更新版本的应用服务。为了保证用户的使用体验，使用户对热更新的过程无感知，本实施例中，在插件进程中的应用程序页面满足预设条件的情况下，才会退出所述插件进程。
本实施例中，所述预设条件可以包括：插件进程中的应用程序页面切入后台和/或插件进程中不包含应用程序页面。则所述进程退出模块403具体可以用于：在检测到插件进程中的应用程序页面切入后台或插件进程中不包含应用程序页面的情况下，退出所述插件进程。例如，用户在玩一个应用游戏，由于其他因素将游戏暂停，并切换到其他应用，如接收到通讯应用消息，并点击打开应用消息，此时，显示屏上原本显示的游戏页面切换至通讯应用消息页面，此时即所述插件进程的应用程序页面切入后台。在上述情况发生或者在所述插件进程中不存在应用程序页面的情况下，可以执行退出插件进程的操作，以保证用户不会感觉正在使用的应用中某种业务或功能突然中断。
进程重启控制模块403，用于接收重启所述插件进程的控制信号，并根据所述控制信号控制重启所述插件进程。
可以通过设置相应的程序控制或采用特定方法，在所述插件进程退出后，立即控制所述插件进程重启，以保证插件进程退出到重启过程不会太长，尽早完成热更新，不影响用户的正常使用。
更新加载模块404，用于在重启所述插件进程的过程中，将所述插件更新包插入所述插件进程的加载器文件中，以使得所述插件进程加载所述插件更新包。
由于本发明实施例实现应用程序的热更新通过插件进程来实现，因此，所述插件更新包需要存储在所述插件进程的加载器文件中。
在一个示例中，所述插件更新包为dex包，所述dex包中包括已修复完成的类文件，所述加载器包括类加载器，则所述数据存储模块402具体可以用于：将所述插件更新包中的dex包插入到插件进程的类加载器的dex数组中。
具体地，所述插件更新包可以基于安卓dex分包方案实现，将修复后或修改后的程序文件中的类抽取出来，打包成单独的热修复dex包，在热更新时，将所述热修复dex包合入所述插件进程类加载器的dex数组中。上述热更新方式为差量更新，由于数据量比较小，实现起来简便快捷。
当然，不采用从已修复程序文件中抽取类的方式，直接使用完整版本的插件更新包也可以实现相应的应用程序热修复，这种热修复为全量更新，数据量相对较大，实现起来相对较慢。
所述插件进程在重启时会加载所述插件更新包，所述插件更新包中可以包括类文件和资源文件，加载完成后，当app主进程再使用插件资源，或调用插件的业务逻辑时，使用的既是热修复后的版本。这样，app插件进程的重启对用户来说是无感知的，在不影响app主进程的情况下，插件模块在后台即实现的修复更新。
本实施例中应用程序的热修复装置采用多进程方式来实现应用程序的热修复，将所有可能需要修复改变的业务组件隔离在一个不影响主进程运行的独立进程，也即插件进程中，从更新包的下载到插件进程的退出、重启并加载更新包的整个过程不需要app重启，在用户无感知的情况下即可完成热修复，极大程度的提升了用户的使用体验。
图5为本发明实施例公开的第二种应用程序的热修复装置的结构示意图，如图5所示，所述应用程序的热修复装置50可以包括：
服务注册模块501，用于注册插件服务，所述插件服务运行在插件进程中。
其中，所述插件进程为独立进程。
本实施例中，可以在宿主的配置文件中注册一个“插件服务”，并设置为独立进程，宿主与插件的所有联系都将通过所述插件服务来分发。
组件注册模块502，用于将所有支持热修复的业务组件注册到所述插件进程中。
在插件模块中实现上述插件服务，并将所有需要热更新、热修复的业务组件，都注册到与插件服务相同的进程中。因为这些业务组件后期可能需要更新或升级，而本申请的目的是实现热更新，即更新过程用户无感知，本申请是通过将需要更新的进程配置为一个独立于主进程的独立进程实现的，因此，所有需要热更新或修复的业务组件必须注册到这个独立进程中，即插件服务的进程中，才能够实现后续更新时的热更新。数据下载模块401，用于在app运行过程中，确定服务器存在插件更新包的情况下，下载所述插件更新包并存储至本地。
进程退出模块402，用于在插件进程中的应用程序页面满足预设条件的情况下，退出所述插件进程。
进程重启控制模块403，用于接收重启所述插件进程的控制信号，并根据所述控制信号控制重启所述插件进程。
更新加载模块404，用于在重启所述插件进程的过程中，将所述插件更新包插入所述插件进程的加载器文件中，以使得所述插件进程加载所述插件更新包。
本实施例中，在app运行之前，预先注册了运行在独立进程的插件服务，这样，宿主与插件的所有联系都将通过所述插件服务来分发，而后将需要热修复或热更新的业务组件都注册到所述插件进程中，保证后续热修复进程只在所述插件进程中进行，而不影响app主进程。从而热修复过程不需要重启app，且对用户来说无感知，用户体验大大提升。
图6为本发明实施例公开的第三种应用程序的热修复装置的结构示意图，如图6所示，所述应用程序的热修复装置60可以包括：
服务注册模块501，用于注册插件服务，所述插件服务运行在插件进程中。
其中，所述插件进程为独立进程。
组件注册模块502，用于将所有支持热修复的业务组件注册到所述插件进程中。
进程启动加载模块601，用于启动app时，启动插件进程并加载插件模块文件。
其中，所述插件模块文件包括类文件和资源文件。所述插件模块为需要热更新或日晚修复的业务模块。
在app应用启动时，在androidapplication组件中，可以区分主进程与插件进程。当启动的进程为插件进程时，加载(初始化)热修复逻辑，并加载插件模块文件中的类文件和资源文件。
进程绑定模块602，用于控制所述app的主进程绑定所述插件服务，以使得所述插件进程退出时，自动生成启动所述插件进程的控制信号，并在插件进程重启后自动完成所述主进程与所述插件服务的绑定。
所述app的主进程绑定所述插件服务后，后续在所述插件进程退出时，系统会自动生成重启所述插件进程的控制信号，并自动完成所述主进程与所述插件服务的绑定。
具体地，主进程与插件进程绑定成功后，重启插件进程的一种实现方式可以是：若所述插件进程在热修复时退出，android系统会自动重新启动所述插件进程。另外一种实现方式可以是：主进程监听插件服务的服务断开监听接口，若监听到所述插件进程退出，控制重新启动并自动绑定插件服务。
数据下载模块401，用于在app运行过程中，确定服务器存在插件更新包的情况下，下载所述插件更新包并存储至本地。
进程退出模块402，用于在插件进程中的应用程序页面满足预设条件的情况下，退出所述插件进程。
进程重启控制模块403，用于接收重启所述插件进程的控制信号，并根据所述控制信号控制重启所述插件进程。
更新加载模块404，用于在重启所述插件进程的过程中,将所述插件更新包插入所述插件进程的加载器文件中，以使得所述插件进程加载所述插件更新包。
本实施例中，所述应用程序的热修复装置在注册插件服务并实现插件进程后，在主进程和插件进程都启动后，将主进程与插件进程绑定，实现了在插件进程热修复自动退出时，迅速控制重启插件进程，并加载热修复更新包，以迅速完成热修复，达到用户无感知的热修复体验效果。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。