CN114528048A - 应用执行方法、应用执行架构、电子设备及存储介质 - Google Patents

Abstract

本申请公开了一种应用执行方法、应用执行架构、电子设备及计算机可读存储介质。应用执行方法可以用于预设平台，应用执行方法包括：在接收到预设应用的启动指令时，启动预设应用的应用插件包，应用插件包包括至少一个应用插件组件，应用插件组件是通过预设应用的源代码进行字节码修改获得的；根据应用插件组件启动预先向预设平台的平台框架层的应用包管理器注册的壳子组件；应用插件组件通过壳子组件进行生命周期的管理。上述应用执行方法、应用执行架构、电子设备及计算机可读存储介质中，由于壳子组件预先在平台框架层的应用包管理器注册，应用插件组件可以通过壳子组件进行生命周期的管理，应用插件组件可以免安装使用，便于实现泛在服务。

Description

应用执行方法、应用执行架构、电子设备及存储介质

技术领域

本申请涉及泛在服务技术，特别涉及一种应用执行方法、应用执行架构、电子设备及计算机可读存储介质。

背景技术

泛在服务在技术上要求服务完全动态化，用户需要的服务不用安装，即用即来，用完即走。在相关技术中，如何实现泛在服务是本领域亟需解决的技术问题。

发明内容

本申请的实施方式提供了一种应用执行方法、应用执行架构、电子设备及计算机可读存储介质。

本申请实施方式的应用执行方法可以用于预设平台，所述应用执行方法包括：在接收到预设应用的启动指令时，启动所述预设应用的应用插件包，所述应用插件包包括至少一个应用插件组件，所述应用插件组件是通过所述预设应用的源代码进行字节码修改获得的；根据所述应用插件组件启动壳子组件，所述壳子组件预先向所述预设平台的平台框架层的应用包管理器注册；所述应用插件组件通过所述壳子组件进行生命周期的管理。

本申请实施方式的应用执行架构可以用于预设平台，所述应用执行架构包括运行管理器和插件运行进程。所述运行管理器用于在接收到预设应用的启动指令时，启动所述预设应用的应用插件包，所述应用插件包包括至少一个应用插件组件，所述应用插件组件是通过所述预设应用的源代码进行字节码修改获得的。所述插件运行进程用于根据所述应用插件组件启动壳子组件，所述壳子组件预先向所述预设平台的平台框架层的应用包管理器注册；所述应用插件组件通过所述壳子组件进行生命周期的管理。

本申请实施方式的电子设备包括一个或多个处理器和存储器。所述存储器存储有计算机程序。所述计算机程序被所述处理器执行的情况下，实现上述实施方式所述的应用执行方法的步骤。

本申请实施方式的计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行的情况下，实现上述实施方式所述的应用执行方法的步骤。

上述应用执行方法、应用执行架构、电子设备及计算机可读存储介质中，由于壳子组件预先在平台框架层的应用包管理器注册，因此，应用插件组件可以在免安装的情况下通过壳子组件进行生命周期的管理，也即是说，应用插件组件可以免安装使用，从而使得预设应用的使用更加便利，便于实现泛在服务。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施方式的描述中将变得明显和容易理解，其中：

图1是本申请某些实施方式的应用执行架构的示意图；

图2至图5是本申请某些实施方式的应用执行方法的流程示意图；

图6是本申请某些实施方式的应用插件包的示意图；

图7至图9是本申请某些实施方式的应用执行方法的流程示意图；

图10是本申请某些实施方式的壳子组件的生命周期状态转移的示意图；

图11是本申请某些实施方式的电子设备的示意图。

具体实施方式

下面详细描述本申请的实施方式，所述实施方式的实施方式在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。

在本申请的实施方式的描述中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个所述特征。在本申请的实施方式的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

