腾讯轻听模仿流水账（3）：16.11.30

1、最近在做一个自定义的音乐播放条：现在关键的点在于那个

最下面音乐播放条的那个就是我想要的效果

现在关键的点在于那个黑色的进度条需要监听音乐的播放来更新这个黑条（我用的是一个imagevie）的长度，现在的方案是新开一个线程，获取mediaPlayer当前音乐的播放进度和总时长，然后除一下，然后调用自定义View中更改这个黑色Imageview长度的方法，但是更改View的外观必须在MainThread中做，所以就用了runOnUiThread(new Runnable(){···})这个方法，最后发现效果不错，能够实现功能，对性能几乎也没有影响
这个功能想了很久，但是一直不敢做，一开始的思路是使用观察者模式，发现使用观察者模式也需要不断地去获取音乐的当前播放进度以及总的时长，其实现在分析起来发现是很容易的，但是当时想到可以新开一个线程去获取音乐的当前播放进度以及总的时长的时候总觉得会很卡，性能会很差一直想着有没有更好的方法去解决这个问题，所以耽搁了很长的时间···· 有些事情要快速去做，否则会浪费很多时间···

2、rxJava的subscription.unsubscribe();会再一次调用 subscriber的onNext()方法

3、现在发现Observable的一个特性，那就是Observable不间断发送信号（这里体现为手动调用onNext()），Subscriber的onNext()方法根本不会得到执行，因为来不及执行（我是这么理解的），所以我们需要加上Thread.sleep(400);这样的代码减缓Obserable发送请求的频率。
同时我还发现，如果这个while(!subscriber.isUnsubscribed())里面的条件一直设为true，即写成while(true)，当你把绑定的subscriber解绑之后再与该Obserable绑定，Obserable的onNext()方法依然无法得到执行，与上述不加Thread.sleep(400);的情况是一样的，即没有信号处理，只有信号发送。
我的理解是，在解绑这段时间里Obserable不断发出的信号没有处理一直被积压，所以自然新加入的Subsciber自然没有能力处理这些积压的发送信号，所以瘫痪了···

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);  //屏幕总长
                    doubles[1] =getMusicCurPos()/getDuration();   //歌曲播放比例

                    subscriber.onNext(doubles);
                    Log.d("PlayerProgress","onNext");
                }
            }
        });