《Android 開發藝術探索》讀後筆記 ---- 第二章

• 進程開頭以：開頭的是當前應用的私有進程，其餘應用的沒法與他跑在同一個進程中
• messgener 的底層實現方式爲aidl的方式
• 調用方經過rpc調用遠程請求會將當前線程進行掛起，一直等到服務端返回數據
• 服務端的binder方法是運行在binder的線程池中的，因此無論如何binder方法必須使用同步。
• 調用端binder調用的回調結果將會在當前線程中實現，服務端的binder實現是在binder的線程池中調用某個線程來實現的
• aidl文件不是實現binder的必需品能夠由本身手寫完成
• ibinder對象有一個linktodeath 設置服務端死亡代理等待服務端死亡回調
• 儘可能避免進行進程間通訊
• 進程間通訊，使用bundle intent直接傳遞數據，使用文件進行通訊（sp）、messenger、
  -- sp的實現包含了緩存策略致使多進行讀寫會發生消息的不可靠問題
  -- messager客服端能夠接受來之服務器端的消息，只須要在sendmessage的時候講客服端的messager設置在replyto 便可，至關於寫信時將本身的地址告訴對方，但願對方按照這個地址回信，messager 是行
  -- aidl中對象的跨進程傳輸本質上就是序列與反序列化的過程，貌似同一個對象其實在兩個進程中是不一樣的對象，因爲這個緣由致使回調在方法在aidl中解綁會致使解綁失敗，由於解綁的listener不是同一個對象，解決方案爲使用remotecallbacklist，remotecallbacklist不是一個list，內部實現方式爲arraymap，key爲binder value爲callback，beginBroadcost和finishbroadcost要配對使用，哪怕致死獲取一個size
  -- 避免在客服端的ui線程中調用binder的方法，避免anr同理，服務端也應該避免在ui線程中調用binder的方法，避免anr
  -- binder將會意外死亡，有兩種調用解決方案，第一種onservicedisconnected 和bindtodeth 這兩個的區別在於回調的線程不一樣，一個在主線程，一個在binder線程池

contentprovider 的crud方法存在大量的多線程併發訪問，須要作好線程同步

socket 中tcp和udp tcp自己提供了超時重傳機制

binder pool 當有不少的aidl要求時，使用自定義binderpool 使用countdownlatch 將異步方法改成同步方法 在bindtodeath 斷線重連機制