CN108390935A - 一种基于文件流的音频播放策略 - Google Patents

Abstract

本发明涉及一种基于文件流的音频播放策略，步骤如下：（1）用户在客户端启动App，并请求播放音频；（2）获取音频播放必要信息；（3）调用音频信息管理器，检查必要信息是否完整可用；（4）根据音频文件的URL地址，请求网络通道并尝试访问；（5）执行鉴权处理，确认客户端、App及用户均有权限；（6）确认音频文件访问权限和用户是否匹配；（7）音频文件的URL地址解码，得到音频文件真正的获取地址；（8）从真正的获取地址以文件流的形式获取音频文件；（9）播放音频文件。本发明，处理流程清晰，容错性好，安全性高，解码速度快，能兼顾多种文件协议和多种音频格式解码，播放器的运行效率有保障，在线播放安全性、可靠性好，便于后期维护。

Description

一种基于文件流的音频播放策略

技术领域

本发明涉及音频在线传输及播放技术领域，具体说是一种基于文件流的音频播放策略。

背景技术

流媒体，又叫流式媒体，是边传边播的媒体，是多媒体的一种。边传边播是指：媒体提供商在网络上传输媒体的“同时”，用户一边不断地接收并观看（视频）或收听（音频）被传输的媒体。“流”媒体的“流”指的是媒体的传输方式（流的方式），而并不是指媒体本身。即：所谓流媒体是指采用流式传输的方式在Internet播放的媒体格式。

传送服务器把媒体信息（简称媒体）当成数据包发出，传送到网络上。用户通过解压设备对这些数据包进行解压后，媒体就会像发送前那样显示出来。流媒体在远程教育、视频点播、网络电台、网络视频等方面有着广泛的应用。

现有技术中，在网络上传输音/视频等媒体信息，主要有下载和流式传输两种方案。

下载常常要花数分钟甚至数小时，用户本地需要大的存储容量支持媒体的下载及保存，下载完毕后才能观看（视频）或收听（音频）媒体信息，所以这种处理方法延迟也很大。

流式传输尤其适用于时基媒体（音频、视频等多媒体文件），时基媒体由传送服务器向用户计算机连续、实时的传送，用户不必等到整个文件全部下载完毕，而只需经过几秒或十数秒的启动延时即可进行观看或收听。当时基媒体在客户端上播放时，文件的剩余部分将在后台从服务器内继续传送。流式不仅使启动延时成十倍、百倍地缩短，而且不需要太大的缓存容量。流式传输避免了用户必须等待整个文件全部从Internet上下载才能观看的缺点。

流式媒体在播放前并不下载整个文件，只将开始部分内容存入用户计算机（例如内存），流式媒体的数据流随时传送随时播放，只是在开始时有一些延迟。流媒体实现的关键技术就是流式传输。

流式传输定义很广泛，主要指通过网络传送媒体（如音频、视频）的技术总称。实现流式传输有两种方法：实时流式传输（Real time streaming）和顺序流式传输（progressive streaming）。

顺序流式传输是顺序下载，在下载文件的同时用户可观看在线媒体，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的前头部分，在传输期间不根据用户连接的速度对下载顺序做调整。

实时流式传输可保证媒体信号带宽与网络连接匹配，使媒体可被实时观看到。实时流式传输根据网络情况调整输出音视频的质量从而实现媒体的持续的实时传送，用户可快进或后退以观看前面或后面的内容。

一般说来，如视频为实时广播，或使用流式传输媒体服务器，或应用如RTSP（RealTime Streaming Protocol，RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议）的实时协议，即为实时流式传输。如使用HTTP（HyperText Transfer Protocol，超文本传输协议，是互联网上应用最为广泛的一种网络协议）服务器，文件即通过顺序流发送，即为顺序流式传输。采用哪种传输方法依赖具体需求。当然，流式文件也支持在播放前完全下载到硬盘。

流的概念：流，简单来说就是建立在面向对象基础上的一种抽象的处理数据的工具。在流中，定义了一些处理数据的基本操作，如读取数据，写入数据等，程序员是对流进行所有操作的，而不用关心流的另一头数据的真正流向。流不但可以处理文件，还可以处理动态内存、网络数据等多种数据形式。如果你对流的操作非常熟练，在程序中利用流的方便性，写起程序会大大提高效率的。

