Xamarinアプリケーションでのメモリ使用量の最適化

これは、 Samuel Debruynによる記事の翻訳です。 私はこの記事がとても気に入ったので、habrコミュニティと共有したいという自発的な欲求がありました:)

Xamarinは、.NET開発者がAndroid、iOS、macOS向けのアプリケーションを.... しかし、この驚くべき機能には価格があり、最も単純なアプリケーションでさえ大量のメモリを簡単に消費する可能性があります。 これがどのように起こり、それで何ができるかを見てみましょう。 私の例のほとんどはXamarin.Androidに基づいていますが、これはXamarin.iOSにも当てはまることがすぐにわかります。

Xamarinアプリケーションでのガベージコレクターの動作

実際、Xamarinアプリケーションはいくつかのタイプのオブジェクトを使用します。 各Xamarinアプリケーションには、2つの異なる世界に存在するオブジェクトがあります。

• System.Object
  
  
  
  から継承されたオブジェクトを含む、管理されたMonoの世界
• NSObject
  
  
  
  （iOS）またはJava.Lang.Object
  
  
  
  （Android）から継承したオブジェクトを含む、管理されていないネイティブワールド

また、2つのガベージコレクタが存在し、機能することにもなります。

• SGENと呼ばれるMonoのガベージコレクター
• ネイティブのAndroidまたはiOSの世界のガベージコレクター

最初にSGENを見てみましょう。 実際、 Xamarin Universityにはこのトピックに関する非常に興味深い講義がいくつかありますが、公式ドキュメントではこれについて非常によく説明されています。

SGENの仕組みについては詳しく説明しません。 このトピックは次の投稿に残します。 ここで知る必要があるのは、 GC.Collect()



コマンドで完全なガベージコレクションを呼び出し、 CG.Collect(0)



コマンドでゼロ世代オブジェクト（最新）のガベージコレクションをCG.Collect(0)



です。 他のコマンドのほとんどは、執筆時点ではMonoに実装されていません。 または、Xamarin Profilerのスナップショット機能を使用して、ガベージコレクションを高速化できます。

ガベージコレクションの終了SGENは、別のネイティブワールドでもガベージコレクションを起動します。

ピアオブジェクト

Xamarinで2種類のオブジェクトに言及しましたか？ はい、いいえ。 オブジェクトはすべて2つの世界に存在しますが、実際には3番目のタイプのオブジェクトを使用します。

• 管理対象オブジェクト（モノの世界）
• 管理されていないオブジェクト（ネイティブワールド）
• ピアオブジェクト（モノワールド、マネージドワールドとアンマネージドワールド間のブリッジオブジェクト）

さらに、ピアオブジェクトを2つのカテゴリに分類できます。

• フレームワークピア：Xamarin.AndroidまたはXamarin.iOS SDKの一部であるクラスのインスタンス
• ユーザーピア：自分で作成し、ネイティブオブジェクトから継承するクラスのインスタンス

したがって、Xamarin開発者として、管理対象オブジェクトまたはユーザーピアを作成する権利があります。

いくつかの例：

• フレームワークピア ： android.content.Context、UIViewController ...
• ユーザーピア： MyCustomActivity、MyCustomViewHolder、MyCustomViewController ...

それらの違いは何ですか？ これをAndroid側（iOSの場合も同様）から見てみましょう。

フレームワークピアは、多くの場合、Managed Callable Wrapper（MCW）と呼ばれます。 この名前から次のことがわかります。

• Managed Callable：オブジェクトが存在し、Monoの世界から呼び出されます
• ラッパー：これは、Monoオブジェクト内のネイティブAndroidオブジェクトのラッパーです

Xamarin / Visual StudioでAndroidバインディングプロジェクトを作成していた場合は、MCWを作成したことを知っておく必要があります。 内部では、XamarinはAndroidの世界からネイティブメソッドを呼び出すコードを生成します。 これを実現するために、JNI（Java Native Interface）を使用します。 Androidの世界に存在するが、まだXamarinでラップしていないメソッドを呼び出したい場合は、JNIを使​​用してこのメ​​ソッドを呼び出すことができます。

ユーザーピアは、Android Callable Wrapper（ACW）と呼ばれることがよくあります。 次に、この名前から次のことがわかります。

• Android呼び出し可能：オブジェクトが存在し、Androidの世界から呼び出されます
• ラッパー：これは、Monoの世界からネイティブメソッドを呼び出すことができるラッパーに過ぎません

したがって、実際には、各ピアオブジェクトは、実際にはメモリ内に存在する2つのオブジェクトで構成されていると言えます。実際のオブジェクト（ネイティブまたはモノ）とラッパーオブジェクトです。

