CN109408133A - 一种启动组件的方法和设备 - Google Patents

Abstract

本申请实施例涉及计算机技术领域，特别涉及一种启动组件的方法和设备，用以解决现有移动端插件化技术中存在的以同步方式启动Activity组件的时长如果超过系统设定时长，会引发系统无响应，导致应用崩溃的问题。本申请实施例在源触发启动组件后，拦截主线程启动组件，通过创建工作线程对组件所在的插件包进行异步安装后重新通过主线程启动组件。本申请实施例在源触发启动组件后拦截主线程启动组件，通过工作线程对组件所在的插件包进行安装由于本申请实施例将安装插件包的线程变为工作线程，从而避免由于主线程阻塞致使安装插件包的时间过长，而引发系统无响应，导致应用崩溃的情况出现。

Description

一种启动组件的方法和设备

技术领域

本申请涉及计算机技术领域，特别涉及一种启动组件的方法和设备。

背景技术

当前Android(安卓)手机应用软件发展迅速，很多大型的应用软件在业务快速发展过程中，遇到2个通用典型问题需要解决：1.单个应用程序方法数限制上限。2.应用程序更新迭代快，而发布大版本周期长，时效性差。Android插件化技术在此背景下应运而生。

Android插件化技术的工作逻辑是：

1、打包阶段生成多个插件包APK(AndroidPackage，安卓安装包)和一个主APK；

2、主APK在启动阶段初始化插件框架；

3、主APK通过Android四大基本组件(Activity(活动)，Service(服务)，BroadcastReceiver(广播接收),ContentProvider(内容提供器))调用插件包APK；

4、插件框架安装插件包APK，并执行。

当应用程序使用插件化技术时，Activity组件分布在主APK和插件包APK中，在启动插件包中的Activity组件时，虽然不同的插件框架会通过不同技术手段实现Activity组件启动，但是这些插件框架都是以同步方式启动Activity组件。

以同步方式启动Activity组件的操作是在主线程进行，此时需要安装Activity组件所在插件包APK，安装过程会涉及到文件拷贝，IO读写，Dex文件优化等，根据设备性能以及插件包文件大小不同，安装的时间也不同。目前如果主线程阻塞时间过长，即如果安装插件包未在系统设定时长内完成，会引发系统无响应，导致应用崩溃。

综上所述，目前以同步方式启动Activity组件的时长如果超过系统设定时长，会引发系统无响应，导致应用崩溃。

发明内容

本申请提供一种启动组件的方法和设备，用以解决现有技术中存在的以同步方式启动Activity组件的时长如果超过系统设定时长，会引发系统无响应，导致应用崩溃的问题。

本申请实施例提供的一种启动组件的方法，该方法包括：

在源触发启动组件后，拦截主线程启动所述组件；

通过工作线程对所述组件所在的插件包进行安装；

在所述插件包安装成功后，重新通过所述主线程启动所述组件。

本申请实施例提供的一种启动组件的设备，该设备包括：

拦截模块，用于在源触发启动组件后，拦截主线程启动所述组件；

异步安装模块，用于通过工作线程对所述组件所在的插件包进行安装；

处理模块，用于在所述插件包安装成功后，重新通过所述主线程启动所述组件。

本申请实施例在源触发启动组件后，拦截主线程启动所述组件，并通过创建工作线程对组件所在的插件包进行异步安装后重新通过主线程启动组件。由于本申请实施例将安装插件包的线程变为工作线程，从而避免由于主线程阻塞致使安装插件包的时间过长，而引发系统无响应，导致应用崩溃的情况出现。

附图说明

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

图1为本申请实施例启动组件的方法流程示意图；

图2为本申请实施例启动组件的完整方法流程示意图；

图3为本申请实施例启动组件的设备结构示意图。

具体实施方式

本申请实施例在有源触发启动组件后，拦截主线程启动所述组件，并通过工作线程对所述组件所在的插件包进行安装，之后重新通过所述主线程启动所述组件。

