了解J2ME在实际开发中的可选包MMAPI

核心提示：在MIDP1.0(JSR 37)并没有提供对声音和视频处理的支持，因此有些厂商就独立开发了API来弥补这样的不足，了解J2ME在实际开发中的可选包MMAPI，在MIDP2.0中(JSR 118)中提供了对多媒体处理的支持，但是它只是Mobile Media API(JSR 135)的一个子集，总结：MMAPI的设计相当

　　在MIDP1.0(JSR 37)并没有提供对声音和视频处理的支持，因此有些厂商就独立开发了API来弥补这样的不足。在MIDP2.0中(JSR 118)中提供了对多媒体处理的支持，但是它只是Mobile Media API(JSR 135)的一个子集。本文将主要对MMAPI做整体介绍。
　　
　　首先我们关注一下MMAPI的特性。
　　
　　支持单音，重复播放和记录基于时间的多媒体文件
　　
　　以CLDC为目标
　　
　　设计小巧，目的为了节省资源
　　
　　MMAPI并非针对任何内容类型和协议
　　
　　可以只实现MMAPI的子集，这就是为什么MIDP2.0中能够只实现其子集的原因
　　
　　扩展性强，MMAPI在不修改原来的功能的情况下可以添加新的功能
　　
　　选择性实现，实现者可以只实现部分功能
　　
　　通常在多媒体的处理过程中有两个重要的环节，一是处理数据传输的协议另一个是处理媒体的数据类型。在MMAPI中提供了DataSource和Player来完成这两步重要的内容。DataSource对数据传输协议进行封装不管它是从哪里过来的，可以是流、文件或者服务器资源等等。Player则负责解码工作，并传输给外设比如显示屏和扬声器，MMAPI的入口点是Manager类，通过它我们可以得到Player的实例。请看下图：
　　
　　通过如下方法我们可以得到一个Player的实例：
　　
　　public static Player
　　createPlayer(String locator)
　　throws IOException,
　　MediaException
　　public static Player
　　createPlayer(DataSource source)
　　throws IOException,
　　MediaException
　　public static Player
　　createPlayer(InputStream stream, String type)
　　throws IOException,
　　MediaException
　　
　　当创建一个Player的时候，它处于UNREALIZED的状态，当Player已经定位了它目标数据后就进入了REALIZED状态，接下来Player对数据进行缓冲这样可以确保播放的流畅，这个状态叫做PREFETCHED。当Player开始播放数据的时候是STARTED状态。Player对数据流提供了基本的控制，通过如下方法可以实现：
　　
　　Player.realize()
　　Player.prefetch()
　　Player.start()
　　Player.setMediaTime(long time)
　　
　　同时Player也答应对数据流进行详尽的控制，并且针对不同的类型提供不同的控制，通过如下方法我们可以获得Control
　　
　　Control[] Player.getControls()
　　Control Player.getControl
　　(String controlType)
　　
　　MMAPI提供了一些系统属性供查询，我们可以使用方法System.getProperty(String key)得到属性值。关于这些属性值得说明请参考MMAPI DOC。
　　
　　supports.mixing
　　supports.audio.capture
　　supports.video.capture
　　supports.recording
　　audio.encodings
　　video.encodings
　　video.snapshot.encodings
　　
　　通常我们想知道我们的机器是否支持某些特定的数据类型和传输协议，但是由于MMAPI规范中并没有规定这些，因此我们只能在运行时得到这些数据，可以调用Manager的getSupportedContentTypes()和getSupportedProtocols()。假如Player播放不能解释的数据或者处理不支持的协议的时候会抛出异常。
　　
　　总结：
　　
　　MMAPI的设计相当灵活，在使用MMAPI之前，理解他的结构和规范是非常重要的。