一種基于iOS的錯誤日志系統(tǒng)設(shè)計方案

楊揚，朱曉民

（1 北京郵電大學(xué)網(wǎng)絡(luò)與交換技術(shù)國家重點實驗室，北京 100876；2 東信北郵信息技術(shù)有限公司，北京 100191）

一種基于iOS的錯誤日志系統(tǒng)設(shè)計方案

楊揚1,2，朱曉民1,2

（1 北京郵電大學(xué)網(wǎng)絡(luò)與交換技術(shù)國家重點實驗室，北京 100876；2 東信北郵信息技術(shù)有限公司，北京 100191）

隨著iOS系統(tǒng)上應(yīng)用復(fù)雜度的不斷增大，開發(fā)者及用戶對于應(yīng)用和系統(tǒng)的可靠性要求也隨之不斷提升。本文設(shè)計實現(xiàn)了一種能夠開機自啟動并始終在后臺運行的iOS日志系統(tǒng)。該日志系統(tǒng)能夠收集系統(tǒng)和第三方應(yīng)用中發(fā)生的錯誤，并將這些錯誤提交到遠(yuǎn)程服務(wù)器上以供進(jìn)一步的分析和研究。

錯誤收集；智能手機； iOS日志系統(tǒng)

隨著移動互聯(lián)網(wǎng)時代的飛速發(fā)展，移動便攜設(shè)備開始在越來越多的商業(yè)和娛樂活動中發(fā)揮重要作用。硬件的提升使得開發(fā)高復(fù)雜度的應(yīng)用成為可能。已有研究提出了智能手機更廣泛的應(yīng)用場景，例如病患信息監(jiān)測，監(jiān)控系統(tǒng)，遠(yuǎn)程控制機器人等。在這些方面設(shè)備和應(yīng)用的可靠性顯得尤為重要。上述應(yīng)用中任何程序崩潰或假死都可能引發(fā)嚴(yán)重的后果，比如電子醫(yī)療應(yīng)用未能及時向醫(yī)療中心發(fā)出警告信息[1]。

目前關(guān)于程序復(fù)雜度提升對智能手機可靠性影響的研究較少，在一些實時性可靠性高的項目上能夠依賴移動設(shè)備的程度尚且不夠明晰[2]。因而，業(yè)界需要通過對智能手機的系統(tǒng)及應(yīng)用錯誤進(jìn)行收集和分析，提升開發(fā)者對智能手機可靠性的理解，為未來的更廣泛應(yīng)用提供理論基礎(chǔ)。

基于以上原因，本文基于蘋果公司開發(fā)的iOS，設(shè)計和實現(xiàn)了一個錯誤日志系統(tǒng)，實現(xiàn)自動從手機中收集錯誤數(shù)據(jù)并匯總于遠(yuǎn)程服務(wù)器以供進(jìn)一步的研究分析。

1 背景及相關(guān)工作

iOS（iPhone Operation System，iPhone操作系統(tǒng)）是由蘋果公司為移動設(shè)備所開發(fā)的操作系統(tǒng)。目前iOS是繼Android之后全世界份額第二的智能手機操作系統(tǒng)。系統(tǒng)內(nèi)核與OS X一樣是使用了基于Mach 3及FreeBSD衍生而來的Darwin內(nèi)核。官方iOS開發(fā)環(huán)境僅支持帶有GUI（Graphical User Interface，圖形用戶接口）的終端應(yīng)用程序。以O(shè)bjective-C作為其開發(fā)語言，SDK（Software Development Kit，軟件開發(fā)工具包）中提供了一系列的預(yù)定義軟件框架，其中大部分的框架與OS X通用。iOS平臺采用強限制的結(jié)構(gòu)，應(yīng)用以沙盒機制運行。根據(jù)蘋果公司的開發(fā)文檔描述，iOS的應(yīng)用沙盒將應(yīng)用限制的級別定義為“每一個應(yīng)用都是一個孤島”。為了軟件安全，這種設(shè)計極大程度地推崇應(yīng)用隔離，犧牲了本機內(nèi)應(yīng)用間的信息共享。

