最近では、米国Googleが「Nexus One」の直売を開始したり、ドコモが「Xperia」を発表したりと、マスコミの話題先行で大いに盛り上がっています。そんな中、Mac（インテル版）にAndroid SDKをインストールし、エミュレータでアプリを動かすことを試してみました。その時の経験と感想を、iPhoneの個人（もしくは小規模）デベロッパーの視点から述べてみたいと思います。

ここではアプリの実機へのインストールやAndroid Market（iPhoneで言うところのApp Store）への登録は行っていません。また、iPhone SDKの全仕様の詳細を把握したわけでもありませんので、その分は差し引いて読んでください。詳細な技術解説はしませんが、これからAndroidプラットフォームを主用ターゲットにしようと考えているデベロッパーの方々の参考になればと思います。

・オープンソースプロジェクト

Androidはオープンソースの携帯端末プラットフォームです。これはOSやそれに付随するフレームワークがオープンソースプロジェクトとして開発され、適切なライセンスの元に配布されることを意味します。 携帯メーカはプロジェクトの成果物を無償で利用し自社製品に搭載できるだけでなく、製品により適合させるための調整や改良を行うことが可能です。そう言う意味では、Apple社も、オープンソースプロジェクトによる多くの成果物（WebKitなど）を効果的に自社製品（Mac OS XやiPhone OSなど）に活用している代表的なメーカです。

世間には「オープン、オープン」と呪文を唱えることで素晴らしい製品ができ上がると錯覚している人がいるようですが（笑）その仕組みと成果物を活用した個々の「製品のデキ」とはまったく関係ありません。また消費者の中には、このオープンの意味を、携帯キャリアの選択が自由になると取り違えている人もいるようです（笑）。加えてこうした状況の中では、意図的に「呪文」をミスリーディングさせようという意思も働いたりしますので、言葉の鵜呑みは禁物です。

携帯メーカーにすれば、プロジェクトの成果物がオープンソースとして提供されることで最新機能を搭載した携帯端末を開発しやすくなります（なにせ無償です）。それに伴うユーザ側のメリットは、Windows搭載パソコンのように、様々なメーカからAndroidを搭載した携帯端末が登場することで自分の好みに合った商品を選択できるようになることです。 例えば外付けキーボードある機種とそうでない機種から好きな方を選ぶといった感じです。 ただし、現状はキャリアとの契約に縛られてしまうため、パソコンほど自由にメーカや機種を選択できないかもしれません。

・歴史は繰り返す

片やiPhoneは製品全体（キャリアを除く）をApple一社でコントロールしています。よってiPhoneとAndroidの関係を、パソコンが普及し始めた時代のMacとWindowsに例える人もいます。しかし、筆者はちょっと違う気がしています。Windows OSはオープンソースではありませんし、Microsoftはそれを企業へライセンスすることでちゃんと収益を上げていました。AndroidをWindowsに例えるならば、携帯端末の世界には「Windows Mobaile」プラットフォームと言う前例があります。

どちらかと言うと、Android登場はパソコンの世界にLinux OSが登場した状況に近いような気がします（ちなみにAndroidのCore OSもLinuxです）。ただしLinux登場時とは異なる点も多々あります。例えばLinuxとMacが対局にあると想定すると、その真ん中辺りにWindowsがいるわけです（笑）。まあ、ここからはあくまでも個人的な見解なのですが、AndroidはLinuxほど極端に寄ってはおらず、ちょうどLinuxとWindowsの真ん中あたりの位置取りだと考えると分かりやすいかもしれません。

「iPhoneはAppleに縛られているから」と言う人をよく見かけますが、AndroidもそれなりにGoogleに縛られていると思います。つまり、Googleとて慈善事業でオープンソースプロジェクトを推進しているわけではありません。より多くの携帯端末から自社クラウドサービスを利用してもらい（主に広告から）利益を増やそうという狙いがあるはずです。よってオープンソースと言えども、それなりの方向を持ってコントロールされているでしょうし、成果物のアプリやフレームワークにしても、ある程度Googleの意図が反映された形となるはずです。

