我使用http://detectmobilebrowser.com的脚本来检测所有移动设备,我将包括条款/android |ipad |ipod | playbook | silk / i.test(a)以包括所有平板电脑设备.
然而,这不能也不能真正解决实际的硬件问题.绘制一张我正在寻找的图片并不是很遥远.
例如,iPhone 4S将比移动用户代理检测器匹配的许多设备具有更强大的功能,这使得它无法将自己与众不同.
有人可能会在奔腾II机器上运行谷歌浏览器(不知何故),并希望查看我的页面. (这个人可能没有iPhone 4S)
显然,为了实际获得这个想法,我将不得不做一些实际的性能测试,并且与任何类型的应用程序的性能测试一样,仅测试应用程序实际执行的任务类型的性能是有意义的.
即使考虑到这一点,我觉得在性能测试例程花费太长时间并且用户已经变得不耐烦之前,很难获得任何合理准确的数字.所以这可能意味着继续它,除非我希望第一次初步印象是完美的.嗯,事实恰恰是这种情况.因此,我无法在“第一次运行后”测量性能并稍后调整参数.
所以我剩下的就是基本上尝试在初始页面加载上执行类似的任务,其方式取决于浏览器渲染和处理速度,同时不向用户呈现任何内容(这样对于用户他们仍然认为该页面正在加载),然后优选地在一秒或两秒内获得足够精确的数字以设置实际页面的参数以使其具有动画并以不喜欢幻灯片放映的令人愉悦的方式呈现.
也许我可以放一整页白色< div>在我的测试用例中,我可以阻止用户看到正在发生的事情,并希望浏览器不会通过避免完成所有工作而变得聪明.
有没有人这样做过？
我知道人们会说,“你可能不需要这样做”,或者“必须有更好的方式”或“减少效果”.
做我在页面上做的任何事情的原因是它看起来很好.这就是它的全部意义.如果我不关心这个问题就不会存在.目标是让javascript能够确定足够的参数,以便在功能强大的计算机上提供令人敬畏的体验,并在功能较弱的计算机上提供可通过的体验.当有更多电力时,应该利用它.所以希望这可以解释为什么这些建议不是问题的有效答案.
解决方法
假设用户在后台启动程序会占用大量cpu时间.如果你使用这个想法,你的页面将自动降低视觉效果,以节省cpu周期.当后台程序结束时,会产生奇特的效果.我不知道你的用户是否会喜欢这种效果(但我确信他们会喜欢他们的浏览器在cpu过载时保持响应的事实).