在使用G7的時候，最不滿意的就是，群發短信的速度太慢，而且有時會出現ANR的情況，就G7的硬件配置來說，按理不至于發生這種情況。原因究竟何在？通過對Rild和Phone的分析認為，原因和Rild以及Phone的設計有些許關系，下面來探討一下這個問題。 以Rild和RefRil庫為例，來分析Rild和Phone的設計上有哪些特點和問題。注意，這里，將短信程序和Phone程序統稱為Phone。 - Rild沒有使用Binder通信機制和Phone進行交互，這一點，雖感覺較奇怪，不過也好理解，因為實現一個用Socket進行IPC通信的架構，比用Binder要簡單，至少代碼量要少一些。 - Rild使用了異步請求/處理的模式，這種模式對于Rild來說是合適的。因為一個請求的處理可能耗時很長，另外一點就是Rild會收到來自BP的unsolicited Response。 - Phone這個應用也使用了異步模式。其實，這也好理解，因為Phone和Rild采用了Socket進行通信，如把Phone中的Socket看做是Rild中的串口設備，就發現這個Phone竟然是Rild在Java層的翻版。這樣設計有問題嗎？其明顯缺陷就是一個請求消息在Java層的Phone中要保存一個，傳遞到Rild中還要保存一個。另外，Phone和Rild交互的是AT命令。這種直接使用AT命令的方式，對以后的擴展和修改都會造成不少麻煩。 - 再來看群發短信問題。群發短信的實現，就是同一個信息發送到不同的號碼。對于目前Phone的實現而言，就是一個for循環中調用一個發送函數，參數中僅有號碼不同，而短信內容是一樣的。這種方式是否太浪費資源了呢？假設群發目標人數為二百個，那么Java層要保存二百個請求信息，而Rild層也要保存二百個請求信息。并且Rild每處理一個命令就會來一個完成通知。對于群發短信功能來說，本人更關心的是，所有短信發送完后的統一結果，而非單條短信發送的結果。 以上是我關于Rild和Phone設計特點的一些總結。如果由我來實現Phone，該怎么做呢？這里，愿將自己的一些想法與讀者分享。 - 在Phone和Rild的進程間通信上，將使用Binder機制。這樣，需首先定義一個Phone和Rild通信的接口，這個接口的內容和Rild提供的服務有關，例如定義一個dial函數，定義一個sendSMS函數。除此之外，需要定義Rild向Phone回傳Response的通知接口。也就是說，Rild直接利用Binder回調Phone進程中的函數，把結果傳過去。采用Binder至少有三個好處。第一，Phone和Rild的交互基于接口函數，就不用在Phone中做AT命令的轉換了，另外基于接口的交互使得程序的可擴展性也得到了提高。第二，可以定義自己的函數，例如提供一個函數用來實現群發短信，通過這個函數可將一條短信內容和多個群發目標打包傳遞給Rild，然后由Rild自己去解析成多條AT命令進行處理。第三，Phone代碼將會被精簡不少。 - 在內存使用方面，有可能Phone和Rild都需保存請求，這時可充分利用共享內存的優勢，將請求信息保存在共享內存中。這樣，可減少一部分內存使用。另外，這塊內存中存儲的信息可能需要使用一定的結構來組織，例如采用優先級隊列。這樣，那些優先級高的請求就能首先得到處理了。 以上是本人在研究Rild和Phone代碼過程中一些不成熟的想法，希望能引起讀者共同的思考。讀者還可以參考網上名為《RIL設計思想解析》的一篇文章。