最初のスクリーンパフォーマンス最適化スキームの記録(バックアップ)について簡単に説明します.
原文は1ヶ月前にジェーン・チャットで発表されました.https://jianliao.com/)ブログで、こちらからバックアップhttps://jianliao.com/blog/jian-liao-shou-ping-xing-neng-you-hua-fang-an-xie-ji-lu/
まず全体の改善案の基礎はReduxが提出したSingle StoreアーキテクチャがReduxの理念に従って応用を抽象化した後、アーキテクチャはMVCの非常に原始的な理念に回帰して、つまり:1つのModel、1つのView、および残りのControllerコード
問題のあるシナリオはオブジェクト化されたパッケージであり,特に各ViewにはMVCのような独立したオブジェクトが存在し,具体的には初期に使用されていたBackboneアーキテクチャについて簡単に話し,各Collectionにデータが分散し,管理が困難であると考えられる.
Reduxのアーキテクチャの中で、ただ1つのStoreだけあって、データに対して統一的な管理を行うのはずっと便利でimmutable-jsの加入、更に全体のアーキテクチャのデータストリームを非常にはっきりさせるRedux方案の中で、データ層はStoreで、インタフェースはReact Componentの構成のViewで、ControllerのはActionsとReducerだけが引き受けることができて、ここでただ類比をします
簡単なデータ構造と関数から複雑なアプリケーションを構築するためには、各部分を抽象化し複合する必要がある.まず、ViewはReact Componentsを介して小さいものから大きいものまで柔軟に組み合わせられ、StoreはMapとReducer関数によっても組み合わせられる(実際にはこの点は徹底していない)また、アプリケーションとサービス側にはデータ同期のニーズがあり、抽象化も考慮する必要がある(後述).全体的なアーキテクチャは大体これらです
Reduxで最も有名なのは、そのTime Travel Debugging機能、すなわちActionsとStoreを記録して遡及することである.実際には、「データインタフェースの分離が十分かどうか」というアーキテクチャが完備しているかどうかを検証する試練でもあります.単一ページアプリケーションが異常を起こさずにデータ状態を自由にロールバックできる場合、アプリケーションの動作とデータストリームが非常に明確であると自信を持って言えます.予測がよく、インタフェースとデータには複雑な双方向の操作がありません.特にインタフェースをレンダリングすると、データ更新Reactコンポーネントが任意にレンダリングされ、更新インタフェースが更新されます.データが影響を受けなければ、アプリケーションは混乱しません.
実際のアプリケーション作成では、ページのロードデータプロセスを切り替えるには、具体的な問題があります.まず、私たちのアーキテクチャでルートを切り替えるのは、まずインタフェースを切り替えてから、インタフェースの初期化時にデータをロードします.しかし、この方法は上記のスキームに反しています.レンダリングプロセスには、データ操作のもう一つの実際の影響があります.データを要求するロジックは、コンポーネントのマウント時に呼び出されます.データをロードしたいのにインタフェースをレンダリングするアーキテクチャがはっきりしているかどうかは、最適化が難しいです.もちろん、私にとって最も頭が痛いのは前のことで、より高いレベルからアーキテクチャを最適化することを阻害する問題です.
たとえば、話題を簡単に切り替えたり、話題をクリックしたり、アドレスを変更したりするには、デフォルトのreact-routerの動作に従ってデータをロードする必要があります.アドレスの変更は、インタフェースの再描画、つまり新しい話題のインタフェースをすぐにレンダリングすることになりますが、話題の数がまだ要求されていないコンポーネントは、データのない話題をレンダリングしなければなりません.データのロードが完了するまで、再レンダリングこのインタフェースの多くの動作は制御を超えており、最適化が困難であり、特にルーティングが制御されていない正しいプロセスでは、データをロードしてからインタフェースをレンダリングし、ロードプロセスにヒントを与える必要があります.
上のアーキテクチャの設計と具体的な問題に基づいて、簡単なチャットは自分で実現したルーティングコンポーネントというルーティングコンポーネントの行為を採用してSingle Storeの中のデータ制御を通じて、および相応のloading状態の現在のバージョンの簡単なチャットを通じて、話題をクリックして、先にloading状態をマークして、同時にバックグラウンドでデータ要求を開始して、要求が完成して、loading状態をリセットする同時に、要求したデータはインタフェースの上で現実的に現れて、データ要求操作をマージすることもでき、将来の最適化には切り替えチームが含まれ、データをロードしてインタフェースをレンダリングする効果を達成する最適化も可能になりました.
このプロセスをうまく処理するために、対応するルーティングにどのようなデータが必要かを知る必要があります.例えば、話題Aの中で、topica、memberA、team 1、contact 1が必要です.話題Bの中で、topicB、memberB、team 1、contact 1のデータをAからBに切り替える必要があります.ローカルにどのようなデータが混在しているかを分析し、それらのデータが欠けていると、欠けているデータを正確につかむことができます.インタフェースに必要なデータキャプチャが完了したときにFacebook Relayをレンダリングすることを目的とした一連のスキームですが、私たちには向いていません.そのため、プロジェクトで簡単なデータ依存分析コードを実現し、この目的を達成しました.
まず、ネットワークの切断と再接続のための特殊な処理について簡単に説明します.ローカルのデータを強制的に更新します.具体的には、メモリキャッシュの古いメッセージと話題を明らかにしたり、すべてのキャッシュの失効をマークしたりします.その後、前述のシナリオに従って現在必要なデータを分析し、データをキャプチャするプロセスの鍵は、ルーティングに基づいて、現在のインタフェースに必要なデータを分析する必要があります.チャットの主な状態はStoreに格納されているため、少なくともアーキテクチャに障害はありません.このような操作を経て、ネットワークが再接続された後、チャットは同期更新の状態に戻ることができます.
最初のスクリーンのロードは似たような問題で、ユーザーはしばらくログインしていません.この場合、同期を行う必要があります.違いは、最初のスクリーンのロードはローカルでキャッシュに対応していません.Single Storeを格納し、次回ページが開くキャッシュとして使用することは、ブラウザを閉じるときにすべてをキャッシュし、次回開くときにすべてを閉じるシーンに復元することに相当し、実際にはユーザはjianliaoを通過する.comアクセスアプリケーションは、このキャッシュにヒットする可能性が高い.
このような出発点に基づいて、アプリケーションを閉じるときにStoreをJSON文字列に変換するlocalStorageアプリケーションを再度開くとき、条件が適切であればキャッシュを直接レンダリングし、バックグラウンドで依存を分析してデータをつかみ始め、最終的に新しいデータを取得した後にインタフェースを再更新ユーザにとってブラウザはjianliaoを入力.comはすぐにレンダリングを開始し、多くの待ち時間を節約します.あまり長くログインしていなければ、新しいデータ更新のインタフェースも明らかではありません.最も直接的な効果は、多くの場合、簡単なチャットがより速く開くことができ、より便利です.
この手口の使用前後で、簡単なチャットのロードの順序がいくつか変化しました.
基数と変動の大きいネットワーク要求時間を除いて、残りはJavaScriptの実行とレンダリングの時間です.チャットの最初の画面をユーザーの前にもっと早く表示させるには、起動とレンダリング速度の最適化を開始します.
ChromeのTimelineデバッグツールを通じて、私が徐々に収集したのは、主にDOM reflowのオーバーヘッドであり、不安定ですが、通常は長い時間の消費を招く点です(次のリストは私が主に記憶に基づいてリストしたもので、完全ではありません): に関係する. をトリガする場合がある. . jQuery初期化プロセスはDOMを読み書きし、reflow(現在は削除できません) をトリガーする可能性があります. React初期化プロセスは、いくつかのDOMのプローブ(最適化できない) を行う. rangy初期化プロセスにはDOM読み書き(最適化不可) がある. favico.jsはDOMの読み書きを初期化する(最適化できない) 問題の鍵はもちろんDOM操作がいくつかのreflowの問題を触発したことである.次にJavaScriptが各種timerと複雑な計算を初期化するのにも時間がかかるが、実際には純粋なJavaScript自体の性能は、コードが問題を書かない限り、遅くはない.
http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/https://gist.github.com/paulirish/5d52fb081b3570c81e3a
残りはCPUが密集する計算がメインであることを考慮すると、実際にはCPUの性能の影響が大きいCPUの性能が良いほどレンダリングが速くなる.少なくとも現在はネットワークの遅い影響を部分的に排除しています.また、レンダリングの最適化は初歩的なもので、後続の深い最適化後、初回レンダリングの性能が向上すると信じています.
Single Storeの重要性
まず全体の改善案の基礎はReduxが提出したSingle StoreアーキテクチャがReduxの理念に従って応用を抽象化した後、アーキテクチャはMVCの非常に原始的な理念に回帰して、つまり:1つのModel、1つのView、および残りのControllerコード
問題のあるシナリオはオブジェクト化されたパッケージであり,特に各ViewにはMVCのような独立したオブジェクトが存在し,具体的には初期に使用されていたBackboneアーキテクチャについて簡単に話し,各Collectionにデータが分散し,管理が困難であると考えられる.
Reduxのアーキテクチャの中で、ただ1つのStoreだけあって、データに対して統一的な管理を行うのはずっと便利でimmutable-jsの加入、更に全体のアーキテクチャのデータストリームを非常にはっきりさせるRedux方案の中で、データ層はStoreで、インタフェースはReact Componentの構成のViewで、ControllerのはActionsとReducerだけが引き受けることができて、ここでただ類比をします
簡単なデータ構造と関数から複雑なアプリケーションを構築するためには、各部分を抽象化し複合する必要がある.まず、ViewはReact Componentsを介して小さいものから大きいものまで柔軟に組み合わせられ、StoreはMapとReducer関数によっても組み合わせられる(実際にはこの点は徹底していない)また、アプリケーションとサービス側にはデータ同期のニーズがあり、抽象化も考慮する必要がある(後述).全体的なアーキテクチャは大体これらです
データインタフェースの分離
Reduxで最も有名なのは、そのTime Travel Debugging機能、すなわちActionsとStoreを記録して遡及することである.実際には、「データインタフェースの分離が十分かどうか」というアーキテクチャが完備しているかどうかを検証する試練でもあります.単一ページアプリケーションが異常を起こさずにデータ状態を自由にロールバックできる場合、アプリケーションの動作とデータストリームが非常に明確であると自信を持って言えます.予測がよく、インタフェースとデータには複雑な双方向の操作がありません.特にインタフェースをレンダリングすると、データ更新Reactコンポーネントが任意にレンダリングされ、更新インタフェースが更新されます.データが影響を受けなければ、アプリケーションは混乱しません.
データ同期の問題
実際のアプリケーション作成では、ページのロードデータプロセスを切り替えるには、具体的な問題があります.まず、私たちのアーキテクチャでルートを切り替えるのは、まずインタフェースを切り替えてから、インタフェースの初期化時にデータをロードします.しかし、この方法は上記のスキームに反しています.レンダリングプロセスには、データ操作のもう一つの実際の影響があります.データを要求するロジックは、コンポーネントのマウント時に呼び出されます.データをロードしたいのにインタフェースをレンダリングするアーキテクチャがはっきりしているかどうかは、最適化が難しいです.もちろん、私にとって最も頭が痛いのは前のことで、より高いレベルからアーキテクチャを最適化することを阻害する問題です.
たとえば、話題を簡単に切り替えたり、話題をクリックしたり、アドレスを変更したりするには、デフォルトのreact-routerの動作に従ってデータをロードする必要があります.アドレスの変更は、インタフェースの再描画、つまり新しい話題のインタフェースをすぐにレンダリングすることになりますが、話題の数がまだ要求されていないコンポーネントは、データのない話題をレンダリングしなければなりません.データのロードが完了するまで、再レンダリングこのインタフェースの多くの動作は制御を超えており、最適化が困難であり、特にルーティングが制御されていない正しいプロセスでは、データをロードしてからインタフェースをレンダリングし、ロードプロセスにヒントを与える必要があります.
上のアーキテクチャの設計と具体的な問題に基づいて、簡単なチャットは自分で実現したルーティングコンポーネントというルーティングコンポーネントの行為を採用してSingle Storeの中のデータ制御を通じて、および相応のloading状態の現在のバージョンの簡単なチャットを通じて、話題をクリックして、先にloading状態をマークして、同時にバックグラウンドでデータ要求を開始して、要求が完成して、loading状態をリセットする同時に、要求したデータはインタフェースの上で現実的に現れて、データ要求操作をマージすることもでき、将来の最適化には切り替えチームが含まれ、データをロードしてインタフェースをレンダリングする効果を達成する最適化も可能になりました.
このプロセスをうまく処理するために、対応するルーティングにどのようなデータが必要かを知る必要があります.例えば、話題Aの中で、topica、memberA、team 1、contact 1が必要です.話題Bの中で、topicB、memberB、team 1、contact 1のデータをAからBに切り替える必要があります.ローカルにどのようなデータが混在しているかを分析し、それらのデータが欠けていると、欠けているデータを正確につかむことができます.インタフェースに必要なデータキャプチャが完了したときにFacebook Relayをレンダリングすることを目的とした一連のスキームですが、私たちには向いていません.そのため、プロジェクトで簡単なデータ依存分析コードを実現し、この目的を達成しました.
スクリーンレンダリングの手口
まず、ネットワークの切断と再接続のための特殊な処理について簡単に説明します.ローカルのデータを強制的に更新します.具体的には、メモリキャッシュの古いメッセージと話題を明らかにしたり、すべてのキャッシュの失効をマークしたりします.その後、前述のシナリオに従って現在必要なデータを分析し、データをキャプチャするプロセスの鍵は、ルーティングに基づいて、現在のインタフェースに必要なデータを分析する必要があります.チャットの主な状態はStoreに格納されているため、少なくともアーキテクチャに障害はありません.このような操作を経て、ネットワークが再接続された後、チャットは同期更新の状態に戻ることができます.
最初のスクリーンのロードは似たような問題で、ユーザーはしばらくログインしていません.この場合、同期を行う必要があります.違いは、最初のスクリーンのロードはローカルでキャッシュに対応していません.Single Storeを格納し、次回ページが開くキャッシュとして使用することは、ブラウザを閉じるときにすべてをキャッシュし、次回開くときにすべてを閉じるシーンに復元することに相当し、実際にはユーザはjianliaoを通過する.comアクセスアプリケーションは、このキャッシュにヒットする可能性が高い.
このような出発点に基づいて、アプリケーションを閉じるときにStoreをJSON文字列に変換するlocalStorageアプリケーションを再度開くとき、条件が適切であればキャッシュを直接レンダリングし、バックグラウンドで依存を分析してデータをつかみ始め、最終的に新しいデータを取得した後にインタフェースを再更新ユーザにとってブラウザはjianliaoを入力.comはすぐにレンダリングを開始し、多くの待ち時間を節約します.あまり長くログインしていなければ、新しいデータ更新のインタフェースも明らかではありません.最も直接的な効果は、多くの場合、簡単なチャットがより速く開くことができ、より便利です.
レンダリングパフォーマンスの最適化(Render Performance Optimization)
この手口の使用前後で、簡単なチャットのロードの順序がいくつか変化しました.
: , , ,
: , , , , 基数と変動の大きいネットワーク要求時間を除いて、残りはJavaScriptの実行とレンダリングの時間です.チャットの最初の画面をユーザーの前にもっと早く表示させるには、起動とレンダリング速度の最適化を開始します.
ChromeのTimelineデバッグツールを通じて、私が徐々に収集したのは、主にDOM reflowのオーバーヘッドであり、不安定ですが、通常は長い時間の消費を招く点です(次のリストは私が主に記憶に基づいてリストしたもので、完全ではありません):
getBoundingClientRect呼び出しは、いくつかのメニュー位置(最適化可能)focusの動作は、DOMのreflow(最適化できないものもあるが、遅延処理可能)scrollTopの読み取りと操作は比較的顕著である(ただし、一部の呼び出しは最適化できない、そうでないとユーザ体験に影響を及ぼす)http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/https://gist.github.com/paulirish/5d52fb081b3570c81e3a
残りはCPUが密集する計算がメインであることを考慮すると、実際にはCPUの性能の影響が大きいCPUの性能が良いほどレンダリングが速くなる.少なくとも現在はネットワークの遅い影響を部分的に排除しています.また、レンダリングの最適化は初歩的なもので、後続の深い最適化後、初回レンダリングの性能が向上すると信じています.