メモリ問題のため、自作UIへ変更予定

何回かのエントリでメモリのことを書きましたが、正式に問題点を書いておきます。

まず前提として、僕の開発環境(iPod touch 2G)では、iOS4を入れて、空きメモリ20-30MBに状況によくなります。次にアプリの使用メモリを調べたのですが（状況によって変わってきますが）、だいたい以下のようになります。

 アプリ13MB + 展開したMIDI 1-6MB + Soundfont 8MB(推奨音源の最大値) = 22-27MB

推奨メモリ 24MB超えています。MIDIも展開して効率重視でデータを持っているので、200KB越えのデータになると、結構膨らんできます。この部分は減らせるかもしれませんが、今は考えないことにします。兎に角、今後の拡張することを考えると、これ以上メモリを使用することはできません。

ここで問題にするのは、最初の13MBです。このうち4MBぐらいが、アプリ起動時から増えていきます。これは、サイドメニューのUIを開いたときに起こります。この部分は応答性を向上させるために、メモリに常駐させているからです。では、UIのどこにメモリを使っているのでしょうか？
結論から言ってしまえば、midif0nのメモリ消費量を不相応に増大させているのは画像ファイルです。もっと言ってしまえば、ボタン(UIButtonクラス)の状態ごとの画像データです。
iPhoneのUIを作成するIB(Interface Builder)というツールがありますが、画像を貼付けたボタンを作成する場合、この画像は、内部的に32bitのフルカラー画像として扱われます。
※公式ドキュメント等を調べたわけではありません。メモリの増減を測定した結果です。

※編集画面です。開発中の画面なので、デバッグ文字列が表示されています。

では、上の画面あたり、どのぐらいメモリを使用しているか具体的に計算してみましょう。まずボタンには４つの状態があります。通常、ハイライト、選択状態、無効の４つの状態です。しかし、ハイライトと選択状態は同じ画像を割り当てていますので、データとしては3つ分です。UI設計は、操作の快適性のため、大きめのボタン(64x64)を採用しています。

縦5列、横4行、サイズ64x64のボタンが3つの状態を持ち、32bit(4 bytes)カラーなので
5x4x64x64x3x4=960KB
だいたい1MBです。この画面が複数あるわけですから、かなりのメモリを使用することになります。

対応方法として、IBを使わずに画像の内部フォーマットを変更できるかもしれませんが、とりあえずこの問題を置いて、もう一つの問題を見てみます。それは、UI変更のリアルタイム性です。これは多くのアプリでは問題になりませんが、音楽アプリにおいては、高負荷の処理中に、リアルタイムで何らかのデータをユーザーにフィードバックさせることは良くあります。実際に開発中に、ミキサー画面のVolume, Pan変更をタイマーを用いてリアルタイムに変更してみました。結果は、負荷が高い場合に、UI更新時に音とびが発生して使い物になりませんでした。

結論として、Cocoa TouchのUIクラスはメモリとパフォーマンスを考慮とすると必ずしも優れた設計になっているとは言えません。
有名な音楽制作アプリのNanoStudioは、この点を考慮して、自作UIを採用している訳ですね。ここで、UI自作のメリットをまとめてみます。

• 高速化（パフォーマンスが見積もりやすくなる）
• 省メモリ
• 可搬性の向上（移植性が高くなる）

車輪の再発明をする前に、まず他に使用できそうなライブラリがないか調べる必要があります。検索すると、Clutterの名前がかなりひっかかります。Clutterは、OpenGL/OpenGL ESを用いたUIライブラリです。インテルやノキアのMee GoやGoogleのChromium OSといった大きなプロジェクトで採用されていることから、信頼性は高いと考えて良さそうです。問題はライセンスがLGPLな点、また調べている限りでは、iPhoneのサポートがどうなっているか不明だったため、早々に調査は打ち切りました。

現状では、ビュー(UIView)、ラベル(UILabel)、ボタン(UIButton)、スライダー(UISlider)程度を実装すれば足りるため、ライブラリは使わずに自前で書くことにしました。そんな訳で、バージョン1.1では、メイン画面に重なるUIを全面的に書き換える予定です。デザイン的に多少、劣化するかもしれませんが、ご承知お願いします。