Phonegap：アプリをレスポンシブにする方法

これまでに、PhoneGapに関するかなりの数のレビュー記事がありますが、残念なことに、それらはモバイルプラットフォームを採用することを決めたフロントエンド開発者、またはクロスプラットフォーム開発に挑戦することを決めたネイティブプログラマーによって書かれました。 PhoneGapの長所と短所が考慮されるのはこの観点からであり、「クロスプラットフォームがいかにクールであるか」または「クロスプラットフォームソリューションの劣等性」についての記事が登場します。



シードとして-6時間で記述されたビデオデモアプリケーション。 3.5時間の既製UIブートストラップ。 ライブラリiScroll、バックボーン、アンダースコア、Jquery、およびバックボーンの小さなラッパーを使用しました（RAD.js-迅速なアプリケーション開発、モバイルランタイムに関連する最適化の一部を担うアーキテクチャフレームワーク）。





エンジンの修理にさらに2時間かかりました。 しかし、今日は、14,000のデータオブジェクトを常に時間通りに処理できるとは限らず、速度が低下したり、動揺したり、自分で書いたスワイプが原因ではありません。 PhoneGapでできることと書くべきことについてです。



PhoneGapでのクロスプラットフォーム開発に携わる人々の意見を考慮して、PhoneGapで開発する際に必要かつ重要であると感じる微妙な点と、それらがなぜそれほど重要なのかを説明します。



PhoneGapは、7つのモバイルオペレーティングプラットフォーム向けのHTML / JavaScriptのクロスプラットフォーム開発プラットフォームとして位置付けられています 。



PhoneGapのクロスプラットフォームは、HTML / JavaScriptアプリケーションのコードがwebViewコンポーネント（アプリケーションに組み込まれたブラウザー）で実行されるという事実によって実現されます。



実際、PhoneGapアプリケーションの開発は、ランタイム環境（モバイルデバイス、限られたプロセッサパワー、メモリ、タッチスクリーンなど）とブラウザ動物園の詳細を考慮したHTML5アプリケーションの開発です。

デスクトップブラウザー用に開発するとき、モバイルサイトまたはPhoneGapアプリケーションを開発するときと同様に、webViewコンポーネントの構築に基づいて、各オペレーティングシステムとそのデフォルトブラウザーの詳細を知り、考慮する必要があります。



そして最も重要なことは、限られたmobile phoneGapアプリケーションのランタイムとリソースの影響を受けるのは、ユーザーインターフェイスの応答性です。



平均的なユーザーにとっては、たとえば、タスクの進行状況を示すダイアログを表示するなど、時間のかかる操作の間はプログラムがインターフェイスをブロックしても怖くない。 ユーザーが無意識のうちにボタンを押してもすぐに反応しない場合に不快感を感じると、さらに悪化します。 これは数秒でもありません。 人が潜在意識の不快感を感じるには、プログラムを押してから反応するまでに150ミリ秒以上の遅延で十分です。 この場合、潜在意識は、プログラムインターフェイスが期待どおりに応答していないことを通知します。



そのため、プログラムではユーザーインターフェイスの応答性に焦点を当てようとしています。 この記事では、JavaScriptコードまたはCSSの最適化については説明しません。これは、PhoneGapとモバイルアプリケーションに固有ではないためです。さらに、これについては既に多くのことが書かれています（ ここ 、 ここ 、 ここ 、 ここ 、またはここ ）。



それどころか、細心の注意を払わないことが多い細かな点に注目したいのですが、最終的にはユーザーにとって決定的な役割を果たし始めます。



モバイルWebアプリケーションのインターフェースと応答性との関係を包括的に調べる記事を見つけるのは簡単ではありません。 たとえば、 この記事 、またはこの記事 。 2番目の記事はごく最近のもので、PhoneGapで優れたアプリケーションを作成するための「動き」の方向を示していますが、著者は「キャンバスベースのUI」を使用している場合があります。

しかし、これらの記事でも、残念ながら、すべての問題が考慮されているわけではありません。



私たちは、私たちが特徴と考えている問題、そして今日考えたい問題を選び出します。

• 「タッチ」デバイスでの「クリック」イベントの300ミリ秒の遅延。
• タッチの問題
• DOM構造の最適化。
• 大きなリストの問題。

おそらく何かを繰り返すでしょうが、それでも始めます。



300ミリ秒の遅延問題：



ブラウザのほとんどのモバイルオペレーティングシステム（およびその結果、webViewでは）は、DOMで直接クリックして「クリック」イベントをトリガーしてから誤タッチの問題を解決するまでに約300ミリ秒の特別な遅延を導入します。



