我的网页中有一些浏览器密集型 CSS 和动画,我想确定用户是否拥有快速的 PC,以便我可以相应地缩放以提供最佳体验。
我正在使用http://detectmobilebrowser.com的脚本来检测所有移动设备,并且我将包含该子句/android|ipad|ipod|playbook|silk/i.test(a)
以包括所有平板电脑设备。
然而,这并不能也不能真正解决实际的硬件问题。画出我正在寻找的东西并没有走得太远。
例如,iPhone 4S 将比移动用户代理检测器匹配的许多设备功能强大得多,这使它无法脱颖而出。有人可能会在 Pentium II 机器上运行 Google Chrome(不知何故)并想查看我的页面。(此人可能没有 iPhone 4S)
显然,要真正了解这一点,我必须进行一些实际的性能测试,并且与任何类型的应用程序的性能测试一样,只测试应用程序实际执行的任务类型的性能是有意义的。
即使考虑到这一点,我觉得在性能测试例程花费太长时间并且用户会变得不耐烦之前,很难获得任何合理准确的数字。所以这可能意味着继续它,除非我希望第一印象是完美的。嗯,这实际上恰好是这种情况。因此,我无法在“第一次运行后”测量性能并稍后调整参数。
所以我剩下的就是基本上尝试在初始页面加载时执行类似的任务,以一种依赖于浏览器渲染和处理速度的方式,同时不向用户呈现任何内容(这样用户仍然认为页面正在加载),然后最好在一两秒内获得足够准确的数字,以便为实际页面设置参数,以便以不类似于幻灯片的令人愉悦的方式进行动画和呈现。
也许我可以<div>
在我的测试用例上放置一个整页的白色,这样我就可以防止用户看到正在发生的事情,并希望浏览器不会因为避免做所有的工作而变得聪明。
有没有人这样做过?
我知道人们会说,“你可能不需要这样做”,或者“必须有更好的方法”或“减少影响的数量”。
我在页面上做的任何事情的原因都是为了看起来不错。这就是它的全部意义所在。如果我不那么关心这个问题就不会存在。目标是让 javascript 能够确定足够的参数,以在功能强大的计算机上提供出色的体验,并在功能较弱的计算机上提供可及的体验。当有更多的电力可用时,应该加以利用。所以希望这可以解释为什么这些建议不是问题的有效答案。