HTML5、ネイティブおよびハイブリッドモバイルアプリアプローチの長所と短所は何ですか？
モバイルアプリを開発したい。私は最近 Telerik Forum の記事を読みました。これは3種類のモバイルアプリケーションを比較していて、どれを選択すればよいのかわかりません。これは、さまざまなモバイルデザインの選択肢の長所と短所を説明する画像です
これらの設計上の選択を決定するために、図に示されている各アーキテクチャの選択の長所と短所をよりよく理解したいと思います。各アーキテクチャアプローチの長所と短所は何ですか？
私はこの問題を検討するのにかなりの時間を費やしたモバイル開発者です。
なぜ聞くのですか？
ほとんどの場合、次の方法でアプリ開発コストを削減したいと考えています。
- 既存のHTML5/Javascript開発スキルを使用する
- 最初から複数のアプリを作成せずに複数のプラットフォームをターゲットにする
- 将来複数のコードベースを維持する必要がない
理由には以下も含まれます。
- HTML5/Javascript開発は、ネイティブプラットフォーム開発よりも「簡単」であると認識されています
- 開発者プログラム登録料の支払いを回避する
- アプリストアのコンテンツ制限を回避する（ギャンブルなど）
- 開発ハードウェアの購入を回避する（iPhone開発用のMacなど）
定義
前述の3つのアプローチのそれぞれが私たちが何を意味するかを正確に確立しましょう。
ネイティブ
通常はアプリストアからデバイスにインストールされるアプリ（ただし、サイドロードされる場合があります）。この説明では、ネイティブアプリのUIは通常、フルスクリーンのWebビューのみで構成されているわけではありません。
モバイルWeb
これは実際にはどのWebページでもかまいませんが、ここでは、ネイティブアプリのルックアンドフィールを模倣しようとする単一ページのWebアプリについて考えてみましょう。これはネイティブアプリではなく、デバイスのブラウザで実行されます。
ハイブリッド
ハイブリッドアプリinstanceofネイティブアプリ。
ほとんどの人は、おそらくハイブリッドアプリを単一ページのモバイルWebアプリ（多分、ネイティブアプリのルックアンドフィールを模倣している）であると理解していますが、ネイティブサービスにアクセスできるネイティブアプリとしてパッケージ化されています（電話ギャップ）。
ただし、実際には、Phonegapモデルと完全にネイティブなものの間にスペクトルがあります。これについては、後で説明します。
モバイルウェブ
技術的な制限
まず、あなたが何をしているのかに応じて、それ自体が取引ブレーカーになる可能性のあるモバイルWebアプリに関するいくつかの技術的な制限を挙げましょう。
- HTML /キャンバスUIのみ
- 特定のデバイスイベントおよびサービスへのアクセスなし（これらは広く文書化されています）
- アプリストアに掲載できない（発見可能性に影響する）
- IOSでは全画面表示になり、ホームスクリーンアイコンが表示されますが、これはほとんどのユーザーにとって珍しい、なじみのないエクスペリエンスです
上記のすべてに対応できる場合は、シングルページのネイティブスタイルWebアプリの課題について詳しく読んでください。ただし、このセクションはFTアプリを参照せずに完了することはありません。
Financial Times
FT web app は、このスタイルのアプリの有名な例です。 これについては、英国のガーディアン紙からの興味深い特徴があります。
それは確かにエンジニアリングの驚くべき偉業です。現在もiOSでのみ利用可能であることに注意してください-これは、高度なクロスブラウザー開発の課題を解決することで、確かに非常に難しい。
単一ページのネイティブスタイルWebアプリ
このセクションは、モバイルWebアプリとPhonegapスタイルアプリの両方に適用されます。
Webアプリ内のネイティブスタイルのルックアンドフィールは通常、使用するUIコンポーネントのスイートを提供する Sencha Touch などのフレームワークで実現されます。
このようなフレームワークは、非常にシンプルなUIには適しています。ただし、柔軟性に欠けます。 Senchaを使用してネイティブアプリデザインを実装することはできません。フレームワークが対応できるものにデザインを適合させる必要があります。
これらのフレームワークが苦しむ主な方法は、プラットフォーム自体のUIの複雑さをエミュレートすることです。 iPhoneでリストの最後までスクロールしたときに得られる素晴らしい小さなバウンス効果はありますか？フレームワークはJavaScriptでそれをエミュレートする必要があります。完全に再現することは不可能であり、遅くなる傾向があり、ユーザーは、ネイティブのように見えますが、明らかに技術的ではないアプリの「不気味な谷」に行き詰まります。ユーザーはその理由を正確に把握することができません。
「HTML5/Javascriptは簡単です」という神話
Webブラウザー内でのデバイスの断片化が蔓延しており、最も基本的なHTMLおよびCSSを超えると、期待どおりに機能しないことに気づくでしょう。 UIの問題を面倒に解決するのに、ネイティブで2度行うよりも多くの時間を費やすことに気づくかもしれません。ネイティブに移行する場合、ネイティブアプリのWebビューはデバイスブラウザと同じでないことに注意してください。また、独自の断片化の問題があります。
また、アプリの機能が複雑になるにつれて、JavaScriptをクリーンで保守可能な状態に保つためには、基本的なjqueryスキル以上のものが必要になることがわかります。
とはいえ、このアプローチを使用すると、シンプルで機能的なアプリをかなり迅速に作成することが完全に可能です。しかし、アプリがそれを行っているときはかなり明白です。
さらにスペクトルに沿って
したがって、ゼロからすべてを何度も記述せずに、Phonegapスタイルのアプリが提供できるより優れたUXが必要です。私たちは何ができる？
非UIコードを共有
複数のネイティブプラットフォーム間でビジネスロジックを共有するために利用できるさまざまな手法があります。 Googleは J2ObjC をリリースしましたJavaはObjective-Cに変換されます。コードを慎重に分解すると、JavaライブラリをAndroidおよびiOS。
Calatrava および Kirin などのライブラリを使用すると、Javascriptで記述されたコードベース（したがって、Javascriptにコンパイルできるもの）をネイティブコードから操作できます。免責事項：私はキリンを作成したFuture Platformsで働いています。 iOSでは、Java GWTで生成され、JavaコードもAndroidでネイティブに実行されます。
必要に応じてWebビューを使用...
フルスクリーンのWebビューは、画面の遷移とバウンス効果を模倣できるようにするためにやらなければならないことがたくさんあります。ただし、ネイティブアプリ内のWebView chrome=はネイティブと区別できない場合があります。
ネイティブアプリとWebビューが通信するための標準的かつ十分に文書化されたメソッドがあります。
リストとテーブルは、この方法で実行すると特にうまく機能しますが、テキストエントリは、ネイティブで（キーボードを完全に制御するために）処理する最適な例です。
要約すれば
どのアプローチが適切かは、アプリがどれほど複雑か、満足できるUIのレベルがどの程度かによって異なります。
私のモットー：できる限りWebviewsを使用しますが、ユーザーが教えないようにしてください。
最初にチェック この調査 何が起こっているかを知るために！
3つのタイプの比較： モバイルアプリケーション開発オプションについて
ネイティブとハイプリッドの比較：
これは本当に良いです： HTML5 vネイティブアプリ：モバイル戦略の重要な考慮事項
コメント：
- あなたはそれらのうちの1つに行くことができますあなたが持っているもの（スキル）とあなたが得ることができるもの（ルックアンドフィール、パフォーマンス、機能性、...）に依存します
- すべてのモバイルアプリ開発者は、彼が最初のバージョンと将来のバージョンのために開発しようとしているアプリケーションについて、明確なビジョン/要件を持っている必要があります。彼が使用するオプションがいつか彼を制限しないことを確認するためだけです。
- 3つの方法を実際に体験し、同時に最新であることに他なりません。これは、正しい判断を下すための感覚と能力を与えます。
電話のハードウェアにアクセスする必要がある場合は、ネイティブアプリを作成する必要があります（HTML5では、GPSなどのデバイスのハードウェアコンポーネントの一部にアクセスできます）。
Web開発に慣れている場合は、ネイティブアプリを作成する必要がない限り、それを使用する必要があります。
あなたが知っておくべきことに関しては、すべての異なる画面サイズ（垂直方向と水平方向を含む）を覚えておくべきだと私は言うでしょう。 OSのさまざまなバージョンを覚えておく必要があります（これはAndroid向けです）。これらはモバイルデバイスであるため、ユーザーは電話に応答して電話をかける可能性があり、デスクトップやサーバーの処理能力もありません。
私自身はモバイル開発者であるため、最悪の事態はオフラインアクセスです。ユーザーをオンラインに強制するだけで、多くのアプリで機能しますが、すべてでは機能しません。
他の大きな悪い面は遅さです。リモートデータの解析に必要な時間は、かなりの時間がかかる場合があります。はい、読み込み時にデータをプリフェッチできますが、それ以外の場合はすべて、速度低下を避けることはできません。
そのようなアプリは、ネイティブアプリよりも高価なアプリであることがわかりました。私のクライアントにはもうお勧めしません。
消費者向けアプリを書くとき、私が成功するために最も重要なことは、アプリのユーザーの受け入れと認識です。そのため、学習、トレーニング、WORA（どこでも一度実行すると書き込み）を失うことに関連する追加の費用にもかかわらず、ネイティブアプリを支持する4つの理由は次のとおりです。
- より速いアプリの起動
- スムーズなスクロール
- 他のOSおよびアプリとより一貫して連携する、より一貫性のあるアプリUI
- より高速なアプリUI応答
何よりも重要なのは、アプリがスロートマーケット市場で成功するのに役立つ優れたユーザーエクスペリエンスです。もちろん例外があり、特にスキルセットの不足、時間と予算の不足があります。アプリは、これらのことについてそれほど気にしないビジネスユーザーの限定されたセットを対象とする場合があります。
FacebookがIOSおよびAndroid向けのネイティブアプリを支持してアプリ戦略を廃止したのは、これらと同様の理由です。
読んでください：
マークザッカーバーグ：私たちの最大の間違いはHTML5に賭けすぎた http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too- much-on-html5 /
FacebookがモバイルWebを捨て、新しいiOSアプリでネイティブに行った理由 http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with- its-new-ios-app＃awesm =〜o9jDrRefxdgnpS
お役に立てれば。
以下では、この大失敗についての私の現在のスタンスは、ハイブリッドはまず始めに、アプリを探索し、顧客のフィードバックをすばやく繰り返し、機能セットを安定させるのに適しているということです。次に、仕様に従ってアプリをネイティブに書き換えて、エクスペリエンスを向上させます。
モバイルWebはまったく別の目的で機能するため、除外しました。アプリストアに参加したい場合は、ネイティブ/ハイブリッドが適しています。導入を簡素化し、経験と技術的能力を犠牲にしても構わない場合は、モバイルWebを選択してください。
長所/短所ネイティブ：
- プロ：他のデバイスエクスペリエンスに適合し、 不気味な谷 の問題はありません。
- 長所：スムーズで一貫したUIエクスペリエンスを提供し、遅延や途切れもほとんどありません。
- メリット：技術的な制限がほとんどないため、デバイスを十分に活用できます。
- 長所：ネイティブツールは、アプリストアの検証に準拠しています。
- プロ：ネイティブフレームワークには、プラットフォームバージョンごとの微調整が含まれており、微調整に費やす時間が短縮されます。
- 欠点：ビルドは長持ちするため、ビルドに時間がかかります。
- 欠点：見つけにくい、高価なポリグロット開発者が必要です。
- 欠点：各デバイスプラットフォームAPI（iOS/Androidなど）を理解する必要があります。
- 欠点：急な学習曲線。
- 欠点：プラットフォームごとに異なるツールセット。
長所/短所ハイブリッド：
- メリット：複数のデバイスプラットフォームをターゲットとする単一のコードベース。
- プロ：開発サイクルが速く、レイアウトの柔軟性が高く、 プロトタイピングとMVP に最適です。
- 長所：快適な学習曲線、多数のドキュメント、役立つフレームワーク。
- プロ：単一の開発ツールセット。 Chromeデバッガツールは優れています。
- Pro：複数のデバイスプラットフォームをターゲットとする1つのコードベース。
- 長所：学習しやすい開発者がたくさんいます。
- 短所：デバイスエクスペリエンスと一貫するために、あらゆるプラットフォームにUIを適合させるために、適切なUIフレームワークが必要 剣道UI 、 Sencha Touch のようなソリューションがあります。
- 短所：メモリとコンピューティングの使用状況を非常に意識する必要があります。CSSやJavaScriptループによっては、アプリのパフォーマンスが大幅に低下する可能性があります。デバイス上でデバッグするために利用できるあまり良いツールではありません。
- 短所：まだ成熟していません。物事は突然変わる可能性がありますが、ツールは改善されています。
ハイブリッドアプリの大きな問題は、フレームワークの断片化です。関心のあるネイティブモバイルプラットフォーム（通常は単に）よりも、フレームワーク（Ionic、Xamarin、React Nativeなど）の方がはるかに多い） 2つ、AndroidおよびiOS）。これらのフレームワークは競合し、出現し、衰退するため、現在のチームを存続させることを計画している場合でも、ハイブリッドに移行してもプラットフォームからプラットフォームへジャンプすることはできません。
GoogleとAppleは、エディター、デバッガー、テストフレームワーク、リファクタリングツール、およびそれらのプラットフォーム用に開発する他の手段を提供およびサポートするために最善を尽くしています。したがって、私は典型的な表現を使用します "ハイブリッドアプリを開発し、お気に入りのエディターで編集し、ブラウザーで開く "の方が合理的な予約ではるかに簡単です。XamarinとReactネイティブはSwiftまたはJava/Androidと同じですが、 "hello world"は短く見えるかもしれませんが、最終的には適切に学習するために同等の時間がかかるはずです。
いずれにせよ、ネイティブコンポーネントの必要性が発生した場合（たとえば、既存のサードパーティライブラリを統合する必要がある場合）、2つではなく3つのフレームワークになります：iOS、Androidおよびこのようなアプリのデバッグ、クロスレイヤー呼び出し間のステップ実行、すべてのレイヤーのログ記録、コードの同期の維持は、複雑であることが不可能な場合もあります。
「アプリはすべてのプラットフォームでまったく同じに見える」と言う人もいます。本当にいいことですか？ Androidアプリは次のようにする必要がありますAndroidアプリとiOSアプリはiOSアプリのようにする必要があります.
新機能についてはどうですか？ウェアラブル？ Androidプラットフォームによって提供されるインスタントアプリ？外部ディスプレイに追加データを表示する？ハイブリッドアプリは多くのネイティブ機能をサポートするようになりましたが、実際にはallをサポートしていますか？時間、すぐに？
最後に、パフォーマンスとユーザーエクスペリエンスだけでなく、セキュリティもネイティブアプリ側にある可能性があります。ハイブリッドフレームワークは、独自のバグやセキュリティのバグなど、間接的なレイヤーを追加します。
上記のすべてをまとめると、選択の可能性の下で、私は間違いなく2つのネイティブアプリ、iOS用とAndroidのいずれかを使用するか、または単にあらゆるプラットフォーム向けのアプリ開発に悩まされている。