これには若干の前提知識が要求される話で UnityC#はフロントエンド実装でしかなくコア実装がC++側にある（ここは解説に含まれています。）点です 一瞬動画中に登場したのですがUnityのフロントC#実装にあるUnityEngineObject.bindingsクラス にあるCompareBaseObjects(UnityEngine.Object lhs, UnityEngine.Object rhs)で”NULLの定義自体”をオーバーロードしています。 （この点も一応動画で一瞬サラッと説明されています） （さらにどうでもいい説明をするとCompareBaseObjectsは同値確認,C#でいうところのequals()的な奴も兼ねてます) （Unityのフロント実装はGithubで読めるので興味あればクラス名でググると読めます） じゃあCompareBaseObjectsは更に何をやってんだって話ですが,内部でGetCachedPtr() というメソッドを叩いてIntePtr.Zeroかどうかを確認しているだけです。 IntPtrはネイティブコード側のポインタを格納する型で,UnityObjectの実態とも言えます。 つまりC++側との参照が切れてるかどうかでNULLを返しているだけなので実態としてはNULLではなく参照が切れていることを表現している実態が残ります。 なので実際のNULLではないという理屈です。 そしてNULLが代入されてない以上元々参照を持っているクラスとの参照がやはり残ってしまうのでgcも走りません。 Unityの型の多くの実態はC++実装のポインタを持ってるだけです。 VS2019とかのデバッガーでも基底クラスを追っかけてm_CachedPtrとか見ると実際の値を確認できます。 やはりあくまでもC#の皮を被ったC++プロダクトなんだなと実感できます。　 じゃあintPtr.Zeroになったら自動でgcが適用されるべきだろ？とは私も思うんですがどうもそこが上手くいかない理由があるようです、パフォーマンスなのかメモリ安全の保証が困難なのかはわかりませんが・・・ NULLの実態を隠蔽するするのはいいとして、Playerloopを一周回して破棄したら自動でC#側のマネージドコードもnullを突っ込んでgc送りにする専用メソッドぐらいは整備してもいいのにとは思います。 まあもうUnity自身が20年モノの巨大プロダクトと化しておりIL2CPPとかとのも絡みもあって膨大な依存関係を修正することはもうどうしようもなく不可能な状態なのでしょう・・・

@@user-or2gc4wo8p 長文で解説して頂いて恐縮ですが、論点がズレてます 私はUnityのnull偽装については一切言及してません。MyComponentのOnDestroyの必要性について伺っています

Unity公式の見解も知りたいところですが、サードパーティのライブラリなどの実装がしょぼくてDestroyを呼ぶだけで参照を解放してなかった場合の対策と読みました..

​@@ruinzu403 ああ理解しました、深夜テンションで先走ってしまい失礼しました。 ああ恥ずかしいので後で消しますねｗ UniRXのAddto()みたいにアンマネージドメモリは全部デストラクタやOnDestroy()で破棄する習慣をつけましょうね程度のものだと思うので あんまし深い意味はないように思えます。 ただ例としては混乱を招く気はするので普通にButtonEventとかで破棄とNULL代入をしたほうがデモンストレーションとしては適切だと思いますね。 動画の締めでも長時間残ってるオブジェクトで顕在化する問題だと明言しているのでご指摘はたぶん妥当なものだと思いますが 一方で明示的な破棄をするにはNULLを代入するしかやりようがないという最大の論点には特に関係ないので割と不毛な論点かなと？とも思います 極端な話PCをシャットダウンすればメモリ開放されるから気にしなくていいよねと話に近いです。