基于iOS平台获取应用程序功能的方法和装置与流程

本申请涉及计算机应用程序技术领域，具体而言，涉及一种基于iOS平台获取应用程序功能的方法和装置。

背景技术：

在软件的插件化架构实现中，有比较成熟的实现实例，比如eclipse的实现。eclipse的规范主要是基于java语言的架构，在其它语言(比如C++)环境中还没有建立标准化的插件系统。

传统的软件系统通过网络进行软件升级有如下几种方案：

1)、直接下载最新的安装包安装。

2)、软件系统自己检测新版本，提示用户下载并安装。

3)、在方法2的基础上，检测本地的版本，上报服务器，服务器给出增量包的地址，然后客户端下载服务器上的增量升级包并安装。

方案1)、2)都是比较常用的方法，但效率比较低，即使有一点小的变化也得下载整个安装包。方案3)的增量包的生成技术决定了下载的冗余度，而且上述3个方案都需要用户协助并且下载完成安装。

为了解决上述的问题，现有技术中，对于个人计算机(Personal Computer，即PC)客户端可以使用微内核插件化程序应用来实现软件的自动升级。该技术使用可扩展的插件结构，通过插件资源描述文件描述插件之间的依赖关系，微内核可根据插件资源配置文件嵌套加载插件资源。实现了自动化插件版本判断、插件的自动下载及基于插件的懒加载程序架构，实现了系统升级的自动化。但是该方案有如下缺点：

1)、未对移动平台进行说明，而且该方案中的方法也无法直接使用在iOS平台；

2)、未对插件在使用本地资源时的资源竞争问题提出解决方案，造成不同的插件及可能在本地资源使用时，发送资源竞争而导致系统错误。

由上分析可知，在现有技术中，对苹果移动设备操作系统上的应用程序进行升级 或者功能替换时，需要重新提交整个应用程序到苹果应用程序商店，进行漫长的审核，导致应用程序更新效率低。

针对现有技术中在移动设备操作系统上更新应用程序的效率低的技术问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请实施例提供了一种基于iOS平台获取应用程序功能的方法和装置，以至少解决现有技术中在移动设备操作系统上更新应用程序的效率低的技术问题。

根据本申请实施例的一个方面，提供了一种基于iOS平台获取应用程序功能的方法，该方法包括：发起用于获取动态库信息的请求至动态库信息服务器；接收动态库信息服务器根据请求返回的动态库信息，其中，动态库信息至少包括如下信息：动态库ID、入口视图控制器名称以及动态库下载路径；根据动态库ID在应用程序的第一沙盒路径下建立动态库目录，获取动态库存储路径；按照动态库下载路径从动态库存放服务器上下载动态库，并将动态库按照动态库存储路径存储至动态库目录下；将下载得到的动态库加载至应用程序中，以供应用程序进行调用。

根据本申请实施例的另一方面，还提供了一种基于iOS平台获取应用程序功能的装置，该装置包括：发起单元，用于发起用于获取动态库信息的请求至动态库信息服务器；接收单元，用于接收动态库信息服务器根据请求返回的动态库信息，其中，动态库信息至少包括如下信息：动态库ID、入口视图控制器名称以及动态库下载路径；建立单元，用于根据动态库ID在应用程序的第一沙盒路径下建立动态库目录，获取动态库存储路径；下载单元，用于按照动态库下载路径从动态库存放服务器上下载动态库，并将动态库按照动态库存储路径存储至动态库目录下；加载单元，用于将下载得到的动态库加载至应用程序中，以供应用程序进行调用。

采用本申请上述实施例，通过发起用于获取动态库信息的请求，并接收动态库信息服务器根据该请求返回的动态库信息，可以根据接收到的动态库信息从动态库存放服务器中将对应的动态库下载到应用程序中；在下载好动态库之后，该应用程序可以加载并调用该动态库，从而获取该动态库对应的功能，通过从动态库存放服务器上下载新的动态库或更新已有动态库的方法，达到更新应用程序功能或增加应用程序功能的目的。在本申请实施例中，在对应用程序进行升级或者功能替换时，无需重新提交整个应用程序到苹果应用程序商店，进行漫长的审核，而是只需要更新或增加所需功能对应的动态库即可达到更新应用程序功能或增加应用程序功能的目的。通过本申请实施例，解决了现有技术中在移动设备操作系统上更新应用程序的效率低的技术问题， 达到了无需重新安装整个应用程序，实现通过动态库更新应用程序功能或增加应用程序功能的技术效果，操作简单方便、操作效率高。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种计算机终端的结构框图；

图2是根据本申请实施例的基于iOS平台获取应用程序功能的方法的流程图；

