1

問題を一言でいうと

ここ数週間、IOS アプリケーションを構築していて、いくつかの問題に遭遇しました。アプリケーションは、画像ラスターを 1 秒間に複数回操作して描画することにより、アニメーションを再生します。画像はUIViews CALayerlike に割り当てて描画しますのでself.layer.contents = (id)pimage.CGImage;計算とレンダリングは 2 つCADisplayLinkの s に分けられます。

このアニメーション手法は、iPhone 6.1 シミュレーターで満足のいくパフォーマンスを達成しますが、物理デバイス (IOS 6.1.3 を実行する Iphone 4s) でビルドすると、大幅な速度低下が発生します。スローダウンは非常に悪いため、実際にはアプリケーションが使用できなくなります。

疑わしい問題

この質問iOS デバイスと iPhone シミュレーター間のメモリ構成の違い で、シミュレーターは実際のデバイスよりもはるかに多くのメモリを使用できることを読みました。ただし、「instruments」でアプリのメモリ使用量を観察しているときに、合計メモリ使用量が 3Mbs を超えていないことに気付きました。それが実際に問題であるかどうかはわかりませんが、おそらく指摘する価値があります。

この質問によると、iOS-Simulator は複数のコアを使用していますか? 、IOSシミュレーターはIntelチップで実行されますが、実際のデバイスはApple A5チップを使用します。これも速度低下の原因ではないかと思います。

Open GL でアニメーションを書き直すことを検討していますが、抜本的な手順を実行する前に、まず既存のコードを改善してみることをお勧めします。

問題が何であるかを特定するための助けをいただければ幸いです。

アップデート

提案を提供してくれたすべての人に感謝します。プロファイリング中に、主なボトルネックは実際には次のアニメーションのイメージ ラスターをクリアすることであることがわかりました。アニメーションのレンダリングを OpenGL で書き直すことにしました。予想していたほど時間はかかりませんでした。アプリはかなり良いレベルのパフォーマンスを達成し、少しシンプルになりました.

4

2 に答える 2

2

これは古典的な問題です。シミュレーターは、強力なワークステーション/ラップトップのリソースを使用しています。

残念ながら、唯一の解決策は、コード、特に表示に関するものに戻って最適化することです。

通常、計算時間から描画時間を最小限に抑えようとしますが、これは実行しているように聞こえますが、メインスレッドで計算しないようにしてください。

dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0ul);
dispatch_async(queue, ^{
    // Do the computation
});

デバイスで実行中にインストゥルメントを使用できるため、CoreGraphics インストゥルメントを使用して、常に何が使用されているかを確認し、問題のあるコードを指摘できます。残念ながら、あなたはおそらくそれが何であるかをすでに知っており、最適化に行き着くだけです.

于 2013-06-05T18:42:44.633 に答える
1

速度低下は、画像のブリッティングに関連している可能性が最も高いです。ディスプレイルックコールバックで変更される一連の静止画像を使用していると思います。プライマリビュー/レイヤーに追加され（古いビュー/レイヤーを削除しながら）、すでにCGImageRefsを含むCALayersを使用できる場合は、CGContextDrawImage（）を使用して、レイヤーのdrawInContextメソッドで画像をブリットできると思います。ブレンドではなくコピーを使用するようにコンテキストを設定して、古いビットを置き換えるだけです。

ディスパッチ キューを使用して、セカンダリ スレッドで画像を含む CALayer サブクラスを作成できます。もちろん、描画はメイン キューで行われます。スロットリングを使用して、10 程度の CALayer のキューを維持し、消費されたときにそれらを補充することができます。

これで解決しない場合は、OpenGL が役立つ可能性がありますが、プロセッサと GPU の間でビットを移動するのに役立つものはありません (画像をアニメーション化するだけでなく、画像のスタックを使用しているため)。

于 2013-06-05T19:04:24.717 に答える