一種基于iOS的錯誤日志系統設計方案

楊揚，朱曉民

（1 北京郵電大學網絡與交換技術國家重點實驗室，北京 100876；2 東信北郵信息技術有限公司，北京 100191）

一種基于iOS的錯誤日志系統設計方案

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

（1 北京郵電大學網絡與交換技術國家重點實驗室，北京 100876；2 東信北郵信息技術有限公司，北京 100191）

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

錯誤收集；智能手機； iOS日志系統

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

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

基于以上原因，本文基于蘋果公司開發的iOS，設計和實現了一個錯誤日志系統，實現自動從手機中收集錯誤數據并匯總于遠程服務器以供進一步的研究分析。

1 背景及相關工作

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

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

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

2 日志系統的設計

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

圖1 系統設計方案

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

當應用轉換為后臺運行后，日志子系統中的組件就會開始同操作系統進行交互，收集信息并存儲到本地數據庫中。在實現階段將采用iOS內置的應用框架庫完成系統。

針對iOS系統對第三方應用所施加的限制，日志子系統中還需要添加生命周期模塊及數據傳輸模塊，其中生命周期模塊可以讓日志系統無限期的在后臺運行，而數據傳輸模塊則在有網絡的時候將本地數據庫中的數據發送到遠程服務器上以便進行進一步的分析。各模塊的設計如下列小節所示。

2.1 系統數據及狀態監測模塊

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

2.2 心跳模塊

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

2.3 Tracker模塊

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

當監測到崩潰或掛起事件后，該模塊會將信息保存在本地的數據庫中。這些信息會同系統數據及狀態監測模塊收集到的信息一起結合起來分析，以便找出崩潰或掛起事件同系統狀態之間的聯系。

2.4 生命周期模塊

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

2.5 數據傳輸模塊

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

考慮到用戶的流量問題，該組件設計為僅在WiFi環境下工作。當前的連接類型可以通過CoreServices框架進行獲取。

3 測試及部分測試結果分析

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

3.1 測試

為了驗證日志子系統，本文另外制作了一個Crasher應用，該應用可以重現一些常見的錯誤，例如livelock，deadlock，內存訪問越界，內存溢出等。

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

3.2 部分測試數據分析

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

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

表1 部分iOS 6系統原生應用被強制停止的次數統計

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

從對日志子系統捕獲數據的分析可以得出如下結論：面對惡意應用或恢復機制設計有缺陷的應用時很容易導致iOS系統發生錯誤。

4 總結及未來的工作

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

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

參考文獻

[1] Eggleston P. iPhone如何為變革聯網醫療器械推波助瀾[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防火墻日志系統的研究與實現[J]. 北京信息科技大學學報(自然科學版), 2012(4):7-11.

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

創新思路嚴把關，扎實鑄就生命線——我院研究所圓滿完成100 Gbit/s OTN設備網管接口測試

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

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

100 Gbit/s OTN設備作為骨干網主要設備，其重要性不言而喻，我院研究所網管項目組力爭通過嚴格深入的網管測試，從而推動和改進100 Gbit/s OTN網絡、產品、管理、服務及業務的品質，更好的肩負起追求卓越、爭做行業先鋒的使命，繼續發揮行業優勢成為OTN產業發展的中流砥柱。

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）；國家自然科學基金資助項目（No. 61372120，61271019, 61101119, 61121001, 61072057, 60902051）；長江學者和創新團隊發展計劃資助（No. IRT1049）；北京市支持中央高校共建項目——青年英才計劃。