この問題を解決するアプローチは、インターネット上で見つけることは難しくありません。 この問題を解決するJavaScriptライブラリは少なくとも数十個あります。 すべての操作の原則は同じです-「touchstart」および「touchend」のイベントを追跡し、最後の呼び出しの終わりにイベント「click」または同様のカスタム（例えば、「tap」）を追跡します。 例は、 stackoverflowのソリューションとしても、 jQueryのプラグインとしても、 Mozillaからの実装でも、またはヒントとしても、別個のライブラリとしても見つけることができます。



残念ながら、わずかな「しかし」が常にあります-「クリック」イベントを生成する場合（たとえば、 Googleが決定に助言するように ）、しばらくしてから、ブラウザ自体が生成する標準の「クリック」の配信をキャッチして停止する必要があります。 Androidの古いバージョンでは、サードパーティライブラリとの非互換性につながる可能性があります。 この場合、カスタムイベントを生成すると、フォーカスが遅延して送信され、入力フィールドを選択するとこの遅延が表示されます。



要素をクリックするときにトリックを正しく転送および設定し、同時にさまざまなタイプの入力フィールドで正しく機能するライブラリを見つけることは非常に難しく、さらに、非常に膨大になります。 一般に受け入れられているアプローチ（「クリック」イベントではなく、他のカスタムイベントを生成する）を使用して、リスナーを直接結び付ける方がはるかに簡単で簡単です。



そして、この場合、アプリケーションはこのライブラリに依存するようになりますが、この欠点はソリューションの単純さとバグの最小数によってブロックされる以上です。

一部のライブラリが行うように、「fastclick」の個々のインスタンスをUIの各要素にバインドすることにも注意する必要があります。 このソリューションは実行可能ですが、モバイルデバイスのリソース消費に関して非常にコストがかかります。 たとえば、リスナーの「ボディ」で委任とバインドを使用し、ネイティブイベントの座標に基づいてポップアップカスタムイベントを生成する必要があります。



2番目の問題はタッチポイントです。



モバイルデバイス（PhoneGapを含む）の誤って設計されたインターフェイスの別の一般的な問題は、次のようにユーザーの唇から聞こえます：「クリックしますが、常に機能するとは限りません」または「クリックしても機能しません」。

次の図を慎重に検討してみましょう。この図は、ユーザーの指がデバイスの画面とどのように正確に相互作用するかを示しています。







指先の実際の接触点（緑）と視覚的な接触点（赤）が異なることは簡単にわかります。 まず、モバイルデバイスを斜めに見ます。 第二に、画面自体は、指先のタッチ領域上の重量平均座標としてタッチ座標を生成します。 どんなに一生懸命努力しても、指先からの理想的な円で成功することはありません。



これらの理由により、実際の接触点が視覚と一致することはありません。



これらの問題の解決策のほとんどは、オペレーティングシステム、つまりタッチスクリーンドライバー自体の責任です。

しかし、これらの微妙さがわからず、プログラムインターフェイスの開発時にそれらを考慮しない場合、インターフェイスのかなり細かい詳細では、これはアプリケーションユーザーにとって顕著な問題になります。 また、ユーザーはボタンを正確に押したと確信していますが、実際には単に押しただけです。



この点は非常に簡単に修正されます-アプリケーションコントロールの適切なレイアウト。 たとえば、ボタンがデザインで十分に大きくない場合、4-6ピクセルの不可視のパディングがある場合、つまり、背景には目に見えない外部境界があり、ユーザーにとって必要で便利な物理サイズに拡大します（写真のピンク色のボックス）。







この問題については、 ここで詳しく説明します 。Microsoftの推奨事項では、画面サイズに応じて、インターフェイス要素の推奨サイズを確認できます。



そして今、最も重要なこと-DOM構造の最適化について







「平均」アプリケーションの多かれ少なかれ「標準」画面を見ると、アプリケーション画面がありそうな200〜300のhtmlタグ（DOMノード）から数えることができます。 この特定の例では、ページはおそらく225のHTML要素を使用しています。 最適なレイアウトとはほど遠いですが、どんなに努力しても、PhoneGapアプリケーションの平均画面は100〜250のHTML要素に数えられます。 また、リスト付きの画面についてはまだ検討していないことを考慮してください（これについては、後ほど説明します）。



ネイティブのアプリケーションと同様の平均的なアプリケーションには、5〜1ダースの画面が含まれます。 PhoneGapの場合、これらのページはすべて単一ページのアプリケーションの一部です。



このようなアプリケーションのアーキテクチャには、一般に受け入れられているアプローチがあります。すべてのページはブロックとして1つのhtmlファイルに配置され、プログラムの実行中に、必要なページに応じて、スタイル

ディスプレイ：なし;

