应用程序的处理方法和装置技术领域
本申请涉及互联网技术领域，尤其涉及一种应用程序的处理方法和装置。
背景技术
随着信息化的发展，出现了大量的应用程序(APP)，其中，同一个厂商可以提供多个
APP。即使是不同的APP，尤其是同一个厂商提供的多个APP，可能存在相似的功能。但是，
目前每个APP都是各自开发，这就会造成效率低下和资源浪费。
发明内容
本申请旨在至少在一定程度上解决相关技术中的技术问题之一。
为此，本申请的一个目的在于提出一种应用程序的处理方法，该方法可以提高应用程
序的实现效率并降低资源浪费。
本申请的另一个目的在于提出一种应用程序的处理装置。
为达到上述目的，本申请第一方面实施例提出的应用程序的处理方法，包括：将预先
生成的组件保存在组件库中；在要启动应用程序的功能项时，根据所述应用程序的信息
和所述功能项的信息，从服务端获取特征数据；根据所述特征数据确定所述组件库中
需要使用的组件；根据所述需要使用的组件，启动所述功能项。
本申请第一方面实施例提出的应用程序的处理方法，通过在组件库中保存组件，可以
对应不同应用程序需要使用的相同组件开发一次，不需要对应每个应用程序分别开发
一次，从而可以提高应用程序的实现效率以及降低资源浪费。
为达到上述目的，本申请第二方面实施例提出的应用程序的处理装置，包括：保存模
块，用于将预先生成的组件保存在组件库中；获取模块，用于在要启动应用程序的功能项
时，根据所述应用程序的信息和所述功能项的信息，从服务端获取特征数据；确定模块，
用于根据所述特征数据确定所述组件库中需要使用的组件；启动模块，用于根据所述需
要使用的组件，启动所述功能项。
本申请第二方面实施例提出的应用程序的处理装置，通过在组件库中保存组件，可以
对应不同应用程序需要使用的相同组件开发一次，不需要对应每个应用程序分别开发
一次，从而可以提高应用程序的实现效率以及降低资源浪费。
本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明
显，或通过本申请的实践了解到。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显
和容易理解，其中：
图1是本申请一实施例提出的应用程序的处理方法的流程示意图；
图2是本申请实施例对应的应用程序系统示意图；
图3是本申请另一实施例提出的应用程序的处理方法的流程示意图；
图4是本申请另一实施例提出的应用程序的处理装置的结构示意图；
图5是本申请另一实施例提出的应用程序的处理装置的结构示意图。
具体实施方式
下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同
或类似的标号表示相同或类似的模块或具有相同或类似功能的模块。下面通过参考附图描
述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。相反，本申
请的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。
图1是本申请一实施例提出的应用程序的处理方法的流程示意图，该方法包括：
S11：将预先生成的组件保存在组件库中。
参见图2，本实施例对应的应用程序系统包括客户端程序(APP)和服务端程序。
客户端程序可以包括业务包、组件库、核心库、数据层、适配层和应用环境。
业务包是APP的私有包，包含运行在APP上的对应该APP业务特性的逻辑处理程序。
不同的APP可以具有对应不同业务特性的业务包。通过不同的业务包，可以将相同的组件
通过不同的样式、布局展示出来。
组件库、核心库和数据层能够被不同的APP公用。其中，组件库包含了展示在各个APP
上的通用组件。核心库包含一些基础库，例如：事件中心、主题库、模板缓存等。数据层
主要包含接口数据的定义，是数据通信基础。可以理解的是，虽然图2中未示出，但是，
不同APP可以公用的模块还可以包括其他模块，如流程管理模块和生命周期管理模块。
适配层是保证组件库、核心库等代码能够成功运行在各个APP环境的核心。其主要功
能是在业务层(包括业务包、组件库、核心库和数据层等)与APP层(即应用环境)之间
搭建一个桥梁，让组件库、核心库能够成功运行在不同的APP应用环境之上，无需破坏原
有APP的设计与特性。适配层一般在业务层初始化的时候通过依赖注册的方式，将协议与
不同APP特殊实现进行绑定。业务层通过调用适配层定义的接口，间接使用APP的特殊实
现。
应用环境包括一个或多个APP，多个APP可以位于相同或不同的移动终端上，APP不同
的APP具有不同的网络出口、用户行为检测等。
服务端用于为客户端提供数据。为了实现不同的APP通过统一接口从服务端获取数据，
在服务端设置有适配层。服务端的适配层响应APP的请求并返回相应于该APP的数据。服
务端的数据可以分为静态数据和动态数据，静态数据例如是固定不变的数据，动态数据例
如是根据不同情况变化的数据。
本实施例中，以组件是用户界面(User Interface，UI)组件为例，相应的，组件
可以保存在客户端的组件库中。
以一个公共组件为例，假设该公共组件的键值设置为A，则可以对应A设置相应的
组件实现类，假设该公共组件的组件实现类用B表示，则可以在组件库中保存键值A
的具体内容和组件实现类B的具体内容，并建立键值A和组件实现类B之间的关联关
系。具体的，键值A与组件实现类B之间的关联关系可以记录在组件库内的组件映射
配置表中。
与现有技术中各APP各自开发不同的是，公共组件A可以被不同的APP使用，从
而可以避免重复开发和资源浪费。
S12：在要启动应用程序的功能项时，根据所述应用程序的信息和所述功能项的信
息，从服务端获取特征数据。
其中，特征数据可以包括静态数据和/或动态数据，不同的APP可以具有不同的特
征数据。
根据要启动的功能项的不同，特征数据也相应是不同的，例如，在要进行页面内
容展示时，特征数据可以包括：与待展示的页面内容相关联的接口数据，以及页面展示的
布局模板数据。以待展示的页面内容是商品详情为例，接口数据例如包括：商品图片、商
品标题、商品价格、商品所在地等商品详情相关的信息。布局模板数据用于描述页面展示
的布局，例如包括需要使用哪些组件以及这些需要使用的组件的展示顺序等。
一些实施例中，所述根据所述应用程序的信息和所述功能项的信息，从服务端获取
特征数据，包括：
向服务端的适配层发送请求消息，所述请求消息中包含所述应用程序的信息和所述功
能项的信息；
接收服务端发送的特征数据，所述特征数据是所述服务端根据所述应用程序的信息和
所述功能项的信息获取的；
其中，所述服务端的适配层能够接收不同应用程序发送的请求消息。
例如，参见图2，在服务端设置有适配层，不同APP可以通过客户端的数据层向服务
端的统一的适配层发送请求消息，服务端中可以预先配置应用程序的信息、功能项的信息
及特征数据之间的关联关系，以根据应用程序的信息和功能项的信息获取相应的特征数据。
应用程序的信息例如包括：应用程序的名称和版本号，在商品详情页展示时，功能项的信
息例如是要展示的商品的ID。
S13：根据所述特征数据确定所述组件库中需要使用的组件。
例如，特征数据中可以包括需要使用的组件的信息，从而确定出需要使用的组件。
S14：根据所述需要使用的组件，启动所述功能项。
在确定出需要使用的组件后，可以采用组件库中保存的具体的组件实现类实现组
件的功能，以及，在需要使用的组件是多个时，组合多个需要使用的组件的功能，从
而启动应用程序的功能项。
本实施例中，通过在组件库中保存组件，可以对应不同应用程序需要使用的相同
组件开发一次，不需要对应每个应用程序分别开发一次，从而可以提高应用程序的实
现效率以及降低资源浪费。
图3是本申请另一实施例提出的应用程序的处理方法的流程示意图，该方法以要
启动的应用程序的功能项是展示应用程序内的商品详情页为例。该方法包括：
S31：将预先生成的组件保存在组件库中，所述组件能被不同的应用程序使用。
例如，预先生成的组件的键值是A，组件的实现类是B，则可以在组件库中保存键
值A和组件实现类B，并建立键值A和组件实现类B之间的关联关系。
S32：建立组件与视图数据模型之间的关联关系。
视图数据模型(view model)用于视图渲染，包含了UI组件的视图渲染所需的全部信
息。
具体的，可以在数据层中建立组件与视图数据模型之间的关联关系，例如，键值A对
应视图数据模型C。
S33：数据层接收应用程序的页面加载器发送的请求消息，所述请求消息中包含应用程
序的信息和商品ID。
应用程序的信息例如包括应用程序的名称和版本号。
商品ID是待展示详情页的商品的ID。
S34：向服务端的适配层发送请求消息，所述请求消息中包含所述应用程序的信息和
商品ID。
当数据层接收到页面加载器发送的请求消息后，可以确定要启动应用程序的商品详情
页，并向服务端的适配层发送请求消息，以获取特征数据。
S35：接收服务端发送的接口数据和布局模板数据，所述接口数据和布局模板数据是所
述服务端根据所述应用程序的信息和商品ID获取的。
其中，服务端可以预先关联保存商品ID与接口数据，从而可以根据商品ID获取到相
应的接口数据，接口数据例如包括：商品标题、价格、图片等商品详情相关信息。
另外，服务端还可以预先关联保存应用程序的信息与布局模板数据，从而可以根据应
用程序的信息获取到相应的布局模板数据。
服务端在预先保存的数据中获取接口数据和布局模板数据后，可以将其发送给客户端
的数据层。
S36：客户端根据布局模板数据确定需要使用的组件。
例如，布局模板数据中包含需要使用的组件的信息，如需要使用哪些组件以组件的排
列顺序等，从而可以确定出需要使用的组件。
S37：根据所述需要使用的组件，以及所述组件与视图数据模型之间的关联关系，确定
与所述需要使用的组件对应的初始的视图数据模型。
例如，需要使用的组件的键值是A，则由于预先建立的关联关系中与A对应的视图数
据模型是C，则可以确定初始的视图数据模型是C。
S38：根据所述布局模板数据和所述接口数据更新所述初始的视图数据模型，得到更新
后的视图数据模型。
其中，初始的视图数据模型中具体的数值可以是空，经过布局模板数据和接口数据的
处理，可以填充具体的数值，如填充商品价格、商品标题和商品图片等，从而得到更新后
的视图数据模型。
S39：采用更新后的视图数据模型进行页面渲染，展示渲染后的页面。
由于更新后的视图数据模型中包含了渲染所需的全部信息，因此，根据更新后的视图
数据模型在渲染后，可以得到商品详情页的具体内容，并展示给具体内容。
一些实施例中，当网络环境比较差时，可能会获取不到接口数据和布局模板数据，
此时，为了方便用户看到基本信息，则可以将渲染分为首次渲染和二次渲染，上述的
根据接口数据和布局模板数据生成更新后的视图数据模型，并根据更新后的视图数据
模型进行的渲染为二次渲染，在此之前可以先根据初始数据进行首次渲染。
例如，在S34和S35之间还可以包括：
S35’：根据初始的布局模板数据和基本信息进行页面的初始渲染，并展示初始渲染
后的页面。
其中，初始的布局模板数据和基本信息可以是预先配置的，以便用户看到基本的页面
内容，如展示商品标题和价格等。
本实施例中，通过不同的应用程序公用组件，可以实现通过跨APP的组件化解决
方案，通过一次开发，就能够将业务快速应用到移动终端不同的APP上，大大的节约
了研发成本，同时能够让业务快速同步上线。
图4是本申请另一实施例提出的应用程序的处理装置的结构示意图，该装置40包括：
保存模块41、获取模块42、确定模块43和启动模块44。
保存模块41，用于将预先生成的组件保存在组件库中，所述组件能被不同的应用程序
使用；
参见图2，本实施例对应的应用程序系统可以包括：客户端程序(APP)和服务端
程序，客户端程序可以包括：业务包、组件库、核心库、数据层、适配层和应用环境。
业务包是APP的私有包，包含运行在APP上的对应该APP业务特性的逻辑处理程序。
不同的APP可以具有对应不同业务特性的业务包。通过不同的业务包，可以将相同的组件
通过不同的样式、布局展示出来。
组件库、核心库和数据层能够被不同的APP公用。其中，组件库包含了展示在各个APP
上的通用组件。核心库包含一些基础库，例如：事件中心、主题库、模板缓存等。数据层
主要包含接口数据的定义，是数据通信基础。可以理解的是，虽然图2中未示出，但是，
不同APP可以公用的模块还可以包括其他模块，如流程管理模块和生命周期管理模块。
适配层是保证组件库、核心库等代码能够成功运行在各个APP环境的核心。其主要功
能是在业务层(包括业务包、组件库、核心库和数据层等)与APP层(即应用环境)之间
搭建一个桥梁，让组件库、核心库能够成功运行在不同的APP应用环境之上，无需破坏原
有APP的设计与特性。适配层一般在业务层初始化的时候通过依赖注册的方式，将协议与
不同APP特殊实现进行绑定。业务层通过调用适配层定义的接口，间接使用APP的特殊实
现。
应用环境包括一个或多个APP，多个APP可以位于相同或不同的移动终端上，不同的
APP具有不同的网络出口、用户行为检测等。
服务端用于为客户端提供数据。为了实现不同的APP通过统一接口从服务端获取数据，
在服务端设置有适配层。服务端的适配层能够响应APP的请求并返回相应于该APP的数据。
服务端的数据可以分为静态数据和动态数据，静态数据例如是固定不变的数据，动态数据
例如是根据不同情况变化的数据。
本实施例中，以组件是用户界面(User Interface，UI)组件为例，相应的，组件
可以保存在客户端的组件库中。
以一个公共组件为例，假设该公共组件的键值设置为A，则可以对应A设置相应的
组件实现类，假设该组件实现类用B表示，则可以在组件库中保存键值A的具体内容
和组件实现类B的具体内容，并建立键值A和组件实现类B之间的关联关系。具体的，
键值A与组件实现类B之间的关联关系可以记录在组件库内的组件映射配置表中。
与现有技术中各APP各自开发不同的是，公共组件A可以被不同的APP使用，从
而可以避免重复开发和资源浪费。
获取模块42，用于在要启动应用程序的功能项时，根据所述应用程序的信息和所述
功能项的信息，从服务端获取特征数据；
其中，特征数据可以包括静态数据和/或动态数据，不同的APP可以具有不同的特
征数据。
根据要启动的功能项的不同，特征数据也相应是不同的，例如，在要进行页面内
容展示时，特征数据可以包括：与待展示的页面内容相关联的接口数据，以及页面展示的
布局模板数据。以待展示的页面内容是商品详情为例，接口数据例如包括：商品图片、商
品标题、商品价格、商品所在地等商品详情相关的信息。布局模板数据用于描述页面展示
的布局，例如包括需要使用哪些组件以及这些需要使用的组件的展示顺序等。
一些实施例中，所述获取模块42用于根据所述应用程序的信息和所述功能项的信
息，从服务端获取特征数据，包括：
向服务端的适配层发送请求消息，所述请求消息中包含所述应用程序的信息和所述功
能项的信息；
接收服务端发送的特征数据，所述特征数据是所述服务端根据所述应用程序的信息和
所述功能项的信息获取的；
其中，所述服务端的适配层能够接收不同应用程序发送的请求消息。
例如，参见图2，在服务端设置有适配层，不同APP可以通过客户端的数据层向服务
端的统一的适配层发送请求消息，服务端中可以预先配置应用程序的信息、功能项的信息
及特征数据之间的关联关系，以根据应用程序的信息和功能项的信息获取相应的特征数据。
应用程序的信息例如包括：应用程序的名称和版本号，在商品详情页展示时，功能项的信
息例如是要展示的商品的ID。
确定模块43，用于根据所述特征数据确定所述组件库中需要使用的组件；
例如，特征数据中可以包括需要使用的组件的信息，从而确定出需要使用的组件。
启动模块44，用于根据所述需要使用的组件，启动所述功能项。
在确定出需要使用的组件后，可以采用组件库中保存的具体的组件实现类实现组
件的功能，以及，在需要使用的组件是多个时，组合多个需要使用的组件的功能，从
而启动应用程序的功能项。
本实施例中，通过在组件库中保存组件，且组件能够被不同的应用程序使用，可
以对应所以应用程序需要使用的相同组件开发一次，不需要对应每个应用程序分别开
发一次，从而可以提高应用程序的实现效率以及降低资源浪费。
一些实施例中，当所述功能项是页面内容展示时，所述特征数据包括：与待展示的页
面内容相关联的接口数据，以及页面展示的布局模板数据，所述布局模板数据中包含需要
使用的组件的信息，以确定需要使用的组件。
参见图5，所述装置40还包括：
建立模块45，用于建立组件与视图数据模型之间的关联关系；
所述启动模块44具体用于：
根据所述需要使用的组件，以及所述组件与视图数据模型之间的关联关系，确定与所
述需要使用的组件对应的初始的视图数据模型；
根据所述布局模板数据和所述接口数据更新所述初始的视图数据模型，得到更新后的
视图数据模型；
采用更新后的视图数据模型进行页面渲染，展示渲染后的页面。
一些实施例中，所述建立模块45具体用于：
在数据层，建立组件与视图数据模型之间的关联关系；
视图数据模型(view model)用于视图渲染，包含了UI组件的视图渲染所需的全部信
息。
具体的，可以在数据层中建立组件与视图数据模型之间的关联关系，例如，键值A对
应视图数据模型C。
参见图5，该装置40还包括：
接收模块46，用于接收所述应用程序的页面加载器发送的请求消息，所述请求消息中
包含所述应用程序的信息和所述功能项的信息，以确定要启动应用程序的功能项，并获取
所述应用程序的信息和所述功能项的信息。
应用程序的信息例如包括应用程序的名称和版本号。
功能项的信息是待展示详情页的商品的ID。
当数据层接收到页面加载器发送的请求消息后，可以确定要启动应用程序的商品详情
页，并向服务端的适配层发送请求消息，以获取特征数据。
一些实施例中，参见图5，该装置40还包括：
初始渲染模块47，用于根据初始的布局模板数据和基本信息进行页面的初始渲染，并
展示初始渲染后的页面。
其中，初始的布局模板数据和基本信息可以是预先配置的，以便用户看到基本的页面
内容，如展示商品标题和价格等。
可选的，所述组件是UI组件，所述组件库和所述数据层位于客户端，所述客户端还包
括：与应用程序对应的业务包，所述页面加载器位于所述应用程序对应的业务包内。
可选的，所述客户端还包括其他的能够被不同的应用程序公用的模块，所述其他的能
够被不同的应用程序公用的模块包括如下项中的一项或多项：核心库、流程管理模块和生
命周期管理模块。
可选的，所述客户端还包括适配层，所述适配层包括不同应用程序的实现信息，以便
数据层在渲染时根据相应应用程序的实现信息进行渲染。
上述的具体内容可以参见方法实施例中的相关描述，在此不再赘述。
本实施例中，通过不同的应用程序公用组件，可以实现通过跨APP的组件化解决
方案，通过一次开发，就能够将业务快速应用到移动终端不同的APP上，大大的节约
了研发成本，同时能够让业务快速同步上线。
需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而
不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”
的含义是指至少两个。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个
或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，
并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，
包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的
实施例所属技术领域的技术人员所理解。
应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实
施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或
固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下
列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路
的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现
场可编程门阵列(FPGA)等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可
以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，
该程序在执行时，包括方法实施例的步骤之一或其组合。
此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各
个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既
可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以
软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读
取存储介质中。
上述提到的存储介质可以是只读存储器，磁盘或光盘等。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、
或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点
包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一
定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何
的一个或多个实施例或示例中以合适的方式结合。
尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，
不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例
进行变化、修改、替换和变型。