CN106067894A - 一种信息获取方法及电子设备 - Google Patents

Abstract

本发明公开了一种信息获取方法及电子设备，所述方法包括：向目标应用的服务器侧发送账户获取请求，接收到所述服务器侧反馈的至少两个账户信息，并基于所述至少两个账户信息中的第一账户信息登录所述目标应用；其中，所述目标应用为能够提供至少一个可下载应用程序的下载服务的应用；从所述目标应用的服务器侧获取到应用分类信息；其中，所述应用分类信息用于表示所述目标应用能够提供的至少一种应用类别；基于所述应用分类信息，获取并保存每一种应用类别中包含的至少一个可下载应用程序的应用信息。

Description

一种信息获取方法及电子设备

技术领域

本发明涉及领域通信领域的信息获取技术，尤其涉及一种信息获取方法及电子设备。

背景技术

目前，智能手机已成为人们生活中必不可少的一部分。为智能手机，尤其是安卓手机提供应用程序也成为一种必要的技术。由GooglePlay提供的各类丰富应用，极大方便了众多使用者。但对于第三方数据统计服务或应用市场而言，需要大量的应用数据(评价、图片、下载量等)，手动获取应用的相关信息显然是不可行的。

发明内容

本发明的主要目的在于提出一种信息获取方法及电子设备，旨在解决现有技术中存在的上述问题。

为实现上述目的，本发明提供的一种信息获取方法，所述方法包括：

向目标应用的服务器侧发送账户获取请求，接收到所述服务器侧反馈的至少两个账户信息，并基于所述至少两个账户信息中的第一账户信息登录所述目标应用；其中，所述目标应用为能够提供至少一个可下载应用程序的下载服务的应用；

从所述目标应用的服务器侧获取到应用分类信息；其中，所述应用分类信息用于表示所述目标应用能够提供的至少一种应用类别；

基于所述应用分类信息，获取并保存每一种应用类别中包含的至少一个可下载应用程序的应用信息。

本发明实施例还提供了一种电子设备，所述电子设备包括：

账户管理单元，用于向目标应用的服务器侧发送账户获取请求，接收到所述服务器侧反馈的至少两个账户信息，并基于所述至少两个账户信息中的第一账户信息登录所述目标应用；其中，所述目标应用为能够提供至少一个可下载应用程序的下载服务的应用；

第一信息获取单元，用于从所述目标应用的服务器侧获取到应用分类信息；其中，所述应用分类信息用于表示所述目标应用能够提供的至少一种应用类别；

第二信息获取单元，用于基于所述应用分类信息，获取并保存每一种应用类别中包含的至少一个可下载应用程序的应用信息。

本发明提出的信息获取方法及电子设备，能够获取到目标应用的至少两个账户信息，并且从中选取一个账户信息登录目标应用，进而获取到目标应用能够提供的至少一个可下载应用程序的应用信息。如此，就避免了手动的获取到目标应用中的多个应用程序的应用信息，从而保证了从目标应用中获取到多个可下载应用程序的应用信息的处理效率，还减少了错误率。

附图说明

图1为实现本发明各个实施例的电子设备一个可选的硬件结构示意图；

图2为如图1所示的电子设备的无线通信系统示意图；

图3为本发明实施例信息获取方法流程示意图；

图4为本发明实施例信息获取处理界面；

图5a为本发明实施例应用类别信息示意界面一；

图5b为本发明实施例应用类别信息示意界面二；

图6为本发明实施例获取应用详情的处理流程示意图；

图7为本发明实施例电子设备组成结构示意图一；

图8为本发明实施例电子设备组成结构示意图二；

图9为本发明实施例进行文件下载的逻辑结构示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的电子设备。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

电子设备可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的电子设备以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是电子设备。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例的电子设备一个可选的硬件结构示意图。

电子设备100可以包括通信单元110、用户输入单元130、输出单元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件的电子设备，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。将在下面详细描述电子设备的元件。

用户输入单元130可以根据用户输入的命令生成键输入数据以控制电子设备的各种操作。

接口单元170用作至少一个外部装置与电子设备100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。另外，当电子设备100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到电子设备100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到电子设备的路径。

输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。输出单元150可以包括显示单元151、音频输出模块152等等。

