王余雷 童向杰

（中興通訊股份有限公司 江蘇省南京市 210012）

1 引言

隨著智能終端和移動互聯(lián)網(wǎng)絡的技術發(fā)展,智能終端得到越來越廣泛的使用，且其功能變得越來越復雜。對于智能終端開發(fā)人員來說，智能終端的穩(wěn)定性是衡量產(chǎn)品質(zhì)量的一個重要指標:在產(chǎn)品開發(fā)、測試和生產(chǎn)等過程中，開發(fā)人員需要進行單元測試、MTBF、老化測試、模糊測試、系統(tǒng)測試、模擬用戶測試等；在產(chǎn)品售后維修等過程中，開發(fā)人員需要進行客退故障樣機進行剖析和質(zhì)量回溯，并且將相應的成果及時地應用到后續(xù)產(chǎn)品的版本演進和流程優(yōu)化等?；诖?，本文提出了從軟件和硬件(含部件)兩大維度進行穩(wěn)定性問題分析的策略，側(cè)重于以Android平臺智能終端的開機定屏問題為對象進行了深入地研究和剖析，以及進行了方案驗證，從而給開發(fā)人員呈現(xiàn)一個較為全面的參考。

2 研究方案

Android平臺智能終端的穩(wěn)定性問題有多種多樣，比如:無法開機、開機黑屏、開機定屏、反復重啟，等等。本文提出了從軟件和硬件(含部件)兩大維度進行穩(wěn)定性問題分析的策略，并且此策略可能不局限于Android 平臺；本文側(cè)重于以Android平臺智能終端的開機定屏問題為對象進行了深入地研究和剖析，對某項目的小概率開機定屏問題和某項目的PMIC 受損問題進行實例分析和驗證，從而給開發(fā)人員呈現(xiàn)一個較為全面的參考。

一般來說，開發(fā)人員分析解決智能終端穩(wěn)定性問題，可從軟件和硬件兩個維度進行分析和方案檢驗（參見圖1）。

從軟件方面進行著手分析，首先，盡可能地第一時間獲取到發(fā)生故障時更為全面的日志信息，如Android 系統(tǒng)和內(nèi)核打印信息，ramdump，coredump，串口打印信息，發(fā)生段錯誤時backtrace 信息，等等；在獲取日志信息后，根據(jù)時間戳或關鍵字符串可能會快速定位到故障現(xiàn)場，再結(jié)合異常打印信息和模塊設計邏輯進行分析和推測等，這就是所謂的日志分析法。通常來講，大部分問題都能從日志信息中發(fā)現(xiàn)蛛絲馬跡，尤其是軟件原因所導致的問題。若開發(fā)人員可從日志文件中分析出指向性的結(jié)論，則接下來就可對相應模塊的程序設計進行原因分析與方案求證。其次，若開發(fā)人員較難地從日志文件中得出指向性的結(jié)論，則盡可能地獲取到故障樣機，然后進行現(xiàn)場診斷：為了快速定位問題，通常開發(fā)人員會在版本中集成一些的工具，如:應用鏡像文件完整性檢查、刷機版本有效性檢查、內(nèi)存模型測試、部件功能自檢等；還可考慮從故障樣機中導出userdata 鏡像文件后再燒錄至另外一臺樣機，檢查是否可再現(xiàn)故障；還可考慮插入USB 數(shù)據(jù)線或按鍵，觀察故障現(xiàn)象是否有變化，等等。這就是所謂的現(xiàn)場診斷法。接著，開發(fā)人員需要厘清一下該故障是單機問題還是多臺樣機共性問題，嘗試去探索出故障復現(xiàn)規(guī)律或評估粗略的復現(xiàn)概率。對于可復現(xiàn)的故障，開發(fā)人員可考慮恢復至默認的出廠版本，觀察故障現(xiàn)象是否存在；或者燒錄不同版本進行對比分析與回溯，觀察故障現(xiàn)象是否存在。這就是所謂的版本對比法；為了提升復現(xiàn)概率，開發(fā)人員可考慮進行MTBF、Monkey、常溫環(huán)境下eMMC 和DDR 壓力測試、高溫低壓環(huán)境下eMMC 和DDR測試、定制化的自動化測試等，觀察在哪些場景下或哪條操作路徑下可更高概率地復現(xiàn)故障。這就是所謂的壓力測試法；為了求證所推測的異常點，開發(fā)人員還可考慮在源代碼中增加打印語句或統(tǒng)計信息進行打點分析。這就是所謂的打點分析法。而對于推測求證法，通常是憑借開發(fā)人員的經(jīng)驗進行大膽推測，然后進行邏輯嚴謹?shù)那笞C，其分析方法貫穿于問題分析的核心過程。最后，開發(fā)人員可考慮組織關聯(lián)的領域?qū)＜疫M行集中討論和診斷，再針對每項可能的原因或舉措進行求證。這就是所謂的專家會診法。

