当为移动设备调整网页时，我总是依赖 CSS 媒体查询。
最近我不再只担心屏幕尺寸，还担心许多移动设备的 javascript 引擎。一些依赖于窗口滚动或快速 DOM 转换序列的常见 javascript 效果在慢速设备上效果非常糟糕。
有没有办法猜测设备性能，以便我可以启用/禁用在慢速设备上看起来很糟糕的元素？
到目前为止我只能想到不好的解决方案：
- 屏幕尺寸。窄屏幕“可能”意味着设备速度慢
-
用户代理信息 http://en.wikipedia.org/wiki/User_agent#User_agent_identification。我可以查看设备、浏览器或 CPU，但这似乎不是一个稳定的长期解决方案，因为需要考虑的设备数量
更新：
修正了我的问题以集中解决一个问题。评论里有一个很好的解决触摸界面问题的方法。
当然，对于这个问题似乎没有特别好的解决方案（这是有道理的，因为这种类型的东西通常应该是隐藏的东西类型）。我认为无论哪种方式，你最好从 UA 检测开始，以处理那些已知属于某一类别的平台。那么您将有两种选择来灵活适应未知/不确定的平台：
渐进增强：从精简测试开始，加载一个或多个小型性能测试来衡量设备性能，然后加载文件以进行适当的增强。测试例如已经提供或在：如果计算机速度慢，请跳过一些代码 https://stackoverflow.com/questions/1055957/skip-some-code-if-the-computer-is-slow
优雅的降级：将那些可能在较慢的设备上导致不利用户体验的功能包装在一个高阶函数中，如果它们在第一次执行时花费太长时间，则该函数将替换它们。在这种情况下，我可能会将其添加到Function.prototype然后允许将可接受的延迟参数链接到函数定义上。第一次调用后存储经过的时间，然后在第二次调用时，如果经过的时间超过延迟，则通过回退换出该函数。如果经过的时间可以接受，则通过交换标准函数来删除分析代码。我需要坐下来制定示例代码（也许这个周末）。这也可以通过其他参数进行调整，例如在交换之前进行多次分析。
第一个选项可能是更友好的选项，但第二个选项可能对现有代码的干扰较小。 Cookie 或收集进一步的 UA 数据也有助于在检索信息后继续分析。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
