ハイブリッドアプリ開発プロセスの共有_PHPチュートリアル-PHPチュートリアル-php.cn

ハイブリッドアプリ開発プロセスの共有

このトピックに関して、この記事では、ビューポート、レム、フレックスボックス、メディアクエリなど、モバイル開発に関連するいくつかの一般的なテクノロジについては詳しく説明しません。ここでは主に、当社のハイブリッド製品戦略、開発プロセスと仕様、パフォーマンスの最適化、および当社が克服した落とし穴について説明します。これらはインターネット上で関連情報が比較的少なく、同様の体験記事が不足していることが多いため、この記事を通じてハイブリッド製品開発における Meizu チームの経験の一部を共有できればと思っています。

製品の背景

このタイプの製品には比較的強力な運用機能が備わっていることを願っています。
インターフェイスデータは cp データの統合から得られるため、特定の違いがある可能性があり、ある程度のフォールトトレランスが必要になる場合もあります。迅速に更新して反復します。

Android と H5 の統合ソリューション

上記の背景の下、最終的にハイブリッドアプリソリューションを選択しました。それでは、次の疑問は、クライアントが Web ページのフロントエンドリソースにどのようにアクセスすべきかということです。ブラウザを使用してサーバー Web ページにアクセスする以前の方法をそのまま使用できますか?答えは絶対ではありません。もちろん、上記の方法も使用できます。さまざまなビジネスニーズに応じて、方法は常に異なります。私たちは次の 2 つのソリューションを最もよく使用します:

静的リソースのローカリゼーション

このソリューションは、まず静的リソースをアプリに埋め込み、次にユーザーがアプリを起動するか HTML ページにアクセスして特定の条件を満たしたときに、リクエストが行われます。リソースのステータスを問い合わせるためにバックグラウンドに送信されます。更新が見つかると、最新のリソースがローカルにダウンロードされ、すべてのユーザーがローカルの静的リソースにアクセスします。更新に失敗すると、埋め込まれた静的リソースまたはダウンロードされた静的リソースにアクセスします。

HTML 5 アプリケーションキャッシュ

このソリューションは実際に HTML5 アプリケーションキャッシュ (HTML5 キャッシュマニフェスト) を使用します。詳細についてはここでは説明しませんが、これに関する情報はオンラインにたくさんあります。注目に値するのは、マニフェスト構成ファイルが正しい MIME タイプ、つまり「text/cache-manifest」で構成されている必要があることです。

通常、2 番目のオプションは、いくつかのアクティビティや特別なページを開発するときに使用されます (オンライン時間が短く、UI が大幅に変更されます)。

ほとんどのアプリページは比較的安定しているか、反復的に開発され、定期的に定期的に更新されます。この場合、最初の解決策を採用します。このソリューションを採用する場合、リソースファイルのサイズを厳密に制御する必要があります。また、必要な圧縮に加えて、長期固定リソースを事前に抽出してアプリに組み込むこともできます。これにより、ユーザーはリソースを更新するたびに、サーバーにアクセスして変更された部分を取得するだけで済み、トラフィックの使用量が大幅に削減されます。

上記の 2 つのソリューションには、サーバー上の静的リソースに毎回アクセスするよりも明らかな利点があります:

オフラインアクセス

リソースの読み込みが速い
サーバーの負荷が低い

ページの読み込み

まず第一に、顧客クライアントページをロードします。ロードが完了すると (pagefinish)、クライアントはフロントエンドによって提供される初期化メソッド (initParams) を呼び出します。このメソッドを通じて、パラメータが渡され、ページが初期化されます。

リソースの構築

現在、リソースの圧縮、マージ、md5 スタンプの追加、およびその他の構築機能に fis3 を使用しています。es6 を使用するプロジェクトの場合は、Babel も使用する必要があります。これに基づいて、内部使用のためにいくつかの fis3 ベースのプラグインも開発しました。最終的な目標は、コマンドラインを実装してすべての構築作業を完了することです。

開発環境構築

nodejs+expressを使ってローカルWebサービスを構築します。

開発プロセス

上の図からわかるように、ビジュアルデザイン、フロントエンド開発、クライアント開発、バックエンド開発はすべて、大部分の並行開発を実装しています。

次に、フロントエンド開発がどのようにバックエンドとともに実装され、クライアントから分離され、並列実装されるかを簡単に説明しましょう。

まず第一に、インターフェイスドキュメント（バックエンドインターフェイスドキュメントとクライアントインターフェイスドキュメント）はノンブロッキングの前提条件です。バックグラウンドインターフェイスドキュメントを使用すると、対応する偽のデータを構築し、対応するインターフェイスリクエストをシミュレートできます。 Android インターフェイスドキュメントを使用すると、クライアントインターフェイスの呼び出しをシミュレートすることもでき、少なくとも基本的なロジックがスムーズであることを確認できます。したがって、インターフェイスドキュメントが存在する限り、実際の共同デバッグの前に、フロントエンド、バックエンド、クライアントは独立して開発され、相互にブロックされません。

