Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> Android開發 >> 關於android開發 >> Android java層音頻相關的分析與理解(三)調用相關

Android java層音頻相關的分析與理解(三)調用相關

編輯:關於android開發

Android java層音頻相關的分析與理解(三)調用相關


Android中會有多個應用需要支持音頻的播放。當同一時間內有多個應用需要輸出音頻的時候,到底是全部輸出?還是輸出其中一個?假如輸出其中一個,那到底輸出哪個?以什麼標准去界定?為了處理這些關系。Android在2.3的時候引入了AudioFocus機制並沿用到現在。

 

1 AudioFocus簡介

 

AudioFocus是一個沒有優先級概念的搶占式的機制。一般情況下,最後申請使用AudioFoucs的應用或取得當前的AudioFocus從而將前面申請的應用給停掉。但是,有一種情況是特殊的,就是通話。通話作為手機的重要功能,從響鈴到通話接受,Telephony都會申請AudioFocus,所有應用都不能從Telephony中獲取音頻焦點,但Telephony可以從任何應用中獲取到AudioFocus。

 

當前Android6.0下AudioFocus有幾種狀態,分別為:

\


從上面AudioFocus的狀態可以看出,其實AudioFocus的狀態是對應的。當後一個應用去GainAudioFocus時,前一個應用就相對應地LossAudioFocus。後一個應用以什麼形式去Gain,前一個應該就會受到相應Loss的通知。但是,當前一個應用收到這個Loss通知時,應用怎麼處理是應用內部的事情。因為AudioFoucs機制是一個建議性而不是強制性的機制。應用使用這種機制只是使用戶體驗更加好,而不采用這套機制,甚至不遵循這套機制,對應用與系統本身來是,是沒有什麼影響的。

再補充說明一下,當應用通過AudioFocus機制去輸出音頻的時候,它可以因為其他應用通過獲取AudioFocus去暫停輸出。但是,應用也可以不通過AudioFocus去輸出音頻。此時該應用的一切音頻輸出邏輯由本身控制。不受AudioFocus機制影響。

2 AudioFocus的實現

 

AudioFocus機制其實相當於一個棧。

\

 


如上圖所示,AudioFocus機制是以棧的形式實現,位於棧頂的應用能獲取到AudioFocus從而能輸出音頻。非棧頂應用會暫時失去AudioFocus直至位於其上面的全部應用關閉或主動丟失AudioFocus。

AudioFocus的實現是從AudioManager.java開始的。

一般來說,應用內部會通過調用AudioManager的requestAudioFocus()方法去獲取AudioFocus。AudioManager這一次,與以往不同,不只是作為一個類似於傳遞者的角色直接獲取AudioService的句柄然後將參數傳遞過去,而是先通過一系列的判斷和封裝,通過2次重載,將應用的相關消息保存並調用AudioSercvice中的requestAudioFocus(),進一步處理獲取AudioFocus操作。


 

所以我們來看一下AudioManager的requestAudioFocus()的主要內容:

public int requestAudioFocus (OnAudioFocusChangeListener l,
            @NonNull AudioAttributes requestAttributes,
            int durationHint,
            int flags,
            AudioPolicy ap) throws IllegalArgumentException {
        ……//一系列的參數判斷
        int status = AUDIOFOCUS_REQUEST_FAILED;
        //將申請AudioFocus的應用的listener放進mAudioFocusIdListenerMap中
registerAudioFocusListener(l);
        IAudioService service = getService();
        try {
            //調用AudioService的requestAudioFocus()
            status = service.requestAudioFocus(requestAttributes, durationHint, mICallBack,
                    mAudioFocusDispatcher, getIdForAudioFocusListener(l),
                    getContext().getOpPackageName() /* package name */, flags,
                    ap != null ? ap.cb() : null);
        } catch (RemoteException e) {
            Log.e(TAG, "Can't call requestAudioFocus() on AudioService:", e);
        }
        return status;
    }

在requestAudioFocus()中,與以往的稍有不同的是,requestAudioFocus()先一步對傳入的參數進行處理,並將申請應用的listener放進了mAudioFocusIdListenerMap中保存。而傳入的參數中,多了mAudioFocusDispatcher和getIdForAudioFocusListener(l)。getIdForAudioFocusListener(l)很明顯,就是將這個listener的名字傳進去。那mAudioFocusDispatcher到底是干什麼的呢?

 

