CN103412757B - 移动应用个性化集成框架的实现方法 - Google Patents

Abstract

本发明提供一种移动应用个性化集成框架的实现方法，该框架由客户端和服务器端构成，包括以下步骤：1）开发者在进行移动应用序列化集成时，首先描述动作序列；2）得到动作序列后，海量存在的移动应用使得每个动作都有多个候选应用可以选择，移动应用运行平台提供了类库获取这些候选应用集合；3）在候选应用集合的基础上，利用服务器端中的应用序列推荐模块并基于用户兴趣相似度和应用序列偏好度预测算法为用户推荐理想的应用执行序列。本方法方便开发者进行移动应用的个性化集成设计，进行最优的应用序列推荐，而且通过移动应用序列偏好度预测算法解决移动应用执行序列的个性化推荐问题，提高用户体验。

Description

移动应用个性化集成框架的实现方法

技术领域

本发明涉及移动互联网应用开发领域，具体而言涉及一种移动应用个性化集成框架的实现方法，适以基于移动应用平台实现相应移动应用个性化集成开发工具和运行支撑机制。

背景技术

随着互联网和智能手机的日益普及，移动应用数量呈现爆炸式增长。截止2012年10月份，苹果App Store和Google Play移动应用数量均超过70万。App Store平台应用下载总数超过500亿次，Google Play平台应用下载总数超过480亿次。海量存在的移动应用给人们带来了新的机遇和挑战。

从开发者角度看，基于大量已有移动应用快捷构造新的应用成为了可能。在开发过程中，若能将已有的成熟移动应用集成进来，无疑会大大缩短开发周期，降低开发风险，同时保证产品质量。但当前大部分的移动应用开发工具对应用集成的支持仅停留在应用编程接口和底层运行机制部分，尚未出现更高层次的面向执行流程的集成支持。以当前典型的移动应用平台Android为例，虽然提供了意图（Intent）机制用于不同应用间相互调用和交换数据，但这种机制对移动应用集成的支持仅停留在应用编程接口层面，带来了两个问题：1）新应用请求是开发者硬编码得到的，在发起该应用请求时，会弹出一个候选应用对话框，用户每次都需要从候选列表中点选应用，虽然可以设置默认应用，但难以构造一个统一的方法用于智能地过滤候选应用列表；2）限制开发者对更多的应用进行序列化集成以完成更强大的功能，以下述场景为例，某开发者希望完成一个很常见的功能：首先获取一幅图片，接着进行图片美化，最后将经过编辑后的图片分享出去。这个功能中的每一步均有大量成熟的移动应用可以利用，拍照类和文件浏览类应用可以获取图片，图片编辑类应用可以处理图片，微博等社交化应用可用于分享。开发者不希望进行重复开发，期望能直接调用一个已存在应用构成的序列完成上述流程，即移动应用的“序列化复用”，现有的移动应用开发工具无法实现类似功能。

从用户角度看，海量存在的移动应用使得选取符合自己个性化需求的应用成为可能。移动应用推荐系统通过获取用户、上下文、应用之间的潜在关联，为用户进行个性化应用推荐，但是目前大量的移动应用推荐系统集中在单个移动应用的个性化推荐问题上，未见面向用户个性化需求的移动应用执行序列推荐方法。在移动应用执行序列环境下，用户在执行过程中的每一步都要从“同 斥”的应用列表中选取符合自己喜好的应用，无疑浪费了大量时间，若选取到不理想的应用，用户还有可能停止该动作序列，甚至卸载应用，因此如何得到一个理想的移动应用执行序列是亟待解决的问题。

发明内容

针对现有技术存在的不足，本发明旨在提供一种移动应用个性化集成框架的实现方法，以一套意图流程描述执行语言，方便开发者从更为自然的执行流程角度完成新移动应用的构造，同时以一个移动应用序列偏好度预测算法，为用户解决移动应用执行序列的个性化推荐问题，适以基于移动应用平台实现相应移动应用个性化集成开发工具和运行支撑机制。