その後、共同デバッグは 3 つの段階に分かれています:

偽データの共同デバッグのシミュレーション

この段階では、偽のデータをローカルに書き込み、ajax を使用してそれをリクエストするだけです。 Android インターフェイスへの呼び出しもシミュレートできます。この段階の主な目的は、フロントエンドロジックが基本的にスムーズに動作していることを確認することです。

バックグラウンドの実インターフェース呼び出し

この段階で必要なのは、ローカルの静的リソースにアクセスすることですが、呼び出すのはリモートサーバーのインターフェースです。この場合、主なことは、ajax クロスドメイン要求の問題を解決することです。これを実装するには多くの方法があります。最も簡単なのは、クロスドメインをサポートするようにブラウザを設定することです。もちろん、nginx または Apache のリバースプロキシを使用して、Ajax クロスドメインリクエストを実装することもできます。

三者共同デバッグ

このステップはテスト前の最後のステップに達しました。現時点では、クライアントは静的リソースと統合されており、Android インターフェイスであってもバックグラウンドサーバーインターフェイスであっても、呼び出されるインターフェイスはシミュレートされなくなりました。

開発中、バグの発見中、ページのデバッグ中など、3 つの共同デバッグ状態間の切り替えが必要になることがよくあります。たとえば、特定の JS ロジックのバグを修正する場合、通常は最初に 2 番目の共同デバッグステップから開始します。結局のところ、PC ブラウザでバグをデバッグする方がはるかに便利です。その後、バグがほぼ修正されると、実デバイスのデバッグのために静的リソースが携帯電話にプッシュされます。

次の疑問は、これら 3 つの共同デバッグ状態の柔軟な切り替えをどのように実現するかということです。コードの一部を見てみましょう:

2345678910111213141516171819202122

3 つの結合デバッグ状態間の切り替えを実現するために、fis3 に基づいてプラグインを開発しました。このプラグインの機能も非常に単純で、上記のコードを処理するだけです。

どうやって対処すればいいですか？まず、上記のコードを見てください。1 つ目はシミュレートされたコードモジュール (and で囲まれた)、2 つ目は実際のコードモジュール ( で囲まれた) です。シミュレーションコードモジュールには、Android インターフェイスをシミュレートする js ファイルの導入、偽のデータのパス、およびシミュレートされた Android 呼び出し初期化インターフェイスが含まれています。実際のコードモジュールは、実際の運用環境で使用する必要があるいくつかのパスを記述することができます。どちらのモジュールも必要ありません。

プラグインが行う必要があるのは、シミュレーションコードモジュールを削除し、実際のコードモジュールを解放することです。

これを行うことの利点について話しましょう。偽のデータ結合デバッグをシミュレートする段階では、このプラグインは必要ありません。したがって、この時点では、上記のコードに従って、シミュレーションコードモジュールが実行されます。リアルインターフェイスのジョイントデバッグを実行したい場合は、fis3 のパーサーステージでプラグインを呼び出して、シミュレーションコードを削除し、実際のコードを使用する必要があります。プラグインの使用は fis3 設定ファイルで設定され、fis3 のメディア API を通じてプラグインを使用するかどうかを動的に制御できます。

パフォーマンスの最適化と落とし穴

これは比較的大きなトピックであり、Yahoo の Fourteen Points など、誰もがすでによく知っているページ最適化のガイドラインや情報がたくさんあります。ここでは、私たちが行った最適化のいくつかと、プロジェクトの観点から解決した問題のいくつかをリストするために最善を尽くします。

写真

使用できない場合は、使用しないようにしてください。使用する必要がある場合は、複数の角度から最適化できます。例:

CDN に配置すると、リソースをユーザーの近くに保ちながら、Cookie などの不要なデータの送信も削減できます。
CSSSprites を使用してリクエスト量を削減します。
画像サイズを小さくするにはWebPを使用してください。
小さなアイコンではbase64:URL画像を使用できます。
場合によっては、技術的な観点から最適化することができないため、ユーザーエクスペリエンスにできるだけ影響を与えずに UI または製品ソリューションを調整する必要がある場合があります。たとえば、UI の学生は、不規則なぼかしたグラデーションを含む背景画像を設定しました。この場合、ぼかしのグラデーションを維持する必要がありますが、それを規則的にするには、画像の小さな部分を切り取り、それをタイリングすることで実現できます。場合によっては、このようなトレードオフを行って、妥協案の解決策を選択する必要があります。

