12

GUIデザインに.xibファイルを使用することとプログラムでこれを行うことの間に違いがあるかどうか疑問に思いました。

コンパイラなので、関連する時間が失われることはないと思います。

私が間違っている？

4

3 に答える 3

26

（注：携帯電話でこれをタップすると、フォーマットや文法がおかしくなることを事前にお詫びします。問題が発生した場合は、ラップトップに戻ったときに修正します。）

私はこれを自分でチェックするために、いくつかの迅速で汚い、非常に非公式なテストを行いました。これが私が見つけたものです（テスト用に作成したアプリは単なるスクラッチであり、必ずしも「実際の」アプリを表すものではないことに注意してください）。

  • 初期画面がペン先の場合、起動時間が速くなりました

  • 以降のすべての画面で、UIを手動でコーディングするとパフォーマンスが向上しました

最初は奇妙ですが、考えてみると、それほど奇妙なことではないかもしれません。

起動の問題は私を混乱させますが、それはAppleがAppleであり、起動時間に夢中になっているためだと思います（もちろん、良い意味で）、アーカイブ（nib）からロードできるように電話のアンアーカイバーを最適化しただけです手作業でコーディングするよりも高速です。

とは言うものの、ほとんどの人は、違いによる大きな影響を受けないアプリを作成しています。私の（再び：迅速で汚い）テストでは、コールドスタート（まだまたはしばらくの間アプリを実行していない）から、nibベースのアプリが手作業でコーディングされたものの約2倍の速度で初期画面を一貫してロードすることが示されましたバージョン。それは大したことのように聞こえますが、私たちはほんの数ミリ秒話しているだけです。その違いは、ユーザーには気付かれません。ウォームスタート（すでにアプリを開いたり閉じたりしている）の場合、起動時間の差ははるかに小さかった。

このため、私はアプリの基盤をレイアウトするためにペン先を使用するのが好きです。トップレベルのナビゲーション（タブコントローラー、ナビゲーションコントローラーなど）を使用してから、残りのUIを手動でコーディングします。

さらに、iPhone UIはiPhoneに非常に固有であるため（驚きです！）、デスクトップアプリを作成するときのようにUIを手動でコーディングすることは難しくありません。同じUIコンポーネントを何度も使用します。それを理解したら、コードでUIを作成するのは簡単です。Windows / OS X /その他のアプリケーションを開発する場合のように、80億個のウィジェットから選択する必要はありません。iPhoneの一貫性は、UIのハンドコーディングに関して、私が長年にわたって開発した中で最も簡単なプラットフォームになっています。

また、UIを手動でコーディングした場合、NSCoding（アプリの実行全体で状態を永続化するために使用するもの）の操作がはるかに簡単であることがわかりました。UIImageインスタンスが原因で、ペン先ベースの画面が適切にアーカイブされないという問題が発生しました。UIImage（少なくとも最後にチェックしたとき）はNSCodingに準拠していないため、アーカイブプロセスが停止します（そして、かなり不快な停止になります）。ここでは例としてUIImageを使用しましたが、アーカイバが保存しようとしてNSCodingに準拠していないものはすべてプロセスを汚してしまうため、これについて考える必要があります。

UIを常に手動でコーディングするもう1つの方法は、動的テーブルを使用しているときです。静的テーブル（セルが基本的に変更されないテーブル）を作成している場合、ペン先は問題ありません。他の種類のテーブル、特にサムネイルやその他のリソースを大量に消費するビットがあるテーブルの場合、手動でコーディングするときに取得するコントロールにより、ペン先ベースのテーブルセルでは得られないパフォーマンスを得ることができます。 。そのために、あなたはしますCocoaTouchをスキップして、CoreGraphicsを直接操作する必要がありますが、パフォーマンスを向上させることは、コードの最後の1行ごとに価値があります。私が取り組んだプロジェクトのテーブルパフォーマンスの例については、Barnes and Noble Store（電子書籍リーダーではありません）およびStyle.comを参照してください。これらの（およびその他の）アプリのフレームワークを構築しました。テーブルをスムーズにスクロールする秘訣は、ペン先から読み込まれたセルを一度も使用したことがないことです（それよりも複雑ですが、ペン先をスキップすることが、パフォーマンスを向上させるための最初のステップでした。それらのアプリで表示されます）。

一般的に言って、ペン先を使用するときに考慮すべき最も重要なことは、UIをファイル間で分割する必要があるということです。つまり、アプリのUI全体を単一のペン先に固定しないでください。ペン先が読み込まれているときは、それがすべてです。ペン先にユーザーが表示することはめったにない可能性があり、他のすべてと同じように読み込まれ、理由もなくリソースを消費します。アプリの画面ごとに個別のペン先を使用しないと、メモリとパフォーマンスの問題が発生しやすくなります。

さらに明確にするために：5つのビューコントローラーを備えたアプリがある場合は、各コントローラーを独自のペン先に固定します。必要になるまで何もロードしたくありません。これには例外がありますが、それは単にコーディングの方法です。十分な時間があれば、「間違った方法」で何かを行う理由が見つかりますが、画面ごとにペン先を使用するアプローチが必要です。あなたがそうしない正当な理由がない限り、それをしている。

そのままにしておきます-少しお役に立てば幸いです。

覚えとけ：

  • 私の非公式ないじくり回しは、ペン先を使用すると起動が速くなることを示しました（ペン先をできるだけシンプルに保ち、必要なものだけを保持する限り）。

  • 起動後、手動でコーディングされたUIのパフォーマンスが向上したようです。

  • 正しく行われ、ゲームなどを作成していない場合、ペン先が認識できるパフォーマンスの問題を引き起こすことはありません。

  • 私の経験では、テーブルは異なります-それらは私がめったにペン先を使用しない1つの場所です。

  • アプリの状態を維持するためにNSCodingを使用している場合、ペン先は問題になる可能性があり、iPhone UIを手動でコーディングするのは比較的簡単なので、回避策はおそらく努力する価値がありません。

  • ペン先はできるだけシンプルにしてください。これは十分に言えません。可能な限り、アプリのUI全体を1つのペン先に詰め込むのではなく、アプリの画面ごとにペン先を作成します。

Ok。今回は本気でやめます。

お役に立てれば ：）

于 2009-12-29T23:00:37.793 に答える
16

ごくわずか。いくつかの例外があります。たとえば、xibを使用してUITableViewCellに入る画像を読み込む場合、多くのセルを持つUITableViewは読み込み時間に敏感であるため、これが問題になる可能性があります。ただし、すべての目的と目的で、パフォーマンスに目立った影響がないようにする必要があります。

xibの情報は、実行時にデコードしてメモリにロードする必要があります。これは、プログラムで直接UI要素を作成するほど高速ではありません。

于 2009-09-07T07:54:29.527 に答える
7

特に、必要以上に多くのコードを記述する必要がある場合は、時期尚早の最適化に注意してください。

于 2009-09-07T08:20:18.710 に答える