一种多语言运行库按需调用方法和系统

本发明涉及软件开发技术领域，特别涉及一种多语言运行库按需调用方法和系统。

背景技术

运行库调用技术是指在软件开发中使用运行库（也称为库或库文件）来访问和执行库中提供的功能和服务。

按需调用库（lazy loading）是一种优化技术，它在程序运行时延迟加载和链接共享库，直到真正需要使用库中的函数或符号时才进行加载。运行库是一组预编译的可重用代码模块，包含了常用的功能实现，如输入输出功能、网络通信功能、数据库连接功能等。对于大型应用程序，其可能包含多个共享库文件，而不是所有函数都会在每次执行中被用到，只有在需要时才加载所需的库文件；对于应用程序支持插件或动态加载模块，按需调用库可确保只在需要时加载插件所需的库，这样可以实现灵活的扩展性，同时减少了对特定插件的依赖；对于可能需要相对较长的初始化时间的库，按需调用库可以将初始化步骤推迟到实际使用时，避免不必要的初始化开销，提高程序的响应性能。总之，按需调用库适用于那些具有复杂性、大型性或需要灵活加载库的应用场景。它可以提高程序的启动速度、减少内存占用，并在需要时确保所需的函数和符号可用，以优化应用程序的性能和资源利用。

此外，在进行软件开发时，会有一些常用的功能和代码需要编写，重复编写较为影响开发效率；还会有一些常用的应用程序包括相同的代码，会重复占用内存空间。当这些重复的代码需要更新或修复时，工作量较大。而且，应用程序若是想要在不同操作系统和平台上运行，涉及跨平台迁移与支持，较为不便。

因此，有必要提供一种改进了的多语言运行库按需调用方法，以解决上述问题。

发明内容

本发明意在提供一种多语言运行库按需调用方法和系统，以解决现有技术中在进行软件开发时，存在因一些常用的功能和代码需要编写进而导致开发效率低，因一些常用的应用程序包括相同的代码进而重复占用内存空间，以及因这些重复的代码需要更新或修复导致的工作量较大，无法实现在不同操作系统和平台上运行时的跨平台迁移与支持等的技术问题，本发明要解决的技术问题通过以下技术方案来实现。

本发明的第一方面提出一种多语言运行库按需调用方法，包括：当Linux操作系统中指定应用在运行阶段运行、且根据需要进行待加载库的加载处理时，根据预设库加载路径策略，控制Linux操作系统中指定应用在运行阶段加载到所需要使用的库；所述库加载路径策略包括不同优先级的路径控制点以及各路径控制点所指向的搜索路径，其中，应用沙箱提前放置有路径控制点以及C/C++按需调用时所需的不同版本的应用程序，且控制点信息可编辑更新、应用程序可上传更新；通过使用以下特定参数中至少两者，在编译阶段和链接阶段限定共享库的搜索路径：路径参数、命令参数、编译参数、链接参数、系统参数；通过使用以下特定参数中至少两者，在编译阶段和链接阶段限定共享库的搜索路径：路径参数、命令参数、编译参数、链接参数、系统参数；在java库多版本按需调用时，利用应用沙箱的运行环境，使应用程序可以在不同发行版本的操作系统所对应的机器上运行；在Java系统中创建代理类来加载和代理原始类的代理加载机制，基于所述代理加载机制在不修改原始类的情况下对原始类进行扩展、增强或拦截，通过定制化的加载策略及沙箱定制类加载器，在应用框架里面Java应用程序根据需要进行待加载类的加载处理；根据所确定的加载路径，获取待加载类或待加载库的文件。

根据可选的实施方式，在进行加载处理之前，先判断预设库加载路径策略中是否包含与待加载库或待加载类的定制加载顺序。

根据可选的实施方式，如果包含与待加载库或待加载类的定制加载顺序，则按照指定加载路径来加载待加载类或待加载库；如果未包含与待加载库或待加载类的定制加载顺序，则按照默认加载路径查找待加载类或待加载库所对应的文件。

根据可选的实施方式，进一步包括：在第一按需调用方式里，应用安装、运行过程中，通过指定路径的方式，使应用在加载时优先从自身封装的库中加载相关文件，再是从应用框架和依赖库中加载相关文件；在第二按需调用方式中，按照应用的需要，能够不受次序限制地加载应用实现层的类、应用框架层的类以及基础类。

