Soul Android app 悬浮view以及帖子中view的联动刷新逆向分析
soul app是我司的竞品,对它的语音音乐播放同步联动的逻辑很感兴趣,于是就开启了一波逆向分析。
下面看代码,以及技术分析,直接步入正轨,哈哈。
我们根据https://github.com/xingstarx/activitytracker 这个工具,找到某一个页面,比如cn.soulapp.android/.ui.post.detail.postdetailactivity 这个页面,然后我们用反编译工具androidtoolplus反编译soul 的android apk, 然后搜索下postdetailactivity这个类。然后找到这个类之后,我们在根据代码经验猜测,这个语音音乐封装的控件可能在哪,肯定是在postdetailactivity里面或者是他内容的某个成员变量里面,一不小心,我们就找到了postdetailheaderprovider。在这个类里面找到了musicstoryplayview, audiopostview这两个view类,他们就是封装好的音频view,音乐view。(就不截图了。有人感兴趣可以按照我说的实践一番就能得到结论了)
关键代码找到了。那就看看他们内部实现吧。
public class musicstoryplayview extends framelayout implements soulmusicplayer.musicplaylistener
类结构上,实现了核心播放器的listener逻辑,那就说明,他的刷新逻辑,都是通过播放器自身的播放状态回调到view自身上,然后view自身实现了对应的刷新机制就可以更改view的状态了
我们选取几个回调的逻辑看看。不做仔细分析。
public void onpause(cn.soulapp.android.lib.common.c.i parami) { d(); } public void onplay(cn.soulapp.android.lib.common.c.i parami) { lovebellingmanager.e().d(); } public void onprepare(cn.soulapp.android.lib.common.c.i parami) { if (this.e == null) { return; } if (parami.b().equals(this.e.songmid)) { e(); } }
那么我们还得思考一个问题,这个listener是什么时候被添加进来的呢。关键点在于view自身的两个方法
protected void onattachedtowindow() { super.onattachedtowindow(); soulmusicplayer.k().a(this); } protected void ondetachedfromwindow() { super.ondetachedfromwindow(); soulmusicplayer.k().b(this); }
所以很明显,在view被添加到window上(也就是在页面上显示出来)的时候,添加入listener里面,从页面消失,就移除出去。
接着我们在看看核心播放器的逻辑里面,是怎么调度的?
根据代码相关联的逻辑,我们很容易找到核心播放器类soulmusicplayer
public void a(cn.soulapp.android.lib.common.c.i parami) { y0.d().a(); lovebellingmanager.e().d(); musicplayer.i().f(); if (textutils.isempty(parami.f())) { return; } object localobject1 = this.d; if (localobject1 != null) { if (!((cn.soulapp.android.lib.common.c.i)localobject1).equals(parami)) { i(); } else { if (!f()) { this.a.setlooping(parami.g()); h(); } return; } } if (this.a == null) { this.a = new ijkmediaplayer(); this.a.setonerrorlistener(this); this.a.setoncompletionlistener(this); this.a.setonpreparedlistener(this); } this.a.setlooping(parami.g()); try { if (l0.e(parami.f())) { soulapp localsoulapp; object localobject2; if (parami.a() != null) { localobject1 = this.a; localsoulapp = soulapp.e(); localobject2 = new java/io/file; ((file)localobject2).<init>(parami.f()); ((ijkmediaplayer)localobject1).setdatasource(localsoulapp, uri.fromfile((file)localobject2), parami.a()); } else { localobject2 = this.a; localsoulapp = soulapp.e(); localobject1 = new java/io/file; ((file)localobject1).<init>(parami.f()); ((ijkmediaplayer)localobject2).setdatasource(localsoulapp, uri.fromfile((file)localobject1)); } } else { localobject1 = parami.a(); if (localobject1 != null) { this.a.setdatasource(soulapp.e(), uri.parse(parami.f().replace("https", "http")), parami.a()); } else { this.a.setdatasource(soulapp.e(), uri.parse(parami.f().replace("https", "http"))); } } this.a.prepareasync(); this.d = parami; this.b = true; } catch (ioexception parami) { parami.printstacktrace(); } }
public void g() { if (f()) { object localobject = this.a; if (localobject != null) { this.b = false; ((ijkmediaplayer)localobject).pause(); localobject = this.e.iterator(); while (((iterator)localobject).hasnext()) { ((musicplaylistener)((iterator)localobject).next()).onpause(this.d); } this.c.removecallbacksandmessages(null); } } }
仔细观察分析这两个方法体,大致可以猜测出,他们是start逻辑,以及暂停播放的逻辑。可以分析出,核心播放器执行完播放,暂停,停止等逻辑后,都会调用list里面的listener,遍历listener,然后触发对应的回调逻辑。
恩,大体的思路有了,就是这么搞,哈哈。
那么我用于我自己项目中,是这么用的么,还是有一些细微差异的,整体方案是参考的soul。细微不同之处在于我是将musicstoryplayview放在xml里面,不是像soul那样,直接new的。所以musicstoryplayview会被添加很多次,比如在列表中有很多个的话,后面需要判断播放的媒体资源,跟musicstoryplayview存放的媒体资源的主键是否一致。
此外出了view类,我对于一些特殊的逻辑,比如activity或者是悬浮view等等,都实现了playlistener。通过他们可以实现一些棘手的问题。
好了,本篇到此结束,如果大家有疑问,欢迎留言交流。