ObjectPool参考サイト
（執筆日：2016/11/14）文章は原文ママ、備忘録移植に伴いリンクを追加
Instantiateがラグい。Instantiate（Destroy）は比較的重いとのこと。
Objectの再利用をするObjectPoolを使おうと考えた。
今回使用させてもらったオブジェクトプールを記載する。
他の方の計測結果
Debug.Log() や Instantiate() などの速度を計測してみる - Qiita
使用したオブジェクトプール
新・オブジェクトプール - テラシュールブログ
注意事項
リサイクルをする＝オブジェクトは削除されない時がある＝HPなどのリセットはStartに書けない。
OnEnable()でリセットが必要な動作を行うこと。それ以外の使いまわせる部位はStartでもいい。
ただしAwake→OnEnable→Startの順に実行されることを忘れないこと。必ず実行してほしいコルーチンをOnEnableに入れた際に、そのコルーチンが使う変数やリファレンスもOnEnable内で設定しないといけない。５
オーディオクリップのLoad Type【Unity】
オーディオクリップをロードする際に設定できる項目に関してのメモ
(オリジナル：2017年)
Force To Mono:
チェックすることでモノラルになる。ファイルサイズがかなり圧縮される。
Load Type: Decompress On Load
オーディオファイルは読み込まれるとすぐに展開されます。サイズの小さい圧縮サウンドにこのオプションを使えば、その場での展開に伴うパフォーマンスのオーバーヘッドを防ぐことができます。ただし、Vorbis でエンコードされたサウンドを読み込み時に展開すると、圧縮されたままの場合の10倍程（ADPCM エンコーディングでは約3.5倍）のメモリーを使用するので、サイズの大きいファイルにはこのオプションを使用しないでください。(Unityマニュアル)
シーンを読み込むと同時に圧縮されたファイルを展開してメモリにロードする。
メリット：すでに展開してあるので再生時のCPU負荷が少なくすむ。
デメリット：ファイルが大きいとメモリも大量に使う。
用途：短いSEなど
Load Type: Compressed In Memory
サウンドはメモリ中では圧縮されたままで、再生中に展開されます。このオプションは若干のパフォーマンスオーバーヘッドが発生します（特に Ogg/Vorbis 圧縮ファイルの場合）ので、メモリー使用量が大きすぎて読み込み時に展開できないファイルにのみに使用してください。展開はミキサースレッドで行われ、Profiler ウィンドウ内の Audio ペインにある “DSP CPU” のセクションでモニタリングできます。(Unityマニュアル)
再生時に展開するため、メモリ消費は上に比べて抑えられる。しかしCPU負荷はある。
メリット：メモリの使用が抑えられる。
デメリット：解凍するためにCPU負荷。
用途：
Load Type: Streaming
サウンドをその場でデコードします。この方式では、圧縮データのバッファーのための使用メモリーが最小限に抑えられます。データはディスクから段階的に読み込まれて必要に応じてデコードされます。展開は別のストリーミングスレッドで行われますが、その CPU 使用量は Pofiler ウィンドウ内の Audio ペインにある “Streaming CPU” のセクションでモニタリングできます。(Unityマニュアル)
よりメモリ消費を抑えれる。長いBGM向け？
備忘録投稿につき追記
上記の特徴を実際に計測したわけではないため、profilerを使って自分で確かめてみる。（BGM系のオーディオクリップ、圧縮はVorbis）
BGM1曲のみ再生
Decompressが他の二つよりメモリを食っていることがわかる。BGMはシーン中常駐していることが多いので下二つ、SEなど頻繁になる可能性がある音は１番上で使うのがやはり正しいか。
参考文献
Collider(Trigger)が当たってないのに反応する・対処法【Unity】
問題：Collider(Trigger)が明らかに当たってないのにOnTriggerEnter2D()が呼ばれる。
追加情報：ChildコンポーネントにもColliderがついている。
結論：ChildコンポーネントのOnTriggerEnter2D()が呼ばれた際、Parentの方のOnTriggerEnter2D()も呼ばれている。
以下詳細：
キャラクターが敵の発射したロケットを攻撃することで、ダメージを受けずにそのロケットを破壊できるようにしたかった。しかしテストしてみるとダメージは受けない（＝破壊には成功している）ものの、攻撃をくらった際ののけぞりアニメーションが再生された。
Debug.Logを使ったところ、どうやらChildコンポーネントのOnTriggerEnter2D()と同時にParentのOnTriggerEnter2D()も呼ばれている様子。
画像にあるSword1HBは剣攻撃1のヒットボックスを担当している。
- ロケットは「プレイヤー攻撃」に触れると壊れる
- 剣攻撃は「エネミー」に触れるとダメージを与える
- ロケットは「キャラクター」に触れるとダメージを与える
- プレイヤーは「エネミーの攻撃」に触れるとのけぞる
「」内はタグ。タグでどのようなColliderなのかを判別している。
今回はこれら4つの処理の中、１つ目のCollisionが行われた際に４つ目のCollisionの処理が出てしまったのが原因だった。最初の設計時にこれらの知識がなかったため、これでも行けると勘違いしていた。
この問題の解決方法はいくつか考えられるが、Responsibility（責任）を見直すことにした。
以下、エクストラ：
ダメージの発生とのけぞりの判定が分かれている。これはあまりよろしくないのでは？と考えた。しかしロケットからダメージ与える責任をなくしてしまうと今回の想定外の挙動は直し辛い（今後のギミックの追加のためにも親子関係は崩したくない）。なのでダメージを受けるキャラクター側をいじるのがベストだろう。
のけぞるとダメージを受けるを同じ管轄で行うようにした。