根据可选的实施方式，进一步包括：配设不同优先级的多个路径控制点，控制点提前放置在应用沙箱中且可编辑更新，具体包括配设用于编译阶段的第一优先级路径控制点、用于运行阶段的第二优先级路径控制点、用于配置文件的第三优先级控制点、用于默认查找路径的第四优先级控制点；所述路径控制点用于控制要执行的指定应用程序、应用程序自带系统库或基础库搜索路径，指定应用程序、应用程序自带系统库/基础库搜索路径、运行时基础库搜索路径、运行时系统库的搜索路径。

根据可选的实施方式，在需要运行应用程序时，且在同一机器上同时存在与所述应用程序相对应的多个版本时，则优先加载指定加载路径所对应的版本。

根据可选的实施方式，在Java系统应用程序的运行依赖于应用沙箱所提供的运行环境；所述应用沙箱利用沙箱定制类加载器隔离，以使在Java虚拟机中，不同的沙箱定制类加载器负责加载不同的类来形成类的加载隔离。

本发明的第二方面提出一种多语言运行库按需调用系统，包括：第一加载处理模块，当Linux操作系统中指定应用在运行阶段运行、且根据需要进行待加载库的加载处理时，根据预设库加载路径策略，控制Linux操作系统中指定应用在运行阶段加载到所需要使用的库；所述库加载路径策略包括不同优先级的路径控制点以及各路径控制点所指向的搜索路径，其中，路径控制点的控制点信息提前放置在应用沙箱中且可编辑更新，通过使用以下特定参数中至少两者，在编译阶段和链接阶段限定共享库的搜索路径：路径参数、命令参数、编译参数、链接参数、系统参数；提供应用沙箱模块，在采用第一按需调用方式时，应用沙箱提前放置有路径控制点以及C/C++按需调用时所需的不同版本的应用程序，且控制点信息可编辑更新、应用程序可上传更新；同时，利用应用沙箱的运行环境，使得应用程序可在不同发行版本的操作系统所对应的机器上运行；在采用第二按需调用方式时，利用应用沙箱的运行环境，使得应用程序可在不同发行版本的操作系统所对应的机器上运行；第二加载处理模块，在Java系统中创建代理类来加载和代理原始类的代理加载机制，基于所述代理加载机制在不修改原始类的情况下对原始类进行扩展、增强或拦截，通过定制化的加载策略及沙箱定制类加载器，在应用框架里面Java应用程序根据需要进行待加载类的加载处理。

本发明实施例包括以下优点：

与现有技术相比，本发明的方法通过第一按需调用方式（即C/C++本地库按需调用方法）使C/C++应用在运行时加载指定版本的库，在应用安装、运行过程中，根据预设加载路径策略来确定指定加载路径，使应用程序在加载时优先加载自身封装的库，再是应用框架和依赖库，对Linux操作系统的预设库加载路径策略进行控制，以实现应用在运行阶段加载到所需要使用的库，从而实现了库的按需调用；通过第二按需调用方式（即java库多版本按需调用方法），通过应用沙箱防止库的不同版本之间相互干扰或冲突，通过定制化的加载策略及沙箱定制类加载器，破坏原有的的类代理加载机制，能够使java应用程序在运行时动态加载指定版本的类，在应用封装过程中，按照应用的需要，能够不受次序限制地加载应用实现层的类、应用框架层的类以及基础类。

此外，本发明能够避免重复编写相同的代码，提高了开发效率，能够避免每个应用程序都包含相同的代码，节省了内存空间，同时也可以对共享库进行版本管理，不同的应用程序可以使用不同版本的共享库，以满足其特定的需求。通过正确管理和维护共享库的版本来实现向后兼容性。

附图说明

图1是本发明的多语言运行库按需调用方法的一示例的步骤流程图；

图2是本发明多语言运行库按需调用方法中所配设的预设库加载路径策略的一具体示例的框架示意图；

图3是示出了本发明的多语言运行库按需调用方法中第二按需调用方式的一示例的示意图；

图4是本发明的多语言运行库按需调用方法的另一示例的步骤流程图；

图5是根据本发明的多语言运行库按需调用系统的一示例的结构示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

为了让开发者能够充分利用已经实现的功能，避免重新编写复杂的代码，同时以一种模块化和可重用的开发方式改进了软件开发的效率和灵活性，本发明提出了一种多语言运行库按需调用方法，该方法具体包括第一按需调用方式（即C/C++本地库按需调用方法）和第二按需调用方式（即java库多版本按需调用方法）。其中，第一按需调用方式（即C/C++本地库按需调用方法）是对Linux操作系统的预设库加载路径策略进行控制，以实现应用在运行阶段加载到所需要使用的库，从而实现了库的按需调用。第二按需调用方式（即java库多版本按需调用方法）通过应用沙箱防止库的不同版本之间相互干扰或冲突，通过定制化的加载策略及沙箱定制类加载器，破坏原有的的类代理加载机制，而在应用框架里面根据需要进行加载类和库。