接下來,我們先來關注一下mAudioFocusDispatcher:

 

    private final IAudioFocusDispatcher mAudioFocusDispatcher = new IAudioFocusDispatcher.Stub() {

        public void dispatchAudioFocusChange(int focusChange, String id) {
            Message m = mAudioFocusEventHandlerDelegate.getHandler().obtainMessage(focusChange, id);
            mAudioFocusEventHandlerDelegate.getHandler().sendMessage(m);
        }
    };

 

從上面我們可以看出,mAudioFocusDispatcher是IaudioFocusDispatcher的一個實現。他裡面有一個方法,負責調用mAudioFocusEventHandlerDelegate去處理消息的內容。那mAudioFocusEventHandlerDelegate又是干什麼呢?我們繼續往下看。

    private class FocusEventHandlerDelegate {
        private final Handler mHandler;
        FocusEventHandlerDelegate() {
            Looper looper;
            if ((looper = Looper.myLooper()) == null) {
                looper = Looper.getMainLooper();
            }
            if (looper != null) {
                // implement the event handler delegate to receive audio focus events
                mHandler = new Handler(looper) {
                    @Override
                    public void handleMessage(Message msg) {
                        OnAudioFocusChangeListener listener = null;
                        synchronized(mFocusListenerLock) {
                            listener = findFocusListener((String)msg.obj);
                        }
                        if (listener != null) {
                            Log.d(TAG, "AudioManager dispatching onAudioFocusChange("
                                    + msg.what + ") for " + msg.obj);
                            listener.onAudioFocusChange(msg.what);
                        }
                    }
                };
            } else {
                mHandler = null;
            }
        }
        Handler getHandler() {
            return mHandler;
        }
    }

從上面我們可以看出,調用mAudioFocusEventHandlerDelegate就是為了回調傳入的listener的onAudioFocusChange方法去處理相關的內容。那明明可以直接通過l.onAudioFocusChange(focusChange)去處理這些信息,為什麼要多此一舉專門用一個handle去處理了?於是我去查了一下啊,原因如下:因為這個回調尚在Binder的調用線程中,如果在這裡因為用戶傳入的listener的代碼有問題而爆出異常或阻塞甚至惡意拖延,則會導致Binder的另一端因異常而崩潰或阻塞。所以到此為止,AudioService已經盡到了通知的義務,應該通過Handler將後續的操作發往另外一個線程,使AudioService盡可能遠離回調現實的影響。

 

所以,現在我們可以進入AudioService去看一下到底AudioService是怎樣處理的。

AudioService. requestAudioFocus()如下:

public int requestAudioFocus(AudioAttributes aa, int durationHint, IBinder cb,
            IAudioFocusDispatcher fd, String clientId, String callingPackageName, int flags,
            IAudioPolicyCallback pcb) {
        // 檢測權限
        if ((flags & AudioManager.AUDIOFOCUS_FLAG_LOCK) == AudioManager.AUDIOFOCUS_FLAG_LOCK) {     //奇怪的地方1
            if (AudioSystem.IN_VOICE_COMM_FOCUS_ID.equals(clientId)) {
                if (PackageManager.PERMISSION_GRANTED != mContext.checkCallingOrSelfPermission(
                            android.Manifest.permission.MODIFY_PHONE_STATE)) {
                    Log.e(TAG, "Invalid permission to (un)lock audio focus", new Exception());
                    return AudioManager.AUDIOFOCUS_REQUEST_FAILED;
                }
            } else {
                //注冊一個AudioPolicy去獲取AudioFocus
                synchronized (mAudioPolicies) {    //奇怪的地方2
                    if (!mAudioPolicies.containsKey(pcb.asBinder())) {
                        Log.e(TAG, "Invalid unregistered AudioPolicy to (un)lock audio focus");
                        return AudioManager.AUDIOFOCUS_REQUEST_FAILED;
                    }
                }
            }
        }

        return mMediaFocusControl.requestAudioFocus(aa, durationHint, cb, fd,
                clientId, callingPackageName, flags);
    }

在上面假如仔細看的話,有2個地方會覺得很奇怪。第一個,AudioManager.AUDIOFOCUS_FLAG_LOCK ,第二個mAudioPolicies。AudioManager.AUDIOFOCUS_FLAG_LOCK代表著AudioFocus被鎖定的狀態。處於這種狀態下假如應用需要獲取AudioFoucs,首先得去registerAudioPolicy。這就和AudioPolicy相關。

 

