Tag: 崩溃
iOS 9.0、9.1、9.2上发生奇怪的崩溃
在具有Xcode 8和Swift 3的设备上调试时，显示具有Adobe RGB（1998）色彩空间的图像对我来说是可行的，但在iOS 9上没有发布。更改色彩空间使其可以工作。 —安德鲁（Andrew）2016年11月16日在16:59 让我们从发生在我身上的事情开始。 有一天，我收到用户的一封电子邮件，她说应用程序不断崩溃。 多亏了Fabric，我知道她在使用iPhone 6 plus和iOS 9.2。 从崩溃日志中，我知道加载子视图后应用程序崩溃的唯一线索，但是我无法在调试和发布模式下从自己的角度重现它。 环顾四周后，我可以仅通过存档和导出特定设备（iOS 9.0、9.1、9.2）进行复制。 看来这使我的生活更轻松，但这只是故事的开始。 导出ipa文件所需的时间太长，因此一旦尝试执行某些操作，则需要五到十分钟的时间来检查结果。 不幸的是，崩溃日志使我误入歧途。 它显示了相同崩溃点的不一致轨迹（您可以在本文的和处找到一些示例），并且它随机发生在不同位置。 我以为是内存泄漏问题，或者是自定义字体，自定义UI或情节提要等问题。 经过三天的尝试和失败，我找到了一个帖子。 这与我的情况并不完全相似。 就我而言，使用电缆进行调试时不会在模拟器或设备中发生，没有与“ ERROR ITMS-90682：Invalid Bundle”有关的线索。 Xcode 8在iOS 9.2及更低版本上崩溃 当我使用Xcode 8 GM Seed构建我的应用程序并在设备或模拟器下的iOS 9.2上运行它时，我感到很奇怪…… stackoverflow.com 但是，我决定像没有希望的猴子那样尝试脚本，但是很惊讶它正常工作。 #!/bin/bash DIRECTORY=$1 echo “——————————” echo “Passed Resources with xcassets folder argument is ” echo “——————————” echo “Processing asset:” find […]
图片如何使我们的APP崩溃
最近，我们的团队遇到了一个特例，这使我们发疯。 在我们发布新版本的应用程序之前，一切看起来都很不错。 但是在接下来的几个小时里，我发现我不断收到很多警告信，似乎出了点坏事……哦！ 没有！ 它们每个都是崩溃报告，并迫使我们进入“值班”模式。 这是细节… 在调查开始时，我们首先检查崩溃报告中的每个不同的调用堆栈线程。 它们都不容易解决，看起来每次崩溃都发生在代码的不同部分。 但是，它们具有与“ 自动布局”和“ 图像”相关的一些共同特征。 我们将继续检查这些报告，并找到另一个线索：这些用户正在使用iOS 9.2 ！ 我认为这不是一个随机的崩溃案例。 我们改变了方式，并开始通过互联网发现相关问题。 我使用以下关键字搜索： iOS9.2, crash, FBSSerialQueue ，并在下面的链接中讨论了有关通过App Store和TestFlight发布后崩溃的信息。 它还引起我们的注意，只有通过App Store下载应用程序时才会发生此问题。 应用程序在启动时立即崩溃。.仅通过TestFlight或Store发行时在iOS9中崩溃… 我有一个iPhone应用程序，仅在通过TestFlight或App Store发布后才在iOS9设备上崩溃。 stackoverflow.com “错误ITMS-90682：无效的捆绑软件-如果应用程序支持iOS 8或更早版本，则’Payload / XXXXX / Assets.car’上的资产目录不能包含16位或P3资产。”之前。 但是，将应用程序提交到iTunes Connect时，我们没有看到此错误。 详细信息是Apple允许开发人员在iOS 9.3版本之后使用具有16位或P3资产的扩展RGB颜色作为图像格式。 但是那些低于iOS 9.3版本的应用将导致无法预料的错误。 目前，我们知道应用程序中会发生什么。 我们重新检查代码中的每一行， 那些与AutoLayout相关的代码正在调整图像位置。 因此问题暴露了，使用iOS 9.0到9.2的用户将在打开我们的产品后立即崩溃。 我们必须调查以下两种不同的途径： 如何解决此问题？ 以及如何防止它再次发生？ 第一个问题很容易解决，后一个问题需要一些技巧。 我们可以回到链接并找到另一个讨论线程： ITMS-90682：不能包含16位或P3资产…| | 苹果开发者论坛 嗨，我刚刚开始在testflight提交中看到此错误（资产没有更改）（我们有仅限iOS10的代码）… forums.developer.apple.com […]
BUGS BUSTERS
最佳iOS崩溃报告工具 一个真正的男人需要接受他并不完美。 大多数情况下，开发人员是男性，因此他们也不是完美的，有时您可能会发现应用程序中的错误。 他们尽力构建没有任何错误的应用程序，但通常情况下，错误会在发布后的一段时间内就已经暴露出来。 有时，此类错误会导致崩溃，而这是没有用户喜欢的。 这种错误并不是偶然地以这种特殊昆虫命名的，因为您感到的烦恼几乎就像被长腿跳屁股吸血性掠食性刺客咬伤一样。 这些向后弯曲的昆虫主要生活在热带地区或任何具有伪装和防护措施的栖息地，因此它们可以爬入墙壁并从其藏身处袭击您，而这些错误却发生在计算机程序和系统中。 它们会干扰源代码，设计或框架中现有系统的功能，导致系统产生意外的挫折并触发意外行为并最终崩溃。 不过，请放心，因为有许多出色的iOS崩溃报告工具可以帮助您将血腥的bug排除在外！ 它们会显示崩溃和登录详细信息，以便您以后进行查看，甚至向您发送电子邮件通知，告知崩溃发生的时间和频率。 总结在系统中产生崩溃或无效输出的错误的报告通常称为错误报告，缺陷报告，故障报告，问题报告，故障报告，变更请求等。 随着时间的流逝，移动应用程序崩溃报告工具变得更加灵活，并且对开发人员更加友好。 它们变得易于集成，并提供了可用性，新功能和用户体验。 从用户的角度来看，崩溃超出了简单的烦恼范围。 当您的应用程序由于故障突然停止运行而没有任何反馈时，通常会导致数据丢失和用户烦恼。 使用崩溃报告器工具可使您从应用程序中收集记录中需要的所有信息，以解决这些小问题。 崩溃报告工具软件结合了两个元素，形成一个连贯的整体：报告库和服务器端收集器。 报告库的任务是介绍有关崩溃的详细信息。 服务器端组件的职责是收集崩溃数据分析和统计信息，并以适当的方式正确显示出来。 无论何时何地，都有崩溃报告工具的配方。 我们经常使用或在特定情况下使用的此故障分析中包含的所有工具选项。 这就是为什么我们没有选择奖牌获得者并提供评估选项。 目的是奖励每种工具的优势并展示其劣势。 然后，您可以得出结论，哪种崩溃报告框架可以解决潜在的应用崩溃问题。 Crashlytics （免费，crashlytics.com） Crashlytics，一个著名的库，被发现可广泛用于iOS应用程序崩溃报告。 Crashlytics最近被Twitter收购，它密切关注iOS应用中的所有崩溃活动，并立即将它们报告给服务器，并仔细查看每次崩溃的令人不安的画面。 Crashlytics在这方面非常高效，因为它可以找到导致应用程序崩溃的确切代码行，可以查看内存堆栈跟踪，因此您可以在相同的环境下重新创建崩溃。 Crashlytics最引人注目的是它的主动性。 与大多数其他工具不同，它考虑了诸如崩溃频率之类的问题并定义了“影响级别”。当特定崩溃发生时，它将通知您任何更改，并分析故障的所有后续后果。 当一遍又一遍报告同一崩溃时，Crashlytics会跟踪该数据，就像“嘿，您尚未解决一个尚未解决的问题，它开始变得值得一提。”从字面上看，崩溃，需要先处理其他事情。 对于每个用户，Crashlytics会立即为每个用户立即向所有员工发送消息，以确保制定了程序并且不会发现任何应用程序崩溃事件。 该工具易于使用，具有经过精心设计的应用程序仪表板，以及系统中发生的应用程序崩溃的所有详细信息以及崩溃的位置， 日期和时间 ，易于使用。 Crashlytics不仅报告崩溃并显示错误，而且还提供了一个界面，允许用户并简化对其的访问。 例如，如果您的应用程序的较新版本中解决了某种类型的崩溃，则可以将其标记为已修复并从仪表板中删除。 然后，Crashlytics将在您的早期版本的应用中跳过此类崩溃。 Crashlytics提供了有关您的应用程序正在使用的设备的详细信息，可帮助您了解确切的运行环境以解决问题。 这些信息包括： 内存 操作系统版本 取向 电池状态 设备是否越狱 磁盘空间 Crashlytics支持与第三方应用程序维护（如Campfire，JIRA，Hipchat，Pivotal Tracker，Redmine和Pager Duty）的集成。 Crashlytics的唯一缺点是它不支持移动应用程序分发功能。 Instabug （$ 0- $ […]
使用Firebase Crashlytics修复崩溃
换一种说法： 在装有iOS 11的任何类型的iPhone上，前台都会发生崩溃 这是我们的出发点。 解决崩溃 在Firebase Crashlytics引入面包屑之前，您可能会与支持团队聊天并向他们询问以下问题： 崩溃是否可以重现？ 复制路径总是一样吗？ 崩溃到底发生在哪里？ 尤其是当崩溃导致堆栈跟踪时，几乎没有任何结果： 现在，有了新的面包屑，我们只需打开“ Logs页面，就可以在崩溃发生之前看到用户的面包屑。 它告诉我们用户在启动后立即收到了转移（存储桶） 最终接收失败： 这比堆栈跟踪给我们的要多得多！ 复制路径是否一致？ 通过在会话之间导航并比较面包屑，我们可以轻松地比较会话并定义每个用户的复制路径是否相同。 这将使崩溃的范围进一步缩小，并使我们有可能更快地重现崩溃。 使用自定义参数 面包屑的妙处在于它们可以为您提供更多信息。 我们可以看到接收到的传输是一个简短的URL。 接收到的传输的类型是不带密码的移动传输： 结论 使用所有这些信息可以帮助我们更快地解决崩溃问题。 事实证明，我们以错误的方式解雇了一个视图控制器。 有时，我们甚至无法通过面包屑来解决崩溃问题。 这是我们团队的游戏规则改变者，使我们更接近拥有100％无崩溃用户的梦想。 更快地解决崩溃问题也意味着需要更多时间来开发功能。 解决崩溃更快 解决最难的崩溃 腾出更多时间来开发功能，而不是解决崩溃问题。
使用Thread Sanitizer（TSan）调试iOS Data Race EXC_BAD_ACCESS错误
如果您是iOS开发人员，则EXC_BAD_ACCESS会遇到EXC_BAD_ACCESS崩溃。 如果您已经尝试启用NSZombie而没有任何运气（因此排除了内存问题/指针悬空），则可能的原因可能是代码中的数据争用情况。 这篇文章讨论了什么是数据争用条件，以及如何使用Thread Sanitizer调试问题。 什么是数据竞争条件？ 当多个线程在不同步的情况下访问同一内存位置时发生数据争用情况，并且这些访问中的至少一项是写操作。 众所周知，数据争用条件很难调试，因为它们与时间有关，并且不会在每次运行代码时发生。 进入—线程消毒剂。 什么是线程消毒剂？ Thread Sanitizer（或TSan）是LLVM工具系列的一部分，该工具结合了编译时检测和运行时监视以检测代码中的线程错误。 它是在Xcode 8中引入的，并支持Objective C和Swift。 它可以检测多种类型的线程错误，其中之一是数据争用条件。 在启用TSan的情况下运行– a）点击申请方案，然后点击“编辑方案” b）在“诊断”选项卡下的“运行时清理程序”部分中，启用“线程清理程序”复选框。 您也可以通过选中“问题暂停”复选框来选择在检测到数据争用时暂停程序执行。 （注意-“ Thread Sanitizer”选项仅在您在iOS Simulator上运行时才可用。在设备上不支持） c）运行您的应用程序并执行导致EXC_BAD_ACCESS崩溃的步骤。 如果您的应用程序具有数据争用条件，则TSan将检测到它并将其记录到控制台。 （请注意，TSan可能不会在一次尝试中检测到所有数据争用条件。在这种情况下，请尝试执行重复多次的步骤）。 解释TSan日志– 数据争用条件的TSan日志如下所示（重要部分以红色突出显示）– TSan日志包含有关哪些确切线程参与了数据竞争条件的信息。 在上面的示例中， main thread和thread T7参与了数据竞争条件。 日志包含每个参与线程的堆栈跟踪。 记录的堆栈跟踪中的星号（*）指向访问/更改数据的确切代码。 在上面的日志中，设置/读取someBool变量时发生了数据争用。 另外，如果您在调用堆栈中上updateBoolValue()一级，您将获得访问/ updateBoolValue()问题的内存位置的确切方法（ startConsumer()和updateBoolValue() ） 该日志还告诉您所涉及的内存位置是否存在于程序的堆/堆栈/数据段中，以及哪个线程分配了该内存。 在上面的示例中，TSan日志状态为- Location is heap block of size 880 at 0x7b5c00000380 allocated by main thread […]