图3是根据本申请实施例的一种可选的基于iOS平台获取应用程序功能的方法的时序图；

图4是根据本申请实施例的一种可选的沙盒分配方法的时序图；以及

图5是根据本申请实施例的基于iOS平台获取应用程序功能的装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本申请实施例进行描述的过程中出现的部分名词或术语适用于如下解释：

iOS 8：第八代苹果移动设备操作系统，是美国苹果公司为iPhone、iPad、iPod touch 等设备开发的移动操作系统。

动态库(framework)：即动态链接库，在本申请中是指在iOS系统(如iOS 8)中使用的后缀为.framework的动态链接库。

沙盒(sandbox)：由苹果公司在iOS系统(如iOS 8)上应用的沙盒机制，iOS应用程序只能在为该程序创建的文件系统中读取文件，不可以去其他地方访问，此区域被称为沙盒。

API：Application Programming Interface，即应用程序编程接口，是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

hook：即钩子，钩子实际上是一个处理消息的程序段，通过系统调用，把它挂入系统。每当特定的消息发出，在没有到达目的窗口前，钩子程序就先捕获该消息，亦即钩子函数先得到控制权。这时钩子函数即可以加工处理(改变)该消息，也可以不作处理而继续传递该消息，还可以强制结束消息的传递。

API hook：Application Programming Interface Hook，即应用程序编程接口钩子技术，是一种对API执行结果进行hook，可以改变API执行结果的技术。

Fishhook：是facebook提供的一个动态修改链接Mach-O符号表的开源工具。

Mach-O：为Mach Object文件格式的缩写，也是用于iOS可执行文件、目标代码、动态库以及内核转储的文件格式。

实施例1：

