8

多くのカスタムUIViewを含むviewcontrollerがあります。InterfaceBuilder (IB) を使用して定義しようとしたカスタム UIView を、次のコードを使用して initWithFrame 内にロードします。

NSArray *xib=[[NSBundle mainBundle] loadNibNamed:@"DayView" owner:self options:nil];

ビュー コントローラーの動作が非常に遅いため、カスタム uiview の項目をプログラムでロードすることにしました。出来上がり、速度は約 7 倍になりました。

XIB ファイルのロードと「クリーンな」コードの使用の違いがこれほど大きいのはなぜですか? 私が考えることができた最初の仮説は、IB はデフォルトで多くのプロパティを設定しているのに対し、コードで定義するときは単純に nil であるというものでした。しかし、それだけではパフォーマンスの大きな違いを説明できません! パフォーマンス上の理由から IB を使用しないように明示的に警告する投稿は見つかりませんでした。

編集:私はこのリンクを見つけたので、ディスクからxibファイルがロードされる時期について興味深いことを説明するこのブログ投稿を見つけました。ディスクからの読み込みが違いを説明していると思います。/K

4

1 に答える 1

8

ここに私が得たいくつかのポイントがあり、私の経験とグーグルからも見つけました。

=> I've done it both ways and here's my two sense:

あなたの見解が比較的単純で、それが大きく変わることはないだろうと確信しているなら; それからXib離れます。そうでない場合は、少なくとも 3 つの大きな利点があるため、プログラムを使用することをお勧めします。

1)すべてが舞台裏でどのように機能しているかについて、より深い知識を得ることができます。これは、問題が発生した場合のデバッグに大いに役立ちます。

2）すべてを完全に制御およびカスタマイズできるため、変更があれば簡単に実装できます

3)混乱が少ない。これは個人的な好みかもしれませんが、ボタンなどから多くのアクションが呼び出される場合、インターフェースビルダーの矢印ジグザグフラバルーは、プログラムよりもはるかに混乱します。

=>コントロールをプログラム的に定義することは、XIBを使用するよりも時間がかかるプロセスです。その場ですべてのコントロールと位置などを作成するためです。

=>プログラムによるビューのロードに関連するファイルは、xib ファイルの約半分のセカンダリ メモリを使用することにも気付きました。それがより大きなアプリケーションに変換されるかどうかはわかりませんが、より大きなアプリケーションでは考慮すべきことかもしれません

=>私はいくつかの読書をしていましたが、プログラム的に有利な取引を封印するようなものを見つけたと思います。Xib ファイルは暗黙的に imageNamed メソッドを使用してイメージをメモリにロードしますが、これにはよく知られたキャッシング「機能」があり、メモリに問題があります。また、IBOutlets は重大なメモリ管理の問題であると聞いています。

これらのインターフェイスビルダーはすべて非常に優れたツールですが、自分が何をしているのかわからない場合や、それらのツールが何をしているのかわからない場合は、

1. 何も学ばない

2. 後でコードに深刻な問題を引き起こす可能性があります

そして、すべてがどのように機能するかを理解したらすぐに、これらの小さなヘルパーを使用しても問題ありません...

私はhtml、flex、swing、cocoa touchを学ぶときに同じことを経験しました...そして最初は少し時間がかかるかもしれませんが、それを理解してヘルパークラス/メソッドを書くことができれば、物事は非常に速くうまくいくでしょう.

Just found some usefull information/tips about xib:

Nib ファイルを小さく保つ Xcode のほとんどの新しいプロジェクトには、1 つまたは 2 つの構成済み nib ファイルが付属しています。Interface Builder を初めて使用する多くの開発者が犯す間違いは、アプリケーションのすべてのウィンドウとメニューをこれらの 1 つまたは 2 つの nib ファイルに配置することです。間違いの理由はしばしば利便性です。(テンプレート プロジェクトは通常、事前構成された nib ファイルを自動的にロードするため、開発者は nib ロード コードをさらに追加する必要がなくなります。) 残念ながら、この便利さに頼ると、多くの場合、パフォーマンスが低下し、アプリケーションのメモリ負荷が増加する可能性があります。

nib ファイルがメモリにロードされるとき、それは全か無かの試みです。nib-loading コードには、ファイル内のオブジェクトの数や重要なオブジェクトを知る方法がないため、ファイル全体をメモリにロードする必要があります。このメモリ内データから、個々のオブジェクトがインスタンス化されます。Cocoa および iPhone アプリケーションの場合、nib ファイル内のすべてのオブジェクトがすぐにインスタンス化されるため、アウトレットとアクションの接続を再確立できます。アプリケーションが最初に nib-file オブジェクトの一部のみを使用する場合、すべてのオブジェクトをメモリに保持するのは無駄です。

すべてのプロジェクトで、特定の状況ですぐに必要なオブジェクトのみが含まれるように、各 nib ファイルを設計することをお勧めします。メモリにロードされると、そのような nib ファイルは可能な限り最小量のメモリを使用しながら、ジョブを完了するために必要なすべてのものを保持します。nib ファイルを整理する際に考慮すべき設計上の選択肢をいくつか示します。

アプリケーションのメイン nib ファイルの場合は、メニュー バーのみを含めます (iPhone アプリケーションの場合は、メイン ウィンドウのみを含めます)。

Mac OS X のドキュメント nib ファイルの場合、ドキュメント ウィンドウと、そのウィンドウを表示するために必要なオブジェクト (コントローラーなど) のみを含めます。

その他の nib ファイルの場合は、表示する単一のウィンドウやパネルなど、重要なオブジェクトに nib ファイルの焦点を合わせます。nib ファイル内の他のすべてのオブジェクトは、そのウィンドウまたはパネルの即時操作を容易にする必要があります。

埋め込まれたビュー階層を変更するウィンドウで、階層が頻繁に変更されない場合は、追加の階層を別の nib ファイルに保存することを検討してください。各ビュー階層は、使用時にのみロードしてください。

すでに大きな nib ファイルがある場合は、Interface Builder のリファクタリング ツールを使用して、それらをいくつかの小さな nib ファイルに分割できます。Interface Builder のリファクタリング ツールの使用方法については、「Nib ファイルのリファクタリング」を参照してください。コードから nib ファイルを明示的にロードする方法については、Resource Programming Guide を参照してください。

しかし、プロのプログラマーとしての私の個人的な意見 (私はソフトウェア開発者であるため) は、初心者がすべてがどのように機能するかを学び、理解するためだけにプログラムによる方法から始める方が常に良いということです。

于 2013-02-11T09:56:39.170 に答える