关于j2me mmapi的player接口的一些理解.

大多时候使用的player接口的时候,都是先声明player,然后用manager来createplayer,然后通过用player接口的start和stop来控制.当然这个是最简单的控制.但是其实真正的状态转化比这个还是要复杂那么一点点的.特别是在一些声音有问题的设备,了解状态的转化能够对排除问题和了解机器的bug有一定的帮助,特别是在移植的时候经常会碰的声音的问题的.

一个player总共有5个状态,可以说player的状态就是这之间互相转化的.
这五个状态分别是:
unrealized(没有实现), realized(实现), prefetched(缓冲读取), started(播放状态), closed(关闭状态).

首先声明一个player后,这个player的状态首先是unrealized(没有实现)状态,一般情况下这个时候会先用createplayer创建这个player,然后使用realize()方法将这个player的状态转化为realized(实现).

这个时候其实已经可以播放了,但是这个时候播放的话,在播放刚启动的时候或多或少会出现的问题就是刚开始的时候会卡一下(读取音乐资源的io操作的后果),因此这个时候最好能够让player进入prefetched(缓冲读取)的状态,这样无论在什么时候播放的话,中间的卡的停顿感就会消失.

这样的话,可以说一个player在播放之前已经准备完毕了.这个时候就能够随时播放了(或者说随时可以进入started(播放状态)了),这时候随时播放任何邪恶的触手的声音都没有问题.-_-特别是一些特殊的游戏对音效和音乐要求的播放时间的精准度比较高的,最好都要prefetched(缓冲读取)的状态比较好.
还有就是所谓的stop的使用,其实是返回prefetched(缓冲读取)的状态,因此并没有所谓的stopped的状态(这个名词的确念起来很顺口).一般如果播放完毕后会自动回到prefetched(缓冲读取)的状态.
关于关闭方面其实我想说的是,很多人关闭音乐都要有一个所谓的顺序之类的,其实没有必要,无论处于怎样的状态(除了closed本身),只要运行close()就能够直接返回closed状态的.其他的很多行为本身是不需要的,不过返回了closed状态本身就是相当于这个player已经关闭了.不能再进行任何别的使用操作了.如果还需要的话,重新创建一个吧.

可能这样说有点笼统,也许划线的话更好理解就是了

unrealized(没有实现)----->realized(实现)----->prefetched(缓冲读取)----->started(播放状态)   
                  realize()            prefetch()                 start()

started(播放状态)----->prefetched(缓冲读取)-----realized(实现)----->unrealized(没有实现)
                 stop()                deallocate()      

以上4个状态随时都可以用close()返回到closed状态.

不过......以上只是理想状态的状态转化而已..有些机型还是有一些问题的,之所以想写这个的原因就是可以利用这个原理来从中分析问题的出处,比如上周碰到的一款国外产品的6230i的移植的问题(208*208屏幕的一款机型),在setloopcount(-1)的情况下,当曲目播放第一遍的时候,状态转化都很正常,当播放第二遍以上的话,即使使用stop()将状态转化为prefetched(缓冲读取)背景也会在播放的.然后就只能针对这样的问题进行修改了.