携帯端末で自社サービスを利用してもらうのなら、それがiPhoneでもかまわない訳ですが、それだけでは不十分であり、端末普及にさらなる推進力が欲しいようです。ところで、もしGoogleのライバルとなる「何か別のサービス」が世に広まり、Android自体がその普及に拍車をかけてしまったら？ この時、GoogleはAndroidにどう対峙するのでしょうか？ Appleは製品で儲け、MicrosoftはOSライセンスで儲け、Googleはクラウドサービスで儲ける、確かに現状はそうですが、これからはどうなるか分かりません。それぞれの思惑が交錯して面白い状況になったことだけは間違いないようです。

・アプリの開発環境

将来どうなるかと言うことはさておき、さっそくAndroidアプリの開発環境を構築してみましょう。嬉しいことに、AndroidアプリはMac上でも開発可能です。ちなみに、iPhoneの場合とは異なり、Androidは、Mac、Windows、Linuxのどの環境でもアプリを開発することができます。まずは、Googleサイトから「Android SDK」をダウンロードしてMacへインストールします。筆者の場合、そのSDKフォルダをiPhoneとMac SDKが保存されているDeveloperフォルダに入れて利用しました（仲良く共存）。

次に統合開発環境 IDE（Integrated Development Environment）の「Eclipse」をダウンロードしてインストールします。こちらはIBM（多分）が推進するオープンソースプロジェクトの成果物で、iPhoneで言う所の「Xcode」に相当します。Carbon版とCocoa版、そして32bit版と64Bit版が存在します。最初にEclipsを起動したら、Android用プラグインのADT（Android Development Tools)を追加インストールします。その後、Windows環境であればJDK（Java Development Kit）6.0のインストールも必要なのですが、Snow Leopard（Mac OS X 10.6）には既にインストール済みですので、その必要はありません。

MacはAndroidアプリの開発環境として相性が良いようです。珍しいことに、Androidの解説本の中にもMac環境を前提に（図版がMac画面なのですぐ分かる）書かれているものが幾つかあります。こうした解説本に従えば、インストールはそれほど難しくなく時間もかかりません。ただし、iPhoneのようにSDKをダウンロードしてインストールすればそれでOKといった簡便さはありません。それなりに行ったり来たりは発生します。 また、解説本によっては使用しているEclipsのバージョンが異なり、図版や手順が若干違う場合もあるので注意が必要です。

Androidの開発環境では、「プラットフォーム OS」「SDK」「IDE」「JDK」といった幾つかの構成要素（モジュール）が別々の管理者から提供されています。開発環境に関わる構成要素の出所が多くなると、トラブルが発生した時に、その切り分けが難しくなるのが常です。つまり「誰が悪いのか？」と言う犯人探しの手間です。こうした環境では、各モジュールに対してバージョンセンシティブに成らざるおえません。iPhoneの場合には、開発環境に問題があればAppleに文句を言えば済むわけですが、Androidでは「どこに怒りの矛先を向けて良いのか？」という混乱がついて回りそうです。

こうした混沌とした状況（それほどでもないですが）を楽しむ「若い衆」も多いと思いますが、いいかげん年を取ると面倒な事が嫌になります（笑）。 以下個人的な話で恐縮ですが「奥底にあるソースを自分で直す」と言うパワーは既に無く、いい加減に開発環境でのトラブルは勘弁（今まで苦労しすぎ）！余生は静かにアプリ開発のためのプログラミングだけに集中させて！と思う今日この頃です。余談ですが、Androidエミュレータを起動すると「NSQuikDrawViewはDEPRECATEDだからCoreGraphics APIを使ってね」と警告が表示されます（笑）。う〜ん、これを見るだけでも、この先ちょっと心配になりますね...。

・開発言語はJava

