一种基于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）；北京市支持中央高校共建项目——青年英才计划。