通常，我們編寫執行Android時，該程式若在一個程序中。若程式有缺陷，如空指標，將會產生空指標異常。 當異常發生時，其呼叫堆疊將會輸出到log中，通過檢視呼叫堆疊，很快可以找到問題的根源，從而解決問題。

但當我們使用Service，通過AIDL跨程序呼叫（或直接編寫Binder IPC的跨程序呼叫）時，需要使用Parcel跨程序傳遞資料。有時這種跨程序呼叫會產生異常，這時問題稍顯複雜一些。一個跨程序異常log示例如下：

07-17 16:28:53.969: V/DemoActivity3.MySessionListener(21000): onLeftSession.
07-17 16:28:54.019: D/dalvikvm(21000): GC_CONCURRENT freed 661K, 54% free 3108K/6727K, external 1657K/2137K, paused 3ms+2ms

通過檢視android.os.Parcel.readException原始碼實現，被呼叫側（Server側）的這些異常的編碼號code和異常描述資訊，在被Parcel讀取後，將在呼叫側丟擲對應型別的異常。

因此，這類因跨程序產生的異常，將被跨程序送到呼叫側（Client側）。也就是說，問題的根源來自Server側的程式碼，若被呼叫側遇到程式崩潰的異常，如NullointerExeption或SecurityException。
將在呼叫側產生一個異常，這個異常由Parcel讀取，在Client側被丟擲。

這種只輸出調用側的呼叫堆疊，如何去分析並解決它呢？由於沒有輸出被呼叫側的堆疊，所以問題根源不那麼明顯。

根據筆者經驗，若是自己直接編寫的Binder IPC子類（沒有使用AIDL的形式），則首先檢查呼叫側的IXXX.Stub.Proxy中的通過Parcel引數寫入是否正確，然後再檢查IXXX.Stub中的switch-case分支中Parcel讀取時,讀取的順序以及引數型別是否正確。

在確認無誤後，再仔細檢查被呼叫側IXXX.Stub的子類實現的各函式的程式碼，如空指標（值為null並在未賦值時使用其成員）；若是上述示例中的安全異常SecurityException，則需檢查未使用new分配記憶體即直接使用，或釋放後仍在使用，類似於C++中對無效記憶體的訪問。尤其是被呼叫的Server側有類的例項物件的變數，它們將是被重點懷疑的物件，通過這些例項物件變數使用成員變數值或成員函式的程式碼，最有可能是問題的根源，這時就要檢查類的例項是否初始化，是否分配了記憶體，其生命週期如何（何時被建立，何時被銷燬）。通過分析檢查程式碼，應該就可以很快找到問題的根源。

另外一種不是輕快好省的方式是，可以將這種跨程序程式碼移植到一個程序中，保證模擬出出問題時的場景，讓程式輸出崩潰時的呼叫堆疊。