如何给苹果提交Bug或功能需求?

苹果的BugReporter是开发者反馈系统和软件故障的主要渠道。通过提交详细的问题描述,开发者可以帮助苹果识别并优先解决重要的bug。尽管存在反馈不透明等问题,苹果内部对此高度重视并设有专门流程处理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

allowtransparency="true" frameborder="0" scrolling="no" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-01-30%2F2823775-apple-bug-reporter-tool&type=3&count=&appkey=&title=%E5%9C%A8%E8%8B%B9%E6%9E%9C%E7%9A%84Bug%20Reporter%E4%B8%AD%EF%BC%8C%E5%BC%80%E5%8F%91%E8%80%85%E5%8F%AF%E4%BB%A5%E6%8F%90%E4%BA%A4%E8%87%AA%E5%B7%B1%E5%8F%91%E7%8E%B0%E7%9A%84%E4%BB%BB%E4%BD%95%E9%97%AE%E9%A2%98%E6%88%96%E5%8A%9F%E8%83%BD%E9%9C%80%E6%B1%82%EF%BC%8C%E5%B9%B6%E6%9F%A5%E7%9C%8B%E5%B7%B2%E6%8F%90%E4%BA%A4%E9%97%AE%E9%A2%98%E7%9A%84%E5%A4%84%E7%90%86%E6%83%85%E5%86%B5%E3%80%82%E8%BF%99%E4%B8%AABug%20Reporter%E5%87%A0%E4%B9%8E%E6%98%AF%E5%BC%80%E5%8F%91%E8%80%85%E5%92%8C%E8%8B%B9%E6%9E%9C%E4%B9%8B%E9%97%B4%E5%85%B3%E4%BA%8E%E7%B3%BB%E7%BB%9F%E5%92%8C%E8%BD%AF%E4%BB%B6%E6%95%85%E9%9A%9C%E7%9A%84%E5%94%AF%E4%B8%80%E5%8F%8D%E9%A6%88%E6%B8%A0%E9%81%93%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1426732433913" width="22" height="16"> 摘要:在苹果的Bug Reporter中,开发者可以提交自己发现的任何问题或功能需求,并查看已提交问题的处理情况。这个Bug Reporter几乎是开发者和苹果之间关于系统和软件故障的唯一反馈渠道。

自从Swift推出以来,很多开发者已经第一时间尝鲜并且尝试用它进行开发了。不过,由于Swift还是个演进中的语言,Xcode对它的支持并不完善,偶尔会出这样那样的小问题。有些开发者在发现问题后,顶多发个博客记录一下然后就不管了,我们是否有更好的办法,比如给苹果提交这个bug,让它快速修复呢?


答案是有的,并且仅对苹果的开发者开放,即苹果的Bug Reporter系统

Radar or GTFO

在苹果的Bug Reporter里,你可以提交你发现的问题或者功能需求,你也可以查看你提交的问题的处理情况。问题会被分配一个ID,并带上rdar://10993759这样的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)

具体内容可以看苹果关于Bug Reporting的文档

提交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系统,发起了“Fix Radar or GTFO”活动,呼吁开发者提交重复性的Radar,想让苹果改进这个Bug收集系统,让它变得更加开放。另外一些人则做了一个openradar,开发者在提交到官方的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吧!~

参考链接:

本文转载自:idlelife


【资源说明】 1.项目代码功能经验证ok,确保稳定可靠运行。欢迎下载使用!在使用过程中,如有问题建议,请及时私信沟通。 2.主要针对各个计算机相关专业,包括计科、信息安全、数据科学与大数据技术、人工智能、通信、物联网等领域的在校学生、专业教师企业员工使用。 3.项目具有丰富的拓展空间,不仅可作为入门进阶,也可直接作为毕设、课程设计、大作业、初期项目立项演示等用途。 4.当然也鼓励大家基于此进行二次开发。 5.期待你能在项目中找到乐趣和灵感,也欢迎你的分享和反馈! 本文介绍了基于QEM(Quadric Error Metrics,二次误差度量)的优化网格简化算法的C和C++实现源码及其相关文档。这一算法主要应用于计算机图形学领域,用于优化三维模型的多边形数量,使之在保持原有模型特征的前提下实现简化。简化的目的是为了提高渲染速度,减少计算资源消耗,以及便于网络传输等。 本项目的核心是网格简化算法的实现,而QEM作为该算法的核心,是一种衡量简化误差的数学方法。通过计算每个顶点的二次误差矩阵来评估简化操作的误差,并以此来指导网格简化过程。QEM算法因其高效性和准确性在计算机图形学中广泛应用,尤其在实时渲染和三维打印领域。 项目代码包含C和C++两种语言版本,这意味着它可以在多种开发环境中运行,增加了其适用范围。对于计算机相关专业的学生、教师和行业从业者来说,这个项目提供了丰富的学习和实践机会。无论是作为学习编程的入门材料,还是作为深入研究计算机图形学的项目,该项目都具有实用价值。 此外,项目包含的论文文档为理解网格简化算法提供了理论基础。论文详细介绍了QEM算法的原理、实施步骤以及与其他算法的对比分析。这不仅有助于加深对算法的理解,也为那些希望将算法应用于自己研究领域的人员提供了参考资料。 资源说明文档强调了项目的稳定性和可靠性,并鼓励用户在使用过程中提出问题建议,以便不断地优化和完善项目。文档还提醒用户注意查看,以获取使用该项目的所有必要信息。 项目的文件名称列表中包含了加水印的论文文档、资源说明文件和实际的项目代码目录,后者位于名为Mesh-Simplification-master的目录下。用户可以将这些资源用于多种教学和研究目的,包括课程设计、毕业设计、项目立项演示等。 这个项目是一个宝贵的资源,它不仅提供了一个成熟的技术实现,而且为进一步的研究和学习提供了坚实的基础。它鼓励用户探索和扩展,以期在计算机图形学领域中取得更深入的研究成果。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值