對于系統(tǒng)運行過程中產(chǎn)生的錯誤數(shù)據(jù)的收集和分析一直是研究計算機系統(tǒng)可靠性的有效途徑。這類研究旨在深入調(diào)查現(xiàn)有系統(tǒng)發(fā)生的錯誤，以便在實際項目中減少錯誤的發(fā)生提高系統(tǒng)的穩(wěn)定性。過去，這類研究主要集中關(guān)注Windows2000， Linux等操作系統(tǒng)。另一些研究則側(cè)重于網(wǎng)絡(luò)操作系統(tǒng)或大規(guī)模超級計算機。最近的研究也開始逐步的關(guān)注手機端操作系統(tǒng)。例如對于Symbian[3]和Android[4]系統(tǒng)的可靠性研究。然而由于iOS系統(tǒng)的諸多限制，因此對于iOS系統(tǒng)的可靠性研究尚且不多。

蘋果官方的錯誤收集系統(tǒng)會將系統(tǒng)錯誤發(fā)送到蘋果的服務(wù)器上供蘋果的工程師分析，但是對于第三方的應(yīng)用來說則沒有提供相應(yīng)的能力[5]?，F(xiàn)有的解決方案如Airbreak、HockyApp、QuincyKit等通過提供鏈接庫的形式，將自身的SDK集成到開發(fā)者的第三方應(yīng)用當(dāng)中。雖然這些方案對于收集開發(fā)者應(yīng)用來說足夠強大，但它們目前都不能收集系統(tǒng)的錯誤，例如系統(tǒng)資源不足、系統(tǒng)假死或系統(tǒng)自動重啟等等。本文則設(shè)計了一種不同的方案，首先開發(fā)者無需將錯誤收集的代碼集成進(jìn)自己的應(yīng)用，其次本方案除了應(yīng)用的錯誤外還會收集iOS系統(tǒng)的錯誤，以此作為對現(xiàn)有解決方案的完善及改良。

2 日志系統(tǒng)的設(shè)計

眾所周知，iOS平臺有著諸多的嚴(yán)格限制。例如，在后臺操作方面對于操作種類和運行時間有限制，此外在能夠訪問的系統(tǒng)資源方面也十分嚴(yán)格。相比之下，日志子系統(tǒng)應(yīng)該作為一項服務(wù)隨著開機自動啟動以監(jiān)測系統(tǒng)假死、自動重啟等事件。該系統(tǒng)應(yīng)無限期的保持在后臺運行并收集諸如內(nèi)存、CPU、網(wǎng)絡(luò)操作等系統(tǒng)狀態(tài)信息。詳細(xì)的結(jié)構(gòu)如圖1所示。

圖1 系統(tǒng)設(shè)計方案

iOS系統(tǒng)僅允許開發(fā)者進(jìn)行終端應(yīng)用的開發(fā)，涉及到其他類型的進(jìn)程，例如系統(tǒng)服務(wù)，是無法由第三方開發(fā)者進(jìn)行開發(fā)的。因此，本文將日志子系統(tǒng)封裝到了終端應(yīng)用中，同時可以借助該應(yīng)用來展示最近監(jiān)測到的錯誤列表。

當(dāng)應(yīng)用轉(zhuǎn)換為后臺運行后，日志子系統(tǒng)中的組件就會開始同操作系統(tǒng)進(jìn)行交互，收集信息并存儲到本地數(shù)據(jù)庫中。在實現(xiàn)階段將采用iOS內(nèi)置的應(yīng)用框架庫完成系統(tǒng)。

針對iOS系統(tǒng)對第三方應(yīng)用所施加的限制，日志子系統(tǒng)中還需要添加生命周期模塊及數(shù)據(jù)傳輸模塊，其中生命周期模塊可以讓日志系統(tǒng)無限期的在后臺運行，而數(shù)據(jù)傳輸模塊則在有網(wǎng)絡(luò)的時候?qū)⒈镜財?shù)據(jù)庫中的數(shù)據(jù)發(fā)送到遠(yuǎn)程服務(wù)器上以便進(jìn)行進(jìn)一步的分析。各模塊的設(shè)計如下列小節(jié)所示。

