1、最近在做一個(gè)自定義的音樂(lè)播放條:現(xiàn)在關(guān)鍵的點(diǎn)在于那個(gè)

現(xiàn)在關(guān)鍵的點(diǎn)在于那個(gè)黑色的進(jìn)度條需要監(jiān)聽(tīng)音樂(lè)的播放來(lái)更新這個(gè)黑條(我用的是一個(gè)imagevie)的長(zhǎng)度,現(xiàn)在的方案是新開(kāi)一個(gè)線(xiàn)程,獲取mediaPlayer當(dāng)前音樂(lè)的播放進(jìn)度和總時(shí)長(zhǎng),然后除一下,然后調(diào)用自定義View中更改這個(gè)黑色I(xiàn)mageview長(zhǎng)度的方法,但是更改View的外觀必須在MainThread中做,所以就用了runOnUiThread(new Runnable(){···})這個(gè)方法,最后發(fā)現(xiàn)效果不錯(cuò),能夠?qū)崿F(xiàn)功能,對(duì)性能幾乎也沒(méi)有影響
這個(gè)功能想了很久,但是一直不敢做,一開(kāi)始的思路是使用觀察者模式,發(fā)現(xiàn)使用觀察者模式也需要不斷地去獲取音樂(lè)的當(dāng)前播放進(jìn)度以及總的時(shí)長(zhǎng),其實(shí)現(xiàn)在分析起來(lái)發(fā)現(xiàn)是很容易的,但是當(dāng)時(shí)想到可以新開(kāi)一個(gè)線(xiàn)程去獲取音樂(lè)的當(dāng)前播放進(jìn)度以及總的時(shí)長(zhǎng)的時(shí)候總覺(jué)得會(huì)很卡,性能會(huì)很差一直想著有沒(méi)有更好的方法去解決這個(gè)問(wèn)題,所以耽擱了很長(zhǎng)的時(shí)間···· 有些事情要快速去做,否則會(huì)浪費(fèi)很多時(shí)間···
2、rxJava的subscription.unsubscribe();會(huì)再一次調(diào)用 subscriber的onNext()方法
3、現(xiàn)在發(fā)現(xiàn)Observable的一個(gè)特性,那就是Observable不間斷發(fā)送信號(hào)(這里體現(xiàn)為手動(dòng)調(diào)用onNext()),Subscriber的onNext()方法根本不會(huì)得到執(zhí)行,因?yàn)閬?lái)不及執(zhí)行(我是這么理解的),所以我們需要加上Thread.sleep(400);這樣的代碼減緩Obserable發(fā)送請(qǐng)求的頻率。
同時(shí)我還發(fā)現(xiàn),如果這個(gè)while(!subscriber.isUnsubscribed())里面的條件一直設(shè)為true,即寫(xiě)成while(true),當(dāng)你把綁定的subscriber解綁之后再與該Obserable綁定,Obserable的onNext()方法依然無(wú)法得到執(zhí)行,與上述不加Thread.sleep(400);的情況是一樣的,即沒(méi)有信號(hào)處理,只有信號(hào)發(fā)送。
我的理解是,在解綁這段時(shí)間里Obserable不斷發(fā)出的信號(hào)沒(méi)有處理一直被積壓,所以自然新加入的Subsciber自然沒(méi)有能力處理這些積壓的發(fā)送信號(hào),所以癱瘓了···
Observable observable=Observable.create(new Observable.OnSubscribe<double[]>()
{
@Override
public void call(Subscriber<? super double[]> subscriber)
{
while(!subscriber.isUnsubscribed())
{
try
{
Thread.sleep(400);
} catch (InterruptedException e)
{
e.printStackTrace();
}
double[] doubles =new double[2];
doubles[0] = DeviceUtils.getDeviceWidth(mContext); //屏幕總長(zhǎng)
doubles[1] =getMusicCurPos()/getDuration(); //歌曲播放比例
subscriber.onNext(doubles);
Log.d("PlayerProgress","onNext");
}
}
});