根据本发明实施例，还提供了一种基于iOS平台获取应用程序功能的方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，图1是根据本申请实施例的一种计算机终端的结构框图。如图1所示，用于基于iOS平台获取应用程序功能的计算机终端10可以包括一个或多个(图中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比 图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储应用程序软件的软件程序以及模块，如本发明实施例中的基于iOS平台获取应用程序功能的方法对应的程序指令/模块，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的漏洞检测方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

在上述运行环境下，本申请提供了如图2所示的基于iOS平台获取应用程序功能的方法。图2是根据本发明实施例一的基于iOS平台获取应用程序功能的方法的流程图，该方法可以包括如下步骤：

步骤S202，发起用于获取动态库信息的请求至动态库信息服务器。

本申请上述步骤S202中，应用程序可以作为应用程序客户端安装在终端中，应用程序可以根据不同的需求(如更新应用程序功能的需求或增加应用程序功能的需求等)，向存放有动态库信息的动态库信息服务器发起请求，以获取应用程序所需动态库的动态库信息。

步骤S204，接收动态库信息服务器根据请求返回的动态库信息。其中，动态库信息至少可以包括如下信息：动态库ID、入口视图控制器名称以及动态库下载路径。

本申请上述步骤S204中，动态库信息服务器可以根据接收到的应用程序发起的请求，将对应的动态库信息返回至应用程序中。具体地，动态库信息可以保存于动态库信息服务器中。应用程序在需要下载动态库时，向动态库信息服务器发起用于获取该动态库对应的动态库信息的请求，动态库信息服务器根据接收到的请求将对应的动态库信息(如上述的动态库ID、入口视图控制器名称(如入口ViewController名称)和动态库的下载路径)返回至应用程序。

步骤S206，根据动态库ID在应用程序的第一沙盒路径下建立动态库目录，获取 动态库存储路径。其中，在一种可选实施例中，上述动态库目录可以包括系统文件目录(如Documents目录)、临时缓存目录(如tmp目录)和资源库目录(如Library目录)等。

具体地，可以根据动态库ID在应用程序的第一沙盒路径(如，iOS 8为应用程序分配的系统沙盒路径，即应用程序沙盒路径)下建立该动态库的动态库目录，在建立好动态库目录之后，从该动态库目录中获取动态库存储路径，以便后续存储动态库及其相关资源(如，加载动态库所需的图片资源等)，由于动态库ID是唯一的，不同动态库所对应的动态库目录不同，也就是说不同的动态库的存储位置均不同，不会存在将不同动态库存储至同一位置的情况。可选的，建立好以后的目录如下：

Documents目录：应用程序沙盒路径/Documents/Plugins/动态库ID/Documents；

tmp目录：应用程序沙盒路径/Documents/Plugins/动态库ID/tmp；

Library目录：应用程序沙盒路径/Documents/Plugins/动态库ID/Library。

步骤S208，按照动态库下载路径从动态库存放服务器上下载动态库，并将动态库按照动态库存储路径存储至动态库目录下。

具体地，按照动态库下载路径完成从动态库存放服务器上下载对应的动态库，并将下载好的动态库按照动态库存储路径存储至动态库目录所指示的存储位置。

作为一个可选的实施例，步骤S208，按照动态库下载路径从动态库存放服务器上下载动态库，并将动态库按照动态库存储路径存储至动态库目录下可以包括：从动态库存放服务器上下载动态库的压缩文件；将下载到的动态库的压缩文件保存至动态库目录下的第一目录中；将第一目录中保存的动态库的压缩文件进行解压缩，生成动态库；将解压缩得到的动态库保存至动态库目录的第二目录中。

具体地，根据动态库下载路径，从动态库存放服务器上下载动态库对应的压缩文件，并将下载得到的压缩文件存储至动态库目录下的第一目录(如上述实施例中的tmp目录)下；将保存至第一目录的压缩文件解压缩得到动态库，并将解压缩得到的动态库移动至动态库目录的第二目录(如上述实施例中的Library目录)下，即完成对动态库的下载并将下载好的动态库存储至动态库目录。

步骤S210，将下载得到的动态库加载至应用程序中，以供应用程序进行调用。

本申请上述步骤S208可以实现，在下载好动态库之后，可以在应用程序中加载该动态库，因此可实现在对动态库进行调用之后，可以获取对应的动态库功能，从而达到更新应用程序功能或者增加应用程序功能的目的。

其中，动态库可以为自定义动态库，并可以作为功能插件动态加载到应用程序中，使应用程序调用该动态库，以获取相应的动态库功能。

采用本申请上述实施例，通过发起用于获取动态库信息的请求，并接收动态库信息服务器根据该请求返回的动态库信息，可以根据接收到的动态库信息从动态库存放服务器中将对应的动态库下载到应用程序中；在下载好动态库之后，该应用程序可以加载并调用该动态库，从而获取该动态库对应的功能，通过从动态库存放服务器上下载新的动态库或更新已有动态库的方法，达到更新应用程序功能或增加应用程序功能的目的。在本申请实施例中，在对应用程序进行升级或者功能替换时，无需重新提交整个应用程序到苹果应用程序商店，进行漫长的审核，而是只需要更新或增加所需功能对应的动态库即可达到更新应用程序功能或增加应用程序功能的目的。通过本申请实施例，解决了现有技术中在移动设备操作系统上更新应用程序的效率低的技术问题，达到了无需重新安装整个应用程序，实现通过动态库更新应用程序功能或增加应用程序功能的技术效果，操作简单方便、操作效率高。

需要说明的是，本申请实施例中的动态库可以为iOS 8所支持的动态库。

具体地，通过iOS 8支持的动态库编译(如，Xcode6编译技术)和调用方式，开发人员根据不同需求开发不同功能的动态库(如，开发人员可以自定义动态的功能，从而满足不同行业的业务需求)，通过网络按需将动态库下载到应用程序中，再由应用程序进行加载调用，达到iOS 8应用程序开发的目的。

通过本申请上述实施例，利用iOS 8支持的动态库，对iOS 8上的应用程序进行更新功能或增加功能的操作，方便快捷、操作效率高。

根据本申请上述实施例，步骤S208，将下载得到的动态库加载至应用程序中可以包括如下步骤：

步骤S1，根据动态库目录获取资源目录。

具体地，根据上述的动态库目录(如，动态库目录中存储有动态库的Library目录)获取资源目录(如bunld)。其中，bunld中存放有加载动态库所需的动态库本身的所有可用的资源文件，如，动态库显示界面的图片、xib文件(用于直观的展现出动态库运行时视图的外观)、数据文件等。

在一个可选的实施例中，bunld＝[NSBundle bundleWithPath:Path]，用于根据指定路径(如上述实施例中的动态库目录)获取所需的资源文件。

步骤S3，基于资源目录和入口视图控制器名称创建入口视图控制器。

在一种可选实施例中，可以利用资源目录(如bunld)和入口视图控制器名称(如入口ViewController名称)创建入口视图控制器(如，入口ViewController)。

可选地，可以通过如下程序实现入口视图控制器的创建：

其中，NSClassFromString()为iOS系统(如iOS 8)提供的API，其作用为根据类名获得相应的类；self.rootViewControllerName为入口视图控制器名称；那么ClassrootClass＝NSClassFromString(self.rootViewControllerName)为根据入口视图控制器名称获得对应的入口视图控制器类。

UIViewController为iOS系统(如iOS 8)提供的基础视图控制器类，上述的入口视图控制器类即为其子类；initWithNibName:bundle:为iOS系统(如iOS 8)提供的用视图控制器名称和资源目录创建视图控制器的方法；rootViewController为一个UIViewController的一个实例对象指针，可以指向任何UIViewController的子类实例对象，在本申请上述实施例中指向要创建的入口视图控制器；因此，rootViewController＝[[rootClass alloc]initWithNibName:self.rootViewControllerName bundle:self.bundle]为用入口视图控制器名称和资源目录创建一个入口视图控制器实例，并将其放到rootViewController指向的地址。

在该实施例中，将入口视图控制器放入rootViewController指向的地址之后，就完成了入口视图控制器的创建。

步骤S5，在应用程序的界面上展示入口视图控制器对应的根视图控制器，以完成动态库的加载。

具体地，将入口视图控制器对应的根视图控制器(如上述的rootViewController)展示在应用程序的界面上，以完成动态库的加载，以使应用程序可以调用动态库的相关功能。

在本申请上述实施例中，为实现对应用程序功能的更新或增加操作，在下载对应 的动态库之后，应用程序需要加载该动态库以将其作为功能插件在应用程序上展示出来，从而实现应用程序对该动态库进行调用。

在本申请上述实施例中，在将下载得到的动态库加载至应用程序中之后，上述的方法还可以包括：步骤S212，调用动态库对应的动态库功能，该步骤S212可以包括：

步骤S2121，检测应用程序是否触发运行动态库。具体地，检测应用程序是否触发运行该动态库(如上述实施例中的功能插件)，并在检测到应用程序触发了运行动态库的情况下，执行步骤S2122。

步骤S2122，调用动态库对应的系统文件路径接口。具体地，当应用程序调用动态库时，动态库需要访问本地资源以实现动态库的功能。为了达到上述目的，应用程序通过调用系统文件路径接口获得访问资源所需的访问路径，即调用系统文件路径接口获取动态库访问资源所需的沙盒路径。

但是，在通常情况下应用程序调用系统文件路径接口时返回的是应用程序所对应的第一沙盒路径。在这种情况下，若应用程序同时调用两个或多个不同的动态库，则将控制每个动态库都按照第一沙盒路径访问资源，这样就导致不同动态库在访问资源时发生资源竞争而导致系统错误。为了解决该问题，需要在系统文件路径接口将第一沙盒路径返回至应用程序之前，对系统文件路径接口将要返回的第一沙盒路径进行hook拦截。

步骤S2123，使用系统文件路径接口获取第一沙盒路径，对第一沙盒路径进行拦截，并读取第一沙盒路径下已经创建的动态库目录，得到拦截后的访问路径。具体地，通过API hook技术对系统文件路径接口的调用结果(即上述的第一沙盒路径)进行拦截，并将读取第一沙盒路径下已经创建的该动态库的动态库目录，使用该动态库目录替换调用结果中的第一沙盒路径，作为拦截后的访问路径保存至调用结果中。即，将该调用结果的第一沙盒路径重新定义为动态库的唯一沙盒路径(即上述的动态库目录)，由于动态库目录是根据唯一的动态库ID创建的，因此每个动态库所对应的动态库目录均是唯一的，即为每个动态库分配了独立的沙盒路径，避免了应用程序同时调用多个动态库时不同动态库获取到相同的路径(即第一沙盒路径)而导致不同动态库在访问本地资源时发生冲突的问题。

在一个可选的实施例中，拦截后的访问路径可以为：应用程序沙盒路径/Documents/Plugins/动态库ID/。

步骤S2124，将拦截后的访问路径返回至应用程序。具体地，将API hook拦截后得到的调用结果返回至应用程序，即将动态库目录返回至应用程序作为动态库访问资 源时的访问路径，而不是返回第一沙盒路径。

步骤S2125，控制动态库按照拦截后的访问路径访问资源，以调用动态库的功能。具体地，将与动态库对应的唯一的动态库目录作为访问路径返回至应用程序，由应用程序控制动态库按照该唯一的访问路径访问资源，解决了现有技术中各个动态库在使用本地资源时的资源竞争问题。

在上述实施例中，当应用程序没有运行任何动态库时，应用程序调用系统文件路径接口将返回第一沙盒路径(如实际的应用程序沙盒路径)；当应用程序运行动态库时，调用系统文件路径接口将返回拦截后重新定义的访问路径(即正在运行的动态库所对应的动态库目录)：应用程序沙盒路径/Documents/Plugins/动态库ID/。由于动态库ID是唯一的，因此得到的访问路径(即动态库目录)也是唯一的，即为每个动态库分配了独立的沙盒路径，避免了不同动态库在访问本地资源时由于资源访问冲突而导致系统错误的问题。

通过本申请上述实施例，为了避免动态库在使用本地资源时产生资源竞争而导致系统错误的问题，通过对系统文件路径接口进行API hook拦截，为不同的动态库分配唯一且独立的访问路径，使得每个动态库只能访问自己被分配的沙盒(即动态库目录所指示的存储区域)，从而实现动态库之间在访问本地资源时互不干扰的效果。

下面结合图3，以在应用程序的更新操作的应用场景为例，本申请上述实施例可以提供的一种可选方案如下所示。该方法可以包括如下步骤：

步骤S301，应用程序20向动态库信息服务器40发送动态库信息请求。

步骤S302，动态库信息服务器40根据请求将动态库信息返回应用程序20。

其中，动态库信息包括动态库ID、入口视图控制器名称以及动态库下载路径。

步骤S303，应用程序20根据动态库ID生成动态库目录。

其中，动态库目录可以包括系统文件目录(如Documents目录)、临时缓存目录(如tmp目录)和资源库目录(如Library目录)。

步骤S304，应用程序20根据动态库下载路径请求从动态库存放服务器60上下载对应的动态库。

步骤S305，动态库存放服务器60将动态库的压缩文件发送至应用程序20。

步骤S306，应用程序20将压缩文件保存至tmp目录并解压得到动态库。

步骤S307，应用程序20将动态库移动至Library目录。

步骤S308，应用程序20加载下载好的动态库。

步骤S309，应用程序20调用动态库，进入动态库功能。

步骤S310，动态库21调用结束，返回应用程序20。

在该实施例中，动态库为iOS 8所支持的动态库。

通过本申请上述实施例，利用iOS 8支持的动态库，在对应用程序进行升级或者功能替换时，无需重新提交整个应用程序到苹果应用程序商店，进行漫长的审核，而是只需要更新或增加所需功能对应的动态库即可达到更新应用程序功能或增加应用程序功能的目的，方便快捷，大大提高了应用程序更新效率。

下面结合图4，以分别获取两个动态库A或B的沙盒路径为例，对本申请上述实施例一种确定沙盒路径的方案进行详细介绍如下。如图4所示，该方法可以包括如下步骤：

步骤S401，将正在运行的动态库设置为动态库A。

步骤S402，进入动态库A子线程以获取动态库A的沙盒路径。

步骤S403，将动态库A的沙盒路径返回至应用程序20，以供应用程序控制动态库A按照返回的动态库A的沙盒路径访问本地资源。其中，动态库A的沙盒路径即本申请上述实施例中的第二沙盒路径。

步骤S404，将正在运行的动态库设置为动态库B。

步骤S405，进入动态库B子线程以获取动态库B的沙盒路径。

步骤S406，将动态库B的沙盒路径返回应用程序，以供应用程序控制动态库B按照返回的动态库B的沙盒路径访问本地资源。其中，动态库B的沙盒路径即本申请上述实施例中的第二沙盒路径。

在该实施例中，若不执行API hook拦截操作，那么动态库A和动态库B将返回相同的沙盒路径(即应用程序沙盒路径)，这将导致动态库A和动态库B在访问本地资源时发生冲突。通过本申请上述实施例，为正在运行的动态库A和动态库B分别分配了独立的访问路径，避免了动态库A和动态库B访问本地资源时的冲突。

此处需要说明的是，在一个可选的实施例中，需要进行API hook的系统文件路径接口可以包括如下三类：

1、沙盒相关API：API：NSString*NSHomeDirectory(void)，用于返回当前用户主 目录的路径；NSString*NSTemporaryDirectory(void)，用于返回可用于创建临时文件的路径目录；NSArray*NSSearchPathForDirectoriesInDomains(NSSearchPathDirectory directory,NSSearchPathDomainMask domainMask,BOOL expandTilde)，用于用户查找特定的目录，如：NSDocumentationDirectory,NSUserDirectory等等。

2、线程相关API：pthread_exit，用于终止调用它的线程并返回一个指向某个对象的指针；pthread_create，是操作系统(如iOS 8系统)的创建线程的函数；dispatch_group_async可以监听一组任务是否完成，完成后得到通知执行其他的操作；dispatch_async的功能是将代码块(如block)发送到指定线程去执行，当前线程不会等待，会继续向下执行。

3、资源相关API：[NSBundle mainBundle]是使用类方法创建一个NSBundle对象；[NSBundle allBundles]是使用NSBundle获取所有的bundle信息(由于iOS 8安全沙盒机制的限制，此处所指的所有的获取的资源，是应用程序的资源)。

对上述三类API进行分析可知，按照编译语言可以将上述三类API重新分为两类：C类型API和OC类型API。下面将分别针对C类型API和OC类型API的hook进行说明。

1、对于C类型API的hook：

根据苹果文档介绍，对于C类型API，通过fishhook可以重新链接/替换本地符号，以实现对C类型API的hook。

具体地，苹果的mach-o结构中的__DATA区有两个section和动态符号链接相关：__nl_symbol_ptr和__la_symbol_ptr。其中，__nl_symbol_ptr为一个指针数组，直接对应non-lazy绑定数据；__la_symbol_ptr也是一个指针数组，通过dyld_stub_binder辅助链接。<mach-o/loader.h>的section头提供符号表的偏移量。

其中，符号表中每一个结构都是一个nlist结构体，其中包含字符表偏移量。通过字符表偏移量最终确定函数指针。在hook C类型API时，通过对间接符号表的偏移量进行修改，可以提供一个假的nlist结构体，从而达到hook的目的。

2、对于OC类型API的hook：

iOS系统(例如iOS 8)提供了强大的运行时技术，可以动态修改selector字符串和对应的函数实现如下内容，从而实现对OC类型API的hook操作：

Method originalMethod＝class_getClassMethod(class,originalSelector)；

Method swizzledMethod＝class_getClassMethod(class,swizzledSelector)；

method_exchangeImplementations(originalMethod,swizzledMethod)。

通过本申请上述实施例，可以实现必要的系统文件路径API hook，使每个动态库都有独立的沙盒路径，以确保动态库之间本地资源的独立使用。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例2：

图5是根据本申请实施例的基于iOS平台获取应用程序功能的装置的示意图，如图5所示，该装置可以包括：发起单元51、接收单元53、建立单元55、下载单元57以及加载单元59。

其中，发起单元51用于发起用于获取动态库信息的请求至动态库信息服务器。具体地，应用程序可以作为应用程序客户端安装在终端中，应用程序可以根据不同的需求(如更新应用程序功能的需求或增加应用程序功能的需求等)，向存放有动态库信息的动态库信息服务器发起请求，以获取应用程序所需动态库的动态库信息。

接收单元53用于接收动态库信息服务器根据请求返回的动态库信息，其中，动态库信息至少包括如下信息：动态库ID、入口视图控制器名称以及动态库下载路径。

具体地，动态库信息服务器可以根据接收到的应用程序发起的请求，将对应的动态库信息返回至应用程序中。具体地，动态库信息可以保存于动态库信息服务器中。应用程序在需要下载动态库时，向动态库信息服务器发起用于获取该动态库对应的动态库信息的请求，动态库信息服务器根据接收到的请求将对应的动态库信息(如上述的动态库ID、入口视图控制器名称(如入口ViewController名称)和动态库的下载路径)返回至应用程序。

建立单元55用于根据动态库ID在应用程序的第一沙盒路径下建立动态库目录，获取动态库存储路径。其中，在一种可选实施例中，上述动态库目录可以包括系统文件目录(如Documents目录)、临时缓存目录(如tmp目录)和资源库目录(如Library目录)等。

具体地，可以根据动态库ID在应用程序的第一沙盒路径(如，iOS 8为应用程序分配的系统沙盒路径，即应用程序沙盒路径)下建立该动态库的动态库目录，在建立好动态库目录之后，从该动态库目录中获取动态库存储路径，以便后续存储动态库及其相关资源(如，加载动态库所需的图片资源等)，由于动态库ID是唯一的，不同动 态库所对应的动态库目录不同，也就是说不同的动态库的存储位置均不同，不会存在将不同动态库存储至同一位置的情况。可选的，建立好以后的目录如下：

Documents目录：应用程序沙盒路径/Documents/Plugins/动态库ID/Documents；

tmp目录：应用程序沙盒路径/Documents/Plugins/动态库ID/tmp；

Library目录：应用程序沙盒路径/Documents/Plugins/动态库ID/Library。

下载单元57用于按照动态库下载路径从动态库存放服务器上下载动态库，并将动态库按照动态库存储路径存储至动态库目录下。

具体地，按照动态库下载路径完成从动态库存放服务器上下载对应的动态库，并将下载好的动态库按照动态库存储路径存储至动态库目录所指示的存储位置。

作为一个可选的实施例，下载单元57可以包括：下载模块，用于从动态库存放服务器上下载动态库的压缩文件；第一保存模块，用于将下载到的动态库的压缩文件保存至动态库目录下的第一目录中；解压缩模块，用于将第一目录中保存的动态库的压缩文件进行解压缩，生成动态库；第二保存模块，用于将解压缩得到的动态库保存至动态库目录的第二目录中。

具体地，根据动态库下载路径，从动态库存放服务器上下载动态库对应的压缩文件，并将下载得到的压缩文件存储至动态库目录下的第一目录(如上述实施例中的tmp目录)下；将保存至第一目录的压缩文件解压缩得到动态库，并将解压缩得到的动态库移动至动态库目录的第二目录(如上述实施例中的Library目录)下，即完成对动态库的下载并将下载好的动态库存储至动态库目录。

加载单元59用于将下载得到的动态库加载至应用程序中，以供应用程序进行调用。

具体地，在下载好动态库之后，可以在应用程序中加载该动态库，因此可实现在对动态库进行调用之后，可以获取对应的动态库功能，从而达到更新应用程序功能或者增加应用程序功能的目的。

其中，动态库可以为自定义动态库，并可以作为功能插件动态加载到应用程序中，使应用程序调用该动态库，以获取相应的动态库功能。

采用本申请上述实施例，通过发起用于获取动态库信息的请求，并接收动态库信息服务器根据该请求返回的动态库信息，可以根据接收到的动态库信息从动态库存放服务器中将对应的动态库下载到应用程序中；在下载好动态库之后，该应用程序可以加载并调用该动态库，从而获取该动态库对应的功能，通过从动态库存放服务器上下 载新的动态库或更新已有动态库的方法，达到更新应用程序功能或增加应用程序功能的目的。在本申请实施例中，在对应用程序进行升级或者功能替换时，无需重新提交整个应用程序到苹果应用程序商店，进行漫长的审核，而是只需要更新或增加所需功能对应的动态库即可达到更新应用程序功能或增加应用程序功能的目的。通过本申请实施例，解决了现有技术中在移动设备操作系统上更新应用程序的效率低的技术问题，达到了无需重新安装整个应用程序，实现通过动态库更新应用程序功能或增加应用程序功能的技术效果，操作简单方便、操作效率高。

需要说明的是，本申请实施例中的动态库可以为iOS 8所支持的动态库。

具体地，通过iOS 8支持的动态库编译(如，Xcode6编译技术)和调用方式，开发人员根据不同需求开发不同功能的动态库(如，开发人员可以自定义动态的功能，从而满足不同行业的业务需求)，通过网络按需将动态库下载到应用程序中，再由应用程序进行加载调用，达到iOS 8应用程序开发的目的。

通过本申请上述实施例，利用iOS 8支持的动态库，对iOS 8上的应用程序进行更新功能或增加功能的操作，方便快捷、操作效率高。

根据本申请上述实施例，加载单元59可以包括：获取模块、创建模块和展示模块。

其中，获取模块用于根据动态库目录获取资源目录。具体地，根据上述的动态库目录(如，动态库目录中存储有动态库的Library目录)获取资源目录(如bunld)。其中，bunld中存放有加载动态库所需的动态库本身的所有可用的资源文件，如，动态库显示界面的图片、xib文件(用于直观的展现出动态库运行时视图的外观)、数据文件等。

在一个可选的实施例中，bunld＝[NSBundle bundleWithPath:Path]，用于根据指定路径(如上述实施例中的动态库目录)获取所需的资源文件。

创建模块用于基于资源目录和入口视图控制器名称创建入口视图控制器。在一种可选实施例中，可以利用资源目录(如bunld)和入口视图控制器名称(如入口ViewController名称)创建入口视图控制器(如，入口ViewController)。

可选地，可以通过如下程序实现入口视图控制器的创建：

其中，NSClassFromString()为iOS系统(如iOS 8)提供的API，其作用为根据类名获得相应的类；self.rootViewControllerName为入口视图控制器名称；那么Class rootClass＝NSClassFromString(self.rootViewControllerName)为根据入口视图控制器名称获得对应的入口视图控制器类。

UIViewController为iOS系统(如iOS 8)提供的基础视图控制器类，上述的入口视图控制器类即为其子类；initWithNibName:bundle:为iOS系统(如iOS 8)提供的用视图控制器名称和资源目录创建视图控制器的方法；rootViewController为一个UIViewController的一个实例对象指针，可以指向任何UIViewController的子类实例对象，在本申请上述实施例中指向要创建的入口视图控制器；因此，rootViewController＝[[rootClass alloc]initWithNibName:self.rootViewControllerName bundle:self.bundle]为用入口视图控制器名称和资源目录创建一个入口视图控制器实例，并将其放到rootViewController指向的地址。

在该实施例中，将入口视图控制器放入rootViewController指向的地址之后，就完成了入口视图控制器的创建。

展示模块用于在应用程序的界面上展示入口视图控制器对应的根视图控制器，以完成动态库的加载。

具体地，将入口视图控制器对应的根视图控制器(如上述的rootViewController)展示在应用程序的界面上，以完成动态库的加载，以使应用程序可以调用动态库的相关功能。

在本申请上述实施例中，为实现对应用程序功能的更新或增加操作，在下载对应的动态库之后，应用程序需要加载该动态库以将其作为功能插件在应用程序上展示出来，从而实现应用程序对该动态库进行调用。

在本申请上述实施例中，上述的装置还可以包括：调用单元，用于在将下载得到的动态库加载至应用程序中之后，调用动态库对应的动态库功能，其中，调用单元可以包括：检测模块、调用模块、拦截模块、读取模块、返回模块以及控制模块。

其中，检测模块用于检测应用程序是否触发运行动态库。具体地，检测应用程序是否触发运行该动态库(如上述实施例中的功能插件)。

调用模块用于在检测到应用程序触发运行动态库的情况下，调用动态库对应的系统文件路径接口。具体地，当应用程序调用动态库时，动态库需要访问本地资源以实现动态库的功能。为了达到上述目的，应用程序通过调用系统文件路径接口获得访问资源所需的访问路径，即调用系统文件路径接口获取动态库访问资源所需的沙盒路径。

但是，在通常情况下应用程序调用系统文件路径接口时返回的是应用程序所对应的第一沙盒路径。在这种情况下，若应用程序同时调用两个或多个不同的动态库，则将控制每个动态库都按照第一沙盒路径访问资源，这样就导致不同动态库在访问资源时发生资源竞争而导致系统错误。为了解决该问题，需要在系统文件路径接口将第一沙盒路径返回至应用程序之前，对系统文件路径接口将要返回的第一沙盒路径进行hook拦截。

拦截模块用于使用系统文件路径接口获取第一沙盒路径，对第一沙盒路径进行拦截；读取模块用于读取第一沙盒路径下已经创建的动态库目录，得到拦截后的访问路径。

具体地，通过API hook技术对系统文件路径接口的调用结果(即上述的第一沙盒路径)进行拦截，并将读取第一沙盒路径下已经创建的该动态库的动态库目录，使用该动态库目录替换调用结果中的第一沙盒路径，作为拦截后的访问路径保存至调用结果中。即，将该调用结果的第一沙盒路径重新定义为动态库的唯一沙盒路径(即上述的动态库目录)，由于动态库目录是根据唯一的动态库ID创建的，因此每个动态库所对应的动态库目录均是唯一的，即为每个动态库分配了独立的沙盒路径，避免了应用程序同时调用多个动态库时不同动态库获取到相同的路径(即第一沙盒路径)而导致不同动态库在访问本地资源时发生冲突的问题。

在一个可选的实施例中，拦截后的访问路径可以为：应用程序沙盒路径/Documents/Plugins/动态库ID/。

返回模块用于将拦截后的访问路径返回至应用程序。具体地，将API hook拦截后得到的调用结果返回至应用程序，即将动态库目录返回至应用程序作为动态库访问资源时的访问路径，而不是返回第一沙盒路径。

控制模块用于控制动态库按照拦截后的访问路径访问资源，以调用动态库的功能。具体地，将与动态库对应的唯一的动态库目录作为访问路径返回至应用程序，由应用程序控制动态库按照该唯一的访问路径访问资源，解决了现有技术中各个动态库在使用本地资源时的资源竞争问题。

在上述实施例中，当应用程序没有运行任何动态库时，应用程序调用系统文件路 径接口将返回第一沙盒路径(如实际的应用程序沙盒路径)；当应用程序运行动态库时，调用系统文件路径接口将返回拦截后重新定义的访问路径(即正在运行的动态库所对应的动态库目录)：应用程序沙盒路径/Documents/Plugins/动态库ID/。由于动态库ID是唯一的，因此得到的访问路径(即动态库目录)也是唯一的，即为每个动态库分配了独立的沙盒路径，避免了不同动态库在访问本地资源时由于资源访问冲突而导致系统错误的问题。

通过本申请上述实施例，为了避免动态库在使用本地资源时产生资源竞争而导致系统错误的问题，通过对系统文件路径接口进行API hook拦截，为不同的动态库分配唯一且独立的访问路径，使得每个动态库只能访问自己被分配的沙盒(即动态库目录所指示的存储区域)，从而实现动态库之间在访问本地资源时互不干扰的效果。

本实施例中所提供的各个模块与方法实施例对应步骤所提供的使用方法相同、应用场景也可以相同。当然，需要注意的是，上述模块涉及的方案可以不限于方法实施例中的内容和场景，且上述模块可以运行在计算机终端或移动终端，可以通过软件或硬件实现。

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

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。