マニュアルに書かれている「1度ビルドして同じ出力先へさらにビルドすればインクリメントビルド」ですが、恐らくiOSプラットフォームの事を指しているのだと思われます。
元々IL2CPPのインクリメントビルドはiOSのみ先行して実装されており、ビルド時のターゲットディレクトリに以前と同じロケーションを指定すると「Warning
Build folder already exists.Would you like to append or replace it?」というダイヤログが表示されていました。
この時、Appendを選択するとインクリメンタルビルドとなっていました。
例えば#00 pc 000f2224の部分が、il2cpp::vm::GetReducedType(Il2CppClass const*) at C:\Program Files\Unity\Hub\Editor\2020.3.18f1\Editor\Data\il2cpp\libil2cpp\vm/Class.cpp:?となり、実際にどのクラスの何行目でクラッシュが発生したのかを確認することが出来ます。
赤色の部分はシンボリケート出来なかった部分です。libart.so not foundとなっており、これはシンボルファイルlibart.soが見つからなかったことを表します。libart.soを何処からか入手できれば、Pickup Custom Locationから指定を行うことでシンボリケートを行いことは可能な筈です。
The display pipeline contains a queue of frames, typically of size 2, which fills up if the game is trying to present frames too quickly. With no more room in the queue, the game loop (or at least the rendering thread) is blocked by an OpenGL or Vulkan call. The game is then forced to wait for the display hardware to show a frame, and this back-pressure synchronizes the two components. This situation is known as buffer-stuffing or queue-stuffing. The renderer process doesn't realize what's going on, so framerate inconsistency gets worse. If the game samples input before the frame, input latency gets worse.
