The Forbidden Zone，天鹅绒摄影机文/ 程月旻 Dora Cheng中英文双语写作者，剧场工作者。毕业于上海戏剧学院戏剧文学系及伦敦艺术大学温布尔登学院视觉艺术系，现居柏林。以文字为支点，展开跨界合作，作品涵盖剧本、小说、装置、摄影，多探索人的精神世界与日常生活之间的裂变。---------------------------------------------------------------《禁区》（The Forbidden Zone) 导演：Katie Mitchell文本：Duncan Macmillan演出地点：Berlin Schaubuehne（柏林邵宾纳剧院）演出时间：2014年10月Katrina Jane Mitchell，英国导演，生于1964年，以多媒体剧场著称，作品题材广泛，常与欧洲主流剧场合作，她曾应邀为伦敦著名博物馆维多利亚和阿尔伯特制作了大型多屏幕影像装置，被称为“英国剧场界的作者导演”。灯亮。平视——透过截断的右侧车厢侧面，远远地，一个正装女人正襟危坐。抬头——她被正面特写在投影布上，戴着蓝色礼帽，抿着猩红嘴唇，肩膀随列车左右震荡，指尖擒住吊坠，平视的眼睛心事重重。列车沿途的一连串黄色光晕从她的正面和背面飘过。平视——三十秒钟后，一身黑衣的摄影师带着组装完成的摄影机和三脚架出现在车厢右侧的轨道上——事实上，这是一列纹丝不动的舞台列车。他快跑到位，站定，迅速打开三脚架，拍摄。抬头——透过一个穿着旧军服的士兵的侧影，我们的目光再次和女人相遇。一直抬头——不到十秒钟之后，透过投影布，女人的手翻动膝盖上的报纸，清晰可见。她的手提包敞开口，露出一个装有纳粹勋章的丝绒小盒（不得不说，翻动这份特制的硬邦邦的报纸，可没有翻动一般报纸“哗嚓”的焦虑感。）是的，我们可以简单的概括为：1949年的芝加哥地铁车厢里，有一男一女两位乘客。然而，实际上，信息喷薄而出：在两分钟左右的时间段里，由于舞台上的列车，我们意识到剧场的空间；由于大屏幕上的投影，导演/作者的视觉空间闪现；摄影师的身体及其机器有意识的加入，一方面，通过演员和技术人员在舞台上的同时出现，瞬间再定义剧场空间的成份；另一方面，实况转播，暗喻着导演/作者在某中程度上放弃了对剧场空间的绝对主导，和观众比肩抗争未知的剧场时间。而后，时间难分先后，事件难分主次，几乎同时，我们意识到几个并行的事件：在剧场空间，演员纹丝不动，导演/作者通过不同机位的现场切换（不同于电影的后期剪接），展现戏剧情境；几个不同机位，意味着几位摄影师及其机器的同时存在，此时，多维度的，时而重叠时而隐没的四重空间，造成时而平行时而交错的四度时间线：导演/作者的时间，大屏幕的时间，摄影师的时间，演员的时间。我们并没有迷失在高强度的数码海洋之中，The Forbidden Zone的工作人员也没有：他们在列车左上角安装了监控电视。我们恍然大悟：包括观众在内的剧场空间，再度被划分为几个部分的时空；导演/作者预支给我们的主导权，以我们的被动加入为代价；我们的私人时空和剧场时空，在浑然不觉之中，重叠、交互、前行。八月在萨尔茨堡(Salzburg)戏剧节首演，十月在柏林邵宾纳剧院（Schaubuehne）持续上演的多媒体戏剧The Forbidden Zone对舞台艺术和影像艺术进行了革命性的结合。这场演出让我们感到一种前所未有的私人性。我们坐在一个椅子上，一群人中，一片黑暗下，一些机油味儿里，可以选择抬头凝视占据整个屏幕的放在胸前的枪口，也可以选择观察匆匆纵贯舞台的摄影师的一头乱发，当然，也可以远远地看见一个经典画面：花园，池塘，一位举枪自尽的女人，和她的枪口对准的，哽在胸口的，人类之间的自相残杀；我们的目光也会扫过她侧面的，一个摄影师的黑色的弓起的脊背。这种极度自由的空间时间体验，瞬间让我们感到一种置身广阔宇宙中的渺小胜利：我们的时间可以由自己支配。我们产生幻觉，以为自己甚至可以闭上眼睛，拒绝私人和机器大生产的信息交换。此时不得不提到：二十世纪电影技术产生之后，曾是戏剧舞台的孩子，而后是伴侣，接着是敌人。二十世纪中期，机器大生产时代到来之后，大量复制的录像产品在拓宽了戏剧的传播范围之余，同时刷新了观众对于时间和空间的感官体验。在双重时空的潜移默化之中，我们抵达了二十一世纪——一个机械大生产影像的时代。1935年，瓦尔特·本雅明（Walter Benjamin）在《机械复制时代的艺术作品》（The Art Work of the Machine Replication）里提到，“当代大众有一种欲望，想使作品在空间上和人情味上同自己更近。”到今天仍旧有理。从时空的角度上说，可远观而不可亵玩的舞台艺术，有时候仍旧被看做是有共同价值的宗教传说以及历史经验的重现——这是扑面而来的人肉味儿。然而，请问：到底什么是人情味儿呢？除了人类固有的社会关系，怎样的时空关系，对当下的我们来说，是富含情感的？1970年代开始，不胜枚举的实验剧场探讨着人和摄影机之间的关系。美国视觉艺术家罗伯特·威尔逊（Robert Wilson）把整面色彩缤纷的电视屏幕墙加入现代歌剧；美国剧团伍斯特小组（The Wooster Group）的表演中，演员和电视屏幕，投影，布景以及麦克风常常共享舞台；英国原型剧团（Proto-type Theater）尝试将视觉艺术作为舞台的主体，演员闯入影像。2010年爱丁堡国际艺术节（Edinburgh International Festival），智利电影剧团（Teatro Cinema）把两个电影屏幕之间的位置作为喜剧舞台，却让观众彻底陷入了泛着蓝光的视觉笑话之中。摄影机总是冷冰冰。直到观看以凯蒂·米歇尔（Katie Mitchell）的作品The Forbidden zone，它才被我冠以一个热烘烘的名字，“多媒体演员”。八十分钟里，舞台上出现了九位演员，至少十八位技术人员，舞台摄像机，四台监控器，一块大屏幕；戏剧文本直接摘自日记及女权主义学者：两次世界大战，一枚纳粹勋章，一具裸体，一瓶毒药，一把手枪，一只戒指导演携手观众，二度阐释了多媒体剧场的意义：来自导演/作者的有序爆发的时空信息，引导观众逐渐明晰个人意志；在此过程中，观众得到了相对进化的观演平等。这种关系是自觉的，温柔的，可爱的；它创造了一种高于人肉味儿的智慧：透过天鹅绒般的摄影机，内视镜般深入时间内部，捏出那根深入骨髓的陈年小钢刺。然而，作为编剧的我感到了另一重震撼：在哲学性四溅的同时，多媒体剧场的文学性，真的消亡了吗？两侧视频
　文章为作者独立观点，不代表微头条立场
的最新文章
Lucinda Childs认为「极简主义是，所有的事情都回到了最初始的状态，所有的事情都可以被精简到最简单。」
新浪潮戏剧《平行宇宙爱情演绎法》（Constellations）。编剧：尼克.佩恩（Nick Payne）[英]，翻译/导演：王翀。
点击最左下角的“阅读原文”翻阅前篇以及更前篇。
点击最左下角的“阅读原文”翻阅前篇、更前篇、更更前篇。
本期于善禄老师开始说明他的十六字箴言：「史论析较释评判测」、「文史哲艺政社经文」。
点击最左下角的“阅读原文”翻阅前篇以及更前篇。
对于八五后导演藤田贵大及其团队来说，与其说是严肃的创作，不如说是一场严肃的玩乐。
去年六月底，台湾小剧场学校举办一系列四场的「共学讲堂：剧场工作者的深度思考」，此为其中一讲「表演艺术评论，为表演艺术发展写下备忘的人」座谈纪录。
本期于善禄老师开始说明他的十六字箴言：「史论析较释评判测」、「文史哲艺政社经文」。
用「生命如同一首幻想曲」做为主题，用音乐(王榆钧音乐会)、演出(初生、长大、消失)、视觉(装置作品)，对孩子说一说生命如诗般的旅程。
去年六月底，台湾小剧场学校举办一系列四场的「共学讲堂：剧场工作者的深度思考」，此为其中一讲「表演艺术评论，为表演艺术发展写下备忘的人」座谈纪录。
十年之内，你何时出现？一千个节目中，哪个有你参与的身影？从牯岭街小剧场出发，你要去哪里？或者，反身之后，你想做些什么？
每席收材料费30元，购票请点击“阅读原文”。
摄影：王昊宸。
国际青年戏剧摇篮计划 Q&A[三星堆丝绸之路戏剧季] 国际青年戏剧摇篮计划详情，请点击最左下角的“阅读原文”
国际青年戏剧摇篮计划 Q&A[三星堆丝绸之路戏剧季] 国际青年戏剧摇篮计划详情，请点击最左下角的“阅读原文”
新青年独立剧评行动自发布之后，报名踊跃，反响热烈。同时，我们也收到投稿人反馈的各种问题，在此我们统一解答如下
新青年独立剧评行动自发布之后，报名踊跃，反响热烈。同时，我们也收到投稿人反馈的各种问题，在此我们统一解答如下
用剧场接近马华文学，在台北接近马来西亚，为的不是重唤乡愁，而是把剧场变成「地方」，在这里，不将任何物理或心理的疆域划分此方或彼方，无需将任何的视线投向单一的他方，因为一切可以繁复共存。
儿童剧《出发！B612星球！》测评场招募招募信息测评时间：日 14:00测评地点：1933微
曲终人散，我得到了一盘全程录音的磁带，而她则保留了7个本属于我个人的秘密，当然，在这个时空当中，我们共同获得了宁静而真诚的体验。
犹太裔青年女导演Yeal Ronen及其团队所创作的戏剧“Third Gerenation”并不向观众灌输某个种族／民族／文化的政治立场；相反，它以铺开的视角，提供给观众一些截然不同的人生经验，从而引发自省。
<img src="http://img01./net/a/04/link?appid=&w=210&h=105&url=/mmbiz/d4OKpeKpsfB2GMQDV3toawjZ3IzhQXQmL9pibDbtbcyNqGyMTte9mMLOz8kU9DWEkkMDHg9YE26gxdh2eVLGlGQ/0?wx_fmt=jpeg"
alt="《看戏笔记之》遭撕逼，让我想起了些什么.." title="《看戏笔记之》遭撕逼，让我想起了些什么.." rel="nofollow"
width="210" height="105">
编者按：转发下文并非是支持作者的观点。只是深感如今直白吐露观戏后感的不易，以及个体订阅号在戏剧环境中弱势得孤
六个迥异的短作品，或环境、或舞蹈、或肢体、或诗歌、或舞踏
连缀成来自更高维度的“时空碎块”
观众或可偶尔踏入其中，看到两个世界之间难以捉摸的边界
在倒向美誉的演后谈中，一位德国中年女性观众勇敢地表达了她截然不同的观感，提出质疑：“我不明白一群普通人在台上乱晃，没有技巧，为什么算是一个集体……我不明白，这场演出有什么意义。我常常看戏，有时候真不理解，这种演出为什么需要我这个观众。”
他们的技术可被“占为己有”，演员却不能——由《信任》所引发的剧场生态焦虑（原载于《北京日报》
超文本剧场向区别于真实空间的赛博空间转移，观众与演员之间的面对面交流被在线访问取代，进而衍生出虚拟排练、IRC（Internet Relay Chat）剧场等概念，大规模并发访问的“电子广场静坐”也可被视为在线发生的社会剧场事件。
举办了第五年的「亚洲剧力无边界」一如既往为观众带来亚洲各地出色的小剧团演出。交流会每年都为亚洲各地的小剧场爱好者提供展现及交流的平台，亦令更多观众有机会欣赏小剧场演出，以更深入了解当前亚洲的小剧场文化。
《台北诗人》取材自台湾诗人王添源的诗作及生平，透过王添源生前留下的日记手稿与诗集，重新走入一位诗人的世界，写下时间终止前，生命中最后的奇幻流离。
前戏4play 招募：占领电话亭系列之《对视》Eye To Eye , Occupy Telephone B
昨日发布的版本标题出错，向此文作者抱歉！
艺幕文化这个暑假将在上海举行第二届全新升级的国际音乐剧夏令营啦！六位欧美一线音乐剧教育专家，汇聚于上海市中心
《亚马逊之光》体验式剧评——追光作者/ 程月旻 Dora Cheng中英文双语写作者，剧场工作者。毕业于上海
舞者小珂和视觉艺术家子涵，创造性地结合了行为艺术、装置艺术、环境剧场、社会剧场和舞蹈剧场等多种形式，形式不拘、思维审慎地，向德国剧场界展现了两位中国青年艺术家毫不逊色于德国同龄创作者的，“正在发生”的前卫戏剧观念。
请戴上耳机或是在安静的房间里使用音箱收听，剧评由 程月旻 Dora Cheng 撰文并在柏林特别录制。作为一个尝试，评论以音频为媒介会如何？有体验感？环境式？或者评论者本身的表演性？我们一起感受下吧～感谢Dora！
BLACK OUT / 黑场演出时间：6月17日丨6月18日 第一场：19:00 第二场：20:30演出地点
把经典电影搬上舞台，从来都是一件任重道远且毁誉参半的事。顺应着2015年纪念德国新电影代表人物法斯宾德诞辰七十周年的风向，“为什么R先生疯狂杀人？”凭着对原作独树一帜的读解和严丝合缝的再创作，在戏剧圈内博得满堂彩。
勅使川原三郎的舞者，双脚贴地，重心住维持在腹部，用细微的身体关节流动，及时而缓慢轻飘、时而快如闪电的手臂及双脚移动，来完成舞蹈动作，而这就是他说过的：「与空间对话，与空气共舞」。
《亚马逊之光》体验式剧评——追光观看纯文字剧评，请点击文章左下角的“阅读原文”。请戴上耳机或是在安静的房间里
《亚马逊之光》体验式剧评——追光作者/ 程月旻 Dora Cheng中英文双语写作者，剧场工作者。毕业于上海
请戴上耳机或是在安静的房间里使用音箱收听，剧评由 程月旻 Dora Cheng 撰文并在柏林特别录制。作为一个尝试，评论以音频为媒介会如何？有体验感？环境式？或者评论者本身的表演性？我们一起感受下吧～感谢Dora！
高俊耀编导演的《饕餮》，改编自香港女作家黄碧云作品《七宗罪》的其中一项人性之罪，这次经过剧本的修编，在牿岭街小剧场演出，票房很快就满了，我想基本上应该可以反映这几年高俊耀在编、导、演创作质量上的可圈可点。
非常感谢 程月旻 Dora Cheng 提供的如此精彩的第一手信息与评述，尤其是她长期以来对 [疯剧场] 的支持和对独立评论的坚持。握手！
[疯剧场]专为戏剧评论及理论性文章的平台。除发布[疯子出品]文章外，获海外多家戏剧网站及多位艺评人授权。在这个不容易严肃的时代，在这个不适合严肃阅读的手机端，坚持做严肃的自媒体刊物。
[疯剧场]专为戏剧评论及理论性文章的平台。除发布[疯子出品]文章外，获海外多家戏剧网站及多位艺评人授权。在这个不容易严肃的时代，在这个不适合严肃阅读的手机端，坚持做严肃的自媒体刊物。本文作者是
, 他是一名独立iOS开发者。
作为一名应用开发者，你是否有过如下经历?
为确保你的应用正确无误，在将其提交到应用商店之前，你必定进行了大量的测试工作。它在你的设备上也运行得很好，但是，上了应用商店后，还是有用户抱怨会闪退 !
如果你跟我一样是个完美主义者，你肯定想将应用做到尽善尽美。于是你打开代码准备修复闪退的问题……但是，从何处着手呢？
这时iOS崩溃日志派上用场了。在大多数情况下，你能从中了解到关于闪退的详尽、有用的信息。
通过本教程，你将学习到一些常见的崩溃日志案例，以及如何从开发设备和iTunes Connect上获取崩溃日志文件。你还将学习到符号化（ symbolication）,从日志追踪到代码 。你还将学习调试一个在待定情况下会闪退的应用。
让我们开始动手吧!
什么是崩溃日志，从哪里能得它?
iOS设备上的应用闪退时，操作系统会生成一个崩溃报告，也叫崩溃日志，保存在设备上。
崩溃日志上有很多有用的信息，包括应用是什么情况下闪退的。通常，上面有每个正在执行线程的完整堆栈跟踪信息，所以你能从中了解到闪退发生时各线程都在做什么，并分辨出闪退发生在哪个线程上。
有几种方法可以从设备上获取崩溃日志。
设备与电脑上的iTunes Store同步后，会将崩溃日志保存在电脑上。根据电脑操作系统的不同，崩溃日志将保存在以下位置:
~/Library/Logs/CrashReporter/MobileDevice/
Windows XP:
C:Documents and Settings&USERNAME&Application DataApple ComputerLogsCrashReporterMobileDevice&DEVICE_NAME&
Windows Vista or 7:
C:Users&USERNAME&AppDataRoamingApple ComputerLogsCrashReporterMobileDevice&DEVICE_NAME&
当用户抱怨闪退时，你可以要求他让设备与iTunes同步，并根据操作系统的不同，到上述位置把崩溃日志下载下来，然后通过电子邮件发送给你。
你必需尽量获取用户设备生成的所有崩溃日志。因为崩溃日志越多，就越容易诊断问题所在!
另外，如果你装了Xcode，也能很容易通过Xcode从你的设备上获得崩溃日志。将iOS设备连接到电脑上，然后打开Xcode。从菜单栏上选择
菜单, 然后选择
Organizer (快捷方式是 Shift-CMD-2).
在 Organizer 窗口上, 选中
Devices 标签栏. 在左侧的导航面板上，选中
Device Logs, 如下图所示:
看看上图，左侧有好几个 Device Logs 菜单项.
LIBRARY 下面的Device Logs是你所有设备（曾经连接到Xcode的）的日志 。每个设备下面的 Device Logs 是对应设备的日志。
应用提交到App Store后，你也能从
获取到用户的崩溃日志. 登录到 iTunes Connect 上, 选择
Manage Your Applications, 点击相应的应用, 点击应用图标下面的
View Details 按钮, 然后点击右栏Links部分的
Crash Reports 。
如果没有崩溃日志，试试点击
Refresh 按钮刷新一下。如果你的应用还卖得不多，或者刚上架不久，iTunes Connect账号上也可能还没有任何崩溃日志。
如果iTunes Connect上有崩溃日志，你将看到如下图:
有时，尽管有用户报告闪退，你仍然看不到崩溃报告。这时，最好让用户直接把崩溃报告发送给你。
什么情况下会产生崩溃日志?
两种主要情况会产生崩溃日志:
应用违反操作系统规则。
应用中有Bug。
违反iOS规则包括在启动、恢复、挂起、退出时watchdog超时、用户强制退出和低内存终止。让我们详细了解一下吧。
Watchdog 超时机制
从iOS 4.x开始，退出应用时，应用不会立即终止，而是退到后台。
但是，如果你的应用响应不够快，操作系统有可能会终止你的应用，并产生一个崩溃日志。这些事件与下列UIApplicationDelegate方法相对应:
application:didFinishLaunchingWithOptions:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationDidBecomeActive:
applicationWillTerminate:
上面所有这些方法，应用只有有限的时间去完成处理。如果花费时间太长，操作系统将终止应用。
注意: 如果你没有把需要花费时间比较长的操作(如网络访问）放在后台线程上就很容易发生这种情况。关于如果避免这种情况的信息，请参考我们的另外两篇教程：
Grand Central Dispatch 和
NSOperations。
用户强制退出
iOS 4.x开始支持多任务。如果应用阻塞界面并停止响应， 用户可以通过在主屏幕上双击Home按钮来终止应用。此时，操作应用将生成一个崩溃日志。
注意: 双击Home按钮后，你将看到运行过的所有应用。那些应用不一定是正在运行，也不一定是被挂起。
通常，用户点击Home按钮时，应用将在后台保留约10分钟，然后操作系统自动将其终止。 所以双击Home按钮显示的应用列表只是表明那是一系列过去打开过的应用。删除那些应用的图标不会产生任何崩溃日志。
低内存终止
子类化UIViewController时,你或许已经注意到
didReceiveMemoryWarning方法。
在前台运行的应用拥有访问和使用内存的最高优化级。然而，这并不意味着该应用能使用设备的所有可用内存 ——每个应用只能使用一部分可用内存。
当内存使用达到一定程度时，操作系统将发出一个
UIApplicationDidReceiveMemoryWarningNotification 通知。同时,调用
didReceiveMemoryWarning 方法。
此时，为了让应用继续正常运行，操作系统开始终止在后台的其他应用以释放一些内存。所有后台应用被终止后，如果你的应用还需要更多内存，操作系统会将你的应用也终止掉，并产生一个崩溃日志。而在这种情况下被终止的后台应用，不会产生崩溃日志。
注意: 根据
, Xcode不会自动添加低内存日志。你必需手动获取日志。 然而，根据我的个人经验，使用 Xcode 4.5.2, 低内存日志也会自动导入，只是”Process”和”Type”属性都被标为Unknown(未知)。
另外，值得一提的是在极短时间内分配一大块内存将给系统内存带来巨大负担。这样，也会产生内存警告的通知。
应用中有Bug
如你所想，大多数闪退都是由于应用中有Bug，因此大多数崩溃日志的产生都是因为应用中的Bug。Bug的种类的有很多。
在本教程的后半部分，你将通过调试一个会产生崩溃日志的含有Bug的应用，学习如何找到问题所在并进行修复!
崩溃日志的实例
让我们看看一个崩溃日志的实例，以使你在处理一些实际问题之前心里有谱。
事不宜迟，见见你的新朋友吧:
// 1: 进程信息
Incident Identifier: 30E46451-53FD-7FC11AD05F
CrashReporter Key:
5af867f6eec76afee451bf9ae5f31
Hardware Model:
Rage Masters [4155]
/var/mobile/Applications/AEF-4CEB-94B6-FE158D885014/Rage Masters.app/Rage Masters
Identifier:
Rage Masters
Code Type:
ARM (Native)
Parent Process:
launchd [1]
// 2: 基本信息
Date/Time:
21:39:06.967 -0400
OS Version:
iOS 6.0 (10A403)
Report Version:
// 3: 异常
Exception Type:
Exception Codes: 0xbadf00d
Highlighted Thread:
// 4: 线程回溯
Thread 0 name:
Dispatch queue: com.apple.main-thread
libsystem_kernel.dylib
0x327f2eb4 mach_msg_trap + 20
libsystem_kernel.dylib
0x327f3048 mach_msg + 36
CoreFoundation
0x36bd4040 __CFRunLoopServiceMachPort + 124
CoreFoundation
0x36bd2d9e __CFRunLoopRun + 878
CoreFoundation
0x36b45eb8 CFRunLoopRunSpecific + 352
CoreFoundation
0x36b45d44 CFRunLoopRunInMode + 100
0x32ac343e CFURLConnectionSendSynchronousRequest + 330
Foundation
0x346e69ba +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 242
Rage Masters
0x000d00 + 8262
libsystem_kernel.dylib
0x32803d98 __workq_kernreturn + 8
libsystem_c.dylib
0x3a987cf6 _pthread_workq_return + 14
libsystem_c.dylib
0x3a987a12 _pthread_wqthread + 362
libsystem_c.dylib
0x3a9878a0 start_wqthread + 4
// 5: 线程状态
Thread 0 crashed with ARM Thread State (32-bit):
r3: 0x39529fc8
r4: 0xffffffff
r5: 0x2fd7d301
r6: 0x2fd7d300
r7: 0x2fd7d9d0
r8: 0x2fd7d330
r9: 0x3adbf8a8
r10: 0x2fd7d308
sp: 0x2fd7d2ec
lr: 0x001bdb25
// 6: 二进制映像
Binary Images:
0xd7fff +Rage Masters armv7
/var/mobile/Applications/AEF-4CEB-94B6-FE158D885014/Rage Masters.app/Rage Masters
0x2fe41000 - 0x2fe61fff
dyld armv7
/usr/lib/dyld
0x327f2000 - 0x32808fff
libsystem_kernel.dylib armv7
/usr/lib/system/libsystem_kernel.dylib
0x328a8000 - 0x328bdfff
libresolv.9.dylib armv7
/usr/lib/libresolv.9.dylib
0x32a70000 - 0x32b35fff
CFNetwork armv7
/System/Library/Frameworks/CFNetwork.framework/CFNetwork
0x32b7a000 - 0x32cc3fff
libicucore.A.dylib armv7
/usr/lib/libicucore.A.dylib
0x32cc4000 - 0x32cc5fff
CoreSurface armv7
/System/Library/PrivateFrameworks/CoreSurface.framework/CoreSurface
0x32f65000 - 0x32f8afff
OpenCL armv7
/System/Library/PrivateFrameworks/OpenCL.framework/OpenCL
这报告看起来像天书。:) 我们分几部分来解读吧:
(1) 进程信息
第一部分是闪退进程的相关信息。
Incident Identifier是崩溃报告的唯一标识符。
CrashReporter Key 是与设备标识相对应的唯一键值。虽然它不是真正的设备标识符，但也是一个非常有用的情报:如果你看到100个崩溃日志的CrashReporter Key值都是相同的，或者只有少数几个不同的CrashReport值，说明这不是一个普遍的问题，只发生在一个或少数几个设备上。
Hardware Model 标识设备类型。 如果很多崩溃日志都是来自相同的设备类型，说明应用只在某特定类型的设备上有问题。上面的日志里，崩溃日志产生的设备是iPhone 4s。
Process 是应用名称。中括号里面的数字是闪退时应用的进程ID。
接下来几行不言自明，无需赘述。
(2) 基本信息
这部分给出了一些基本信息，包括闪退发生的日期和时间，设备的iOS版本。如果有很多崩溃日志都来自iOS 6.0，说明问题只发生在iOS 6.0上。
在这部分，你可以看到闪退发生时抛出的异常类型。还能看到异常编码和抛出异常的线程。根据崩溃报告类型的不同，在这部分你还能看到一些另外的信息。
(4) 线程回溯
这部分提供应用中所有线程的回溯日志。 回溯是闪退发生时所有活动帧清单。它包含闪退发生时调用函数的清单。看下面这行日志:
0x34648e88
0x83000 + 8740
它包括四列:
帧编号—— 此处是2。
二进制库的名称 ——此处是 XYZLib.
调用方法的地址 ——此处是 0x34648e88.
第四列分为两个子列，一个基本地址和一个偏移量。此处是0×83000 + 8740, 第一个数字指向文件，第二个数字指向文件中的代码行。
(5) 线程状态
这部分是闪退时寄存器中的值。一般不需要这部分的信息，因为回溯部分的信息已经足够让你找出问题所在。
(6) 二进制映像
这部分列出了闪退时已经加载的二进制文件。
符号化Symbolication
第一次看到崩溃日志上的回溯时，你或许会觉得它没什么意义。我们习惯使用方法名和行数，而非像这样的神秘位置:
Rage Masters
0x0001625c
0x2a000 + 3003
将这些十六进制地址转化成方法名称和行数的过程称之为符号化。
从Xcode的Organizer窗口获取崩溃日志后过几秒钟，崩溃日志将被自动符号化。上面那行被符号化后的版本如下 :
Rage Masters
0x0001625c
-[RMAppDelegate application:didFinishLaunchingWithOptions:] (RMAppDelegate.m:35)
Xcode符号化崩溃日志时，需要访问与App Store上对应的应用二进制文件以及生成二进制文件时产生的
.dSYM 文件。必需完全匹配才行。否则，日志将无法被完全符号化。
所以，保留每个分发给用户的编译版本非常重要。提交应用前进行归档时，Xcode将保存应用的二进制文件。可以在Xcode Organizer的Archives标签栏下找到所有已归档的应用文件。
在发现崩溃日志时，如果有相匹配的.dSYM文件和应用二进制文件，Xcode会自动对崩溃日志进行符号化。如果你换到别的电脑或创建新的账户，务必将所有二进制文件移动到正确的位置，使Xcode能找到它们。
注意: 你必需同时保留应用二进制文件和.dSYM文件才能将崩溃日志完整符号化。每次提交到iTunes Connect的构建都必需归档。
.dSYM文件和二进制文件是特定绑定于每一次构建和后续构建的，即使来自相同的源代码文件，每一次构建也与其他构建不同，不能相互替换。
如果你使用Build 和 Archive 命令,这些文件会自动放在适当位置。 如果不是使用Build 和 Archive命令，放在Spotlight能够搜索到的位置（比如Home目录）即可。
低内存闪退
因为低内存崩溃日志与普通崩溃日志略有不同，所以本教程特别分开说明一下。:]
iOS设备检测到低内存时，虚拟内存系统发出通知请求应用释放内存。这些通知发送到所有正在运行的应用和进程，试图收回一些内存。
如果内存使用依然居高不下，系统将会终止后台线程以缓解内存压力。如果可用内存足够，应用将能够继续运行而不会产生崩溃报告。否则，应用将被iOS终止，并产生低内存崩溃报告。
低内存崩溃日志上没有应用线程的堆栈回溯。相反，上面显示的是以内存页数为单位的各进程内存使用量。(在撰写本文的时候，一个内存页的大小是4KB。)
被iOS因释放内存页终止的进程名称后面你会看到
jettisoned 字样。如果看到它出现在你的应用名称后面，说明你的应用因使用太多内存而被终止了。
低内存崩溃日志看起来像这样：
Incident Identifier: 30E46451-53FD-7FC11AD05F
CrashReporter Key:
5af867f6eec76afee451bf9ae5f31
OS Version:
iPhone OS 3.1.3 (7E18)
Date/Time:
21:39:06.967 -0400
Free pages:
Wired pages:
Purgeable pages:
Largest process:
Rage Masters
Count resident pages
Rage Masters
9320 (jettisoned) (active)
mediaserverd
dataaccessd
CommCenter
SpringBoard
2158 (active)
accessoryd
mDNSResponder
当应用发生低内存闪退时，你必需看看应用中内存使用的方式，以及是如何处理低内存警告的。你可以使用Instruments工具中使用Allocations 和 Leaks来发现内存分配问题和内存泄漏问题。如果你不知道如何利用 Instruments 检查内存问题，可以看看
还有，别忘记虚拟内存！ Instruments工具的Leaks 和 Allocations 不能跟踪显存使用情况。必需使用 VM Tracker 才能查看显存使用情况。
VM Tracker 默认是关闭的。打开Instrument,手动 选中
Automatic Snapshotting 标志或者按下
Snapshot Now 按钮。
本教程后面将会学习如何研究低内存崩溃日志。
在研究真实闪退场景之前，还有一点需要重点介绍一下：就是那些有趣的异常编码 。
你可以在报告的异常部分——前面代码的第3部分找到异常编码。有些编码比较常见。
通常，异常编码以一些文字开头，紧接着是一个或多个十六进制值，此数值正是说明闪退根本性质的所在。
从这些编码中，可以区分出闪退是因为程序错误、非法内存访问或者是其他原因。
下面是一些常见的异常编码:
0x8badf00d: 读做 “ate bad food”! (把数字换成字母，是不是很像 :p)该编码表示应用是因为发生watchdog超时而被iOS终止的。
通常是应用花费太多时间而无法启动、终止或响应用系统事件。
0xbad22222: 该编码表示 VoIP 应用因为过于频繁重启而被终止。
0xdead10cc: 读做 “dead lock”!该代码表明应用因为在后台运行时占用系统资源，如通讯录数据库不释放而被终止 。
0xdeadfa11: 读做 “dead fall”! 该代码表示应用是被用户强制退出的。根据苹果文档, 强制退出发生在用户长按开关按钮直到出现 “滑动来关机”, 然后长按 Home按钮。强制退出将产生 包含0xdeadfa11 异常编码的崩溃日志, 因为大多数是强制退出是因为应用阻塞了界面。
注意: 在后台任务列表中关闭已挂起的应用不会产生崩溃日志。 一旦应用被挂起，它何时被终止都是合理的。所以不会产生崩溃日志。
大展身手的时候到了!
好了! 你已经学习了所有分析崩溃日志和修复错误的基础知识!
假设你刚进入Rage-O-Rage有限公司工作。该公司有一个在App Store上热销的应用，叫 Rage Masters。
你的老板安迪要你帮忙解决几个用户经常抱怨闪退问题。你的任务就是研究这些闪退，符号化用户提供的崩溃日志，查找问题所在，并修复之。
下载应用的源代码。
注意: 如果你想自己重新生成崩溃报告，请遵照以下指引：
下载源码然后在Xcode中打开工程文件。
使用正确的provisioning profile连接到iOS设备。
从Xcode工具栏上选择iOS设备——不是模拟器作为target，然后构建应用。
当你在设备上到默认页面（应用的全屏图片）时，立即在Xcode上点击停止按钮。
关闭 Xcode。
在设备上直接打开应用。
测试场景，完成后连接设备到电脑上，通过Xcode获取崩溃日志。
场景 1: 糟糕的代码
一封来自用户的邮件: “大哥，你的应用就是一坨屎! 我将其下载到我自己的iPod Touch和iPhone上，还下载到我儿子的iPod Touch上。在所有的设备上，都是还没打开就闪退了……”
别一封来自用户的邮件说, “我下载了你们的应用，一打开就闪退。真悲催…”
另一封邮件说得更明确：”你们的应用不能运行。我把它下载到我和妻子的设备上。所有设备都是 一打开就闪退了…”
好吧，别灰心! 这些意见藏着什么玄机呢？让我们看看崩溃日志吧:
Incident Identifier: 85833DBA-3DF7-43EE-AF80-4E5C51091F42
CrashReporter Key:
5af867f6eec76afee451bf9ae5f31
Hardware Model:
Rage Masters [20067]
/var/mobile/Applications/BD1F-4E61-BB18-0F/Rage Masters.app/Rage Masters
Identifier:
Rage Masters
Code Type:
ARM (Native)
Parent Process:
launchd [1]
Date/Time:
13:37:31.148 -0400
OS Version:
iOS 6.0 (10A403)
Report Version:
Exception Type:
Exception Codes: 0xbadf00d
Highlighted Thread:
Application Specific Information:
Soheil-Azarpour.Rage-Masters failed to launch in time
Elapsed total CPU time (seconds): 8.030 (user 8.030, system 0.000), 20% CPU
Elapsed application CPU time (seconds): 3.840, 10% CPU
Thread 0 name:
Dispatch queue: com.apple.main-thread
libsystem_kernel.dylib
0x327f2eb4 mach_msg_trap + 20
libsystem_kernel.dylib
0x327f3048 mach_msg + 36
CoreFoundation
0x36bd4040 __CFRunLoopServiceMachPort + 124
CoreFoundation
0x36bd2d9e __CFRunLoopRun + 878
CoreFoundation
0x36b45eb8 CFRunLoopRunSpecific + 352
CoreFoundation
0x36b45d44 CFRunLoopRunInMode + 100
0x32ac343e CFURLConnectionSendSynchronousRequest + 330
Foundation
0x346e69ba +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 242
Rage Masters
0x000ea1c4 -[RMAppDelegate application:didFinishLaunchingWithOptions:] (RMAppDelegate.m:36)
0x37f30ad4 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 248
0x37f3065e -[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 1186
0x37f28846 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 694
0x37ed0c3c -[UIApplication handleEvent:withNewEvent:] + 1000
0x37ed06d0 -[UIApplication sendEvent:] + 68
0x37ed011e _UIApplicationHandleEvent + 6150
GraphicsServices
0x _PurpleEventCallback + 588
GraphicsServices
0x370831ce PurpleEventCallback + 30
CoreFoundation
0x36bd4170 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
CoreFoundation
0x36bd4112 __CFRunLoopDoSource1 + 134
CoreFoundation
0x36bd2f94 __CFRunLoopRun + 1380
CoreFoundation
0x36b45eb8 CFRunLoopRunSpecific + 352
CoreFoundation
0x36b45d44 CFRunLoopRunInMode + 100
0x37f27480 -[UIApplication _run] + 664
0x37f242fc UIApplicationMain + 1116
Rage Masters
0x000ea004 main (main.m:16)
libdyld.dylib
0x3b630b1c start + 0
发现问题了吗? 异常编码是
0xbadf00d,还有后面的报告:
Application Specific Information:
Soheil-Azarpour.Rage-Masters failed to launch in time
Elapsed total CPU time (seconds): 8.030 (user 8.030, system 0.000), 20% CPU
Elapsed application CPU time (seconds): 3.840, 10% CPU
这说明应用在启动时就闪退了，iOS的watchdog机制终止了应用。帅! 找到问题了，但是为什会发生这样的事呢？
接着往下看日志。 从下向上读回溯日志。最底下的帧 (frame 25: libdyld.dylib)是最先调用的，然后是帧24, Rage Masters, main (main.m:16) ，依此类推。
跟应用源代码相关的帧是最重要的。忽略掉系统库和框架。下一个与代码相关的帧是:
Rage Masters
0x -[RMAppDelegate application:didFinishLaunchingWithOptions:] (RMAppDelegate.m:35)
应用在执行RMAppDelegate (RMAppDelegate.m:35)类
application:didFinishLaunchingWithOptions: 方法第35 行代码时闪退。打开Xcode看看那行代码：
NSData *directoryData = [NSURLConnection sendSynchronousRequest:request returningResponse:nil error:nil];
就是它了! 同步调用web服务?! 在主线程上?! 在
application:didFinishLaunchingWithOptions: 方法上?!! 谁写的代码呀?!
Network calls on the main thread makes kittens sad.
不管如何，问题得你来修复了。这个调用必需异步进行，甚至更理想的情况是，在
application:didFinishLaunchingWithOptions:返回YES之后的其他部分再执行Web服务。
在其他地方调用可能需要比较多的修改。当下，我们只要使应用不闪退就行。可以在日后再实现更好的设计。 将上面那行讨厌的代码（及其下面的三行代码）换成下面这个异步的版本吧:
[NSURLConnection sendAsynchronousRequest:request
queue:[NSOperationQueue mainQueue]
completionHandler:^(NSURLResponse *response, NSData *data, NSError *error)
NSURL *cacheDirectory = [[[NSFileManager defaultManager] URLsForDirectory:NSUserDirectory inDomains:NSCachesDirectory] lastObject];
NSURL *filePath = [NSURL URLWithString:kDirectoryFile relativeToURL:cacheDirectory];
[data writeToFile:[filePath absoluteString] atomically:YES];
场景 2: 无法响应事件的按钮
一名用户说: “我不能将某个rage master添加到书签里面。我想添加的时候应用就闪退…”
用一名用户说 ：”书签不能用 … 在详细页面上，点击书签按钮,应用就闪退了!”
上面的抱怨说得不是很清楚，引起问题的原因肯定有多样。看看崩溃日志:
Incident Identifier: 3AAA63CC-3088-41CC-84D9-82FE03F9F354
CrashReporter Key:
5af867f6eec76afee451bf9ae5f31
Hardware Model:
Rage Masters [20090]
/var/mobile/Applications/BD1F-4E61-BB18-0F/Rage Masters.app/Rage Masters
Identifier:
Rage Masters
Code Type:
ARM (Native)
Parent Process:
launchd [1]
Date/Time:
13:39:00.081 -0400
OS Version:
iOS 6.0 (10A403)
Report Version:
Exception Type:
EXC_CRASH (SIGABRT)
Exception Codes: 0x0
Crashed Thread:
Last Exception Backtrace:
CoreFoundation
0x36bff29e __exceptionPreprocess + 158
libobjc.A.dylib
0x34f0f97a objc_exception_throw + 26
CoreFoundation
0x36c02e02 -[NSObject(NSObject) doesNotRecognizeSelector:] + 166
CoreFoundation
0x36c0152c ___forwarding___ + 388
CoreFoundation
0x36b58f64 _CF_forwarding_prep_0 + 20
0x37fbb0a8 -[UIApplication sendAction:to:from:forEvent:] + 68
0x37fbb05a -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 26
0x37fbb038 -[UIControl sendAction:to:forEvent:] + 40
0x37fba8ee -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 498
0x37fbade4 -[UIControl touchesEnded:withEvent:] + 484
0x37ee35f4 -[UIWindow _sendTouchesForEvent:] + 520
0x37ed0804 -[UIApplication sendEvent:] + 376
0x37ed011e _UIApplicationHandleEvent + 6150
GraphicsServices
0x3708359e _PurpleEventCallback + 586
GraphicsServices
0x370831ce PurpleEventCallback + 30
CoreFoundation
0x36bd416e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 30
CoreFoundation
0x36bd4112 __CFRunLoopDoSource1 + 134
CoreFoundation
0x36bd2f94 __CFRunLoopRun + 1380
CoreFoundation
0x36b45eb8 CFRunLoopRunSpecific + 352
CoreFoundation
0x36b45d44 CFRunLoopRunInMode + 100
GraphicsServices
0x GSEventRunModal + 70
0x37f242fc UIApplicationMain + 1116
Rage Masters
0x000ca004 main (main.m:16)
libdyld.dylib
0x3b630b1c start + 0
异常代码是SIGABRT。通常,
SIGABRT 异常是由于某个对象接收到未实现的消息引起的。 或者，用简单的话说，在某个对象上调用了不存在的方法。
这种情况一般不会发生，因为A对象调用了B方法，如果B方法不存在，编译器会报错。但是，如果你是使用selector间接调用方法的，编译器则无法检测对象是否存在该方法了。
回到崩溃日志。它指出闪退发生在编号为0的线程上。 这意味着很可能是在主线程上调用了某个对象没有实现的方法。
如果你接着阅读回溯日志，会发现跟你的代码相关的只有帧22, main.m:16. 这没有多大帮助。 :[
继续向上查看框架调用，出现这个:
CoreFoundation
0x36c02e02 -[NSObject(NSObject) doesNotRecognizeSelector:] + 166
这不是你自己写的代码。但至少它确认了是对象调用了一个没有实现的方法。
RMDetailViewController.m文件, 因为那是书签按钮实现动作的地方。 找到书签功能代码:
-(IBAction)bookmarkButtonPressed {
self.master.isBookmarked = !self.master.isB
// Update shared bookmarks
if (self.master.isBookmarked)
[[RMBookmarks sharedBookmarks] bookmarkMaster:self.master];
[[RMBookmarks sharedBookmarks] unbookmarkMaster:self.master];
// Update UI
[self updateBookmarkImage];
看起来没什么问题，再检查一下storyboard (XIB文件) ，确认按钮连接的正确性。
就是它了! 在
MainStoryboard.storyboard,按钮连接的是 bookmarkButtonPressed: 而不是bookmarkButtonPressed (注意后面的分号说明方法有一个参数）。 只要将上面的方法签名修改成这样就能修复问题了:
-(IBAction)bookmarkButtonPressed:(id)sender {
// Remain unchanged..
当然，你也可以简单地在XIB文件上删除错误的连接，然后重新连接方法，使XIB文件连接到正确的方法上。两者方法都行。
又处理了一个闪退问题，好样的。:]
场景 3: 表格上的Bug
另一用户抱怨道, “在书签视图上无法删除书签…” 还有另一用户抱怨同样的问题, “当我试图删除书签时，应用闪退…”
这些邮件没什么作用，还是看看崩溃日志!
Incident Identifier: 5B62D681-D8FE-41FE-8D52-AB7E6D6B2AC7
CrashReporter Key:
5af867f6eec76afee451bf9ae5f31
Hardware Model:
Rage Masters [20088]
/var/mobile/Applications/BD1F-4E61-BB18-0F/Rage Masters.app/Rage Masters
Identifier:
Rage Masters
Code Type:
ARM (Native)
Parent Process:
launchd [1]
Date/Time:
13:38:45.762 -0400
OS Version:
iOS 6.0 (10A403)
Report Version:
Exception Type:
EXC_CRASH (SIGABRT)
Exception Codes: 0x0
Crashed Thread:
Last Exception Backtrace:
CoreFoundation
0x36bff29e __exceptionPreprocess + 158
libobjc.A.dylib
0x34f0f97a objc_exception_throw + 26
CoreFoundation
0x36bff158 +[NSException raise:format:arguments:] + 96
Foundation
0x346812aa -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 86
0x37f04b7e -[UITableView(_UITableViewPrivate) _endCellAnimationsWithContext:] + 7690
0x -[UITableView deleteRowsAtIndexPaths:withRowAnimation:] + 22
Rage Masters
0x000fd9ca -[RMBookmarksViewController tableView:commitEditingStyle:forRowAtIndexPath:] (RMBookmarksViewController.m:68)
0x -[UITableView(UITableViewInternal) animateDeletionOfRowWithCell:] + 80
0x37fbb0a8 -[UIApplication sendAction:to:from:forEvent:] + 68
0x37fbb05a -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 26
0x37fbb038 -[UIControl sendAction:to:forEvent:] + 40
0x37fba8ee -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 498
0x37fbb0a8 -[UIApplication sendAction:to:from:forEvent:] + 68
0x37fbb05a -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 26
0x37fbb038 -[UIControl sendAction:to:forEvent:] + 40
0x37fba8ee -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 498
0x37fbade4 -[UIControl touchesEnded:withEvent:] + 484
0x37ee35f4 -[UIWindow _sendTouchesForEvent:] + 520
0x37ed0804 -[UIApplication sendEvent:] + 376
0x37ed011e _UIApplicationHandleEvent + 6150
GraphicsServices
0x3708359e _PurpleEventCallback + 586
GraphicsServices
0x370831ce PurpleEventCallback + 30
CoreFoundation
0x36bd416e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 30
CoreFoundation
0x36bd4112 __CFRunLoopDoSource1 + 134
CoreFoundation
0x36bd2f94 __CFRunLoopRun + 1380
CoreFoundation
0x36b45eb8 CFRunLoopRunSpecific + 352
CoreFoundation
0x36b45d44 CFRunLoopRunInMode + 100
GraphicsServices
0x GSEventRunModal + 70
0x37f242fc UIApplicationMain + 1116
Rage Masters
0x000fb004 main (main.m:16)
libdyld.dylib
0x3b630b1c start + 0
这看起来跟前面那个崩溃日志很像。是另一个SIGABRT 异常。 你可能想知道是否是相同的问题：发送信息到一个没有实现相应方法的对象?
让我们从回溯日志看看哪些方法被调用了。从底部开始，你的源代码最后被调用的是帧 6:
Rage Masters
0x00088c66 -[RMBookmarksViewController tableView:commitEditingStyle:forRowAtIndexPath:] (RMBookmarksViewController.m:68)
这是UITableViewDataSource 的一个方法. 呵呵?! 毫无疑问苹果已经实现了该方法 —— 你可以重载它, 但不像是还没有实现。而且,这是个可选的委派方法。 所以问题不是调用了一个没有实现的方法。
再看看上面的几个帧:
Foundation
0x346812aa -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 86
0x37f04b7e -[UITableView(_UITableViewPrivate) _endCellAnimationsWithContext:] + 7690
0x -[UITableView deleteRowsAtIndexPaths:withRowAnimation:] + 22
帧 5, UITableView调用了它自己的另一个方法
deleteRowsAtIndexPaths:withRowAnimation: 然后是看起来像苹果内部方法的
_endCellAnimationsWithContext: 被调用。然后Foundation framework发生异常
handleFailureInMethod:object:file:lineNumber:description:.
这些分析结合用户的抱怨，看起来是你在处理UITableView删除行过程中有Bug。回到Xcode。你知道看哪里吗 ? 能从崩溃日志中判断出来? 就是
RMBookmarksViewController.m文件的第68行:
- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath {
[self.tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationAutomatic];
发现问题了吗? 给你点时间，仔细看一下。
找到了吧! 数据源呢? 代码在表格视图上删除了一行，但并没有修改背后的数据源。把上面的代码替换成下面的就能修复问题了:
-(void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath {
RMMaster *masterToDelete = [bookmarks objectAtIndex:indexPath.row];
[bookmarks removeObject:masterToDelete];
[[RMBookmarks sharedBookmarks] unbookmarkMaster:masterToDelete];
[self.tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationAutomatic];
搞定了!走起，讨厌的 bug!!
场景 4: 吃棒棒糖时闪退!
用户邮件说, “当rage master吃棒棒糖时应用就闪退…” 另一用户说, “我让rage master 吃棒棒糖，没几次应用就闪退了!”
崩溃日志如下:
Incident Identifier: 081E58F5-95A8-404D-947B-5E104B6BC1B1
CrashReporter Key:
5af867f6eec76afee451bf9ae5f31
Hardware Model:
OS Version:
iPhone OS 6.0 (10A403)
Kernel Version:
Darwin Kernel Version 13.0.0: Sun Aug 19 00:28:05 PDT 2012; root:xnu-~4/RELEASE_ARM_S5L8940X
13:39:59 -0400
Time since snapshot: 4353 ms
Free pages:
Active pages:
Inactive pages:
Throttled pages:
Purgeable pages:
Wired pages:
Largest process:
Rage Masters
recent_max
lsd &6a9f5b5f36b23fc78f87b6d8f1f49a9d&
(daemon) (idle)
afcd &b0aff2e2fec81a8dcdbb2&
(daemon) (idle)
itunesstored &4e0cd9f873deb2d6d13d&
(daemon) (idle)
softwareupdatese &2bc4b5aed3b34f81027d0ae&
(daemon) (idle)
Amazon &ec3e59af67ba14&
(suspended)
accountsd &ac0fce15c1aefc498d521ac7&
(daemon) (idle)
coresymbolicatio &edbab153b4b&
(daemon) (idle)
Skype &504cf2fe60cb3cdea836b&
(background)
MobileMail &bff817c61ce33c85a43ea9a6c98c29f5&
(continuous)
MobileSMS &4d67aeea207464cfc581&
(background)
MobilePhone &3fca241f2a193d0fbea41&
(continuous)
librariand &c9a9be81aace79b911f27e&
kbd &3e7136ddcefc3d77a0cd&
tccd &eb5ddcfd987d67cae6a4c4ea&
Rage Masters &90b45dc5b06cf7dc4d492&
(frontmost) (resume)
ptpd &04a56fce9aeea8e5a7ea&
iaptransportd &f784f30dc09de8113ef6&
locationd &892cd1c9ffa43c99a82dba197be5f09e&
syslogd &cbef142fa0a839f0885afb693fb169c3&
mediaserverd &daca32c9b8f3a6b1faac43a2&
dataaccessd &2a3f6a518f3f3646bf35eddd36f25005&
aosnotifyd &d4d14fe447cfef3e6542&
wifid &37998cdbb9b34f090d0c&
SpringBoard &27372aae101f3bbc87804edc10314af3&
backboardd &b33eda98eb5c72c098858&
UserEventAgent &6edfd8d8dbadcdfc94f90&
mediaremoted &4ff39c50c6ace813cb25&
pasteboardd &8aa321f84a076a711dc1c51&
springboardservi &ff6f64b3a21a39c9a1793321eefa5304&
syslog_relay &45eabb54426&
DTMobileIS &2aaa9047854ea&
notification_pro &845b7beebc8538ca9ceef&
syslog_relay &45eabb54426&
ubd &74dc476dfcda555fcb8d774&
twitterd &4bc397d55b8e&
configd &ecf6b8671844&
absinthed.N94 &7f0caa940b863c901aa9&
filecoordination &fbab576f37a63b56aaa7d8&
distnoted &a89af76ec8633ac2bbe99bc2b7964bb0&
apsd &94d2f82d775bc279ae608&
networkd &f53a6c8a588&
aggregated &8c3c991dc4153bc38aee1e&
BTServer &c92fbdec9dbd&
fairplayd.N94 &7bd896bd90d05cf1c86a&
fseventsd &996cc4caaea8d781b55bce08&
imagent &1ea1d07b2f&
mDNSResponder &3ed27a827d97&
lockdownd &ba3f1b91af7d5f58dd5bbe&
powerd &2d2ffed5e69638aeba1b92ef124ed861&
CommCenter &1f425e1e897d32e8864fdd8eeaa803a8&
notifyd &51c0e03da8a93ac8a595442fcaac531f&
ReportCrash &8c32f231b2ed360bb151b2563bcaa363&
这日志跟我们前面见到的相差很多。
这个一个来自iOS 6的低内存崩溃日志。正如我们前面所说的，低内存崩溃日志与其他类型的崩溃日志很不一样，它们不指向特定的文件和代码行。相反，它们画出了闪退时设备上的内存使用情况的图表。
至少，头部还是跟其他崩溃日志很像的:
提供了 Incident Identifier, CrashReporter Key, Hardware Model, OS Version等信息。
接下来部分是低内存崩溃日志特有的:
Free pages 指可用内存页数。每页大小约是4KB, 上面的日志中，可用内存约为3,872 KB (或者说 3.9 MB)。
Purgeable pages 是那部分可被清除或重用的内存。在上面的日志中，是0KB。
Largest process是闪退时使用大部分内存的应用名称，在上面的日志中，正是你的应用!
Processes显示了闪退时各进程列表，还包含内存使用量。包含进程名 (第一列), 进程唯一标识符(第二名), 进程使用的内存页数(第三列)。最后一列是每个应用的状态。通常，发生闪退的应用的状态是 frontmost。 这里是 Rage Masters, 使用28591 页 (or 114.364 MB) 内存——这内存太多了!
通过，最大进程和frontmost状态的应用是相同的， 而且也是引起低内存闪退的应用进程。但是也可能看到最大进程和 frontmost状态应用不同的例子。比如，如果最大进程是SpringBoard, 忽略它 , 因为 SpringBoard 进程是显示主屏幕的应用，出现在你双击home按钮等情况，而且它是一直活动的。
低内存发生时，iOS向活动的应用发出低内存警告并终止后台应用。如果前台应用仍然继续增长内存，iOS将终止它。
为了查找低内存问题的原因，你必需使用Instruments剖析应用。如果你不知道怎么做，可以看一下我们 一篇关于这个方面的教程.。 :] 另外, 你也可以走捷径，响应低内存警告通知，以解决部分闪退问题。
回到Xcode查看RMLollipopLicker.m文件。 这是实现吃棒棒糖的视图控制器。看看源代码:
#import &RMLollipopLicker.h&
#define COUNT 20
@interface RMLollipopLicker ()
@property (weak, nonatomic) IBOutlet UIProgressView *progressV
@property (weak, nonatomic) IBOutlet UILabel *
@property (weak, nonatomic) IBOutlet UILabel *lickedTimeL
@implementation RMLollipopLicker {
NSOperationQueue *
NSMutableArray *
#pragma mark - Life cycle
- (void)viewDidLoad {
[super viewDidLoad];
self.progressView.progress = 0.0;
self.label.text = [NSString stringWithFormat:@&Tap on run and I&ll lick a lollipop %d times!&, COUNT];
self.lickedTimeLabel.text = @&&;
lollipops = [[NSMutableArray alloc] init];
queue = [[NSOperationQueue alloc] init];
- (void)lickLollipop {
NSURL *fileURL = [[NSBundle mainBundle] URLForResource:@&Lollipop& withExtension:@&plist&];
NSDictionary *dictionary = [NSDictionary dictionaryWithContentsOfURL:fileURL];
NSString *lollipop = [dictionary objectForKey:@&Lollipop&];
[lollipops addObject:lollipop];
#pragma mark - IBActions
- (IBAction)doneButtonPressed:(id)sender {
[self dismissViewControllerAnimated:YES completion:nil];
- (IBAction)runButtonPressed:(id)sender {
[sender setEnabled:NO];
[queue addOperationWithBlock:^{
for (NSInteger i = 0 ; i = COUNT) {
self.label.text = [NSString stringWithFormat:@&Tap on run and I&ll lick a lollipop %d times!&, COUNT];
self.progressView.progress = 0.0;
[sender setEnabled:YES];
当用户点击运行按钮, 应用开始一个背景线程，调用 lickLollipop 方法若干次，然后更新界面反映吃棒棒糖的数量。 lickLollipop 方法从属性列表文件(PLIST）文件读取一个长字符串，然后添加到数组上。这些数据并不重要, 能在不影响用户体验的前提下重新创建。
利用每种能够清除和重建数据而不影响用户体验的情况是好习惯。这样能够方便地释放内存，减少低内存警告。
那么，如何提高代码质量呢? 实现 didReceiveMemoryWarning 方法，像下面这样处理数据:
-(void)didReceiveMemoryWarning {
[lollipops removeAllObjects];
[super didReceiveMemoryWarning];
万岁，你研究了4个闪退案例! 你的应用更完善了，并且学到了一些重要的调试技巧。
下载改进后的项目代码。
你喜欢iOS崩溃日志揭秘吗? 希望你能将学到的运用到你自己的应用中，也希望你能处理闪退，使你的应用更强壮!
相关 [ios 应用 日志] 推荐：
- 移动开发 - ITeye博客
/zh-hans/30818/ios应用崩溃日志揭秘. Soheil Moayedi Azarpour, 他是一名独立iOS开发者. 作为一名应用开发者，你是否有过如下经历?. 为确保你的应用正确无误，在将其提交到应用商店之前，你必定进行了大量的测试工作. 它在你的设备上也运行得很好，但是，上了应用商店后，还是有用户抱怨会闪退. 如果你跟我一样是个完美主义者，你肯定想将应用做到尽善尽美. 于是你打开代码准备修复闪退的问题……但是，从何处着手呢. 在大多数情况下，你能从中了解到关于闪退的详尽、有用的信息. 通过本教程，你将学习到一些常见的崩溃日志案例，以及如何从开发设备和iTunes Connect上获取崩溃日志文件.
- CSDN博客移动开发推荐文章
一、如何获得crash日志. 当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上. 这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息（低内存闪退日志例外），对于开发人员定位问题很有帮助. 如果设备就在身边，可以连接设备，打开Xcode - Window - Organizer，在左侧面板中选择Device Logs（可以选择具体设备的Device Logs或者Library下所有设备的Device Logs），然后根据时间排序查看设备上的crash日志. 这是开发、测试阶段最经常采用的方式. 如果应用程序已经提交到App Store发布，用户已经安装使用了，那么开发者可以 通过iTunes Connect（Manage Your Applications
- View Details - Crash Reports）获取用户的crash日志.
- jicknan - 爱范儿 · Beats of Bits
过去的一年堪称苹果的丰收年，革命性的 iPad 和大卖特卖的 iPhone 4 的各种故事贯穿了整个 2010，然而，除去优秀的硬件设计，iOS 的真正竞争力，在于它那恐怖的 30 万应用. 今天，苹果公布了 2010 的最佳 iOS 应用榜单（应该是北美的统计）. 1：美国人对于职棒的爱超过了一切，在总榜单上， 的免费应用甚至超过了愤怒小鸟. 2：美国人对于僵尸的爱超过了俄罗斯方块和帮他们找路的 TomTom，总榜单上面有三个僵尸类游戏：僵尸农场，使命的召唤：僵尸 以及植物大战僵尸. 3：iPhone 总榜单前十名有七个游戏，现在再看看我之前的文章，这才只是手机游戏对传统游戏领域侵蚀的开端而已.
- ItTalks - 《商业价值》杂志
专注于研究苹果公司的咨询公司Piper Jaffray’s Gene Munster近期发布了一份研究报告. 报告显示，2011年，iOS设备用户正在以更大的热情购买付费应用，而付费iOS应用的价格也普遍得到提升. Piper Jaffray详细监测了自App Store上线以来，包括终端数量、应用下载数量、付费应用数量、免费应用数量、收入等在内的各种数据. 数据显示，App Store的应用下载量持续增长. 在刚过去的2011年第2季度，获得了59%的仅次于App Store上线伊始的季度增长率. Piper Jaffray预计，与2010年平均每个用户51个的App下载量相比，2011年iOS用户将会平均下载83个应用，增长率为61%.
- yonghai - Solidot
《金融时报》成为第一家因苹果应用内订阅分成政策而移除iOS应用的世界知名媒体. 金融时报发言人Tom Glover表示，他们是在与苹果友好协商后决定移除应用，表示iTunes对基于广告的应用来说仍然是一个重要渠道. 苹果的新政策要求从应用内内容销售和订阅中提取三成收入. 为了遵循苹果要求，Amazon、Barnes & Noble、Kobo、Google和《华尔街日报》决定从应用内移除购买功能. 《金融时报》是苹果新政策的主要批评者，它移除应用并不出人意料. 它早在6月份就推出了一个基于Web的iPad app，逐渐将用户从原生应用转移到Web应用. 亚马逊也推出了基于Web的应用.
- 橙子 - 谷奥——探寻谷歌的奥秘
尽管已经有iOS应用支持直接发布文章到Blogger，但第三方用着就是别扭. 于是今天Google推出了官方的Blogger for iOS应用，支持的功能包括：. 发布和编辑博文，也可保存为草稿. 可直接拍摄照片或选择图片库里的照片发布. 支持iPhone、iPad和iPod touch，需要3.1.3以上版本，内含中文界面. (C) musiXboy 发表于 谷奥——探寻谷歌的奥秘 ( http://www.guao.hk ), 2011. |
没有评论 |
永久链接 |
关于谷奥 |
投稿/爆料.
- Leomg - 36氪
我一直都认为自己是一个电影爱好者，自诩电影达人. 但是现在我发现自己其实是一个伪电影爱好者. 我彻底被MovieCat!（电影猫）打败了. 《MovieCat!》是一款电影知识问答类的iOS游戏. 在游戏中，主角是各种造型的猫咪，它出演电影中的各种角色、片段. 在游戏的过程中电影猫会想你提出很多和该电影相关各种问题，让各个玩家挑战自己对电影的熟悉程度. 电影猫会问一些经典的电影台词、重现一些经典的电影镜头，并且表现方式都是很搞笑的. 事实上，这更需要玩家对电影比较熟悉才能够很好的猜对电影猫的问题. 游戏规则很简单，可以自己设定有时的难度. 首先要选择自己的电影猫的造型：美国西部牛仔爱好者可以选择英雄佐罗，谍战爱好者可以扮演007，美女可以争做《泰坦尼克号》中的Rose.
大量新生移动设备的兴起，改变了互联网的未来. 在技术的发展上， HTML5会取代App应用吗. 在HTML5规范中，已经加入了相机、磁力罗盘、GPS信息的支持. 很多新兴浏览器也已经开始支持这些新特性. 能否用一个统一的HTML5来替代 android和 ios并行开发的双重成本呢. 以下译自Michael Mahemoff的一篇文章，详细分析了HTML5能否取代Android和iOS应用程序. 移动应用程序(App)和HTML5都是目前最火的技术，二者之间也有不少重叠之处. 在移动设备浏览器里运行的html5的web页面，也可以重新打包成不同平台上运行的app. 目前很多浏览器都有很好的跨平台支持，（译注：firefox居然可以在android中使用和windows下同样的浏览器内核），HTML5的web方案，对开发者来说更为方便.
- InfoQ cn
移动互联网如火如荼，iOS 应用+ Android 应用+ 手机站似乎成了所有互联网公司的标配，你的网站要是还没有个iOS 应用，似乎都不好意思跟人打招呼. GitHub运维专家Jesse Newland QCon分享Github ChatOps机器人与GitHub架构演进. 如何正确实施，大幅提升企业生产力. QCon北京Node.js专场：异步非阻塞，单线程，事件驱动，如何在企业应用落地发挥成效. 百度技术沙龙第三十四期：机器学习之多媒体方向的思考（日 周六）. 百度技术沙龙特约观察员火热招募中，2013，因为有你更精彩. 《JavaScript语言精粹》作者Douglas Crockford确认参会，.
- 無標題文檔
我不是版本控，所以至今才给我的 iPad 更新到了
iOS6，顺便过滤和重新安装了些应用. 很久以前我就盘点过经常使用的软件（
），所以干脆这里也整理下. 通常好用的软件都会「很有名」而且用很久了，估计大家也都早已经认识. 这次的 iOS 软件或许对 iOS 重度用户说起来有些火星请勿见笑，就权当大家做个参考吧. 我使用 iPad
主要是用来看书和资料、新闻、查地图以及刷微博和做些简单的笔记，所以这里列出来的应
用都至少是我一周内肯定会要打开用到的. 这个自然不用多说了，这是我每天都要启动的应用. 用它来看 Google Reader 是再合适不过的事情了.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。}