需要说明的是，在发明中，运行库是指一组预编译的可重用代码模块，包含了常用的功能实现，如输入输出、网络通信、数据库连接等。此外，沙箱为应用提供的一个虚拟化的隔离环境，并保证程序所有操作都在这个隔离环境内执行。本发明的应用沙箱主要目的是提供应用跨发行版和同机运行的兼容运行机制，含有应用运行所依赖的库与框架的虚拟化环境，确保应用不受不同发行版应用运行环境差异的影响而可兼容运行。但是不限于，上述仅作为可选示例进行说明，不能理解成对本发明的限制。

实施例1

下面将结合图1、图2、图3和图4，具体说明本发明的多语言运行库按需调用方法。

图1是本发明的多语言运行库按需调用方法的一示例的步骤流程图。

首先，在步骤S101中，当Linux操作系统中指定应用在运行阶段运行、且根据需要进行待加载库的加载处理时，根据预设库加载路径策略，控制Linux操作系统中指定应用在运行阶段加载到所需要使用的库；所述库加载路径策略包括不同优先级的路径控制点以及各路径控制点所指向的搜索路径，其中，应用沙箱提前放置有路径控制点以及C/C++按需调用时所需的不同版本的应用程序，且所述路径控制点的控制点信息可编辑更新、应用程序可上传更新；通过使用以下特定参数中至少两者，在编译阶段和链接阶段限定共享库的搜索路径：路径参数、命令参数、编译参数、链接参数、系统参数。

为了确保C/C++应用程序能按需加载到所需库，需配设库加载路径策略（即预设库加载路径策略）。

在一具体实施方式中，例如对Linux操作系统的应用程序Y1（即指定应用）进行库加载或运行的场景。

具体地，配设不同优先级的多个路径控制点。所述多个路径控制点的控制点信息提前放置在应用沙箱中且可编辑更新，用于控制要执行的指定应用程序、应用程序自带系统库或基础库搜索路径，指定应用程序、应用程序自带系统库/基础库搜索路径、运行时基础库搜索路径、运行时系统库的搜索路径。

图2是本发明多语言运行库按需调用方法中所配设的预设库加载路径策略的一具体示例的框架示意图。

在图2的示例中，Linux操作系统的预设库加载路径策略包括多个路径控制点，这些路径控制点的优先级各不相同，其中，路径控制点的控制点信息提前放置在应用沙箱中且可编辑更新。

具体包括配设用于编译阶段的第一优先级路径控制点、用于运行阶段的第二优先级路径控制点、用于配置文件的第三优先级控制点、用于默认查找路径的第四优先级控制点。

进一步地，根据运行时和应用的支撑关系，以及不同系统的库与应用的运行库之间的支撑关系，对这些控制点以及指向的路径进行配设。

需要说明的是，上述配设有四级优先级控制点，但是不限于，还可根据实际系统需要或业务需要，配设三级优先级控制点、五级优先级控制点或更多级优先级控制点。此外，对于控制点及其优先级，可按现有已形成的对应关系来执行。上述仅作为可选示例进行说明，不能理解成对本发明的限制。

具体地，在编译阶段和链接阶段限定共享库的搜索路径：路径参数、命令参数、编译参数、链接参数、系统参数。

对于上述四级优先级控制点及其指向的搜索路径，第一优先级控制点是编译阶段指定的库加载路径控制点，是比其他三级优先级高的控制点，由C/C++应用直接使用，应用可在编译阶段使用例如-Wl、-rpath等GCC参数（是GNU的 C和 C++编译器的参数）对待加载库的库加载路径进行规定。第一优先级控制点用于指定应用程序自身的可执行文件、自身开发的运行库的加载路径，以及当运行时提供的应用运行库，及版本不满足应用要求时，应用自带的应用运行库所在的加载路径。

例如，在C/C++本地库按需调用的场景下，以FFmpeg为例，调用FFmpeg可实现对音频、视频进行编解码、转码、封装等操作。具体编译时可指定库加载路径，运行时采用指定库加载路径进行调用。在需要运行应用程序时，且在同一机器上同时存在与所述应用程序相对应的多个版本时，则优先加载指定路径（即指定库加载路径）的版本。

