一場由Parcelable引發的血案

問題背景

前陣子接手了直播模塊，有個需求需要在已有的AIDL介面中增加多一個int類型的參數B。由於該AIDL介面中已經有了一個自定義類型的參數A(已經實現Parcelable介面)，我便將參數B追加到A的後面。嗯，炒雞簡單的，只是運行之後有問題而已(微笑臉)

有一個詭異的問題：無論B傳入什麼值，另一方接收到都始終為0(int的默認值)，而A接收到的值卻是正確的？！

Take it easy! 作為共產主義的接班人，我當然是有辦法的啦：

懷疑是Freeline不支持AIDL，改用AS重新build，問題依舊

懷疑是辣雞AS的問題，重新啟動再build，問題依舊

懷疑是工具鏈的版本問題，改為最新版本再次編譯，問題依舊

懷疑是int的問題？將B改為float, boolean等其他的基本類型，問題依舊，取到的始終是默認值

抱著希望在StackOverflow和Google上逛了一圈，無果

求助群里的小夥伴，答曰沒有遇到過此情況，並向我丟了一連竄的「233333」和一波表情

辭職

就在我一籌莫展的時候，突然腦子一抽，試著把介面定義中A參數和B參數位置調換。震驚地發現，居然可以了！！

嗯，此篇文章完結，撒花~

解決方案

將基本類型的參數放在自定義類型的參數前面，雖然解決了問題，但是治標不治本，只能算個workaround。

不知道大家有沒有發現：參數的定義順序會影響結果這一行為，是不是跟實現Parcelable介面的時候有點類似？Parcelable中如果read的順序和write的順序不同的話，產生的結果也不同。

基於這點，我們懷疑問題出在自定義類型的參數A，先來看下相關代碼：

//ILivePlayerService.aidl interface ILivePlayerService {

//參數A：config, 參數B：type

void setPlayerConfig(in PlayerConfig config, int type) }//PlayerConfig.java public class PlayerConfig implements Parcelable { //省略其他代碼.... String streamUrl; int roomId; int anchorId; public PlayerConfig() { } protected PlayerConfig(Parcel in) { //省略其他代碼.... this.streamUrl = in.readString(); this.roomId = in.readInt(); this.anchorId = in.readInt(); } @Override public void writeToParcel(Parcel dest, int flags) { //省略其他代碼.... dest.writeString(this.streamUrl); dest.writeInt(this.roomId); //下面注釋的這句，代碼中是沒有的。問題就出現在這裡.. //dest.writeInt(this.anchorId); } @Override public int describeContents() { return 0; } public static final Creator CREATOR = new Creator() { @Override public PlayerConfig createFromParcel(Parcel source) { return new PlayerConfig(source); } @Override public PlayerConfig[] newArray(int size) { return new PlayerConfig[size]; } }; }

果然， 沒有正確地實現 Parcelable 介面，在寫入的時候（詳見上面代碼中 方法中的注釋）漏掉了變數 ，而讀取的時候卻有。

論接手別人的代碼是一種怎樣的體驗？

我們先把 中漏掉的變數補上，再跑一下看問題是否解決了。

不出所料，那個詭異的問題沒有了，可是為什麼呢？我們來看下AIDL生成的Java代碼：

//AIDL生成的 ILivePlayerService.java //為了方便查看，格式了一下代碼 @Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException { switch (code) { case INTERFACE_TRANSACTION: { reply.writeString(DESCRIPTOR); return true; } //setPlayerConfig方法 case TRANSACTION_setPlayerConfig: { data.enforceInterface(DESCRIPTOR); //參數A：config com.kk.model.PlayerConfig _arg0; if ((0 != data.readInt())) {

//在解析的時候，會調用PlayerConfig的createFromParcel方法 _arg0 = com.kk.model.PlayerConfig.CREATOR.createFromParcel(data); } else { _arg0 = null; } //參數B：type int _arg1; _arg1 = data.readInt(); this.setPlayerConfig(_arg0, _arg1); reply.writeNoException(); return true; } } return super.onTransact(code, data, reply, flags); }

我們可以看到在解析數據的時候，參數A和參數B都是從data中解析的(共用一個Parcel源)其中，解析參數A 的時候會將 傳入到自己實現的 方法中進行處理，如下

//PlayerConfig.java 部分代碼 public static final Creator CREATOR = new Creator() { @Override public PlayerConfig createFromParcel(Parcel source) {

//接受到aidl傳入的data

return new PlayerConfig(source); } }; protected PlayerConfig(Parcel in) { //aidl傳入的data在這裡解析

this.streamUrl = in.readString();

this.roomId = in.readInt();

this.anchorId = in.readInt(); } @Override public void writeToParcel(Parcel dest, int flags) {

//省略其他代碼....

dest.writeString(this.streamUrl);

dest.writeInt(this.roomId);

//下面注釋的這句，代碼中是沒有的。問題就出現在這裡..

//dest.writeInt(this.anchorId); }

由於 沒有正確地實現 ，只寫入了1個int類型，但是卻讀取了2個，這就導致了參數A多讀取了一個int… 等到參數B想從 中讀取的時候，就會讀取不到數值(返回默認值)…

這個涉及到了Parcel的內部機制，可以參考這篇文

小結

這次的坑是因為沒有正確實現Parcelable介面導致的。這很不應該，其實我們可以讓工具來做這種體力活，比如AS中有個插件叫做「Android Parcelable code generator」就可以一鍵生成Parcelable代碼，或者去Github搜搜Parcelable相關的註解庫也行~

程序猿要對自己好點，能用工具完成的事情盡量不要自己寫~

踩坑結束！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！