6

在为移动设备调整网页时，我总是依赖 css 媒体查询。

最近我不再只担心屏幕大小，还担心许多移动设备的 javascript 引擎。一些依赖于窗口滚动或快速 DOM 转换序列的常见 javascript 效果在慢速设备上效果不佳。

有什么方法可以猜测设备性能，以便我可以启用/禁用在慢速设备上看起来很糟糕的元素？

到目前为止，我只能想到不好的解决方案：

  1. 屏幕尺寸。窄屏“可能”意味着慢速设备
  2. 用户代理信息。我可以查看设备、浏览器或 CPU，但这似乎不是一个稳定的长期解决方案，因为要考虑的设备数量

更新：修复了我的问题以专注于一个问题。在评论中有一个很好的解决触摸界面问题的方法。

4

3 回答 3

2

似乎对于这个问题没有特别好的解决方案（这是有道理的，因为这种类型的东西通常应该是隐藏的东西类型）。我认为无论哪种方式，您最好从 UA 检测开始，以处理那些已知属于某一类别的平台。然后，您有 2 个选项可以灵活地适应未知/不确定的平台：

  1. 渐进式增强：从精简测试开始，加载一个或多个小型性能测试以衡量设备性能，然后加载文件以进行适当的增强。测试例如已经提供或在：如果计算机速度慢，请跳过一些代码

  2. 优雅降级：将那些可能在较慢的设备上导致不利用户体验的候选功能包装在一个更高阶的函数中，如果它们在第一次执行时花费的时间过长，则替换它们。在这种情况下，我可能会将其添加到Function.prototype然后允许将可接受的延迟参数链接到函数定义。在第一次调用后存储经过的时间，然后在第二次调用时，如果经过的时间超过延迟，则使用回退换出函数。如果经过的时间可以接受，则通过交换标准函数来删除分析代码。我需要坐下来编写示例代码（也许这个周末）。这也可以通过其他参数进行调整，例如在交换之前进行多次分析。

第一个选项可能是更友好的选项，但第二个可能对现有代码的干扰较小。Cookie 或收集更多 UA 数据也有助于在检索到信息后继续进行分析。

于 2012-09-15T13:52:23.413 回答
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);
}

当然，运行它也会影响设备的速度，所以它并不是最好的解决方案。作为一项规则，我倾向于在屏幕很小的时候禁用动画和其他多余的东西。

这种方法的另一个缺点——我以前经历过——是一个实现多选项卡环境 setIntervals 的特定浏览器在不查看选项卡时会自动限制为特定速度。这意味着对于这个浏览器来说，tab键会自动降低他们的体验——除非这个强加的速度限制可以以某种方式被检测到。

于 2012-09-15T13:17:36.540 回答
1

您可以制作自己的迷你基准测试。做一些苛刻的计算并对结果计时。如果它比您认为最慢的受支持设备慢，那么您将降低到站点的密集度较低的版本。

如果用户遇到性能问题，您也可以创建一个易于访问的链接以切换到更基本的站点。

缩小屏幕尺寸不是一个好主意。许多现代手机都有小屏幕和快速处理器。

于 2012-09-15T14:13:14.870 回答