面向未来万物互融时代，终端会越来越多样化，手机，手表，耳机，电视，智能眼镜，智能车机等服务的演进，将从过往的以终端为中心，到以平台为中心，最终演变成以人为中心的泛在服务，一切无缝、无感、随人流转。泛在服务在技术上要求服务完全动态化，用户需要的服务不用安装，即用即来，用完即走。在相关技术中，可以通过Android(安卓)即时应用(Instant APP)，微信小程序，以及Harmony OS(鸿蒙系统)卡片服务实现应用免安装使用，然而这三种技术都需要服务提供者根据三种技术框架重新开发服务，工作量大。

请参阅图1和图2，本申请实施方式的应用执行方法可以用于预设平台100，应用执行方法包括：

01：在接收到预设应用的启动指令时，启动预设应用的应用插件包，应用插件包包括至少一个应用插件组件，应用插件组件是通过预设应用的源代码进行字节码修改获得的；

02：根据应用插件组件启动壳子组件，壳子组件预先向预设平台100的平台框架层11的应用包管理器注册；应用插件组件通过壳子组件进行生命周期的管理。

请参阅图1，本申请实施方式的应用执行架构10可以用于预设平台100。应用执行架构10包括运行管理器12和插件运行进程13。

本申请的应用执行方法可由本申请实施方式的应用执行架构10实现，其中，步骤01可以由运行管理器12实现，步骤02可以由插件运行进程13实现，也即是说，运行管理器12可用于在接收到预设应用的启动指令时，启动预设应用的应用插件包，应用插件包包括至少一个应用插件组件，应用插件组件是通过预设应用的源代码进行字节码修改获得的。插件运行进程13可用于根据应用插件组件启动壳子组件，壳子组件预先向预设平台100的平台框架层11的应用包管理器注册；应用插件组件通过壳子组件进行生命周期的管理。

上述应用执行方法、应用执行架构10中，由于壳子组件预先在平台框架层11的应用包管理器注册，因此，应用插件组件可以在免安装的情况下通过壳子组件进行生命周期的管理，也即是说，应用插件组件可以免安装使用，从而使得预设应用的使用更加便利，便于实现泛在服务。另外，由于应用插件组件是通过预设应用的源代码进行字节码修改获得的，因此，可以复用预设应用的源代码，不需要重新开发，能够减少服务开发者的工作量，服务接入的成本几乎为零，可以快速扩展动态服务生态的规模。

预设平台100可以是Android(安卓)平台、Windows平台、Linux平台等，在此不做具体限定，本申请的实施例以预设平台100为Android平台为例进行说明。

预设应用的源代码不具有对应的壳子组件，因此源代码不能免安装使用。字节码修改可以通过字节码工具实现，字节码工具将基类替换为普通Java类以实现字节码修改，应用插件组件具有对应的壳子组件，壳子组件可以为真实的Android应用组件，运行管理器12可以通过在AndroidManifest.xml中声明的方式预埋一些标准的Android应用组件(即壳子组件)到Android系统的应用包管理器(Package Manager Service，PMS)中，通过这些标准的Android应用组件代理执行应用插件组件的生命周期。应用插件组件是可以动态下载、免安装即可运行的Android应用组件。运行管理器12在本申请中也可以称作runtime，可以为预设进程，用于运行和管理应用插件组件。平台框架层可以为安卓框架层(AndroidFramework)，本申请的应用执行方法运行在安卓框架层，不需要系统修改。PMS可以存储Android系统的所有应用的四大组件(Activity/Service/Content Provider/Receiver)，在标准Android系统，四大组件需要向PMS注册，才能正常工作。

预设应用可以是任意安卓应用程序包(Android application package，apk)，例如包括视频apk、相机apk、打车apk、地图apk、外卖apk等，在此不做具体限定。

请参阅图3，在某些实施方式中，应用执行方法包括：

03：根据当前应用场景确定预设应用并生成启动指令。

请参阅图1，在某些实施方式中，应用执行架构10包括泛在服务平台14。步骤03可以由泛在服务平台14实现，也即是说，泛在服务平台14可用于根据当前应用场景确定预设应用并生成启动指令。

如此，能够通过当前应用场景提供相应的服务。

具体地，泛在服务平台14可以根据用户所处的环境确定当前应用场景，根据当前用户场景推导用户意图，根据用户意图映射到需要启动的泛在服务，从而确定泛在服务对应的预设应用并生成启动指令。例如，泛在服务平台14根据用户所处的环境确定用户处于公交站附近，此时推导用户可能要坐车，因此需要提供辅助用户坐车的服务，从而可以确定预设应用例如为公交apk，进而可以生成公交apk的启动指令。

请参阅图4，在某些实施方式中，步骤01(在接收到预设应用的启动指令时，启动预设应用的应用插件包)，包括：

011：在接收到启动指令时，查找本地是否存在应用插件组件；

012：在本地存在应用插件组件时，启动应用插件组件。

请参阅图1，在某些实施方式中，运行管理器12包括插件管理模块124。步骤011可以由插件管理模块124实现，步骤012可以由运行管理器12实现，也即是说，插件管理模块124可用于在接收到启动指令时，查找本地是否存在应用插件组件。运行管理器12可用于在本地存在应用插件组件时，启动应用插件组件。

如此，在本地存在应用插件组件时，能够直接启动应用插件组件，不用每次都进行应用插件组件的下载。

具体地，运行管理器12包括组件启动模块122，组件启动模块122用于接收泛在服务平台14的启动指令，在接收到启动指令后，组件启动模块122能够调用插件管理模块124查找应用插件包所需要的应用插件组件，其中，可以用一个应用插件组件或多个应用插件组件编排一起执行来给用户提供服务。组件启动模块122可以查找本地的插件仓库15中是否存在所需的应用插件组件，在本地的插件仓库15中存在所需的应用插件组件时，启动应用插件组件。运行管理器12可以根据当前存储设备类型以及存储容量，缓存最近频繁使用的应用插件组件，如此可以避免每次都需要重新下载应用插件组件。另外，在缓存应用插件组件的预设时长后，可以将应用插件组件进行清除。

请参阅图5，在某些实施方式中，步骤01(在接收到预设应用的启动指令时，启动预设应用的应用插件包)，还包括：

013：在本地不存在应用插件组件时，下载应用插件包；

014：处理应用插件包以得到应用插件组件；

015：将应用插件组件保存在本地。

请参阅图1，在某些实施方式中，运行管理器12包括处理模块126。步骤013可以由插件管理模块124实现，步骤014和步骤015可以由处理模块126实现，也即是说，插件管理模块124可用于在本地不存在应用插件组件时，下载应用插件包。处理模块126可用于处理应用插件包以得到应用插件组件、将应用插件组件保存在本地。

如此，在本地不存在应用插件组件时，能够下载应用插件组件并进行启动以给用户提供服务。

具体地，在本地的插件仓库15中不存在所需的应用插件组件时，例如对于第一次启动的应用插件组件，则可以从插件服务市场16下载应用插件包，具体地，可以根据应用插件包名称、唯一标识，通过HTTPS协议从插件服务市场16下载应用插件包，并保存在SDCARD上的临时目录。其中，HTTPS(Hyper Text Transfer Protocol over Secure SocketLayer)是以安全为目标的HTTP通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。应用插件包可以包括多个应用插件组件，每个应用插件组件的元数据定义在应用插件包定义文件中，例如请参图6，应用插件包包括应用插件包定义文件和三个应用插件组件，三个应用插件组件的元数据定义在应用插件包定义文件中。开发者可以用于标准应用组件开发Android应用程序，开发者不用修改Android应用的源代码，只需要在打包时候，用预设打包工具打包，预设打包工具通过字节码修改程序自动进行字节码修改(对开发者完全透明)，就可以发布到插件服务市场16以供下载。

应用插件包下载结束后，从SDCARD上的临时目录读取应用插件包，通过解压、解析等方式处理应用插件包以得到应用插件组件的镜像及其元数据，其中，镜像可以直接存储在指定的SDCARD目录，元数据可以存储在SQLITE关系数据库中，元数据包括应用插件包云端URL、本地镜像的唯一标识、本地镜像存储路径、本地镜像MD5哈希值等信息。

请参阅图7，在某些实施方式中，步骤01(在接收到预设应用的启动指令时，启动预设应用的应用插件包)，包括：

016：检查应用插件组件的合法性并在检查通过后启动插件运行进程13以用于运行应用插件组件，一个应用插件包对应一个插件运行进程13。

请参阅图1，在某些实施方式中，步骤016可以由运行管理器12实现，也即是说，运行管理器12可用于检查应用插件组件的合法性并在检查通过后启动插件运行进程13以用于运行应用插件组件，一个应用插件包对应一个插件运行进程13。

如此，不同的应用插件包运行在不同的插件运行进程13中，可以实现代码指令隔离。

具体地，运行管理器12检查应用插件组件的合法性，在应用插件组件合法时启动一个插件运行进程13作为应用插件包的所有应用插件组件以及壳子组件的运行容器。为了保证应用插件包运行的安全性，一个应用插件包可以分别单独对应一个插件运行进程13，不同的应用插件包运行在不同的插件运行进程13中，可以实现代码指令隔离；不同的应用插件包的数据可以存储在不同的沙盒中，实现数据的隔离。

插件运行进程13包括插件组件装载器132和类加载器134。插件运行进程13接收到应用插件组件的启动请求后，插件组件装载器132从插件仓库15读取应用插件组件的镜像，其中，应用插件组件的进行可以是可装载的Jar文件，然后，通过类加载器134加载该应用插件组件。

请参阅图8，在某些实施方式中，步骤02(根据应用插件组件启动壳子组件)，包括：

022：将应用插件组件的名称作为壳子组件的启动参数。

请参阅图1，在某些实施方式中，插件运行进程13包括插件组件装载器132。步骤022可以由插件组件装载器132实现，也即是说，插件组件装载器132可用于将应用插件组件的名称作为壳子组件的启动参数。

如此，启动的壳子组件与应用插件组件对应，能够更好地实现对应用插件组件进行生命周期管理。

具体地，为了启动和管理应用插件组件，需要启动壳子组件作为应用插件组件的代理，插件运行进程13调用Android Framework API启动壳子组件，并把应用插件组件的class(类)名称作为启动壳子组件的参数。

请参阅图9，在某些实施方式中，平台框架层11包括应用组件生命周期管理器，应用执行方法包括：

04：应用组件生命周期管理器驱动壳子组件的生命周期的状态转移函数执行；

05：通过应用插件组件的生命周期管理代理模块136把壳子组件的生命周期代理到应用插件组件的生命周期函数；

06：应用插件组件回调壳子组件的生命周期函数至生命周期管理代理模块136；

07：生命周期管理代理模块136将壳子组件的生命周期函数回调到壳子组件执行。

请参阅图1，在某些实施方式中，应用执行架构10包括平台框架层11，平台框架层11包括应用组件生命周期管理器，插件运行进程13包括生命周期管理代理模块136和四大组件实例138。步骤04可以由应用组件生命周期管理器实现，步骤05和步骤07可以由生命周期管理代理模块136实现，步骤06可以由四大组件实例138实现。也即是说，应用组件生命周期管理器可用于驱动壳子组件的生命周期的状态转移函数执行。生命周期管理代理模块136可用于把壳子组件的生命周期代理到应用插件组件的生命周期函数。四大组件实例138可用于回调壳子组件的生命周期函数至生命周期管理代理模块136。生命周期管理代理模块136可用于将壳子组件的生命周期函数回调到壳子组件执行。

如此，能够通过壳子组件实现应用插件组件的生命周期的代理。

具体地，应用组件生命周期管理器(Activity Manager Service，AMS)为Android四大组件生命周期管理器，AMS启动壳子组件，并且通过进程间通信(Inter-ProcessCommunication，IPC)驱动壳子组件生命周期状态转移函数执行。例如，以Android的Activity壳子组件，生命周期状态转移如图10所示。壳子组件是标准的Android组件，壳子组件的生命周期和应用插件组件的生命周期支持Android四大组件。下面以Activity壳子组件为例进行说明，Service壳子组件、Content Provider壳子组件以及BroadcastReceiver壳子组件和Activity壳子组件的工作原理和方式是一样的。Activity壳子组件有五种状态：Starting、Running、Stopped、Paused和Destroyed。Starting状态是初始状态；Running状态是Activity壳子组件显示在屏幕上，并且处于显示窗口栈的顶部，用户可以有输入焦点。Paused状态是Activity壳子组件仍旧显示在屏幕上，但窗口已经失去了输入焦点，此时壳子组件无法与用户交互。Stopped状态是Activity壳子组件已经退到后台，既看不到界面，也无法与用户交互。Destroy状态是虚拟状态，表示Activity壳子组件已经从内存中完全移除。AMS通过调用Activity壳子组件的生命周期函数来驱动Activity壳子组件的状态转移。比如从Starting状态转移到Running状态，所需要执行的生命周期转移函数序列是onCreate()->onStart()->onRestoreinstanceState()->onResume()。

通过生命周期管理代理模块136把壳子组件的生命周期代理到应用插件组件的生命周期函数，例如，以壳子组件为Activity壳子组件为例进行说明，可以将壳子组件的onCreate()等方法代理到应用插件组件执行。

四大组件实例138可以回调壳子组件的一些生命周期函数，比如，四大组件实例138调用Android的startActivity()去启动另外一个Activity壳子组件，四大组件实例138通过生命周期管理代理模块136把startActivity()的请求通过壳子组件代理执行。生命周期管理代理模块136接收到生命周期回调函数请求(super())或者Framework API后，会通过壳子组件代理去执行。

需要说明的是，本申请的应用执行方法零反射无Hack实现插件技术，不需要HackAndroid API调用，不需要修改Android框架。

插件组件装载器132、类加载器134、生命周期管理代理模块136等可以动态地从云端更新下载，也即是说，实现了动态运行框架，运行框架本身也能动态更新。

运行管理器12的功能很小，只有100多个方法，运行管理器12的镜像小于15KB。

本申请可以沿用成熟的Android原生应用生态，运行管理器12以及应用插件组件可以运行在任何标准的AOSP(Android Open Source Project)设备上。本方案可以解决过多的静态安装导致设备的存储/内存开销过大的问题，并且可以实现以人为中心的“泛在服务平台”。

需要指出的是，上述所提到的具体数值只为了作为例子详细说明本申请的实施，而不应理解为对本申请的限制。在其他例子或实施方式或实施例中，可根据本申请来选择其他数值，在此不作具体限定。

请参阅图11，本申请实施方式的应用执行方法可由本申请实施方式的电子设备1000实现。具体地，电子设备1000包括一个或多个处理器1004和存储器1002。存储器1002存储有计算机程序。计算机程序被处理器1004执行的情况下，实现上述任一实施方式的应用执行方法的步骤。

例如，计算机程序被处理器1004执行的情况下，实现以下应用执行方法的步骤：

01：在接收到预设应用的启动指令时，启动预设应用的应用插件包，应用插件包包括至少一个应用插件组件，应用插件组件是通过预设应用的源代码进行字节码修改获得的；

02：根据应用插件组件启动壳子组件，壳子组件预先向预设平台100的平台框架层11的应用包管理器注册；应用插件组件通过壳子组件进行生命周期的管理。

在某些实施方式中，电子设备1000可包括智能手机、平板电脑、智能手表、智能手环、等装置，在此不做具体限定。

本申请实施方式的计算机可读存储介质，其上存储有计算机程序，程序被处理器执行的情况下，实现上述任一实施方式的应用执行方法的步骤。

例如，程序被处理器执行的情况下，实现以下应用执行方法的步骤：

01：在接收到预设应用的启动指令时，启动预设应用的应用插件包，应用插件包包括至少一个应用插件组件，应用插件组件是通过预设应用的源代码进行字节码修改获得的；

02：根据应用插件组件启动壳子组件，壳子组件预先向预设平台100的平台框架层11的应用包管理器注册；应用插件组件通过壳子组件进行生命周期的管理。

可以理解，计算机程序包括计算机程序代码。计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读存储介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、以及软件分发介质等。处理器可以是中央处理器，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种应用执行方法，用于预设平台，其特征在于，所述应用执行方法包括：

在接收到预设应用的启动指令时，启动所述预设应用的应用插件包，所述应用插件包包括至少一个应用插件组件，所述应用插件组件是通过所述预设应用的源代码进行字节码修改获得的；

根据所述应用插件组件启动壳子组件，所述壳子组件预先向所述预设平台的平台框架层的应用包管理器注册；所述应用插件组件通过所述壳子组件进行生命周期的管理。

2.根据权利要求1的应用执行方法，其特征在于，所述应用执行方法包括：

根据当前应用场景确定所述预设应用并生成所述启动指令。

3.根据权利要求1的应用执行方法，其特征在于，所述在接收到预设应用的启动指令时，启动所述预设应用的应用插件包，包括：

在接收到所述启动指令时，查找本地是否存在所述应用插件组件；

在本地存在所述应用插件组件时，启动所述应用插件组件。

4.根据权利要求3的应用执行方法，其特征在于，所述在接收到预设应用的启动指令时，启动所述预设应用的应用插件包，还包括：

在本地不存在所述应用插件组件时，下载所述应用插件包；

处理所述应用插件包以得到所述应用插件组件；

将所述应用插件组件保存在本地。

5.根据权利要求1所述的应用执行方法，其特征在于，所述在接收到预设应用的启动指令时，启动所述预设应用的应用插件包，包括：

检查所述应用插件组件的合法性并在检查通过后启动插件运行进程以用于运行所述应用插件组件，一个应用插件包对应一个插件运行进程。

6.根据权利要求1所述的应用执行方法，其特征在于，所述根据所述应用插件组件启动壳子组件，包括：

将所述应用插件组件的名称作为所述壳子组件的启动参数。

7.根据权利要求1所述的应用执行方法，其特征在于，所述平台框架层包括应用组件生命周期管理器，所述应用执行方法包括：

所述应用组件生命周期管理器驱动所述壳子组件的生命周期的状态转移函数执行；

通过所述应用插件组件的生命周期管理代理模块把所述壳子组件的生命周期代理到所述应用插件组件的生命周期函数；

所述应用插件组件回调所述壳子组件的生命周期函数至所述生命周期管理代理模块；

所述生命周期管理代理模块将所述壳子组件的生命周期函数回调到所述壳子组件执行。

8.一种应用执行架构，用于预设平台，其特征在于，所述应用执行架构包括：

运行管理器，所述运行管理器用于在接收到预设应用的启动指令时，启动所述预设应用的应用插件包，所述应用插件包包括至少一个应用插件组件，所述应用插件组件是通过所述预设应用的源代码进行字节码修改获得的；

插件运行进程，所述插件运行进程用于根据所述应用插件组件启动壳子组件，所述壳子组件预先向所述预设平台的平台框架层的应用包管理器注册；所述应用插件组件通过所述壳子组件进行生命周期的管理。

9.一种电子设备，其特征在于，所述电子设备包括一个或多个处理器和存储器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行的情况下，实现权利要求1-7任一项所述的应用执行方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行的情况下，实现权利要求1-7任一项所述的应用执行方法的步骤。

Images