CN110308949A

CN110308949A - 插件化框架的实现方法、装置及计算机可读存储介质

Info

Publication number: CN110308949A
Application number: CN201910573245.6A
Authority: CN
Inventors: 聂海
Original assignee: Shenzhen Coocaa Network Technology Co Ltd
Current assignee: Shenzhen Coocaa Network Technology Co Ltd
Priority date: 2019-06-28
Filing date: 2019-06-28
Publication date: 2019-10-08

Abstract

本发明公开了一种插件化框架的实现方法，该方法包括：根据宿主的功能接口定义宿主的公共接口，并将公共接口打包成jar包；根据jar包的接口协议将第三方应用软件打包成插件；当宿主接收到插件调用指令时，通过插件管理器获取插件调用指令对应的插件，并将对应的插件加载至宿主中；将加载后的插件转化为jar包中的接口类型，并通过jar包中的接口类型调用加载的插件。本发明还公开了一种插件化框架的实现装置及计算机可读存储介质。本发明在宿主和插件中建立的公共接口，在有新的插件上线后也无需对宿主中的代码进行修改，就可实现对所有插件的调用，降低的软件开发的难度和时间，为软件的维护的扩展带来便利。

Description

插件化框架的实现方法、装置及计算机可读存储介质

技术领域

本发明涉及系统开发领域，尤其涉及一种插件化框架的实现方法、装置及计算机可读存储介质。

背景技术

在智能设备越来越普及的今天，软件的数量在快速增长，且每个软件内部的功能和内容也在快速增多，比如，微信从最开始的即时聊天应用(IM)演变成一个集成社交、游戏、线上到线下(Online To Offline，简称O2O)和公众平台等几大领域的超级APP，这样给用户带来丰富的使用体验的同时，也暴露出了一些新的问题。比如，软件体积增多而导致系统启动速度越来越慢、软件运行越来越卡顿、智能设备内存占用越来越大、软件开发时编译速度慢、开发调试慢、软件版本迭代麻烦等问题，这样不但对智能设备的硬件性能有了更高的要求，也严重影响了软件的扩展和升级，因此，软件插件化技术越来越被重视。

目前的软件插件化技术是通过Method生成得到的实例中的各个需要调用的具体方法来实现对单个插件的调用，但当有新的插件上线时，无法通过统一的插件加载框架来实现对新增插件的统一调用，而需要根据新增插件重新对宿主代码进行修改，因此，目前的这种方式不能适用大面积的插件调用，成为亟待解决的技术问题。

发明内容

本发明的主要目的在于提供一种插件化框架的实现方法、装置及计算机可读存储介质，旨在解决在有新的插件上线时，无法通过统一的插件加载框架来实现所有插件的统一调用的技术问题。

为实现上述目的，本发明提供一种插件化框架的实现方法，所述插件化框架的实现方法包括：

根据宿主的功能接口定义所述宿主的公共接口，并将所述公共接口打包成jar包；

根据所述jar包的接口协议将第三方应用软件打包成插件；

当宿主接收到插件调用指令时，通过插件管理器获取所述插件调用指令对应的插件，并将对应的插件加载至所述宿主中；

将加载后的插件转化为所述jar包中的接口类型，并通过所述jar包中的接口类型调用加载的插件。

优选地，所述通过插件管理器获取所述插件调用指令对应的插件的步骤，包括：

通过插件管理器从本地获取所述插件调用指令对应的插件；和/或

通过插件管理器从服务器的插件列表中获取所述插件调用指令对应的插件。

优选地，所述通过插件管理器从服务器的插件列表中获取所述插件调用指令对应的插件的步骤，包括：

通过插件管理器获取所述插件调用指令中的插件名称，并根据所述插件名称向服务器发送插件请求指令，以使所述服务器接收到所述插件请求指令，并根据所述插件请求指令从插件列表中获取所述插件名称对应的插件；

接收所述服务器获取到的插件，并保存至本地。

优选地，所述插件包括dex文件、jni文件和resource包，所述将所述插件加载至所述宿主中的步骤，包括：

将所述插件的dex文件加载至所述宿主dex文件路径中；和

将所述插件的jni文件加载至所述宿主目标jni文件中；和

将所述宿主resource包与所述插件resource包进行整合。

优选地，所述将所述插件的dex文件加载至所述宿主dex文件路径中的步骤，包括：

获取所述插件的dexElements列表和所述宿主的dexElements列表；

将插件的dexElements列表和所述宿主的dexElements列表中的dex文件进行合并；

将合并后的dexElements列表加载至所述宿主中。

