response信息的獲取，是在第一篇初始化分析中，提到的readerLoop中。由readline函數(shù)以‘行’為單位接收上來。
AT的response有兩種，一是主動(dòng)上報(bào)的，比如網(wǎng)絡(luò)狀態(tài)，短信，來電等都不需要經(jīng)過請求，有一unsolicited詞語專門描述。另一種才是真正意義上的response，也就是命令的響應(yīng)。
這里我們可以看到，所有的行，首先經(jīng)過sms的自動(dòng)上報(bào)篩選，因?yàn)槎绦诺腁T處理通常比較麻煩，無論收發(fā)都單獨(dú)列出。這里是因?yàn)橐磿r(shí)處理這條短信消息（兩行，標(biāo)志＋pdu），而不能拆開處理。處理函數(shù)為onUnsolicited（由s_unsolHandler指向），我們等下介紹。
除開sms的特例，所有的line都要經(jīng)過processLine，我們來看看這個(gè)流程：
processLine
|----no cmd--->handleUnsolicited //主動(dòng)上報(bào)
|----isFinalResponseSuccess--->handleFinalResponse//成功,標(biāo)準(zhǔn)響應(yīng)
|----isFinalResponseError--->handleFinalResponse//失敗，標(biāo)準(zhǔn)響應(yīng)
|----get '>'--->send sms pdu//收到>符號，發(fā)送sms數(shù)據(jù)再繼續(xù)等待響應(yīng)
|----switch s_type--->具體響應(yīng)//命令有具體的響應(yīng)信息需要對應(yīng)分析
我們這里主要關(guān)注handleUnsolicited自動(dòng)上報(bào)（會(huì)調(diào)用到前面smsUnsolicite也調(diào)用的onUnsolicite），以及switchs_type具體響應(yīng)信息，另外具體響應(yīng)需要handleFinalResponse這樣的標(biāo)準(zhǔn)響應(yīng)來最終完成。
1.onUnsolicite（主動(dòng)上報(bào)響應(yīng)）
static void onUnsolicited (const char *s, constchar *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號）寫入Parcel先，然后通過s_unsolResponses數(shù)組，查找到對應(yīng)的responseFunction完成進(jìn)一步的的解析，存入Parcel中。最終通過sendResponse將其傳遞回原進(jìn)程。流程：
sendResponse-->sendResponseRaw-->blockingWrite-->writeto s_fdCommand(前面建立起來的和上層框架的socket連接)
這些步驟之后有一些喚醒系統(tǒng)等其他操作。不再詳述。
b)RIL_requestTimedCallback：
通過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）在sendcommand的時(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ī)范?！?/p>
handleFinalResponse會(huì)設(shè)置s_commandcond這一object，也就是at_send_command_full_nolock等待的對象。到這里，響應(yīng)的完整信息已經(jīng)完全獲得，sendcommand可以進(jìn)一步處理返回的信息了（臨時(shí)結(jié)果，以及標(biāo)準(zhǔn)返回的成功或失敗，都在sp_response中）。
pp_outResponse參數(shù)將sp_response返回給調(diào)用at_send_command_full_nolock的函數(shù)。
繼續(xù)我們在文章二的分析的話，這個(gè)函數(shù)其實(shí)是requestDial，不過requestDial忽略了響應(yīng)，所以我們另外看個(gè)例子，如requestSignalStrength，命令其實(shí)就是前面提到的at+csq：可以看到確實(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號），錯(cuò)誤碼（sendcommand的錯(cuò)誤，不是AT響應(yīng)）。如果有AT響應(yīng)，通過訪問pRI->pCI->responseFunction來完成具體response的解析，并寫入Parcel。
然后通過同樣的途徑：
sendResponse-->sendResponseRaw-->blockingWrite-->writeto s_fdCommand
完成最終的響應(yīng)傳遞。
到這里，我們分析了自動(dòng)上報(bào)與命令響應(yīng)，其實(shí)response部分，也就告一段落了，三篇分析RIL的文章也到此結(jié)束。