2.1 系統(tǒng)數(shù)據(jù)及狀態(tài)監(jiān)測模塊

在iOS中有許多高級API（Application Programming Interface，應(yīng)用程序接口）能夠用以獲取系統(tǒng)信息或監(jiān)視系統(tǒng)運行狀態(tài)， 本部分實現(xiàn)的模塊通過這些系統(tǒng)調(diào)用同系統(tǒng)內(nèi)核進(jìn)行交互，以獲取內(nèi)存、CPU信息以及運行中的進(jìn)程列表。為了將數(shù)據(jù)在不同的模塊間傳遞，需要將所有收集到信息從底層的C語言結(jié)構(gòu)橋接到高級Objective-C的類中。此外，該模塊會將所有的信息加上時間戳后存儲到本地數(shù)據(jù)庫中。

2.2 心跳模塊

心跳模塊用于探知系統(tǒng)的假死或者自動重啟等事件。該組件每10 s向一個XML（eXtensible Markup Language，可擴展標(biāo)記語言）文件寫入一次alive信息。當(dāng)用戶關(guān)閉系統(tǒng)或者殺死日志系統(tǒng)的應(yīng)用程序進(jìn)程時該組件會寫入一條shutdown信息。在每次應(yīng)用啟動到開始寫入第一條alive信息前，該組件會讀取上一次寫入的信息，并檢查是否有假死或者自動重啟的事件發(fā)生過。

2.3 Tracker模塊

該模塊通過分析iOS系統(tǒng)日志來探測崩潰和掛起事件。系統(tǒng)日志由Apple System Logger（ASL）框架提供。當(dāng)運行中的進(jìn)程發(fā)起了某個事件或者向標(biāo)準(zhǔn)輸出流中寫入信息時，iOS將會生成相應(yīng)的信息，這些信息都可以通過Tracker模塊來獲取。因此，需要另一個線程來周期性的獲取最新的系統(tǒng)日志并發(fā)出廣播信息。一旦Tracker模塊接受到廣播信息，就可以通過辨識日志中事件的schema對事件進(jìn)行分析，判定事件是崩潰事件、掛起事件還是其他事件。本文將集中關(guān)注程序崩潰和應(yīng)用掛起這兩類開發(fā)者最常遇到的事件。如需對其他類型的事件追蹤，也可以很方便的通過修改程序來進(jìn)行擴展。

當(dāng)監(jiān)測到崩潰或掛起事件后，該模塊會將信息保存在本地的數(shù)據(jù)庫中。這些信息會同系統(tǒng)數(shù)據(jù)及狀態(tài)監(jiān)測模塊收集到的信息一起結(jié)合起來分析，以便找出崩潰或掛起事件同系統(tǒng)狀態(tài)之間的聯(lián)系。

2.4 生命周期模塊

前文提到iOS對程序有很多嚴(yán)格的限制，例如應(yīng)用程序只能在用戶啟動程序后方可運行，并且會在進(jìn)入后臺狀態(tài)后的10 min內(nèi)被殺死。而日志子系統(tǒng)需要隨系統(tǒng)啟動且無限期的在后臺運行。因此本文在系統(tǒng)中加入了生命周期模塊以模擬 Voice over IP（VoIP） 類型應(yīng)用的方式解決這兩個問題。通過查閱蘋果的官方文檔可以得知，VoIP應(yīng)用會在系統(tǒng)啟動時在后臺激活，但會在不到10 s的時間內(nèi)被掛起。接下來又會每隔10 min在后臺重新啟動一次，同樣活動時間不超過10 s。盡管如此，iOS系統(tǒng)卻允許任何應(yīng)用的進(jìn)程在被停止前可以發(fā)起一個長達(dá)10 min的后臺任務(wù)schedule。綜合考慮以上因素后，在本模塊的支撐下，日志系統(tǒng)的生命周期可以表述如下。當(dāng)系統(tǒng)啟動時，日志系統(tǒng)作為VoIP應(yīng)用自動啟動，在10 s的活動時間內(nèi)本模塊將啟動一個10 min的后臺任務(wù)schedule。10 min過后，由于iOS系統(tǒng)會再次啟動VoIP應(yīng)用，因此程序又可以繼續(xù)運行。出于對耗電量和系統(tǒng)資源占用的考慮，本模塊每次工作后會sleep10 s，然后進(jìn)行下一次的信息獲取。經(jīng)測試，應(yīng)用運行400 s，有200 s左右的時間處于休眠狀態(tài)，因此當(dāng)日志系統(tǒng)運行時并不會對系統(tǒng)性能造成顯著的影響。

