- GC付きの言語におけるゲームプログラミング(id:yaneurao:20040324#p1)
もうそうなってくると、携帯Javaでは、GCに期待できない。またnewのオーバーヘッドも馬鹿にならないので、ゲーム開始時とかシーンの初期化時以外にnewを使えない。残る手段はC風にプログラムを書くことだ。こんなプログラム書くのなら、C++のほうが遙かにマシである。
503iの時からJava使っていると、最近のケータイは使えるリソースも多くて、しかも速くて、いい時代になったなーとかいう感じはするんだけど、その分ケータイゲーム自体が高機能になってきているので、上にあるような問題点はたぶん解消されてない。おそらくしばらくは解消されないだろう。
にしても速くなったねー。私が最初に買ったケータイはF503iで、これのLoopテストには1222msかかっている。最新のF900iでは3ms!400倍のスピードアップ。
Docomoは基本的にJava1本なのだが、auはJavaやめてCで書くようにしようよという考えでBREW1本に絞ろうとしている。最新のCDMA 1X端末は、なんともうJavaがのってないのだ。
注1) EZアプリ (Java) のアプリケーションはご利用いただけません。
BREWの問題点は、キャリアから認定されていないアプリ、いわゆる勝手アプリが作れないことにある。これは単なるauの方針なのか、それともJavaのサンドボックスモデルのようなものがないからいちいち検証をしなければいけないのか、どっちなのかは分からないけど、これのせいでのら開発者にとってはまったく魅力のない端末になってしまっている。しばらくDocomoに貢ぐ生活が続くんだろうなあ。
ケータイ上でわざわざJavaを使う利点としてよく挙げられるサンドボックスによるセーフティだけど、これもどの程度信用できるものか良く分からない。
Javaベースのアプリケーションは、いわゆる「サンドボックス」(つまりVM)内で実行されるので、テストは必要ないという誤解がよくあります。事実は、Javaベースのアプリケーションを提供している通信事業者の多くは匿名のアプリケーションがネットワーク上の携帯電話にダウンロードされ実行されることに対する危険を認識するようになり、事前検証を運用するようになってきています。
まあこれはBREW推進側の言い分なのでそのまま鵜呑みにはできない。なんやかんやいっても、VMがあるおかげで端末が致命的な状態におちいるのが防がれている場面はあると思うし。Javaステでもいいけど、C++を使ってJavaVMレベルのサンドボックスモデルをケータイ上で実現する方法って考えられているのかな。