プログラミング

アプリサイズ10KB!ドコモのiアプリ開発時の涙ぐましい努力【プログラミング】

現在の携帯端末といえば、スマホのiPhoneとandroidが主流で、それぞれのアプリも非常に充実しているものがあります。皆さんも自分の好きなアプリをインストールして、充実したスマホライフを満喫していることでしょう。

エンジニアの中には「スマホアプリ作っているよ」という人もいるでしょう。僕もだいぶ昔にandroidアプリ作成を多少経験したことがあります。といっても、アプリ開発をしていたわけではなく、テスト用のアプリ作成を経験した程度。

当時はまだスマホが出て2~3年くらいのときで、作り方もいまいちよく分からない状態でやっていました。その後現場が変わったこともあり、androidアプリに触れる機会はなくなってしまったのですが、チャンスがあればやってみたいなと思っているところです。

 

というわけで、今回はスマホアプリの話・・・と思いきや、そうではありません。スマホ誕生前に主力として活躍していたフューチャーフォン(=ガラケー)で、かつドコモのiアプリの話です。

初期のドコモのiアプリのときに導入されていた方法が、涙ぐましい努力の結晶だったことを紹介したいと思います。昔は大変だったな~なんて感傷に浸りたい人は、ぜひどうぞ。

ドコモのiアプリとは?

「iアプリ」とは何ぞやということですが、日本の携帯電話のキャリアとして最大手であるドコモがガラケー全盛時代にリリースしたJavaアプリのことです。iOSのアプリという意味ではありません。

僕は大学生から18年間くらいドコモを使っていて、iアプリの誕生から現在までをユーザとして経験した人間。といっても、もはやどんなアプリを使ったか全然覚えていません。唯一覚えているのは、「Jigブラウザ」かな。

ガラケー時代は、通常ブラウザとフルブラウザ(PCサイトも見れるブラウザ。今では当たり前)のに分かれており、フルブラウザ対応の料金プランはも高く設定されていたんだけど、「Jigブラウザ」などのiアプリによるフルブラウザを使えば、安い料金プランでも使い放題で重宝していました。

今のスマホとはもちろん比べ物になりませんが、当時のガラケーの性能をフルに引き出して、速度的にも非常に優秀だったと記憶しています。思い出補正は否定しませんが。

調べてみたところ、なんと、公式サイトがまだ生き残っていました。スマホ用のJigブラウザがあるのは知っているけど、ガラケー今でもサポートしているんですね。すごい。

初期のアプリサイズは10KBまで

で、そんなiアプリですが、初期のアプリサイズが驚愕の数値で、最大10KBです。

これは最初期に出された、DoJa-1.0プロファイル上のアプリの情報です。アプリサイズは10KB、ヒープ容量が96KBが最小でした。どちらも極めて厳しいサイズですが、アプリサイズの制限が本当に大変だったと言われています。

機種 アプリサイズ(KB) ヒープ容量(KB)
FOMA N2001 10 96
FOMA N2002 10 560
FOMA P2101V 30 1100
FOMA D2101V 10 128
FOMA P2002 10 560
FOMA SH2101V 30 1024
FOMA T2101V 30 1105

 

 

アプリサイズというのは、つまりはコードからコンパイルしたバイトコードや、画像などのリソースも含めたJarファイルです。これを10KB(10240バイト)に抑えていたわけです。

アプリサイズはあまり意識しかことないかもしれないので、どのくらいのもんなのか確認してみます。ただ、iアプリの開発環境を構築するのはいろいろと難しい事情があるので、2019年4月30日現在のandroidのアプリサイズで比較します。

  • Jota+(Text Editor) 7.17MB
  • ストップウォッチタイマー 2.34MB

比較的機能が少なそうなアプリを選んだつもりですが、小さいものでも2MBは軽く超えています。モノも時代も異なるので、一概に比較はできませんが、10KB以内にまるのを作成できるとは想像できないですね。

初期のアプリの開発コード

iアプリのサイズが極めて厳しいことは分かったけど、じゃあどうやって作っていたのよ、と疑問になりますよね。何か削る要素があるのかというと、基本的にはなくてプログラムを削るしかないんです。

プログラム削ったら機能が不足するので、やりたいことができないじゃないか、と言われると確かにそうなんですが、一つだけ機能を減らさずにサイズを減らす方法があります。

それは変数名やクラス名、メソッド名を小さくすることです。コードはかなり適当な感じで書きますが、例えばこんな感じ。


// ----------------------------------
// 変更前
// ----------------------------------
public class MainFrame {

    private static final String TITLE = "サンプルアプリ";
    private static final String ERROR_MESSAGE = "エラーが発生しました";

    public void showFrame() {
        try {
            // 何らかの処理
        } catch (Exception e) {
            showMessage(ERROR_MESSAGE);
        }        
    }

    public void showMessage(String message) {
        // メッセージ表示処理
    }
}

// ----------------------------------
// 変更後
// ----------------------------------
public class F {

    private static final String A = "サンプルアプリ";
    private static final String B = "エラーが発生しました";

    public void s() {
        try {
            // 何らかの処理
        } catch (Exception e) {
            m(B);
        }
    }

    public void m(String s) {
        // メッセージ表示処理
    }
}

 

変数名やメソッド名の文字数を減らしていけば、コンパイルされるclassファイルに書かれる文字数が減るのでサイズ減少が期待できます。とにかく省エネのプログラムですね。

この程度の大きさのプログラムであれば、これでも読めないことはないですが、組めば組むほど可読性が悪くなるのは目に見えています。

この問題をどうやってクリアしたのでしょうか?

プリプロセッサ+Javaという邪道

先人は知恵を絞った結果、Java言語では使用しないあるものを使用することにしました。C系の言語でよく使用するプリプロセッサです。

具体的には以下のようなコードを書きます。


#define _MainFrame     F
#define _TITLE         A
#define _ERROR_MESSAGE B
#define _showFrame     s
#define _showMessage   m
 
public class _MainFrame {
 
    private static final String _TITLE = "サンプルアプリ";
    private static final String _ERROR_MESSAGE = "エラーが発生しました";
 
    public void _showFrame() {
        try {
            // 何らかの処理
        } catch (Exception e) {
            _showMessage(_ERROR_MESSAGE);
        }
    }
 
    public void _showMessage(String s) {
        // メッセージ表示処理
    }
}

下記の構文は”_MainFrame”という文字を”F”という文字に変換することを意味しています。

 #define _MainFrame F

この部分はJavaの構文ではないので、当然Javaコンパイラではコンパイルできません。なので、1回をプリプロセッサに通します。そうすると、以下のコードが出来上がります。


public class F {
 
    private final String A = "サンプルアプリ";
    private final String B = "エラーが発生しました";
 
    public void s() {
        try {
            // 何らかの処理
        } catch (Exception e) {
            m(B);
        }
    }
 
    public void m(String s) {
        // メッセージ表示処理
    }
}

これでコンパイルすることができるので、あとは普通にビルドするだけですね。

このようにマクロ併用のコードに対し、プリプロセッサ→Javaコンパイラと2段階に分けて通すことで、可読性を上げつつサイズを減少させることができました。まあ、IDEは使えないので、それは大変だったと思いますが。

実は今回の記事は、別サイトで見たプリプロセッサ併用の工夫を元に書いています。そのサイトを最近探してみたのですが、見当たらず。ただ、個人的におもしろいと思っていて、自分で残しておこうと思って書いたものです。

最後に:今では絶対やらないであろう工夫がおもしろい

当時のモバイル端末は、メモリもストレージもとにかく少なく、開発時にも知恵を絞っていたことが伺えます。詳しくは知らないけど、ファミコンのソフトなどはもっとすごい工夫をしていたんじゃないかなと予想しています。

現在の携帯やスマホは、メモリもストレージの容量も充実しているので、このような工夫は全く必要なく、恵まれた環境にあります。ただし、こういう絞りに絞った知恵みたいなものは生まれにくくなったかもしれません。

潤沢なリソースが使用できる環境で開発できることに感謝しつつ、制限の中で精一杯取り組むことは忘れないようにしていきたいですね。そして、今後も良いものを作ることができるように心がけていきます。

プログラミングスクールに通って実務までの最短距離を歩もう

人手不足により、プログラマの報酬が大きく増加しています。首都圏の場合、2~3年の経験を積めば月単価60万円(月商)も可能。

プログラマの魅力は手に職がつくこと、働く場所を選ばないことです。経験を積んでいけば、将来的には憧れのノマドワーカも夢ではありません。

ただし、プログラミングは自主学習の難易度が極めて高く、孤独で相談できない環境は多くの人が挫折します。なので、メンターや仲間と一緒に取り組めるプログラミングスクールに通うのがベターです。

中には就職支援をしてくれるスクールもあります。スクールを活用し、最短距離で実際の開発現場へ進んでいきましょう。

相談はこちらから▼