ディスプレイ：ブロック;

目的のページが表示されます（たとえば、JqueryMobileで行われます）。



しかし、残念ながら、このアプローチでは、ページを切り替える際に（だけでなく）アプリケーションが遅延します。 また、アプリケーションが複雑になるほど、これらの遅延は長くなります。



これは、DOMを照会する最も一般的なJavaScript関数（document.querySelector（ 'selector'）など）でさえ、実行時間はドキュメントのオブジェクトモデル内のノードの数に依存するという事実によるものです。 たとえば、3レベルセレクターを使用した指定された操作は、100要素では0.003ミリ秒、10,000要素では0.36ミリ秒（約40アプリケーションページ）で実行されます。 これらは些細なことであると主張することができます。実際の生活では40ページはあまり見られず、0.36 msは1ペニーです。



しかし、純粋なJavaScriptを使用する人はほとんどいないため、JQuery（バージョン2まで）を使用すると、指定された時間が2.46ミリ秒に増加します。 また、単純なリクエストに加えて、DOMで操作を実行する必要があることを考慮すると、これはかなり複雑なアプリケーションでの目の遅延によっても目立ってしまう可能性があります。



これは、要素の数が異なるドキュメントを生成し、コンソールで2レベルのCSSを選択した結果を表示する小さなSYNTHETICテストです。



Chrome 28.0.1500.63で実行した結果

index.jsの1つのアイテムの作成を開始：12

なし1アイテム：0.078ms index.js：38

なしjquery 1アイテム：0.774ms index.js：43

ブロック1アイテム：0.131ms index.js：38

ブロックjquery 1アイテム：0.234ms index.js：43

jquery show1アイテム：1.768ms index.js：52

index.jsの10個のアイテムの作成を開始：12

なし10アイテム：0.071ms index.js：38

なしjquery 10アイテム：0.138ms index.js：43

ブロック10アイテム：0.139ms index.js：38

ブロックjquery 10アイテム：0.090ms index.js：43

jquery show10アイテム：0.865ms index.js：52

index.jsの100個のアイテムの作成を開始：12

なし100アイテム：0.071ms index.js：38

なしjquery 100アイテム：0.099ms index.js：43

ブロック100アイテム：0.103ms index.js：38

ブロックjquery 100アイテム：0.105ms index.js：43

jquery show100 items：1.418ms index.js：52

index.jsの1000アイテムの作成を開始：12

なし1000アイテム：0.178ms index.js：38

なしjquery 1000アイテム：0.163ms index.js：43

ブロック1000アイテム：0.156ms index.js：38

ブロックjquery 1000アイテム：0.176ms index.js：43

jquery show1000アイテム：9.709ms index.js：52

index.jsで10000アイテムの作成を開始：12

なし10000アイテム：2.333ms index.js：38

なしjquery 10000アイテム：2.434ms index.js：43

ブロック10000アイテム：1.810ms index.js：38

ブロックjquery 10000アイテム：1.810ms index.js：43

jquery show10000アイテム：106.425ms

テストからわかるように、「display：none」を使用したソリューションは、ドキュメントのレンダリングのみの作業を削除し、「冗長」DOMを要求する時間を変更しないため、役に立ちません。

このソリューションは、リフローとリペイントのみを取り除くのに役立ちます。これらのイベント中のブラウザーの動作については、 記事で詳しく説明しています 。



繰り返しになりますが、 テストは総合的なものであり、実際の条件には対応せず、一部のポジションは特別に「圧倒」されました。 しかし、多数のページと複雑なレイアウトを持つ単一ページのアプリケーションを使用して、実際のプロジェクトで何が起こるかを完全に把握できます。



プラットフォームによって（ブラウザーが異なると）時間は異なりますが、モバイルブラウザーでは状況がさらに悪化することが容易にわかります。標準的なアプローチを使用した複雑な単一ページアプリケーションでは、モバイルデバイスでスムーズなアニメーションを取得することはできません。



この場合、2つの解決策があります。

• ページコンテンツをajaxリクエストでロードします。
• ページがすでに標準的なアプローチである可能性が高い場合は、DOMに読み込んだ後、メインDOMツリーから非表示ページの責任を持つDOMブランチを切断し、JavaScriptでこれらのブランチへのリンクを保持する必要があります（たとえば、 api.jquery.com/detachを使用）切断されたブランチはクリアされません。

これらの2つのオプションを組み合わせることで、最大限の最適化を実現できます。 次に、ページまたはテンプレートを初めて読み込むだけで、DOMブランチをメインドキュメントツリーにアタッチまたはデタッチするだけです。



最適化の既知の場所を忘れてはなりません。



そして再びDOMについて-大きなリストの問題



