スマホアプリ開発環境雑感

October 17th, 2011

MagoPicのiPhone版を作るにあたって、下記いくつかの開発環境をリサーチしてみた。

結論から言うと、自分がやりたいことの主なジャンルからすると、そこまでクロスプラットフォームの開発環境に対するメリットは感じられなかった。またカメラやOpenGLなどを酷使しようとするとTitaniumやPhoneGapでは独自の拡張モジュールを書かないと対応出来なくて、そうなると結局ネイティブで書いた方がデバッグしやすかったりとやりにくさを感じた。しかし、TitaniumやPhoneGapは既存のWebサービスのフロントエンドを作るというような用途においてはかなりお手軽である事が分かった。

要はケースバイケースということなので、ケーススタディを交えて紹介する。

 

言語の壁は低い

C/C++がある程度分かればプラットフォームごとのラーニングコストはJavaとObjectiveCに関してはかなり低かった。またeclipseもXCodeも非常に洗練されており、普段screenとvimでの開発がメインの自分にとってはカルチャーショックだった。(結局ソースはvimで書いたけど)

JavaScriptに関してはノウハウがあった方がかなりよいがやっつけも可。

C/C++が分かるのであれば、新しい言語を学ぶことがいやだという理由でクロスプラットフォームの開発環境を選ぶというのはあまり得策では無いかもしれない。そういう動機で凝ったことをしようとしたりするとすぐに制限にぶつかる。

 

基本TitaniumでOK 【字画命名】

 名付けマシーン - exilis

このアプリはTitaniumで3分で作ったもの。Android版とiPhone版がコードを共有している。とはいっても、実際のロジックとUIはクライアントには実装されておらず、 数年前に子供の名前を考えるときに書いたPythonスクリプトをGoogle App Engineにのっけて適当にインターフェースをくっつけた。クライアントはWebViewを表示しているだけ。

ちなみに同等のことはPhoneGapでも出来るが、「PhoneGapはWebViewの拡張インターフェース」的な色合いが強くプログラムのエントリーポイントやプロジェクトの管理自体は開発者に委ねられている。一方でTitaniumはプロジェクトファイル自体も一つのxmlファイルから動的に生成され、単一のIDEでプロジェクトの作成からビルド、パッケージングまで行うことが出来る。現時点ではiPhoneとAndroid以外のプラットフォームを視野に入れないのであればPhoneGapを使うメリットは感じられなかった。

  • Titaniumによるクライアントのコード実装:3分
  • サーバーコードの実装:数時間
  • パッケージング&ストア登録:一日
    • アイコンの作成(&inkscapeの使い方勉強):数時間
    • スクリーンショットや各種マーケティングアセットの作成:数時間
    • Androidパッケージングハマり:数時間
    • iOSパッケージングはまり:数時間
この程度の規模であれば、プログラム自体はサーバークライアント合わせて半日ぐらいで全部出来るのだが、それを公開するまでの作業が非常に多い。
  • Titaniumで日本語のアプリ名をつけるとビルドエラーが発生
    • Android版:build.pyを書き換え、utf8デコードと、メインActivityのクラス命名ルーチンにパッチ
    • iOS版:ネットを探したらローカライゼーション用のplistを設置するだけでOK
  • アイコン、スプラッシュスクリーンがたくさん
    • アイコン4種、スプラッシュスクリーン15種、解像度やオリエンテーションに応じて必要
    • アイコンは1024×1024、スプラッシュスクリーンは1024×768,768×1024で作っておいてimagemagickのスクリプトを書いて一発
      • -geometryオプションで’!’をつけるとアスペクト比を無視してリサイズしてくれる
  • ストアに登録する時に必要な画像がたくさん
    • スクリーンショットが面倒くさい

OpenGLを使うならネイティブ 【カレイド卿】

 Available in Android MarketLord Mange - exilis

このアプリは、カメラからの入力をOpenGLのテクスチャに流し込んでエフェクトを加えて描画するというもの。おまけでキャプチャした画像をTwitterに投稿する機能も実装した。OpenGLが出てきた時点でTitaniumとPhoneGapは選択肢から消える。UnityやCoronaなど商用のエンジンは検討の価値あり。しかし、OpenGL自体がそもそもプラットフォームを越えたインターフェースを定義するものであるので、OpenGLを使ってかかれたプログラムをJava<->ObjectiveC(C/C++)間で移植する手間は殆どキーワード置換のみの単純作業だ。

このアプリはAndroid版とiPhone版それぞれネイティブで別々に作成した。

リアルタイムでのカメラストリームの処理は、転送データ量的にもCPU負荷にも重いものなので、ネイティブでの実装は必須だ。Androidの場合はJavaだと十分にパフォーマンスが出ないというのであればNDKの使用も検討すべきだ。このアプリの場合は、カメラからのYUVストリームをOpenGLのテクスチャバッファに流し込み、ちゃんとRGBに変換して表示するというのが重い処理だった。ネットを見た限りではJavaでのYUV->RGBコンバージョンとNDKによる実装しか見られなかったが、いずれもCPU負荷が高い&バッファのコピーが一度余分に発生するので、YUVのストリームをそのままテクスチャバッファに流し込んでYUV->RGBコンバージョンはGPU上で行うことにした。

Android版の開発においては、カメラプレビューが流れてくるスレッド、OpenGLのレンダリングスレッド、UIスレッドをちゃんと意識した設計にしないと非常に不安定になるという点で大分はまった。iOS版はAndroid版が出来てから移植を行ったが、問題なく数時間で完了した。

Androidのカメラは鬼門 【マゴピク】

これはAndroidネイティブで作成した。当初はカメラアプリということもあって、リッチなカメラUIを実装しようと思いTitaniumではなくネイティブを選んだが、ふたを開けてみるとAndroidのカメラ回りのコードは機種依存、バージョン依存が激しく、きちんと実装しようと思うとかなりのノウハウが必要である事が分かった。初期公開バージョンは独自のカメラプレビュー機能を実装していたが、すぐに取りやめ、カメラインテントを呼び出す方式に変更した。おかげでお気に入りのカメラアプリを使ってマゴピクの写真を撮ることなども出きるようになったので、Androidのアプリのデザインとしてはよい方向で落ち着いたとは思う。

しかし、こうなるとネイティブで実装する必要が殆ど無い。Titaniumで充分だ。強いて言えば、マゴピクのAndroid版はユーザー登録等の煩雑な作業を一切取っ払ってシームレスにサービスを使用出きるようにするというこだわりがあったので、それを実現するためのAndroid本体で管理されているGoogleAccountの取得、認証APIを叩けるというのが唯一の言い訳。しかしその程度であればカスタムモジュールを書けば済んだし、それ以外の通信やUIに関してはiPhone版と共通にすることが出来たのになぁ。はっきり言って失敗だった。Titaniumで作るべきだった。

まとまりが無いが、まとまらないので一旦ここで切る

Leave a Reply

*