Douban Musicianアプリは、2011年にPhoneGapフレームワークを使用して開発されました。PhoneGapは、ネイティブとウェブアプリのミックスアーキテクチャに基づいており、現在でもPhoneGapを使用する唯一のDoubanアプリです。これは、PhoneGapを使用する唯一のDoubanアプリであり、音楽人アプリの新しいiOSバージョンがリリースされたばかりで、アプリのネイティブ側にいくつかの機能強化を加え、同じアーキテクチャを維持しています。
PhoneGapを使用することを決定した当時の経緯
技術選定の際にこの選択をした理由はいくつかあります：
開発効率の考慮
Doubanのミュージシャンユーザーからの強い要望があったにもかかわらず、ミュージシャンアプリの位置づけや方向性は、常に模索し、素早く反復するフェーズにありました。つまり、音楽プロダクトラインは、できるだけシンプルな方法で、できるだけ少ない人的リソースで開発し、できるだけ早く複数のプラットフォームでリリースし、反復のニーズに素早く対応できるようにしたいと考えていました。これらのニーズを満たすことを優先しました。
ネイティブアプリとウェブアプリのどちらが優れているかについては多くの論争があるようですが、純粋に技術的な問題ではないと思います。開発効率という点ではウェブアプリが、パフォーマンスや開発の自由度という点ではネイティブアプリが優れていることは自明であり、アプリにハイブリッドアーキテクチャを採用するかどうかは、やはり製品のポジショニングと開発戦略が最も重要な要素だと私は考えています。私の考えでは、最も重要な要素は製品の位置づけと開発戦略です。 もしあなたがアプリをできるだけ早くリリースし、クロスプラットフォームで、予見可能なイテレーションに迅速に対応したいのであれば、ハイブリッドアーキテクチャは検討する価値があります。すべてのプラットフォームをカバーするのに十分な開発者がいて、製品設計が高度に成熟しており、製品サイクルで受け入れられる開発期間が比較的長いのであれば、ネイティブの方が明らかに良い選択です。
クロスプラットフォームへの配慮
Douban Musicianは、コンテンツを表示し、ストリーミング音楽を聴くことに特化したアプリとなり、ネイティブコードでしか実装できない機能はあまり必要なくなります。つまり、ハイブリッド・アーキテクチャでは、実装すべきネイティブ機能や解決すべきクロスプラットフォームの問題が少なくなり、ハイブリッド・アーキテクチャの利点が拡大します。
最初の要素を考慮した結果、ハイブリッドアーキテクチャを使う価値があったとしても、アプリ自体の特性がウェブアプリのアプローチに適していないのであれば、その必要はありません。 ウェブアプリ開発が効率的な理由は、html+css+jsで実現できることがネイティブコードで実現できることよりもずっとシンプルであることと、一方でクロスプラットフォームなアプローチが使えるという利便性にあります。アプリで実現すべき機能がhtmlでできず、ネイティブコードを使わなければならないのであれば、両方の利点がなくなってしまいます。
実際、最初のバージョンがリリースされる少し前に、デザイン面での見直しが行われ、アプリの全体的な外観やスタイル、特定の機能やインタラクションが大幅に変更されました。しかし実際には、デザインの変更が完全に実装されるまでわずか数日しかかかりませんでした。このスピードは、ウェブのフロントエンド開発では確かに難しいことではありませんが、ネイティブアプリでは想像を絶するものです。
アプリのアーキテクチャと開発ワークフロー
PhoneGapは単なるネイティブシェルであり、アプリのカーネルは完全なWebアプリで、呼び出す必要のあるネイティブ関数はネイティブプラグインの形で実装され、jsインターフェースを公開することで呼び出されます。ウェブアプリのフレームワークの選択では、当時ウェブアプリ専用のjsフレームワークをいくつか調査しましたが、そのほとんどがあまり成熟しておらず、適切なものがありませんでした。ミュージシャンのアプリのサイズはそれほど大きくなく、モバイルデバイスのウェブビューではパフォーマンスが非常に重要なので、実装の効率を最適化するために、いくつかの小さなツールを組み合わせて、できるだけミニサイズのフレームワークにして使うことにしました。フレームワークは大まかに以下のような小さなパーツで構成されています：
- jQuery
- iScroll4
- jsテンプレートのメカニズム；
- urlの配布とアクセス履歴の管理；
- ページの関係とページ切り替えのメカニズム；
- Jsonp ベースの API インタフェースラッパーです。
これは、ミニマルなjsフレームワークのクリーンな実装です。通信にjsonpを使う理由は、デバッグにchromeを使えるようにしたいからです。そうすれば、開発は簡単で、ローカルのhtmlファイルをダブルクリックするだけで、chromeが完璧なモバイルデバイスエミュレータになり、好きなフロントエンド開発のデバッグワークフローを使うことができ、どんなモバイルデバイスエミュレータよりもずっと便利です。
私はgitサブモジュールとしてwebappの部分を使用しており、iosとandroidの両方のリポジトリに含まれています。
PhoneGap開発で発生する問題
遭遇した印象的な問題の概要を説明します。実際、PhoneGapの現在のバージョンは大幅に改善されており、主流の携帯電話の性能は以前よりもはるかに向上しているため、現在ではPhoneGapを新たに開発することははるかに容易になっているはずです。
css3パフォーマンスの問題
半透明や投影のようなエフェクトがあるデザインから始めたのですが、css3で実装するとパフォーマンスが低下することがわかりました。その後、可能な限り不透明な要素を使用し、投影などのエフェクトを削除し、domの複雑さを減らすなど、このためにデザインを修正したところ、パフォーマンスが大幅に改善されました。
画素密度の問題
ピクセル密度が異なる画面では、異なるイメージを用意し、cssのメディアセレクタを使って、-webkit-device-pixel-ratioに従って0.75、1、1.5、2の密度を持つ異なるcssを挿入し、異なる背景イメージを使用する必要があります。修正する必要があるのは1つのcssファイルだけで、MakeFileスクリプトが他のいくつかのcssファイルを自動的に生成します。もちろん、4つのイメージセットが存在し、正しい名前が付けられていることも確認する必要があります。
Mp3再生に関する問題
iOSのウェブビューがmp3再生をサポートすることに問題はありませんが、ユーザーが率先して再生しない場合、ウェブビューが自動的に再生を開始できないという制限があります。さらに厄介なのは、一部の古いバージョンのアンドロイドはオーディオタグをサポートしていますが、mp3形式のオーディオはサポートしていません。この場合、PhoneGap付属のオーディオ再生機能しか使えません。ユーザーにとっては、効果は同じですが、Webアプリの依存性が高まり、Webアプリの部分が複雑になります。
システムによる行動の違い
iOSとandroidはwebviewを使用していますが、その動作はほとんど同じで、webkitを使用しているため、スタイルは非常に近く、ほぼ自動的に完璧なクロスプラットフォームになります。しかし、実際の開発では、例えば、まだいくつかの違いがあることがわかりました：
- もちろん、これはPhoneGapのカプセル化と関係があります；
- アンドロイドは時々ソフトキーボードの問題がありますが、そのためのプラグインがあります；
- 外部URLを開く際の一貫性のない挙動を処理します；
- サポートされているアニメーション手法には違いがあり、プラットフォームが異なれば、可能な限り効率的でアクセラレーションが難しいアニメーション手法を使用する必要があります。
- アンドロイドの物理キーのいくつかについて、特別なハンドラー関数を書く必要があります。
ネイティブコードが必要
ウェブアプリの中ではできない要件があり、これはよく遭遇することです。例えば
- プッシュメッセージ
- ステータスバーリマインダー
- 内蔵ブラウザを開いて、いくつかのURLにアクセスしてください；
- ソーシャルプラットフォームのアカウントをバインドします；
- ダウンロードしたイメージや音楽などのファイルをキャッシュします。
この問題を解決するためのプラグインは数多く見つけることができ、現在市場に出回っているプラグインは、私たちがMusicianアプリの初期バージョンを開発したときよりもはるかに豊富になっていますが、それでも需要を満たすことができない可能性があり、タスクを完了させるために独自のプラグインを書く必要があります。つまり、出てくる需要ごとに、各システム用のネイティブソリューションを作る必要があります。私たちは、Musicianアプリで使用している「ソーシャルプラットフォームに推薦する」プラグインをオープンソース化し、同様のニーズを持つ他の開発者が利用できるように準備を進めています。
より多くのプラットフォームに移植可能。
私は単にWebOSを試してみましたが、スタイルは非常に一貫性があるでしょうが、いくつかの他の問題があり、安定性のために、WebOSのパッケージをリリースしませんでした。また、IE10のモバイル版はすでに非常に標準に優しいブラウザですが、スタイルはまだwebkitとは異なり、あなたは直接webkitのWebアプリを使用することはできません、あなたは適応を行う必要があります。デスクトップWeb開発の世界に戻りましょう。
面白いことに、MacGapを使ってアプリのコア部分をMac用のデスクトップアプリケーションにパッケージ化するのは、まったく手間がかからず、ほとんどすぐに使えます。
要約すると
使用感としては、iOSでの結果はAndroidよりも若干良く、ネイティブ・インターフェースとほとんど見分けがつきません。レンダリング速度など細部ではネイティブアプリに比べ若干の不利は残りますが、全体的には全く問題ないレベルだと思われます。
要約すると、PhoneGapに基づいて得られた結果は満足のいくものであり、開発は費用対効果に優れています。ミュージシャンアプリのユーザーレビューも比較的良好です。製品が安定した後、将来的にPhoneGapの代わりに純粋なネイティブアプリを使用するかどうかはまだわかっておらず、製品の将来の決定次第です。すべてをトレードオフにする必要があり、フレームワークに特効薬はありません。