ビューポート

ビューポートの幅の設定に関しては、現在 2 つの一般的な方法があります:

固定幅を記述する
デバイスの幅に設定する

1 つ目の方法はシンプルで便利です。メディアクエリは必要、rem は不要など、1 つのバージョンですべてのモデルに適しています。また、ページの細かさの問題に関しては、ビューポートの幅を比較的大きく設定すると、線やフォントなどをより細かく制御できます。

2番目の方法については、現在、ほとんどの大企業がモバイル端末にこの方法を使用しています。結局のところ、この方法のパフォーマンスは以前の方法よりも高く、スケーリング処理が 1 つ少なく、互換性も優れています。

したがって、上記の比較の後、2 番目の方法をお勧めします。しかし、他社の人とコミュニケーションをとる過程で、さまざまな理由から依然として最初の方法を採用していることもわかりました。同時に、最初の方法を使用して実装されるプロジェクトもいくつかあります。

最初の方法を使用すると、ページが読み込まれるときに描画効果があまり良くなく、左から右へのタイル処理 (実際にはスケーリング処理) が発生する場合があることがわかりました。この点に関しては、実際には不透明度の制御によって効果を最適化することができます。

アニメーション

アニメーションはハイブリッドアプリの問題点であるに違いありません。 Android の組み込み Web ビューで Android と同様の効果を持つアニメーションを実装したい場合、それは非常に難しく、多くの落とし穴に遭遇することになります。

たとえば、劇場の予約ページを作成する場合、座席選択エリアはズームできる必要があります。この機能要件を満たした上で開発を開始します。

スケーリングに関して、最初に思いつくのはCSS3のtransform属性のscale値です。次に、開発にはスケールソリューションを採用しました。

アニメーションの開発プロセスには常に困難が伴い、当然のことながら問題が発生します。手動ズーム後、座席選択エリアの座席がかなりぼやけてしまいました。

写真を使用しているため、拡大すると写真がぼやけてしまうのではないかと思うかもしれませんが、これは当然です。さて、次に、CSS を使用して背景色を設定して座席を直接描画してみます。ただし、その結果、ズームインするとまだぼやけてしまいます。

この場合は、落ち着いて考える必要があります。正確になぜですか?

理由を説明する前に、まず別の古代の CSS 属性ズームを導入し、その 2 つの違いについて説明する必要があります:

Zoom は当初 IE ブラウザーのプライベート属性にすぎませんでしたが、その後、ほとんどのブラウザーがこの属性の使用に対応しましたが、結局のところ、まだ仕様には書き込まれませんでした。スケールは w3c 標準に書き込まれます。
レンダリング順序が異なります。スケールは最初に染色されてからスケーリングされ、ズームはスケーリングされてからレンダリングされます。
スケーリング原点、スケーリング方向など、スケールに関連する制御パラメータが多数あります。ズームのデフォルトのズーム原点は左上隅であり、ズーム原点を変更するための直接パラメータはありません。

上記の違いに基づいて、次の結論を導き出すことができます:

ズームを使用してズームすると、視覚効果がより鮮明になります。スケールを使用してズームすると、視覚効果がぼやけます。
ズームを使用してズームすると、ページのリフローが発生する可能性があります。スケーリングにスケールを使用しても、ページの再配置は発生しません。
ズームを使用したズームは、HTML レンダリングルールによって制限されます。たとえば、最小フォントが 12 ピクセルの場合、どのように縮小してもフォントは 12 ピクセルのままです。スケールはそうではありません。

次に、拡大すると座席がぼやける問題の解決方法について説明します。上記の結論に基づいて、2 つの解決策が導き出されます:

ズームを使用してズームすると、倍率のぼやけの問題が解決されます。
スケールを使用してズームしますが、最初はスケール値を少し大きく、たとえば 3 (サイズの 3 倍) に設定します。次に、スケールを密かに 1x に設定します (setTimeout など)。

アニメーションの最適化については、この例から先にお話しますが、実はハイブリッドアプリの開発過程ではまだまだ最適化のプロセスが多く、もちろん落とし穴もたくさん踏んでいます。さらに詳しく知りたい場合は、Meizu のライフサービス、アクティビティセンター、電話イエローページ、その他のアプリを試してみることができます。これらはすべて、多かれ少なかれハイブリッドソリューションを使用して開発されています。

結論

現在、フロントエンドテクノロジーは日々変化しており、常に新しいテクノロジー (React、es6 など) を試し、常に細部に焦点を当て、常に最適化と再最適化を行っています。これらすべてを 1 つのブログ投稿でカバーすることはできません。今後、新しいコンテンツを追加して、一緒に議論し、学習していきます。

について話します。