在一具体实施方式中，例如使用-Wl,-rpath 参数指定的路径如下：

例如，有一个自定义的共享库文件libexample.so存放在/path/to/mylibs 目录下。在编译一个指定程序时，需要使用上述这个自定义的共享库文件。可通过以下方式使用-Wl 和 -rpath 参数来指定共享库的查找路径（或搜索路径）：

gcc -o myprogram myprogram.c -L/path/to/mylibs -lexample -Wl,-rpath=/path/to/mylibs，上述命令中的参数使用说明如下。

其中，-L/path/to/mylibs指定了/path/to/mylibs作为编译阶段的库搜索路径，在该路径下搜索库文件。例如通知链接器，根据应用程序中的链接指令和库搜索路径来查找和加载所需的库文件。

-lexample表示要链接名为libexample.so的库文件。链接器会尝试在默认库搜索路径和 -L参数指定的库搜索路径中查找该库文件。

-Wl,-rpath=/path/to/mylibs用于通知链接器在应用程序运行时搜索共享库文件时，将 /path/to/mylibs 添加到运行时库搜索路径中。因此，应用程序运行时会优先在/path/to/mylibs 目录下搜索并加载所需的库文件。

通过使用这些参数，可在编译和链接阶段规定共享库的查找路径（或搜索路径），确保程序能够正确地链接和加载自定义的共享库文件。

对于运行阶段的控制点，第二优先级控制点是运行阶段环境变量LD_LIBRARY_PATH控制点，由C/C++应用程序直接使用，应用程序可通过修改LD_LIBRARY_PATH环境变量对待加载库的指定加载路径进行规定。第二优先级控制点的作用是针对应用及自带库的，LD_LIBRARY_PATH控制点在运行阶段进行规定比在编译阶段进行规定更为灵活。

需要说明的是，LD_LIBRARY_PATH环境变量适用于Linux系统，LD_LIBRARY_PATH环境变量包含一个或多个用冒号分隔的目录路径。当应用程序启动时，操作系统会在这些路径中按顺序搜索待加载库（例如为共享库文件），直到找到所需的库文件或搜索完所有路径。通过修改 LD_LIBRARY_PATH 环境变量，可将自定义的目录路径添加到共享库的加载路径中，从而控制应用程序在运行时搜索共享库文件的顺序和位置。

例如，假设有一个名为libexample.so 的共享库文件位于 /path/to/mylibs/ 目录下。可使用以下命令修改 LD_LIBRARY_PATH环境变量：

export LD_LIBRARY_PATH=/path/to/mylibs:$LD_LIBRARY_PATH。

通过将 /path/to/mylibs 添加到LD_LIBRARY_PATH中，操作系统在应用程序运行时会自动先在/path/to/mylibs目录下搜索和加载待加载库（例如共享库文件）。通过修改LD_LIBRARY_PATH环境变量，可优先使用自定义路径中的共享库文件，而不是默认路径中的库文件。这对于需要在特定路径下使用特定版本或自定义的共享库文件非常有用。

对于第三优先级控制点，是配置文件/etc/ld.so.conf控制点，由C/C++运行时的产品直接使用，所述产品例如为基础运行时、C++客户端基础运行时、C++服务端应用运行时的产品。第三优先级控制点指定了C/C++应用框架、应用运行库的加载路径。

例如，/etc/ld.so.conf文件包含一系列目录路径，每行一个目录路径，在文件中列出的路径即是共享库的搜索路径控制点。操作系统按照文件中路径出现的顺序依次搜索这些路径，直到找到所需的共享库文件或搜索完所有路径。通过编辑/etc/ld.so.conf文件，可添加、删除或修改共享库的搜索路径控制点。修改后的配置会影响系统范围内的共享库搜索行为。修改/etc/ld.so.conf文件后，需运行ldconfig命令来更新共享库缓存，以使新的搜索路径生效。

例如，假设要将/path/to/mylibs目录添加到共享库的搜索路径中。可以通过以下方式编辑/etc/ld.so.conf文件：sudo vi /etc/ld.so.conf。

然后，在文件的新一行中添加/path/to/mylibs 路径，保存并关闭文件。接下来，运行以下命令来更新共享库缓存：sudo ldconfig。

因此，操作系统在应用程序运行时会优先搜索/path/to/mylibs目录下的共享库文件。通过修改/etc/ld.so.conf文件，可在系统范围内控制共享库的搜索路径，并使新的路径生效。

