私の今後のiPhoneゲームでは、さまざまなシーン要素が独自のCCNodeに分割されます。
私の障害物ノードには多くのノードが含まれており、それぞれが障害物を表しています。すべての障害物ノードの内部には、障害物を構成する画像（1〜4画像）があり、一度に最大10個の障害物しかありません。私のゲームが更新するたびに、障害物ノードの更新関数が呼び出され、すべての障害物が左に移動します。しかし、これは私のゲームをかなり遅くします。
同時に、画像を含むだけのパーティクルノードがあり、障害物ノードとまったく同じようにすべてのフレームで画像を移動しますが、パフォーマンスに目立った影響はありません。しかし、一度に何百もの画像があります。
私の質問は、なぜ障害物がそれをそれほど遅くするのに、粒子はそうしないのかということです。障害物で使用されている画像をパーティクル内の画像に置き換えてみましたが、（目立った）違いはありません。別のレベルの子ノードがあるということでしょうか？
すべての画像をテクスチャ アトラスに配置し、クラスを使用してバッチとして 1 回レンダリングすると、アプリのパフォーマンス、実行速度、フレーム レートなどが大幅に向上します。CCSpriteBatchNode画面上で多くのオブジェクトを頻繁に移動すると、ハードウェアの動作が大幅に低下します。
このクラスの使い方は簡単です。すべての画像を含むテクスチャ アトラスを使用してクラスを作成し、スプライトと同様に、このクラスを子としてレイヤーに追加します。
ただし、スプライトを作成するときは、レイヤーの子としてではなく、このバッチ ノードに子として追加してください。
それは非常に簡単で、おそらくここでかなり役立つでしょう.
Cocos2d のドキュメントを思い出すと、パーティクルは非常に軽量であるため、非常に多くのパーティクルを一度に画面に表示できます。ノードはより重く、物理システムと相互作用し、ノード固有のレンダリングを必要とするため、フレーム間でより多くの処理が必要になります。最後にレンダー ループ コードを見たとき、基本的にシーン内の CCnode の数に基づく O(n) でした。NSTimers と Cocos の組み込み実行ループを使用すると、パフォーマンスにもかなりの違いが生じます。
大幅に遅くなるものの例を教えてください。これらの障害物を正確にどのように更新しますか?
cocos2d のドキュメントには、何らかの形でパフォーマンスに関係するいくつかのベスト プラクティスがあります。1 秒あたりのフレーム数を最適化するためにできることはたくさんあります。
一般に、コードが遅い場合は、Instruments.app を使用して、コードがどこで多くの時間を費やしているかを把握するのに役立ちます。フレームワークを使用しているため、コードが多くの時間を費やしている関数を見つけ出し、フレームワークのベスト プラクティスまたはその他の最適化によってそれを削減する方法を見つけ出すことになるため、これはあまり役に立ちません。パフォーマンスの改善に関する優れたブログ投稿がいくつかありますが、これは非常に役に立ちました。