其中，本申请实施例的源对象是能够启动组件的对象，比如可以是Activity(活动)对象、Fragment(片段)对象、Context(上下文)对象等。

本申请实施例的组件是系统组件，以Android系统为例，组件包括Activity、Service组件、BroadcastReceiver组件和ContentProvider组件。

如果本申请实施例的源和组件都是Activity，则源的Activity和组件的Activity是不同的Activity。

本申请实施例可以应用于Android系统中，也可以应用于需要启动插件包的其他系统。

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，显然，所描述的实施例仅仅是本申请一部份实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

如图1所示，本申请实施例启动组件的方法包括：

步骤100、在源触发启动组件后，拦截主线程启动所述组件；

步骤101、通过工作线程对所述组件所在的插件包进行安装；

步骤102、在所述插件包安装成功后，重新通过主线程启动所述组件。

本申请实施例在源触发启动组件后，拦截主线程启动所述组件，并通过创建工作线程对组件所在的插件包进行异步安装后重新通过主线程启动组件。由于本申请实施例将安装插件包的线程变为工作线程，从而避免由于主线程阻塞致使安装插件包的时间过长，而引发系统无响应，导致应用崩溃的情况出现。

源触发启动组件的方式有很多，比如用户与界面UI交互时会触发启动组件，交互方式包括很多，例如点击页面图片、点击按钮、点击手机通知栏图标等。

本申请实施例在有源触发启动组件后，主线程会启动该组件。本申请实施例这时会拦截主线程启动所述组件。

在实施中，拦截主线程启动所述组件的方式有很多，比如在上层应用中，可以通过动态代理的方式拦截主线程启动组件；在底层系统中，可以通过修改android framework源码实现拦截主线程启动组件。

以本申请实施例应用于Android系统，且组件是Activity为例：

主线程在启动Activity时会调用Instrumentation(应用程序活动的监测器)中的某个方法，本申请实施例可以在Instrumentation中调用的方法前插入执行本申请实施例的代码，从而实现拦截主线程启动组件。

上面的例子是动态代理Instrumentation实现拦截主线程启动组件，在实施中还包括动态代理ActivityManagerNative实现拦截主线程启动组件。

由于本申请实施例解决的是在安装插件包过程中的问题，而不是所有的组件都在插件包中，所以在拦截主线程启动所述组件后，可以进一步判断需要启动的组件是否在插件包中，如果是，则进行后续步骤；否则触发主线程通过系统继续在主线程上执行所述组件。

本申请实施例判断需要启动的组件是否在插件包中的方式有很多，以本申请实施例应用于Android系统，且组件是Activity为例：

在应用APK打包过程中，生成了一份组件和插件包对应的配置文件，此文件被一同打入APK中。应用启动的时候会去读取解析此文件，后续启动组件时使用组件名去配置文件查找就能确定其是否存在插件包中，以及存在哪个插件包中。

由于有可能需要启动的组件所在的插件包已经安装，所以在确定需要启动的组件在插件包中后，判断需要启动的组件所在的插件包是否已经安装，如果是，则触发主线程通过系统继续在主线程上执行所述组件；否则进行后续步骤(即进行异步安装)。

本申请实施例判断需要启动的组件所在的插件包是否已经安装的方式有很多，以本申请实施例应用于Android系统，且组件是Activity为例：

应用运行过程中，插件包一旦第一次被安装过后，会在内存中保存一个对象。当再次启动组件时，如果内存中有对应的对象，就确定该组件所在插件包已安装。

在实施中，如果确定所述组件在插件包中，且所述插件包未安装，则执行本申请实施例异步安装过程。

在进行异步安装过程之前，需要创建一个工作线程，并且在主线程上注册一个监听器，该监听器的作用是检测插件包是否安装成功。

具体的异步安装过程为：

通过工作线程判断应用的安装目录中是否有所述组件所在的插件包；

