3

私は今しばらくiOSアプリをプログラミングしています。しかし、それでも私のアプリは定期的にクラッシュし、非常に安定するまでに時間がかかります。これは非常に面倒です。

それで、クラッシュプルーフプログラミングiosアプリに関するプログラミングパターンはありますか?

4

3 に答える 3

4
  • コンパイラの警告を上げます。すべての警告を削除します。
  • 静的アナライザーを実行します。すべての警告を削除します。
  • GuardMalloc および/または Scribbling を使用して実行します。
  • すべてのリークを削除
  • すべてのゾンビを削除
  • 単体テストを書く
  • 高レベルのライブ エラー検出 (アサーションなど) を記述します。
  • 機能を追加する前にバグを修正します。
  • ソース管理と継続的インテグレーションを使用します。
  • 読んだ。向上。
于 2012-08-13T23:31:38.357 に答える
1

1) ARC を使用します。

ARC の学習曲線は短く、私が SO について読んだ大きな問題は、人々がオブジェクトをインスタンス化したが、そのオブジェクトを強力な ivar (またはプロパティ) に割り当てるのを忘れたため、不思議なことにオブジェクトが消えてしまうことです。いずれにせよ、この利点は非常に魅力的であるため、これをマスターする必要があります。そうすれば、すぐに保持しなければならないすべてのメモリ管理のほとんどがなくなります。

2) クリーンなビルド

ビルド時に警告が表示されることはありません。たくさんある場合、実際の問題が発生すると、無視することに慣れた粗雑な行に埋もれてしまいます。プロのプログラマーはクリーンにビルドします。

3) 分析を使用する

Xcode/llvm には驚異的なアナライザーがあります - それを使用してください - それは Product メニュー項目の下にあります。次に、表示されるすべての警告をクリーンアップします。

4) 適切な構成を使用する

私は常にリリース (またはディストリビューション) 構成、ReleaseWithAsserts、およびデバッグを持っています。コードがはるかに大きく、最適化されたコンパイルとは異なる方法で実行されるため、lldb を使用する場合にのみデバッグを使用します。ReleaseWithAsserts は Debug に似ていますが、Debug=1 プリプロセッサ フラグが削除され、オプティマイザが -Os (リリースのデフォルト) に設定されます。

最後に、リリース/配布構成には、前処理マクロに次のものがあります。

NS_BLOCK_ASSERTIONS=1 NDEBUG

1 つ目はすべての 'NSAssert()' 行をオフにし、2 つ目はすべての 'assert()' ステートメントをオフにします。このようにして、出荷されたコードでアクティブなアサートはありません

5) 大量の assert を使用します。

アサートは、プログラマーにとって親友の 1 つです。ここには、プログラマーだけが使用するだけでは決して書かれないような質問がたくさんあります。（私の使用法では）リリース構成でコンパイルされているため、オーバーヘッドはそれらを入力することです。

別のソースからオブジェクトを取得するたびに、その存在をアサートします (つまり:

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

これは非常に簡単に入力できますが、数千命令後に nil オブジェクトが原因で問題が発生した場合にデバッグに費やす時間を節約できます。クラスでもアサートできます。

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

これは、辞書からオブジェクトを引き出す場合に特に便利です。

メソッドの先頭にアサートを配置して、nil 以外のオブジェクトを受け取ったことを確認することもできます。

一部の変数に値があるとアサートできます。

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

繰り返しますが、Release/Distribution 構成以外のすべてで、アサートは「ライブ」ですが、その構成ではコンパイルされています。

NSAssert も同様ですが、引数の数に応じて異なるマクロを使用する必要があります。

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

6) 選択的なログを使用して、発生するはずのことが確実に行われるようにします。

リリース/配布用にコンパイルされる独自のログ マクロを定義できます。これを pch ファイルに追加します。

#ifndef NDEBUG

#define MYLog NSLog

#else

#define MYLog(format, ...)

#endif

これは別のポイントを指摘しています-使用できます：

#ifndef NDEBUG
...
#endif

より複雑なチェックを行うコードの一部をブロックします。これは、リリース/配布ではなく、開発ビルドに対してのみアクティブになります。

于 2012-08-14T00:41:43.757 に答える
0

あなたはすでにこれらのことをしているかもしれませんが、私がしていることは次のとおりです。

  1. デバッガー/シミュレーターを使用してアプリのすべての画面に移動し、[Simulate Memory Warning] を選択します。前の画面に戻ります。これにより、viewDidLoad 内の既存の UIView オブジェクトと変数の割り当てが再割り当てされます (不適切なポインター参照が発生する可能性があります)。

  2. dealloc で実行中のタイマーを必ず無効にしてください。

  3. オブジェクト A がオブジェクト B のデリゲートになっている場合は、オブジェクト A の割り当て解除でそれをクリアしてください。

  4. dealloc 内の通知オブザーバーを必ずクリアしてください。

于 2012-08-14T00:03:49.473 に答える