在這裡AudioPolicy與AudioPolicyService一點關系的沒有。前者在java層,只是負責提供簡單的音頻路由和音頻焦點的管理;後者處於C++層負責處理音頻相關的路由策略。在這裡,由於我們一般不會用到AudioPoluicy和AudioManager.AUDIOFOCUS_FLAG_LOCK,所以這個會在4.3稍作解析就過了。

 

回到AudioService. requestAudioFocus(),我們其實可以發現,真正處理AudioFocus的,是MediaFocusControl……


所以現在就來看一下MediaFocusControl是怎麼處理的。

 

   protected int requestAudioFocus(AudioAttributes aa, int focusChangeHint, IBinder cb,
            IAudioFocusDispatcher fd, String clientId, String callingPackageName, int flags) {
         ……
        //跳過各種判斷
        synchronized(mAudioFocusLock) {
          ……
            //通過AudioFocusDeathHandler對申請AudioFocus的應用進行監聽
            AudioFocusDeathHandler afdh = new AudioFocusDeathHandler(cb);
            try {
                cb.linkToDeath(afdh, 0);
            } catch (RemoteException e) {
                ……
                return AudioManager.AUDIOFOCUS_REQUEST_FAILED;
            }
            
// mFocusStack就是AudioFocus機制所在的棧
// 如果申請AudioFocus的應用已經獲取的AudioFocus,不作任何處理
            if (!mFocusStack.empty() && mFocusStack.peek().hasSameClient(clientId)) {
                ……
            }

            // 如果已經在Stack中已經存在去這個應用的請求,就先remove掉它
            removeFocusStackEntry(clientId, false /* signal */, false /*notifyFocusFollowers*/);
            
            //新建一個FocusRequester對象
            final FocusRequester nfr = new FocusRequester(aa, focusChangeHint, flags, fd, cb,
                    clientId, afdh, callingPackageName, Binder.getCallingUid(), this);
            if (focusGrantDelayed) {
                //處於可延遲獲取AudioFocus狀態(正在通話)下,先把它放進Stack中
                final int requestResult = pushBelowLockedFocusOwners(nfr);
                if (requestResult != AudioManager.AUDIOFOCUS_REQUEST_FAILED) {
                    notifyExtPolicyFocusGrant_syncAf(nfr.toAudioFocusInfo(), requestResult);
                }
                return requestResult;
            } else {
                
                if (!mFocusStack.empty()) {
                    //使上一個占有AudioFocus的應用失去AudioFocus
                    propagateFocusLossFromGain_syncAf(focusChangeHint);
                }

                //將當前的request放在棧頂
                mFocusStack.push(nfr);
            }
            //通知系統該應用獲取AudioFocus
            notifyExtPolicyFocusGrant_syncAf(nfr.toAudioFocusInfo(),
                    AudioManager.AUDIOFOCUS_REQUEST_GRANTED);

        }//synchronized(mAudioFocusLock)

        return AudioManager.AUDIOFOCUS_REQUEST_GRANTED;
    }

 

在這裡我們可以看到真正的requestAudioFocus()處理。其實主要的流程就是:

1) 判斷是否需要延遲獲取AudioFocus(通話狀態),判斷應用是否已經擁有AudioFocus等等。

2) 讓上一個占有AudioFocus的應用失去AudioFocus,並通過一系列的操作回調它的onAudioFocusChange方法。(流程較簡單,不詳細敘述了)

3) 將當前應用FocusRequester放到棧頂,並通知系統當前應用獲取AudioFocus

 

失去AudioFocus的操作(abandonAudioFocus)和requestAudioFocus是大同小異的。所以在這裡也不詳細說明了。

 

3 AudioPolicy的使用
\

最後在這裡簡單說一下java層的AudioPolicy的理解。AudioService會有一個HashMap的對象mAudioPolicies,裡面保存著所有registerAudioPolicy()過的應用的信息。通過registerAudioPolicy()我們可以對AudioFocus進行鎖定並不允許不注冊AudioPolicy的應用修改。但是這個功能其實我們大部分時候都不會用到。

音頻調用相關就簡單分析到這。再重申一下,AudioFocus是一個建議非強制機制,我們不適用AudioFocus都不會影響應用的音頻輸出與輸入。
 

 


 

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved