堅牢で省資源な文字列“ディスクリプタ”：Symbian OS開発の勘所（5）（1/3 ページ）

Symbian OSでの文字列（ディスクリプタ）は、実装を隠し機能のみを公開することに加えて、リソースを徹底的にケチる設計となっている

[大久保 潤 管理工学研究所，＠IT MONOist]

　今回はユーザーサイドで可変長のオブジェクトを扱うためにSymbian OSで用意されている機構の1つ、文字列（ディスクリプタ）について解説を行います。この部分はそれほど難しい作りはしていないのですが、Symbianが携帯・スマートフォン開発に必要だと考えているもの（あるいは不要だと考えているもの）が明らかになる面白いデザインをしています。これらを通じて携帯・スマートフォン開発の位置付けに関する誤解を解いていければ、というのが今回のもくろみです。

文字列から見えてくる視点の違い

　機能の提供主体がデバイス側にあり、ソフトウェアはそれらを制御するだけという本当にピュアな組み込みシステムの場合、文字列処理で悩むことは少ないでしょう。しかし表示装置を介するユーザーインターフェイスを持ち、ちょっと複雑な内容を表示しようとすると文字列をいかに扱うかという悩みは必ず発生します。さらに高度化し、例えばユーザーに文字列を編集させる、メールをやりとりする、HTMLを解析する等々の機能が必要になる環境では、もちろん動的に変わる文字列を適切に扱える枠組みが必要になります。このように文字列に対する態度でグルーピングしていくと、その結果はそのまま組み込みシステムの分類にもなりそうです。図1にまとめてみましょう。

図1　組み込みシステムのレベリング

　リアルタイム性が必要とされる組み込みシステムですが、その応用の幅は多岐にわたっています。そしてLevel3に属する組み込みシステムは、最近になって現れてきたカテゴリです。そのため携帯・スマートフォンのシステム開発で主要な問題である「システムの複雑度」に対する理解がなおざりにされているきらいがありました。

　「ありました」と過去形になっているのは、例えばFOMAのOSがSymbian OS（4ベンダ）とLinux系（2ベンダ）だけになってしまっていることによります。

タスクスイッチを行うリアルタイムスケジューラとC言語があればすべてが記述できる。ほかに必要なのは適切な設計だけだ。さあ周期タスクがきちんと起床されるようにクロック数を計算していこうじゃないか（注1）。

　このアプローチは図1でいうLeve1からせいぜいLevel2のカテゴリには妥当なのでしょうが、携帯・スマートフォンの複雑度に対してはあまりに粗雑過ぎました。もちろんリアルタイム処理ができることは必須要件なので、それらに関する機構が存在することや、技法を守ることは必要です。しかしそれだけでは十分な条件にはなりません。

　多くの組み込みOSは、そのあたりの対象システムの複雑度にかかわる部分を「アプリケーション固有の設計」と切り捨てて回避してしまっています。リアルタイムかつ省電力な環境におけるGUIはどのような構造を持つべきか、その環境でプログラムをコンポーネント化して扱うためには何が必要なのか、そのようなことを真剣に考えるべきだったのでしょうが、残念ながら多くのOSにおいてそれらは達成されなかったようです。その結果が現在FOMAに搭載されているOSの種類に集約されています（注2）。

　Level3の要求を満たす組み込みOSでは、リアルタイム性を保証しつつGUIを用意し、かつソフトウェアのコンポーネント化を進めるためにフレームワーク群が導入されています。そして文字列もこのフレームワーク群と整合性を持つように、違った装いを持つのが一般的です。

※注1：

最近このような趣旨に基づく組み込み技術の解説書を読みました。基本的な技術の解説部分については特に異論はないのですが、その本によれば携帯・スマートフォンもその技法で解決できる問題の範疇に入っているのだそうです。誠にナイーブな、もしくは、為にする論だといえるでしょう。

※注2：

これらのOS群の中でSymbian OSの競争優位性の源泉は何か、とよく質問を受けます。第4回で述べたとおり、フレームワークがそろっているので悩まずに済むというのはもちろんですが、「省電力性」を実現するために徹底的に非同期性を導入したところにあるというのが、最近の筆者の答えです。これを実現している非同期フレームワークについては次回いよいよ解説を行います。