为达成上述目的，本发明所采用的技术方案如下：

一种移动应用个性化集成框架的实现方法，该框架由客户端和服务器端构成，其中客户端为开发者提供了集成开发工具，服务器端用于收集用户信息并生成推荐的动作序列返回至客户端，该方法包括以下步骤：

1）开发者在进行移动应用序列化集成时，首先描述动作序列；

2）得到动作序列后，海量存在的移动应用使得每个动作都有多个候选应用可以选择，移动应用运行平台提供了类库获取这些候选应用集合；

3）在候选应用集合的基础上，利用服务器端中的应用序列推荐模块并基于用户兴趣相似度和应用序列偏好度预测算法为用户推荐理想的应用执行序列；

其中：前述动作代表发起某种类型的应用请求，其具有一数据结构<action,<type,uri>,category,<key,value>>，其中action指定请求的动作名称，<type,uri>指定请求的数据类型和数据源，category指定响应请求动作的组件的类别信息，<key,value>指定请求时携带的附加信息；

前述动作序列具有形如<X,Y,Z,...>的顺序序列，其中X，Y，Z为一个动作或多个动作的逻辑并；

前述移动应用具有形如<A,<package,class>>的数据结构，其中A为一个动作，<package,class>为能响应A的具体移动应用的组件信息，package对应于移动应用的包名，class对应于组件的类名；

前述应用序列是形如〈a,b,c,...〉的由移动应用构成的顺序序列，其中α_i表示第i个移动应用，α.size表示序列长度。

进一步，在步骤1）中描述动作序列时，开发者使用意图过程执行语言IPEL，IPEL基于可扩展标记语言XML，语法结构由XSD约束，其中：

IPEL流程从<process>元素开始，该<process>元素用于唯一的标识流程，<request>元素表示一次功能请求，其describe属性用于对该功能请求进行描述，skip属性用于标识该步是否可以跳过，reselect属性用于标识该步是否可 以重新选择；

每次功能请求通过<pick>或<invoke>元素描述，其中：

<invoke>元素包含一个<intent>子元素，表示该功能只由一个固定的动作完成；

<pick>元素拥有多个<intent>子元素，每个子元素代表了一个请求动作，其中：

子元素<intent>定义了<action>、<category>、<data>、<extra>四个子元素，<action>元素指定请求的动作名称，<category>包含响应请求动作的组件的类别信息，，<data>元素包含需要传递的数据信息，其中type属性标记数据的MIME类型，uri属性标记数据源地址，<extra>元素包含动作携带的附加信息。

进一步，在前述步骤3）进行应用序列推荐时，对于动作序列中的每一步，用户u都有一个候选移动应用集合，从每步的候选移动应用集合中选取一个应用，即构成了一个候选应用执行序列α；通过计算用户兴趣相似度得到用户相似度矩阵后，取出和用户u最相似的K个用户在完成该动作时采用的应用执行序列，构成集合S；再利用应用序列偏好度预测算法，以α和S作为算法的输入，输出是预测的用户u对候选应用序列α的偏好度；得到每个候选应用执行序列的偏好度之后，选取偏好度最大的候选应用序列，即是推荐给用户的最优应用序列。

进一步，在前述应用序列推荐过程中，采用如下公式计算用户兴趣相似度：

其中，N(u)、N(v)分别表示用户u和v安装的应用集合，N(i)表示安装了应用i的用户集合，该算法惩罚了用户u和v的共有应用集合中热门应用对兴趣相似度的影响。

由以上本发明的技术方案可知，本发明的有益效果在于通过定义了意图流程描述执行语言，方便开发者从更为自然的执行流程角度完成新移动应用的构造；而且通过移动应用序列偏好度预测算法解决移动应用执行序列的个性化推荐问题，方便开发者进行移动应用的个性化集成设计，进行最优的应用序列推荐，使用户可以从众多移动应用中选择符合自己个性化需求的应用成为了可能，提高用户体验。