在iOS***中，提供了文件流操作类-NSFileHandle，允许更有效地使用文件，Objective-C使用NSFileHandle类对文件进行流操作，可以很好的支持流媒体，更适合于音频在线传输及播放。

NSFileHandle基本步骤如下：

1、打开文件，获取NSFileHandle对象。

2、对上面打开文件，通过NSFileHandle对象进行I/O流操作。

3、关闭文件。

由于音频媒体涉及版权，其在网络传输中的安全性、可靠性是行业竞争的关键，各家对音频播放时的处理策略都各不相同，考虑到前端开发和后台开发的协调、后期维护，有必要统一规范适合于本企业App（英文Application的简称，指智能设备的第三方应用程序，例如智能手机、智能平板等，智能设备可统称客户端）的音频播放策略。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种基于文件流的音频播放策略，处理流程清晰，容错性好，安全性高，解码速度快，能兼顾多种文件协议和多种音频格式解码，播放器的运行效率有保障，在线播放安全性、可靠性好，便于后期维护。

为达到以上目的，本发明采取的技术方案是：

一种基于文件流的音频播放策略，其特征在于，包括如下步骤：

步骤1，用户在客户端启动App，并请求播放音频；

步骤2，App获取音频播放必要信息，所述音频播放必要信息至少包括：

音频文件的ID，用于唯一标识某一音频文件，

音频文件的获取地址，包括：音频文件的物理地址，或音频文件的URL地址，物理地址对应于播放本地音频，URL地址对应于播放在线音频，

音频文件的音频格式，

音频文件的码率，

音频文件的播放时长；

步骤3，App调用音频信息管理器，检查音频播放必要信息是否完整可用，

如果信息不完整可用，则返回不可用错误信息，

如果信息完整可用，则转步骤4；

步骤4，当获取地址为音频文件的物理地址，转播放本地音频处理，按现有技术实施，不再详述，

当获取地址为音频文件的URL地址，则请求网络通道并尝试访问；

步骤5，执行鉴权处理，确认客户端、App及用户均有权通过网络通道访问音频文件的URL地址，

如果鉴权失败，则返回无权限错误信息，

如果鉴权成功，则转步骤6；

步骤6，确认音频文件访问权限和用户是否匹配，

如果用户无权限访问音频文件，则返回无权限错误信息，

如果用户有权限访问音频文件，则转步骤7；

步骤7，音频文件的URL地址解码，得到音频文件真正的获取地址，防止地址盗链，防止非法访问，真正的获取地址指向预设的传送服务器，

如果解码错误，则返回地址错误信息，

如果解码正确，则转步骤8；

步骤8，从真正的获取地址以文件流的形式获取音频文件；在获取音频文件时，循环等待文件流；循环等待文件流是因为音频文件不是一次性下载到本地，而是以流的方式通过网络传输；

步骤9，播放音频文件。

在上述技术方案的基础上，步骤2所述App获取音频播放必要信息时，还获取音频显示必要信息，所述音频显示必要信息至少包括：

音乐名称，

演唱歌手姓名，

演唱专辑名称，

音乐封面图片，

音乐歌词。

在上述技术方案的基础上，步骤3所述检查音频播放必要信息是否完整可用具体步骤如下：

检查音频播放必要信息是否缺失，

检查音频文件的ID格式是否正确，

检查音频文件的获取地址格式是否正确，

检查音频文件的音频格式是否为播放器支持的音频格式，

检查音频文件的码率格式是否正确。

在上述技术方案的基础上，步骤5所述鉴权处理具体步骤如下：

客户端通过iOS设备唯一识别码UDID或广告标识符IDFA或站点标识符MAC Address进行鉴权，用户通过选择开关确定是否对客户端进行绑定，绑定的客户端其参数设置和/或充值缴费具有高优先级，参数设置可同步到未绑定的同一用户的其他客户端中，充值缴费可设定为仅绑定客户端可执行，用于防止用户资金被盗刷、盗用、越权使用；

App通过通用唯一识别码UUID或“机器＋应用”的唯一标识bundle_id进行鉴权，用于防止App被恶意修改、利用，在App第一次启动时调用一次，然后将该串存储起来，在需要时替代UDID来使用；

用户通过用户账号+密码或用户账号+密码+临时验证码或用户账号+短信验证码进行鉴权，用于防止未登录或未授权用于超权限使用。

