Question

我现在正在编写ios应用程序一段时间。但是我的应用程序仍然会定期崩溃，并且需要时间才能使它们非常稳定。我觉得这很烦人。

那么，是否有关于防撞编程ios app的编程模式？

Answer 1

调高编译器警告。删除所有警告。
运行静态分析器。删除所有警告。
使用GuardMalloc和/或Scribbling运行。
删除所有泄漏
删除所有Zombies
写单元测试
编写高级别的实时错误检测（例如断言）
在添加功能之前修复错误。
使用源代码管理和持续集成。
读取。提高。

Answer 2

1）使用ARC。

ARC有一个很小的学习曲线，我在SO上读到的一个大问题是人们实例化对象但忘记将对象分配给强大的ivar（或属性），因此对象神秘地消失了。无论如何，这种好处是如此引人注目，你应该掌握这一点。当你这样做时，你必须保持原样的大部分内存管理功能都会消失。

2）建立清洁

构建时永远不会有警告。如果你有一堆，当一个真正的问题出现时，它会被埋没在你用来忽视的残骸中。专业程序员打造干净。

3）使用Analyze

Xcode / llvm有一个非凡的分析器 - 使用它 - 它在Product菜单项下。然后清理它给你的每一个警告。

4）使用正确的配置

我总是有Release（或Distribution）配置，ReleaseWithAsserts和Debug。我在使用lldb时只使用Debug，因为代码要大得多，并且它的执行方式与优化的编译方式不同。 ReleaseWithAsserts与Debug类似，但Debug = 1预处理器标志被删除，优化器设置为-Os（Release的默认值）。

最后，发布/分发配置在预处理宏中具有以下内容：

NS_BLOCK_ASSERTIONS=1 NDEBUG

第一个关闭所有'NSAssert（）'行，第二个关闭所有'assert（）'语句。这样，您的代码

中没有任何断言处于活动状态

5）使用大量的断言。

断言是作为程序员可以拥有的最好的朋友之一。我在这里看到很多问题如果程序员只使用它们就永远不会写出来。开销就是键入它们，因为（在我的使用中）它们是在Release配置中编译的。

每当你从另一个来源获得一个对象时，断言它的存在（即：

MyObject *foo = [self someMethod];
assert(foo);

这很容易输入，但是当nil对象在以后导致数千条指令出现问题时，可以节省数小时的调试时间。你也可以在课堂上断言：

MyObject *foo = [self someMethod];
assert([foo isMemberOfClass:[MyObject class]]);

当您从字典中提取对象时，这尤其有用。

您可以在方法的开头放置断言，以验证您收到的对象也不是零。

您可以声明某个变量具有值：

assert(i>1 && i<5);

同样，除了Release / Distribution配置之外，assert都是“live”，但是在那个配置中它们被编译出来。

NSAssert类似 - 但您必须使用不同的宏，具体取决于参数的数量。

NSAssert(foo, @"Foo was nil");
NSAssert1(foo, @"Foo was nil, and i=%d", i);
...

6）使用选择性日志来确保应该发生的事情

您可以定义自己的Log宏，该宏将针对Release / Distribution进行编译。将其添加到您的pch文件：

#ifndef NDEBUG

#define MYLog NSLog

#else

#define MYLog(format, ...)

#endif

这指出了另一点 - 你可以使用：

#ifndef NDEBUG
...
#endif

阻止执行更复杂检查的一些代码 - 它只对您的开发版本有效，而不是为发布/分发。

Answer 3

你可能已经这样做了，但这就是我的工作：

使用调试器/模拟器转到应用程序中的每个屏幕，然后选择“模拟内存警告”。返回上一屏幕。这会导致重新分配viewDidLoad中的现有UIView对象和变量赋值（这可能导致错误的指针引用）。
确保使dealloc中的所有正在运行的计时器无效。
如果对象A使自己成为对象B的委托，请确保在对象A的dealloc中清除它。
请务必清除dealloc中的任何通知观察者。

如何制作抗崩溃的ios应用程序

3 个答案: