mieki256's diary

開発用のデバッグ処理を記述する際に、

#ifdef DEBUG
    .....
#endif

という書き方をする場合がある。これは、

static final boolean DEBUG = true;

if ( DEBUG ) {
    ....
}

という書き方ができる。…たぶん。

• DEBUG には static final を指定してあるので、javaコンパイラは DEBUG を定数として取り扱う。
• 定数として true が指定してあるのだから、if ( DEBUG ) { ... } は、コンパイラが行う最適化によって、単に ... の部分がコードとして出力される。
• DEBUG = false とすれば、if (DEBUG ) { ... } は絶対に処理が通らないことになる。と、javaコンパイラは判断してくれるので、最終的にコードとしては出力されない。

よって、目的は果たせる。はず。たぶん。

懸念事項としては、javaコンパイラがそこまで最適化をしてくれるだろうか、という点がある。javaコンパイラはかなりタコなのではないか、信用できん、と言われるかもしれない。

とはいえ、実際に true / false を変更して出力された .jar のバイト数を確認したところ、バイト数が増減していることは確認できた。javaコンパイラもさすがにこの程度の最適化はしてくれてるのではないか、と判断できる。…たぶん。おそらく。

定数埋め込みを期待して、

#define SCREEN_W 240

といった記述をすることがあるが。これは、java における定数の記法、

static final int SCREEN_W = 240;

といった形で書ける。

iアプリ開発の初期においては、定数埋め込みをプログラマーが意識的に手作業で行わないと、容量削減に繋がらなかったような雰囲気があったらしく。故に、プリプロセッサで #define を列挙していく方法が当たり前になってる、らしいのだけど。

現状では、難読化ツールと最適化ツールを通すことによって、似たようなことをある程度やってくれる模様。いや、もしかすると javaコンパイラが優秀になって、定数は定数として扱う・埋め込んでくれるようになったのかもしれないけれど。

実際に、

• static final int 〜 = 〜 の記述のままのソース
• 手作業で定数埋め込みをしたソース

を、

1. コンパイル
2. 難読化
3. 最適化
4. .jar 圧縮

を経由させて、最終的に出力されたそれぞれの .jar のバイト数を確認してみたのだけど。単純に定数埋め込みをすれば、その分バイト数が減るといった関係性は特に見出せなかった。それどころか、場合によっては逆にバイト数が増える場面もあったりして首を傾げたり。どうも .jar に圧縮する段階で、バイト数の増え方・減り方が予想しにくくなるような、そんな予感も。

そんなわけで。もしかすると、「プリプロセッサを用いて定数埋め込みをすれば容量が減る」という話は、もはや迷信の類になりかけているのではないか。てなことを思っていたりするのだけど。さて。

例えば、

#ifdef DEBUG
  #define DEBUG_MESSAGE System.out.println
#endif

といった定義をしてる場合。冗長な記述や、関数呼び出しを避けたうえで、同様のことを行う方法はちょっと思いつかない。

if ( DEBUG ) { System.out.println(...); }

といったように長々と書くか。あるいは、

public void DebugMessage(String str) {
    if ( DEBUG ) {
        System.out.println(str);
    }
}

DebugMessage(...);

といったように、関数・メソッドにすることになりそうな。

後者の書き方でも、javaコンパイラ or 最適化ツールが、コードに出力しないよう上手くやってくれるならいいのだけど。そのへん未検証だったり。関数呼び出しまで「これは要らないだろう。関数の中身は空なんだから」と判断してくれるなら助かるのだけど。そこまで判断してくれないなら、空の関数を呼び出すコードが無意味に入り込んでしまって、バイト数が増えてしまう。

前者の書き方をする場合、eclipse 等のコード補完機能を使えば、打ち込む手間隙はそんなにかからないとは思うけど。例えば、syso と打って補完機能を使えば、System.out.println に直してくれたりするわけで。＞ eclipse。適当な文字列に、適当な補完文字列を割り当てておけば、記述する行為自体は楽になる。はず。

作業途中で、画像読み込みに関して、自分のやりたいこととは、ちと違うことに気がついた。全画像を一気に展開するのではなく、必要なときに必要な画像だけ展開したいわけで…。そうなるとあちこち大きく書き換えることになる。うーむ。

…自分が作ったソースを元にして、作業したほうが良さそうな気もしてきた。が、バグが出たときの検証・修正を考えると、できるだけ向こうに合わせておいたほうがいいんだよな。うーん。

ルパンの目の前で、ちょっと親しくなった子供が ―― 例えば、ピアニストになる夢を語っていた少女の指が、クラスター不発弾を拾ったことで吹き飛んだり。あるいは、サッカー選手になると宣言した少年の足が、地雷を踏んで吹き飛んだり。

ルパンは子供を、病院まで、抱いて連れて行く。ルパンの赤ジャケは、子供の血でみるみる染まっていく。パッと見はわからないけど。

病院の屋上で落ち込んでるルパンに、次元が声をかける。今まで散々人を殺してきたお前が、たかだかガキの手足ごときで神妙な顔してるんじゃねえ。みたいな。

ルパンが答える。俺がワルサーの引き金を引くときは、殺す相手の顔をしっかり見ながら引いてる。でも、「正義の戦争だ」と叫んだあの大統領は、夢を断たれたあの娘の顔を、これっぽっちでも思い浮かべながら叫んでいたのか。みたいな。…とか大体そんな感じにならないか。そっち方面はよく知らんけど。

つーか市街地にクラスター弾撃ったのはアメリカじゃなくて別の国だったような。と思ったが、アメリカもまだ使ってるのかな。

やはり血の色なのか。

じゃあ、最初のルパンは何故緑色で、3番目のルパンは何故ピンクなのか。

まあ、実際は、単に見栄えの問題かなとは思うんだけど。何か意味を盛り込む・こじつけてみるのも面白そう。

モンキーパンチという漫画家が「ルパン三世」という漫画を大ヒットさせた。アニメ化の企画も舞い込み日本中で大ヒット。しかし、アニメ版があまりにもメジャーになり過ぎて原作が顧みられることは無くなってしまった。不満を持つ原作者。自分の作ったキャラじゃないのに、色紙にクラリスを描いてくれと言われても困るのだ。いっそのこと、アニメ化の権利を奪い返したい。が、打つ手がない。そこで彼が目をつけたのが、世界的にも有名な大泥棒、ルパン三世。

ってなんか既に似たようなエピソードがありそうな気もしてきた。まず間違いなく、似たようなタイトルはありそうな予感。

ルパンが、ルパンのアニメ化の権利を盗もうとするにあたって、アニメ業界の暗部が次々と露呈していくのですよ。って、どうしても社会派路線にしたいのか。＞自分。

TVSPの2時間分、ルパンは刑務所・独房の中。様子を見に来た銭形との会話だけで話が進む。

そんな脚本を書ける人、居ないわな。ていうかプロットの段階で絶対没になりそう。

2時間ずっと、銭湯 or 温泉で、女湯を覗くことに果敢にもチャレンジ。全裸・フルチンで。

ソレ、「うる星やつら」ではないか。

次元は「アホらしい」とか言ってシラケてそうだけど。ゴエモンは微妙な立ち回りをさせたほうが面白そう。

ルパンの絞首刑から始まるあたりからして凄い。発想における格が、近年のTVSPとは違う感じが。

シールじゃなくてソールというのか。自分の使ってるマウスは IntelliMouse Optical だから、AS-24/26 あたりを選べばよいのだな。…む。Web販売のみの商品なのか。