谷歌浏览器打开视频全屏的时候有动画，感觉这动画多余的，怎么样关闭？_百度知道
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。
谷歌浏览器打开视频全屏的时候有动画，感觉这动画多余的，怎么样关闭？
我有更好的答案
使用起来很稳定，IE的内核，启动和运行的速度也很快。一直用的QQ浏览器，能兼容很多软件没有安装过，不是很了解，可以去设置里面看下有没有选项。界面简洁，像那种多余的特效是没有的哦，不会出现卡顿的现象呢。可以下载安装了用了看下
采纳率：72%
没有安装过谷歌浏览器，常用360安全浏览器和搜狗浏览器。
为您推荐：
其他类似问题
谷歌浏览器的相关知识
换一换
回答问题，赢新手礼包本来地图网页运行的好好的，突然从上周四()开始，就开始接到 PM 和 QA 说网页崩溃的报告。
然后我就在本机重现，刚开始以为是有网页上有什么内存泄漏；可是都运行这么长时间了，并且 IE 和 Firefox 都没有出现过此问题，看来应该是和 chrome 有关系了。说归这样说，可是需要证据啊。于是就猜测是不是 Chrome 新自动升级引入的BUG，然后就开始了漫长的排查过程。
找了好几个同事来协助排查，也没有发现页面上有任何内存使用异常的现象；但是就 Chrome 进程内存却会飙升，并且嗖嗖的一会就 600M 以上了。
一开始以为是页面 flash 导致的；于是就把页面引入的 flash 去掉了，可对比后发现才省去 7M 内存（一个 flash 就占 7M，而整个页面内存才占用 20M，看来 flash 作为内存杀手和崩溃杀手，果真名不虚传啊）。然后就满怀惊喜的测试，结果是页面依旧会崩溃，这下又无奈了。
没办法，只能从头再来，一步步的跟踪时间点。刷新了好多次之后，终于发现了一个规律，页面在加载完地图后，开始内存飙升，CPU 满负荷运转。等过个几十秒，CPU正常，然后地图开始陆续加载低图。
这下终于找到了一个突破口，于是找来地图开发的同学，让来协助定位问题所在。可一起研究了半天，除了观察到页面爆卡这个现象之外，原因排查依旧毫无进展。于是又不停地刷新页面，观察规律。每次都是先加载地图低图，然后页面 UI 停止响应，再过一段时间，页面正常，开始加载页面其他地图底图。观察了不知道多少次之后，猜测可能是地图缩放导致的。因为页面地图加载后，会有一次放大，此时页面就会崩溃；在其他同学机器上测试，有的会复现，有的不会复现，好像就是因为有的同学页面会有地图放大操作，而有的没有地图放大操作。
确定了这个原因之后，赶紧写了一个测试代码。CSS如下：
height: 600px;
width: 600px;
background: red;
.transform {
transform: scale(200);
.transition {
-webkit-transition: -webkit-transform .25s cubic-bezier(0, 0, .25, 1);
-moz-transition: -moz-transform .25s cubic-bezier(0, 0, .25, 1);
-o-transition: -o-transform .25s cubic-bezier(0, 0, .25, 1);
transition: transform .25s cubic-bezier(0, 0, .25, 1)
由于是做地图开发的，所以也放入一些地图底图图片，HTML 如下代码：
&div class=&div transition& id=&d1&&
&img src=&http://webrd01./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1685&y=775&z=11&&
&img src=&http://webrd02./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1686&y=775&z=11&&
&img src=&http://webrd02./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1685&y=776&z=11&&
&img src=&http://webrd03./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1686&y=776&z=11&&
&img src=&http://webrd04./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1685&y=774&z=11&&
&img src=&http://webrd03./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1687&y=775&z=11&&
&img src=&http://webrd01./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1686&y=774&z=11&&
&img src=&http://webrd01./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1684&y=776&z=11&&
然后就是写一段代码，模拟地图放大操作，JS代码如下：
setTimeout(function () {
var d1 = document.getElementById(&d1&);
d1.classList.add(&transform&);
setTimeout(function () {
var d1 = document.getElementById(&d1&);
d1.classList.remove(&transform&);
document.getElementById(&d1&).classList.remove(&transition&);
然后刷新一下页面，果真，页面还真是实实在在的卡爆了，和线上网页卡爆现象一模一样。
找到了原因所在，然后就是怎么解决了。页面开发了这么久，还真不是一时半会说改就能改的。然后费了半天的时间，把地图 JS-API 的版本从 1.2 切换到 1.3，这下就终于搞定了（1.3版本API地图缩放缩放过程与1.2不同，基本不会出现此问题）。等QA测试稳妥后，赶紧上线。这两天快被 PM 给逼疯了，天天在耳边说，赶紧上线赶紧上线。
到最后，独悦乐不如众悦乐，遇到问题就要会和大家分享一下。一方面给
提BUG，一方面在此码字，真是醉了。
最后，放上页面完整代码，并附上内存和CPU使用图表，有兴趣的同学可以在本机尝试一下，记住 chrome 的版本号是39.0.2171.71 m：
&!DOCTYPE html&
&meta charset=&UTF-8&&
&title&Chrome transition and transform scale bug&/title&
height: 600px;
width: 600px;
background: red;
.transform {
transform: scale(200);
.transition {
-webkit-transition: -webkit-transform .25s cubic-bezier(0, 0, .25, 1);
-moz-transition: -moz-transform .25s cubic-bezier(0, 0, .25, 1);
-o-transition: -o-transform .25s cubic-bezier(0, 0, .25, 1);
transition: transform .25s cubic-bezier(0, 0, .25, 1)
&a href=&javascript:& id=&a1&&点击我，测试页面是否相应？&/a&
&div id=&a1Test&&&/div&
var clickedTimes = <span style="background-color: #f5f5f5; color: #;
document.getElementById(&a1&).addEventListener(&click&, function(){
clickedTimes++;
document.getElementById(&a1Test&).innerHTML = &你一共点击了 & + clickedTimes + & 次！&;
}, false);
&div class=&div transition& id=&d1&&
&img src=&http://webrd01./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1685&y=775&z=11&&
&img src=&http://webrd02./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1686&y=775&z=11&&
&img src=&http://webrd02./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1685&y=776&z=11&&
&img src=&http://webrd03./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1686&y=776&z=11&&
&img src=&http://webrd04./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1685&y=774&z=11&&
&img src=&http://webrd03./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1687&y=775&z=11&&
&img src=&http://webrd01./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1686&y=774&z=11&&
&img src=&http://webrd01./appmaptile?lang=zh_cn&size=1&scale=1&style=7&x=1684&y=776&z=11&&
setTimeout(function () {
var d1 = document.getElementById(&d1&);
d1.classList.add(&transform&);
}, <span style="background-color: #f5f5f5; color: #00);
setTimeout(function () {
var d1 = document.getElementById(&d1&);
d1.classList.remove(&transform&);
document.getElementById(&d1&).classList.remove(&transition&);
}, <span style="background-color: #f5f5f5; color: #00);
CPU和内存占用情况：
阅读(...) 评论()移动端动画的效率问题
时间： 15:56:32
&&&& 阅读：498
&&&& 评论：
&&&& 收藏：0
标签：最近工作很忙，好久没有发帖了。前些日子跳槽到一家新单位就接到了一个很难的工作项目。在这个项目中技术核心点是动画效率问题。经过了近半个月的攻关各种难题总算是搞定了。同时，对移动端浏览器对动画的解析能力有了一个更高的认知。在这里想和大家分享一下。有不足之处欢迎指正！做移动前端的盆友应该都知道，动画特效方面，尤其兼容安卓系统，就和互联网端兼容IE6一样麻烦。好多效果不错的创意都因为不兼容安卓系统而夭折。归根到底还是因为安卓浏览器性能的问题。这里篇外话一下，安卓手机的硬件可以甩苹果一条街。但在浏览器上表现的则相反。现在安卓系统已经发展到android 4.X了.可分配给浏览器的内存还是少的可怜！貌似不足10%; 所以一些很流畅的动画效果在IOS上跑一点压力没有。但在android上跑卡的要命！希望android 5.0时可以多给点内存在浏览器上，尽量提升一下浏览器的性能比。言归正传，在移动端动画效果上，使用css3动画要比jquery动画效率高的多。在安卓手机上表现尤其明显！所以移动端动画以css3动画为优先。我们知道css3动画分为两大类： animation和transform，这两者根据实际项目需求来分别使用。前者为关键帧动画，后者为变换动画。关键帧动画多用于可循环动画。而变换动画多用于一次性动画。当然这也不是绝对的。两者是可以相互转换使用的。究竟这两者在移动端那个更省浏览器性能，我参考了大量的文档也没有得出什么结论来。总之个人认为差不多吧。关键还是代码写的是否合理。方法是否应用得当。通过做这个实际项目的大量效果测试得出一些自己的观点。大家仅供参考。第一，先说说transform：比如有一个需求，我需要将一个整体元素从下至上移动到屏幕上，这里有很多办法来加以实现。举例：要想让一个元素动起来，我们需要给这个元素先加一个原始的动画样式；#erjidiv{position:&width: 100%;&heigth:600top: 0&left: 0&&-webkit-transform:translateY(100%);&&-webkit-transition:-webkit-transform 0s 0s;}然后通过某些事件接口修改这个样式即可$("#erjidiv").css({& &&&"-webkit-transform":"translateY(0%)",& &&&"-webkit-transition":"-webkit-transform 0.5s ease-out 1s",})这样通过位移Y轴translateY的方式.延迟1s 由快变慢的方式完成了动画。在互联网中运用的CSS3样式。大家很习惯都使用 "-webkit-transition":"all 0.5s ease-out 1s",但在移动端为了性能问题不推荐这么做。all所包含的是所有属性。如果只是某一处只运用了该动画的话。那么没有什么太大的区别，至少肉眼看不出来。但如果在同一时间实行多处元素动画的话。使用all属性就会有卡顿现象。而只写改变某个属性的话则该现象基本可以杜绝了。尤其在安卓上表现明显。所以此处我只使用了-webkit-transform属性。有童靴会问，我改变其top的坐标值不是一样可以移动嘛；比如这样：#erjidiv{position:&width: 100%;&heigth:600top: -600&left: 0&&-webkit-transition:top 0s 0s;}$("#erjidiv").css({& &&&"top":"0px",& &&&"-webkit-transition":"top 0.5s ease-out 1s",})是的，这样依然可以达到该效果。但这么做显然在动画效率上不高。我参考了一些文章，说这么做效果还不如jquery动画效率高。这点我没有拿jquery动画和这个比较过。但这个和前者比较过。确实从流畅度来讲不如前者。尤其是同一时间多个元素同时执行动画。另外，像top、left、width、height等这些css基础属性在移动端不到迫不得已的情况下还是少参与动画的好。真的是很影响动画效率。我们使用css3的-webkit-transition的方式来做动画。与其门当户对配合的也应该是css3的属性-webkit-transform，两者完美结合才能在最大程度上提升动画效果。降低浏览器内存损耗。此外，有童靴很可能使用互联网做动画的方式来做移动端动画（以前我也这么干过&&）比如一个元素在静止状态时，采用了样式A。当它:hover时采用样式B。这样就实现了动画。把这种制作动画的方式搬到移动端一样也是可以的。其原理无非是两个样式的切换。那么根据这个原理上面的需求还可以变成这样：.style1{position:&width: 100%;&heigth:600top: 0&left: 0&&-webkit-transform:translateY(100%);&&-webkit-transition:-webkit-transform 0s 0s;}.style2{position:&width: 100%;&heigth:600top: 0&left: 0&&-webkit-transform:translateY(0%);&&-webkit-transition:-webkit-transform 0.5s ease-out 1s;}$("#erjidiv").removeClass("style1").addClass("style2");这样，通过移除和添加样式也可以实现上面的需求。那么这种办法是不是效率也比较高呢？通过实际测试，当多个元素同时动画的时候。使用修改其样式也就是第一种办法要比这种添加和删除样式高效的多。所以，如果使用-webkit-transform这种动画方式的时候，最好的方案就是第一种，使用js修改其动画样式的效率是最高的。其他的方法效率都不高。不推荐在移动端上使用。第二，再说说animation：严格意义上来讲。transform方式不算是动画。只能算是变换。而animation才是正宗的动画。使用animation方式做动画，我们不得不提到关键帧@-webkit-keyframes。通过对其起始状态和终点状态之间的过程设置来形成动画。关于关键帧动画的使用就不举例说明了。百度一下有很多。animation动画我个人理解多用于循环动画的地方。在这种动画需求下使用效率是最高的。优点是可以任意添加动作状态。缺点个人认为是不易进行控制。最大的缺陷是使用js无法获取到关键帧里面的动画状态参数。我想动态的改变关键帧里的变化数值，但无法做到。这里面的值只能写死或是使用百分比来代替具体数值。在移动端各种适配的需求下。很难有太灵活的变化。不过好像有js插件可以写关键帧动画。但我由于时间问题，还没有这方面的详细研究。如果哪位同仁有这方面的经验，可以赐教一二。之所以说它不易控制是没有一个好的启动切入点。目前我所知的办法就是当我要启动一个关键帧动画的时候，我需要给这个元素临时添加一个样式。这个样式里写入了引用关键帧动画的-webkit-animation-name：XXX，然后设置周期、播放次数、变化方式等等参数。比如：.fangda {-webkit-animation-name:-webkit-animation-duration: 1s;-webkit-animation-timing-function: ease--webkit-animation-iteration-count:}@-webkit-keyframes fangda {&&0% {-webkit-transform:scale(1,1)}50% {-webkit-transform:scale(1.2,1.2); }100% {-webkit-transform:scale(1,1); }}$("#erjidiv").addClass("fangda");这样当我给元素添加样式后，动画开始启动。这种方法其实又回到了刚才在谈到transform方式时的用到的第三种方法。当我一瞬间同时使用好几个关键帧动画时，使用这种添加的方式没有修改其样式的效率高。会造成一瞬间卡顿的现象。这个尤以在安卓系统手机上表现明显。但第一种方法可以使用JS修改其样式。而关键帧动画却修改不了。后来为了提高性能。想到不如先把样式加上。但我先让其暂停。想让它运行的时候再使用，于是乎想到了关键帧动画里有animation-play-state这个属性来控制暂停和运行。测试后果然可以。测试系统（android4.0以上，IOS6以上）。通过对比这种控制暂停，然后再让其启动的方式比单一添加样式的效率高很多。.fangda {-webkit-animation-name:-webkit-animation-duration: 1s;-webkit-animation-timing-function: ease--webkit-animation-iteration-count:-webkit-animation-play-state:}@-webkit-keyframes fangda {&&0% {-webkit-transform:scale(1,1)}50% {-webkit-transform:scale(1.2,1.2); }100% {-webkit-transform:scale(1,1); }}$("#erjidiv").css("-webkit-animation-play-state","running");//根据需求再启动通过以上的修正可以大大提高css3动画在移动端浏览器上效果的提升。即便在安卓浏览器上也能有较好的体现。最后，再说说其他方面的个人心得；考虑到移动端浏览器性能问题。尽量避免同时多个动画。关键帧动画不用时，要么暂停掉。要么直接删除样式。个人更倾向于后者。有时候为了提高流畅度。必要时还要打开其渲染3d功能。在全局样式中进行设置如下样式：-webkit-transform-style:preserve-3d;-webkit-backface-visibility:-webkit-transform:translate3d(0,0,0)另外，浏览器在加载过程中会有一个预存渲染功能（专业术语叫什么忘记了，个人命名的便于理解），就是当要触发某些动画样式的时候，最好浏览器事先有过渲染，这样在执行起来的时候就会更加流畅。（因为节省了渲染时间）这也就很好的解释了为什么采用添加的方式没有改变其样式效率高！不添加动画样式时。浏览器事先是没有渲染的。添加时它需要临时渲染再执行动画，这需要时间。而改变样式却是在浏览器事先已经渲染好了动画，只不过不执行或是在暂停状态。需要时就可以马上启动。所以正是因为有了这个预存渲染的功能。再采用合适的方式时，就能缩短浏览器渲染时间，减少卡顿现象的产生的可能！真正的做到了提高移动端浏览器css3动画的效率问题！
& &-转自（前端网W3Cfuns-作者：oceanjauh）标签：
&&国之画&&&& &&&&chrome插件&&
版权所有 京ICP备号-2
迷上了代码！问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
测试用机是米3。做的一个场景动画，iphone4下都很流畅，而安卓机跪了，尤其集中在面积较大的动画执行上，米3惨不忍睹，MOTO G稍微好一点，大家有什么好建议吗
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
按下面顺序优化一遍吧：
是否导致layout
如果是，尽可能将动画元素absolute化以避免影响文档树，造成大面积重新计算layout。
是否启用硬件加速
“用到了CSS3动画”和“开启了硬件加速”是两件事情，虽然前者有可能导致后者。
开启硬件加速在webkit中有神奇的万金油：opacity: 1;或者-webkit-backface-visibility:。
是否是有高消耗的属性（css shadow、background-attachment: fixed等）
有的话，图片也是一种选择。这算得上是用空间换时间的优化了。
repaint的面积
如果是，只好缩小动画面积了。这一步的优化有限，基本上还是依赖于上面三者
翻墙读一下吧：
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，解决技术问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
一线的工程师、著名开源项目的作者们，都在这里：
获取验证码
已有账号？经验5546 米
在线时间320 小时
版本7.9.21
积分 6001, 距离下一级还需 13999 积分
积分 6001, 距离下一级还需 13999 积分
机型小米平板2
签到次数152
MIUI版本7.9.21
具体哪个版本以后出现的这个问题，我不记得了，最近两周用自带浏览器在线看土豆网的火影忍者总是一卡一卡的，而且打开浏览器观看视频的时候机器发热量很大。也试过别的浏览器，QQ的 海豚的 都是支持FLASH播放的浏览器。问题都一样，不知道还有别人跟我一样吗？
分享到微信朋友圈
打开微信，点击底部的“发现”，使用 “扫一扫” 即可将网页分享到我的朋友圈。
经验1480 米
在线时间96 小时
版本3.4.12
积分 1643, 距离下一级还需 357 积分
积分 1643, 距离下一级还需 357 积分
机型索爱LT18i
签到次数16
MIUI版本3.4.12
经验5546 米
在线时间320 小时
版本7.9.21
积分 6001, 距离下一级还需 13999 积分
积分 6001, 距离下一级还需 13999 积分
机型小米平板2
签到次数152
MIUI版本7.9.21
好像还没有人反应过这个问题
经验2744 米
在线时间110 小时
版本V8.5.4.0.MADCNED
积分 3583, 距离下一级还需 1417 积分
积分 3583, 距离下一级还需 1417 积分
机型小米Note2
MIUI版本V8.5.4.0.MADCNED
重新刷机看看
经验5546 米
在线时间320 小时
版本7.9.21
积分 6001, 距离下一级还需 13999 积分
积分 6001, 距离下一级还需 13999 积分
机型小米平板2
签到次数152
MIUI版本7.9.21
经验6424 米
在线时间584 小时
版本V8.2.3.0.MAHCNDL
积分 7764, 距离下一级还需 12236 积分
积分 7764, 距离下一级还需 12236 积分
机型小米MIX
签到次数225
MIUI版本V8.2.3.0.MAHCNDL
看看优酷上有没有吧，小米手机看优酷是直接看html的视频，比flash对资源的消耗要少很多。
“他们很容易就忘记了这一点，正如他们希望别人善待自己，但自己完全不懂如何善待别人。”
http://t.cn/hb1HUn
经验5546 米
在线时间320 小时
版本7.9.21
积分 6001, 距离下一级还需 13999 积分
积分 6001, 距离下一级还需 13999 积分
机型小米平板2
签到次数152
MIUI版本7.9.21
优酷 土豆 看 都卡，因为要看火影忍者所以只能在浏览器上看~~~~
感恩节勋章
参与回帖活动
MIUI七周年
MIUI 9纪念勋章
新版论坛APP
更新新版APP
“澎湃S1 ”芯片纪念勋章
参与活动回帖可得
1000万用户纪念勋章
MIUI1000万用户纪念勋章
已关注微信
关注腾讯微博
已关注腾讯微博
关注新浪微博
已关注新浪微博
MIUI 100周
100周发布纪念勋章
已关注极客秀微信
Copyright (C) 2017 MIUI
京ICP备号 | 京公网安备34号 | 京ICP证110507号