圖1

若從軟件方面較難地得出具有指向性的結(jié)論，開發(fā)人員則可考慮從硬件方面進行著手分析，首先，通過假電池連接安捷倫直流電源進行開機過程中不同階段的電流測量，分析其電流值是否異常，若存在明顯的異常，則可能存在硬件受損而導致漏電等問題。這就是所謂的電流分析法。接著，對于可復現(xiàn)的故障，開發(fā)人員可分兩個階段進行硬件最小系統(tǒng)的構(gòu)建：第一階段，拆除部件外設和拔掉SIM 卡、SD 卡等，觀察故障現(xiàn)象是否存在；第二階段，針對某一塊故障單板進行在板器件的拆除，僅僅保留CPU、內(nèi)存和PMIC 等硬件最小系統(tǒng)，再觀察故障現(xiàn)象是否存在。這就是所謂的最小系統(tǒng)法。再者，開發(fā)人員可對發(fā)生故障時單板的器件或部件的管腳進行信號測量與記錄，同時對正常工作時單板的器件或部件的管腳進行信號測量與記錄，兩者進行對比分析；為了求證最小系統(tǒng)的eMMC 和DDR 功能性，開發(fā)人員可采用燒錄版本至故障樣機，確認其下載或開機等功能是否正常；為了求證最小系統(tǒng)的可見的器件焊接等問題，開發(fā)人員可使用風槍進行短暫加熱，觀察故障現(xiàn)象是否存在；為了求證最小系統(tǒng)的供電問題，開發(fā)人員可考慮采用外供電源的方法，觀察故障現(xiàn)象是否存在；等等。然后，若硬件最小系統(tǒng)仍然存在相應的故障現(xiàn)象，則需要產(chǎn)線人員參與分析是否與主板或最小系統(tǒng)的CPU/eMMC+DDR/PMIC 等有關，可考慮采用交叉驗證法、X-Ray 檢查法、切片分析法、紅墨水實驗法等。最后，開發(fā)人員可考慮聯(lián)絡平臺廠家或者eMMC+DDR 的原廠，對于可能與eMMC+DDR 有關的問題，則可考慮讓原廠安排技術人員現(xiàn)場支持，并且安排故障樣機的單體功能測試和單板的DDR 夾具測試，確認單體功能是否正常和DDR 的時序及眼圖等是否正常。

開機定屏，是指智能終端在開機的過程中，出現(xiàn)長時間停在一個界面上而無法正常進行操作的問題現(xiàn)象。一般來說，在開啟日志打印情況下，開發(fā)人員可獲取智能終端開機過程的日志信息，就可定位開機啟動至哪個階段發(fā)生故障現(xiàn)象。開機過程可粗略地劃分為四個階段：

（1）BootROM 啟動至Bootloader；

（2）Bootloader 啟動至Kernel；

（3）Kernel 加載文件系統(tǒng)和system_server 主服務等；

（4）system_server 等服務加載運行各個應用等。

當開機啟動至Bootloader 階段，具有開發(fā)經(jīng)驗的人員可推測與硬件相關性更大些；當開機啟動至system_server 主服務階段，表明外設驅(qū)動基本功能正常，從而可推測與關鍵文件損壞或版本燒錄異常導致版本不完整等，或者與硬件受損導致漏電有關。

3 實踐分析

MTK 平臺某款智能手機發(fā)生小概率的開機定屏問題，其分析思路是: 首先，從軟件維度來看，獲取到故障樣機，采用現(xiàn)場診斷法進行常規(guī)的診斷，通過組合按鍵進入Recovery 模式，執(zhí)行應用鏡像文件完整性檢查、Root 檢查等，其測試結(jié)果正常；通過特定的操作進入工程模式，執(zhí)行memtester 內(nèi)存模型測試等，其測試結(jié)果正常；然后開啟日志打印功能。再次重啟開機，該故障仍然存在，抓取從開機啟動至定屏整個過程完整的日志信息。根據(jù)日志信息初步分析的結(jié)論是: Kernel 啟動正常，而在系統(tǒng)服務啟動時發(fā)現(xiàn)如下的異常打印信息:

