drawRectを描画するかどうか（drawRect / Core Graphics vs subviews / imagesを使用する必要があるのはなぜですか？）
この質問の目的を明確にするために：サブビューとdrawRectの両方を使用して複雑なビューを作成する方法を知っています。私はいつ、なぜ、どちらを使用するのかを完全に理解しようとしています。 また、事前に最適化することはあまり意味がなく、プロファイリングを実行する前に、より困難な方法を実行することも理解しています。私は両方の方法に慣れていると考えて、今は本当にもっと深く理解したいと思っています。 私の混乱の多くは、テーブルビューのスクロールパフォーマンスを本当にスムーズかつ高速にする方法を学ぶことから生じます。もちろん、このメソッドの元のソースは、iPhoneのTwitter（以前のTweetie）の作成者によるものです。基本的に、表のスクロールをスムーズにするための秘訣は、サブビューを使用せず、すべての描画を1つのカスタムuiviewで行うことです。基本的に、多くのサブビューを使用するとオーバーヘッドが大きくなるため、レンダリングが遅くなり、親ビューを介して常に再合成されるようです。 公平を期すために、これは3GSがかなり新しいブランドスパンキンであったときに書かれ、それ以来iDevicesはより速くなりました。それでも、この方法はインターウェブや他の場所で定期的 に高パフォーマンスのテーブルとして推奨されています。実際、これはAppleのTable Sample Codeで推奨される方法であり、いくつかのWWDCビデオ（Practical Drawing for iOS Developers）、および多くのiOS プログラミングブックで推奨されています。 グラフィックをデザインし、それらのコアグラフィックスコードを生成するための素晴らしいツールもあります。 だから、最初は「Core Graphicsが存在する理由はある。それが速い！」と信じるようになった。 しかし、「可能な限りお気に入りのコアグラフィックス」というアイデアが浮かんだと思うとすぐに、drawRectがアプリの応答性の低下の原因であることが多く、メモリの消費が非常に高く、CPUに大きな負担がかかることがわかります。基本的に、「drawRectのオーバーライドを回避する」必要があります（WWDC 2012 iOSアプリのパフォーマンス：グラフィックとアニメーション）） だから、すべてのように、それは複雑だと思います。多分あなたは私と他の人がdrawRectを使用するときと理由を理解するのを助けることができますか？ Core Graphicsを使用する明らかな状況がいくつかあります。 動的データがある（Appleの株価チャートの例） シンプルなサイズ変更可能な画像では実行できない柔軟なUI要素がある あなたは動的グラフィックを作成しており、一度レンダリングされると複数の場所で使用されます Core Graphicsを回避する状況が見られます。 ビューのプロパティは個別にアニメーション化する必要があります ビューの階層が比較的小さいので、CGを使用して知覚される余分な労力は利益に値しません すべてを再描画せずにビューの一部を更新したい サブビューのレイアウトは、親ビューのサイズが変更されたときに更新する必要があります だからあなたの知識を授けなさい。drawRect / Core Graphicsにはどのような状況で到達しますか（これはサブビューでも実行できます）？その決定にあなたを導く要因は何ですか？どのように/なぜバターのようなスムーズなテーブルセルスクロールに推奨される1つのカスタムビューで描画するのに、Appleは一般にパフォーマンス上の理由からdrawRectを推奨していませんか？シンプルな背景画像はどうですか（サイズ変更可能なpng画像を使用する場合と、CGを使用して作成する場合）。 価値のあるアプリを作成するためにこのテーマを深く理解する必要はないかもしれませんが、理由を説明できない限り、テクニックを選択するのは好きではありません。私の脳は私に腹を立てます。 質問の更新 情報ありがとうございます。ここにいくつかの明確化する質問： コアグラフィックスで何かを描画しているが、UIImageViewsと事前レンダリングされたpngで同じことを達成できる場合は、常にそのルートをたどりますか？ 同様の質問：特にこのようなbadassツールではでは、コアグラフィックスにインターフェイス要素を描画することを検討する必要があるのはいつですか？（おそらく、要素の表示が可変である場合。たとえば、20の異なるカラーバリエーションがあるボタン。他のケースはありますか？） 以下の私の回答を理解しているとしたら、複雑なUIViewのレンダリング自体の後にセルのスナップショットビットマップを効果的にキャプチャし、複雑なビューをスクロールして非表示にしているときにそれを表示することで、テーブルセルと同じパフォーマンス向上が得られるでしょうか？明らかに、いくつかの作品は解決する必要があります。ただ面白いと思った。