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。通过他们可以实现一些棘手的问题。