Androidアプリの開発言語は「Java」です。Javaのソースコードは中間言語に翻訳され、それをDalvik仮想マシンが解釈して実行します。データベースのSQLiteや3D描画フレームワークのOpenGLも、Javaソースコード内から利用できます。また、AndroidではWebKitも使えますので、一部のフレームワークはiPhoneと良く似ています。ただし、処理スピードに関しては、ネイティブコードにコンパイルされるObjectiv-Cには及ばないかもしれません。また、状況によっては一般的に言われるガーベージコレクションによる処理の遅延という問題も発生するかもしれません（最近のJavaシステムではかなり改善されているそうですが...）。

ところで、速度が必要な処理ではネイティブコードを使いたいと考えるデベロッパーも多いでしょう。そのために、GoogleからAndroid NDK（Native Development Kit）がリリースされています。これにより、昔からあるJNI（Java Native Interface）を用いた仕組みが追加されます。CやＣ++ソースコードからネイティブコードライブラリを作成し、それをAndroidアプリパッケージに埋め込みます。このネイティブコードライブラにゲームなどで速度が要求されるモジュールを隔離するのが有効な手段です。しかし、開発のメインルーティンから工程が分離されますので、日常的な使い勝手が良いかどうかは疑問です（ライブラリ内からJava APIが呼び出せるかも未確認）。

iPhoneでは「開発にObjective-Cを使うのがちょっと...」と言う話を良く聞きます。確かに、ユーザインターフェース制御にはCocoaの習得とObjective-C表記が必須ですが、それ以外のコードについてはCやC++でも記述可能です。C++はソースファイルの拡張子を「.mm」とするだけです。ゲーム等であれば、Objective-Cのソースコード使用量を1%未満に留めることも可能でしょう。筆者もMac版のCarbon（Cocoaではない）アプリを移植してみましたが、Objective-Cのコード量は全体の1/3程度となりました。速度を要求される個所はそのままＣやC++で記述すれば追加処理は必要なく、そのルーチン内ではObjective-C表記も使え、Cocoaメソッドを呼ぶことも可能です。

・開発工程を試す

Androidアプリの開発工程は、iPhoneのそれとそっくりです。アプリの挙動を定義したXMLファイル「AndroidManifest.xml」は、iPhoneの「info.plist」と似ています。レイアウトに配置するウィジット（iPhoneのコントロール）や文字列などのオブジェクトもXMLファイルに定義しておき、アプリから読み込んでインスタンス化します。これは、iPhoneでのnibファイルの仕組みに相当します。当然レイアウトやウィジットはAPIを使いダイレクトにソースファイルへ記載することも可能です（これも同じ）。また、各国言語に対するローカライズ作業は、こうしたXMLファイルを複数作成してアプリパッケージに埋め込む手法を取ります（これまた同じ）。

ウィジットのレイアウトには、携帯端末の画面サイズの多様性を考慮して相対配置を使うことが推奨されています（iPhoneは絶対位置）。この仕様が関係しているのかどうかは分かりませんが、Androidには「Interface Builder」に相当するビジュアル・レイアウトツールがディフォルトで付属していません。つまり、レイアウト用XMLファイルを効率的に編集するツールが無いのです。確かにEclipsのプラグインツールには簡易エディタがありますが、機能が貧弱です。解説本に別のツールアプリも紹介されていましたが、一見したところ、Mac開発者が昔々に使っていたResEditよりも底機能な感じです。

ですから、ウィジット操作で発生するイベントをソースコードのアクションに結びつける作業は手作業（テキスト編集）となります。Interface Builderであれば、ビューに配置したオブジェクトは、インスタンス変数ならIBOutletをアクションならIBActionをターゲットとして、ラインを引っ張りながらビジュアルにリンクできます。Androidには、そうした仕組みが無いようです。XMLに文字列で固有のID（iPhoneのビューのTagに相当）を定義しておき、それをソースコード上で表記することでリンクを完成させます（Carbonアプリのコントロールリソースのリンクと同じ）。

レイアウト用XMLを編集し指定オブジェクトをソースコードと結び付ける作業は、実際にソースコードを書いてプログラミングする作業と同等の手間がかかります。現在のプログラミングではこの傾向が顕著なので、Interface Builderを操作していると「俺は本当にプログラマーか？」と悩んだりします（笑）。この作業に対処する優秀なツールの存在は間違いなくアプリ開発の効率を上げます。Androidにもオープンソースの強みを生かした優秀なツールが登場することを期待したいと思います。ちなみに筆者が知らないだけで、既に優秀なツールがあるかもしれません。その場合はご容赦ください。