在上述技术方案的基础上，步骤6具体步骤如下：

根据用户id信息判断用户的权限等级，

根据音频文件的ID和用户的权限等级，请求网络，检查用户是否有权限播放音频文件的ID对应的音频文件，

根据音频文件的ID判断音频文件的版权登记，检查音频文件是否被授权使用。

在上述技术方案的基础上，步骤7所述音频文件的URL地址解码具体步骤如下：

获取音频文件的ID，

获取客户端和服务端约定的客户端密钥，

发送音频文件的ID、客户端密钥、音频文件的URL地址到服务端，

服务端验证客户端密钥通过后，用服务端密钥完成对音频文件的URL地址的解码，得到音频文件真正的获取地址，

用客户端密钥及时间戳加密音频文件真正的获取地址，得到二次加密地址，

服务端将二次加密地址返回客户端，

服务端将时间戳绑定用户ID，

通过用户ID获取绑定的时间戳，

客户端用客户端密钥及时间戳完成对二次加密地址的解码，得到音频文件真正的获取地址。

在上述技术方案的基础上，步骤8所述文件流的获取步骤如下：

步骤8.1，App调用下载器，从传送服务器以文件流的形式获取音频文件，

判断当前是否下载到数据，

如果没有下载到数据，则返回下载错误信息，

如果有下载到数据，则转步骤8.2；

步骤8.2，进一步判断是否需要解密，

如果需要解密，则将文件流进行跳转，进行解密处理，解密后再写入文件流缓冲器，

如果不需要解密，则直接写入文件流缓冲器；

步骤8.3，等待文件流缓冲器发出的缓冲消息，

如果可用数据量未满，则继续等待，

如果可用数据量已满，则返回文件尾部，完成获取音频文件。

在上述技术方案的基础上，在执行步骤8之前，先执行音频格式的判断和矫正处理，具体步骤如下：

获取音频播放必要信息中的音频文件的音频格式后，调用音频格式分析器，判断音频播放必要信息是否可用，

如果不可用，则返回格式未知错误，

如果可用，则查询音频文件暂存器，判断本地是否存在该音频格式的音频文件，

如果存在，则转步骤9，

如果不存在，则执行步骤8。

在上述技术方案的基础上，在执行步骤8之后，分析获取音频文件的音频格式，产生临时音频格式，

将临时音频格式和音频播放必要信息中的音频文件的音频格式对比，

如果不相同，则返回矫正提示信息，

如果相同，则音频文件写入音频文件暂存器。

在上述技术方案的基础上，传送服务器接收矫正提示信息，核查音频文件的音频格式，

修正传送服务器中记录的音频文件的音频格式，

修正音频播放必要信息中的音频文件的音频格式，

如果修正后的音频格式与音频文件暂存器中音频文件不同，则进一步清空音频文件暂存器，重新执行步骤8。

本发明所述的基于文件流的音频播放策略，处理流程清晰，容错性好，安全性高，解码速度快，能兼顾多种文件协议和多种音频格式解码，播放器的运行效率有保障，在线播放安全性、可靠性好，便于后期维护。

附图说明

本发明有如下附图：

图1 本发明的流程图。

具体实施方式

以下结合附图对本发明作进一步详细说明。

本发明所述的基于文件流的音频播放策略，功能规划如下：

功能1：播放在线音频，

播放在线音频时，基于文件流传输音频文件的媒体信息，

在线音频基于文件流传输并存储为本地音频，

音频文件实际获取地址的保护。

功能2：播放本地音频，播放本地音频时，按现有技术实施，本发明中不详述。

功能3：音频格式的判断和矫正。

功能4：音频格式的解码器获取。

功能5：文件流的加密和解密。

功能6：播放音频跳过前奏功能。

功能7：实时拖动播放进度，播放音频功能。

功能8：自动切换歌曲功能。

功能9：播放模式选择功能。

功能10：播放音质切换功能。

如图1所示，本发明所述的基于文件流的音频播放策略，包括如下步骤：

步骤1，用户在客户端启动App，并请求播放音频；

步骤2，App获取音频播放必要信息，所述音频播放必要信息至少包括：

音频文件的ID，用于唯一标识某一音频文件，

