スクリプトの制限

Unity は、サポートしているすべてのプラットフォームで共通のスクリプティング API と体験を提供します。ただし、独自の制限があるプラットフォームもあります。これらの制限を理解するために、以下の表では、各プラットフォームとスクリプティングバックエンドに適用される制限について説明します。

プラットフォーム (スクリプティングバックエンド)	事前 (AOT) コンパイル	スレッドに対応
Android (IL2CPP)	可	可
Android (Mono)	なし	可
iOS (IL2CPP)	可	可
スタンドアロン (IL2CPP)	可	可
スタンドアロン (Mono)	なし	可
ユニバーサル Windows プラットフォーム (IL2CPP)	可	可
Web (IL2CPP)	可	なし

事前コンパイル (AOT)

プラットフォームの中には、ランタイムのコード生成ができないものもあります。そのため、そのようなデバイスで実行時 (Just-In-Time、JIT) コンパイルをおこなうと失敗します。代わりに、すべてのコードを事前 (Ahead-Of-Time、AOT) にコンパイルする必要があります。しばしば、この差異はあまり重要でないこともあります。しかし、ある特定の場合では、AOT コンパイルを必要とするプラットフォームには、追加の配慮が必要なことがあります。

リフレクション

リフレクションは AOT プラットフォームでサポートされています。 しかし、コードがリフレクションによって使用されていることをこのコンパイラーが推測できない場合、ランタイムにコードが存在しない可能性があります。 詳細は マネージコードストリッピング を参照してください。

System.Reflection.Emit

AOT プラットフォームは、System.Reflection.Emit 名前空間のメソッドを実装できません。

シリアライズ

事前 (AOT) コンパイルが必要なプラットフォームでは、リフレクションの使用が原因でシリアライズと非シリアライズで問題が発生することがあります。シリアライズと非シリアライズの一部として、型とメソッドをリフレクション経由でのみ使用できる場合、事前コンパイラーは型とメソッドのためにコードが生成される必要があることを検知することができません。

ジェネリック型とメソッド

ジェネリック型とメソッドの場合、異なるジェネリックインスタンスは異なるコードを必要とするため、コンパイラーはどのジェネリックインスタンスを使うかを判断しなければなりません。例えば、List<int> に使われるコードは、List<double> に使われるコードと異なります。しかし、IL2CPP は参照型のためのコードを共有します。つまり、List<object> と List<string> には同じコードが使われます。

以下のような場合、IL2CPP がコンパイル時に見つけられなかったジェネリック型やメソッドを参照することが可能です。

1. ランタイムに新しいジェネリックインスタンスを作成する場合。Activator.CreateInstance(typeof(SomeGenericType<>).MakeGenericType(someType))；
2. ジェネリックインスタンスで静的メソッドを呼び出す場合。typeof(SomeGenericType<>).MakeGenericType(someType)).GetMethod("AMethod").Invoke(null, null)；
3. 静的ジェネリックメソッドを呼び出す場合。typeof(SomeType).GetMethod("GenericMethod").MakeGenericMethod(someType).Invoke(null, null)；
4. コンパイル時に推論できないジェネリック仮想関数への呼び出しがある場合。
5. 深いネスト状のジェネリック値の型を持つ呼び出しの場合。例えば、Struct<Struct<Struct<...<Struct<int>>>>

To support those cases IL2CPP generates generic code that will work with any type parameter. However this code is slower because it can make no assumptions on the size of the type or if it is a reference or value type. If you need to ensure that faster generic methods are generated, do the following:

• If the generic argument will always be a reference type, add the where: class constraint. Then IL2CPP will generate the fallback method using reference type sharing which causes no performance degradation.
• If the generic argument will always be a value type, add the where: struct constraint. This enables some optimizations, but the code will still be slower because the value types can be different sizes.
• Create a method named UsedOnlyForAOTCodeGeneration and add references to the generic types and methods you wish IL2CPP to generate. This method does not need (and probably shouldn’t) be called. The example below will ensure that a specialization for GenericType<MyStruct> will be generated.

public void UsedOnlyForAOTCodeGeneration()
{
    // Ensure that IL2CPP will create code for MyGenericStruct
    // using MyStruct as an argument.
    new GenericType<MyStruct>();

    // Ensure that IL2CPP will create code for SomeType.GenericMethod
    // using MyStruct as an argument.
    new SomeType().GenericMethod<MyStruct>();

    public void OnMessage<T>(T value) 
    {
        Debug.LogFormat("Message value: {0}", value);
    }

    // Include an exception so we can be sure to know if this
    // method is ever called.
    throw new InvalidOperationException(
        "This method is used for AOT code generation only. " +
        "Do not call it at runtime.");
}

“速い (小さな) ビルド” 設定を有効にすると、ジェネリックコードの完全に共有可能な 1 つのバージョンだけがコンパイルされることに注意してください。 これは生成されるメソッドの数を減らし、コンパイル時間とビルドサイズを削減しますが、ランタイムのパフォーマンスを犠牲にします。

ネイティブコードからのマネージメソッドの呼び出し

ネイティブコードから呼び出せるように C 言語の関数ポインターにマーシャリングを行う必要があるマネージメソッドには、AOT プラットフォーム上でいくつかの制限があります。

• マネージメソッドは静的メソッドでなければなりません。
• マネージメソッドは、MonoPInvokeCallback 属性を持つ必要があります。
• マネージメソッドがジェネリックの場合、[MonoPInvokeCallback(Type)] オーバーロードを使用して、サポートする必要があるジェネリックの特殊化を指定する必要があるかもしれません。 その場合、型は正しい数のジェネリック引数を持つジェネリックインスタンスでなければなりません。以下のように、1 つのメソッドに複数の[MonoPInvokeCallback] 属性を指定することができます。

// Generates reverse P/Invoke wrappers for NameOf<long> and NameOf<int>
// Note that the types are only used to indicate the generic arguments.
[MonoPInvokeCallback(typeof(Action<long>))]
[MonoPInvokeCallback(typeof(Action<int>))]
private static string NameOfT<T>(T item) 
{
    return typeof(T).Name;
}

スレッド不可

プラットフォームによっては、スレッドの使用をサポートしていません。そのため、System.Threading 名前空間を使用するマネージコードはすべて、ランタイムに失敗します。また、.NET クラスライブラリの一部は、暗示的にスレッドに依存しています。よく使われる例としては、System.Timers.Timer クラスがあり、スレッドのサポートに依存しています。

例外フィルター

IL2CPP は例外フィルターをサポートしていますが、IL2CPP は C++ 例外を使用してマネージ例外を実装しているため、フィルターステートメントと catch ブロックの実行順序が異なります。 フィルターがフィールドへの書き込みをブロックしない限り、気づかないかもしれません。

MarshalAs と FieldOffset 属性

IL2CPP は、MarhsalAs と FieldOffset 属性をランタイムで反映することをサポートしていません。IL2CPP はコンパイル時にはこれらの属性をサポートしています。適切な プラットフォーム呼び出しによるマーシャリング を行うために、これらを使用する必要があります。

dynamic キーワード

IL2CPPは、C# の dynamic キーワードには対応していません。このキーワードには JIT コンパイルが必要ですが、IL2CPP では不可能です。

Marshal.Prelink

IL2CPPは、 Marshal.Prelink または Marshal.PrelinkAll APIメソッドをサポートしていません。

System.Diagnostics.Process API

IL2CPP は、System.Diagnostics.Process API メソッドをサポートしていません。デスクトッププラットフォームでこれが必要な場合は、Mono スクリプティングバックエンドを使用してください。