附图说明

图1为移动应用个性化集成框架的实现原理图。

图2为客户端的原理示意图。

图3为服务器端的原理示意图。

图4为实际应用场景中一个动作序列实例的执行过程。

具体实施方式

为了更了解本发明的技术内容，特举具体实施例并配合所附图式说明如下。

如图1-3所示，根据本发明的较优实施例，由于Android平台应用编程接口开放度较高，有良好的运行机制支撑应用间相互调用，基于Android平台初步实现了移动应用个性化集成框架。参考图1，框架包含客户端和服务器端两部分，客户端为开发者提供了一套集成开发工具，服务器端用于收集用户信息并生成推荐的动作序列返回至客户端。本实施例中，服务器端以一个在SAE（Sina App Engine）上搭建的简易服务器为例，当然，服务器端也可以部署在其他平台上，只需开发者修改相应的客户端配置文件，在该框架下开发者无需对服务器端进行配置。

客户端通过JAVA语言编写，以包的形式提供给开发者。客户端的整体架构如图2所示，客户端主要功能包括：向服务器端上传用户信息；从服务器端获取移动应用类别信息存储至本地数据库；解析开发者编写的IPEL脚本，生成候选应用集合上传至服务器；获取推荐的应用序列。

参考图1-3所示，开发者在进行移动应用序列化集成时，首先描述动作序列。

动作由大写字母表示，例如A，代表发起某种类型的应用请求，其具有一数据结构<action,<type,uri>,category,<key,value>>，其中action指定动作名称，<type,uri>指定请求的数据类型和数据源，category指定请求的类别，<key,value>指定请求时携带的附加信息。

动作序列具有形如<X,Y,Z,...>的顺序序列，其中X，Y，Z为一个动作或多个动作的逻辑并A∪B∪...。

移动应用a具有形如<A,<package,class>>的数据结构，其中A为一个动作，<package,class>为能响应A的具体移动应用的组件信息，package对应于移动应用的包名，class对应于组件的类名。

应用序列α是形如〈a,b,c,...〉的由移动应用构成的顺序序列，其中α_i表示第i个移动应用，α.size表示序列长度。

开发者在描述动作序列时，使用意图过程执行语言IPEL，IPEL基于可扩展标记语言XML，语法结构由XSD约束。IPEL的属性定义如下表所示：

参考下表所示的<intent>复合元素定义，<intent>定义了<action>、<category>、<data>、<extra>四个子元素，<action>元素的name属性为请求的动作名称，<category>包含了响应该动作的组件的类别信息，<data>元素包含需要传递的数据信息，其中type属性标记数据的MIME（多用途互联网邮件扩展，Multipurpose Internet Mail Extensions）类型，uri属性标记数据源地址，<extra>元素包含动作携带的附加信息。

由于移动手机平台的特殊性：同一时间只能和一个应用交互，IPEL只考虑了顺序类型的功能流程，而不考虑并发等其他类型。完整的IPEL流程从<process>元素开始，该元素用于唯一的标识流程；<request>元素表示一次功能请求，其describe属性用于对该功能请求进行描述，例如“获取图片”，skip属性用于标识该步是否可以跳过，reselect属性用于标识该步是否可以重新选择。完整的IPEL语法结构如下表所示：

每次功能请求通过<pick>或<invoke>元素描述，其中<pick>和<invoke>复合元素定义如下表所示：

有时开发者希望某个功能可以由多个不同类型的动作完成，例如获取一幅图片，该功能可以通过拍照或浏览文件两种不同类型的动作完成，定义<pick>元素描述此类请求。<pick>元素拥有多个<intent>子元素，每个子元素代表了一个请求动作。<invoke>元素则表示该功能只由一个固定的动作完成。

在得到动作序列后，海量存在的移动应用使得每个动作都有多个候选应用可以选择，移动应用运行平台提供了类库获取这些候选应用集合。例如Android平台。

参考图1结合图2-3，若一款移动应用基于本实施例的框架来实现，则用户在初次安装该款应用时，本机上的已安装应用信息会被上传至服务器，这是由UploadService类完成的。该类继承自IntentService类，负责完成客户端和服务器端的网络通信，其他需要上传至服务器的数据包括：动作序列中响应每个动作的经过筛选的候选移动应用集合、用户在完成某个动作序列所采用的应用序列。同时，客户端中的PackageChangedReceiver类负责监听用户卸载旧应用或安装新应用类型的操作，一旦监听到这类操作后就通过UploadService类与服务器进行通信，刷新用户的已安装应用信息。

参考图2所示，客户端的另一功能是解析IPEL脚本，最终生成候选移动应用序列。用户编写的IPEL脚本置于Android项目的资源文件夹assets目录下。ProcessParser类基于开源XML解析工具dom4j，通过分析脚本中的<pick>元素和<invoke>元素，生成自定义的WrappedIntent类，按顺序放入表（List）中。Android应用框架层提供了PackageManager类，该类包含方法queryIntentActivities可以分析Intent请求，返回由ResolveInfo类型的对象构成的List，每个对象包含一个可以响应指定动作的具体移动应用信息。

这种基于Intent Filter机制得到的候选应用集合粒度过大，例如，某开发者希望利用社交类应用分享一幅图片，该动作对应的Intent请求中子元素<action>的actionname属性值为“SEND”，解析该Intent请求后得到的候选应用列表中不仅包含微博、人人等社交类应用，还包括网盘、邮箱、蓝牙等无关应用，因此需要对应用集合进行过滤。考虑到谷歌市场（Google Play）将移动应用分为个性化、交通、体育等34个分类，我们将分类概念引入到IPEL语法中，每个<intent>元素均包含这样一个子元素：

<extra key="category_in_google_play"value="No.;No.;…"/>

该<extra>元素的value属性由数字字符串序列组成，每个数字字符串代表一个分类，由分号隔开。例如微博和Facebook属于“社交类”应用，编码为25，而网盘属于“效率类”应用，编码为23，邮箱属于“工具类”应用，编码为27。利用编码信息即可把响应同一Intent请求的不同类别的应用区分开来。

从数据库中读取这些应用所属的类别，筛选类型不符的应用，即得到了一个动作的候选应用集合，这就是过滤模块的功能。对每个WrappedIntent类均进行此操作，即可得到该动作序列中每步的候选应用集合，上传至服务器。

Activity作为Android最重要的组件之一，是应用形成的基础，负责系统和用户间的交互。但是它在响应一次应用请求后即返回，为克服这种“一步式”响应机制，我们自定义了ProcessHandlerActivity类。该类继承自Activity类，重写了onActivityResult方法，在响应了一次应用请求后，检测是否有后续请求，有的话则发起新的Intent请求，以此实现“多步式”顺序响应机制，达到“序列化复用”已安装应用的目的。在得到推荐的移动应用序列之后，该类在运行时刻绑定已安装应用和用户进行交互。为了展示响应Intent请求的候选应用集合，并且记录候选集合的点击事件，需要自定义一个Intent请求响应界面，这部分实现也包含在该类中。

参考图3所示，服务器端由PHP语言编写，整个架构的主要功能有：向Google服务器提交HTTP请求，获取某个移动应用的类别信息并返回至客户端；根据用户已安装的应用信息计算用户相似度矩阵；为用户推荐理想的应用序列。

在进行应用序列推荐时，对于动作序列中的每一步，用户u都有一个候选移动应用集合，从每步的候选移动应用集合中选取一个应用，即构成了一个候选应用执行序列α。通过计算用户兴趣相似度得到用户相似度矩阵后，取出和用户u最相似的K个用户在完成该动作时采用的应用执行序列，构成集合S。再利用应用序列偏好度预测算法（SequencePreference Evaluation算法），α和S构成了算法的输入，输出是预测的用户u对候选应用序列α的偏好度。得到每个候选应用执行序列的偏好度之后，选取偏好度最大的候选应用序列，即是推荐给用户的最优应用序列。

