经验61087 米
威望410 米
在线时间2511 小时
版本7.11.16
急用户所急，想用户所想
机型小米Max2
签到次数215
MIUI版本7.11.16
本帖最后由 、Stamina 于
22:16 编辑
& && & 众所周知，MIUI是一个快速迭代的手机系统，在系统的更新过程中难免会遇到一些扰人的BUG，那么究竟如何正确有效的反馈BUG，及时和开发组沟通，收录BUG，处理BUG，以使MIUI越发稳定，越发好用呢？接下来，我结合自己的经验，和大家分享一下正确有效反馈BUG的方法。
1、在哪里反馈BUG？
& && &MIUI是一个由发烧友参与开发的手机系统，普通的发烧友和特殊用户组都可以积极反馈自己遇到的BUG，但值得注意的是，由于特殊用户组拥有88及以上的阅读权限，可以直接在MIUI专区的BUGLIST直接进行反馈。
（1）普通发烧友
& && & 普通发烧友可以直接在相应机型的BUG反馈版块进行反馈，会有BUG区版主将正确有效反馈的BUG提交给开发组，也就是提交到MIUI专区的BUGLIST里面。红米NOTE版块的反馈地址为：。
（2）特殊用户组
& && & 特殊用户组包括内测粉丝组、荣与开发组、解答组等阅读权限在88以上的发烧友，特殊用户组可以直接在MIUI专区的BUGLIST直接进行反馈，当然在相应机型的BUG反馈版块反馈也是可以的。BUSLIST的地址为：。
2、反馈BUG前需要做什么？
& && &目前MIUI的用户已经突破一亿，在使用过程中，遇到相同BUG的机友肯定不在少数。所以，在反馈BUG前，一定要通过以下方式确认是否已经有机友反馈过类似BUG，避免重复反馈。
（1）查看BUG反馈版块置顶的BUG汇总贴
1.png (179.51 KB, 下载次数: 3)
& && &可以通过查看本月和上月的BUG汇总贴，了解自己反馈的BUG是否已经有机友反馈过，避免重复反馈。上月的BUG汇总贴可以直接在本月汇总贴里面进入，底部有相应链接。
（2）查看最近反馈的BUG& && &对于在内测更新中出现的BUG，如果汇总贴没有及时收录，可以在BUG反馈版块将帖子以发帖时间排序，查看最近是否有机友反馈过类似BUG。因为内测组的机友都很积极，这样可以避免大量机友反馈同一BUG的情况。& && &如果已经有机友反馈类似BUG，那么你只需要在此帖中点我也遇到即可，不需要再次反馈类似BUG。
（3）搜索相应关键词
2.png (24.69 KB, 下载次数: 3)
& && &如果以上方法没有找到类似BUG，可以运用论坛搜索功能，搜索相关关键词，如果还是没有找到相关BUG反馈贴，那么楼主就可以认真反馈BUG了。
3、如何正确有效的反馈BUG
3.png (118.79 KB, 下载次数: 5)
（1）简明扼要的标题& && &帖子标题要简明扼要地说明问题，建议使用标题【版本号】【手机版本】问题详情，例如，【5.3.3】【NOTE 4G】网络助手不能自动校正流量 。
（2）填写正确的机型信息& && &选择正确的使用机型、ROM版本和版本号。对于红米note机型来说，ROM版本分为稳定版和开发版两种。
（3）正确的问题描述& && & 在问题描述里面，可以将标题所描述的内容更加详尽的做一下说明。
（4）复现步骤& && &清楚简明的说明相关BUG的复现步骤，开发组才能够更好的复现您所遇到的BUG，建议通过1、2、3的方式填写复现步骤。
（5）BUG截图& && &清楚的截图才能让开发组了解你究竟遇到了什么问题。上传一张截图，可以直接点击上传截图，如需上传多张截图请使用下方编辑器。
（6）log文件& && &提取相关log文件，开发组才能够进一步定位BUG产生的原因，进而解决BUG。对于闪退、WIFI断线、耗电严重、无故重启等BUG，log文件都是至关重要的。log文件获取方法：
1.拨号键盘——输入*#*#284#*#*——等待一分钟
2.SD卡根目录下的MIUI/debug_log文件夹内会出现bugreport***.zip文件，即为log文件
（7）每个帖子反馈一个BUG
& && &由于不同类型的BUG是由不同的开发组进行处理的，所以大家在反馈BUG时务必每一个帖子反馈一个BUG，这样才能够和开发组正确对接。
（8）BUG反馈模板& && & 这是我之前反馈的一个BUG，大家可以参考一下，互相学习，。
& && &总而言之，一个好的BUG反馈贴是由一个简明扼要的标题、详细的复现步骤、正确的BUG截图、相关log文件组成的，大家在反馈BUG的时候务必按照相关要求进行反馈，这样方便开发组快速高效的处理BUG。
4、盖章代表着什么？（1）已答复：代表您反馈的问题已经有人答复了，并不是已经解决了问题，请各位不用担心，如果还有其他询问，请直接回复答复人询问内容即可。
（2）待讨论：这是代表您反馈的内容，相关人员或者开发组无法马上判定是否存在这个问题，需要各位发烧友提供相关的资料来协助判断问题的所在。
（3）请补充：这是代表您反馈的内容没有达到之前所说的反馈要求，请您检查下还缺了点什么后补充了再与本区版主或者开发组联系。
（4）已提交：这是代表您反馈的内容已经提交给开发组查看原因和处理了，请耐心等候修复即可。
5、如何正确补充帖子？
& && & 在反馈BUG之后，经常会遇到帖子被盖章“请补充”，这时需要进入帖子查看版主或者开发组的相关回复，补充相关内容到帖子中，补充之后务必艾特相关人员，否则开发组会以为你没有补充相关内容。
& && & MIUI之所以可以成为中国乃至世界上数一数二的第三方定制安卓ROM，离不开所有发烧友的努力，正是因为各位发烧友积极的反馈BUG，系统才能够越趋稳定，越趋完美。是你们的无私付出，才有了MIUI的今天。& && &&&希望大家能够正确有效的反馈BUG，感谢大家的付出，认真反馈BUG都会有加分的！
分享到微信朋友圈
打开微信，点击底部的“发现”，使用 “扫一扫” 即可将网页分享到我的朋友圈。
已有&23&人评分
助人为乐^_^
MIUI 因你更精彩！
精品文章^_^
助人为乐^_^
MIUI 因你更精彩！
MIUI 因你更精彩！
MIUI 因你更精彩！
精品文章^_^
精品文章^_^
精品文章^_^
MIUI 因你更精彩！
助人为乐^_^
MIUI 因你更精彩！
感谢分享^_^
精品，原创文章^_^
精品文章^_^
感谢分享^_^
助人为乐^_^
助人为乐^_^
MIUI 因你更精彩！
经验&+102&
经验31222 米
威望575 米
在线时间1651 小时
版本7.11.20
机型小米MIX 2
签到次数175
MIUI版本7.11.20
已有&1&人评分
MIUI 因你更精彩！
擅用论坛搜索资源，有问题也可@我& &&&NOTE 4G拍摄
经验19451 米
威望140 米
在线时间874 小时
版本7.11.20
机型小米手机6
签到次数122
MIUI版本7.11.20
通过手机发布
已有&1&人评分
MIUI 因你更精彩！
经验29998 米
威望427 米
在线时间847 小时
版本5.11.11
MIUI小白⊙﹏⊙‖∣°
机型红米Note TD版
签到次数68
MIUI版本5.11.11
通过手机发布
好帖子，支持
已有&1&人评分
MIUI 因你更精彩！
经验30567 米
威望304 米
在线时间1168 小时
版本7.10.26
机型小米Note 移动4G/联通4G
签到次数93
MIUI版本7.10.26
写得很详细，希望能帮到友友！
已有&1&人评分
MIUI 因你更精彩！
经验94015 米
威望238 米
在线时间1912 小时
版本7.10.26
机型小米Max 标准版
签到次数96
MIUI版本7.10.26
不错，是需要这么个引导贴子&&
已有&1&人评分
精品文章^_^
经验10212 米
在线时间333 小时
版本7.11.16
机型红米Note3
签到次数91
MIUI版本7.11.16
已有&1&人评分
MIUI 因你更精彩！
经验19957 米
在线时间358 小时
版本7.9.27
MIUI 论坛组
机型小米手机6
签到次数127
MIUI版本7.9.27
感谢分享，支持
已有&1&人评分
精品文章^_^
MIUI 因你更精彩！祝各位水友:新年快乐！羊年大吉^O^发大财
各位友友如果觉得我的帖子对你有帮助，请给我一个赞。或是加加分什么的。感谢大家的支持
经验3135 米
在线时间105 小时
版本V8.5.2.0.NAACNED
积分 3574, 距离下一级还需 1426 积分
积分 3574, 距离下一级还需 1426 积分
机型小米手机5
签到次数53
MIUI版本V8.5.2.0.NAACNED
通过手机发布
MIUI之所以可以成为中国乃至世界上数一数二的第三方定制安卓ROM，离不开所有发烧友的努力，正是因为各位发烧友积极的反馈BUG，系统才能够越趋稳定，越趋完美。是你们的无私付出，才有了MIUI的今天。
经验21737 米
在线时间297 小时
版本7.11.7
机型小米Note 移动4G/联通4G
签到次数110
MIUI版本7.11.7
通过手机发布
万圣节勋章
参加回帖活动
米兔月饼勋章
参加回帖活动
MIUI七夕鹊桥勋章
MIUI七周年
MIUI 9纪念勋章
小米众筹2周年
参加回帖活动
小米7周年勋章
2017米粉节晒单赢专属勋章
“澎湃S1 ”芯片纪念勋章
参与活动回帖可得
参与红米Note 4X活动
2017年小金鸡勋章
回复2016年度评选活动贴
APP 1000万
MIUI论坛APP注册用户突破1000万纪念勋章
MIUI 300周
MIUI 300周更新纪念勋章
为奥运加油勋章
为奥运加油勋章
小米六周年
小米六周年米粉节
MIUI 2000万
MIUI 2000万发烧友纪念勋章
1000万用户纪念勋章
MIUI1000万用户纪念勋章
MIUI 7纪念勋章
参加流量购买活动
MIUI五周年
MIUI五周年纪念勋章
MIUI三周年
MIUI三周年纪念勋章
百万壁纸评审纪念勋章
已关注微信
已关注极客秀微信
MIUI6 荣誉勋章
MIUI6 荣誉勋章
MIUI V5内测元勋
MIUI V5内测元勋勋章
关注腾讯微博
已关注腾讯微博
关注新浪微博
已关注新浪微博
MIUI 100周
100周发布纪念勋章
MIUI六周年
MIUI六周年纪念勋章
MIUI 8纪念勋章
MIUI 8纪念勋章
MIUI 3000万
MIUI 3000万发烧友纪念勋章
发烧友俱乐部
发烧友俱乐部
小火箭勋章
神舟11号 话题活动
小米平板首发纪念勋章
小米平板首发纪念勋章
新版论坛APP
更新新版APP
圣诞节勋章
参与圣诞活动
小米5发布会
参加小米5发布会直播页大转盘抽奖获得
Copyright (C) 2017 MIUI
京ICP备号 | 京公网安备34号 | 京ICP证110507号如何写有效的bug报告_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
如何写有效的bug报告
阅读已结束，下载文档到电脑
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩5页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢如何给苹果提交Bug或功能需求？
发表于 10:17|
来源idlelife|
作者pockry
摘要：在苹果的Bug Reporter中，开发者可以提交自己发现的任何问题或功能需求，并查看已提交问题的处理情况。这个Bug Reporter几乎是开发者和苹果之间关于系统和软件故障的唯一反馈渠道。
自从Swift推出以来，很多开发者已经第一时间尝鲜并且尝试用它进行开发了。不过，由于Swift还是个演进中的语言，Xcode对它的支持并不完善，偶尔会出这样那样的小问题。有些开发者在发现问题后，顶多发个博客记录一下然后就不管了，我们是否有更好的办法，比如给苹果提交这个bug，让它快速修复呢？答案是有的，并且仅对苹果的开发者开放，即苹果的。Radar or GTFO在苹果的Bug Reporter里，你可以提交你发现的问题或者功能需求，你也可以查看你提交的问题的处理情况。问题会被分配一个ID，并带上rdar://这样的URI链接，因此给苹果提Bug被称为“file a Radar”，意味着你的问题出现在了苹果工程师的雷达上面，十分形象。在国外苹果开发者中间有一句广为流传的话叫做“Radar or GTFO(Get The f*ck Out)”，意思是除非你发布了一个Radar，否则苹果不会处理你的问题。无论你在个人博客或者苹果的开发者论坛上面提交Bug，即使苹果工程师看到也会被忽略掉的，这个Bug Reporter几乎是开发者和苹果之间关于系统和软件故障的唯一反馈渠道（如果是和App审核、苹果设备相关的问题，你可以寻找对应的客服）。如何写一个Radar？使用苹果开发者账号登录到Bug Reporter后，你可以提交问题。苹果的这个系统和其它的Bug追踪系统并没有太大的差别，你需要先选择发生问题的产品、问题类型、复现频率，然后用标题和文字来尽可能清晰的描述你的问题细节。编写问题细节并没有固定的格式，你需要提供出问题的系统或软件版本，如果有截图或者其他文件证据可以作为附件添加。需要注意的是，你需要用英文编写问题。不过，虽然没有格式，作为完美主义者的苹果还是对问题细节的描述做出了诸多规定和建议。比如，标题部分：Safari is slow.（坏的）Safari is slow allocating JavaScript arrays. (Include JavaScript sample with your bug report.)（好的）问题细节也需要包含以下几个部分：复现问题的步骤预期结果实际结果变通方案回归测试和条件隔离情况（Regression/Isolation）具体内容可以看苹果关于。提交Radar的技巧提交Radar可能会遇到一个情况，那就是这个问题之前已经有人提交过，那么它会被标注为“duplicate”，不要惊慌，其实这里包含着一个提交Radar的技巧。前面说过，向苹果反馈bug的唯一途径是Bug Reporter，在其它地方闹得满城风雨也没有用，苹果也不建议这么做，如果你做得太过分了，还可能受到苹果的惩罚。那么，如何让苹果重视你提交的问题呢？Daniel Pasco，一位有经验的苹果开发者在他的里这样向我们传授经验：工程师团队总是面对太多需要解决的问题，工程师们定期的和它们的上级主管开会，对问题进行分类，以决定接下来需要解决哪个问题。一个问题被报告得越多，说明它越需要关注，工程师在下判断时也会更容易。对于所有软件公司来说都是这样，当你发布了一个产品，人们很有可能会报告一两个边缘用例（edge case）下的问题，你当然会想在时间允许的情况下修复它，但如果有数百人报告相同的问题，说明问题很严重，并亟待解决。苹果在这方面和其它公司并无不同。从某种意义上来说，提出重复的问题是一种投票，或是对已存在问题的一个支持。一个问题获得的重复次数越多，说明它的优先级越高。因此，如果你发现了一个问题，在提出Radar之后，可以将Radar原文发布到自己的博客或者论坛上，号召其它开发者提出相同的Radar，促使苹果工程师重视这个问题。不过也要有所克制，注意不要滥用。除了提交重复问题，还有一个可能不太常用的技巧是，你可以去勾搭苹果工程师，如果你提交的Radar好几天了都没动静，你可以联系苹果工程师，以求获得一个反馈。当然，这里如何勾搭和勾搭的技巧就需要大家自己琢磨了。看到这里你是不是蠢蠢欲动，想去Bug Reporter上提交几个bug？但国外的苹果开发者对这个Radar系统却并不怎么买账，为什么呢？Fix Radar or GTFO苹果的这个Bug Reporter系统最大的问题是，开发者提交问题之后，无法快速收到有效的反馈。一般的场景是这样，你提交了一个问题，然后它被标为duplicate并关闭，然后就没有然后了。别的开发者无法看到你的提交的Radar，你无法看到苹果的工程师对于此问题的回复，你也无法得知你提交的问题何时能得到修复。（如果你提交的Bug非常紧急或有一些其它问题，苹果也可能会直接联系你，不过这种情况很少）Mattt大神，一个Radar在提出足足7年之后才被修复，除了提交Radar的技巧之外，缺乏有效的沟通手段也是造成这一结果的原因。另外，这个Bug Reporter系统还有UI不美观，完全不像苹果出品，对于开发者不够友好的缺陷。在2012年，一些苹果开发者再也无法忍受如同黑洞一般的Bug Reporter系统，发起了“”活动，呼吁开发者提交重复性的Radar，想让苹果改进这个Bug收集系统，让它变得更加开放。另外一些人则做了一个，开发者在提交到官方的Bug Reporter之余，也可以将他们的Radar提交到这里，开发者可以看到别人的Radar并进行讨论。开发者的这些努力收到了一定的效果，2013年9月，苹果对Bug Reporter系统进行重新设计，改进了它的UI和使用体验，但是，对于开发者们开放Radar的要求则未予满足，你仍然不知道你提交问题之后究竟发生了什么。不过，也有开发者对“Fix Radar or GTFO”运动并不以为然，像这篇所说的：其实开发者并不需要一个Radar，需要Radar的是苹果，如果Radar对于苹果来说工作得很好，那么就没什么问题。比如在是否开放Radar上面，如果开放Radar会造成一些不好的后果，比如Bug被恶意利用、Radar优先级被活跃用户干扰等等，那么还不如不开放。开发者需要做的是“file and forget（提交并遗忘）”，提交Bug已经尽到了开发者的责任，接下来的就留给苹果吧。是的，也许我们走过头了，如果我们知道，提交的Radar会被认真对待，那么其实没有必要要求更多，毕竟对于改进产品最迫切的是苹果，而不是开发者。所以，信息不对称是万恶之源，那么就让我们来看看，一个Radar被提交后，苹果是怎么处理的吧。苹果内部是如何处理Radar的？一个曾参观过苹果内部的开发者道：苹果内部有一个专门的Mac app用于处理提交的Bug，在这个app里面，苹果工程师能够对问题进行标记和分类，不同的工程师能对同一个问题进行讨论，最终进行优先级的评定，比如评定为“Show-Stopper”状态的问题是必须第一时间解决的，否则不会发布下一个更新。事实上，苹果非常重视提交到Bug Reporter的问题，一位曾在苹果工作过的开发者：所有的问题都会被很快的分类并进行讨论，只是问题是，讨论多涉及到苹果内部的技术，而由于苹果的保密措施，所以即使是讨论也是难以对外分享的。所以，你可以放心的提交Bug而无需担心它受到冷落，而另一方面，也不要太期待从苹果得到反馈，如果苹果修复了这个问题，那么你是幸运的；如果苹果没有修复，说明这个问题的优先级还不够高，工程师们有其它要做的事情。如果你认为你发现的问题很重要，你可以尝试一下上面提到的技巧。重要的是态度，其实你和苹果的目标是一致的，都想解决你提出的问题，所以没有必要闹得不愉快。据苹果最新的财报显示，中国已经是iPhone最大的发售地了，中国的iOS开发者数量也居世界前列，苹果本身也越来越重视中国。但相比之下，苹果软件在中国的本地化仍然存在一些问题，有不少问题值得报告；中国的iOS开发者也显得太低调，无论是开发者之间的交流，还是和苹果之间的交流都很少。我想，向苹果提交bug和功能需求是一种沟通和表达自己的手段，无论是对于开发者自己，还是对提高中国在苹果软件开发生态的地位都是有帮助的。所以还等什么呢？快去提交Radar吧！~参考链接：：Daniel Pasco的博客，讲解了如何提Radar，提Radar的技巧，以及一些范例。：另一篇关于提交Radar的文章，里面提到Radar系统的一些问题，以及提交Radar的tips。：一个功能需求的Radar范例。：“Fix Radar or GTFO”的官网，已有600+开发者提交了相同的Radar。：Hacker News上对于此运动的讨论，基本上大家对于Radar系统都不满意。：请自备梯子。对Radar系统缺乏透明度，开发者自己弄的一个变通方案。：同为开发者，对“Fix Radar or GTFO”的批评。：对苹果改进Bug Reporter的报道。本文转载自：（责编/唐小引）
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章如何合理地制造“BUG”并且查找BUG - 文章 - 伯乐在线
& 如何合理地制造“BUG”并且查找BUG
什么是BUG，简单点说就是，程序没有按照我们预想的方式运行。我比较喜欢把BUG分成两类：
没有Crash掉的
可能在平时的编程实践中，往往简单的把BUG与Crash基本等价了。而且我们很多精力也都放在解决Crash的Bug上面。而对于没有Crash掉的BUG，似乎没有过多的关注。但是，实际情况上那些让人痛彻心扉的“天坑”往往是那些没有Crash掉的BUG造成的，比如前一段时间OpenSSL心脏大出血。为什么这么说呢？且听我慢慢道来。
如何合理的制造BUG
Crash掉的BUG，用程序的死证明了你的程序存在问题，你必须抓紧时间来解决程序的问题了。而没有Crash掉的Bug，像是一个善于撒谎的人，伪装成可以正常运转的样子，让整个程序运行在一个不稳定的状态下。虽然外表看起来好好地（没有crash），但是里子早就烂透了，一旦报露出问题往往是致命的，比如OpenSSL的心脏大出血。这就是前人总结的“死程序不说谎”。
Crash不可怕，可怕的是程序没有Crash而是运行在一个不稳定的状态下，如果程序还操作了数据，那带来的危害将是灾难性的。
所以放心的让程序Crash掉吧，因为当他Crash掉的时候，你还有机会去修正自己的错误。如果没有Crash，那就有可能要给整个程序和产品收尸了。因此合理制造“BUG”的原则之一，也是最大的原则就是：尽量制造Crash的BUG，减少没有Crash的BUG，如果有可能将没有Crash掉的Bug转换成Crash的BUG以方便查找。
这个应该都比较熟悉，他的名字叫做“断言”。断言（assertion）是指在开发期间使用的、让程序在运行时进行自检的代码（通常是一个子程序或宏）。断言为真，则表明程序运行正常，而断言为假，则意味着它已经在代码中发现了意料之外的错误。断言对于大型的复杂程序或可靠性要求极高的程序来说尤其有用。而当断言为假的时候，几乎所有的系统的处理策略都是，让程序死掉，即Crash掉。方便你知道，程序出现了问题。
断言其实是“防御式编程”的常用的手段。防御式编程的主要思想是：子程序应该不因传入错误数据而被破坏，哪怕是由其他子程序产生的错误数据。这种思想是将可能出现的错误造成的影响控制在有限的范围内。断言能够有效的保证数据的正确性，防止因为脏数据让整个程序运行在不稳定的状态下面。
关于如何使用断言，还是参考《代码大全2》中“防御式编程”一章。这里简单的做了一点摘录，概括其大意：
1. 用错误处理代码来处理预期会发生的状况，用断言来处理绝不应该发生的状况。
2. 避免把需要执行的代码放到断言中
3. 用断言来注解并验证前条件和后条件
4. 对于高健壮性的代码，应该先使用断言再处理错误
5. 对来源于内部系统的可靠的数据使用断言，而不要对外部不可靠的数据使用断言，对于外部不可靠数据，应该使用错误处理代码。
1. 用错误处理代码来处理预期会发生的状况，用断言来处理绝不应该发生的状况。2. 避免把需要执行的代码放到断言中3. 用断言来注解并验证前条件和后条件4. 对于高健壮性的代码，应该先使用断言再处理错误5. 对来源于内部系统的可靠的数据使用断言，而不要对外部不可靠的数据使用断言，对于外部不可靠数据，应该使用错误处理代码。
而在IOS编程中，我们可以使用NSAssert来处理断言。比如：
- (void)printMyName:(NSString *)myName
NSAssert(myName == nil, @"名字不能为空！");
NSLog(@"My name is %@.",myName);
- (void)printMyName:(NSString *)myName&&{&&&&&&NSAssert(myName == nil, @"名字不能为空！");&&&&&&NSLog(@"My name is %@.",myName);&&}
我们验证myName的安全性，需要保证其不能为空。NSAssert会检查其内部的表达式的值，如果为假则继续执行程序，如果不为假让程序Crash掉。
每一个线程都有它自己的断言捕获器（一个NSAssertionHanlder的实例），当断言发生时，捕获器会打印断言信息和当前的类名、方法名等信息。然后抛出一个NSInternalInconsistencyException异常让整个程序Crash掉。并且在当前线程的断言捕获器中执行handleFailureInMethod:object:file:lineNumber:description:以上述信息为输出。
当时，当程序发布的时候，不能把断言带入安装包，你不想让程序在用户机器上Crash掉吧。打开和关闭断言可以在项目设置中设置：
在release版本中设置了NS_BLOCK_ASSERTIONS之后断言失效。
尽可能不要用Try-Catch
并不是说Try-Catch这样的异常处理机制不好。而是，很多人在编程中，错误了使用了Try-Catch，把异常处理机制用在了核心逻辑中。把其当成了一个变种的GOTO使用。把大量的逻辑写在了Catch中。弱弱的说一句，这种情况干嘛不用ifelse呢。
而实际情况是，异常处理只是用户处理软件中出现异常的情况。常用的情况是子程序抛出错误，让上层调用者知道，子程序发生了错误，并让调用者使用合适的策略来处理异常。一般情况下，对于异常的处理策略就是Crash，让程序死掉，并且打印出堆栈信息。
而在IOS编程中，抛出错误的方式，往往采用更直接的方式。如果上层需要知道错误信息，一半会传入一个NSError的指针的指针：
- (void) doSomething:(NSError* __autoreleasing*)error
if(error != NULL)
*error = [NSError new];
- (void) doSomething:(NSError* __autoreleasing*)error{&&&&...&&&&if(error != NULL)&&&&{&&&&&&&&*error = [NSError new];&&&&}&&&&....}
而能够留给异常处理的场景就极少了，所以在IOS编程中尽量不要使用Try-Catch。
（PS：见到过使用Try-Catch来防止程序Crash的设计，如果不是迫不得已，尽量不要使用这种策略）
尽量将没有Crash掉的BUG，让它Crash掉
上面主要讲的是怎么知道Crash的“BUG”。对于合理的制造“BUG”还有一条就是尽量把没有Crash掉的“BUG”，让他Crash掉。这个没有比较靠谱的方法，靠暴力吧。比如写一些数组越界在里面之类的。比如那些难调的多线程BUG，想办法让他Crash掉吧，crash掉查找起来就比较方便了。
总之，就是抱着让程序“死掉”的心态去编程，向死而生。
如何查找BUG
其实查找BUG这个说法，有点不太靠谱。因为BUG从来都不需要你去找，他就在那里，只增不减。都是BUG来找你，你很少主动去找BUG。程序死了，然后我们就得加班加点。其实我们找的是发生BUG的原因。找到引发BUG的罪魁祸首。说的比较理论化一点就是：在一堆可能的原因中，找到那些与BUG有因果性的原因（注意，是因果性，不是相关性）。
于是解决BUG一般可以分两步进行：
合理性假设，找到可能性最高的一系列原因。
对上面找到的原因与BUG之间的因果性进行分析。必须确定，这个BUG是由某个原因引起的，而且只由改原因引起。即确定特定原因是BUG的充分必要条件。
找到原因之后，剩下的事情就比较简单了，改代码解决掉。
合理性假设
其实，BUG发生的原因可以分成两类：
我们自己程序的问题。
系统环境，包括OS、库、框架等的问题。
前者找到了，我们可以改。后者就比较无能为力了，要么发发牢骚，要么email开发商，最后能不能被改掉就不得而知了。比如IOS制作framework的时候，category会报方法无法找的异常，到现在都没有解决掉。
当然，一般情况下导致程序出问题的原因的99.999999%都是我们自己造成的。所以合理性假设第一条：
首先怀疑自己和自己的程序，其次怀疑一切。
首先怀疑自己和自己的程序，其次怀疑一切。
而程序的问题，其实就是开发者自己的问题。毕竟BUG是程序员的亲子亲孙，我们一手创造了BUG。而之所以能够创造BUG，开发者的原因大致有三：
知识储备不足，比如IOS常见的空指针问题，发现很多时候就是因为对于IOS的内存管理模型不熟悉导致。
错心大意，比较典型的就是数组越界错误。还有在类型转化的时候没注意。比如下面这个程序：
//array.count = 9
for (int i = 100; array.count - (unsigned int)i & 10 ; )
//array.count = 9for (int i = 100; array.count - (unsigned int)i > 10 ; ){&&&&i++&&&&.....}
按道理讲，这应该是个可以正常执行的程序，但是你运行的话是个死循环。可能死循环的问题，你改了很多天也没解决。直到同事和你说array.count返回的是NSUInterge，当与无符号整形相间的时候，如果出现负值是回越界的啊。你才恍然大悟：靠，类型的问题。
这个就是思维方式的问题，但是也是问题最严重的。一旦发生，很难查找。人总是最难怀疑自己的思维方式。比如死循环的问题，最严重的是函数间的循环引用，还有多线程的问题。
但是庆幸的是绝大多数的BUG都是由于知识储备不足和粗心大意造成的。所以合理性假设的第二条：
首先怀疑基础性的原因，比如自己知识储备和粗心大意等人为因素，通过这些原因查找具体的问题。之后再去怀疑难处理的逻辑错误。
首先怀疑基础性的原因，比如自己知识储备和粗心大意等人为因素，通过这些原因查找具体的问题。之后再去怀疑难处理的逻辑错误。
有了上面的合理性怀疑的一些基本策略，也不能缺少一些基本的素材啊。就是常见的Crash原因，最后我们还是得落地到这些具体的原因或者代码上，却找与BUG的因果性联系。
访问了一个已经被释放的对象，比如
NSObject * aObj = [[NSObject alloc] init];
[aObj release];
NSLog(@"%@", aObj);
NSObject * aObj = [[NSObject alloc] init]; [aObj release]; NSLog(@"%@", aObj);
访问数组类对象越界或插入了空对象
访问了不存在的方法
字节对齐,(类型转换错误)
多线程并发操作
Repeating NSTimer
合理性假设第三条：尽可能的查找就有可能性的具体原因。
因果性分析
首先必须先说明的是，我们要找的是“因果性”而不是“相关性“。这是两个极度被混淆的概念。而且，很多时候我们错误的把相关性当成了因果性。比如，在解决一个多线程问题的时候，发现了一个数据混乱的问题，但是百思不得其解。终于，有一天你意外的给某个对象加了个锁，数据就正常了。然后你就说这个问题是这个对象没有枷锁导致的。
但是，根据上述你的分析，只能够得出该对象枷锁与否与数据异常有关系，而不能得出就是数据异常的原因。因为你没能证明对象加锁是数据异常的充分必要条件，而只是使用了一个单因变量实验，变量是枷锁状态，取值x=[0，1],x为整形。然后实验结果是枷锁与否与数据异常呈现正相关性。
相关性：在概率论和统计学中，相关（Correlation，或称相关系数或关联系数），显示两个随机变量之间线性关系的强度和方向。在统计学中，相关的意义是用来衡量两个变量相对于其相互独立的距离。在这个广义的定义下，有许多根据数据特点而定义的用来衡量数据相关的系数。
因果性：因果是一个事件（即“因”）和第二个事件（即“果”）之间的关系，其中后一事件被认为是前一事件的结果。
相关性：在概率论和统计学中，相关（Correlation，或称相关系数或关联系数），显示两个随机变量之间线性关系的强度和方向。在统计学中，相关的意义是用来衡量两个变量相对于其相互独立的距离。在这个广义的定义下，有许多根据数据特点而定义的用来衡量数据相关的系数。&&&因果性：因果是一个事件（即“因”）和第二个事件（即“果”）之间的关系，其中后一事件被认为是前一事件的结果。
错误的把相关性等价于因果性。不止是程序员，几乎所有人常见的逻辑错误。为了加深认识，可以看一下这篇小科普：。
因果性分析的首要问题就是，别被自己的逻辑错误欺骗，正确的分辨出相关性和因果性之间的区别。不要把相关性等价于因果性。
之后便是因果性分析的内容了，之前一直反复说，因果性分析的目的就是确定特定原因是BUG发生的充分必要条件。那么确定这个事情，就需要两步：
充分性证明
必要性证明
关于充分性证明，这个基本上就是正常的逻辑推理。基本思路就是，能够还原出BUG出现的路径，从原因到BUG发生处的代码，走了怎样的函数调用和控制逻辑。确定了这个基本上就能够证明充分性。一般情况下根据Crash的堆栈信息能够，非常直接的证明充分性。
关于必要性证明，这个就比较困难了。充分性和必要性的定义如下：当命题“若A则B”为真时，A称为B的充分条件，B称为A的必要条件。那么必要性就是，BUG能够作为导致BUG的原因的原因。这个说法比较拗口。换种说法，就是你得确认这个BUG能够解释原因，这个BUG就是而且只是这个原因造成的。
只有证明了充分必要性，才能算是真正找到了BUG的原因。
关于作者：
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2017 伯乐在线}