对于第四优先级控制点，即系统默认的查找路径控制点，该控制点直接指向了/lib、/usr/lib等默认路径，这些默认路径包括C系统库与系统工具。

例如，当使用/lib、/usr/lib等默认路径来规定共享库的查找路径时，可直接在编译和链接命令中使用这些路径。

例如命令为gcc -o myprogram myprogram.c -L/lib -L/usr/lib -lexample。在上述命令中：-L/lib 指定了 /lib 作为编译阶段的库搜索路径控制点。链接器会在该路径下搜索共享库文件。

-L/usr/lib指定了/usr/lib作为编译阶段的另一个库搜索路径控制点。链接器也会在该路径下搜索共享库文件。

-lexample 表示要链接名为 libexample.so 的库文件。链接器会尝试在默认的库搜索路径（包括 /lib 和/usr/lib）以及 -L 参数指定的路径中查找该库文件。

通过使用上述这些默认路径，可直接将它们作为编译和链接阶段的库搜索路径，无需额外的参数。链接器会按照默认路径的优先级进行搜索并加载所需的库文件。

需要说明的是，在本发明中上述仅作为可选示例进行说明，不能理解成本发明的限制。

传统上，Java应用程序在运行时只能加载和使用单个版本的库。当应用程序依赖于不同版本的同一库时，可能会发生依赖冲突或版本不兼容的问题。这使得库的升级和管理变得复杂和困难。本发明的第二按需调用方式能够解决上述问题。

在步骤S102中，在java库多版本按需调用时，利用应用沙箱的运行环境，使得应用程序可在不同发行版本的操作系统所对应的机器上运行。

具体地，通过应用沙箱，各应用程序可被隔离在一个受限的环境中，与底层操作系统和其他应用程序相互独立，能够避免对底层系统的干扰和冲突，同时也提供了一种隔离环境，使得不同发行版的操作系统可在同一台设备机器上运行，并且能够相互通信和交互。应用沙箱的核心是沙箱的根文件系统，独立于宿主机根文件系统，应用程序的运行主要依赖于沙箱里的库和配置文件。应用沙箱仅在应用程序运行期间有效。

进一步地，应用沙箱可提供一层安全控制，能够限制应用程序对外部资源的访问权限。因此，通过引入应用沙箱，能够有效避免在库的多版本调用中，不同版本的库所存在的安全漏洞或不兼容问题，能够减少被恶意库利用的风险。

所述一层安全控制包括文件系统隔离机制。所述文件系统隔离机制具体是指应用沙箱使用独立的根文件系统，与宿主机的根文件系统分离，因此，应用程序只能在应用沙箱内访问特定的文件和目录，并且无法直接访问宿主机上的文件系统。

此外，应用沙箱可对类加载过程进行控制和管理，以确保只加载受信任的类或资源，从而提高了应用程序的安全性。

具体地，例如通过类加载器隔离，在应用沙箱内使用独立的类加载器（沙箱定制类加载器），与宿主机的类加载器隔离开来。由此，能够确保应用程序只能加载应用沙箱内部定义的类，而无法访问宿主机上的其他类。

更具体地，所述类加载策略包括应用沙箱能够设定自身的类加载策略。例如只允许加载指定目录下的类或者特定库文件中的类。由此，能够限制应用程序只能加载特定来源的类，防止恶意代码注入。

进一步地，还包括安全检查。具体在类加载过程中，应用沙箱能够进行安全检查，例如检查类的签名、权限等信息，以确保只加载经过验证和授权的类。这有助于防止恶意代码通过伪装成合法类的方式进行攻击。

此外，应用沙箱能够限制应用程序对某些类的访问权限。通过访问控制列表（ACL）或者白名单机制实现，只允许应用程序访问特定的类，防止非授权类的调用以实现类访问限制。只有经过验证的库被加载和使用。因此能够更好地管理应用程序的依赖关系，避免版本冲突和依赖问题。

此外，引入应用沙箱可为各应用程序提供更好的可扩展性。应用沙箱可在运行时动态加载库和卸载库，以满足应用程序的需求。因此能够实现更灵活的库管理和升级，而无需停止或重启整个应用程序。

通过第二按需调用方式（即java库多版本按需调用方法）中引入应用沙箱，能够提供更好的隔离性、安全性、管理和控制，并能够增强应用程序的可扩展性。因此，能够更好地处理库的多版本问题，同时保证应用程序的稳定性和安全性。

