没抢到小马哥的红包,无心回家了,回公司写篇文章安慰下自己TT。。话说年关难过,bug多多,时间久了难免头昏脑热,不辨朝暮,难识乾坤。。。艾玛,扯远了,话说谁没踩过坑,可视大家都是如何从坑里爬出来的呢?
话说,有那么一天,
PM:『我这里有个需求,很简单很简单那种』
RD:『哦,需要做三天』
PM:『真的很简单很简单那种』
RD:『哦,你又说了一遍很简单,那么现在需要做六天了』
对呀,静音功能多简单,点一下,欸,静音了;再点一下,欸,不静音了;再点一下,欸。。。
我一看API,是挺简单的:
private void setMuteEnabled(boolean enabled){ AudioManager mAudioManager = (AudioManager) getContext().getSystemService(Context.AUDIO_SERVICE); mAudioManager.setStreamMute(AudioManager.STREAM_MUSIC, enabled); }
是吧,多简单,三分钟搞定。不过说真的,这并不是什么好兆头,太简单了,简单到令人窒息啊!
话说,过了几天,
QA:『如果我先开启静音,然后退出我们的app再进来,尽管页面显示静音状态,但我无法取消静音啊』
RD:『一定是你的用法有问题!』
当然,我也挺心虚的啊,因为这段代码我总共花了三分钟,说有bug,我也不敢不信呐。我们再来细细把刚才的场景理一遍:
有个问题需要交代一下,Android api并没有提供获取当前音频通道是否静音的api(为什么没有?你。。你居然问我为什么?你为什么这么着急?往后看就知道啦),所以我在进入app加载view时,要根据本地存储的静音状态来初始化view的状态:
boolean persistedMute = mute.getContext().getSharedPreferences("volume", Context.MODE_PRIVATE).getBoolean("Volume.Mute", false); muteButton.setChecked(persistedMute);
而这个字段是在用户点击了muteButton之后被存入SharedPreference当中的。
不可能啊,到这里毫无悬念可言啊,肯定是没有问题的呀。
接着看,这时候我们要取消静音了,调用的代码就是下面这段代码:
private void setMuteEnabled(boolean enabled){ AudioManager mAudioManager = (AudioManager) getContext().getSystemService(Context.AUDIO_SERVICE); mAudioManager.setStreamMute(AudioManager.STREAM_MUSIC, enabled); }
然后,app一脸不屑的看都不看洒家一眼,依旧不吱声。
坑爹呢吧!!自行脑补我摔手机的场景
正是:自古bug多简单,惹得骚年尽难眠。:scream:
我这么无辜,寥寥几行代码,能犯什么错误呢?所以问题一定出在官方的API上。
/** * Mute or unmute an audio stream. * <p> * The mute command is protected against client process death: if a process * with an active mute request on a stream dies, this stream will be unmuted * automatically. * <p> * The mute requests for a given stream are cumulative: the AudioManager * can receive several mute requests from one or more clients and the stream * will be unmuted only when the same number of unmute requests are received. * <p> * For a better user experience, applications MUST unmute a muted stream * in onPause() and mute is again in onResume() if appropriate. * <p> * This method should only be used by applications that replace the platform-wide * management of audio settings or the main telephony application. * <p>This method has no effect if the device implements a fixed volume policy * as indicated by {@link #isVolumeFixed()}. * * @param streamType The stream to be muted/unmuted. * @param state The required mute state: true for mute ON, false for mute OFF * * @see #isVolumeFixed() */ public void setStreamMute(int streamType, boolean state) { IAudioService service = getService(); try { service.setStreamMute(streamType, state, mICallBack); } catch (RemoteException e) { Log.e(TAG, "Dead object in setStreamMute", e); } }
我们摘出最关键的一句,大家一起来乐呵乐呵。。。。
The mute requests for a given stream are cumulative: the AudioManager
can receive several mute requests from one or more clients and the stream
will be unmuted only when the same number of unmute requests are received.
就是说,我们可以发送任意次静音请求,而想要取消静音,还得发出同样次数的取消静音请求才可以真正取消静音。
好像找到答案了。不对呀,我以你的人格担保,我只发了一次静音请求啊,怎么取消静音就这么费劲呢!
突然,嗯,就是在这时,我想起前几天我那本被茶水泡了的《深入理解Android》卷③提到,其实每个app都可以发送静音请求,而且各自都是单独计数的。那么问题来了,每个app发静音请求的唯一身份标识是啥嘞?
还是要看设置静音的接口方法:
public void setStreamMute(int streamType, boolean state) { IAudioService service = getService(); try { service.setStreamMute(streamType, state, mICallBack); } catch (RemoteException e) { Log.e(TAG, "Dead object in setStreamMute", e); } }
这个service其实是AudioService的一个实例,当然,其实AudioManager本身所有操作都是转发给AudioService的。
/** @see AudioManager#setStreamMute(int, boolean) */ public void setStreamMute(int streamType, boolean state, IBinder cb) { if (mUseFixedVolume) { return; } if (isStreamAffectedByMute(streamType)) { if (mHdmiManager != null) { synchronized (mHdmiManager) { if (streamType == AudioSystem.STREAM_MUSIC && mHdmiTvClient != null) { synchronized (mHdmiTvClient) { if (mHdmiSystemAudioSupported) { mHdmiTvClient.setSystemAudioMute(state); } } } } } mStreamStates[streamType].mute(cb, state); } }
最后一行我们看到实际上设置静音需要传入cb也就是AudioManager传入的mICallBack,以及是静音还是取消静音的操作state,而这个mute方法本质上也是调用了VolumeDeathHandler的mute方法,我们直接看这个方法的源码:
public void mute(boolean state) { boolean updateVolume = false; if (state) { if (mMuteCount == 0) { // Register for client death notification try { // mICallback can be 0 if muted by AudioService if (mICallback != null) { mICallback.linkToDeath(this, 0); } VolumeStreamState.this.mDeathHandlers.add(this); // If the stream is not yet muted by any client, set level to 0 if (!VolumeStreamState.this.isMuted()) { updateVolume = true; } } catch (RemoteException e) { // Client has died! binderDied(); return; } } else { Log.w(TAG, "stream: "+mStreamType+" was already muted by this client"); } mMuteCount++; } else { if (mMuteCount == 0) { Log.e(TAG, "unexpected unmute for stream: "+mStreamType); } else { mMuteCount--; if (mMuteCount == 0) { // Unregister from client death notification VolumeStreamState.this.mDeathHandlers.remove(this); // mICallback can be 0 if muted by AudioService if (mICallback != null) { mICallback.unlinkToDeath(this, 0); } if (!VolumeStreamState.this.isMuted()) { updateVolume = true; } } } } if (updateVolume) { sendMsg(mAudioHandler, MSG_SET_ALL_VOLUMES, SENDMSG_QUEUE, 0, 0, VolumeStreamState.this, 0); } }
其实这个方法的逻辑比较简单,如果静音,那么mMuteCount++,否则—。这里面还有一个逻辑处理了发送了静音请求的app因为crash而无法发出取消静音的请求的情形,如果出现这样的情况,系统会直接清除这个app发出的所有静音请求来使系统音频正常工作。
那么,mMuteCount是VolumeDeathHandler的成员,而VolumeDeathHandler的唯一性主要体现在传入的IBinder实例cb上。
private class VolumeDeathHandler implements IBinder.DeathRecipient { private IBinder mICallback; // To be notified of client's death private int mMuteCount; // Number of active mutes for this client VolumeDeathHandler(IBinder cb) { mICallback = cb; } …… }
结论就是: AudioManager的mICallBack是静音计数当中发起请求一方的唯一身份标识。
对呀,有名片啊,问题是我这是同一个app啊,同一个啊……问题出在哪里了呢。
刚才我们知道了,其实静音请求计数是以AudioManager当中的一个叫mICallBack的家伙为唯一标识的,这个家伙是哪里来的呢?
private final IBinder mICallBack = new Binder();
我们发现,其实对于同一个AudioManager来说,这个mICallBack一定是同一个。反过来说,我们在操作静音和取消静音时没有效果,应该就是因为我们的mICallBack不一样,如果是这样的话,那么说明AudioManager也不一样。。。
操曰:『天下英雄,唯使君与操耳』
玄德大惊曰:『操耳是哪个嘛?』
正当我收起我惊呆了的下巴的时候,我回过神来,准备对AudioManager的身世一探究竟。且说,AudioManager是怎么来的?
AudioManager mAudioManager = (AudioManager) getContext().getSystemService(Context.AUDIO_SERVICE);
那么这个getSystemService又是什么来头??经过一番查证,我们发现,其实这个方法最终是在ContextImpl这个类当中得以实现:
@Override public Object getSystemService(String name) { ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name); return fetcher == null ? null : fetcher.getService(this); }
那么问题的关键就在与我们拿到的这个ServiceFetcher实例了。且看它的get方法实现:
public Object getService(ContextImpl ctx) { ArrayList<Object> cache = ctx.mServiceCache; Object service; synchronized (cache) { if (cache.size() == 0) { // Initialize the cache vector on first access. // At this point sNextPerContextServiceCacheIndex // is the number of potential services that are // cached per-Context. for (int i = 0; i < sNextPerContextServiceCacheIndex; i++) { cache.add(null); } } else { service = cache.get(mContextCacheIndex); if (service != null) { return service; } } service = createService(ctx); cache.set(mContextCacheIndex, service); return service; } }
如果有缓存的Service实例,就直接取出来返回;如果没有,调用createService返回一个。再看看下面的片段,这个问题就很清楚了:
registerService(AUDIO_SERVICE, new ServiceFetcher() { public Object createService(ContextImpl ctx) { return new AudioManager(ctx); }});
这一句就实际上往SYSTEM_SERVICE_MAP.get当中添加了一个与AudioService有关的ServiceFetcher实例,而这个实例里面居然直接new了一个AudioManager。
等会儿让我想会儿静静。它在这里new了一个AudioManager。它怎么能new了一个AudioManager呢。
再来看看我们用的Context会有什么问题。
AudioManager mAudioManager = (AudioManager) getContext().getSystemService(Context.AUDIO_SERVICE);
这段代码是在View当中的,换句话说,getContext返回的是初始化View时传入的Context。初始化这个View传入的Context是我们唯一的Activity。这时,我不说,大家也会猜到下面的内容了:
有了前面的分析,解决方法其实也就浮水而出了:
AudioManager mAudioManager = (AudioManager) getContext().getApplicationContext().getSystemService(Context.AUDIO_SERVICE);
我们只要使用Application全局Context去获取AudioManager不就没有那么多事儿了么?其实尽可能地引用Application而不是Activity,在很多场合甚至会避免内存泄露。有朋友问起什么时候应该用Application,什么时候应该用Activity,答案很明显,只要是Application可以做到的,就一律不要用Activity,除非引用方的生命周期跟Activity的生命周期一致。
再来回答, 为什么系统没有提供获取是否静音的Api这个问题 。如果系统确实提供了这个Api,它应该为你提供哪些信息呢?是告诉你系统当前是否静音吗?它告诉你这个有啥意义呢,反正那些别人操作的结果,如果已经静音,你也单方面做不到取消静音;是告诉你你这个应用是否已经发送过静音请求?请求数量你自己完全可以自己记录,为什么还要官方Api提供给你?所以,获取是否处于静音状态这个接口其实意义并不见得有多大。当然,实际上这个api是写在代码中的,只不过被@hide了,我们就当做没有看待好了。
静音的故事讲完了,这个小故事告诉我们一个道理: 代码从来都不会骗我们 。
侯捷先生在《STL源码剖析》一书的扉页上面写道『源码之前,了无秘密』。写程序的时候,我经常会因为运行结果与预期不一致而感到不悦,甚至抱怨这就是『命』,想想也是挺逗的。计算机总是会忠实地执行我们提供的程序,如果你发现它『不听』指挥,显然是你的指令有问题;除此之外,我们的指令还需要经过层层传递,才会成为计算机可以执行的机器码,如果你对系统api的工作原理不熟悉,对系统的工作原理不熟悉,你在组织自己的代码的时候就难免一厢情愿。
至于官方API文档,每次看到它都有看到『课本』一样的感觉。中学的时候,老师最爱说的一句话就是,『课本要多读,常读常新』。官方API呢,显然也是这样。没有头绪的时候,它就是我们救星啊。
作为Android开发者,尽管我不需要做Framework开发,但这并不能说明我不需要对Framework有一定的认识和了解。我们应该在平时的开发和学习当中经常翻阅这些系统的源码,了解它们的工作机制有助于我们更好的思考系统api的应用场景。
关于Android系统源码,如果不是为了深入的研究,我比较建议直接在网上直接浏览:
想了解更多干货,请搜索关注公众号: 腾讯Bulgy ,或搜索微信号:weixinBugly,关注我们
Bugly 是腾讯内部产品质量监控平台的外发版本,支持iOS和Android两大主流平台,其主要功能是App发布以后,对用户侧发生的crash以及卡顿现象进行监控并上报,让开发同学可以第一时间了解到app的质量情况,及时修改。目前腾讯内部所有的产品,均在使用其进行线上产品的崩溃监控。
腾讯Bugly 经过内部团队4年打磨,目前腾讯内部所有的产品都在使用,基本覆盖了中国市场的移动设备以及网络环境,可靠性有保证。使用 Bugly ,你就使用了和手机QQ、QQ空间、手机管家相同的质量保障手段。