軟件問題的分析與解決

嵌入式軟件由于調(diào)試手段的限制、部署場景的多樣化、軟硬件問題混合在一起、外部環(huán)境因素的影響等因素，導(dǎo)致軟件經(jīng)常會遇到一些非常難以解決的問題。

3.1 解題思想

熟悉軟件的業(yè)務(wù)流程：從業(yè)務(wù)的角度發(fā)現(xiàn)問題、復(fù)現(xiàn)問題并解決問題。

熟悉軟件的總體架構(gòu)：軟件架構(gòu)是解決難題問題的基本框架，基于軟件架構(gòu)解決問題不會陷入到局部細(xì)節(jié)，導(dǎo)致修復(fù)一個(gè)問題的同時(shí)產(chǎn)生新的問題，不會犯原則性、方向性錯誤。

熟悉軟件代碼的實(shí)現(xiàn)：熟悉代碼的細(xì)節(jié)，能夠更好、更快的在蛛絲馬跡中找到證據(jù)和突破點(diǎn)，甚至在問題還沒有收斂前，提供一種收斂的方向，引領(lǐng)問題的解決，對代碼的熟悉程度直接關(guān)系到解決問題的速度。

3.2 調(diào)試手段和信息不足相關(guān)問題

3.2.1 現(xiàn)場偶發(fā)性、難復(fù)現(xiàn)性引發(fā)的問題

一些偶發(fā)性現(xiàn)象級問題，甚至導(dǎo)致系統(tǒng)偶發(fā)性的重啟，無法復(fù)現(xiàn)，設(shè)備重啟之后，故障消失后，再也很難復(fù)現(xiàn)。

1、分析日志文件

從log中尋找異常提示，是應(yīng)對不可重復(fù)性、偶發(fā)性故障最基本的手段。在系統(tǒng)某處發(fā)生異常時(shí)，一定會在log中留下蛛絲馬跡，可以請客戶協(xié)助提供串口日志，在log文件中查找問題?；蛘咴O(shè)備自己內(nèi)部記錄log，但嵌入式設(shè)備由于存儲空間的限制，可能先前過于久遠(yuǎn)的信息，就會被新的信息被覆蓋，針對這種情況，就需要定期清除無效日志。有些異常會導(dǎo)致系統(tǒng)重啟，而重啟之后，就會導(dǎo)致異常信息被正常重啟的信息覆蓋，這就需要系統(tǒng)能夠支持log的備份。不管怎么樣，log為定位現(xiàn)場問題提供了最基本的、最主要的信息來源。一個(gè)完善的log機(jī)制，對于定位現(xiàn)場問題非常有幫助。如果不滿足，可能首要任務(wù)是先完善日志功能。

2、回退軟件版本，緊急消除現(xiàn)場問題

有些現(xiàn)場問題，雖然偶發(fā)事件，但發(fā)生后影響嚴(yán)重，客戶無法接受。針對這種情況，在解決問題之前，可以先把軟件降級，降級到相對穩(wěn)定，沒有嚴(yán)重故障的版本。

3、比較相鄰版本之間的代碼改動

如果不容易復(fù)現(xiàn)的故障，確認(rèn)在升級了某個(gè)軟件版本之后才出現(xiàn)的，而其他現(xiàn)場條件都沒有變化，且分析log也無法發(fā)現(xiàn)異常點(diǎn)。此時(shí)，一種高效的解決此問題的方法，就是比較兩個(gè)版本之間的代碼的改動。

代碼改動比較少，分析代碼比較容易；如果代碼改動比較多，就需要根據(jù)用戶描述的現(xiàn)象，結(jié)合前后代碼的改動模塊，初步分析最可能是哪個(gè)模塊引起的，這種往往需要對系統(tǒng)架構(gòu)較深刻的理解。在眾多修改模塊中，分析最有可能關(guān)聯(lián)的代碼模塊的改動，然后逐一排查 。分析代碼的改動與出現(xiàn)的現(xiàn)象之間可能的關(guān)聯(lián)關(guān)系，對開發(fā)人員個(gè)人的技術(shù)素養(yǎng)和方法論有較高的要求 。比較相鄰版本之間的代碼改動，針對某些棘手的現(xiàn)場問題，有時(shí)候確實(shí)是一個(gè)非常有效的手段。

4、問題復(fù)現(xiàn)

雖然常規(guī)來說現(xiàn)場很難復(fù)現(xiàn)，但可以人為的修改軟件、構(gòu)建或增加模擬數(shù)據(jù)，人為創(chuàng)造或觸發(fā)條件，增加故障復(fù)現(xiàn)的幾率。在設(shè)計(jì)觸發(fā)條件時(shí)，需要圍繞用戶描述的現(xiàn)場故障現(xiàn)象來設(shè)計(jì)觸發(fā)條件，觀察是否能否復(fù)現(xiàn)，且表現(xiàn)一致。

5、分析代碼

根據(jù)用戶描述的現(xiàn)象，硬分析代碼，是一種通用的方法，放之四海皆準(zhǔn)的方法，熟悉自身代碼的邏輯關(guān)系是基本功，但解決問題的效率就比較難把握了。

6、增加 log 更新版本繼續(xù)測