音频文件的获取地址，包括：音频文件的物理地址，或音频文件的URL地址，物理地址对应于播放本地音频，URL地址对应于播放在线音频，

音频文件的音频格式，

音频文件的码率，

音频文件的播放时长；

步骤3，App调用音频信息管理器，检查音频播放必要信息是否完整可用，

如果信息不完整可用，则返回不可用错误信息，

如果信息完整可用，则转步骤4；

步骤4，当获取地址为音频文件的物理地址，转播放本地音频处理，按现有技术实施，不再详述，

当获取地址为音频文件的URL地址，则请求网络通道并尝试访问；

步骤5，执行鉴权处理，确认客户端、App及用户均有权通过网络通道访问音频文件的URL地址，

如果鉴权失败，则返回无权限错误信息，

如果鉴权成功，则转步骤6；

步骤6，确认音频文件访问权限和用户是否匹配，

如果用户无权限访问音频文件，则返回无权限错误信息，

如果用户有权限访问音频文件，则转步骤7；

步骤7，音频文件的URL地址解码，得到音频文件真正的获取地址，防止地址盗链，防止非法访问，真正的获取地址指向预设的传送服务器，

如果解码错误，则返回地址错误信息，

如果解码正确，则转步骤8；

步骤8，从真正的获取地址以文件流的形式获取音频文件；在获取音频文件时，循环等待文件流；循环等待文件流是因为音频文件不是一次性下载到本地，而是以流的方式通过网络传输；

步骤9，播放音频文件。

所述文件流，是指将服务端中的文件以流的形式进行传输，传输给客户端。客户端收到服务端给来的流后，会将流缓冲进入本地文件，通常处理方式如下：

首先需要打开open某个文件，如：

void open(const char* filename,ios_base::openmode mode);

参数的含义：

filename：要打开的文件名

mode：要打开文件的方式

打开文件后，利用write函数将流写入文件。并且将文件流存入播放器内存缓冲buffer中，准备播放。

使用文件流是因为：在流中，定义了一些处理数据的基本操作，如读取数据，写入数据等，程序员是对流进行所有操作的，而不用关心流的另一头数据的真正流向。并且非常灵活易用。

在上述技术方案的基础上，步骤2所述App获取音频播放必要信息时，还获取音频显示必要信息，所述音频显示必要信息至少包括：

音乐名称，

演唱歌手姓名，

演唱专辑名称，

音乐封面图片，

音乐歌词。

在上述技术方案的基础上，所述音频播放必要信息和音频显示必要信息，存储于自定义的音乐信息的数据结构MusicItem中，App在需要时调用自定义的音乐信息的数据结构MusicItem以存入或取出音频播放必要信息和音频显示必要信息。

App采用自定义的音乐信息的数据结构MusicItem，可以更好的对音频播放必要信息和音频显示必要信息进行管理，后期维护也比较方便。例如：

创建一个MusicItem类

public class MusicItem {

String name; --存储音乐的名字

Uri songUri; --存储音乐的Uri地址

Uri albumUri;--存储音乐封面的Uri地址

Bitmap thumb;--存储封面图片

long duration;--存储音乐的播放时长，单位是毫秒

MusicItem(Uri songUri, Uri albumUri, String strName, long duration) {

this.name = strName;

this.songUri = songUri;

this.duration = duration;

this.albumUri = albumUri;

}

}

MusicItem类的具体信息可按需调整，上述仅为一个示例。

在上述技术方案的基础上，步骤1所述App维护一播放列表，用于存储正在播放的音乐及等待播放的音乐，

App每次启动时，从播放列表获取上次运行时正在播放的音乐及等待播放的音乐。

在上述技术方案的基础上，步骤3所述检查音频播放必要信息是否完整可用具体步骤如下：

检查音频播放必要信息是否缺失，

检查音频文件的ID格式是否正确，

检查音频文件的获取地址格式是否正确，

检查音频文件的音频格式是否为播放器支持的音频格式，

检查音频文件的码率格式是否正确。

在上述技术方案的基础上，步骤5所述鉴权处理具体步骤如下：

客户端通过iOS设备唯一识别码UDID或广告标识符IDFA或站点标识符MAC Address进行鉴权，用户通过选择开关确定是否对客户端进行绑定，绑定的客户端其参数设置和/或充值缴费具有高优先级，参数设置可同步到未绑定的同一用户的其他客户端中，充值缴费可设定为仅绑定客户端可执行，用于防止用户资金被盗刷、盗用、越权使用；

