6

Webページをモバイルデバイスに適合させるとき、私は常にcssメディアクエリに依存しています。

最近、私はもはや画面サイズだけでなく、多くのモバイルデバイスのjavascriptエンジンについても心配していません。ウィンドウスクロールまたはDOM変換のクイックシーケンスに依存するいくつかの一般的なJavaScript効果は、低速のデバイスでは非常にうまく機能しません。

遅いデバイスで見栄えの悪い要素を有効/無効にできるように、デバイスのパフォーマンスを推測する方法はありますか？

これまでのところ、私は悪い解決策しか考えられません。

  1. 画面サイズ。狭い画面「かもしれない」は遅いデバイスを意味します
  2. ユーザーエージェント情報。デバイス、ブラウザ、またはCPUを見ることができましたが、検討するデバイスの数が多いため、それは安定した長期的な解決策ではないようです。

更新：1つの問題に焦点を当てるように私の質問を修正しました。コメントには、タッチインターフェイスの問題に対する優れた解決策があります。

4

3 に答える 3

2

私が考えることができる唯一の方法は、エフェクトを使用する前または使用中に、バックグラウンドでJSである種の速度テストを実行することです。これは、プロセッサ速度が原因で遅いデバイスをキャッチするか、またはその逆で、時間精度が高い/速いデバイスをキャッチする必要があります。ただし、デバイスに最適化があり、グラフィック効果を計算するために異なるプロセッサを使用している場合、これは機能しません。

var speedtest = function(){
  /// record when we start
  var target = new Date().getTime(), count = 0, slow = 0;
  /// trigger a set interval to keep a constant eye on things
  var iid = setInterval(function(){
    /// get where we actually are in time
    var actual = new Date().getTime();
    /// calculate where we expect time to be
    target += 100;
    /// 100 value here would need to be tested to find the best sensitivity
    if ( (actual - target) > 100 ) {
      /// make sure we aren't firing on a one off slow down, wait until this
      /// has happened a few times in a row. 5 could be too much / too little.
      if ( (++slow) > 5 ) {
        /// finally if we are slow, stop the interval
        clearInterval(iid);
        /// and disable our fancy resource-hogging things
        turnOffFancyAnimations();
      }
    }
    else if ( slow > 0 ){
      /// decrease slow each time we pass a speedtest
      slow--;
    }
    /// update target to take into account browsers not being exactly accurate
    target = actual;
    /// use interval of 100, any lower than this might be unreliable
  },100);
}

もちろん、これを実行すると、デバイスの速度にも影響するため、実際には最善の解決策ではありません。原則として、画面が小さい場合は、アニメーションなどの不要なものを無効にする傾向があります。

この方法のもう1つの欠点は、私が以前に経験したことですが、マルチタブ環境を実装する特定のブラウザーsetIntervalsは、タブが表示されていないときに自動的に特定の速度に制限されることです。これは、このブラウザがタブで移動すると、自動的にエクスペリエンスがダウングレードされることを意味します-この課せられた速度制限が何らかの方法で検出されない限り。

于 2012-09-15T13:17:36.540 に答える
2

確かに、この問題には特に良い解決策はないようです（このタイプのものは通常、隠されているタイプのものであると想定されているため、これは理にかなっています）。いずれにせよ、UA検出から始めて、あるカテゴリまたは別のカテゴリに分類されることがわかっているプラ​​ットフォームを処理するのが最善だと思います。次に、未知の/不確実なプラットフォームに柔軟に適応するための2つのオプションがあります。

  1. プログレッシブエンハンスメント：簡素化されたテストから始めて、デバイスのパフォーマンスを測定するための小さなパフォーマンステストをロードしてから、適切なエンハンスメントのためにファイルをロードします。すでに提供されているようなテスト：コンピュータが遅い場合はコードをスキップする

  2. グレースフルデグラデーション：低速のデバイスで不利なUXを引き起こす可能性のある機能を、最初の実行に時間がかかりすぎる場合に置き換える高階関数でラップします。この場合、おそらくそれを追加してFunction.prototype、許容可能な遅延引数を関数定義にチェーンできるようにします。最初の呼び出しストアの後で時間が経過し、2回目の呼び出しで時間が経過した場合は遅延を超えて、フォールバックを使用して関数をスワップアウトします。経過時間が許容できる場合は、標準関数を交換してプロファイリングコードを削除します。私は座ってサンプルコードを作成する必要があります（多分今週末）。これは、スワッピングする前に複数回プロファイリングするなどの追加の引数によって調整することもできます。

最初のオプションはより親しみやすいオプションである可能性がありますが、2番目のオプションは既存のコードへの影響が少ない可能性があります。Cookieを使用したり、さらにUAデータを収集したりすることも、情報が取得された後もプロファイルを継続するのに役立ちます。

于 2012-09-15T13:52:23.413 に答える
1

ある種の独自のミニベンチマークを作成することができます。いくつかの厳しい計算を行い、結果の時間を計ります。サポートされているデバイスの中で最も遅いと思われるデバイスよりも遅い場合は、サイトの集中度の低いバージョンに移動します。

また、ユーザーがパフォーマンスの問題を経験している場合は、簡単にアクセスできるリンクを作成して、より基本的なサイトに切り替えることもできます。

画面サイズを小さくするのは良い考えではありません。最近の携帯電話の多くは、高速プロセッサを搭載した小さな画面を備えています。

于 2012-09-15T14:13:14.870 に答える