この構造により、Xamarinはまったく異なるプラットフォームで実行できます。これがXamarinが非常に優れている理由です。 これらすべてにより、Xamarin開発者は非常に簡単にアプリケーションを作成できますが、これがどのように機能するかを理解していないことが、Xamarinアプリケーションのメモリ問題の原因になることがよくあります。

注意！ 古典的なビットマップの例

Xamarinアプリケーションで最も一般的な「大きな」オブジェクトは、ビットマップ（画像）です。 ほとんどすべてのアプリケーションには、より魅力的に見えるように、少なくともいくつかの写真が含まれています。 しかし、これには価格があります。これらの写真は、ほとんどの場合、アプリケーションのメモリ内で最大のオブジェクトです。

ただし、Androidにビットマップをダウンロードさせ、ユーザーにとって都合の良い方法でメモリ内の重量を確認すると、ほとんどの場合、サイズが無視できることに気付くでしょう。 5 MBの画像でも数バイトを占有します。

これはどのように可能ですか？ 5 MBはどこに行きましたか？ Monoの世界では、この図はネイティブオブジェクトのラッパーにすぎません。 このネイティブオブジェクトは、メモリで5 MBを占有します。

さて、言ってみましょう、しかしこれはどのように問題の原因になり得、これは投稿のトピックにどのように関係しますか？ 以下のアクティビティコードを見てみましょう。

 [Activity(Label = "App1", MainLauncher = true, Icon = "@drawable/icon")] public class MainActivity : Activity { protected override void OnCreate(Bundle bundle) { base.OnCreate(bundle); SetContentView(Resource.Layout.Main); for (int i = 0; i < 100; i++) { var hugeBitmap = Android.Graphics.BitmapFactory.DecodeFile($"path/to/bitmaps/{i}.png"); if(!ImageContainsUnicorn(hugeBitmap)) { continue; } var imageView = FindViewById<ImageView>(Resource.Id.SomeImageView); imageView.SetImageBitmap(hugeBitmap); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは100個のビットマップをロードし、画像にユニコーンが含まれているかどうかを確認し、含まれている場合はImageViewに表示します。 割り当てられたビットマップがスコープから外れるとすぐにガベージコレクターによって収集されるため、最後に1つのビットマップのみを使用するため、メモリの問題はありません。

間違った。 OutOfMemoryException



原因で、アプリケーションは数ミリ秒でOutOfMemoryException



します。 これが起こる理由を理解するために、この状況でXamarinがどのように機能するかを見てみましょう。

hugeBitmap変数はMCWであり、Monoでのこのオブジェクトのサイズは小さくなります。 上記のコードは一般に（Monoの世界で）ガベージコレクションを開始すべきではありません。

一方、アンドロイドはクレイジーになり、ガベージコレクターはクレイジーなペースで実行されます。 ただし、組み立てられるオブジェクトを見つけることはできません。 ガベージコレクターはビットマップを収集できません。ビットマップはマネージド（モノ）ワールドのラッパーオブジェクトを参照するためです。 マネージラッパーがSGENによって収集されるまで、ネイティブガベージコレクターは何もできません。 その結果、ネイティブの世界では、アプリケーションはOutOfMemoryException



をキャッチします。

何ができますか？

各ピアオブジェクトはIDisposableインターフェイスを実装します。 これがどのように実装されているかを簡単に見てみましょう。

• 財団のNSObject
• Java.Langのオブジェクト

Xamarin.Androidの上記の実装は、Java.Interopの使用に切り替えたため、最新バージョンでは使用されなくなったことに注意してください。 これの実装自体は完全に異なりますが、作業方法は古い方法と非常に似ています。

ご覧のとおり、 Dispose()



の呼び出しは、ラッパーとラップされた（ネイティブ）オブジェクトの間のブリッジをDispose()



ます。 これにより、リンクが削除されます。ラッパーオブジェクトを破棄した後、もちろん、このオブジェクトにネイティブワールドにリンクがない場合、ネイティブオブジェクトはガベージコレクタによって収集できます。

いいね！ だから私は常にすべてのオブジェクトでDispose()



を呼び出す必要がありますか？

ほとんど、しかし完全ではありません。 実際、using構文を使用して上記のコードを改善できます。 知っているように、usingはusingブロックの終了後、すぐにDispose()



呼び出します。 99％の場合、必要なメソッド/プロパティを呼び出した直後にフレームワークピアを破棄するのは完全に正常です。 ネイティブオブジェクトは、必要な限り存続し、このオブジェクトへの参照以外は何も壊しません。

上記のコードの改良版は次のようになります。

 protected override void OnCreate(Bundle bundle) { base.OnCreate(bundle); SetContentView(Resource.Layout.Main); for (int i = 0; i < 1000; i++) { using(var hugeBitmap = Android.Graphics.BitmapFactory.DecodeFile($"path/to/bitmaps/{i}.png")) { if (!ImageContainsUnicorn(hugeBitmap)) { continue; } using(var imageView = FindViewById<ImageView>(Resource.Id.SomeImageView)) { imageView.SetImageBitmap(hugeBitmap); } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、 OnResume()



などの別のメソッドでImageViewを使用する必要がある場合、ImageViewをOnResume()



するのに最適な場所Dispose()



、アクティビティ自体のOnDestroy()



またはDispose()



。 FindViewById()



を必要な回数だけ呼び出すことができると主張して言うことができますが、これは非常に高価な操作であり、避けるべきです。 通常、このメソッドはオブジェクトのライフサイクルの最後に使用するか、 Dispose()



メソッドをオーバーライドします。 これは必要なことではありませんが、アプリケーションのメモリ使用量を減らすのに役立ちます。

イベントに関する小さなメモ

おそらく、上記のすべてがイベントに適用されることを既に推測しているでしょう。 アクティビティの最後のライフサイクルメソッド、View Controllerなどでイベントの登録を解除することを忘れないでください。 または、SGENはオブジェクトを収集しません。 オブジェクトにピアオブジェクトへの参照がある場合、これらのピアオブジェクトは永久に存続します。

ユーザーピアオブジェクトでDispose（）を呼び出さないようにする理由

時間が来たら、Xamarinはユーザーピアオブジェクトに対してDispose()



を呼び出します。 しかし、アプリケーション開発者にとって、この時期がいつ来るべきかを理解するのはそれほど簡単ではありません。 一般に、ドキュメントには、ユーザーピアオブジェクトに対してDispose()



手動で呼び出さないでください。 オブジェクトを参照しているものが何もないことを確認してください。そうすれば、フレームワークが作業を行います。

IntPtrおよびJNIHandleOwnershipを持つコンストラクター

Dispose()



ユーザーピアオブジェクトを手動で呼び出し、Android OSがこのオブジェクトを必要とする場合、Monoは以下のコンストラクターを呼び出します。

 public MyClass(IntPtr javaRef, JniHandleOwnership transfer) : base(javaRef, transfer) { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様のコンストラクターは、JNIHandleOwnershipなしのXamarin.iOSのみにあります。 この場合、Monoは消えたオブジェクトを再作成しようとします。

そのようなコンストラクターが実装されていない場合、アプリケーションはNotSupportedException



即座にNotSupportedException



します。 Googleがオブジェクトのライフサイクルを変更することを決定し、このサイクルの最後までDispose()



を呼び出すと、アプリケーションもクラッシュします。

WeakReferenceがどのように役立つか

ネイティブオブジェクトへのリンクを配置しないように、通常の（強力な）リンクの代わりにWeakReferenceを使用します。 これは、これらのオブジェクトを検索する際のパフォーマンスに少しコストがかかりますが、ネイティブガベージコレクターはいつでもこれらのオブジェクトを収集できます。 したがって、リンクのタイプを慎重に選択してください！ すぐに消えることのできないビットマップは、弱いリンクの良い候補になる可能性がありますが、UILabelのような小さなオブジェクトの場合、それは実際には重要ではありません。

Xamarin.Formsはどうですか？

Xamarin.Formsの各要素には、モバイルプラットフォーム上で独自のレンダリングがあり、カスタムまたはNuGetパッケージの一部として提供されます。 これらのレンダリングはユーザーピアであり、そのように見なされます。 以下に、組み込みのAndroidレンダリングでDispose()



実装する方法の例を示します。 レンダリングを実装し、常に内部のネイティブオブジェクトを破棄する場合は、同様のパターンに固執することをお勧めします（こちらのコードを参照）。

AndroidとiOSがお手伝いします

AndroidとiOSには、差し迫ったメモリ不足を通知できるメカニズムがあります。 iOSでは、これはUIViewControllerのDidReceiveMemoryWarning（）です 。 Androidでは、これはより隠されており、文書化されていません： ApplicationのOnTrimMemory（） 。 これらのメソッド内でGC.Collect()



を呼び出す必要があると想定するのは論理的です。 これにより、いくつかのオブジェクトがクリアされ、いくつかのファイナライザが開始され、使用されていないピアオブジェクトでDispose()



呼び出されます。 これにより、ネイティブガベージコレクターが未使用のオブジェクトをクリーンアップし、ネイティブ側の空き容量を増やすことができます。

おわりに

この投稿は、Xamarinアプリケーションのメモリ効率を向上させるためのいくつかの有用な提案を提供すると思いますが、まだ多くのことを伝えてください。 これについては次の投稿で説明しますが、その間、ドキュメントを読んだり、GitHubでXamarinのソースコードを参照したり、Xamarinやネイティブプロファイラーを試してみたりできます。