本实施例中，采用如下公式（1）来计算用户兴趣相似度：

其中，N(u)、N(v)分别表示用户u和v安装的应用集合，N(i)表示安装了应用i的用户集合，该算法惩罚了用户u和v的共有应用集合中热门应用对兴趣相似度的影响。

用户在第一次使用基于本框架开发的移动应用时，手机中已安装的应用列表会上传至服务器数据库。获取移动应用类别模块（图3中简写为获取应用类别）向Google服务器发送携带应用包名信息的HTTP请求，返回包含指定应用的页面信息。PHP语言自定义的DOMDocument类可以解析HTML文档，从中获取 到类别信息，返回至客户端。

服务器端的数据库中存储的信息是“用户-应用”信息对，若对两两用户直接使用前述公式（1）计算相似度，时间复杂度过高。为此，首先建立应用到用户的倒排表，接着利用公式（1）计算用户间的相似度，得到用户相似度矩阵。

客户端会将动作序列的候选应用集合上传至服务器，从每个动作的候选应用集合中任意选取一个应用，即组成了一个候选应用序列α；从用户相似度矩阵中选取K个最相似的用户，从数据库中读取他们关于此动作序列的应用序列，构成应用序列集合S。α和S即构成了应用序列偏好度预测算法的输入，输出即是用户对于该候选应用序列的偏好度。从所有可能的应用序列组合中，选取偏好度最大的应用序列，即得到了推荐结果。其中，应用序列偏好度预测算法如下表所示：

本实施例的移动应用个性化集成框架在实现时，需由Eclipse和ADT（AndroidDevelopment Tools）构成Android平台下的开发环境，开发者在使用该工具时，需要在项目中导入客户端JAVA包。还需在AndroidManifest.xml中对UploadService和PackageChangedReceiver进行注册，如下表所示：

同时添加读取手机状态和连接网络的权限，如下表所示：

下面以一个应用实例说明本发明的实现。假设某开发者希望在应用中集成这样一个动作序列：首先通过拍照或文件浏览类型的动作获取一幅图片，接着通过图片编辑类型的动作对图片进行处理，最后通过分享类型的动作将图片分享至社交网络。开发者首先遵循IPEL语法规则编写image_share.ipel脚本文件。以图片编辑类型的动作为例，在脚本中如下定义：

开发者将包含该功能的Activity组件的父类置为ProcessHandlerActivity类，接着在启动该动作序列的代码段调用startProcess方法即可触发应用序列。以开发者在按下Button(即按钮)控件时执行该动作序列为例，执行过程如图4所示，开发者所定义的IPEL脚本被解析为一个完整的动作序列。在按下Button后触发该动作序列，每个动作都对应于一个经过筛选的候选应用集合，若和服务器端进行通信则会获取一个推荐的应用序列，如“ES文件浏览器->Fotolr照片编辑器->微博”，此时候选应用列表不会弹出，而是直接进入指定应用，这样 可以节省用户时间。可以看出，不同用户在使用该功能时会基于本机已安装应用列表得到不同的应用序列，这种机制为用户带来了更好的使用体验。

综上所述，本发明的移动应用个性化集成框架的实现方法通过定义了意图流程描述执行语言，方便开发者从更为自然的执行流程角度完成新移动应用的构造；而且通过移动应用序列偏好度预测算法解决移动应用执行序列的个性化推荐问题，方便开发者进行移动应用的个性化集成设计，进行最优的应用序列推荐，使用户可以从众多移动应用中选择符合自己个性化需求的应用成为了可能，提高用户体验。

虽然本发明已以较佳实施例揭露如上，然其并非用以限定本发明。本发明所属技术领域中具有通常知识者，在不脱离本发明的精神和范围内，当可作各种的更动与润饰。因此，本发明的保护范围当视权利要求书所界定者为准。

