iOSのpresentRenderBufferブロック

Question

セットアップ：メインスレッド上

• CADisplayLink、間隔ごとに
• iOSの10.2
• OpenGLES 2.0
• iPhone 6

を発射するように設定。

-(void)callbackFromCADisplayLink:(CADisplayLink *)dl 
{ 
    u64 tStart = high_res_clock_now(); 

    <Process input, advance game world, prepare graphics commands> 

    // Frame processed 
    u64 prePresentElapsed = high_res_clock_now() - tStart; 

    [myEAGLContext presentRenderbuffer:GL_RENDERBUFFER]; 

    // Graphics commands submitted 
    u64 postPresentElapsed = high_res_clock_now() - tStart; 
} 

私は何を見つけることだと、次のとおりです。

• prePresentElapsedは0.5-2.5ms範囲内で一貫しています。
• 2つのグラフィックモードが本質的にあります：
• "高速モード"：postPresentElapsedは一貫16msの
• でホバリングされる：postPresentElapsedが1.5-4ms範囲
• "低速モード" で一貫していますシステムは「高速モード」で始まりますが、一見無作為に（「大きなフレームスパイク」に関連付けられているようには見えません）「スローモード」に縮まり、アプリが非アクティブ/バックグラウンド状態になるまで「スローモード」にとどまりますその後、アクティブ状態に戻る。

明らかに、vsyncのダウンストリーム効果のためにpresentRenderbufferがブロックされているようです。

質問：

1. モードの切り替えの原因は何？
2. にはどうすれば確実に

Answer 1

のiOSは、CPUとGPUのクロック速度を変更するには非常に有効である「高速モード」に滞在することができます。 OSに関する限り、理想的な状態は、可能な限り遅いクロック速度（スピードモードで起こっているようなもの）で60fpsでアプリケーションを一貫して実行することです。

アプリが起動すると、クロック速度あなたのアプリの尺度を取得し、ユーザーの経験に影響を与えることなく可能な限りクロック速度を遅くします。これは、ユーザーのバッテリーを節約し、デバイスを冷却し続けるためです。

私の知る限り、この動作を無効にしたり、制御したり、監視したりすることができないため、パフォーマンス測定をもっと難しくしています。また、クロックスピード管理が遅すぎるまでクロック速度を上げることができないため、アプリケーションにビジーフレームがあると、奇妙なフレームを見逃してしまうことにもなります。