如果有，则通过工作线程从所述安装目录中安装所述插件包；否则通过工作线程从所述应用的安装文件中解压所述插件包的安装包，并通过工作线程利用解压后的安装包安装所述插件包。

这里的应用为当前正在运行的应用，同时也是组件所在的应用。

以本申请实施例应用于Android系统，且组件是Activity为例：

对于Android系统的APK中会有配置文件，记录每个插件包里包含哪些activity，以及包含所有的插件包文件，这些插件包文件放在APK的安装目录(也可以称为标准目录)中。

不同的处理器架构，安装目录也不相同，比如ARM架构安装目录是armeabi，X86架构安装目录是x86。

根据该配置文件就可以找到对应的插件包以及确定安装目录中插件包的安装包，之后就可以通过安装包进行安装。

可选的，在通过工作线程对所述组件所在的插件包进行安装之后，就可以通过主线程上的监听器判断所述插件包是否安装成功。

由于各个系统版本的兼容性，以及手机厂商对系统的改动，可能会导致APK拷贝路径错误；有些应用软件故意篡改应用下的插件包，导致安全校验不通过等原因会出现安装失败的情况发生。

整个安装过程包括解压插件包、dex优化、资源注入等环节。每个环节都可能出现IO异常或者其他错误，本申请实施例可以设置一个回调函数，该函数作用是将安装过程中的失败信息返回给监听器，而监听器如果收到失败信息就可以知道安装过程中有错误。

如果安装成功，则重新通过所述主线程启动所述组件；

如果安装失败，可以按照预先的设置进行处理，比如可以将组件进行降低。

以本申请实施例应用于Android系统，且组件是Activity为例，如果插件包安装失败，可以将Activity降级到HTML(HyperText Markup Language，超文本标记语言)5。

如果本申请实施例应用于Android系统，且源是Fragment，组件是Activity，则Android系统会对组件的requestCode(请求码)值进行偏移。

在Android系统中Fragment表示Activity中的行为或用户界面部分。一个Activity中可以包括多个Fragment。

源触发启动组件时，源本身可以是Activity或Fragment。如果源是Activity，则启动组件的方式就是Activity到Activity；如果源是Fragment，则启动组件的方式就是Fragment到Activity。

requestCode作为参数用于建立源和被启动的Activity的联系。

目前对于源本身可以是Fragment，启动Activity的方式是将调用FragmentActivity中的startActivity方法，先校验requestcode，然后requestcode被偏移，最后调用父类方法启动Activity。

如果对requestCode进行校验确定requestCode被偏移过，则校验不通过，直接导致应用崩溃。

基于此，为了避免requestCode校验不通过导致应用崩溃的情况发生，本申请实施例提供了一种对requestCode进行改写和重置的方案。

具体的，若所述源是Fragment，重新通过主线程启动所述组件之前，将所述Fragment对应的requestCode当前的值作为偏移后的值，并将所述当前的值改写为初始值；

所述拦截主线程启动所述组件之后，通过工作线程对所述组件所在的插件包进行安装之前，还包括：

对所述Fragment对应的requestCode进行检测，若确定requestCode被改写，则将所述requestCode当前的值重置为所述偏移后的值。

本申请实施例在插件包安装成功后，判断requestCode当前的值是否与初始值不同，如果不同，则将所述Fragment对应的requestCode当前的值作为偏移后的值，并将所述当前的值改写为初始值。

这里可以建立初始值和偏移后的值的映射关系。

在拦截主线程启动所述组件后，判断requestCode当前的值是否被改写过。比如可以根据映射关系判断，如果根据映射关系确定requestCode当前的值(即初始值)有对应的偏移后的值，就确定requestCode当前的值被改写过。

如果确定requestCode当前的值被改写过，将所述requestCode当前的值重置为所述偏移后的值。由于在此之前FragmentActivity的startActivity已经对requestCode进行校验，所以再改写回来也不会造成应用崩溃。