Claims (3)

1.一种移动应用个性化集成框架的实现方法，该框架由客户端和服务器端构成，其中客户端为开发者提供了集成开发工具，服务器端用于收集用户信息并生成推荐的应用执行序列返回至客户端，其特征在于，该方法包括以下步骤：

1)开发者在进行移动应用序列化集成时，首先描述动作序列；

2)得到动作序列后，海量存在的移动应用使得每个动作都有多个候选应用可以选择，移动应用运行平台提供了类库获取这些候选应用集合；

3)在候选应用集合的基础上，利用服务器端中的应用序列推荐模块并基于用户兴趣相似度和应用序列偏好度预测算法为用户推荐理想的应用执行序列；

其中：前述动作代表发起某种类型的应用请求，其具有一数据结构<action,<type,uri>,category，<key,value>>,其中action指定请求的动作名称，<type,uri>指定请求的数据类型和数据源，category指定响应请求动作的组件的类别信息，<key,value>指定请求时携带的附加信息；

前述动作序列具有形如＜X,Y,Z,...＞的顺序序列，其中X，Y，Z为一个动作或多个动作的逻辑并；

前述移动应用具有形如<A,<package,class>>的数据结构，其中A为一个动作，<package,class>为能响应A的具体移动应用的组件信息，package对应于移动应用的包名，class对应于组件的类名；

移动应用的序列是形如<a,b,c,...>的由移动应用构成的顺序序列；

步骤1)中描述动作序列时，开发者使用意图过程执行语言IPEL，IPEL基于可扩展标记语言XML，语法结构由XSD约束，其中：

IPEL流程从<process>元素开始，该<process>元素用于唯一的标识流程，<request>元素表示一次功能请求，其describe属性用于对该功能请求进行描述，skip属性用于标识该步是否可以跳过，reselect属性用于标识该步是否可以重新选择；

每次功能请求通过<pick>或<invoke>元素描述，其中：

<invoke>元素包含一个<intent>子元素，表示该功能只由一个固定的动作完成；

<pick>元素拥有多个<intent>子元素，每个复合元素代表了一个请求动作，其中：

复合元素<intent>定义了<action>、<category>、<data>、<extra>四个子元素，<action>元素指定请求的动作名称，<category>包含响应请求动作的组件的类别信息，<data>元素包含需要传递的数据信息，其中type属性标记数据的MIME类型，uri属性标记数据源地址，<extra>元素包含动作携带的附加信息。

2.根据权利要求1所述的方法，其特征在于，在前述步骤3)进行应用执行序列推荐时，对于动作序列中的每一步，用户u都有一个候选移动应用集合，从每步的候选移动应用集合中选取一个应用，即构成了一个候选应用执行序列α；通过计算用户兴趣相似度得到用户相似度矩阵后，取出和用户u最相似的K个用户在完成该动作时采用的应用执行序列，构成集合S；再利用应用执行序列偏好度预测算法，以α和S作为算法的输入，输出是预测的用户u对候选应用执行序列α的偏好度；得到每个候选应用执行序列的偏好度之后，选取偏好度最大的候选应用执行序列，即是推荐给用户的最优应用执行序列。

3.根据权利要求2所述的方法，其特征在于，在前述应用执行序列推荐过程中，采用如下公式计算用户兴趣相似度：

$w_{uv}=\frac{{\mathrm{\&Sigma;}}_{i\&Element;N\left(u\right)\&cap;N\left(v\right)}\frac{1}{\log (1+|N\left(i\right)\left|\right)}}{\sqrt{\left|N\left(u\right)\right|\left|N\left(v\right)\right|}}$

其中，N(u)、N(v)分别表示用户u和v安装的应用集合，N(i)表示安装了应用i的用户集合，该算法惩罚了用户u和v的共有应用集合中热门应用对兴趣相似度的影响。