・フレームワーク

プログラミングでは、OSの仕組み以上にフレームワークのデザインやコンセプト（完成度）が重要です。Javaフレームワークは、元々ウェブサイト上でアプレットを起動させるために開発されましたが、現在では多用な業務現場で利用されています。Android SDKは、これに独自のフレームワークを追加することで構成されています。片やCocoaフレームワークは、NEXTSTEP（懐かしい）に搭載されていたものがMac OS Xへ移植、拡張された生粋のパソコンアプリ構築用フレームワークです。iPhone OSへの実装はそのサブッセットなのですが、実はiPhoneに搭載されている方が先進的な部分もあります。調べてみると、両フレームワークを使って出来る事は似たようなものであることが理解できます（ターゲットカテゴリーが同じなので）。

しかし、両者には微妙に異なる雰囲気が漂っています。Androidには、携帯を拡張してインターネットサービスを使いやすくしようというコンセプトが見えます。iPhoneでは、パソコンをそのまま携帯に収めてしまおうと言う野望を感じます（笑）。フレームワークは単純に数多くのクラストとメソッドが存在していれば良いというものでもありません。ある目的を達成するには、それぞれのクラスが密接に協調して働く必要があります。協調できるということは、すべてのクラスがある目的を想定して統一されたデザインで設計されていると言うことです。プログラミングにおいては、デベロッパーの意図を清く正しく実装できるフレームワークが重要です。その能力の差が、それを用いて開発されたアプリの「質」の差となって現れるわけです。

ところで、フレームワークとは関係ないのですが、Androidでひとつだけ気になる点があります。それは、ユーザインターフェースに関する「ガイドライン」がどこにも提示されていないことです。これだと、アプリのユーザインターフェース実装をデベロッパー各人に任せることになります。携帯端末のアプリをマニュアルを読みながら使うことなど稀なので、ひとつのアプリの操作経験が別アプリに生かせないのはユーザにとって苦痛です。オープンソースの性格上UIの実装方法はデベロッパーの自由という方針も理解できますが、いくらかの規則と束縛は、もう一段階高いレベルのユーザ経験を提供するためには必要ではないでしょうか？

・アプリの実行環境

ソースコードやリソースの編集が終了したら、コンパイル＋リンクを実行しAndroid携帯端末のエミュレータを起動して動作確認を行います（これはiPhoneと同じ）。この作業でiPhoneと大きく異なる点は、色々と特性（画面の大きさ等）の異なるエミュレータを複数タイプ用意できることです。この機能により、自分のターゲットとする携帯端末を模したエミュレータを選択して動作確認が行えます。もしあらゆる端末が開発ターゲットであるとすれば、複数のエミュレータで順次確認することになります。

Androidでは単独でバックグランドに常駐するアプリ（サービスと呼ぶ）作ることができます。また、各アプリの画面表示（アクティビティと呼ぶ）は、切り替える毎にスタックに積まれてメモリに常駐します。iPhoneで言えば、UINavigationControllerがUIViewControllerを切り替える処理と似ています。違う点は、この処理は別アプリのアクティビティにも適用されることです。ですから一度ホームへ戻らなくても即座に前のアプリへ戻ることが可能です。メモリ使用状況がタイトになれば、一定のルールに従い優先順位の低いアクティビティから順次解放されます。同時に起動しているアプリが増えてくるとかなりヤバそうな仕様ですが（笑）、空きメモリが豊富にある状況なら快適なユーザ体験を提供できます。

iPhoneでは、Appleが供給している特定アプリ（MailとかSafari）以外のメモリ常駐は許されていません。OSの機能としてバックグランドタスクやマルチタスクは可能なのですが、敢えてそれをデベロッパーに解放していません（マルチスレッドはOK）。その機能の実装はユーザ体験を阻害するデメリットの方が大きいと判断し「それは今は使わない」という決断を下しています。デバイスのメモリ容量やバッテリーの問題が解決すれば、それなりの手法を用意してから、バックグランドやマルチタスクの解放が始まるでしょう。iPhone OS 4.0に期待しましょう！

