ちょっとした背景: 私は、さまざまな状態のさまざまなステータス アイコンを持つ iOS アプリに取り組んでいます。これらのアイコンは、UITableViewCell imageViews、カスタム MKMapAnnotations、およびその他のいくつかのスポットなど、さまざまな場所とサイズで使用されます。私は実際に、より静的なステータス アイコンを含むセットと、デザインに動的なテキストが挿入されたセットをいくつか持っています。
そのため、最初は静的なラスター アセットを使用するという従来のルートに進みましたが、サイズが動的であるため、これが常に最適なソリューションとは限らず、CGAffineTransforms を使用したスケーリングの品質には満足できませんでした。代わりに、ギアを少し変更して、別のことを試しました。
- アイコンの高レベル クラスごとにカスタム UIView サブクラスを作成しました。ステータスを取得するモデルオブジェクトを入力として取ります（列挙型を使用して、これをある種のモデルコンストラクターにロードすることもできたと思いますが、これが私が行った方法です）ので、何を描画する必要があるかを決定できます。次に、drawRect で必要な描画を行います。すべての図面はビュー境界に基づいているため、妥当な寸法にスケーリングされます。
- モデル入力と使用するサイズを受け取り、カスタム ビューを構築するクラス メソッド コンストラクターを持つカテゴリを作成しました。
- これらのアイコンのラスター化されたバージョンを特定の場所 (UITableViewCell imageView など) にプラグインするオプションも必要だったので、高速な iOS7 スナップショット機能を使用してビューを構築し、UIImage を返すコンストラクターも作成しました。
それで、これは私に何を与えますか？ここに私が見ることができる長所/短所があります。
長所
- さまざまなシナリオやコンテキストで簡単に使用できる、完全にスケーラブルなグラフィック。
- テキストなどのグラフィックスに動的な情報を追加することで簡単に互換性があります。描画しているすべてのものについて正確な形状データを持っているので、すべてがどのように配置されているかを知っているので、テキスト ボックスの境界を推測する必要はありません。
- ラスター化されたアセットが必要になる可能性がある状況との互換性がありますが、必要になるまでラスター化しないため、動的ビューのすべての利点が得られます。
- ラスター アセットを含める必要がないため、アプリケーションのサイズが縮小されます。
短所
- 最初に描画コードを作成するワークフローは理想的ではありません。簡単なことはコードで直接実行できますが、より複雑なことについては、Illustrator または Sketch でベクター アセットを作成し、それを PaintCode に取り込み、生成された描画コードをより合理的なものにクリーンアップする必要があります。これは最も理想的なプロセスではありません。
質問は、この種の状況に対処する方法について、より良い提案がある人はいますか? この種のテクニックに関する膨大な量の資料は見つかりませんでした。これを処理するためのより良い方法を見逃しているのか、それとも隠れた落とし穴があるのか 疑問に思っています...パフォーマンスはそうではないようです私のアプローチでのテストの問題ですが、iPad3またはiPhone 4でまだテストしていないため、まだ不明な点がある可能性があります.