显示单元151可以显示在电子设备100中处理的信息。例如，当电子设备100处于电话通话模式时，显示单元151可以显示与通话或其它通信(例如，文本消息收发、多媒体文件下载等等)相关的用户界面(UI)或图形用户界面(GUI)。当电子设备100处于视频通话模式或者图像捕获模式时，显示单元151可以显示捕获的图像和/或接收的图像、示出视频或图像以及相关功能的UI或GUI等等。

同时，当显示单元151和触摸板以层的形式彼此叠加以形成触摸屏时，显示单元151可以用作输入装置和输出装置。显示单元151可以包括液晶显示器(LCD)、薄膜晶体管LCD(TFT-LCD)、有机发光二极管(OLED)显示器、柔性显示器、三维(3D)显示器等等中的至少一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明显示器，典型的透明显示器可以例如为TOLED(透明有机发光二极管)显示器等等。根据特定想要的实施方式，电子设备100可以包括两个或更多显示单元(或其它显示装置)，例如，电子设备可以包括外部显示单元(未示出)和内部显示单元(未示出)。触摸屏可用于检测触摸输入压力以及触摸输入位置和触摸输入面积。

存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，电子设备100可以与通过网络连接执行存储器160的存储功能的网络存储装置协作。

控制器180通常控制电子设备的总体操作。例如，控制器180执行与语音通话、数据通信、视频通话等等相关的控制和处理。电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器160中并且由控制器180执行。

至此，己经按照其功能描述了电子设备。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型电子设备等等的各种类型的电子设备中的滑动型电子设备作为示例。因此，本发明能够应用于任何类型的电子设备，并且不限于滑动型电子设备。

如图1中所示的电子设备100可以被构造为利用经由帧或分组发送数据的诸如有线和无线通信系统以及基于卫星的通信系统来操作。

现在将参考图2描述其中根据本发明的电子设备能够操作的通信系统。

这样的通信系统可以使用不同的空中接口和/或物理层。例如，由通信系统使用的空中接口包括例如频分多址(FDMA)、时分多址(TDMA)、码分多址(CDMA)和通用移动通信系统(UMTS)(特别地，长期演进(LTE))、全球移动通信系统(GSM)等等。作为非限制性示例，下面的描述涉及CDMA通信系统，但是这样的教导同样适用于其它类型的系统。

参考图2，CDMA无线通信系统可以包括多个电子设备100、多个基站(BS)270、基站控制器(BSC)275和移动交换中心(MSC)280。MSC280被构造为与公共电话交换网络(PSTN)290形成接口。MSC280还被构造为与可以经由回程线路耦接到基站270的BSC275形成接口。回程线路可以根据若干己知的接口中的任一种来构造，所述接口包括例如E1/T1、ATM，IP、PPP、帧中继、HDSL、ADSL或xDSL。将理解的是，如图2中所示的系统可以包括多个BSC2750。在图2中，描绘了多个卫星300，但是理解的是，可以利用任何数目的卫星获得有用的定位信息。

基于上述电子设备硬件结构以及通信系统，提出本发明方法各个实施例。

实施例一、

本发明实施例提供了一种信息获取方法，如图3所示，所述方法包括：

步骤301：向目标应用的服务器侧发送账户获取请求，接收到所述服务器侧反馈的至少两个账户信息，并基于所述至少两个账户信息中的第一账户信息登录所述目标应用；其中，所述目标应用为能够提供至少一个可下载应用程序的下载服务的应用；

步骤302：从所述目标应用的服务器侧获取到应用分类信息；其中，所述应用分类信息用于表示所述目标应用能够提供的至少一种应用类别；

步骤303：基于所述应用分类信息，获取并保存每一种应用类别中包含的至少一个可下载应用程序的应用信息。

本发明实施例可以应用于任意一种电子设备，比如，可以应用于电脑、智能手机、平板电脑、笔记本等个人终端设备，还可以应用于服务器等设备。

本实施例中所述目标应用，即为能够为用户提供至少一种可下载应用程序的下载处理的应用，可以参见图4，在目标应用里提供了应用A、应用B和应用C三种可下载应用，具体来说，所述目标应用可以为google play，或者是某些应用商店类的应用。