セキュリティを強固にするために、AndroidもiPhoneと同じく、各アプリは隔離された「サンドボックス」に保存されます。そこから別アプリへのコンテンツへアクセスすることは禁止されています。問題なのは、アプリの保存可能スペースが現状では200MByte前後しかないことです（OSの制限？ Appleのフラッシュメモリ買占めの影響？）。これだと、コンテンツやリソースを大量に含んだアプリのインストールは苦しくなります。多分、大きな辞書とか大作ゲームは不可能でしょう。同じくファイルへ大量データを保存するアプリ（画像データベースなど）も制限されます。iPhoneは搭載されたフラッシュメモリの最大容量（例えば32G）までアプリを保存することが可能です。

・アプリの配布方法

物事にはすべてにメリットとデメリット（裏と表）が存在します。兎角人は片方にだけ目を向けがちですが、両方見極めての判断が必要です。iPhoneアプリを実機にインストールしたりApp Storeで配布したりするには「iPhone Developer Program」との年間契約（費用 \10,800）が必要です。Androidの開発ではこうした費用は発生しません。確かに費用がかかるのはデメリットですが、この費用、何かトラブルに遭遇した時に「Appleに文句を言う権利」を手に入れたと思えば納得できます。契約に10万もかかるようなら考え直しますが、配布手続きを含めたポータルサイトの整備、新着情報の配布、メンテナンス、個別Ｑ&Aなどが付いていると思えば、この年間費用は安いと思います。

Androidで完成したアプリ（商品）を置く店舗は「Android Market」です。アプリをAndroid Marketへ登録するには、App Storeとは異なり特別な承認審査は必要ありません（若干はあるという噂あり）。加えて、Androidアプリはそこに置かなくても自由に配布することができます。こうした点をメリットと見る向きは多く、実際に様々なビジネス展開が可能になると思われます。しかし「商品の品質を維持する」と言う意味では 承認が無いことがデメリットへと変わるケースもあります。実際に、ユーザのセキュリティに被害をおよぼすアプリが登録された事件がAndroid Marketで起こったようです。

それにしても、Android Marketの国内外での評判が芳しくありません。アプリを置いたり買ったりしている筆者からすれば、現状のApp Storeでも数多くの不満があります。商品レビュー、図版やデモ、カテゴリー分け、検索と閲覧などなど...改善して欲しい個所が山ほど有ります。しかし、それ以下だと言うAndroid Marketの評判を聞くに及んで、何故すぐに改善されないのか首をひねります。クラウドサービスが本業のGoogleらしくないですね。AndroidアプリはAndroid Marketに置かなくても配布できるというメリットを誇示したいのでしょうか？ しかし、ユーザとデベロッパー両方の視点として、流通アプリをまとめる魅力的なフラッグシップ店は欠かせないような気がします。

・多様性はもろ刃の剣

それではアプリをAndroid Marketで販売しようとした時の懸念事項は何でしょうか？ Android携帯端末が多数登場すれば、Android用アプリの供給が劇的に増え、将来的にはApp Storeの商品数を抜くだろうと言う予想もあります。しかし「理想論」としてはそうであっても、そんなに簡単に物事が運ばないのが現実です。パソコンの世界でも、もし当時のアナリストの予想通りに事が運んでいたら、はるか昔にLinuxはコンシューマーデスクトップ市場でWindowsを駆逐していたはずです。

パソコンの場合、MicrosoftはIntelと共に各メーカのプラットフォームを強力にコントロールしていました。Androidにおいては、Googleによるそうしたコントロールは希薄なように見えます。すると端末メーカもライバルとの競争があるので、他社よりアピールできる機能を積極的に自社製品へ搭載しようとします。その結果、機種間の互換性に亀裂が入り、アプリ開発者への重荷が表面化することになります。ちょうど、Linuxのデストリビューションが多様化し開発者やユーザが分散してしまったのと同じ状況です。