本申请实施例在进行异步安装过程中，还可以向用户展示预设的提示信息，以使用户了解当前软件的工作状态。

具体的，所述拦截主线程启动所述组件之后，重新通过所述主线程启动所述组件之前，通过所述主线程显示提示信息。

这里的提示信息可以是文字、图片、动画等。比如可以在异步安装过程中向用户展示Loading(装载)页面；也可以是显示安装进度条的页面；还可以弹出一个对话框显示插件包正在安装之类的信息等。

如图2所示，本申请实施例启动组件的完整方法包括：

步骤200、确定源触发启动Activity。

步骤201、拦截主线程启动所述Activity。

步骤202、判断所述Activity的requestCode是否进行改写，如果是，则执行步骤203；否则执行步骤204。

步骤203、确定Activity的requestCode偏移后的值，并将偏移后的值作为requestCode当前的值。

步骤204、判断所述Activity是否在插件包中，如果是，则执行步骤205；否则，执行步骤214。

步骤205、判断所述Activity所在的插件包是否已安装，如果是，则执行步骤214；否则，执行步骤206。

步骤206、通过工作线程判断应用的安装目录中是否有所述组件所在的插件包；如果有，则执行步骤207；否则，执行步骤208。

步骤207、通过工作线程从所述安装目录中安装所述插件包，并执行步骤209。

步骤208、通过工作线程从所述应用的安装文件中解压所述插件包的安装包，并通过工作线程利用解压后的安装包安装所述插件包。

步骤209、判断插件包是否安装成功，如果是，则执行步骤211；否则执行步骤210。

步骤210、将Activity进行降级。

步骤211、判断源是否是Fragment，如果是，则执行步骤212；否则，执行步骤213。

步骤212、将所述Fragment对应的requestCode当前的值作为偏移后的值，建立初始值和偏移后的值的映射关系，并将所述当前的值改写为初始值。

步骤213、再次启动Activity，并返回步骤201。

步骤214、通过系统继续在主线程上执行所述组件。

基于同一发明构思，本申请实施例中还提供了一种启动组件的设备，由于该设备解决问题的原理与本申请实施例启动组件的方法相似，因此该设备的实施可以参见方法的实施，重复之处不再赘述。

如图3所示，本申请实施例启动组件的设备包括：

拦截模块300，用于在源触发启动组件后，拦截主线程启动所述组件；

异步安装模块301，用于通过工作线程对所述组件所在的插件包进行安装；

处理模块302，用于在所述插件包安装成功后，重新通过所述主线程启动所述组件。

本申请实施例在源触发启动组件后，拦截主线程启动所述组件，并通过创建工作线程对组件所在的插件包进行异步安装后重新通过主线程启动组件。由于本申请实施例将安装插件包的线程变为工作线程，从而避免由于主线程阻塞致使安装插件包的时间过长，而引发系统无响应，导致应用崩溃的情况出现。

源触发启动组件的方式有很多，比如用户与界面UI交互时会触发启动组件，交互方式包括很多，例如点击页面图片、点击按钮、点击手机通知栏图标等。

本申请实施例在有源触发启动组件后，主线程会启动该组件。本申请实施例这时拦截模块300会拦截主线程启动所述组件。

在实施中，拦截主线程启动所述组件的方式有很多，比如在上层应用中，可以通过动态代理的方式拦截主线程启动组件；在底层系统中，可以通过修改android framework源码实现拦截主线程启动组件。

以本申请实施例应用于Android系统，且组件是Activity为例：

主线程在启动Activity时会调用Instrumentation中的某个方法，本申请实施例可以在Instrumentation中调用的方法前插入执行本申请实施例的代码，从而实现拦截主线程启动组件。

上面的例子是动态代理Instrumentation实现拦截主线程启动组件，在实施中还包括动态代理ActivityManagerNative实现拦截主线程启动组件。

