メモリの問題

次に、3 つのｉアプリに対して JAM が記憶領域（JAR ファイルと ScratchPad の保存領域）を割り 当てる例を示します。

ｉアプリ対応携帯電話 アプリケーション

実行メモリ

Java Application Manager (JAM)

ｉアプリ1の JARファイル

ｉアプリ1の ScratchPad

ｉアプリ2の ScratchPad ｉアプリ2の JARファイル

ｉアプリ3の JARファイル (ScratchPad非使用) アプリケーション記憶メモリ

図6: ｉアプリ対応携帯電話のメモリ

開発者にとって、メモリには次の 2 つの制約があります。

• 限られたアプリケーション実行メモリ。ｉアプリはこの領域で実行されます。実行時に生成されるオブジ ェクトもここに格納されます。

• 限られたアプリケーション記憶メモリ。ここにはｉアプリのJARファイルと、そのｉアプリに対応する ScratchPadが格納されます。

アプリケーション実行時サイズに対する絶対的な制約は、ｉアプリが実行される携帯電話に搭載さ れているアプリケーション実行メモリの量によります。搭載されるアプリケーション実行メモリの 量、およびｉアプリ実行時にアプリケーション実行メモリがどのように使われるかはメーカーによ り異なります。

またアプリケーション記憶サイズは、プロファイルの世代により以下のように制限されています

（以降、1K バイト=1024 バイトとします）。これらのサイズの制限を越えるｉアプリは携帯電話 に正しくダウンロードできないのでご注意ください。

プロファイル JARファイル ScratchPad

DoJa-1.x 30Kバイト 10Kバイト

DoJa-2.x 30Kバイト 200Kバイト

DoJa-3.x 100Kバイト 400Kバイト

DoJa-4.x 100Kバイト 400Kバイト

DoJa-5.x JARファイルとScratchPadの合計で 1024Kバイト (*1)

(*1)メーカーによっては、ダウンロード即起動ｉアプリではDoJa-4.xプロファイルと同様に、JARファ

イルサイズが100Kバイトまで、ScratchPadサイズが400Kバイトまでに制限される場合があります。

注意事項：

Copyright Ⓒ 2008-2012 NTT DOCOMO, Inc. All Rights Reserved.

● ScratchPadサイズは、メーカーによっては規定のサイズより大きいサイズをサポートする場合があります。

またメーカーの採用する領域管理方式によっては、新たにインストールしようとしているｉアプリの

ScratchPadサイズが、インストール済みｉアプリが使用しているScratchPadサイズの合計サイズにより制限

を受ける場合もあります。いずれの場合にも、ｉアプリがADFのSPsizeキーで宣言した容量のScratchPad を確保できない場合、そのｉアプリは携帯電話にダウンロードすることはできません。

【DoJa-3.0】

DoJa-3.0プロファイル以降では、1つのｉアプリに割り当てられたScratchPadを内部的に最大16個まで分割管

理することができます。分割管理されたScratchPadへのアクセス方法は7.1項を、ScratchPadを分割管理する ためのADFの設定方法は15.5.1項を参照してください。

【DoJa-5.0】

DoJa-5.0プロファイル以降では、上記の規定により100Kバイトを超えるJARファイルをダウンロードするこ

とができます。ただし携帯電話に100Kバイトを超えるJARファイルをダウンロードできるようにするために は、ｉアプリの配布に使用するWebサーバーがレンジリクエストによるバイト単位の部分的GETに対応して いなければなりません。レンジリクエストに対して部分的GETの応答（206 Partial content）を返さないWeb サーバーからは、100Kバイトを超えるJARファイルをダウンロードすることはできないため注意してくださ い。

特に、JARファイルのダウンロードにおいてCGIを利用しているような場合には注意が必要です。

また上記で解説したレンジリクエストでは、If-Unmodified-Sinceヘッダを使用した条件付きリクエストが行わ れます。これに起因して、ｉアプリのダウンロード元を複数サーバでロードバランス処理させている場合など では、個々のサーバのシステム時刻、およびそれらに配置するJARファイルのタイムスタンプを合わせていな い場合、ｉアプリのダウンロードが正しく行えないことがあるため注意してください。

3.2.1 メモリ使用量の最小化

ここでは、大きなカテゴリとして、アプリケーション実行メモリとアプリケーション記憶メモリに 分けて説明します。

アプリケーション実行メモリ（ヒープメモリ）