需要说明的是，通常情况下java应用程序是直接加载和使用java应用程序运行时中的库，但是如果java应用程序对库的版本有特殊要求，比如运行时带的log4j版本为1.0，而java应用程序需要使用log4j2.0版本，就需要java应用程序自带log4j2.0，并优先加载java应用程序自带的库。通过利用应用沙箱的运行环境，使得应用程序可以在不同发行版本的操作系统所对应的机器上运行。因此，能够避免在调用库的不同版本之间相互干扰或冲突影响应用程序的稳定性和可靠性版等问题，并能够提供更灵活的库管理和升级机制。

需要说明的是，上述仅作为可选示例进行说明，不能理解成本发明的限制。

接下来，在步骤S103中，在Java系统中创建代理类来加载和代理原始类的代理加载机制，基于所述代理加载机制在不修改原始类的情况下对原始类进行扩展、增强或拦截，通过定制化的加载策略及沙箱定制类加载器，在应用框架里面Java应用程序根据需要进行待加载类的加载处理。

图3是示出了本发明的多语言运行库按需调用方法中第二按需调用方式的一示例的示意图。

在Java系统中通过创建代理类来加载和代理原始类的机制（即代理加载机制）。所述代理加载机制中的代理是指委派加载。所述代理加载机制是在Java中通过创建代理类来加载和代理原始类的机制。

具体地，当有类/库加载需求时，先在拓展/上下文加载器中寻找需要加载的类/库，若是找到了则成功输出类/库。若是未找到，则根据加载策略在应用沙箱的加载器中继续寻找，若是找到了，则成功输出类/库；若是未找到，则在系统加载器中继续寻找，若是找到了，则成功输出类/库。若是未找到，则在拓展加载器中继续寻找；若是找到了，则成功输出类/库；若是没找到则在引导加载器中继续寻找，直至找到为止。

需要说明的是，应用沙箱的加载器和加载策略是通过特意设计而形成的。应用沙箱的加载器，又称沙箱定制类加载器，是在Java提供的类加载代理机制的基础上，将应用服务器扩展类加载、应用运行库加载、应用框架加载和应用加载联合成一个智能的混合类加载器，根据应用沙箱的需求进行定制，例如在应用沙箱所提供的运行环境中使用的自定义类加载器。沙箱定制类加载器主要用于在应用沙箱中控制类的加载和访问权限，来限制应用程序只能加载特定的类或资源，并防止恶意代码或不受信任的类被加载，能够在运行时自动加载，对应用无入侵，即不需要应用做额外的配置（例如使用默认配置）和开发。

对于加载策略，针对运行在应用沙箱内的应用类和依赖库分散在不同的安装层、多种不同的应用类型各自有不同的加载策略。在实现时，加载一个类之前，先判断加载策略有对这个类的加载顺序是否进行了定制。在确定进行了定制时，则按照定制的类加载路径来加载这个类。在确定未进行定制时，则按照默认的加载顺序到相应的路径下查找和加载类文件。混合类加载器的默认加载策略是优先加载应用实现需要的应用封装包，其次是应用框架和基础库，最后与应用服务器加载的运行时的系统结合，由此能够实现应用的零封装依赖，在运行时加载系统所提供的依赖库包。定制化加载策略依赖策略配置文件实现，可在策略配置文件中定制加载顺序，策略文件例如yaml文件、json文件或者其他文件。因此，应用能够根据自身的特点，配置类的加载顺序，例如使应用加载应用运行库下统一升级的一款依赖jar包，通过本发明的应用沙箱的加载器和加载策略，无需应用重新分装打包和安装，即可轻松实现。

基于代理加载机制在不修改原始类的情况下，对原始类进行扩展、增强或拦截。通过定制化的加载策略及沙箱定制类加载器，破坏原有的类代理加载机制，而在应用框架里面根据需要进行加载类（即加载待加载类）。沙箱定制类加载器继承了自标准的Java类加载器，并根据沙箱的需求进行定制，通过在应用沙箱中控制类的加载和访问权限，来限制指定应用程序只能加载特定的类或资源，并防止恶意代码或不受信任的类被加载。

具体地，按照应用的需要，能够不受次序限制地加载应用实现层的类、应用框架层的类以及基础类。

在需要运行应用程序时，且在同一机器上同时存在与所述应用程序相对应的多个版本时，则优先加载指定加载路径所对应的版本。

而在确定未包含指定加载路径时，使用默认假造路径进行加载。