具体地，假设我们要向google play进行信息获取的场景下，需要至少两个谷歌账号来申请授权。然后需要使用谷歌的protobuf SDK将请求参数进行编码，得到编码后的账户获取请求；

然后向目标应用的服务器发送账户获取请求，也就是进行checkin请求，请求之后可获得至少一个安卓标识(Android ID)和令牌(Token)；

根据获得的AndroidID和Token重新编码，得到至少一个账户信息；

然后基于至少一个账户信息再次向服务器进行checkin动作；Checkin动作完成以后，根据获得的AndroidID和Token，随机选取一个谷歌账户及第一账户信息，完成账户登录目标应用的操作。

上述应用分类信息可以为所述服务器侧能够提供的多个应用的多种类别，需要说明的是，获取到的应用分类信息可以只包括有应用类别信息，比如参见图5a和图5b，图5a表示应用分类信息可以仅为目标应用中的几种类别，图5b可以为一个实际用例，比如，目标应用中可以包括有游戏类应用、教育类应用、生活类应用、购物类应用、即时通信类应用等等。

进一步地，每一种应用类别中包括有至少一个可下载应用程序，比如，即时通信类中可以包括有微信、电话、通讯录管理等等应用；游戏类中可以包括有多种游戏，这里不进行穷举。

进一步需要理解的是，本实施例中最终获取到的为每一种可下载应用的应用详情，比如，可以包括有应用名称、安装包下载地址、图标和截图下载地址、安装包大小、签名信息、版本号等。比如，应用名称为微信、安装包的下载地址为微信的服务器侧，微信的图标及其下载地址可以均在微信的服务器侧，另外，安装包的大小可以为30M，版本号可以用于表征当前提供的应用对应的版本，比如，可以为3.0版本。

可见，通过采用上述方案，就能够获取到目标应用的至少两个账户信息，并且从中选取一个账户信息登录目标应用，进而获取到目标应用能够提供的至少一个可下载应用程序的应用信息。如此，就避免了手动的获取到目标应用中的多个应用程序的应用信息，从而保证了从目标应用中获取到多个可下载应用程序的应用信息的处理效率，还减少了错误率。

实施例二、

本发明实施例提供了一种信息获取方法，如图3所示，所述方法包括：

步骤301：向目标应用的服务器侧发送账户获取请求，接收到所述服务器侧反馈的至少两个账户信息，并基于所述至少两个账户信息中的第一账户信息登录所述目标应用；其中，所述目标应用为能够提供至少一个可下载应用程序的下载服务的应用；

步骤302：从所述目标应用的服务器侧获取到应用分类信息；其中，所述应用分类信息用于表示所述目标应用能够提供的至少一种应用类别；

步骤303：基于所述应用分类信息，获取并保存每一种应用类别中包含的至少一个可下载应用程序的应用信息。

本发明实施例可以应用于任意一种电子设备，比如，可以应用于电脑、智能手机、平板电脑、笔记本等个人终端设备，还可以应用于服务器等设备。

本实施例中所述目标应用，即为能够为用户提供至少一种可下载应用程序的下载处理的应用，可以参见图4，在目标应用里提供了应用A、应用B和应用C三种可下载应用，具体来说，所述目标应用可以为google play，或者是某些应用商店类的应用。

具体地，假设我们要向google play进行信息获取的场景下，需要至少两个谷歌账号来申请授权。然后需要使用谷歌的protobuf SDK将请求参数进行编码，得到编码后的账户获取请求；

然后向目标应用的服务器发送账户获取请求，也就是进行checkin请求，请求之后可获得至少一个安卓标识(Android ID)和令牌(Token)；

根据获得的AndroidID和Token重新编码，得到至少一个账户信息；

然后基于至少一个账户信息再次向服务器进行checkin动作；Checkin动作完成以后，根据获得的AndroidID和Token，随机选取一个谷歌账户及第一账户信息，完成账户登录目标应用的操作。

本实施例详细介绍如何获取到应用分类信息以及如何获取到应用信息，具体如下：

所述从所述目标应用的服务器侧获取到应用分类信息，包括：向所述目标应用的服务器侧发送第一访问请求，接收到服务器侧反馈的针对所述第一访问请求的第一页面内容信息；解析所述第一页面内容信息，获取到至少一种应用类别；将所述至少一种应用类别作为所述应用分类信息。