优选地，所述将所述插件的jni文件加载至所述宿主目标jni文件中的步骤，包括：

将所述插件jni文件打包存放至所述插件的lib目录中；

将所述插件的lib目录加载至所述宿主的lib目录。

优选地，所述将所述宿主resource包与所述插件resource包进行整合的步骤，包括：

所述将所述宿主resource包与所述插件resource包进行整合的步骤，包括：

根据所述插件resource的路径信息创建相应的resource包，其中，所述插件的数量与所述resource包的数量一一对应；

将所述resource包的信息发送至所述宿主的资源管理器中，通过所述资源管理器对所述宿主resource包与所述插件resource包进行整合。

优选地，所述将加载后的插件转化为所述jar包中的接口类型，并通过所述jar包中的接口类型调用加载的插件的步骤，包括：

对加载后的插件进行实例化；

将实例化后的插件强制转化为所述jar包中的接口类型；

通过所述jar包中的接口类型调用加载的插件。

此外，为实现上述目的，本发明还提供一种插件化框架的实现装置，所述插件化框架的实现装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的插件化框架的实现程序，所述插件化框架的实现程序被所述处理器执行时实现上述任一项所述插件化框架的实现方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，其上存储有插件化框架的实现程序，所述插件化框架的实现程序被处理器执行时实现上述任一项所述插件化框架的实现方法的步骤。

本发明根据宿主的功能接口定义所述宿主的公共接口，并将所述公共接口打包成jar包；根据所述jar包的接口协议将第三方应用软件打包成插件；当宿主接收到插件调用指令时，通过插件管理器获取所述插件调用指令对应的插件，并将对应的插件加载至所述宿主中；将加载后的插件转化为所述jar包中的接口类型，并通过所述jar包中的接口类型调用加载的插件。通过上述实施方式，将宿主中所有功能接口定义到一个公共接口中，并将该公共接口打包成jar包，同时在打包插件时都需根据该jar包的接口协议来定义插件中的接口，使得所有插件都满足宿主的接口调用，在宿主接收到插件调用指令时，可通过插件管理器获取并加载该插件，并将加载后的插件实例化成该jar包中的接口类型，从而实现宿主对该插件的调用。本发明在宿主和插件中建立的公共接口，在有新的插件上线后也无需对宿主中的代码进行修改，就可实现对所有插件的调用，降低的软件开发的难度和时间，为软件的维护的扩展带来便利。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的装置结构示意图；

图2为本发明插件化框架的实现方法第一实施例的流程示意图；

图3为本发明插件化框架的整体结构图；

图4为本发明插件化框架的实现方法第二实施例的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，图1是本发明实施例方案涉及的硬件运行环境的终端结构示意图。

本发明实施例终端可以是智能电视，也可以是智能手机、平板电脑、电视机顶盒、穿戴设备等安装有安卓系统的终端设备。

如图1所示，该终端可以包括：处理器1001，例如CPU，通信总线1002，用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选的用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

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

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

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及插件化框架的实现程序。

在图1所示的终端中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(用户端)，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的插件化框架的实现程序，并执行以下操作：

根据所述jar包的接口协议将第三方应用软件打包成插件；

进一步地，处理器1001可以调用存储器1005中存储的插件化框架的实现程序，还执行以下操作：

接收所述服务器获取到的插件，并保存至本地。

将所述插件的dex文件加载至所述宿主dex文件路径中；和

将所述插件的jni文件加载至所述宿主目标jni文件中；和

将所述宿主resource包与所述插件resource包进行整合。

获取所述插件的dexElements列表和所述宿主的dexElements列表；

将合并后的dexElements列表加载至所述宿主中。

将所述插件jni文件打包存放至所述插件的lib目录中；

将所述插件的lib目录加载至所述宿主的lib目录。

所述将加载后的插件转化为所述jar包中的接口类型，并通过所述jar包中的接口类型调用加载的插件的步骤，包括：

对加载后的插件进行实例化；

将实例化后的插件强制转化为所述jar包中的接口类型；

通过所述jar包中的接口类型调用加载的插件。

本发明插件化框架的实现装置的具体实施例与下述插件化框架的实现方法各实施例基本相同，在此不作赘述。

参照图2，本发明插件化框架的实现方法的第一实施例的流程示意图，所述插件化框架的实现方法包括：

步骤S10，根据宿主的功能接口定义所述宿主的公共接口，并将所述公共接口打包成jar包。