在Java系统应用程序的运行依赖于应用沙箱所提供的运行环境。

所述应用沙箱利用沙箱定制类加载器隔离，以使在Java虚拟机中，不同的沙箱定制类加载器负责加载不同的类来形成类的加载隔离。

应用沙箱利用沙箱定制类加载器隔离的特性来增强安全性和隔离性。类加载器隔离是指在Java系统内的Java虚拟机中，不同的沙箱定制类加载器负责加载不同的类，从而形成类的加载隔离。每个类加载器都有自己的命名空间，各类加载器只能看到自己加载的类和它的父加载器所加载的类，而无法直接访问其他加载器加载的类。因此，能够避免类冲突和类版本不一致等问题。通过使用不同的类加载器为每个库版本创建独立的类加载环境进而避免了不同版本库之间的类冲突，并使得应用程序能够同时加载并使用不同版本的库。

需要说明的是，上述仅作为可选示例进行说明，不能理解成本发明的限制。

接下来，在步骤S104中，根据所确定的加载路径，获取待加载类或待加载库的文件。

例如，确定使用指定加载路径，则根据该指定加载路径从相应目录下获取待加载类或待加载库的文件。

例如，确定使用默认加载路径，则根据该默认加载路径从相应目录下获取待加载类或待加载库的文件。

需要说明的是，上述仅作为可选示例进行说明，不能理解成本发明的限制。

图4是示出了本发明的多语言运行库按需调用方法的另一示例的步骤流程图。

在另一示例中，本发明的多语言运行库按需调用方法还包括以下步骤S201。

需要说明的是，由于在图4的示例中的步骤S101、步骤S102、步骤S103、步骤S104与图1中的步骤S101、步骤S102、步骤S103、步骤S104大致相同，因此省略了对相同部分的说明。下面将具体说明步骤S201。

在步骤S201中，在进行加载处理之前，先判断预设库加载路径策略中是否包含与待加载库或待加载类的定制加载顺序。

如果包含与待加载库或待加载类的定制加载顺序，则按照指定加载路径来加载待加载类；

如果未包含与待加载库或待加载类的定制加载顺序，则按照默认加载路径查找待加载类或待加载库所对应的文件。

具体地，在第一按需调用方式（即C/C++本地库按需调用方法）里，应用安装、运行过程中，通过指定路径的方式，使应用在加载时优先从自身封装的库中加载相关文件，再是从应用框架和依赖库中加载相关文件；在第二按需调用方式（即java库多版本按需调用方法）中，按照应用的需要，能够不受次序限制地加载应用实现层的类、应用框架层的类以及基础类。

需要注意的是，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

与现有技术相比，本发明的方法通过第一按需调用方式（即C/C++本地库按需调用方法）使C/C++应用在运行时加载指定版本的库，在应用安装、运行过程中，根据预设加载路径策略来确定指定加载路径，使应用程序在加载时优先加载自身封装的库，再是应用框架和依赖库，对Linux操作系统的预设库加载路径策略进行控制，以实现应用在运行阶段加载到所需要使用的库，从而实现了库的按需调用；通过第二按需调用方式（即java库多版本按需调用方法），通过应用沙箱防止库的不同版本之间相互干扰或冲突，通过定制化的加载策略及沙箱定制类加载器，破坏原有的的类代理加载机制，而在应用框架里面根据需要进行加载类和库，使java应用程序在运行时动态加载指定版本的库，在应用封装过程中，按照应用的需要，能够不受次序限制地加载应用实现层的类、应用框架层的类以及基础类。

此外，本发明能够避免重复编写相同的代码，提高了开发效率，能够避免每个应用程序都包含相同的代码，节省了内存空间，同时也可以对共享库进行版本管理，不同的应用程序可以使用不同版本的共享库，以满足其特定的需求。通过正确管理和维护共享库的版本来实现向后兼容性。

实施例2

下述为本发明系统实施例，可以用于执行本发明方法实施例。对于本发明系统实施例中未披露的细节，请参照本发明方法实施例。

图5是根据本发明的多语言运行库按需调用系统的一示例的结构示意图。

如图5所示，本公开第二方面提供一种多语言运行库按需调用系统500，多语言运行库按需调用系统500包括第一加载处理模块510、提供应用沙箱模块520、第二加载处理模块530和文件获取模块540。

