唱歌作为主产品的核心功能，用户体验是非常重要的。随着版本的不断迭代，在开始录制时要做的准备工作变得越来越多，越来越繁重。导致在点击开始录制后，到真正开始录制，也就是开始播放伴奏，用户等待时间比较久。今天我们就来梳理一下， 唱吧在开始录制时做了哪些事情，以及如何为产品提速。
首先，我们来梳理一下启动时都做了什么：
首先是统计。好吧，必须的
检查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操作符就是合并多个数据流，然后发送(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开始产出数据，则唤醒两个线程，开始播放伴奏，即开始录制，省去了等待的时间。
最后，我们来看一下优化后的效果，我这边只试了两款设备，还是挺明显的。
| 设备 | 优化前（ms） | 优化后（ms） |
|---|---|---|
| 坚果pro 2s | 1324 | 420 |
| 美图 | 1845 | 865 |