具体地，应用的类别信息，是通过对GooglePlay应用URL进行HTTP访问，然后对返回的第一页面内容进行格式解析，从第一页面内容中获取类别名。

上述应用分类信息可以为所述服务器侧能够提供的多个应用的多种类别，需要说明的是，获取到的应用分类信息可以只包括有应用类别信息，比如参见图5a和图5b，图5a表示应用分类信息可以仅为目标应用中的几种类别，图5b可以为一个实际用例，比如，目标应用中可以包括有游戏类应用、教育类应用、生活类应用、购物类应用、即时通信类应用等等。

进一步地，每一种应用类别中包括有至少一个可下载应用程序，比如，即时通信类中可以包括有微信、电话、通讯录管理等等应用；游戏类中可以包括有多种游戏，这里不进行穷举。

所述获取到每一种应用类别中包含的至少一个可下载应用程序的应用信息，包括：

基于应用类别组成针对所述应用类别的第二访问请求，发送所述第二访问请求至服务器侧；接收到所述服务器侧反馈的针对所述第二访问请求的第二页面内容信息；解析所述第二页面内容信息，获取到所述应用类别包含的至少一个可下载应用程序的应用信息，其中，所述应用信息中至少包括有以下至少之一：可下载应用程序名称、可下载应用程序的安装包下载地址、可下载应用程序的图标及其下载地址、可下载应用程序的截图及其下载地址。

具体地，参见图6：

步骤601：获取遍历的类名下应用包名。

遍历category表中类名，组成一个URL，作为获取应用包名的入口，比如类名为APP_WIDGETS,则组成对应类别应用列表的url；对该url进行httpget请求,并得到页面内容。

步骤602：对得到的第二页面内容进行分析，可以获得具体应用包名信息。

步骤603：根据应用包名，获取应用详情等。可以为向应用详情接口服务器侧发送GET请求，获取应用详情，包括：应用名称、安装包下载地址、图标和截图下载地址、安装包大小、签名信息、版本号等。

进一步需要理解的是，本实施例中最终获取到的为每一种可下载应用的应用详情，比如，可以包括有应用名称、安装包下载地址、图标和截图下载地址、安装包大小、签名信息、版本号等。比如，应用名称为微信、安装包的下载地址为微信的服务器侧，微信的图标及其下载地址可以均在微信的服务器侧，另外，安装包的大小可以为30M，版本号可以用于表征当前提供的应用对应的版本，比如，可以为3.0版本。

可见，通过采用上述方案，就能够获取到目标应用的至少两个账户信息，并且从中选取一个账户信息登录目标应用，进而获取到目标应用能够提供的至少一个可下载应用程序的应用信息。如此，就避免了手动的获取到目标应用中的多个应用程序的应用信息，从而保证了从目标应用中获取到多个可下载应用程序的应用信息的处理效率，还减少了错误率。

实施例三、

在上述两个实施例的基础上，本实施例进一步提供根据配置判断是否对可下载应用程序进行下载，以及根据下载处理情况进行后续操作的场景。

所述方法还包括：

基于预设的配置信息确定是否基于所述应用信息进行下载；

若确定下载，则下载得到以下至少之一：可下载应用程序的安装包、可下载应用程序的图标、可下载应用程序的截图。

这里，需要说明的是，本实施例可以根据管理人员进行配置确定是否进行安装包的下载，进一步地，基于下载的安装包可以在电子设备侧进行安装包的检测，比如，可以包括有安装包所适用的系统或者所使用的设备等等，这里不再进行详述。

另外，关于所要下载的具体内容可以由管理人员在操作界面上进行选择，比如，可以选择下载某一类的应用，或者，可以选择下载某一个可下载应用。

如果获取成功，将应用详情保存至数据库，图片和应用安装包等大文件，可以保存至OSS云存储中。

所述方法还包括：

若无法基于所述应用信息进行下载，则获取到下载失败原因；

基于所述下载失败原因执行以下处理之一：

若所述下载失败原因表征为网络问题，则控制执行预设次数的下载处理，直至完成预设次数的下载处理且均下载失败，则将所述应用信息保存至下载失败列表；