在一具体实施方式中，第一加载处理模块510当Linux操作系统中指定应用在运行阶段运行、且根据需要进行待加载库的加载处理时，根据预设库加载路径策略，控制Linux操作系统中指定应用在运行阶段加载到所需要使用的库；所述库加载路径策略包括不同优先级的路径控制点以及各路径控制点所指向的搜索路径，其中，路径控制点的控制点信息提前放置在应用沙箱中且可编辑更新；通过使用以下特定参数中至少两者，在编译阶段和链接阶段限定共享库的搜索路径：路径参数、命令参数、编译参数、链接参数、系统参数。

提供应用沙箱模块520在采用第一按需调用方式时，应用沙箱提前放置有路径控制点以及C/C++按需调用时所需的不同版本的应用程序，且控制点信息可编辑更新、应用程序可上传更新；同时，利用应用沙箱的运行环境，使得应用程序可在不同发行版本的操作系统所对应的机器上运行；在采用第二按需调用方式时，利用应用沙箱的运行环境，使得应用程序可在不同发行版本的操作系统所对应的机器上运行。

第二加载处理模块530在Java系统中创建代理类来加载和代理原始类的代理加载机制，基于所述代理加载机制在不修改原始类的情况下对原始类进行扩展、增强或拦截，通过定制化的加载策略及沙箱定制类加载器，在应用框架里面Java应用程序根据需要进行待加载类的加载处理。

文件获取模块540根据所确定的加载路径，获取待加载类的文件。

根据可选的实施方式，在进行加载处理之前，先判断预设库加载路径策略中是否包含与待加载库或待加载类的定制加载顺序。

根据可选的实施方式，包括：如果包含与待加载库或待加载类的定制加载顺序，则按照指定加载路径来加载待加载类或待加载库；如果未包含与待加载库或待加载类的定制加载顺序，则按照默认加载路径查找待加载类或待加载库所对应的文件。

根据可选的实施方式，进一步包括：在应用安装或应用运行过程中，按照指定加载路径来加载待加载库，使得优先从应用自身封装的库中加载，再从应用框架和依赖库中加载。

根据可选的实施方式，进一步包括：配设不同优先级的多个路径控制点，所述多个路径控制点的控制点信息提前放置在应用沙箱中，且控制点信息可编辑更新；具体包括配设用于编译阶段的第一优先级路径控制点、用于运行阶段的第二优先级路径控制点、用于配置文件的第三优先级控制点、用于默认查找路径的第四优先级控制点；所述路径控制点用于控制要执行的指定应用程序、应用程序自带系统库或基础库搜索路径，指定应用程序、应用程序自带系统库/基础库搜索路径、运行时基础库搜索路径、运行时系统库的搜索路径。

根据可选的实施方式，包括：在需要运行应用程序时，且在同一机器上同时存在与所述应用程序相对应的多个版本时，则优先加载指定加载路径所对应的版本。

根据可选的实施方式，在Java系统的应用程序的运行依赖于应用沙箱所提供的运行环境；所述应用沙箱利用沙箱定制类加载器隔离，以使在Java虚拟机中，不同的类加载器负责加载不同的类来形成类的加载隔离。

需要说明的是，上述仅作为可选示例进行说明，不能理解成本发明的限制。

与现有技术相比，本发明通过第一按需调用方式（即C/C++本地库按需调用方法）使C/C++应用在运行时加载指定版本的库，在应用安装、运行过程中，根据预设加载路径策略来确定指定加载路径，使应用程序在加载时优先加载自身封装的库，再是应用框架和依赖库，对Linux操作系统的预设库加载路径策略进行控制，以实现应用在运行阶段加载到所需要使用的库，从而实现了库的按需调用；通过第二按需调用方式（即java库多版本按需调用方法），通过应用沙箱防止库的不同版本之间相互干扰或冲突，通过定制化的加载策略及沙箱定制类加载器，破坏原有的的类代理加载机制，而在应用框架里面根据需要进行加载类和库，使java应用程序在运行时动态加载指定版本的库，在应用封装过程中，按照应用的需要，能够不受次序限制地加载应用实现层的类、应用框架层的类以及基础类。

此外，本发明能够避免重复编写相同的代码，提高了开发效率，能够避免每个应用程序都包含相同的代码，节省了内存空间，同时也可以对共享库进行版本管理，不同的应用程序可以使用不同版本的共享库，以满足其特定的需求。通过正确管理和维护共享库的版本来实现向后兼容性。

以上具体地示出和描述了本发明的示例性实施例。应可理解的是，本发明不限于这里描述的详细结构、设置方式或实现方法；相反，本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。