4
iPhone / iPad / iO向けの高速で無駄のないPDFビューア-ヒントとヒント?
最近、PDFの描画について多くの質問があります。 はい、PDFをで簡単にレンダリングできますUIWebViewが、これは優れたPDFビューアに期待するパフォーマンスと機能を提供できません。 PDFページをCALayerまたはUIImageに描画できます。Appleには、ズーム可能なUIScrollviewで大きなPDF を描画する方法を示すサンプルコードさえあります しかし、同じ問題が増え続けています。 UIImageメソッド: PDF UIImageは、レイヤーアプローチと同様に光学的にスケーリングされません。 制限UIImagesからの生成でCPUとメモリがヒットしPDFcontext、新しいズームレベルのリアルタイムレンダリングを作成するためにそれを使用できなくなります。 CATiledLayerメソッド: PDFページ全体をaに描画すると、かなりのオーバーヘッド(時間)CALayerが発生します。個々のタイルがレンダリングで表示されます(tileSizeを微調整しても) CALayers 事前に準備できません(画面外でレンダリングされます)。 一般に、PDFビューアもメモリをかなり消費します。Appleのズーム可能なPDFの例のメモリ使用量も監視します。 現在のプロジェクトでは、PDFビューアを開発UIImageしていて、別のスレッドでページのをレンダリングしています(ここでも問題です)、スケールがx1のときにページを表示しています。CATiledLayerスケールが1を超えると、レンダリングが開始されます。iBooksも同様のダブルテイクアプローチを採用しており、ページをスクロールすると、鮮明なバージョンが表示される前に1秒未満でページの低解像度バージョンを表示できます。 ページの各側にフォーカスがある2ページをレンダリングして、PDFイメージが描画を開始する前にレイヤーをマスクできるようにします。フォーカスされたページから+2ページ離れると、ページは再び破棄されます。 描画PDFのパフォーマンス/メモリ処理を改善するためにどれほど小さくても明白でも、誰かが洞察を持っていますか?またはここで議論された他の問題? 編集:いくつかのヒント(Credit- Luke Mcneice、VdesmedT、Matt Gallagher、Johann): 可能な場合は、メディアをディスクに保存します。 TiledLayersでレンダリングする場合は、より大きなtileSizeを使用します INIT頻繁プレースホルダオブジェクトと配列を用い、alternitively別の設計アプローチは、これ 画像は、 CGPDFPageRef NSOperationsまたはGCD&ブロックを使用して、事前にページを準備します。 CGContextSetInterpolationQuality(ctx, kCGInterpolationHigh); CGContextSetRenderingIntent(ctx, kCGRenderingIntentDefault);前CGContextDrawPDFPageに呼び出して、描画中のメモリ使用量を減らします docRefで初期化するのNSOperationsは悪い考え(メモリ)であり、docRefをシングルトンにラップします。 不要なNSOperations場合はキャンセルできます。特にメモリを使用する場合は、コンテキストを開いたままにしてください。 ページオブジェクトをリサイクルし、未使用のビューを破棄する 開いているコンテキストが必要なくなったらすぐに閉じます メモリ警告を受け取ったら、DocRefとページキャッシュを解放して再ロードします その他のPDF機能: PDF内のリンクの取得(およびこことここ) リンク配置のためのPDF Rectについて PDF annotdatestringsの変換 リンクのターゲットを取得する(/Dest配列からページ番号を取得する) 目次を取得する ドキュメントのタイトルとキーワード 生のテキストの取得(およびこことこことここ(配置に焦点を当てた)) 検索(およびここ)(すべてのPDFで機能するわけではありません(変な文字が表示されるだけです。エンコードの問題だと思いますが、よくわかりません)-Credit BrainFeeder) CALayerおよびオフスクリーンレンダリング -次のページをレンダリングして高速/スムーズな表示 …