App通过通用唯一识别码UUID或“机器＋应用”的唯一标识bundle_id进行鉴权，用于防止App被恶意修改、利用，在App第一次启动时调用一次，然后将该串存储起来，在需要时替代UDID来使用；

用户通过用户账号+密码或用户账号+密码+临时验证码或用户账号+短信验证码进行鉴权，用于防止未登录或未授权用于超权限使用。

在上述技术方案的基础上，步骤6具体步骤如下：

根据用户id信息判断用户的权限等级，

根据音频文件的ID和用户的权限等级，请求网络，检查用户是否有权限播放音频文件的ID对应的音频文件，

根据音频文件的ID判断音频文件的版权登记，检查音频文件是否被授权使用。

在上述技术方案的基础上，步骤7所述音频文件的URL地址解码具体步骤如下：

获取音频文件的ID，

获取客户端和服务端约定的客户端密钥，

发送音频文件的ID、客户端密钥、音频文件的URL地址到服务端，

服务端验证客户端密钥通过后，用服务端密钥完成对音频文件的URL地址的解码，得到音频文件真正的获取地址，

用客户端密钥及时间戳加密音频文件真正的获取地址，得到二次加密地址，

服务端将二次加密地址返回客户端，

服务端将时间戳绑定用户ID，

通过用户ID获取绑定的时间戳，

客户端用客户端密钥及时间戳完成对二次加密地址的解码，得到音频文件真正的获取地址。

在上述解码的基础上，相应的音频文件的URL地址加密具体步骤如下：

服务端产生加密随机数，

服务端通过加密随机数与客户端约定客户端密钥，

服务端通过加密随机数生成服务端密钥，

服务端通过服务端密钥对音频文件真正的获取地址进行加密处理，得到可对外发布的音频文件的URL地址。

为了简化加密解密音频文件真正的获取地址的繁琐程度，也可考虑重定向地址、具有时间戳fstime的临时URL地址、使用自定的加密函数生成加密签名字符串等方式，对音频文件真正的获取地址进行加密处理及解密处理，将加密处理后的音频文件的URL地址公开给用户。

在上述技术方案的基础上，步骤8所述文件流的获取步骤如下：

步骤8.1，App调用下载器，从传送服务器以文件流的形式获取音频文件，

判断当前是否下载到数据，

如果没有下载到数据，则返回下载错误信息，

如果有下载到数据，则转步骤8.2；

步骤8.2，进一步判断是否需要解密，

如果需要解密，则将文件流进行跳转，进行解密处理，解密后再写入文件流缓冲器，

如果不需要解密，则直接写入文件流缓冲器；

步骤8.3，等待文件流缓冲器发出的缓冲消息，

如果可用数据量未满，则继续等待，

如果可用数据量已满，则返回文件尾部，完成获取音频文件。

所述可用数据量是当前音频文件（例如歌曲）的总数据量，需要从网络中下载填充，当可用数据量已满，代表音频缓冲成功，即当前音频文件（例如歌曲）已经从网络中下载填充完毕。

在上述技术方案的基础上，在执行步骤8之前，先执行音频格式的判断和矫正处理，具体步骤如下：

获取音频播放必要信息中的音频文件的音频格式后，调用音频格式分析器，判断音频播放必要信息是否可用，

如果不可用，则返回格式未知错误，

如果可用，则查询音频文件暂存器，判断本地是否存在该音频格式的音频文件，

如果存在，则转步骤9，

如果不存在，则执行步骤8。

如果音频文件本地已经存在，则无需执行步骤8，故在执行步骤8之前，有此预处理过程。

在上述技术方案的基础上，在执行步骤8之后，分析获取音频文件的音频格式，产生临时音频格式，

将临时音频格式和音频播放必要信息中的音频文件的音频格式对比，

如果不相同，则返回矫正提示信息，

如果相同，则音频文件写入音频文件暂存器。

在上述技术方案的基础上，传送服务器接收矫正提示信息，核查音频文件的音频格式，

修正传送服务器中记录的音频文件的音频格式，

修正音频播放必要信息中的音频文件的音频格式，

