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。通過他們可以實作一些棘手的問題。
原文位址
https://www.cnblogs.com/xing-star/p/12768379.html