學(xué)習(xí)Android程序時(shí)總結(jié)之談
希望我學(xué)習(xí)Android程序時(shí)的一點(diǎn)經(jīng)驗(yàn)?zāi)芙o大家?guī)韼椭瑢?dǎo)致WebDeployment出錯(cuò)的原因也許還有很多，不過在你遇到錯(cuò)誤時(shí)，可以先檢查一下你程序中的字符串，暫時(shí)把他們置為””,試試看。沒準(zhǔn)就是他引起的問題啊。
1. onUnsolicite（主動(dòng)上報(bào)響應(yīng)）
static void onUnsolicited (const char *s, const char *sms_pdu)；短信的AT設(shè)計(jì)真是麻煩的主，以致這個(gè)函數(shù)的第二個(gè)參數(shù)完全就是為它準(zhǔn)備的。
response 的主要的解析過程，由at_tok.c中的函數(shù)完成，其實(shí)就是字符串按塊解析，具體的解析方式由每條命令或上報(bào)信息自行決定。這里不再詳述，onUnsolicited只解析出頭部(一般是+XXXX的形式)，然后按類型決定下一步操作，操作為 RIL_onUnsolicitedResponse和RIL_requestTimedCallback兩種。
a)RIL_onUnsolicitedResponse：將 unsolicited的信息直接返回給上層。通過Parcel傳遞，將 RESPONSE_UNSOLICITED，unsolResponse（request號(hào)）寫入Parcel先，然后通過 s_unsolResponses數(shù)組，查找到對應(yīng)的responseFunction完成進(jìn)一步的的解析，存入Parcel中。最終通過 sendResponse將其傳遞回原進(jìn)程。
流程：
sendResponse-->sendResponseRaw-->blockingWrite-->write to s_fdCommand(前面建立起來的和上層框架的socket連接)這些步驟之后有一些喚醒系統(tǒng)等其他操作。不再詳述。通過event機(jī)制（參考文章二）實(shí)現(xiàn)的timer機(jī)制，回調(diào)對應(yīng)的內(nèi)部處理函數(shù)。
通過internalRequestTimedCallback將回調(diào)添加到event循環(huán)，最終完成callback上掛的函數(shù)的回調(diào)。比如pollSIMState，onPDPContextListChanged等回調(diào)， 不用返回上層， 內(nèi)部處理就可以。
2. switch s_type（命令的具體響應(yīng)）及handleFinalResponse（標(biāo)準(zhǔn)響應(yīng)）命令的類型（s_type）在send command的時(shí)候設(shè)置（參考文章二）。
有NO_RESULT，NUMERIC，SINGLELINE，MULTILINE幾種，供不同的AT使用。比如AT+CSQ是singleline, 返回at+csq=xx,xx，再加一行OK，比如一些設(shè)置命令，就是no_result, 只有一行OK或ERROR。
這幾個(gè)類型的解析都很相仿，通過一定的判斷（比較AT頭標(biāo)記等），如果是對應(yīng)的響應(yīng)，就通過 addIntermediate掛到一個(gè)臨時(shí)結(jié)果sp_response->p_intermediates隊(duì)列里。如果不是對應(yīng)響應(yīng)，那它其實(shí)應(yīng)該是穿插其中的自動(dòng)上報(bào)，用onUnsolicite來處理。
具體響應(yīng)，只起一個(gè)獲取響應(yīng)信息到臨時(shí)結(jié)果，等待具體分析的作用。無論有無具體響應(yīng)，最終都得以標(biāo)準(zhǔn)響應(yīng)handleFinalResponse來完成，也就是接受到OK,ERROR等標(biāo)準(zhǔn)response來結(jié)束，這是大多數(shù)AT命令的規(guī)范。
Android會(huì)設(shè)置s_commandcond這一object，學(xué)習(xí)Android程序也就是at_send_command_full_nolock等待的對象。到這里，響應(yīng)的完整信息已經(jīng)完全獲得，send command可以進(jìn)一步處理返回的信息了（臨時(shí)結(jié)果，以及標(biāo)準(zhǔn)返回的成功或失敗，都在sp_response中）。
可以看到確實(shí)是通過at_send_command_singleline來進(jìn)行的操作，response在p_response中。p_response如果返回失敗（也就是標(biāo)準(zhǔn)響應(yīng)的ERROR等造成），則通過RIL_onRequestComplete發(fā)送返回?cái)?shù)據(jù)給上層，結(jié)束命令。如果成功，則進(jìn)一步分析p_response->p_intermediates， 同樣是通過at_tok.c里的函數(shù)進(jìn)行分析。并同樣將結(jié)果通過RIL_onRequestComplete返回。
RIL_onRequestComplete：
RIL_onRequestComplete和RIL_onUnsolicitedResponse很相仿，功能也一致。
通過Parcel來傳遞回上層，同樣是先寫入RESPONSE_SOLICITED（區(qū)別于 RESPONSE_UNSOLICITED），pRI->token(上層傳下的request號(hào)），錯(cuò)誤碼（send command的錯(cuò)誤，不是AT響應(yīng)）。
學(xué)習(xí)Android程序如果有AT響應(yīng)，通過訪問pRI->pCI->responseFunction來完成具體 response的解析，并寫入Parcel。然后通過同樣的途徑：完成最終的響應(yīng)傳遞。到這里，我們分析了自動(dòng)上報(bào)與命令響應(yīng)，其實(shí)response部分，也就告一段落了。三篇分析RIL的文章也到此結(jié)束。
【編輯推薦】