如果修正后的音频格式与音频文件暂存器中音频文件不同，则进一步清空音频文件暂存器，重新执行步骤8。

清空音频文件暂存器的原因如下：因为音频缓冲器中会存有歌曲播放数据，如果修正后的音频格式与音频文件暂存器中音频文件不同，那么需要清空暂存器，如果不清空则会导致数据缓冲存在，假如此时播放另外一首正确的歌曲，那么会使用之前暂存器中的垃圾数据，导致播放错乱。

在上述技术方案的基础上，步骤9中，播放音频文件具体步骤如下：

步骤9.1，获取设备播放权限，在iOS***中，设备播放音频时需要获取当前设备音频播放权限，使app拥有播放app的权利，

如果播放权限获取失败，则尝试不多于预设次数的获取重试，默认预设次数为3次，如依然获取失败，则返回无播放权限错误信息，

如果播放权限获取成功，则获取音频信息和音频数据流；

步骤9.2，判断音频信息是否可用，

如果不可用，则返回音频播放失败信息，

如果可用，则设置播放队列；

步骤9.3，判断音频缓冲区是否收到文件流，

如果没有收到，则继续等待，转步骤9.4，

如果有收到，则转步骤9.5；

步骤9.4，进一步判断等待是否超过阈值，

如果超过，则返回音频播放失败信息，

如果没超过，则转步骤9.3，

步骤9.5，处理音频数据流。

在上述技术方案的基础上，步骤9.5具体步骤如下：

步骤9.5.1，调用音频解码器管理模块，判断音频数据流是否可解码播放，

如果不可以，则返回音频播放失败信息，

如果可以，则转步骤9.5.2；

是否可解码播放是指是否支持音频数据流对应的音频格式的播放；

步骤9.5.2，根据音频格式判断有无对应的音频解码器，

有则直接从本地调用音频解码器，

没有则从相应服务器下载音频解码器到本地后，从本地调用音频解码器；

步骤9.5.3，音频解码器解码播放音频数据流，

如果解码失败，则返回音频播放失败信息，

如果解码成功，则是输出解码数据进行播放。

本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。

Claims (10)

1.一种基于文件流的音频播放策略，其特征在于，包括如下步骤：

步骤1，用户在客户端启动App，并请求播放音频；

步骤2，App获取音频播放必要信息，所述音频播放必要信息至少包括：

音频文件的ID，用于唯一标识某一音频文件，

音频文件的获取地址，包括：音频文件的物理地址，或音频文件的URL地址，物理地址对应于播放本地音频，URL地址对应于播放在线音频，

音频文件的音频格式，

音频文件的码率，

音频文件的播放时长；

步骤3，App调用音频信息管理器，检查音频播放必要信息是否完整可用，

如果信息不完整可用，则返回不可用错误信息，

如果信息完整可用，则转步骤4；

步骤4，当获取地址为音频文件的物理地址，转播放本地音频处理，按现有技术实施，不再详述，

当获取地址为音频文件的URL地址，则请求网络通道并尝试访问；

步骤5，执行鉴权处理，确认客户端、App及用户均有权通过网络通道访问音频文件的URL地址，

如果鉴权失败，则返回无权限错误信息，

如果鉴权成功，则转步骤6；

步骤6，确认音频文件访问权限和用户是否匹配，

如果用户无权限访问音频文件，则返回无权限错误信息，

如果用户有权限访问音频文件，则转步骤7；

步骤7，音频文件的URL地址解码，得到音频文件真正的获取地址，防止地址盗链，防止非法访问，真正的获取地址指向预设的传送服务器，

如果解码错误，则返回地址错误信息，

如果解码正确，则转步骤8；

步骤8，从真正的获取地址以文件流的形式获取音频文件；在获取音频文件时，循环等待文件流；循环等待文件流是因为音频文件不是一次性下载到本地，而是以流的方式通过网络传输；

步骤9，播放音频文件。

2.如权利要求1所述的基于文件流的音频播放策略，其特征在于：步骤2所述App获取音频播放必要信息时，还获取音频显示必要信息，所述音频显示必要信息至少包括：

音乐名称，

演唱歌手姓名，

演唱专辑名称，

音乐封面图片，

音乐歌词。

3.如权利要求1所述的基于文件流的音频播放策略，其特征在于：步骤3所述检查音频播放必要信息是否完整可用具体步骤如下：

