2010年の終わりのどこかで、出版社（雑誌、書籍、パンフレット）からの印刷物をiPadで読みやすいように電子形式に変換するアプリケーションを実装する命令を受けました。 長い会話と説明の後、技術タスクの最終タスクは次のように定式化されました。
電子雑誌ストアであるiPadアプリを作成します。 簡単な登録に合格したユーザーは、必要な金額まで残高を補充し、利用可能な電子ジャーナルをダウンロードして表示できます。 雑誌はインタラクティブである必要があります。つまり、一連のスライド、回転、ビデオ、音声の表示、フォントの増加、ブックマークの追加、ページをスクロールするための美しいアニメーション、同じ静脈内の物のリストの機能があります。 情報源の雑誌は、出版社から直接提供された、きれいなPDFでした。
長い間話をせず、すべての問題を掘り下げないために、サーバー部分の実装、ユーザー登録、残高補充、同期を破棄します。 私たちはクラスに直接進みます。クラスは、雑誌の閲覧と対話を担当することになっています。
私は、プロジェクトgithub.com/brow/leavesをアニメーションの基礎として採用しましたが、これは今でもこの方向で最も有名なエンジンの1つです。 折り畳み効果とページめくり効果の実装が本当に気に入りました。 エンジンの初期ビューを次の図に示します。
エンジンを自分用に変更し、プレビューを表示し、ブックマークやその他のニュアンスにページを追加する機能を作成し、出版社から144ページの重量の40ページの雑誌のPDFバージョンを受け取り、実際のデバイスにアップロードすると、致命的な問題が発生しました。 ランダムなページをめくると、雑誌がクラッシュしました。
ログに目を向けると、エラーが発生しました。
データフォーマッタは一時的に利用できません
実際、iPadで仮想RAMが不足しているため、アプリケーションを使用できます。 ツールを使用してさらに深く掘り下げる-メモリ割り当て、次のpdfページをレンダリングするときに、割り当てられたメモリが蓄積され、解放されないことに気付きました。
もちろん、CGPDFPageReleaseおよびメモリの解放とクリーニングに関連する他の操作を正しく使用しなかったと思われるかもしれません。 しかし、何百ものインターネットの投稿、問題、解決策を研究した後、アプリケーションを1か月以上テストしましたが、トピック「大きなPDFのレンダリング」に関する唯一の合理的な説明は、CGPDFPageReleaseメソッドを呼び出すときにiOs SDKが実際にメモリを破壊しないことです。 公式のアップルWebサイトに記載されているように（残念ながら、リンクを見つけることができませんでした）、CGPDFはページタイルをメモリにキャッシュします。これにより、次回コールがレンダリングされるときにレンダリングが高速になります。 つまり、このようなAppleの内部キャッシュメカニズムに問題があり、重いPDF雑誌の読み取りを一貫して妨げていました。
冷や汗の中で、締め切りにつかまって、私はこの問題の最適な解決策を探し始めました。 さらに、顧客はCATiledLayerの遅いレンダリングをあまり好きではありませんでしたが、1ページの重さが少なくとも7 MBであると説明することは困難でした。 パブリッシャーからUIWebViewに奇跡のPDFファイルをダウンロードしようとしましたが、その結果、アイデアは完全に失敗しました。 Webコンポーネントは、すでに松葉杖でいっぱいの私のエンジンよりも速く落ちました。
問題の解決策に目を向けます 。
最後に、ファイルからすべての写真とテキストを取り出すPDFパーサーを作成したいと思いました。 次に、それらを自分の形式で上書きし、標準ツール（UIImageView、UITextView、CoreTextなど）を使用してアプリケーションに表示しました。 私はまだこれを有望なアイデアだと考えていますが、たくさんのAdobeマニュアルを読むのをマスターしたことはありません。 インターネット上で通常のpdfパーサーを見つけることも機能しませんでした-誰もが不器用に画像を引き裂くか、まったく引き裂かなかった。 少なくとも.docまたは.html形式でPDFからテキストを取得しようとしていますが、私は一般的に黙っています。
私の最終的な実装は、次のメカニズムを表しています。
Quark Xpressパブリッシングプログラムの助けを借りて、PDFからすべての重い画像を切り取り、さらに圧縮し、サイズと色空間を変更しました。 次に、擬似スクリプト言語（htmlのようなタグが使用されている場所）を開発しました。次に例を示します。
（ページ番号= 1）
（pdf）1（/ pdf）
（画像）0,0,768,1024、first_page_image.png（/ image）
（テキスト）.....（テキスト）
（ビデオ）.....（ビデオ）
（スライド）.....（スライド）
（3d）....（3d）
（/ページ）
次に、ページごとに明るいjpgプレビューが作成されました。 プレビューでページめくり効果が終了すると、CATiledLayerが追加され、切り取られた画像（つまり、テキストと単純な要素のみ）でpdf-kuを描画し始めました。 同時に、タグ付きのファイルが解析され、すべてのインタラクティブ要素が背景または前景に追加され、ハンドラーがそれらに掛けられ、アニメーションが適切な場所で開始され、インタラクティブ要素と対話するための特別な「アクティベーター」要素が追加されました。
その結果、私のアプリケーションはクラッシュせず、十分に速く動作し、ToRのすべての要件を満たしました。
約1か月前、電子ジャーナルの実装について同様の提案が再び出されました。 しかし、私は拒否することを余儀なくされました。なぜなら、私はこのすべての出血をもう一度やりたくなかったからです。 しかし、私自身の好奇心のために、インターネット上の新しい安定したフリーエンジンを分析しました。 新しいもののうち、私はgithub.com/vfr/Readerが好きでした
しかし、1年前に苦しんでいたのと同じpdf-kuをそこに注ぐとすぐに、それも落ちました。 公式のアップルエンジンもすべて落ちています。
誰かが自分の経験を共有したい場合、または彼のエンジンが巨大なpdf-ok-writeの問題を解決することを保証したい場合は、より詳細なヒントを共有し、あなたのエンジンを落とす可能性のある非常に悪意のあるpdf-kuを捨てます。