若所述下载失败原因表征所述应用无法应用于目标设备，则结束下载处理；

若所述下载失败原因表征服务器对所述第一账户信息进行限制，则从所述至少两个账户信息中选取到第二账户信息，切换到第二账户登录所述目标应用，并执行对所述可下载应用程序的下载。

具体来说，如果获取失败，分析失败原因：

如果是网络问题，重试10次，如果10次都失败，则保存至失败列表；

如果应用不适用模拟设备，则该步骤跳过；

如果错误解析是遇到谷歌对账户的临时限制，则切换登录账户，继续下载。

进一步地，如果配置要求下载文件，则将下载请求利用Nginx将下载请求分散至各个下载服务器，每台下载服务器配置至少两个账户，然后根据安装包下载地址、图标和截图下载地址进行文件下载；下载完成后，调用OSS接口，将文件上传至OSS云存储中。

可见，通过采用上述方案，就能够获取到目标应用的至少两个账户信息，并且从中选取一个账户信息登录目标应用，进而获取到目标应用能够提供的至少一个可下载应用程序的应用信息。如此，就避免了手动的获取到目标应用中的多个应用程序的应用信息，从而保证了从目标应用中获取到多个可下载应用程序的应用信息的处理效率，还减少了错误率。

另外，还可以根据配置信息确定是否进行应用程序的安装包等具体内容的下载，提升了管理的有效性。

实施例四、

本发明实施例提供了一种电子设备，如图7所示，包括：

账户管理单元71，用于向目标应用的服务器侧发送账户获取请求，接收到所述服务器侧反馈的至少两个账户信息，并基于所述至少两个账户信息中的第一账户信息登录所述目标应用；其中，所述目标应用为能够提供至少一个可下载应用程序的下载服务的应用；

第一信息获取单元72，用于从所述目标应用的服务器侧获取到应用分类信息；其中，所述应用分类信息用于表示所述目标应用能够提供的至少一种应用类别；

第二信息获取单元73，用于基于所述应用分类信息，获取并保存每一种应用类别中包含的至少一个可下载应用程序的应用信息。

本发明实施例可以应用于任意一种电子设备，比如，可以应用于电脑、智能手机、平板电脑、笔记本等个人终端设备，还可以应用于服务器等设备。

本实施例中所述目标应用，即为能够为用户提供至少一种可下载应用程序的下载处理的应用，可以参见图4，在目标应用里提供了应用A、应用B和应用C三种可下载应用，具体来说，所述目标应用可以为google play，或者是某些应用商店类的应用。

具体地，假设我们要向google play进行信息获取的场景下，需要至少两个谷歌账号来申请授权。然后需要使用谷歌的protobuf SDK将请求参数进行编码，得到编码后的账户获取请求；

然后向目标应用的服务器发送账户获取请求，也就是进行checkin请求，请求之后可获得至少一个安卓标识(Android ID)和令牌(Token)；

根据获得的AndroidID和Token重新编码，得到至少一个账户信息；

然后基于至少一个账户信息再次向服务器进行checkin动作；Checkin动作完成以后，根据获得的AndroidID和Token，随机选取一个谷歌账户及第一账户信息，完成账户登录目标应用的操作。

上述应用分类信息可以为所述服务器侧能够提供的多个应用的多种类别，需要说明的是，获取到的应用分类信息可以只包括有应用类别信息，比如参见图5a和图5b，图5a表示应用分类信息可以仅为目标应用中的几种类别，图5b可以为一个实际用例，比如，目标应用中可以包括有游戏类应用、教育类应用、生活类应用、购物类应用、即时通信类应用等等。

进一步地，每一种应用类别中包括有至少一个可下载应用程序，比如，即时通信类中可以包括有微信、电话、通讯录管理等等应用；游戏类中可以包括有多种游戏，这里不进行穷举。

进一步需要理解的是，本实施例中最终获取到的为每一种可下载应用的应用详情，比如，可以包括有应用名称、安装包下载地址、图标和截图下载地址、安装包大小、签名信息、版本号等。比如，应用名称为微信、安装包的下载地址为微信的服务器侧，微信的图标及其下载地址可以均在微信的服务器侧，另外，安装包的大小可以为30M，版本号可以用于表征当前提供的应用对应的版本，比如，可以为3.0版本。

