录制启动优化录制启动优化

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

首先是统计。好吧，必须的
检查sdcard剩余存储空间。视频需要预留的多一些，音频要求比视频低一些，但也需要一个门槛。低于我们要求的话提示用户清理内存，禁止录制
对伴奏格式进行检测。录制阶段的播放器仅支持指定格式的音频文件，其他格式会提示伴奏文件错误，禁止录制
权限检查及申请。麦克风权限、摄像头权限
如果当前设备有提供硬件耳返SDK的话，我们在这里使用集成进来的SDK打开手机的硬件耳返提升录制体验
实例并初始化Recorder、Player、Decoder、Camera、Score、VoiceAnalysis、Producer等组件，这里大部分为native操作
启动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() { @Override public void call(Subscriber subscriber) { subscriber.onNext(checkStorage()); if (subscriber.isUnsubscribed()) { subscriber.onCompleted(); } } }), Observable.create(new Observable.OnSubscribe() { @Override public void call(Subscriber subscriber) { subscriber.onNext(checkAccompanyAvailable()); if (subscriber.isUnsubscribed()) { subscriber.onCompleted(); } } }), Observable.create(new Observable.OnSubscribe() { @Override public void call(Subscriber subscriber) { subscriber.onNext(checkPermission()); if (subscriber.isUnsubscribed()) { subscriber.onCompleted(); } } }), new Func3() { @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() { @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开始产出数据，则唤醒两个线程，开始播放伴奏，即开始录制，省去了等待的时间。
最后，我们来看一下优化后的效果，我这边只试了两款设备，还是挺明显的。