Windows Mobile 6 .Net コンパクト フレームワーク フォーム ベースのアプリケーションをサポートしています。アプリケーションで使用されているデータ量が原因でメモリ不足エラーが発生するポイントに到達しました。アプリケーションの期待寿命は限られていますが、代替プラットフォーム/アプリケーションが開発されるまで、適切に機能し続けることを確信したいと思います. アプリケーションで使用されるデータ量は減っていないため、1 つのオプションはアプリケーション コードのサイズを縮小することです。
少し前に、アプリケーション コードが占有するメモリを最小限に抑える方法の 1 つは、すべてのソースを個別のアセンブリに移動し、小さなスタートアップ シェルを使用してアプリケーションを起動することであると指摘したブログ投稿またはドキュメントを思い出しました。そのアプローチの作業を開始する前に、それが正しいアプローチであることを確認し、それによって達成される可能性のある節約を数値化したいと思います。
上記のアプローチは正しいですか?もしそうなら、それをサポートするドキュメントはありますか?
すべてのアプリケーション コードをマネージ dll に配置し、非常に小さな実行可能スタブを作成して起動する方法について説明すると、プロセスに必要なメモリ量が減少します。節約できるメモリ量は、次に高い 64Kb 境界に合わせて配置された実行可能ファイルのサイズに相当します。
詳細については、次のブログ エントリを参照してください: http://blogs.msdn.com/b/robtiffany/archive/2009/04/09/memmaker-for-the-net-compact-framework.aspx
このブログ エントリには、WinCE 5 のメモリ管理システムの詳細な説明へのリンクと、恐ろしい「dll クランチ」が大きな問題である理由へのリンクもあります。
ただし、Windows Mobile 6.1 の導入以降、状況が少し変わったことに注意してください。ネイティブ Dll は、以前のバージョンと同じ場所にマップされなくなり、プロセスを操作するためのメモリ スペースが大幅に増えました。質問で Windows Mobile 6 について言及したので、この提案されたリファクタリングによって作業用のメモリが実際に増えますが、(.exe が巨大でない限り) 十分なメモリが得られない可能性があることに注意してください。
Windows Mobile 6.1 で導入されたメモリ管理の変更の詳細については、こちらを参照してください。
http://bolingconsulting.com/2008/windows-mobile-6-1-memory-management-changes/
この「メモリ不足」の問題に一度遭遇しました。PC アプリケーションで使用されるクラスほど多くの情報を含まないデータを保持するために、特別なクラスを作成する必要がありました。
MS-DOSを使用して読んだこと以外に、小さなスタートアップ シェル スクリプトの使用について参照しているドキュメントを見たことがありません。