1.2. 我所谓流媒体的功能

以前我们谈过：

第一步：
声明两个Player，分别由两个独立的线程掌控着；

第二步：
HttpConnection开始向服务器请求该audio文件的第一部分字节，我们定这次读取的字节数为18KB；

第三步：
等第一部分数据到位后，Player A开始realize和prefetch，并开始播放；

第四步：
在Player A播放同时，(18KB的amr数据可以播放10秒钟)，HttpConnection继续请求第二部分数据(假设GPRS每秒钟传输3KB，那么18KB需要传输6秒，算上前后通讯损失的时间，应该不会超过10秒钟)；

第五步：
第二部分数据到位后，假设Player A还没有播放完(这需要调整你的每一部份数据字节数来使得假设成立)，那么将数据喂给Player B让它realize和prefetch；

第六步：
Player A播放完后，得到事件通知，于是让Player B开始播放。

如此往复。

      大致的思路就是这样。

这次，我们起了两个线程，一个叫做“Main(主) ”，一个叫做“Secondary(从属)”，他们都掌握着一个Player，同样一个是Main Player，一个是Secondary Player。这两个Player的操作实际上都被Audio.java类完全封装好了。线程里面仅仅是调用

Audio.prefetchSound(m_form,

                                             m_isInputMusic,

                                             m_Sequence);

啦，

Audio.playSound(m_Sequence);

啦，这样就可以把媒体资源预先运算以及播放了。

同时，还必须用到PlayerListener接口，来得到播放器的各种事件通知，我们需要得知每一个播放器的播放结束消息，以便作出下一步选择：是让从属线程开始播放呢，还是让主线程开始播放呢。

PlayerListener的播放结束消息(PlayerListener.END_OF_MEDIA)的处理中，我们还必须用到MVC模式中的Controller，它是代码中的GUIController.java，它负责处理几个消息：

l         EventID.EVENT_MAIN_DownloadCompleted

l         EventID.EVENT_Main_BeginToPlay

l         EventID.EVENT_SECONDARY_BeginToPlay

怎么综合使用这些消息和事件呢？

比如说，当主线程的媒体文件下载完毕后，就应该通知GUIController让从属线程也开始下载并加载媒体文件。

当主线程的媒体文件播放完毕了，这时候照理说从属线程的Player也已经预先加载好了下一个要播放的媒体文件(如果不行的话就应该调整媒体文件的大小了以使得下载时间和播放时间差不多)，就应该在

public void playerUpdate(Player player, String event, Object data)

的函数处理中，让Secondary Player播放了。

这次我们直接将媒体文件用讨论稿中谈及的ffmpeg自动切分的办法，已经辟成11小段的AMR文件了，每一个AMR文件都可以独立播放，连起来就是一首完整的《大长今》乐曲。

PlayerA和PlayerB只是周而复始的下载、预运算、播放他们罢了。只不过掌控着Player的两个线程和主控制器，会选择时机来让这些操作次第展开。

上面所说的逻辑，可以用下图表示：

3使用感受

摘要：本章 简单描述StreamingDemo在真实GPRS环境下的使用感受。

3.1. Nokia7610手机上的设置

如果你真的要在手机上用到这种功能，那么请申请开通你的GPRS包月套餐，那样20块钱就可以使用50MB流量的GPRS了。

如果你的手机是Nokia的S60系列手机，建议用Nokia程序管理器设置这个应用配置一个参数：在连接网络时第一次询问。否则你会屡屡被网络连接警告框打断的。

3.2. Nokia7610手机上的使用感受

这种流媒体的播放，还是取决于使用时GPRS网络的好坏。

我在晚上19点使用了一下，感觉比较流畅，甚至超乎我的预期，不认真听，甚至感觉不到在哪里停顿的。

但是在晚上20点又用了一下，就有点拖拖拉拉的，延迟较为明显。

可见现行的GPRS网络环境还是容易出现拥挤的。