由于本申请实施例解决的是在安装插件包过程中的问题，而不是所有的组件都在插件包中，所以在拦截主线程启动所述组件后，异步安装模块301可以进一步判断需要启动的组件是否在插件包中，如果是，则进行后续步骤；否则触发主线程通过系统继续在主线程上执行所述组件。

本申请实施例判断需要启动的组件是否在插件包中的方式有很多，以本申请实施例应用于Android系统，且组件是Activity为例：

在应用APK打包过程中，生成了一份组件和插件包对应的配置文件，此文件被一同打入APK中。应用启动的时候会去读取解析此文件，后续启动组件时使用组件名去配置文件查找就能确定其是否存在插件包中，以及存在哪个插件包中.。

由于有可能需要启动的组件所在的插件包已经安装，所以在确定需要启动的组件在插件包中后，异步安装模块301判断需要启动的组件所在的插件包是否已经安装，如果是，则触发主线程通过系统继续在主线程上执行所述组件；否则进行后续步骤(即进行异步安装)。

本申请实施例判断需要启动的组件所在的插件包是否已经安装的方式有很多，以本申请实施例应用于Android系统，且组件是Activity为例：

应用运行过程中，插件包一旦第一次被安装过后，会在内存中保存一个对象。当再次启动组件时，如果内存中有对应的对象，就确定该组件所在插件包已安装。

在实施中，如果确定所述组件在插件包中，且所述插件包未安装，则异步安装模块301执行本申请实施例异步安装过程。

在进行异步安装过程之前，处理模块302需要创建一个工作线程，并且在主线程上注册一个监听器，该监听器的作用是检测插件包是否安装成功。

具体的异步安装过程为：

异步安装模块301通过工作线程判断应用的安装目录中是否有所述组件所在的插件包；

如果有，则通过工作线程从所述安装目录中安装所述插件包；否则通过工作线程从所述应用的安装文件中解压所述插件包的安装包，并通过工作线程利用解压后的安装包安装所述插件包。

这里的应用为当前正在运行的应用，同时也是组件所在的应用。

以本申请实施例应用于Android系统，且组件是Activity为例：

对于Android系统的APK中会有配置文件，记录每个插件包里包含哪些activity，以及包含所有的插件包文件，这些插件包文件放在APK的安装目录(也可以称为标准目录)中。

不同的处理器架构，安装目录也不相同，比如ARM架构安装目录是armeabi，X86架构安装目录是x86。根据该配置文件就可以找到对应的插件包以及确定安装目录中插件包的安装包，之后就可以通过安装包进行安装。

可选的，在通过工作线程对所述组件所在的插件包进行安装之后，处理模块302就可以通过主线程上的监听器判断所述插件包是否安装成功。

由于各个系统版本的兼容性，以及手机厂商对系统的改动，可能会导致APK拷贝路径错误；有些应用软件故意篡改应用下的插件包，导致安全校验不通过等原因会出现安装失败的情况发生。

整个安装过程包括解压插件包、dex优化、资源注入等环节。每个环节都可能出现IO异常或者其他错误，本申请实施例可以设置一个回调函数，该函数作用是将安装过程中的失败信息返回给监听器，而监听器如果收到失败信息就可以知道安装过程中有错误。

如果安装成功，则重新通过所述主线程启动所述组件；

如果安装失败，可以按照预先的设置进行处理，比如可以将组件进行降低。

以本申请实施例应用于Android系统，且组件是Activity为例，如果插件包安装失败，可以将Activity降级到HTML(HyperText Markup Language，超文本标记语言)5。

如果本申请实施例应用于Android系统，且源是Fragment，组件是Activity，则Android系统会对组件的requestCode(请求码)值进行偏移。

在Android系统中Fragment表示Activity中的行为或用户界面部分。一个Activity中可以包括多个Fragment。

