录制启动优化

唱歌作为主产品的核心功能，用户体验是非常重要的。随着版本的不断迭代，在开始录制时要做的准备工作变得越来越多，越来越繁重。导致在点击开始录制后，到真正开始录制，也就是开始播放伴奏，用户等待时间比较久。今天我们就来梳理一下， 唱吧在开始录制时做了哪些事情，以及如何为产品提速。

首先，我们来梳理一下启动时都做了什么：

1. 首先是统计。好吧，必须的

2. 检查sdcard剩余存储空间。视频需要预留的多一些，音频要求比视频低一些，但也需要一个门槛。低于我们要求的话提示用户清理内存，禁止录制

3. 对伴奏格式进行检测。录制阶段的播放器仅支持指定格式的音频文件，其他格式会提示伴奏文件错误，禁止录制

4. 权限检查及申请。麦克风权限、摄像头权限

5. 如果当前设备有提供硬件耳返SDK的话，我们在这里使用集成进来的SDK打开手机的硬件耳返提升录制体验

6. 实例并初始化Recorder、Player、Decoder、Camera、Score、VoiceAnalysis、Producer等组件，这里大部分为native操作

7. 启动Consumer线程用来处理录制结果，开始录制

以上这么多事情，如果我们依次处理的话效率太低。这里我们可以将任务分成两批，1-4步我们可以认为是前置条件，后面5-7作为第二批。然后使用RxJava提供的zip操作符，将具体要执行的事件进行合并。

关于zip操作符官方文档描述：

Returns an Observable that emits the results of a specified combiner function applied to combinations of two items emitted,in sequence, by two other Observables.

Zip示意图

简单来说zip操作符就是合并多个数据流，然后发送(Emit)最终合并的数据。

下面是代码示例：

private void rxStartRecord() {
    Observable.zip(Observable.create(new Observable.OnSubscribe<Boolean>() {
        @Override
        public void call(Subscriber<? super Boolean> subscriber) {
            subscriber.onNext(checkStorage());
            if (subscriber.isUnsubscribed()) {
                subscriber.onCompleted();
            }
        }
    }), Observable.create(new Observable.OnSubscribe<Boolean>() {
        @Override
        public void call(Subscriber<? super Boolean> subscriber) {
            subscriber.onNext(checkAccompanyAvailable());
            if (subscriber.isUnsubscribed()) {
                subscriber.onCompleted();
            }
        }
    }), Observable.create(new Observable.OnSubscribe<Boolean>() {
        @Override
        public void call(Subscriber<? super Boolean> subscriber) {
            subscriber.onNext(checkPermission());
            if (subscriber.isUnsubscribed()) {
                subscriber.onCompleted();
            }
        }
    }), new Func3<Boolean, Boolean, Boolean, Boolean[]>() {
        @Override
        public Boolean[] call(Boolean aBoolean, Boolean aBoolean2, Boolean aBoolean3, Boolean aBoolean4) {
            return new Boolean[]{aBoolean, aBoolean2, aBoolean3};
        }
    })
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(new KTVSubscriber<Boolean[]>() {
          @Override
          public void onNext(Boolean[] aBoolean) {
               super.onNext(aBoolean);
               //下面处理收到的结果
               if (!aBoolean[1]) {

               } else if (!aBoolean[2]) { 

               } else if (!aBoolean[3]) {

               } else {
                    
               }
          }
    });
}

这里只是简单示意，实际上我们在这个地方使用它子线程并行的特点注册的事件要更多。同时，不仅仅是录制，这个方法在很多场景都适用。

上面我们解决了由于接口block引起的耗时。除此之外由于native组件较多，同时又有很多子线程的异步操作，初始化时没有一个比较好的状态同步机制，导致player和consumer的线程等待的时间比较久。

录制模块流程图

改造的方案是直接启动player和consumer，刚开始上游没有产出数据，则两个线程处于挂起状态。当上游的Decoder和Recorder开始产出数据，则唤醒两个线程，开始播放伴奏，即开始录制，省去了等待的时间。

最后，我们来看一下优化后的效果，我这边只试了两款设备，还是挺明显的。