Unity3D：iOSアプリケーションデリゲートの変更

iOS用のゲームを開発するプロセスの多くは、いずれかのネイティブ機能を使用する必要性に対処しなければならなかったと思います。 Unity3Dに関しては、この問題で多くの問題が発生する可能性があります。一部の機能を実装するには、Objective-Cで記述されたネイティブプラグインに目を向ける必要があります。 この瞬間に誰かがすぐにアイデアを絶望し、放棄します。 誰かが既製のソリューションをAssetStoreまたはフォーラムで探しており、既製のソリューションがすでに存在することを望んでいます。 既製のソリューションがない場合、私たちの最も永続的なものは、iOSプログラミングの深byとObjective-CコードとのUnity3Dの相互作用に突入する以外の方法はありません。



最後の道を選択する人は（私自身も知っていると思いますが）、この困難で厄介な道で多くの問題に直面します。

• iOSはまったく馴染みのない孤立したエコシステムであり、独自の方法で開発されています。 少なくとも、アプリケーションに到達する方法を理解するために多くの時間を費やす必要があります。また、自動生成されたXcodeプロジェクトの深さのどこで、Unity3Dエンジンがアプリケーションのネイティブコンポーネントと対話するためのコードがあります。
• Objective-Cは、かなり独立した、ほとんど似ていないプログラミング言語です。 そして、Unity3DアプリケーションのC ++コードと対話することになると、Objective-C ++と呼ばれるこの言語の「方言」が登場します。 彼についての情報はほとんどなく、そのほとんどは古代のものでありアーカイブです。
• Unity3DとiOSアプリケーション間の相互作用のプロトコルはあまり説明されていません。 最も単純なネイティブプラグインの開発方法を書いているネットワーク上の愛好家のチュートリアルのみに頼るべきです。 同時に、より深い問題や複雑なことをする必要から生じる問題に触れる人はほとんどいません。

Unity3DとiOSアプリケーションとの相互作用のメカニズムについて学びたい方は、catの下でお願いします。



Unity3Dのネイティブコードとの緊密なボトルネックをより明確にするために、この記事では、iOSアプリケーションデリゲートとUnity3Dコードの相互作用の側面について説明します。これにより、C ++およびObjective-Cツールが実装され、アプリケーションをデリゲートする方法を変更できます。 この情報は、Unity3D + iOSリンケージメカニズムの理解と実用化の両方に役立ちます。

iOSとアプリケーション間の相互作用

はじめに、アプリケーションとシステムの相互作用がiOSでどのように実装されているか、またはその逆を見てみましょう。 概略的に、iOSアプリケーションの起動は次のようになります。







コードの観点からこのメカニズムを研究するには、「シングルビューアプリ」テンプレートを使用してXcodeで作成された新しいアプリケーションが適しています。







このテンプレートを選択すると、出力はデバイスまたはエミュレーターで実行でき、白い画面を表示できる最も単純なiOSアプリケーションを提供します。 Xcodeは、ソースコードを含む5つのファイル（ヘッダー.hファイルが2つ）と、興味のないいくつかの補助ファイル（組版、構成、アイコン）を含むプロジェクトを作成します。







ソースコードファイルが何を担当しているか見てみましょう。

• ViewController.m / ViewController.hは、あまり興味深いソースコードではありません。 アプリケーションにはビュー（コードではなく、ストーリーボードを使用）があるため、このビューを制御するControllerクラスが必要になります。 一般に、この方法でXcode自体はMVCパターンを使用することを推奨します。 Unity3Dを生成するプロジェクトには、これらのソースファイルはありません。
• AppDelegate.m / AppDelegate.hは、アプリケーションのデリゲートです。 カスタムアプリケーションコードの作業が開始されるアプリケーションのポイント。
• main.m-アプリケーションの開始点。 C / C ++アプリケーションのように、プログラムが起動するメイン関数が含まれています。

次に、 main.mファイルで始まるコードを見てみましょう。