检查音频播放必要信息是否缺失，

检查音频文件的ID格式是否正确，

检查音频文件的获取地址格式是否正确，

检查音频文件的音频格式是否为播放器支持的音频格式，

检查音频文件的码率格式是否正确。

4.如权利要求1所述的基于文件流的音频播放策略，其特征在于：步骤5所述鉴权处理具体步骤如下：

客户端通过iOS设备唯一识别码UDID或广告标识符IDFA或站点标识符MAC Address进行鉴权，用户通过选择开关确定是否对客户端进行绑定，绑定的客户端其参数设置和/或充值缴费具有高优先级，参数设置可同步到未绑定的同一用户的其他客户端中，充值缴费可设定为仅绑定客户端可执行，用于防止用户资金被盗刷、盗用、越权使用；

App通过通用唯一识别码UUID或“机器＋应用”的唯一标识bundle_id进行鉴权，用于防止App被恶意修改、利用，在App第一次启动时调用一次，然后将该串存储起来，在需要时替代UDID来使用；

用户通过用户账号+密码或用户账号+密码+临时验证码或用户账号+短信验证码进行鉴权，用于防止未登录或未授权用于超权限使用。

5.如权利要求1所述的基于文件流的音频播放策略，其特征在于：步骤6具体步骤如下：

根据用户id信息判断用户的权限等级，

根据音频文件的ID和用户的权限等级，请求网络，检查用户是否有权限播放音频文件的ID对应的音频文件，

根据音频文件的ID判断音频文件的版权登记，检查音频文件是否被授权使用。

6.如权利要求1所述的基于文件流的音频播放策略，其特征在于：步骤7所述音频文件的URL地址解码具体步骤如下：

获取音频文件的ID，

获取客户端和服务端约定的客户端密钥，

发送音频文件的ID、客户端密钥、音频文件的URL地址到服务端，

服务端验证客户端密钥通过后，用服务端密钥完成对音频文件的URL地址的解码，得到音频文件真正的获取地址，

用客户端密钥及时间戳加密音频文件真正的获取地址，得到二次加密地址，

服务端将二次加密地址返回客户端，

服务端将时间戳绑定用户ID，

通过用户ID获取绑定的时间戳，

客户端用客户端密钥及时间戳完成对二次加密地址的解码，得到音频文件真正的获取地址。

7.如权利要求1所述的基于文件流的音频播放策略，其特征在于：步骤8所述文件流的获取步骤如下：

步骤8.1，App调用下载器，从传送服务器以文件流的形式获取音频文件，

判断当前是否下载到数据，

如果没有下载到数据，则返回下载错误信息，

如果有下载到数据，则转步骤8.2；

步骤8.2，进一步判断是否需要解密，

如果需要解密，则将文件流进行跳转，进行解密处理，解密后再写入文件流缓冲器，

如果不需要解密，则直接写入文件流缓冲器；

步骤8.3，等待文件流缓冲器发出的缓冲消息，

如果可用数据量未满，则继续等待，

如果可用数据量已满，则返回文件尾部，完成获取音频文件。

8.如权利要求1所述的基于文件流的音频播放策略，其特征在于：在执行步骤8之前，先执行音频格式的判断和矫正处理，具体步骤如下：

获取音频播放必要信息中的音频文件的音频格式后，调用音频格式分析器，判断音频播放必要信息是否可用，

如果不可用，则返回格式未知错误，

如果可用，则查询音频文件暂存器，判断本地是否存在该音频格式的音频文件，

如果存在，则转步骤9，

如果不存在，则执行步骤8。

9.如权利要求8所述的基于文件流的音频播放策略，其特征在于：在执行步骤8之后，分析获取音频文件的音频格式，产生临时音频格式，

将临时音频格式和音频播放必要信息中的音频文件的音频格式对比，

如果不相同，则返回矫正提示信息，

如果相同，则音频文件写入音频文件暂存器。

10.如权利要求9所述的基于文件流的音频播放策略，其特征在于：传送服务器接收矫正提示信息，核查音频文件的音频格式，

修正传送服务器中记录的音频文件的音频格式，

修正音频播放必要信息中的音频文件的音频格式，

如果修正后的音频格式与音频文件暂存器中音频文件不同，则进一步清空音频文件暂存器，重新执行步骤8。