本申请涉及数据处理技术领域，具体而言，涉及一种应用数据处理方法及装置。
背景技术
大公司通常开发了多个不同的功能的app，用户手机上也一般会安装数个同一公司的app。对于同一个公司开发的数个app来说，app之间在用户设备上进行数据共享与通信，本质上是app两两之间需要通过进程通信的方法进行交互。现阶段存在的困难有：
a.实现上的困难：ios和android平台的app之间通信的编程接口不统一，并且应用之间的通信接口的调用，需要知道别的应用的包名和接口的具体定义。而每个app的通信接口的定义往往是不同的，就算是同一个厂商的app也很难统一接口。因此很难直接利用ios或者android设备的原生通信接口进行app的通信。
b.缺少中心入口：用户设备上不一定如开发者所愿安装了某些必须的app。并且多个app缺少统一的账号系统，其直接后果是，厂商并没有意识到用户是在同一个手机上使用多个他们发布的app，例如：目前某公司的多个游戏之间的数据是没有整合的，游戏之间进行联动很困难。实际上在手机设备上可以获取更多用户设备相关信息，足够区分不同的设备，可以认为使用这个设备的通常是同一个用户。
c.安全风险较大：如果实现有漏洞，极其容易造成用户隐私泄露，损害厂商形象的同时又可能被下架。
相关技术中的方案，主要分为两类，一类是有超高用户覆盖率的高安装量的app作为超级入口(例如：微信、支付宝)，构建账号体系，提供使用微信登录这样的功能。而很多公司都没有这样的高安装量的app，因此这种方式只适合少数公司。因此只能采用另一种实现方式：每个app在后台开一个httpwebserver，其他的app通过访问用户手机本地的固定端口，来进行交互。这种实现方式由于app的后台保活存在问题，已经不能保证app本地开启的web服务器能一直保持开启并接受消息。并且http服务容易被app恶意利用，存在很高的安全风险。
针对相关技术中上述的问题，目前尚未提出有效的解决方案。
技术实现要素：
本申请的主要目的在于提供一种应用数据处理方法及装置，以解决相关技术中应用之间数据交互安全性较低，容易被劫持的问题。
为了实现上述目的，根据本申请的一个方面，提供了一种应用数据处理方法。该方法包括：第一应用根据设备标识码确定待通信的第二应用，其中，所述第二应用内嵌有共享软件开发工具包，用于共享应用数据；所述第一应用从服务器获取会话标识和所述第二应用的网页地址协议；所述第一应用采用所述会话标识和所述网页地址协议与所述第二应用进行应用数据交互。
进一步地，所述第一应用根据所述设备标识码确定所述第二应用包括：所述第一应用向所述服务器发送所述设备标识码，以使所述服务器根据所述设备标识码确定所述第一应用所在的用户设备上内嵌有共享软件开发工具包上的多个应用；所述第一应用从所述多个应用中选取所述第二应用。
进一步地，在所述第一应用采用所述会话标识和所述网页地址协议与所述第二应用进行应用数据交互之前，还包括：所述第一应用通过调用第二应用的网页地址协议来唤醒所述第二应用。
进一步地，所述第一应用采用所述会话标识和所述网页地址协议与所述第二应用进行应用数据交互包括：所述第一应用通过与所述第二应用对应的应用程序编程接口向所述第二应用发送通信请求消息，以使所述第二应用根据所述通信请求消息确定待交互的应用数据，其中，所述应用程序编程接口包含的参数信息至少包括：所述会话标识、所述网页地址协议、通信命令。
进一步地，所述第一应用通过与所述第二应用对应的应用程序编程接口向所述第二应用发送通信请求消息包括：所述第一应用通过所述应用程序编程接口向所述第二应用发送通信请求消息，其中，所述通信请求消息携带的信息至少包括：所述会话标识、所述通信命令，所述通信请求消息用于从所述第二应用获取第一应用数据；所述第一应用接收所述服务器下发的所述第一应用数据，其中，所述第一应用数据由所述服务器根据所述第二应用发送的所述会话标识和所述通信命令来确定。
进一步地，在所述第一应用接收所述服务器下发的所述第一应用数据之前，还包括：所述第二应用接受服务端的安全性校验，其中，所述安全性校验采用所述服务端为所述第二应用分配的公钥、所述服务端本地存储的与所述公钥配对的私钥以及所述第一应用在所述服务端预存的安全密钥来完成。
进一步地，所述第一应用通过与所述第二应用对应的应用程序编程接口向所述第二应用发送通信请求消息包括：所述第一应用通过所述应用程序编程接口向所述第二应用发送通信请求消息，以使所述第二应用采用所述会话标识和所述通信命令从所述服务器拉取所述第二应用数据，其中，所述通信请求消息携带的信息至少包括：所述会话标识、所述通信命令，所述通信请求消息用于向所述第二应用发送第二应用数据。
为了实现上述目的，根据本申请的另一方面，提供了一种应用数据处理装置。该装置包括：确定单元，用于第一应用根据设备标识码确定待通信的第二应用，其中，所述第二应用内嵌有共享软件开发工具包，用于共享应用数据；获取单元，用于所述第一应用从服务器获取会话标识和所述第二应用的网页地址协议；数据交互单元，用于所述第一应用采用所述会话标识和所述网页地址协议与所述第二应用进行应用数据交互。
进一步地，所述确定单元还包括：第一发送模块，用于所述第一应用向所述服务器发送所述设备标识码，以使所述服务器根据所述设备标识码确定所述第一应用所在的用户设备上内嵌有共享软件开发工具包上的多个应用；选取模块，用于所述第一应用从所述多个应用中选取所述第二应用。
进一步地，还包括：唤醒单元，用于在所述第一应用采用所述会话标识和所述网页地址协议与所述第二应用进行应用数据交互之前，所述第一应用通过调用第二应用的网页地址协议来唤醒所述第二应用。
进一步地，所述数据交互单元包括：第二发送模块，用于所述第一应用通过与所述第二应用对应的应用程序编程接口向所述第二应用发送通信请求消息，以使所述第二应用根据所述通信请求消息确定待交互的应用数据，其中，所述应用程序编程接口包含的参数信息至少包括：所述会话标识、所述网页地址协议、通信命令。
进一步地，所述第二发送模块包括：第一发送子模块，用于所述第一应用通过所述应用程序编程接口向所述第二应用发送通信请求消息，其中，所述通信请求消息携带的信息至少包括：所述会话标识、所述通信命令，所述通信请求消息用于从所述第二应用获取第一应用数据；第一接收子模块，用于所述第一应用接收所述服务器下发的所述第一应用数据，其中，所述第一应用数据由所述服务器根据所述第二应用发送的所述会话标识和所述通信命令来确定。
进一步地，还包括：安全性校验单元，用于在所述第一应用接收所述服务器下发的所述第一应用数据之前，所述第二应用接受服务端的安全性校验，其中，所述安全性校验采用所述服务端为所述第二应用分配的公钥、所述服务端本地存储的与所述公钥配对的私钥以及所述第一应用在所述服务端预存的安全密钥来完成。
进一步地，所述第二发送模块包括：第二发送子模块，用于所述第一应用通过所述应用程序编程接口向所述第二应用发送通信请求消息，以使所述第二应用采用所述会话标识和所述通信命令从所述服务器拉取所述第二应用数据，其中，所述通信请求消息携带的信息至少包括：所述会话标识、所述通信命令，所述通信请求消息用于向所述第二应用发送第二应用数据。
为了实现上述目的，根据本申请的另一方面，提供了一种处理器，其特征在于，所述处理器用于运行程序，其中，所述程序运行时执行上述任意一项所述的应用数据处理方法。
为了实现上述目的，根据本申请的另一方面，提供了一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序执行上述任意一项所述的应用数据处理方法。
为了实现上述目的，根据本申请的另一方面，提供了一种电子设备，其特征在于，包括：一个或多个处理器，存储器，显示装置以及一个或多个程序，其中，所述一个或多个程序被存储在所述存储器中，并且被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行上述任意一项所述的应用数据处理方法。
通过本申请，采用以下步骤：第一应用根据设备标识码确定待通信的第二应用，其中，所述第二应用内嵌有共享软件开发工具包，用于共享应用数据；所述第一应用从服务器获取会话标识和所述第二应用的网页地址协议；所述第一应用采用所述会话标识和所述网页地址协议与所述第二应用进行应用数据交互，解决了相关技术中应用之间数据交互安全性较低，容易被劫持的问题，进而达到了提升应用之间数据交互安全性的效果。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是根据本申请实施例提供的应用数据处理方法的流程图；
图2是根据本申请实施例提供的应用数据处理方法中服务器的推送消息的示意图；
图3是根据本申请实施例提供的应用数据处理方法中应用之间发送消息的示意图；以及
图4是根据本申请实施例提供的应用数据处理装置的示意图。
具体实施方式
需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
为了便于描述，以下对本申请实施例涉及的部分名词或术语进行说明：
sharesdk：多个app中嵌入的用于互相之间消息分发的sdk。
shareservice：嵌入sharesdk的app中运行的用于交换消息的后台服务。
sharesdkserver：sharesdk所连接的服务器。
shareapi：多app用于交换信息的关键api，例如下面的sendcommandtoshareapp。
udid：userdeviceidentifier，这里不同于apple的udid(uniquedeviceidentifier)，指通过一定算法获取的用户的设备特征，能用来区分不同的用户设备。
urlscheme，android和ios平台的一种app自定义协议，例如，定一个share-app://xxx，类似于url的链接，只要以share-app://开头的链接的事件都会被分配给这个app处理。
根据本申请的实施例，提供了一种应用数据处理方法。
图1是根据本申请实施例的应用数据处理方法的流程图。如图1所示，该方法包括以下步骤：
步骤s101，第一应用根据设备标识码确定待通信的第二应用，其中，第二应用内嵌有共享软件开发工具包，用于共享应用数据。
上述的共享软件开发工具包可以为sharesdk，用于第二应用与其它应用之间消息分发。
步骤s102，第一应用从服务器获取会话标识和第二应用的网页地址协议。
上述的会话标识可以为sessionid，上述的网页地址协议可以为urlscheme。
第一应用向服务器发送请求表示想要与第二应用进行通信，服务器返回至第一应用中的sessionid和第二应用的urlscheme。
需要说明的是，在本申请实施例中提及的sessionid可以为包含，通信业务编号，通信安全码等一序列用于简单的防止伪造以及区分不同请求的hash字符串。
步骤s103，第一应用采用会话标识和网页地址协议与第二应用进行应用数据交互。
由于是采用第一应用从服务器获取到的会话标识和第二应用的网页地址协议与第二应用进行应用数据交互。避免了第一应用与第二应用直接进行数据交互，提升了第一应用与第二应用之间数据交互的安全性。
本申请实施例提供的应用数据处理方法，通过第一应用根据设备标识码确定待通信的第二应用，其中，所述第二应用内嵌有共享软件开发工具包，用于共享应用数据；所述第一应用从服务器获取会话标识和所述第二应用的网页地址协议；所述第一应用采用所述会话标识和所述网页地址协议与所述第二应用进行应用数据交互，解决了相关技术中应用之间数据交互安全性较低，容易被劫持的问题，进而达到了提升应用之间数据交互安全性的效果。
可选地，在本申请实施例提供的应用数据处理方法中，第一应用根据设备标识码确定第二应用包括：第一应用向服务器发送设备标识码，以使服务器根据设备标识码确定第一应用所在的用户设备上内嵌有共享软件开发工具包上的多个应用；第一应用从多个应用中选取第二应用。
在本申请实施例中涉及的应用可以装载在手机和平板等移动终端上，由于移动终端等均为私人的物品，通常认为大部的手机和平板都对应唯一的用户，针对这类设备，可以基于硬件特征码生成一个唯一的设备标识码(udid)，也可以理解为唯一的用户标识。
需要说明的是，生成udid的算法有很多，ios可考虑用uinquedeviceindentifier和机型等硬件特征一起来生成这个udid，android可以考虑利用imei码以及一些硬件特征来生成这个udid，每个不同的udid可以认为对应一个不同的设备。在用户登录应用之后一般都有手机号或者邮箱及实名认证(例如，游戏都要求实名认证，每个账号不管是手机号注册的还是邮箱注册的，最终可通过手机号或者邮箱来获取唯一的实名用户)。让用户通过sharesdk来获取udid，通过udid来绑定设备，为了避免串号，一台设备只绑定一个用户，是否是一个用户可以通过手机号或者实名认证进行判定(一个用户可以有多个游戏账号)，同一设备最新绑定的用户替代之前绑定的用户，通过这样的方法可以保证用户和设备严格的一对多的关系。
因此，在上述方案中，第一应用向服务器发送udid，以使服务器根据udid确定第一应用所在的用户设备上内嵌有共享软件开发工具包上的多个应用，从多个应用中选取待与第一应用通信的第二应用。
可选地，在本申请实施例提供的应用数据处理方法中，在第一应用采用会话标识和网页地址协议与第二应用进行应用数据交互之前，还包括：第一应用通过调用第二应用的网页地址协议来唤醒第二应用。
例如，第一应用通过调用第二应用的urlscheme，来唤醒第二应用的sharesdk的后台服务进程。
可选地，在本申请实施例提供的应用数据处理方法中，第一应用采用会话标识和网页地址协议与第二应用进行应用数据交互包括：第一应用通过与第二应用对应的应用程序编程接口向第二应用发送通信请求消息，以使第二应用根据通信请求消息确定待交互的应用数据，其中，应用程序编程接口包含的参数信息至少包括：会话标识、网页地址协议、通信命令。
在上述方案中，通过调用第二应用的sendcommandtoshareapp(对应上述的发送通信请求消息)，这样的应用程序编程接口来向第二应用表示，希望获取第二应用的某一个数据(对应上述的待交互的应用数据)，这个数据类型可通过通信命令来设定。其中，应用程序编程接口包含的参数信息至少包括：sessionid，urlscheme，command。
可选地，在本申请实施例提供的应用数据处理方法中，第一应用通过与第二应用对应的应用程序编程接口向第二应用发送通信请求消息包括：第一应用通过应用程序编程接口向第二应用发送通信请求消息，其中，通信请求消息携带的信息至少包括：会话标识、通信命令，通信请求消息用于从第二应用获取第一应用数据；第一应用接收服务器下发的第一应用数据，其中，第一应用数据由服务器根据第二应用发送的会话标识和通信命令来确定。
在上述方案中，通信请求消息携带的信息至少包括：sessionid和通信命令，也即，第二应用将sessionid和通信命令发送到服务器，最后由服务器下发第一应用数据至第一应用。
可选地，在本申请实施例提供的应用数据处理方法中，在第一应用接收服务器下发的第一应用数据之前，还包括：第二应用接受服务端的安全性校验，其中，安全性校验采用服务端为第二应用分配的公钥、服务端本地存储的与公钥配对的私钥以及第二应用在服务端预存的安全密钥来完成。
在上述方案中，如果有“恶意应用二”应用冒充第二应用，向服务器拉取消息，这时候服务器需要验证第二应用究竟是“恶意应用二”还是真正的第二应用。对于服务器与第二应用之间的通信，服务器可以通过给每个app都打包一个rsa公钥，服务器存放私钥，以及这个app预存在服务器端的一个安全密钥，就能校验客户端的app是否为真正的第二应用。由于第一应用的数据是由服务器根据第二应用发送的会话标识和通信命令来确定，在确定第二应用为真正的第一应用的情况下，从而才能保证第一应用获取到的数据是准确性，也保证了数据交互的安全性。
可选地，在本申请实施例提供的应用数据处理方法中，第一应用通过与第二应用对应的应用程序编程接口向第二应用发送通信请求消息包括：第一应用通过应用程序编程接口向第二应用发送通信请求消息，以使第二应用采用会话标识和通信命令从服务器拉取第二应用数据，其中，通信请求消息携带的信息至少包括：会话标识、通信命令，通信请求消息用于向第二应用发送第二应用数据。
在上述方案中，通信请求消息携带的信息至少包括：sessionid和通信命令，也即，第一应用将携带sessionid和通信命令的通信请求消息发送第二应用，第二应用将采用会话标识和通信命令从服务器中拉取第二应用数据，最后由服务器下发第二应用数据至第二应用。
在上述的实施例中，方案实现的思路是，如果app1想给app2发消息(也即进行数据交互)，首先在服务器上查询app2的urlscheme，这时可用设备标识码udid来确认玩家当前登录的是哪一个设备，这个设备上有哪些接入了sharesdk的app。然后app1调用对应的api，将通信session和command发给app2，app2再拿这些参数去服务器拉取数据，完成整个通信。由于信息是由app2向服务器拉取的，不是在用户设备上直接由app1传给app2，因此，比现有的app1与app2直接传输信息的机制更安全。
为了加大app及时收到服务器的推送消息的概率，因此让出于运行状态的app来分发消息。通过互相之间的消息分发，能够做到只要这些app中有一个在后台存活，就能响应服务器的消息推送，并将消息分发给目标应用，如下图2所示。
app之间发消息，可以分成两个步骤，如图3所示，首先后台唤醒另外一个app。然后另外一个app的后台服务中接收并处理消息，其过程如下：步骤1:app1通过sharesdk中消息发送部分发给app2开启shareservice。步骤2:shareservice通知服务器app1在请求数据data1。步骤3:服务器就把数据下发给app1，由app1中的sharesdk中代码来接收并处理数据。
其通信过程解释如下：app1首先向服务器发送请求表示想要与app2进行通信，服务器返回一个sessionid，以及app2的urlscheme，app1唤醒通过调用app2的urlscheme，来唤醒app2的sharesdk后台服务进程。然后通过调用app2的sendcommandtoshareapp(sessionid，urlscheme，command，userdata)这样的api来向app2表示，希望获取app2的某一个数据，这个数据类型可通过command来设定。app2再将sessionid和command发送到sharesdkserver，最后由sharesdkserver下发数据给app1。
需要说明的是，这里的sendcommandtoshareapp(shareapi)只是举例说明通信api的用法，这类api用3个关键信息：sessionid和urlscheme和command，来描述通信对象以及行为，具体的api实现方式很灵活，在本申请中不作限定。
综上所述，本申请实施例的应用数据处理方法，在不依赖于app证书检查，不假设设备信道安全，而是采用一种带认证的消息系统pull模型来保证应用间安全的通信。
例如，用户的网络传输由https保证安全，然后用户设备上的app无法被破解改写，用户的账号密码没有被泄露，用户设备没越狱第三方app不能随意读取其他的app的数据。下面分析app1与app2通信过程中存在的三种攻击模型(threatmodel):
1、用户设备上通信信道被劫持：app1直接发给app2的信息只有sessionid和command，在设备手机上监听信道也窃取不了什么有效信息。
2、app1被恶意app冒充：就算有“恶意应用一”冒充app1给app2发session和command，由于信息需要app2向服务器去拉取，“恶意应用一”是无法获取信息。
3、app2被恶意app冒充：如果有“恶意应用二”冒充app2，向服务器拉取消息，这时候服务器需要验证app2究竟是“恶意应用二”还是真正的app2。对于sharesdkserver与app2之间的通信，sharesdkserver可以通过给每个app都打包一个rsa公钥，服务器存放私钥，以及这个app预存在服务器端的一个securekey，就能校验客户端的app是否为真正的app2。
这三种情形包括了正常设备上几乎所有的恶意app的可能的攻击方式，本申请实施例的应用数据处理方法，能防御这三种攻击，基本能保证app之间的数据信息的安全交换。
需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例还提供了一种应用数据处理装置，需要说明的是，本申请实施例的应用数据处理装置可以用于执行本申请实施例所提供的用于应用数据处理方法。以下对本申请实施例提供的应用数据处理装置进行介绍。
图4是根据本申请实施例的应用数据处理装置的示意图。如图4所示，该装置包括：确定单元10、获取单元20和数据交互单元30。
具体地，确定单元10，用于第一应用根据设备标识码确定待通信的第二应用，其中，第二应用内嵌有共享软件开发工具包，用于共享应用数据；
获取单元20，用于第一应用从服务器获取会话标识和第二应用的网页地址协议；
数据交互单元30，用于第一应用采用会话标识和网页地址协议与第二应用进行应用数据交互。
本申请实施例提供的应用数据处理装置，通过确定单元10第一应用根据设备标识码确定待通信的第二应用，其中，第二应用内嵌有共享软件开发工具包，用于共享应用数据；获取单元20第一应用从服务器获取会话标识和第二应用的网页地址协议；数据交互单元30第一应用采用会话标识和网页地址协议与第二应用进行应用数据交互，解决了相关技术中应用之间数据交互安全性较低，容易被劫持的问题，进而达到了提升应用之间数据交互安全性的效果。
可选地，在本申请实施例提供的应用数据处理装置中，确定单元10还包括：第一发送模块，用于第一应用向服务器发送设备标识码，以使服务器根据设备标识码确定第一应用所在的用户设备上内嵌有共享软件开发工具包上的多个应用；选取模块，用于第一应用从多个应用中选取第二应用。
可选地，在本申请实施例提供的应用数据处理装置中，还包括：唤醒单元，用于在第一应用采用会话标识和网页地址协议与第二应用进行应用数据交互之前，第一应用通过调用第二应用的网页地址协议来唤醒第二应用。
可选地，在本申请实施例提供的应用数据处理装置中，数据交互单元30包括：第二发送模块，用于第一应用通过与第二应用对应的应用程序编程接口向第二应用发送通信请求消息，以使第二应用根据通信请求消息确定待交互的应用数据，其中，应用程序编程接口包含的参数信息至少包括：会话标识、网页地址协议、通信命令。
可选地，在本申请实施例提供的应用数据处理装置中，第二发送模块包括：第一发送子模块，用于第一应用通过应用程序编程接口向第二应用发送通信请求消息，其中，通信请求消息携带的信息至少包括：会话标识、通信命令，通信请求消息用于从第二应用获取第一应用数据；第一接收子模块，用于第一应用接收服务器下发的第一应用数据，其中，第一应用数据由服务器根据第二应用发送的会话标识和通信命令来确定。
可选地，在本申请实施例提供的应用数据处理装置中，还包括：安全性校验单元，用于在第一应用接收服务器下发的第一应用数据之前，第二应用接受服务端的安全性校验，其中，安全性校验采用服务端为第二应用分配的公钥、服务端本地存储的与公钥配对的私钥以及第二应用在服务端预存的安全密钥来完成。
可选地，在本申请实施例提供的应用数据处理装置中，第二发送模块包括：第二发送子模块，用于第一应用通过应用程序编程接口向第二应用发送通信请求消息，以使第二应用采用会话标识和通信命令从服务器拉取第二应用数据，其中，通信请求消息携带的信息至少包括：会话标识、通信命令，通信请求消息用于向第二应用发送第二应用数据。
所述应用数据处理装置包括处理器和存储器，上述确定单元10、获取单元20和数据交互单元30等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。
处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来提升应用之间数据交互安全性。
存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)，存储器包括至少一个存储芯片。
本发明实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现所述应用数据处理方法。
本发明实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行所述应用数据处理方法。
本发明实施例提供了一种电子设备，包括：一个或多个处理器，存储器，显示装置以及一个或多个程序，其中，所述一个或多个程序被存储在所述存储器中，并且被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行上述任意一项所述的应用数据处理方法。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。存储器是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。