本发明实施例终端可以是智能电视，也可以是智能手机、平板电脑、电视机顶盒、穿戴设备等安装有安卓系统的终端设备，为方便说明，后续实施例均以智能电视为例。在智能电视的安卓系统中建立一个插件化框架，需要先在实际工程中定义宿主工程和插件工程，该宿主工程和插件工程实际为由第三方软件开发工具包(Software Development Kit，简称SDK)打包成的安装包(AndroidPackage，简称apk)。例如，宿主为某播放器apk，插件为其他提供音视频内容的播放器apk。在建立插件化框架时，先要确定宿主需要实现的所有功能和使用到的功能接口，并将这个功能接口定义到宿主的公共接口中，在通过打包工具如aapt等将该公共接口打包成jar包，这样jar包中就包含宿主中所有要使用到的接口类型。

在生成jar包后，需要设置jar包的属性，使宿主和插件均可依赖该jar包实现调用，具体地，将该jar包在宿主中设置成Compile，在插件中设置成provided，这样实现宿主和各插件依赖该jar包。例如，在某工程结构中，宿主为某播放器apk，插件为提供音视频资源的其他播放器apk，该宿主中需要实现的功能为播放、暂停、前进、后退，故定义了四个功能接口如功能接口1、功能接口2、功能接口3、功能接4来分别实现这四个功能，则需将这所有的功能接口统一放置在这一个公共接口，并打包成jar包，由于宿主和插件均依赖该jar包，所以在宿主调用插件时，只要该插件中的实例化后转化成jar包中的接口类型，就可以直接被宿主调用。

本领域的技术人员可以认为，宿主中功能接口的名称和数量不受限制，可以根据实际需要进行设置。

步骤S20，根据所述jar包的接口协议将第三方应用软件打包成插件。

在对第三方应用软件打包成插件时，需要根据jar包中接口协议来打包插件，具体地，就是将该jar包作为标准公共接口，根据这个标准公共接口来分别对第三方应用软件打包成插件，以使插件能适用该宿主的接口标准，实现宿主对各插件的统一调用。当然，在打包插件时各个插件在与宿主有相同依赖的情况下，都不能将相同的依赖打包进插件，否则可能出现重复依赖的问题。为了后续统一标准化的加载插件的jni文件(或so文件)，所以要在每个插件中建立相同的jni的文件存储路径，如lib/armeabi、lib/armeabi-v7a。

步骤S30，当宿主接收到插件调用指令时，通过插件管理器获取所述插件调用指令对应的插件，并将对应的插件加载至所述宿主中。

当宿主接收到用户触发的插件调用指令时，会从后台的公共接口中获取插件调用指令对应的插件名称，并将插件名称发送至插件管理器，插件管理器接收到该插件名称后，根据该插件名称获取对应的插件，并加载至宿主中。请参照图3，图3为本发明插件化框架的整体结构图，宿主的公共接口中包含n个功能接口，n为正整数，宿主根据插件调用指令调用对应的功能接口，请求插件管理器从插件列表中获取所要调用的插件，其中插件列表中包含m个功能插件，m为正整数，当插件管理器获取到插件后，将该插件加载至宿主中。

作为一种实施方式，可以通过插件管理器从本地获取所述插件调用指令对应的插件。在宿主需要调用某插件时，先判断本地是否有所述插件调用指令对应的插件，如有，则直接将该插件加载至宿主中。

作为另一种实施方式，可以通过插件管理器从服务器的插件列表中获取所述插件调用指令对应的插件。通过插件管理器向服务器或云端发送插件请求指令，服务器或云端接收到该指令后，从服务器的插件列表中所述插件调用指令对应的插件，并将其下载到本地缓存或宿主中。

获取到相应的插件后，需要插件管理器将插件加载至宿主中，这需要将该插件的dex文件、jni文件和resource包均加载至宿主中，宿主中才包含实现该插件功能中代码资源。由于插件的数量较多，宿主只需要根据实际情况需要，获取相应的插件就行，不需要获取并加载所有的插件。

步骤S40，将加载后的插件转化为所述jar包中的接口类型，并通过所述jar包中的接口类型调用加载的插件。

插件加载至宿主中后，需要先将加载后的插件进行实例化，再将实例化后的插件强制转化为该jar包中的接口类型，这样宿主就可以通过所述jar包中的接口类型调用加载的插件。

在本实施例中根据宿主中公共接口的接口协议对所有第三方应用软件打包成插件，使所有插件都能适用宿主的接口调用要求，在有新的插件上线后也无需对宿主中的代码进行修改，就可实现对所有插件的调用，降低的软件开发的难度和时间，为软件的维护的扩展带来便利。

进一步的，参照图4，本发明插件化框架的实现方法的第二实施例的流程示意图，基于上述图2所示的实施例，所述将所述插件加载至所述宿主中的步骤，包括：

