CATiledLayerを使用して PDF ページをレンダリングするときの仕組みを理解しようとしていますCGContextDrawPDFPage()。
私の理解では、drawLayer:inContext:タイルと詳細レベルごとに 1 回呼び出されます。あれは正しいですか？
タイル化されたレイヤーのデリゲートで呼び出しますが、タイル化されたレイヤーのタイルサイズを小さくすると、より頻繁に呼び出されるCGContextDrawPDFPage().
ことに気付きました ( にログを入れることによってdrawLayer:inContext:) 。drawLayer:inContext:これは私が不思議に思う：
drawLayer:inContext:タイル レイヤーのタイル サイズを小さくすると、より頻繁に呼び出されることに気付きました。
はい、もちろん。レイヤーのサイズが同じであると仮定すると、より小さなタイルを使用するように指示すると、その領域をカバーするためにさらに多くのタイルが必要になります。
私のPDFページはx回描画/レンダリングされていますか?
CGContextDrawPDFPage() をタイルごとに 1 回呼び出すので、はい。
ただし、次の理由により、問題にならない場合があります。
CGContextDrawPDFPage() はページのどの部分を描画するかを魔法のように知っていますか?
そうかもしれませんが、魔法は必要ありません。
CATiledLayer が を呼び出す前-drawLayer:inContext:に、CGContext のクリップを設定して、そのタイルの領域のみを含めます。PDF 描画コードは、( 経由で) クリップの境界を取得し、CGContextGetClipBoundingBoxその四角形内のコンテンツのみをレンダリングすることを選択できます。
つまり、次の 2 つの注意事項があります。
CGContextDrawPDFPage()はブラック ボックスであるため、実際にはその最適化を行わない可能性があります。当たり前のように思えますが、実際に起こっているかどうかを確認するには、パフォーマンスの数値を確認する必要があります。CGContextDrawPDFPage。これは、CG がどれほどスマートであるか、および内部にキャッシュするかどうかによって異なります。PDF ページをレンダリングするとき、CATiledLayer はリソースの無駄ではありませんか? その利点は何ですか？
CATiledLayer の利点は主にメモリの節約にあります。レンダリングされたコンテンツが格納されるビットマップは非常に大きいため、現在画面に表示されているコンテンツのみをレンダリングして保持するのに費用がかかります。また、ユーザーのズームとスクロールの方法に応じて、最近表示された、またはすぐに再び表示される可能性のある領域をキャッシュするメカニズムも提供します。
トレードオフは、描画をタイルごとに個別の呼び出しに分割する必要があり、そうでない場合よりも頻繁にタイルにレンダリングする必要がある場合があることです。
ビューの大きさ、ズームイン/ズームアウトの程度、PDF の描画コスト、およびアプリケーションで他に何が起こっているかによって、CATiledLayer を使用する意味がある場合とそうでない場合があります。パフォーマンスの数値を見て判断するのはあなた次第です。
オーガだから...えっと、PDFはタマネギのようなものです。QuartzCore はPDF レンダリング メソッドに大きく基づいており (初期のドキュメントでもこの事実について言及されているほどです)、CATiledLayer は特定の「タイリング」レンダリング メソッドを使用して、繰り返し描画されるオブジェクトを指定します。したがって、タイルが移動または更新されると、レイヤーはより多くのデータを要求するため、1 つ以上のバックグラウンド スレッドで drawLayer:inContext: を呼び出します。
CATiledLayers は、キャッシュを多用し、可視レイヤーのみをロードするため、非常に効率的です。