つまり、まだ解決はしていないけど、どうしてこのようなログが吐出されるのかという点で類似する不具合から想像しているだけにすぎないのだけど。
昨日分かったことを並べていくと、
まず、現状問題となっているであろうと予測した「MediaPlayerの生成を何度もしないようにする。」という修正をやってみた。
これまで、曲の切り替えなどで毎回MediaPlayerを初期化していたのは、Resetして再利用するときに下手してStatusエラーがでちゃうのが不安だったので、面倒くさいからっていう理由でした。やはり、そういうことを面倒くさがらずに、一回使い終わったらちゃんと状態をみてResetをし、その後曲を設定するというように変更。
プログラム側からそのような処理を隠蔽するため、中間クラスとしてGaplessMediaPlayerというクラスと、その中で保持される、MediaPlayerHolderというMediaPlayerへの機能の移譲を行うクラスをもつようにした。
こうすることで、MediaConrollerクラスはスッキリした実装になったとおもう。
その後、きちんと動作するようにテストを実施したのですが、ここで新しいバグが発生した。
いままで以上に簡単にEqualizerの設定画面から戻るときに落ちるようになったのです。
しかも出力されるLogCatのパターンも同じ。
前よりひどくなったので、これはなにか変なことになってないかとジィっとプログラムをみてみたところ。一つ見つけました。
それは、Visualizerの解放の順番
間違ってる例
onPause()にて
onPause()にて
mVisualizer.setMeasurementMode(Visualizer.MEASUREMENT_MODE_NONE); mVisualizer.setEnabled(false); mVisualizer.release(); mVisualizer = null;
正しい例
onPause()にて
mVisualizer.setEnabled(false); mVisualizer.setMeasurementMode(Visualizer.MEASUREMENT_MODE_NONE); mVisualizer.release(); mVisualizer = null;
そう、setEnabledの設定順番が間違っていた。
これのせいで、Visualizerのリスナー処理のなかで、visualizer.getEnabled()を呼んでしまい例のダンプが発生していました。
LogCatの状況ではそれが原因にみえなかったのでわかりにくい。
すでに、Releaseで解放されてしまったVisualizerクラスに対してgetEnabled()をしちゃてているので、あのようなダンプにつながったのだとおもいます。
ということは、これまで悩ませていた不具合も、MediaPlayerに関連するVisualizer,Equalizer等でRelease済のものに対してなにか処理をしているのかもしれない。
しかし、おかしいのは上記の実装は、MediaPlayerの初期化の修正の前からのものです。
なので、発生するなら以前からずっと同じように発生しているはずなのですが、、
とにかく、同様のことをやっていないかプログラムを見直すことにします。
No comments:
Post a Comment