デベロッパーからすると、開発対象デバイスの種類は少ない方が助かります（理想は1機種）。そう言う意味では、 iPhoneは かなり理想的なのですが、それでも3Gと3GSの間には多くの相違点があります。

・CPUとGPUの処理速度
・メモリ容量（128Mと256Ｍ)
・外部記憶容量（8Gから32G）
・カメラの能力（画素数）
・ビデオ撮影の有無
・コンパスの有無

ターゲットにiPod touchを含めるともう少し要因が増えます（カメラの有無、スピーカーの有無、3G回線やGPSの有無など）。Android携帯では画面（スクリーン）サイズが違うという要因も追加されます。それとは別に、個別デバイスのOSバージョンの違い（iPhoneなら2.0.0〜3.1.2）も考慮すべきです。ちなみにカメラやGPSの有無であれば、フレームワークに用意されている判定用APIを使いソースコードで切り分けられるでしょう。

ところがメモリ容量の違いやCPUとGPUの速度差はやっかいです。ターゲットデバイスをiPhone 3GSに固定して開発した（3Gの実機での確認を省いた）デベロッパーは、App Storeのレビューに3Gユーザからの苦情が殺到したのではないでしょうか？ そのほとんどはメモリ不足で起こるクラッシュや、CPUやGPUの違いが引き起こす処理速度低下に対するクレームです。また、メモリがタイトになった時だけOSに潜むバグが目覚めて悪影響を被る場合もあります。機種数の少ないiPhoneであっても、実機対応を怠ることで後から深刻な問題に遭遇することになります。

Android携帯は画面サイズは様々ですし、メーカによっては特別な機能が追加されている可能性もあります。 実機テストをせずにエミュレータだけで動作確認したアプリを配布するには相当な勇気がいります（ギャンブル）。開発時にはなるべく多くの実機でテストすることが必須ですが、とは言っても全実機を入手することは不可能ですので、エミュレータに頼るしか手はありません。そうなると、アプリを全機種対象に配布しようとするデベロッパーには大きな不安とリスクが付きまとうことになります（まあ、開き直るという手もありますが...）。

・Androidで食っていけるか？

Androidは新たに登場したプラットホームとして技術的にもビジネス的にも大変興味深い側面を持っています。MicrosoftのWindows Mobaileが即座に反撃のノロシを上げないかぎりは（笑）当分の間は多くの携帯メーカの有力な選択肢になるでしょう。しかし、いちデベロッパーの立場として、Android Marketでアプリを販売して食っていけるかと尋ねられれば、正直その自信はまったくありません。ちなみに、iPhoneならいける気もしますし、実際に食っている人もいます。またiPhoneの場合には、MacやiPadアプリ開発へと習得技術の継承が可能な利点もあります。

先ほども延べましたが、今後登場するだろう数多くのAndroid携帯を物理的にすべてカバーする時間も資金もはありません。かと言って、エミュレータで動作確認しただけの作品を売る度胸もないのです。Android携帯端末の市場が大きくなり、特定の機種に絞ったカスタムメイドのアプリの需要が上がれば、それを受注して仕事にできる可能性は高いと思います。ただし、Android Marketが存在していることが仇となり「報酬は売上の一部を」といった仕事が多数を占めてくると（最近はiPhoneでも多い）、かなり辛いものがあります。その時には、多分その仕事は受けないでしょう。

さて、AndroidとiPhoneの開発環境を比較しながらデベロッパーとしての個人的な感想を色々と述べてきましたが、実際に使ってどう感じるかは、使う人の経験値により大きく異なります。当然、Java開発環境に慣れ親しんだ人にはAndroidアプリ開発の方が楽でしょうし、MacでCocoaアプリを開発していた人は圧倒的にiPhone SDKを好むでしょう。将来の「生業」の有力候補と見なすかどうかは別として、技術的に興味ある方は、ぜひ一度自分で試して確認してみてください。より多くのことを勉強しておけば、必ずどこかでそれに助けられるものです。