2.5 數(shù)據(jù)傳輸模塊

數(shù)據(jù)傳輸模塊將所有存儲在本地數(shù)據(jù)庫中的信息發(fā)送到遠(yuǎn)程服務(wù)器上，以便于檢索分析來自不同設(shè)備的錯誤信息。本模塊每隔30 s檢查一次數(shù)據(jù)庫，看是否有更新數(shù)據(jù)插入。如果有則取出這些數(shù)將它們發(fā)送到遠(yuǎn)程服務(wù)器上交由ruby腳本處理。腳本程序與MySQL建立連接，將各個設(shè)備上收集到的信息存入數(shù)據(jù)庫。

考慮到用戶的流量問題，該組件設(shè)計為僅在WiFi環(huán)境下工作。當(dāng)前的連接類型可以通過CoreServices框架進(jìn)行獲取。

3 測試及部分測試結(jié)果分析

本部分對日志子系統(tǒng)進(jìn)行了真機測試。首先，通過另一個叫做Crasher的程序產(chǎn)生錯誤來檢測日志子系統(tǒng)的功能是否正常。接下來，對于測試中設(shè)備產(chǎn)生的典型數(shù)據(jù)進(jìn)行了分析。

3.1 測試

為了驗證日志子系統(tǒng)，本文另外制作了一個Crasher應(yīng)用，該應(yīng)用可以重現(xiàn)一些常見的錯誤，例如livelock，deadlock，內(nèi)存訪問越界，內(nèi)存溢出等。

由于Crasher程序無法產(chǎn)生系統(tǒng)級別的錯誤，如導(dǎo)致自動重啟或系統(tǒng)假死的錯誤。因此這些錯誤只能依靠人工來完成，當(dāng)測試人員使用系統(tǒng)時發(fā)生了上述狀況后，可以通過檢查數(shù)據(jù)庫中的信息來判斷該錯誤是否被正常捕獲。

3.2 部分測試數(shù)據(jù)分析

由于沒有足夠的數(shù)據(jù)來達(dá)到顯著性差異，因此本文中人工分析了一些日志數(shù)據(jù)以提升對iOS系統(tǒng)工作原理的理解，并借此來探知該操作系統(tǒng)可能會出現(xiàn)的問題。

第一，在分析了系統(tǒng)中出現(xiàn)了很高的內(nèi)存占用時產(chǎn)生的日志后，可以發(fā)現(xiàn)iOS會優(yōu)先把資源分配給用戶正在使用的應(yīng)用，例如在內(nèi)存管理方面會將盡可能多的內(nèi)存分配給該活躍應(yīng)用。如果應(yīng)用需要的內(nèi)存超出了當(dāng)前空閑內(nèi)存，系統(tǒng)將會停止其他進(jìn)程以釋放資源。通過這里的觀察表明，iOS系統(tǒng)在釋放內(nèi)存時無法很好的預(yù)測哪些進(jìn)程是用戶可能會經(jīng)常切換到。表1展示了數(shù)據(jù)收集期間部分iOS 6系統(tǒng)原生應(yīng)用被強制停止的次數(shù)。此外，從實驗中可以發(fā)現(xiàn)強制退出事件的發(fā)生與設(shè)備的使用頻率緊密相關(guān)。例如表1中，強制退出事件發(fā)生最多的應(yīng)用之一就是Safari Internet Browser，它也是最常用的一個應(yīng)用。當(dāng)用戶運行內(nèi)存消耗較大的應(yīng)用后再切換到其他后臺程序時往往需要一段的響應(yīng)時間，即使該應(yīng)用經(jīng)常被用到。在這段響應(yīng)時間里其實系統(tǒng)重新啟動了這些應(yīng)用。盡管大多數(shù)的應(yīng)用重啟動時間非常短，但在測試中我們發(fā)現(xiàn)App Store應(yīng)用往往需要1 min時間完成重啟動。原因是由于App Store每次啟動時需要從遠(yuǎn)程服務(wù)器下載商店數(shù)據(jù)。從這個角度上來看，iOS的強制退出機制仍有進(jìn)一步完善的空間。