大きなリストの問題は、前のセクションで説明した問題の一部です。

リスト要素が多いほど、ページ内のHTML要素が多くなり、リストの更新とレンダリングが遅くなります。



ネイティブコンポーネントでは、これはキャッシュを介して実装されます（ Androidでのネイティブコンポーネントの実装例 ）。







この問題は、すでに非表示になっている要素のデータを置き換えるか、その位置を再配置するか、非表示のリスト要素を削除して新しい要素を生成することで解決できます。 つまり、実際には、画面上には1000個の要素のリストはありませんが、画面上に表示される10個の要素のリストと、おそらく現在作業中のいくつかの非表示要素があります。



Webアプリケーションでは、このようなリストの実装はほとんど見ることができません。 原則として、すべてが可能な限り簡単に行われます：1000要素のリスト。 デスクトップでこれがそれほど重要でない場合、モバイルプラットフォームでは、PhoneGapを開発プラットフォームとして放棄する際に大きなリストが決定的な役割を果たす可能性があります。



この問題の解決策として、「ページング」、つまりリストを部分的に表示することをお勧めします。 このアーキテクチャソリューションは、多くのjsライブラリによって実装されています。 彼を非常に美しく打つことができます-例えば、スワイプで。







または、ネイティブコンポーネントと同様の機能を実装するJavaScriptライブラリを作成または検索できます。 たとえば、 InfiniteWallまたはhereで行われます 。



最後に、時間と神経を節約するための役立つヒントをいくつか紹介します。

1. 使用するサードパーティのライブラリが少ないほど、モバイルデバイスのリソースが限られているためです。 比較のために、サードパーティのライブラリである「宇宙船」の中隊を挙げることができます。 この飛行隊は、アプリケーションのビジネスケースを完成させるために、1つの「負荷」を運ぶ必要があります。 しかし、燃料は飛行隊全体で消費されます。 したがって、リソース（「燃料」）を節約し、最適なライブラリを選択して、その機能を最大限に活用してください。 たとえば、バージョン2以降のjQueryは、パフォーマンスにおいてzeptoにそれほど劣りませんが、より多くの機能があります。
2. アプリケーションは、すべてのプラットフォームとOSバージョンで同じように見える必要はありません。 プログラムの速度と機能を維持するために、スタイルとデザインにいくつかの譲歩をする価値があるかもしれません。 IEの状況を覚えておいてください。
3. リストでは、imgタグに「src」属性を使用せず、CSS背景を使用して画像を表示します。 この場合、画像はリストアイテムが画面に表示されている場合にのみロードされます。
4. クライアント/サーバーアーキテクチャを備えたWebページの場合に機能する最適化方法は、PhoneGapのアプリケーションにとって必ずしも重要で最適ではありません。 たとえば、ロードされたJavaScriptファイルのサイズに注意を払ったり、画像内の不可視ピクセルを最小化することは意味がありません。この場合、これらのファイルをダウンロードするための長いネットワーク要求がないためです。 残念ながら、各ファイルをダウンロードする前に250ミリ秒の遅延をキャンセルした人はいなかったため、ユーザーはその対処方法を決定しました。 怠zyなプリロードとタイルを選択しました。
5. 入力フィールドを画面の上部に配置します-これにより、モバイルデバイスでキーボードを表示するときにページの異なるレイアウト動作が回避されます。
6. 大きなリストを避ける-これは難しい作業です。 少なくともそれを解決するための青写真を既に持っているときにそれをつかみます。
7. 影、グラデーション、半透明性を最大限に取り除きます。 このすべての美しさは、モバイルデバイスからの追加の電力を必要とするため、本当に必要な場合にのみ使用してください。
8. 次のように、CSSを介してGPUパワーを使用します。
   
   transform: translate3d(0,0,0);

-webkit-transform: translate3d(0,0,0);


   
   
   
   
   
   特に、 特定の実装について読むことができます。
   
   または、 テストの詳細 。
   
   

また、ヒント付きの記事へのリンクがいくつかあります： here 、 hereまたはhere 。



しかし、最も重要なことは、私たちが言いたい ことです。PhoneGapで書くことができます。



それは開発のための万能薬ではありませんが。 各ツールは、独自のタスク用に設計されています。 PhoneGapを使用すると、レスポンシブアプリケーションや非標準設計のアプリケーションを作成できます（これはネイティブコードを使用するよりも簡単です）。 ただし、大量のデータを処理する必要がある場合は、PhoneGapが適切でない場合がありますが、対処できる場合もあります。



ヒントが役立つことを願っています。



PS 11時間のUI最適化後、同じボタンサイズでバグが残りましたが、アプリケーションは本当に「良くなりました」。