int main(int argc, char * argv[]) { //1 @autoreleasepool { //2 return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); // 3 } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1行目ではすべてが明確であり、説明なしで2行目に進みましょう。これは、アプリケーションのライフサイクルがAutoreleaseプール内で発生することを示しています。 自動解放プールを使用すると、アプリケーションのメモリ管理をこの特定のプールに委ねることがわかります。つまり、特定の変数のメモリを解放する必要がある場合の問題を処理します。 iOSでのメモリ管理に関するストーリーはこのストーリーの範囲を超えているため、このトピックを掘り下げる意味はありません。 このトピックに興味がある人のために、例えば、 この記事を見つけることができます。



行3に進みましょう。UIApplicationMain関数を呼び出します。 プログラムの起動パラメーター（argc、argv）が渡されます。 次に、この関数では、アプリケーションのメインクラスとして使用するクラスが示され、そのインスタンスが作成されます。 最後に、アプリケーションデリゲートとして使用するクラス、そのインスタンスが作成される、アプリケーションクラスインスタンスとそのデリゲート間の接続が設定されることが示されます。



この例では、アプリケーションインスタンスを表すクラスとしてnilが渡されます-大まかに言って、ローカルアナログはnullです。 nilに加えて、 UIApplicationから継承した特定のクラスをそこに渡すことができます。 nilが指定されている場合、UIApplicationが使用されます。 このクラスは、iOS上のアプリケーションの集中制御ポイントであり、シングルトン（シングルトン）です。 これにより、アプリケーションの現在の状態、通知、ウィンドウ、システム自体で発生したイベント、このアプリケーションに影響を与えるイベントなど、ほぼすべてを学習できます。 このクラスはほとんど継承しません。 Application Delegateクラスの作成について詳しく説明します。

アプリケーションデリゲートの作成

アプリケーション呼び出しとして使用するクラスの指示は、関数呼び出しで発生します

 NSStringFromClass([AppDelegate class])
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この呼び出しを部分的に分析しましょう。

 [AppDelegate class]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコンストラクトはAppDelegateクラス（AppDelegate.h / .mで宣言されている）のオブジェクトを返し、 NSStringFromClass関数はクラス名を文字列として返します。 作成し、UIApplicationMain関数のデリゲートとして使用するクラスの文字列名を渡すだけです。 理解を深めるために、 main.mファイルの3行目を次のように置き換えることができます。

 return UIApplicationMain(argc, argv, nil, @"AppDelegate");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、その実装の結果は元のバージョンと同一になります。 どうやら、開発者は文字列定数を使用しないように、まさにそのようなアプローチを考え出すことにしました。 標準的なアプローチでは、デリゲートクラスの名前を変更すると、パーサーはすぐにエラーをスローします。 通常の行を使用する場合、コードは正常にコンパイルされ、アプリケーションを起動するだけでエラーを受け取ります。



クラスの文字列名のみを使用してクラスを作成する同様のメカニズムは、C＃からのリフレクションを思い出させるかもしれません。 Objective-Cとそのランタイムは、C＃のReflectionよりもはるかに強力です。 これは、この記事のコンテキストでは非常に重要なポイントですが、すべての機能を説明するには時間がかかります。 ただし、以下のObjective-Cの「Reflection」については引き続き対応します。 アプリケーションデリゲートの概念とその機能を理解することは残っています。

アプリケーションデリゲート

iOSとのアプリケーションの相互作用はすべて、UIApplicationクラスで行われます。 このクラスは多くの責任を引き受けます-イベントの発生源、アプリケーションの状態などを通知します。 ほとんどの場合、彼の役割は通知です。 しかし、システムで何かが発生した場合、何らかの方法でこの変更に対応し、何らかのカスタム機能を実行できる必要があります。 UIApplicationクラスのインスタンスがこれを行う場合、このプラクティスはDivine Objectと呼ばれるアプローチに似始めます。 したがって、このクラスをその責任の一部から解放することを考える価値があります。



これらの目的のために、iOSエコシステムはアプリケーションデリゲートなどを使用します。 名前自体から、 Delegationなどの設計パターンを扱っていると結論付けることができます。 つまり、アプリケーションの特定のイベントに対する反応を処理する責任を、アプリケーションデリゲートに単純に移します。 このため、この例では、カスタム機能を記述できるAppDelegateクラスを作成し、UIApplicationクラスはブラックボックスモードで動作するようにしました。 このアプローチは、アーキテクチャ設計の美しさの点で誰かに議論の余地があるように思えるかもしれませんが、iOSの作者自身がこのアプローチに私たちを押し付けており、開発者の大部分（すべてではないにしても）がそれを使用しています。



アプリケーションの作業中にアプリケーションデリゲートがメッセージを受信する頻度を視覚的に確認するには、図を見てください。







黄色の長方形は、アプリケーションライフサイクルの特定のイベントに応じたさまざまなデリゲートメソッドの呼び出しを示しています。 この図は、アプリケーションの状態の変化に関連するイベントのみを示しており、通知の受け入れやフレームワークとのやり取りなど、デリゲートの責任に関する他の多くの側面は表示していません。



Unity3Dからアプリケーションデリゲートにアクセスする必要がある場合の例をいくつか示します。

1. プッシュおよびローカル通知の処理
2. アプリケーション起動イベントを分析に記録する
3. アプリケーションの起動方法の決定-「クリーン」またはバックグラウンドを終了する
4. アプリケーションが起動された正確な方法-通知のためにタッチする、 ホーム画面のクイックアクションを使用する、または単にインコンをタップする
5. WatchKitまたはHealthKitとの相互作用
6. 別のアプリケーションからURLを開いて処理します。 このURLがアプリケーションに適用される場合、システムにブラウザでそのURLを開かせる代わりに、アプリケーションで処理できます。

これはシナリオの完全なリストではありません。 さらに、デリゲートがネイティブプラグインの多くの分析および広告システムを変更することは注目に値します。

Unity3Dがアプリケーションデリゲートを実装する方法

ここで、Unity3Dによって生成されたXcodeプロジェクトを見て、Unity3Dでアプリケーションデリゲートがどのように実装されているかを見てみましょう。 iOSプラットフォーム用にビルドする場合、Unity3Dは多くの定型コードを使用するXcodeプロジェクトを自動的に生成します。 アプリケーションデリゲートコードは、このテンプレートコードにも適用されます。 生成されたプロジェクト内には、 UnityAppController.hおよびUnityAppController.mmファイルがあります 。 これらのファイルには、興味のあるUnityAppControllerクラスのコードが含まれています。



実際、Unity3Dは「Single View Application」テンプレートの修正バージョンを使用します。 このテンプレートでのみ、Unity3Dはアプリケーションデリゲートを使用してiOSイベントを処理するだけでなく、エンジン自体の初期化、グラフィックコンポーネントの準備などにも使用します。 メソッドを見ると、これは非常に理解しやすいです。

 - (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UnityAppControllerクラスのコード内。 このメソッドは、カスタムコードに制御を転送できるアプリケーションの初期化時に呼び出されます。 たとえば、このメソッド内には、次の行があります。

 UnityInitApplicationNoGraphics([[[NSBundle mainBundle] bundlePath] UTF8String]); [self selectRenderingAPI]; [UnityRenderingView InitializeForAPI: self.renderingAPI]; _window = [[UIWindow alloc] initWithFrame: [UIScreen mainScreen].bounds]; _unityView = [self createUnityView]; [DisplayManager Initialize]; _mainDisplay = [DisplayManager Instance].mainDisplay; [_mainDisplay createWithWindow: _window andView: _unityView]; [self createUI]; [self preStartUnity];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの課題の詳細についても説明しなくても、Unity3Dの作業準備に関連していると推測できます。 次のシナリオが判明します。

1. main.mmのmain関数が呼び出されます
2. アプリケーションのインスタンスクラスとそのデリゲートが作成されます。
3. アプリケーションデリゲートは、Unity3Dエンジンを準備して起動します
4. カスタムコードが機能し始めます。 il2cppを使用する場合、コードはC＃からIL、そしてC ++コードに変換され、Xcodeプロジェクトに直接入ります。

このスクリプトはかなり単純で論理的に聞こえますが、潜在的な問題をもたらします。Unity3Dで作業しているときにソースコードにアクセスできない場合、どのようにアプリケーションデリゲートを変更できますか？

影響を受けるUnity3Dがアプリケーションデリゲートを変更する

AppDelegateListener.mm/.hファイルを調べることができます。 これらには、任意のクラスをアプリケーションデリゲートのイベントリスナーとして登録できるマクロが含まれています。 これは良いアプローチです。既存のコードを変更する必要はなく、新しいコードを追加するだけです。 ただし、重大な欠点があります。すべてのアプリケーションイベントがサポートされるわけではなく、アプリケーションの起動に関する情報を取得する方法がありません。



ただし、最も明白な、受け入れられない方法は、Unity3DがXcodeプロジェクトをビルドした後にデリゲートソースコードを手動で変更することです。 このアプローチの問題は明らかです。このオプションは、手でアセンブリを作成し、各アセンブリの後にコードを手動で変更する必要性に混乱しない場合に適しています。 ビルダー（Unity Cloud Buildまたはその他のビルドマシン）を使用する場合、このオプションはまったく受け入れられません。 これらの目的のために、Unity3D開発者は抜け穴を残しました。



UnityAppController.hファイルには、変数とメソッドの宣言に加えて、マクロ定義も含まれています。

 #define IMPL_APP_CONTROLLER_SUBCLASS(ClassName) ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このマクロは、単にアプリケーションのデリゲートをオーバーライドすることを可能にします。 これを行うには、いくつかの簡単な手順を実行する必要があります。

1. Objective-Cで独自のアプリケーションデリゲートを作成する
2. ソースコード内のどこかに次の行を追加します

    IMPL_APP_CONTROLLER_SUBCLASS(___)
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

3. Unity3DプロジェクトのPlugins / iOSフォルダー内にこのソースを配置します

これで、標準Unity3Dアプリケーションデリゲートがカスタムデリゲートに置き換えられるプロジェクトを受け取ります。

デリゲート置換マクロはどのように機能しますか

マクロの完全なソースコードを見てみましょう。

 #define IMPL_APP_CONTROLLER_SUBCLASS(ClassName) ... @interface ClassName(OverrideAppDelegate) \ { \ } \ +(void)load; \ @end \ @implementation ClassName(OverrideAppDelegate) \ +(void)load \ { \ extern const char* AppControllerClassName; \ AppControllerClassName = #ClassName; \ } \ @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソースでこのマクロを使用すると、マクロで説明されているコードがコンパイル段階でソースの本体に追加されます。 このマクロは次のことを行います。 まず、クラスのインターフェイスにloadメソッドを追加します。 Objective-Cのコンテキストのインターフェイスは、パブリックフィールドとメソッドのコレクションと考えることができます。 C＃では、クラスに静的なロードメソッドが表示され、何も返されません。 次に、このロードメソッドの実装がクラスのコードに追加されます。 このメソッドでは、変数AppControllerClassNameが宣言されます。これは、char型の配列であり、この変数には値が割り当てられます。 この値は、クラスの文字列名です。 明らかに、この情報はこのマクロの動作メカニズムを理解するのに十分ではないため、この「ロード」メソッドとは何か、変数が宣言される理由を理解する必要があります。



公式ドキュメントでは、ロードは、メイン関数が呼び出される前であっても、アプリケーションの起動のごく初期の段階で、各クラス（具体的にはインスタンスではなくクラス）に対して1回呼び出される特別なメソッドであると述べています。 アプリケーションの起動時のObjective-c（ランタイム）ランタイム環境は、アプリケーションの操作中に使用されるすべてのクラスを登録し、実装されている場合はその上でloadメソッドを呼び出します。 アプリケーションのコードの作業を開始する前であっても、変数AppControllerClassNameがクラスに追加されることがわかりました。



そして、「そして、この変数がメソッド内で宣言され、このメソッドを終了するとメモリから削除される場合、この変数を持つことのポイントは何ですか？」と考えるかもしれません。 この質問に対する答えは、Objective-Cの範囲をわずかに超えています。

C ++はどこにありますか？

この変数の宣言をもう一度見てみましょう

 extern const char* AppControllerClassName;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この宣言で理解できない唯一のものは、extern修飾子です。 純粋なObjective-Cでこの修飾子を使用しようとすると、Xcodeはエラーをスローします。 実際、この修飾子はObjective-Cの一部ではなく、C ++で実装されています。 Objective-Cは、「クラスを備えたC言語」であると言って、非常に簡潔に説明できます。 C言語の拡張機能であり、Objective-Cコードが散在するCコードを無制限に使用できます。



ただし、externやその他のC ++機能を使用するには、Objective-C ++を使用するためのいくつかのトリックが必要です。 この言語については、C ++コードの挿入を許可するのは単なるObjective-Cコードであるという事実のため、事実上情報がありません。 一部のソースファイルをObjective-CではなくObjective-C ++としてコンパイルする必要があることをコンパイラが考慮するには、このファイルの拡張子を.mから.mmに変更するだけです。



extern修飾子自体は、グローバル変数を宣言するために使用されます。 もっと正確に言えば、コンパイラに「信じてください、そのような変数は存在しますが、そのメモリはここではなく別のソースに割り当てられました。 そして彼女には価値もあります、私は保証します。」 したがって、コード行は単にグローバル変数を作成し、その中にカスタムクラスの名前を格納するだけです。 この変数を使用できる場所を理解するだけです。

メインに戻る

前に言ったことを思い出してください-アプリケーションデリゲートはクラス名を指定することで作成されます。 通常のXcodeプロジェクトテンプレートで定数値[myClassクラス]を使用してデリゲートが作成された場合、どうやらUnityのメンバーはこの値を変数でラップすることを決定しました。 科学的な突く方法を使用して、Unity3Dによって生成されたXcodeプロジェクトを取得し、 main.mmファイルに移動します。



その中には以前よりも複雑なコードがありますが、このコードの一部は不必要なものとして欠落しています。

 // WARNING: this MUST be c decl (NSString ctor will be called after +load, so we cant really change its value) const char* AppControllerClassName = "UnityAppController"; int main(int argc, char* argv[]) { ... UIApplicationMain(argc, argv, nil, [NSString stringWithUTF8String: AppControllerClassName]); } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、このまさに変数の宣言と、その助けを借りてアプリケーションデリゲートを作成しています。

カスタムデリゲートを作成した場合、必要な変数が存在し、既に重要です-クラスの名前。 メイン関数の前に変数を宣言して初期化すると、デフォルト値-UnityAppControllerが設定されます。



この決定により、すべてが非常に明確になります。

マクロの問題

もちろん、大多数の状況では、このマクロを使用することは素晴らしい解決策です。 ただし、大きな落とし穴があることに注意してください。複数のカスタムデリゲートを持つことはできません。 これは、2つ以上のクラスがIMPL_APP_CONTROLLER_SUBCLASSマクロ（ClassName）を使用する場合、最初のクラスには必要な変数の値が割り当てられ、それ以降の割り当ては無視されるためです。 そして、この変数は文字列です。つまり、複数の値を割り当てることはできません。



この問題は縮退しており、実際にはありそうもないと思われるかもしれません。 しかし、そのような問題が実際に発生していなかった場合、そして非常に奇妙な状況下でさえ、この記事は起こりませんでした。 状況は次のとおりです。 多くの分析および広告サービスを使用するプロジェクトがあります。 これらのサービスの多くには、Objective-Cコンポーネントがあります。 彼らはあなたのプロジェクトに長い間存在しており、あなたは彼らとのトラブルを知りません。 ここでは、カスタムデリゲートを作成する必要があります。 問題からあなたを救うために設計された魔法のマクロを使用し、プロジェクトを構築し、アセンブリの成功に関するレポートを取得します。 デバイスでプロジェクトを実行すると、機能が動作せず、単一のエラーが発生しません。



そして、広告または分析プラグインの1つが同じマクロを使用している可能性があります。 たとえば、 AppsFlyerのプラグインでは、このマクロが使用されます。

複数の宣言の場合のextern変数の値は何ですか？

同じextern変数が複数のファイルで宣言されており、マクロの方法（loadメソッド）で初期化されている場合、変数がどの値を取るかをどのように理解できますか？ パターンを理解するために、簡単なテストアプリケーションを作成しました 。そのコードはここにあります 。



アプリケーションの本質は簡単です。 2つのクラスAとBがあり、両方のクラスで、外部変数AexternVarが宣言され、特定の値が割り当てられます。 クラスの変数値は異なって設定されます。 メイン関数では、この変数の値がログに記録されます。 変数の値は、ソースがプロジェクトに追加される順序に依存することが実験的に判明しました。 Objective-Cランタイムがアプリケーションの実行中にクラスを登録する順序はこれに依存します。 実験を繰り返したい場合は、プロジェクトを開き、プロジェクト設定の「ビルドフェーズ」タブを選択します。 プロジェクトはテスト用で小規模なので、ソースコードは8つしかありません。 それらはすべて、[ソースのコンパイル]リストの[ビルドフェーズ]タブにあります。







このリストでクラスAのソースがクラスBのソースよりも高い場合、変数はクラスBから値を取得します。それ以外の場合、変数はクラスAから値を取得します



これが理論的にどれだけ多くの問題を引き起こす可能性があるかを想像してみてください。 特に、プロジェクトが巨大で自動的に生成され、そのような変数がどのクラスで宣言されているかわからない場合。

問題解決

この記事の前半で、Objective-CがC＃Reflectionに有利なスタートを切ると言われました。 具体的には、問題を解決するために、 Method Swizzlingと呼ばれるメカニズムを使用できます。 このメカニズムの本質は、アプリケーション中に任意のクラスのメソッドの実装を別のクラスの実装に置き換える機会があることです。 したがって、UnityAppControllerの目的のメソッドをカスタムメソッドに置き換えることができます。 既存の実装を採用し、必要なコードを補完します。 メソッドの既存の実装を必要なものに置き換えるコードを書いています。 アプリケーションの作業中、マクロを使用するデリゲートは以前のように機能し、UnityAppControllerの基本実装を呼び出します。そこでカスタムメソッドが機能し、目的の結果が得られます。 この方法は、 この記事で詳しく説明されています 。 この手法を使用して、補助クラス（カスタムデリゲートの類似物）を作成できます。このクラスでは、すべてのカスタムコードを記述し、カスタムクラスを他のクラスの機能を呼び出す一種のラッパーにします。このアプローチは機能しますが、メソッドが置き換えられた場所とそれがもたらす結果を追跡することが困難であるという事実のため、非常に暗黙的です。

問題の別の解決策

発生した問題の主な側面は、カスタムデリゲートが多数存在すること、または1つだけを持つことができる、または部分的に2つに置き換えることができることです。同時に、カスタムデリゲートのコードが異なるソースファイルに忍び寄らないようにする方法はありません。アプリケーションにデリゲートが1つしかない場合は、状況を参照と見なすことができ、カスタムクラスを好きなだけ作成できる必要がありますが、これらのクラスはいずれも問題を回避するためにマクロを使用しません。



物事は小さく、ビルドマシンを使用してプロジェクトをビルドする機能を残したまま、Unity3Dを使用してこれをどのように行うことができるかを決定します。解決アルゴリズムは次のとおりです。

1. 必要な量のカスタムデリゲートを作成し、プラグインのロジックを異なるクラスに分割し、SOLIDの原則を順守し、洗練に頼らないようにします。
2. UnityAppController XCode . UnityAppController .
3. UnityAppController Unity .
4. XCode UnityAppController ,

このリストで最も難しい項目は間違いなく最後です。ただし、この機能は、ポストプロセスビルドスクリプトを使用してUnity3Dに実装できます。このようなスクリプトは、ある美しい夜に書かれたもので、GitHubで見ることができます。



この後処理はかなり使いやすく、Unityプロジェクトで選択します。インスペクターウィンドウを見て、NewDelegateFileというフィールドを確認します。変更したUnityAppControllerをこのフィールドにドラッグアンドドロップして保存します。







iOSプロジェクトをビルドするとき、標準のデリゲートは変更されたものに置き換えられ、手動の介入は不要です。これで、プロジェクトに新しいカスタムデリゲートを追加するときに、UnityプロジェクトにあるUnityAppControllerオプションを変更するだけで済みます。

PS

最後にたどり着いたみんなのおかげで、この記事は本当に非常に長くなったことがわかりました。ペイントされた情報が役に立つことを願っています。