表1 部分iOS 6系統(tǒng)原生應(yīng)用被強制停止的次數(shù)統(tǒng)計

第二，關(guān)于系統(tǒng)自動重啟的日志信息，測試中發(fā)現(xiàn)了一例特殊的數(shù)據(jù)信息。當(dāng)一個應(yīng)用掛起一段時間后，系統(tǒng)會嘗試重啟該應(yīng)用。然而，重啟后該應(yīng)用立刻再次進(jìn)入掛起狀態(tài)。結(jié)果系統(tǒng)進(jìn)了不斷重啟該應(yīng)用的循環(huán)。一段時間后，該事件就會被iOS watchdog捕獲。然而，watchdog終止該應(yīng)用不斷重啟的方式是終止了所有的后臺第三方應(yīng)用，并重啟了application loader。接下來，系統(tǒng)會嘗試再次啟動之前的應(yīng)用，但是上述的情況再次發(fā)生了。這時系統(tǒng)重啟了設(shè)備。值得注意的是，在本文的日志子系統(tǒng)中捕獲的一些事件在系統(tǒng)自身提供的日志中被遺漏了。

從對日志子系統(tǒng)捕獲數(shù)據(jù)的分析可以得出如下結(jié)論：面對惡意應(yīng)用或恢復(fù)機制設(shè)計有缺陷的應(yīng)用時很容易導(dǎo)致iOS系統(tǒng)發(fā)生錯誤。

4 總結(jié)及未來的工作

本文設(shè)計完成了一個iOS平臺上的錯誤日志子系統(tǒng)。該系統(tǒng)可以收集應(yīng)用崩潰、掛起、系統(tǒng)假死和系統(tǒng)自動重啟等事件。真機測試展示了該系統(tǒng)在iOS可靠性分析上的用途。測試中可以發(fā)現(xiàn)iOS系統(tǒng)為了滿足前臺應(yīng)用程序的內(nèi)存需求有可能會終止用戶經(jīng)常使用到的程序，某些極端情況下還會導(dǎo)致系統(tǒng)重啟。此外本文在測試中發(fā)現(xiàn)惡意程序和設(shè)計有缺陷的程序很容易導(dǎo)致整個系統(tǒng)發(fā)生嚴(yán)重錯誤。這些錯誤有可能會對用戶體驗及重要程序的運行產(chǎn)生較大的負(fù)面影響。

未來的工作可以進(jìn)一步對大量的iOS設(shè)備進(jìn)行錯誤數(shù)據(jù)的收集和分析，用統(tǒng)計學(xué)上的方法對數(shù)據(jù)進(jìn)行處理，還可以同Android設(shè)備的錯誤信息進(jìn)行對比。另外在收集大量數(shù)據(jù)后也可以針對性的增強該日志系統(tǒng)的擴展性和可靠性。

參考文獻(xiàn)

[1] Eggleston P. iPhone如何為變革聯(lián)網(wǎng)醫(yī)療器械推波助瀾[J]. 世界電子元器件，2012(1):55-57.

[2] Ascione P, Cinque M, Cotroneo D. Automated logging of mobile phones failures data. In Ninth IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing, 2006[C]. IEEE Press, 2006.

[3] Cinque M, Cotroneo D, Kalbarczyk Z, et al. How Do Mobile Phones Fail? A Failure Data Analysis of Symbian OS Smart Phones. In Proc. of the 2007 Int. Conf. on Dependable Systems and Networks (DSN’07), 2007 [C]. DSN ’07,2007.

