這個方法是用來將服務端的binder物件轉換成客戶端所需的aidl介面型別物件，這種轉換時區分程序的，那麼如何區分呢？咱們先做乙個實驗，建立乙個service，在乙個activity中繫結它，然後再將service設定為與activity同一程序和不再同一程序兩種情況，並列印出serviceconnection中繫結成功返回的ibinder，結果如下：
同一程序時
非同一程序時
從log日誌可以看出，當同一程序時，返回ibinder是bookservices$1，我們知道$表示的是bookservices中的內部類，而在bookservices的定義中，我們只在mbinder的初始化中定義了乙個ibookmanager.stub()的子類，即同程序時，在onserviceconnected接收到的是ibookmanager.stub()型別。
先看下asinte***ce的**：
public static com
.example
.administrator
.ipctest
.ibookmanager asinte***ce(android.os
.ibinder obj)
android.os
.iinte***ce iin = obj.querylocalinte***ce(descriptor);
if (((iin!=null)&&(iin instanceof com
.example
.administrator
.ipctest
.ibookmanager)))
return new com
.example
.administrator
.ipctest
.ibookmanager
.stub
.proxy(obj);
}
obj.querylocalinte***ce(descriptor)決定，那麼再看querylocalinte***ce的原始碼：
public @nullable iinte***ce querylocalinte***ce(@nonnull string descriptor)
return
null;
}
public
void
attachinte***ce(@nullable iinte***ce owner, @nullable string descriptor)
attachinte***ce中定義的，不過是不是很眼熟？因為attachinte***ce函式是在stub的建構函式中被呼叫的this.attachinte***ce(this, descriptor);，所以在querylocalinte***ce中的比較結果肯定為true，那麼返回的mowner也就是stub本身了。
當然這是在同一程序的情況下，那麼當服務端和客戶端不在同一程序時呢？
由上面的log可知，跨程序呼叫時，onsericeconnected中接收到的service為android.os.binderproxy型別，從上面的源**可以看出，當querylocalinte***ce返回為空時，asinte***ce返回的就是android.os.binderproxy型別。
那麼還有乙個問題：為什麼同一程序下回返回stub，而不同程序下回返回binderproxy呢？
關於new的一點筆記
必須delete用new建立物件的那個位址。而樓主pa getpointa 這樣其實已經改變了原來的那個new出來的位址，這時候delete就可能有問題了 如果getpointa返回的也是同一種型別的指標，且該指標也是被new出來的話，那麼delete pa這句話本身也不會出錯。否則，就錯了 另外，...
關於git的一點筆記
很早的時候註冊了github，然後搞了一些自己寫的 上去，逐漸學會了使用git，但是目前也僅僅是乙個很淺的初級，覺得有必要記錄一下呵呵。1 在github上面建立乙個倉庫 2 git clone dddddd dir 轉殖到本地 3 git add 新增檔案到working memory 4 git...
關於vue元件的一點筆記
近期在學習vue的一些知識，總結了部分vue元件的一些筆記，特此記錄，以便後期學習修正。關於單檔案元件，包含一下一些內容 1 三個部分組成 1 template模板 此部分為html結構，有且只有乙個根標籤 2 script 用於處理邏輯，在部分匯入元件 export default 3 style...