步骤S50，将所述插件的dex文件加载至所述宿主dex文件路径中。

具体地，在对插件的dex文件进行注入时，包括以下步骤：

步骤S501，获取所述插件的dexElements列表和所述宿主的dexElements列表。

步骤S502，将插件的dexElements列表和所述宿主的dexElements列表中的dex文件进行合并。

步骤S503，将合并后的dexElements列表加载至所述宿主中。

在插件管理器获取到包含有宿主调用的功能接口对应的方法名称的插件后，需要将该插件中的dex文件、jni文件和resource包一一注入至宿主中，这样宿主才可调用到该插件中代码资源，实现该插件相应的功能。宿主在加载插件中的某个类的时候，会去宿主的ClassLoader中的pathList的dexElements列表里面去找，如果有，才能调用到；如果没有，则会报错，如提示noclassfounfError。所以需要通过修改宿主本身的dexElements列表，将插件中的dexElements列表的项注入到宿主的dexElements列表中，来实现宿主对插件内容访问的有效性。

实现步骤S501至步骤S503的代码如下：

步骤S60，将所述插件的jni文件加载至所述宿主目标jni文件中。

具体地，在对插件的jni文件进行注入时，包括以下步骤：

步骤S601，将所述插件jni文件打包存放至所述插件的lib目录中。

步骤S602，将所述插件的lib目录加载至所述宿主的lib目录。

将插件中的dex文件注入到宿主中后，此时可以正常调用插件中的内容了。但是通常SDK中还有jni文件的使用，而且一般以aar形式集成的SDK都是依赖宿主自动加载或者通过System.loadlibrary(soName)的形式来加载的，这两种加载方式的前提是将jni文件(或so文件)装载在宿主的lib目录下，如果将jni文件(或so文件)打包在插件中，宿主原来的nativeLibraryDirectories是不包含插件内jni文件(或so文件)的路径的，也就会导致加载失败，提示报错，如UnsatisfiedLinkError。如果加载相关部分没有保护还会直接导致宿主进程崩溃。这个时候就需要我们手动将插件的jni文件(或so文件)注入到宿主的jni文件(或so文件)列表中去，以供插件调用。

实现步骤S601至步骤S602的代码如下：

try{

//获取当前类的属性

Field nativeLibraryDirectories＝

pathList.getClass().getDeclaredField("nativeLibraryDirectories")；

nativeLibraryDirectories.setAccessible(true)；

//获取DEXPATHList中的属性值

File[]files1＝(File[])nativeLibraryDirectories.get(pathList)；

for(int i＝0；i<files1.length；i++){

Log.i(TAG,"get base JniLib success"+files1[i].getAbsolutePath())；

}

Object filesss＝Array.newInstance(File.class,files1.length+1)；

//添加自定义.so路径

File pluginFile＝new File(soPath)；

Array.set(filesss,0,pluginFile)；

Log.i(TAG,"add plugin JniLib:"+pluginFile.getAbsolutePath())；

//将系统自己的追加上

for(int i＝1；i<files1.length+1；i++){

Array.set(filesss,i,files1[i-1])；

}

//注入

nativeLibraryDirectories.set(pathList,filesss)；

Log.i(TAG,"inject JniLib success")；

return true；

}catch(NoSuchFieldException e){

e.printStackTrace()；

}catch(SecurityException e){

e.printStackTrace()；

}catch(IllegalAccessException e){

e.printStackTrace()；

}catch(IllegalArgumentException e){

e.printStackTrace()；

}catch(NegativeArraySizeException e){

e.printStackTrace()；

}catch(ArrayIndexOutOfBoundsException e){

e.printStackTrace()；

}catch(Exception e){

e.printStackTrace()；

}

步骤S70，将所述宿主resource包与所述插件resource包进行整合。

当该插件化框架中不存在相互调用资源的情况，各个插件apk只会调用到本插件内部的资源时，每一个插件实际上可以通过具体路径创建一个对应的resource包。最终有多少个插件就能生成多少个resource包，实际上可以通过修改宿主的资源管理器(AssetsManager)来根据调用者的包名来动态的选择对应的resource包即可。具体地，将所述宿主resource包与所述插件resource包进行整合时，需要执行以下步骤：

步骤S701，根据所述插件resource的路径信息创建相应的resource包，其中，所述插件的数量与所述resource包的数量一一对应。

步骤S702，将所述resource包的信息发送至所述宿主的资源管理器中，通过所述资源管理器对所述宿主resource包与所述插件resource包进行整合。

