本文主要讲解了一下几个方面：
（1）bitmap.copy()发生np的原因及Config 为何为null；
（2）不同系统setMetadata的实现机制及其差异性对比;
（3）不同版本support 库MediaSessioCompat::setMetadata实现差异。
一、深坑背景
既然是深坑，必然是难以发现（偶现问题），大家可能在想MediaSessionCompat::setMetadata()一个方法调用还未出现什么问题，正因我也是这么想，所以问题发生了 。
问题现场 ：在RDM问题列表中发现了一个np问题 （只有几例，上报机型均为小米系统，api19），来自bitmap.copy() ，对应到项目调用处 mMediaSessionCompat.setMetadata() 如下图所示 ，这里是专门针对小米系统锁屏进行的相关处理。
图1 问题现场
图2 bitmap.copy np 处
一看便知 ，传入的congfig为null导致 ，为什么config为null，我们后面再讲，先来看看为什么setMetadata会导致bitmap.copy ，带着疑问去看看setMetadata的调用过程。
二、MediaSessioCompat::setMetadata 调用过程
在讲解MediaSessioCompat::setMetadata前，先了解一下RemoteControlClient、MediaSession等多媒体控制相关类。
RemoteControlClient 主要用于锁屏状态控制音乐播放，锁屏界面由系统提供，在Android 4.0 (API 14)提供，目前已经被标记为deprecated（目前已推荐使用MediaSession）。 MediaSession 是一个专门解决媒体播放时界面和服务通讯问题的框架，在Android 5.0才被引进，可应用在锁屏、耳机线控、蓝牙耳机。
而这里的MediaSessioCompat 是support包提供的一个兼容性类 ，从命名就可以看出来，setMetadata方法作用主要是更新数据（包括歌曲名、歌手、背景图、字幕等信息），因此对于音频类系统锁屏是相当重要的。
MediaSessioCompat::setMetadata()内部实践上调用的是 MediaSessionImpl::setMetadata，既然是兼容类 ，对应的MediaSessionImpl 肯定在不同版本有着不同实现 （api 21 作为区分节点），如下：
图3 MediaSessionImpl实现
（1）MediaSessionImplBase::setMetadata (api <21)
在MediaSessionImplBase内部 主要进行了两大操作，先对metadata数据中的 bitmaps数据进行拷贝 （发现bitmap相关操作了），然后又对api 19 和 api 14 分别进行了区分（后面解释为什么会进行区分），调用各自的setMetadata。
图 4 MediaSessionImplBase::setMetadata (api <21)
没错，bitmap.copy()的np问题正是发生在这里，通过Bitmap相关api注释知，bitmap.getConfig()可能返回为null，奈何这竟然是一个系统bug，迭代了这么多版本google竟未修复。
图5 cloneMetadataIfNeeded()
这里的Config其实指的是 bitmap的类型 ：可以看到确实有两类返回的config为null
图6 Config
具体什么情况为null了 ，我在Bitmapcreate Bitmap(Bitmap source, int x, int y, int width, int height, Matrix m, boolean filter) 实现中找到了蛛丝马迹，如下图中注释：gif 文件会产出 null configs，但是对于我们项目来说，专辑封面采用的都不是gif格式，因此对于bitmap.getConfig()返回为null还是为弄清（那位大神知道请告诉一下，谢谢）。
图7 BitmapcreateBitmap 内部实现
虽然这个np问题可以轻而易举的解决，单本人不甘停留如此，还有有个疑问为什么要clone bitmap相关数据（注释已经说了，防止recycle），那在什么时候会recycle 。
（2）在那里进行recycle操作
在（1）中已经说过，MediaSessionImplBase里面会进行两部分操作，第二部分操作是setMetadata，其内部实现如下：
创建editor 、put 数据、最后apply。 这里分别使用了RemoteControlClient.MetadataEditor和MediaMetadataEditor （api 19 才提供）。
图8 MediaSessionCompatApi19
apply()才是关键 ，内部实现如下：其中mOriginalArtWork就是专门用来缓存封面的bitmap ，可能考虑到锁屏比较频繁，防止频繁调用吧，但是bitmap.recycle() 不是在2.3.3以后就不推荐使用吗，真不知道为何在此还要如此实现。
图9 RemoteControlClient::apply()
细心一点的同学可能发现，在这个里面竟然调用了MediaSession::setMetadata()根据，前面对MediaSession(5.0 引进)介绍知，在5.0以下实现方式肯定不一致：
图 10 4.4.4 版本的apply()方法
另外 ，在高版本中又是如何处理相关问题的了，带着这些疑问我们直接分析MediaSession::setMetadata()方法即可。
三、MediaSession::setMetadata()
在第二部分，主要讲解了MediaSessioCompat::setMetadata api 21以下的调用，在api >=21时，其内部调用的是 MediaSession::setMetadata()，具体如下：
图11 MediaSession::setMetadata()
这里也是分为两步 ：更新metadata 数据，执行更新 。
相比api <21 情况，这里并未clone 封面背景bitmap ，保证了一定性能。内部使用的是scaleBitmap 最后实际调用Bitmapcreate Bitmap(Bitmap source, int x, int y, int width, int height, Matrix m, boolean filter) ，整个过程简单明了。
而对于执行更新，这里采用的IPC 方式，上面的mBinder 其实是 ISession.aidl 对象，效率相比之前的提高不少。（这里具体就不展开。）
四、不同版本support 库MediaSessioCompat::setMetadata实现差异
前面讲的MediaSessioCompat 是基于support-v4-23.4.0 版本，可以看到MediaSessioCompat为了配合RemoteContorlClient::apply() 方法中的 bitmap.recyle() , 在setMetadta内部对进行了Clone。
图12 support-v4-23.4.0 MediaSessioCompat::setMetadata()
而在support-v4-22.2.1 中发现，并未对封面bitmap 进行可能，这种情况下，发生crash是必然的，可能正因如此，google在后面的support 库修复了这个问题。support-v4-23.4.0版本发生np ，原因前面已经说了，是因为bitmap.getConfig()为null导致 （这种情况极其少，因而极难发现）。
图13 support-v4-22.2.1 MediaSessioCompat::setMetadata()
感慨：本文主要记录了一次系统填坑经历 ；反思，在使用系统API时一定要全面弄清，尽量避免进坑。
网友评论