[4] 康海燕, 陳然, 苑曉姣, 等. 基于Android防火墻日志系統(tǒng)的研究與實現(xiàn)[J]. 北京信息科技大學(xué)學(xué)報(自然科學(xué)版), 2012(4):7-11.

[5] 金福生, 李樸之. iOS應(yīng)用程序開發(fā)方法與實踐[M]. 北京:人民郵電出版社, 2012.

創(chuàng)新思路嚴(yán)把關(guān)，扎實鑄就生命線——我院研究所圓滿完成100 Gbit/s OTN設(shè)備網(wǎng)管接口測試

受中國移動通信集團公司網(wǎng)絡(luò)部委托，中國移動通信集團設(shè)計院研究所網(wǎng)管項目組于2013年11月29日啟動100 Gbit/s OTN設(shè)備網(wǎng)管與接口測試項目。共歷時20余天，奔赴武漢、深圳、成都、北京等4個城市，輾轉(zhuǎn)華為、中興、上海貝爾和烽火等4家公司，對OMC功能、北向接口進(jìn)行了全量測試，充分了解了業(yè)內(nèi)各主流設(shè)備商100 Gbit/s OTN設(shè)備網(wǎng)管技術(shù)研發(fā)現(xiàn)狀，為集團公司集采工作提供了寶貴的決策參考。

此次測試任務(wù)，設(shè)計院研究所領(lǐng)導(dǎo)高度重視，網(wǎng)管項目組積極籌劃，嚴(yán)格按照“對集團負(fù)責(zé)，對行業(yè)負(fù)責(zé)”的原則，創(chuàng)新性地取得了三個“提高”：一是增加了全量的北向接口上報字段與OMC數(shù)據(jù)一致性的核查，提高了北向接口數(shù)據(jù)的完整性、準(zhǔn)確性和一致性。二是改變以往的傳統(tǒng)做法，此次測試遍歷所有不同型號的網(wǎng)元，雖然測試工作量成倍增加，但卻提高了測試結(jié)果的全面性和客觀性。三是為滿足省公司運維的迫切需求，根據(jù)網(wǎng)絡(luò)部的要求，在測試前一天臨時更改測試計劃，追加5條新的OMC功能，極大地提高了網(wǎng)管項目組的應(yīng)急攻關(guān)能力。最終，經(jīng)過項目組人員的共同努力，本次測試完成OMC功能項共計94個，北向接口功能項128個，屬性項642個，系統(tǒng)全面、準(zhǔn)確客觀地評估了廠商網(wǎng)管系統(tǒng)及接口在配置管理、性能管理、故障管理和安全管理等多方面的管理能力。

100 Gbit/s OTN設(shè)備作為骨干網(wǎng)主要設(shè)備，其重要性不言而喻，我院研究所網(wǎng)管項目組力爭通過嚴(yán)格深入的網(wǎng)管測試，從而推動和改進(jìn)100 Gbit/s OTN網(wǎng)絡(luò)、產(chǎn)品、管理、服務(wù)及業(yè)務(wù)的品質(zhì)，更好的肩負(fù)起追求卓越、爭做行業(yè)先鋒的使命，繼續(xù)發(fā)揮行業(yè)優(yōu)勢成為OTN產(chǎn)業(yè)發(fā)展的中流砥柱。

Design of an iOS-based log system

YANG Yang1,2, ZHU Xiao-min1,2
(1 State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China; 2 EBUPT Information Technology Co., Ltd., Beijing 100191, China)

The increasing complexity of smart phones makes developers stricter in the dependability of apps and system. This paper proposes the design and implementation of a logger to collect relevant failure data. The logger can collect meaningful failure data and to upload the data to the remote server for further analysis and research.

failure collection; smart phones; iOS log system

TN929.5

A

1008-5599（2014）01-0079-05

2013-12-05

國家973計劃項目（No. 2013CB329102）；國家自然科學(xué)基金資助項目（No. 61372120，61271019, 61101119, 61121001, 61072057, 60902051）；長江學(xué)者和創(chuàng)新團隊發(fā)展計劃資助（No. IRT1049）；北京市支持中央高校共建項目——青年英才計劃。