可见，通过采用上述方案，就能够获取到目标应用的至少两个账户信息，并且从中选取一个账户信息登录目标应用，进而获取到目标应用能够提供的至少一个可下载应用程序的应用信息。如此，就避免了手动的获取到目标应用中的多个应用程序的应用信息，从而保证了从目标应用中获取到多个可下载应用程序的应用信息的处理效率，还减少了错误率。

实施例五、

本发明实施例提供了一种电子设备，如图7所示，包括：

账户管理单元71，用于向目标应用的服务器侧发送账户获取请求，接收到所述服务器侧反馈的至少两个账户信息，并基于所述至少两个账户信息中的第一账户信息登录所述目标应用；其中，所述目标应用为能够提供至少一个可下载应用程序的下载服务的应用；

第一信息获取单元72，用于从所述目标应用的服务器侧获取到应用分类信息；其中，所述应用分类信息用于表示所述目标应用能够提供的至少一种应用类别；

第二信息获取单元73，用于基于所述应用分类信息，获取并保存每一种应用类别中包含的至少一个可下载应用程序的应用信息。

本发明实施例可以应用于任意一种电子设备，比如，可以应用于电脑、智能手机、平板电脑、笔记本等个人终端设备，还可以应用于服务器等设备。

本实施例中所述目标应用，即为能够为用户提供至少一种可下载应用程序的下载处理的应用，可以参见图4，在目标应用里提供了应用A、应用B和应用C三种可下载应用，具体来说，所述目标应用可以为google play，或者是某些应用商店类的应用。

具体地，假设我们要向google play进行信息获取的场景下，需要至少两个谷歌账号来申请授权。然后需要使用谷歌的protobuf SDK将请求参数进行编码，得到编码后的账户获取请求；

然后向目标应用的服务器发送账户获取请求，也就是进行checkin请求，请求之后可获得至少一个安卓标识(Android ID)和令牌(Token)；

根据获得的AndroidID和Token重新编码，得到至少一个账户信息；

然后基于至少一个账户信息再次向服务器进行checkin动作；Checkin动作完成以后，根据获得的AndroidID和Token，随机选取一个谷歌账户及第一账户信息，完成账户登录目标应用的操作。

本实施例详细介绍如何获取到应用分类信息以及如何获取到应用信息，具体如下：

所述第一信息获取单元，用于向所述目标应用的服务器侧发送第一访问请求，接收到服务器侧反馈的针对所述第一访问请求的第一页面内容信息；解析所述第一页面内容信息，获取到至少一种应用类别；将所述至少一种应用类别作为所述应用分类信息。

具体地，应用的类别信息，是通过对GooglePlay应用URL进行HTTP访问，然后对返回的第一页面内容进行格式解析，从第一页面内容中获取类别名。

上述应用分类信息可以为所述服务器侧能够提供的多个应用的多种类别，需要说明的是，获取到的应用分类信息可以只包括有应用类别信息，比如参见图5a和图5b，图5a表示应用分类信息可以仅为目标应用中的几种类别，图5b可以为一个实际用例，比如，目标应用中可以包括有游戏类应用、教育类应用、生活类应用、购物类应用、即时通信类应用等等。

进一步地，每一种应用类别中包括有至少一个可下载应用程序，比如，即时通信类中可以包括有微信、电话、通讯录管理等等应用；游戏类中可以包括有多种游戏，这里不进行穷举。

所述第二信息获取单元，用于基于应用类别组成针对所述应用类别的第二访问请求，发送所述第二访问请求至服务器侧；接收到所述服务器侧反馈的针对所述第二访问请求的第二页面内容信息；解析所述第二页面内容信息，获取到所述应用类别包含的至少一个可下载应用程序的应用信息，其中，所述应用信息中至少包括有以下至少之一：可下载应用程序名称、可下载应用程序的安装包下载地址、可下载应用程序的图标及其下载地址、可下载应用程序的截图及其下载地址。

进一步需要理解的是，本实施例中最终获取到的为每一种可下载应用的应用详情，比如，可以包括有应用名称、安装包下载地址、图标和截图下载地址、安装包大小、签名信息、版本号等。比如，应用名称为微信、安装包的下载地址为微信的服务器侧，微信的图标及其下载地址可以均在微信的服务器侧，另外，安装包的大小可以为30M，版本号可以用于表征当前提供的应用对应的版本，比如，可以为3.0版本。