源触发启动组件时，源本身可以是Activity或Fragment。如果源是Activity，则启动组件的方式就是Activity到Activity；如果源是Fragment，则启动组件的方式就是Fragment到Activity。

requestCode作为参数用于建立源和被启动的Activity的联系。

目前对于源本身可以是Fragment，启动Activity的方式是将调用FragmentActivity中的startActivity方法，先校验requestcode，然后requestcode被偏移，最后调用父类方法启动Activity。

如果对requestCode进行校验确定requestCode被偏移过，则校验不通过，直接导致应用崩溃。

基于此，为了避免requestCode校验不通过导致应用崩溃的情况发生，本申请实施例提供了一种对requestCode进行改写和重置的方案。

具体的，在所述插件包安装成功后，若所述源是Fragment，所述处理模块302将所述Fragment对应的requestCode当前的值作为偏移后的值，并将所述当前的值改写为初始值，重新通过主线程启动所述组件；

所述拦截主线程启动所述组件之后，所述异步安装模块301对所述Fragment对应的requestCode进行检测，若确定requestCode被改写，则将所述requestCode当前的值重置为所述偏移后的值，并判断所述组件是否在插件包中，且所述插件包是否未安装。

本申请实施例在插件包安装成功后，处理模块302判断requestCode当前的值是否与初始值不同，如果不同，则将所述Fragment对应的requestCode当前的值作为偏移后的值，并将所述当前的值改写为初始值。

这里可以建立初始值和偏移后的值的映射关系。

在拦截主线程启动所述组件后，异步安装模块301判断requestCode当前的值是否被改写过。比如可以根据映射关系判断，如果根据映射关系确定requestCode当前的值(即初始值)有对应的偏移后的值，就确定requestCode当前的值被改写过。

如果确定requestCode当前的值被改写过，将所述requestCode当前的值重置为所述偏移后的值。由于在此之前FragmentActivity的startActivity已经对requestCode进行校验，所以再改写回来也不会造成应用崩溃。

本申请实施例在进行异步安装过程中，还可以向用户展示预设的提示信息，以使用户了解当前软件的工作状态。

具体的，拦截主线程启动所述组件之后，所述拦截模块300通过所述主线程显示提示信息。

这里的提示信息可以是文字、图片、动画等。比如可以在异步安装过程中向用户展示Loading页面；也可以是显示安装进度条的页面；还可以弹出一个对话框显示插件包正在安装之类的信息等。

以上参照示出根据本申请实施例的方法、装置(系统)和/或计算机程序产品的框图和/或流程图描述本申请。应理解，可以通过计算机程序指令来实现框图和/或流程图示图的一个块以及框图和/或流程图示图的块的组合。可以将这些计算机程序指令提供给通用计算机、专用计算机的处理器和/或其它可编程数据处理装置，以产生机器，使得经由计算机处理器和/或其它可编程数据处理装置执行的指令创建用于实现框图和/或流程图块中所指定的功能/动作的方法。

相应地，还可以用硬件和/或软件(包括固件、驻留软件、微码等)来实施本申请。更进一步地，本申请可以采取计算机可使用或计算机可读存储介质上的计算机程序产品的形式其具有在介质中实现的计算机可使用或计算机可读程序代码，以由指令执行系统来使用或结合指令执行系统而使用。在本申请上下文中，计算机可使用或计算机可读介质可以是任意介质，其可以包含、存储、通信、传输、或传送程序，以由指令执行系统、装置或设备使用，或结合指令执行系统、装置或设备使用。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (14)

1.一种启动组件的方法，其特征在于，该方法包括：

在源对象触发启动组件后，拦截主线程启动所述组件；

通过工作线程对所述组件所在的插件包进行安装；

在所述插件包安装成功后，重新通过所述主线程启动所述组件。

2.如权利要求1所述的方法，其特征在于，所述拦截主线程启动所述组件之后，还包括：

判断所述组件是否在插件包中，且所述插件包是否未安装；