这种实施方式不需要修改插件的资源id，去修改插件打包程序，是相对比较简单的方式。

当然，作为另一种实施方式，也可以是修改插件打包程序，如aapt等官方的打包工具，实现原理是修改打包程序将资源的id限制到非0x01(系统资源地址)和非0x7f(宿主工程资源地址)，之后再将插件的资源合并到宿主中，以此来实现资源的合并。

当然，作为另一种实施方式，也可以是修改项目的R.txt文件，目的同样是区分宿主和插件的资源id范围，防止id重复导致调用异常。

在完成上述步骤S40和步骤S50之后，可以在智能电视中正常将第三方SDK插件化，并正常使用了，但是面对众多的第三方插件，需要形成统一的插件加载框架，因此先将各个插件固定放置在宿主的assets目录下新建的plugin_player目录下，然后使用统一的加载方法来加载所有的插件即可。

在本实施例中通过将插件的dex文件和jni文件注入至宿主中，并将宿主与插件的resource包进行合并，使得宿主可以实现动态选择调用插件中的资源。

此外，本发明实施例还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有插件化框架的实现程序，所述插件化框架的实现程序被处理器执行时实现如下操作：

根据所述jar包的接口协议将第三方应用软件打包成插件；

进一步地，所述插件化框架的实现程序被处理器执行时还实现如下操作：

接收所述服务器获取到的插件，并保存至本地。

将所述插件的dex文件加载至所述宿主dex文件路径中；和

将所述插件的jni文件加载至所述宿主目标jni文件中；和

将所述宿主resource包与所述插件resource包进行整合。

获取所述插件的dexElements列表和所述宿主的dexElements列表；

将合并后的dexElements列表加载至所述宿主中。

将所述插件jni文件打包存放至所述插件的lib目录中；

将所述插件的lib目录加载至所述宿主的lib目录。

对加载后的插件进行实例化；

将实例化后的插件强制转化为所述jar包中的接口类型；

通过所述jar包中的接口类型调用加载的插件。

本发明计算机可读存储介质的具体实施例与上述插件化框架的实现方法各实施例基本相同，在此不作赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims

1.一种插件化框架的实现方法，其特征在于，所述插件化框架的实现方法包括：

根据所述jar包的接口协议将第三方应用软件打包成插件；

2.如权利要求1所述的插件化框架的实现方法，其特征在于，所述通过插件管理器获取所述插件调用指令对应的插件的步骤，包括：

3.如权利要求2所述的插件化框架的实现方法，其特征在于，所述通过插件管理器从服务器的插件列表中获取所述插件调用指令对应的插件的步骤，包括：

接收所述服务器获取到的插件，并保存至本地。

4.如权利要求1所述的插件化框架的实现方法，其特征在于，所述插件包括dex文件、jni文件和resource包，所述将所述插件加载至所述宿主中的步骤，包括：

将所述插件的dex文件加载至所述宿主dex文件路径中；和

将所述插件的jni文件加载至所述宿主目标jni文件中；和

将所述宿主resource包与所述插件resource包进行整合。

5.如权利要求4所述的插件化框架的实现方法，其特征在于，所述将所述插件的dex文件加载至所述宿主dex文件路径中的步骤，包括：

获取所述插件的dexElements列表和所述宿主的dexElements列表；

将合并后的dexElements列表加载至所述宿主中。

6.如权利要求4所述的插件化框架的实现方法，其特征在于，所述将所述插件的jni文件加载至所述宿主目标jni文件中的步骤，包括：

将所述插件jni文件打包存放至所述插件的lib目录中；

将所述插件的lib目录加载至所述宿主的lib目录。

7.如权利要求4所述的插件化框架的实现方法，其特征在于，所述将所述宿主resource包与所述插件resource包进行整合的步骤，包括：

8.如权利要求1所述的插件化框架的实现方法，其特征在于，所述将加载后的插件转化为所述jar包中的接口类型，并通过所述jar包中的接口类型调用加载的插件的步骤，包括：

对加载后的插件进行实例化；

将实例化后的插件强制转化为所述jar包中的接口类型；

通过所述jar包中的接口类型调用加载的插件。

9.一种插件化框架的实现装置，其特征在于，所述插件化框架的实现装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的插件化框架的实现程序，所述插件化框架的实现程序被所述处理器执行时实现如权利要求1至8中任一项所述插件化框架的实现方法的步骤。

10.一种计算机可读存储介质，其上存储有插件化框架的实现程序，其特征在于，所述插件化框架的实现程序被处理器执行时实现如权利要求1至8中任一项所述插件化框架的实现方法的步骤。