如果常規(guī)的log無法展現(xiàn)故障的異常，就需要在猜測有可能的部分增加日志，在現(xiàn)場復(fù)測。但這種日志添加的位置是否合理，決定了問題再次出現(xiàn)時(shí)是否能定位問題的準(zhǔn)確性。這種方法在工程實(shí)踐中，實(shí)施難度大，需要客戶多次配合。

3.2.2 現(xiàn)象與真正的原因不在一起的問題

大多時(shí)候解決軟件故障，是可以做到頭痛醫(yī)頭，腳痛醫(yī)腳。有些時(shí)候，頭痛的原因并不在“頭”，而在“腳”。這就需要知道“頭痛” 與 “腳” 的某種關(guān)聯(lián)關(guān)系。

解決這樣的問題，對技術(shù)人員的綜合技能的要求非常高，因?yàn)檫@個(gè)問題，不再是局部問題，而是發(fā)散到調(diào)查該問題的技術(shù)人員不熟悉的其他的軟件組件領(lǐng)域。即使對于熟悉整個(gè)系統(tǒng)的人而言，也是一個(gè)難點(diǎn)，因?yàn)閱栴}的現(xiàn)象與根源之間的路徑是發(fā)散的，沒有一個(gè)確切的路徑。

首先，必須以故障的表面現(xiàn)象作為錨點(diǎn)，作為出發(fā)點(diǎn)。為后續(xù)進(jìn)一步的調(diào)查立一個(gè)基點(diǎn)。根據(jù)現(xiàn)象找到出問題的代碼，根據(jù)代碼和log分析代碼的表面原因。如果確實(shí)是本處代碼的問題，直接在此解決即可。即頭痛醫(yī)頭，腳痛醫(yī)腳。

很多情形下，真正的原因不在顯示異常的地方，比如收到了異常的事件、或參數(shù)不合理、或自身狀態(tài)機(jī)的問題等。這時(shí)候就需要追溯，為什么會有這樣的事件或消息？有時(shí)候，由于復(fù)雜系統(tǒng)的程序員沒有系統(tǒng)的視角，常以為消除了故障表面現(xiàn)象就是解決了問題。很多時(shí)候站在系統(tǒng)的視角，可以從多個(gè)層面加以解決，消除異常事情，可以從規(guī)則過濾模塊解決，也可從前置模塊或后續(xù)模塊解決。具體在哪兒解決最合理，這就需要有系統(tǒng)和結(jié)構(gòu)的視角。當(dāng)然，也曾遇到有人解決類似問題是屏蔽異常消息或者屏蔽ASSERT，并沒從根源去消除為什么產(chǎn)生了異常。

3.2.3 報(bào)錯點(diǎn)發(fā)生在第三方庫內(nèi)部

軟件報(bào)錯的地方是在第三方庫，而第三方庫有沒有源代碼或不熟悉

如果集成的第三方庫沒有源代碼，則把這個(gè)問題上報(bào)給第三方，讓第三方給出內(nèi)部出錯的原因，更新庫或者配合抓日志分析。如果第三方庫有源代碼的話，可分析第三方代碼，增加日志或檢查傳入第三方庫函數(shù)的參數(shù)是否正確，是否合法；大多數(shù)時(shí)候，是錯誤地傳入了不合適的參數(shù)給第三方庫。檢查使用第三方的時(shí)序是否正確，在軟件系統(tǒng)中，時(shí)序是一個(gè)非常重要，同樣的函數(shù)，同樣的代碼，如果時(shí)序不對，也會導(dǎo)致代碼邏輯紊亂。不過現(xiàn)在提供庫或者SDK，一般都有技術(shù)支持，也可直接尋求幫助。

3.2.4 軟硬件結(jié)合導(dǎo)致的無法定位的問題

在嵌入式系統(tǒng)中，有時(shí)候會出現(xiàn)硬件異常導(dǎo)致軟件狀態(tài)或邏輯錯誤，硬件人員很難根據(jù)有限的信息判斷硬件到底怎么了，通常軟件和硬件就會反復(fù)的踢皮球。但是用戶角度看到的異常是在軟件這邊。

由于硬件團(tuán)隊(duì)對客戶現(xiàn)場的設(shè)備，通常沒有檢測手段來判斷是否真是硬件問題的，軟件團(tuán)隊(duì)最好能夠通過日志配置，確認(rèn)硬件故障單元?；蛘咧苯訉臋C(jī)寄回硬件部門，軟件配合復(fù)現(xiàn)問題，以幫助硬件團(tuán)隊(duì)判斷。

硬件故障問題，需要特別關(guān)注供電、時(shí)鐘信號，復(fù)位時(shí)間等，曾經(jīng)遇到幾次因?yàn)榇诼╇姵鋈?dǎo)致外部傳感器復(fù)位異常的問題?？傊浻布慕缓咸帲侨菀壮镀さ牡胤?，這需要軟件人員也同時(shí)了解硬件的工作原理，在出故障時(shí)，能夠更好的判斷是軟件異常，還是硬件真的有故障。

還有一個(gè)商業(yè)上的問題，如果客戶感受到是硬件的問題，需要回收設(shè)備，會造成很大的經(jīng)濟(jì)損失。一般情況下是軟件想辦法規(guī)避異常，畢竟軟件復(fù)制不需要成本。