若确定所述组件在插件包中，且所述插件包未安装，则通过工作线程对所述组件对应的插件包进行安装。

3.如权利要求2所述的方法，其特征在于，所述判断所述组件是否在插件包中，且所述插件包是否未安装之后，还包括：

若所述组件不在插件包中，或所述组件在插件包中但所述插件包已安装，则继续在主线程上执行所述组件。

4.如权利要求2所述的方法，其特征在于，所述在所述插件包安装成功后，重新通过所述主线程启动所述组件之前，还包括：

若所述源对象是Fragment对象，将所述Fragment对应的requestCode当前的值作为偏移后的值，并将所述当前的值改写为初始值；

所述拦截主线程启动所述组件之后，通过工作线程对所述组件所在的插件包进行安装之前，还包括：

对所述Fragment对应的requestCode进行检测，若确定requestCode被改写，则将所述requestCode当前的值重置为所述偏移后的值。

5.如权利要求1所述的方法，其特征在于，所述通过工作线程对所述组件所在的插件包进行安装，包括：

通过工作线程判断应用的安装目录中是否有所述组件所在的插件包；

如果有，则通过工作线程从所述安装目录中安装所述插件包；否则通过工作线程从所述应用的安装文件中解压所述插件包的安装包，并通过工作线程利用解压后的安装包安装所述插件包。

6.如权利要求5所述的方法，其特征在于，所述通过工作线程对所述组件所在的插件包进行安装之后，还包括：

通过主线程上的监听器判断所述插件包是否安装成功。

7.如权利要求1～5任一所述的方法，其特征在于，所述拦截主线程启动所述组件之后，重新通过所述主线程启动所述组件之前，还包括：

通过所述主线程显示提示信息。

8.一种启动组件的设备，其特征在于，该设备包括：

拦截模块，用于在源触发启动组件后，拦截主线程启动所述组件；

异步安装模块，用于通过工作线程对所述组件所在的插件包进行安装；

处理模块，用于在所述插件包安装成功后，重新通过所述主线程启动所述组件。

9.如权利要求8所述的设备，其特征在于，所述异步安装模块还用于：

在所述拦截模块拦截主线程启动所述组件之后，判断所述组件是否在插件包中，且所述插件包是否未安装，若确定所述组件在插件包中，且所述插件包未安装，则通过工作线程对所述组件对应的插件包进行安装。

10.如权利要求9所述的设备，其特征在于，所述异步安装模块还用于：

在判断所述组件是否在插件包中，且所述插件包是否未安装之后，若确定所述组件不在插件包中，或确定所述组件在插件包中但所述插件包已安装，则通过系统继续在主线程上执行所述组件。

11.如权利要求9所述的设备，其特征在于，所述处理模块还用于：

在所述插件包安装成功后，若所述源是Fragment，将所述Fragment对应的requestCode当前的值作为偏移后的值，并将所述当前的值改写为初始值，重新通过主线程启动所述组件；

所述异步安装模块还用于：

所述拦截主线程启动所述组件之后，对所述Fragment对应的requestCode进行检测，若确定requestCode被改写，则将所述requestCode当前的值重置为所述偏移后的值，并判断所述组件是否在插件包中，且所述插件包是否未安装。

12.如权利要求8所述的设备，其特征在于，所述异步安装模块具体用于：

通过工作线程判断应用的安装目录中是否有所述组件所在的插件包；

如果有，则通过工作线程从所述安装目录中安装所述插件包；否则通过工作线程从所述应用的安装文件中解压所述插件包的安装包，并通过工作线程利用解压后的安装包安装所述插件包。

13.如权利要求12所述的设备，其特征在于，所述处理模块还用于：

通过主线程上的监听器判断所述插件包是否安装成功。

14.如权利要求8～12任一所述的设备，其特征在于，所述拦截模块还用于：

拦截主线程启动所述组件之后，通过所述主线程显示提示信息。