« Robの嘆き、そしてハッパ | トップページ | サイズ削減計画の掟 »

アセンブラ気分

 iアプリを作るべく、いろいろなサイトや本を漁り、どうやら敵は「サイズ」であることが判明。503iを無視すればコードサイズ(jar)は30KB以下でなければならない。30KBつったらあーた、240Kbitでっせ。ファミコンのゼビウスも載りません(256KbitROM)。ちなみに1MbitROMは128KBなので、900iでギリギリ足りないサイズ(100KB)。DQ1がやっと載るくらい。もちろんスクラッチパッドという拡張RAMがあるんですが、その代わりJavaなのでどっちもどっちですな。

 で、Javaで(速度ではなく)サイズを気にするなんてのは普通ならしなくていいので、jarサイズを縮めるテクニックなんてのは、常套手段がないわけですが、幾つか見つけまして、とりあえずまとめてみました。

 まず、諸悪の根源はクラスです。クラスを1つ作るとclassファイルが1つ出来、そのサイズが馬鹿にならない(200B程度)ので、クラスは極力減らすことが重要です。クラスの中にクラスを作ったってclassファイルは(innerClass@とかいうプレフィクスのおまけつきで)できてしまうので、無駄なあがきです。
 というわけなので、構造体(としてのクラス)はあきらめましょう。カラーRGBを構造体で纏めるなんてもってのほか(w)です。
 クラスは1つが望ましいのですが、画面描画につかうCanvasと、アプリ起動に使うIApplicationの二つが必要なので、どうしても最低二つにならざるを得ません(画面描画用にPanelを使うのなら別)。
 結論として、iアプリは、IApplicationを継承したアプリ起動クラスとCanvasを継承した画面描画クラスの二つだけで作ることが望ましいです。

 クラスが二つだけということで、すでにオブジェクト指向などというものは役に立たなくなってるわけですが(w)、せっかく二つあるんだから再利用性やクラスの独立性も考えて、二つのクラスにそれぞれふさわしい役割分担をさせたいと思うのがプログラマの人情というものでしょう。
 すぐに考え付くのが、描画周りはCanvas継承クラスで、内部処理やライブラリその他はIApplication継承クラスでメソッドを書くというやり方です。美しいですね。
 しかし、それはお勧めできません。
 別クラスのメソッドを呼び出したり、フィールド変数にアクセスするよりも、自クラスのそれにアクセスした方がサイズ的に有利だからです。
 クラスを増やさないというのはiアプリ鉄の掟ですが、メソッドを増やさないのもまたiアプリの掟です。単なるフィールド変数のアクセサを書くなんてもったいないことをしてはいけないのです。
 そうなると別クラスではpublic宣言をする必要があります。自クラスであればpublicにする必要はありません。
 また、二つのクラスを同じようにメソッドを増やして太らせるよりも、思い切って1つのクラスで全てを行ってしまった方が後々メモリの調整もしやすくて有利です。
 それに片方のクラスを汎用機能を纏め、ライブラリ化してしまうとサイズが固定化/肥大化しがちですし、「動くものは弄るな」の法則が働いてしまいます。

 そうなると、答えは決まってきます。IApplication継承クラスは、Canvas継承クラスのインスタンスを作って、カレントに割り当てるだけで後は何もしない。全ての処理はCanvas継承クラスで行います。アプリケーションの終了でさえ、IApplicationクラスに戻る必要はありません。
 再利用性は、ソースコードのコピペで実現しましょう。どうせiアプリなんて、そう何回もメンテしませんし、Dojaのバージョンが変われば手をつけなければなりません。機種ごとのカスタマイズだってあります。したがってライブラリ化で楽をしようと思わないことが肝要ですw。

 スレッドやイベントは極力使わないようにしましょう。
 paintメソッドは使う必要はありません。Canvas#getGraphicsでGraphicsのインスタンスは取得できます。repaint()で描画指示を出すよりも、lock()/unlock()を使ったほうが制御しやすいし、処理も速いし、機種依存もありません。
 processEventメソッドは使わざるを得ませんが、そこでダラダラキーの処理を行っているとメインループに影響を与えることになるので、typeとparamだけ取得してどっかにコピーして終わらせちゃった方がラクでしょう。
 つまり最低限必要なメソッドは、アプリ起動のIApplication#startとCanvas継承クラスのメインループ(例えばexe())とキー取得イベントをキャッチするCanvas#processEventの3つだけ、ということになります。簡単なアプリなら本当にこれだけでOKです。


 ということで、すでにJavaの体裁を成していない異形のプログラム構造になってしまいましたw。先人たちの業績や今のトレンドをぶちこわしにするプログラミングスタイルですが、どこかなつかしさを感じます。
 これって「昔のゲーム機でアセンブリ言語」で書くときと同じですよね。あるいは8bitPCでBASICプログラミングもそうです。
 スコープなし、構造体なし、オブジェクト指向なし。SFCはそうでした。それでもシムシティが作れてしまうわけです。ウィンドウシステムもお手の物です。別にJavaの機能を駆使しなければ作れないものではないのです。めんどくさいかもしれませんけど、一人で作るくらいのスケールなら、これもアリでしょう。昔とった杵柄気分ですね。

 ただ、ソースファイルまでひとつになってしまうのが難点です。まあプリプロセッサを使えばいいわけですが、そうなると益々Javaではなくなってしまいますな、わははw

|

« Robの嘆き、そしてハッパ | トップページ | サイズ削減計画の掟 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/19762/709646

この記事へのトラックバック一覧です: アセンブラ気分:

« Robの嘆き、そしてハッパ | トップページ | サイズ削減計画の掟 »