N505はiアプリ開発者の鬼門である。
すばらしい企画もN505対応のために泣く泣く仕様を削除する。
とにかく搭載メモリが少ないのが一番の原因だ。
今回の開発もN505検証のために大幅なスケジュールのズレが生じた。
デバッグも後一歩で終わる、その時!
N505だけアプリが動かないと報告が・・・・・・・・・・・・・・・・・。
2日前まではバリバリ動いていたのに。
何が起こったのか?
確かにバグ修正は行ったが、そんな大幅な変更していない。
しかもN505だけだ。
なぜなんだ~。
と叫んでも仕方が無いので現状把握することに。
動かない原因は"Out of Memory"だった。
これは想定の範囲だ。
確かにクライアントの要望で追加したから使用メモリも増えただろう。
試しに容量を削減すれば前の状態に戻るのでアプリは動くハズだ。
ビルドしてアプリを起動する。
う、動かん・・・・。
とっさにVisualSorceSafeを起動し、2日前のソースの履歴をチェックし変更箇所を確認する。
特におかしいところはない。
他に変更した所はないか脳内検索をかける。
「!」
まだ変更した所がそういえばあった。あったはいいがまさかそれが原因なんて・・・。
いやいや、すべてにおいて疑いを持つのがプログラマの仕事だ。
その辺は刑事と似ている。(←刑事は自分を疑わないけど)
その変更箇所とはjamファイルのスクラッチパッド容量の指定だ。
通常505シリーズのスクラッチパッド容量のMAXは200KBなのだが、開発中はスクラッチパッドの消費サイズが100KBでも、その指定はMAXの200KBとしている。開発中は容量が変動するので毎回書き直すのが面倒だからだ。
スクラッチパッドのデータ内容が確定した時点で使用容量を小さくする。
例えば最終が120KBだった場合、MAXの200KBのままだと、そのアプリをダウンロードした時点で200KB消費してしまう。残りの80KBは未使用のままだ。携帯ユーザーのアプリダウンロード数にかかわるから最適化するのが人の道。
そのスクラッチパッド容量の最適化をしたのが2日前。
最終データは160KBだったので、スクラッチパッドの指定は170KBとしたのだった。(←多少余裕をもたせておき、直前の変更にも対応できるようにしておく)
まさかとは思ったが、jamのスクラッチパッド指定を200KBに戻してアプリを起動した。
う、動いた!
原因はよくわからないが、とにかく動いた。ソースはいじってない。
もちろんN505以外はこんなことをしなくても動いている。
また野生の感を使ってしまった・・・・。
Nシリーズはメモリアラインがシビアな設計(N900でも問題がある)なので、jamの指定容量で何か変わってしまうのか?
それとも何か単純なミスをしているのか?
今のところ不明。