5

私のアプリケーションはOpenGLを多用しており、画像の処理、シーンのレンダリング、プレビューの表示などに使用されています。ただし、Appleの公式ドキュメント「OpenGLESプログラミングガイドfor iOS」としてマルチタスクを実装した後も、奇妙なクラッシュが発生しました。散発的にアップ。デバッグナビゲータスタックトレースには、「sgxPatchDeferredFramebufferOffsets」、「presentRenderbuffer EXC_BAD_ACCESS」、「gpus_ReturnNotPermittedKillClient」などが表示されます。

それで、OpenGLESマルチタスクを正確に実装する必要があるものを知りたいと思います。

=============更新:問題は解決しました============

あなたの答え、CStreel、そして助けようとした他の人たちに感謝します。

「iOS用OpenGLESプログラミングガイド」の「バックグラウンドアプリケーションがグラフィックスハードウェアでコマンドを実行しない可能性がある」の部分を2回目に読んだ後、この問題について新たに理解しました。

私のアプリの大きな問題は、通知メソッドにOpenGLESマルチタスクを実装すべきではないということです。デリゲートメソッドとは異なり、通知メソッドは非同期で呼び出されるため、アプリケーションがすでにバックグラウンドに移動している場合、これらの停止アニメーションアクションとglFinish()呼び出しは有効にならない場合があります。これは、一連のOpenGL ES関連のアクションを実行しているときにすぐにロック画面ボタンを押すと、より頻繁に発生する可能性があります。

他に問題が見つかった場合は、お気軽にご連絡ください。

4

2 に答える 2

4

アプリがバックグラウンドに入る直前に、アプリがOGLES関数を呼び出すと、OSはアプリをすぐに強制終了します

詳細については、アプリの状態とマルチタスクをお読みください責任あるバックグラウンドアプリであることをお読みください

そのドキュメントからの抜粋を次に示します。

(Required) When moving to the background, make sure your app adjusts its behavior appropriately.

OGLESに関して

 ...the app should stop calling OpenGL ES functions.
于 2012-10-17T03:18:53.823 に答える
0

通知は同期または非同期にすることができます。NSOperationQueueを指定して通知を登録すると、コールバックは非同期になります。それ以外の場合は、常に同期になると思います。

これらのクラッシュがいくつか発生し、コードにいくつかのバグが見つかりました。

  1. 共有EAGLContextは、「マルチスレッド」であるにもかかわらず、それを使用するすべてのスレッドで常に設定されているわけではありません。アプリコードを入力してopenGLコマンドを発行するには、メインスレッドがRunLoopを離れるたびにコンテキストを設定する必要があるようです。
  2. iOS 6のバグが原因と思われるため、iOS 6ではバッファを変更するときに追加の「glFlush()」が必要でした。iOS5と7は影響を受けませんでした。
  3. 「DidEnterBackground」通知と他のコード/スレッド間の同期の欠如。これは、他のスレッドがまだopenGLを使用しているときに、アプリの状態の変化を通知するメインスレッドが早期に戻ってきたことを意味します。openGLの呼び出しが完了するまで、通知スレッドを保持します。戻ることが許可された後でのみ、iOSはopenGLで「ウォッチドッグ」を開始します。

DidEnterBackground / WillEnterForeground通知(コールバックではない)を使用して、openGL操作を停止/再開します。それでも非常にまれなクラッシュが発生します(自動化を使用し、取得する前に20〜30分間ロック/ロック解除/回転する必要があります)が、WillResignActive/DidBecomeActiveを使用しても違いはありません。それらは関係なく起こります。

于 2014-03-17T11:57:52.857 に答える