從上述的異常日志信息和JAVA Stack 來看，表明系統(tǒng)服務PackageManager 解析xml 文件時發(fā)生嚴重的錯誤。因而，將故障樣機中所解析的packages.xml 或packages-backup.xml 文件導出，通過查看和比對相應文件的內(nèi)容，確認是packages.xml 文件損壞導致xml 解析錯誤，進而導致Android 平臺的系統(tǒng)主進程system_server無法正常啟動，從而表現(xiàn)為開機定屏的問題現(xiàn)象。至此，基本上即可得出了指向性的結(jié)論，進而可大膽地推測與eMMC 和DDR 或者文件系統(tǒng)有關。其次，為了排查是否與eMMC 和DDR 電氣特性有關，進行了ETT 高溫低壓等場景下的壓力測試，使用了FlashTool工具的Memory Test 功能測試等；同時組織硬件領域?qū)＜疫M行會診和走查原理圖、布線等，其結(jié)論是測試等正常，暫未發(fā)現(xiàn)設計問題。接著，為了提升分析效率和快速驗證方案有效性，需要嘗試增加復現(xiàn)概率或找出復現(xiàn)規(guī)律，協(xié)調(diào)測試人員參與安排該項目的MTBF測試、CTS 測試、Monkey 測試和模擬用戶測試等，通過壓力測試發(fā)現(xiàn)了發(fā)生同類型的故障的樣機，由此，表明該故障是可復現(xiàn)的。同時開發(fā)人員對packages.xml 文件生成原理進行了研究:該文件是由PackageManagerService.java 生成，其文件內(nèi)容記錄了Android 系統(tǒng)中所安裝的APK 應用程序的所有屬性、權限等信息，當Android系統(tǒng)安裝、卸載、更新APK 應用程序時，packages.xml 文件都會被更改。從而，開發(fā)人員發(fā)現(xiàn)了一個非常有價值的突破口:通過自動化腳本實現(xiàn)反復安裝和卸載APK 應用程序，以達到packages.xml文件被反復更改的目的，進而可能達成增加復現(xiàn)概率。其方案是:利用Android 平臺monkeyrunner 測試框架和Python 語言編寫自動化測試腳本，實現(xiàn)安裝APK 應用程序后重啟智能手機，并且將啟動路徑下不同階段的packages.xml 導出至電腦端；然后選取三部故障樣機進行了壓力測試。其結(jié)果是以約2%概率復現(xiàn)了該故障。再者，考慮采用推測求證法，根據(jù)以往的故障經(jīng)驗進行大膽地推測和小心地求證，推測是否可能與內(nèi)存數(shù)據(jù)未能完整地同步至eMMC 有關，為此，優(yōu)化自動化測試腳本在特定階段通過Python 腳本調(diào)用sync操作，求證故障現(xiàn)象是否存在；其結(jié)果是測試10000 次，未復現(xiàn)故障，至此，問題根因有了更為明確的指向性，其原因大概率的是與軟件（含固件）配置有關。最后，開發(fā)人員采用版本對比法進行了不同的版本和不同eMMC+DDR 廠家的對比測試，開發(fā)人員求證了某兩個時期版本故障現(xiàn)象存在差異，進一步地了解到MTK 平臺近期文件系統(tǒng)增加了discard 屬性配置，研究了JEDEC 規(guī)范中discard 屬性，其要點是執(zhí)行discard 時要防止意外的數(shù)據(jù)丟失；同時還求證了采用三星廠家的芯片不存在此問題，開發(fā)人員和Hynix 原廠技術支持進行溝通，了解到該款芯片的某固件版本存在設計缺陷，未能正確地處理discard 屬性配置。至此，問題的根因是與Hynix 芯片的某固件版本未能正確地處理discard 屬性有關?？紤]升級eMMC 芯片固件的成本，開發(fā)人員提出了最終的解決方案是MTK 平臺去掉文件系統(tǒng)的discard 屬性配置，針對此解決方案，進行了累計60000次的自動化測試，未復現(xiàn)故障。

4 結(jié)束語

本文提出了從軟件和硬件(含部件)兩大維度進行穩(wěn)定性問題分析的策略，并且此策略可能不局限于Android 平臺；本文側(cè)重于以Android平臺智能終端的開機定屏問題為對象進行了深入地研究和剖析，以及進行了方案驗證，從而給開發(fā)人員呈現(xiàn)一個較為全面的參考。