通常、アプリケーション実行メモリを占める最大のコンポーネントは実行可能プログラム（ｉア プリ実行環境およびｉアプリを構成するクラス群）そのものです。ｉアプリとそれに必要なすべ てのオブジェクトが携帯電話のアプリケーション実行メモリに入りきらない場合は、実行可能プ ログラムのサイズか生成されるオブジェクトセットのサイズ、またはその両方を削減する以外に 方法はありません。

実行可能プログラムのサイズを削減する方法については、3.2.2 項を参照してください。

生成されるオブジェクトのサイズを削減する場合は、次に示す内容を検討します。

− ガベージコレクションを頻繁に呼び出す。特に搭載メモリ量の少ないｉアプリ実行環境では、アプリケー ション実行メモリ上に発生したフラグメンテーションが原因で、一度にまとまったサイズのメモリを確保 できなくなるケースが発生します（OutOfMemoryError、UIException、ConnectionExceptionなど の例外が発生したり、ｉアプリの動作が不安定になるなどの問題として現れます）。この場合、できるだ け早め早めにガベージコレクションを呼び出すようにすることで問題が解決することがあります。

− メモリにはできるだけ少ないオブジェクトを保持する。または生成するオブジェクトの数およびサイズを 最小限に抑える。

− アプリケーションプログラムの分割を検討する（例えば複数のレベルをもつゲームの設計では、レベル毎 にアプリケーションプログラムを分割し複数のｉアプリとするなど）。

Copyright Ⓒ 2008-2012 NTT DOCOMO, Inc. All Rights Reserved.

− 可能な限りstaticを使用する。

− 過度のメソッド呼び出しのネストや再帰を避けてスタックの深さを最小限に抑える。

− メソッドに渡すパラメータの数を最小限に抑える。

− クラスの数、および個々のクラスのサイズを最小限に抑える。

− スレッドの多用を避ける。

− サイズがあらかじめ決められたクラスを作成する。Hashtable、ByteArrayInputStream、

ByteArrayOutputStream、Vectorなど、サイズが動的に大きくなるクラスを使用すると、メモリのフ ラグメンテーションを引き起こすことがあります。

− 必要がなくなったメディアデータやイメージは速やかに破棄（dispose()）する。

生成されるオブジェクトサイズを可能な限り小さくし、アプリケーション実行メモリを効率的に使 用しているにもかかわらず、まだメモリが不足する場合は、次の内容を検討してください。

− 変数に保存しているデータをScratchPadに移す。

− メモリを消費しやすい処理をクライアント側からサーバー側に移す。

− サーバー側からデータをダウンロードする場合、一括してダウンロードするのではなく、必要最小限のも のに絞り部分的にダウンロードする。

【DoJa-5.0】

DoJa-5.0プロファイルにて、アプリケーション実行メモリの使用状況をモニタリングするためのユーティリテ

ィであるMemoryManagerクラスがcom.nttdocomo.langパッケージに追加されました。

CLDCのjava.lang.RuntimeクラスにもfreeMemory()やtotalMemory()といった類似の機能がありま すが、MemoryManagerクラスではそれら機能に加え、アプリケーション実行メモリ上の最大連続空き容量（フ ラグメントによって分断されていない連続空きエリアのうち、最大のエリアの容量）を知ることができます。

また、ｉアプリ実行環境が複数のアプリケーション実行メモリ区画を持っている（Javaオブジェクト用のヒー プの他にメディアデータ専用のヒープを持っているなど）場合には、区画ごとにこれらの情報をモニタリング することができます。

アプリケーション記憶メモリ

ｉアプリを保存するために、アプリケーション記憶メモリの中に以下の 2 つのブロックが確保され ます。

• JARファイルの格納に割り当てられるブロック

• ScratchPadに割り当てられるブロック

JARファイル

JARファイルには、できるだけコンパクトにした必須のファイルだけを入れる必要があります。ｉアプリオプ ションAPIやｉアプリ拡張APIを使用するなどの理由で携帯電話の機種ごとに異なるモジュールをｉアプリに 入れる必要がある場合は、機種ごとに別のｉアプリ（別のJARファイル）を作成することを検討してください

（機種別にダウンロードを制御する方法については第16章を参照）。このようにすれば、携帯電話にダウン ロードされるJARファイルに、不要なエントリが含まれることはありません。

またJARファイルには画像やサウンドなどのリソース（第7章参照）を含めることができますが、これはJAR ファイルサイズに大きな影響を与えます。使用頻度の低いリソースは、ｉアプリ実行時に通信機能を使用して 入手することを検討してください。