可见，通过采用上述方案，就能够获取到目标应用的至少两个账户信息，并且从中选取一个账户信息登录目标应用，进而获取到目标应用能够提供的至少一个可下载应用程序的应用信息。如此，就避免了手动的获取到目标应用中的多个应用程序的应用信息，从而保证了从目标应用中获取到多个可下载应用程序的应用信息的处理效率，还减少了错误率。

实施例六、

在上述实施例四和实施例五的基础上，本实施例进一步提供根据配置判断是否对可下载应用程序进行下载，以及根据下载处理情况进行后续操作的场景。

基于图7提供的电子设备的组成结构，参见图8，所述电子设备还包括：

下载管理单元74，用于基于预设的配置信息确定是否基于所述应用信息进行下载；

若确定下载，则下载得到以下至少之一：可下载应用程序的安装包、可下载应用程序的图标、可下载应用程序的截图。

这里，需要说明的是，本实施例可以根据管理人员进行配置确定是否进行安装包的下载，进一步地，基于下载的安装包可以在电子设备侧进行安装包的检测，比如，可以包括有安装包所适用的系统或者所使用的设备等等，这里不再进行详述。

另外，关于所要下载的具体内容可以由管理人员在操作界面上进行选择，比如，可以选择下载某一类的应用，或者，可以选择下载某一个可下载应用。

如果获取成功，将应用详情保存至数据库，图片和应用安装包等大文件，可以保存至OSS云存储中。

所述下载管理单元，用于若无法基于所述应用信息进行下载，则获取到下载失败原因；

基于所述下载失败原因执行以下处理之一：

若所述下载失败原因表征为网络问题，则控制执行预设次数的下载处理，直至完成预设次数的下载处理且均下载失败，则将所述应用信息保存至下载失败列表；

若所述下载失败原因表征所述应用无法应用于目标设备，则结束下载处理；

若所述下载失败原因表征服务器对所述第一账户信息进行限制，则从所述至少两个账户信息中选取到第二账户信息，切换到第二账户登录所述目标应用，并执行对所述可下载应用程序的下载。

具体来说，如果获取失败，分析失败原因：

如果是网络问题，重试10次，如果10次都失败，则保存至失败列表；

如果应用不适用模拟设备，则该步骤跳过；

如果错误解析是遇到谷歌对账户的临时限制，则切换登录账户，继续下载。

进一步地，如果配置要求下载文件，可以参见图9则将下载请求利用Nginx将下载请求分散至各个文件下载服务器，每台下载服务器配置至少两个账户，然后根据安装包下载地址、图标和截图下载地址进行文件下载；下载完成后，调用OSS接口，将文件上传至OSS云存储中，比如图中所示的Redis中。

可见，通过采用上述方案，就能够获取到目标应用的至少两个账户信息，并且从中选取一个账户信息登录目标应用，进而获取到目标应用能够提供的至少一个可下载应用程序的应用信息。如此，就避免了手动的获取到目标应用中的多个应用程序的应用信息，从而保证了从目标应用中获取到多个可下载应用程序的应用信息的处理效率，还减少了错误率。

另外，还可以根据配置信息确定是否进行应用程序的安装包等具体内容的下载，提升了管理的有效性。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种信息获取方法，其特征在于，所述方法包括：

向目标应用的服务器侧发送账户获取请求，接收到所述服务器侧反馈的至少两个账户信息，并基于所述至少两个账户信息中的第一账户信息登录所述目标应用；其中，所述目标应用为能够提供至少一个可下载应用程序的下载服务的应用；

从所述目标应用的服务器侧获取到应用分类信息；其中，所述应用分类信息用于表示所述目标应用能够提供的至少一种应用类别；

基于所述应用分类信息，获取并保存每一种应用类别中包含的至少一个可下载应用程序的应用信息。

2.根据权利要求1所述的方法，其特征在于，所述从所述目标应用的服务器侧获取到应用分类信息，包括：

向所述目标应用的服务器侧发送第一访问请求，接收到服务器侧反馈的针对所述第一访问请求的第一页面内容信息；

解析所述第一页面内容信息，获取到至少一种应用类别；

将所述至少一种应用类别作为所述应用分类信息。

3.根据权利要求1所述的方法，其特征在于，所述获取到每一种应用类别中包含的至少一个可下载应用程序的应用信息，包括：

基于应用类别组成针对所述应用类别的第二访问请求，发送所述第二访问请求至服务器侧；

接收到所述服务器侧反馈的针对所述第二访问请求的第二页面内容信息；

解析所述第二页面内容信息，获取到所述应用类别包含的至少一个可下载应用程序的应用信息，其中，所述应用信息中至少包括有以下至少之一：可下载应用程序名称、可下载应用程序的安装包下载地址、可下载应用程序的图标及其下载地址、可下载应用程序的截图及其下载地址。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

基于预设的配置信息确定是否基于所述应用信息进行下载；

若确定下载，则下载得到以下至少之一：可下载应用程序的安装包、可下载应用程序的图标、可下载应用程序的截图。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

若无法基于所述应用信息进行下载，则获取到下载失败原因；

基于所述下载失败原因执行以下处理之一：

若所述下载失败原因表征为网络问题，则控制执行预设次数的下载处理，直至完成预设次数的下载处理且均下载失败，则将所述应用信息保存至下载失败列表；

若所述下载失败原因表征所述应用无法应用于目标设备，则结束下载处理；

若所述下载失败原因表征服务器对所述第一账户信息进行限制，则从所述至少两个账户信息中选取到第二账户信息，切换到第二账户登录所述目标应用，并执行对所述可下载应用程序的下载。

6.一种电子设备，其特征在于，所述电子设备包括：

账户管理单元，用于向目标应用的服务器侧发送账户获取请求，接收到所述服务器侧反馈的至少两个账户信息，并基于所述至少两个账户信息中的第一账户信息登录所述目标应用；其中，所述目标应用为能够提供至少一个可下载应用程序的下载服务的应用；

第一信息获取单元，用于从所述目标应用的服务器侧获取到应用分类信息；其中，所述应用分类信息用于表示所述目标应用能够提供的至少一种应用类别；

第二信息获取单元，用于基于所述应用分类信息，获取并保存每一种应用类别中包含的至少一个可下载应用程序的应用信息。

7.根据权利要求6所述的电子设备，其特征在于，所述第一信息获取单元，用于向所述目标应用的服务器侧发送第一访问请求，接收到服务器侧反馈的针对所述第一访问请求的第一页面内容信息；解析所述第一页面内容信息，获取到至少一种应用类别；将所述至少一种应用类别作为所述应用分类信息。

8.根据权利要求6所述的电子设备，其特征在于，所述第二信息获取单元，用于基于应用类别组成针对所述应用类别的第二访问请求，发送所述第二访问请求至服务器侧；接收到所述服务器侧反馈的针对所述第二访问请求的第二页面内容信息；解析所述第二页面内容信息，获取到所述应用类别包含的至少一个可下载应用程序的应用信息，其中，所述应用信息中至少包括有以下至少之一：可下载应用程序名称、可下载应用程序的安装包下载地址、可下载应用程序的图标及其下载地址、可下载应用程序的截图及其下载地址。

9.根据权利要求6-8任一项所述的电子设备，其特征在于，所述电子设备还包括：

下载管理单元，用于基于预设的配置信息确定是否基于所述应用信息进行下载；若确定下载，则下载得到以下至少之一：可下载应用程序的安装包、可下载应用程序的图标、可下载应用程序的截图。

10.根据权利要求9所述的电子设备，其特征在于，所述下载管理单元，用于若无法基于所述应用信息进行下载，则获取到下载失败原因；

基于所述下载失败原因执行以下处理之一：

若所述下载失败原因表征为网络问题，则控制执行预设次数的下载处理，直至完成预设次数的下载处理且均下载失败，则将所述应用信息保存至下载失败列表；

若所述下载失败原因表征所述应用无法应用于目标设备，则结束下载处理；

若所述下载失败原因表征服务器对所述第一账户信息进行限制，则从所述至少两个账户信息中选取到第二账户信息，切换到第二账户登录所述目标应用，并执行对所述可下载应用程序的下载。