除非另外注明，否则，下面介绍的更改均适用于最新 Chrome Beta 渠道版（Android、Chrome 操作系统、Linux、Mac 和 Windows）。
HTTP 密码和信用卡页面的“Not Secure”警告
为帮助用户安全地浏览网页，Chrome 通过地址栏中的一个图标指示连接的安全性。过去，Chrome 未将 HTTP 连接明确标记为不安全。从 56 版开始，Chrome 将把收集密码或信用卡信息的 HTTP 页面标记为不安全页面，这是将所有 HTTP 网站都标记为不安全网站的长期计划的一部分。该功能将在未来几周逐步推出。
为避免被标记为不安全，网站应使用 HTTPS 保护流量的安全并遵循一般安全性指导原则。
访问采用 HTTP 连接的网站时在 Chrome 网址栏中出现“Not Secure”警告
网络蓝牙
网站现在可以利用 Web Bluetooth API 在 Android、Chrome 操作系统 以及 Mac 上与低功耗蓝牙 (BLE) 设备进行交互。Web Bluetooth API 采用 GATT 协议，网站开发者只需编写几行 JavaScript 代码，便可连接到打印机和 LED 显示器等蓝牙设备。网络蓝牙还可与实物网信标相结合，用于发现和控制附近的设备。更多chrome资讯：www.yangfenzi.com/tag/chrome
作为入门指南，请查阅 GitHub 上的这些示例和演示：
googlechrome.github.io/samples/web-bluetooth/index.html
github.com/WebBluetoothCG/demos
CSS position: sticky
Chrome 现在支持 CSS position: sticky 这种全新的元素定位方式。position: sticky 元素采用相对定位，但会在用户到达某个滚动位置时变为 position: fixed。
在之前的版本中，如果希望构建的内容标头可在固定到视口顶部前保持正常滚动，就需要侦听滚动事件，然后按指定阈值将元素的定位方式从 relative 切换到 fixed。这种方法难以同步，因此视觉效果上的改善不大。现在，用户只需将元素以 sticky 形式进行定位，便可获得想要的效果。
此版本中的其他特性
- Android 上新增的 Remote Playback API 可让网站在智能 TV 和音响设备上启动和控制 HTMLMediaElement 的播放。
- WebVR API 在 Android 上以来源试用版形式提供，让开发者能够在网络上打造虚拟现实体验。
WebGL 2.0 API 默认情况下在桌面设备平台上处于启用状态，能够通过 < canvas > 元素提供 OpenGL ES 3.0 级别的渲染能力。 - 如果用户未与网站进行大量交互，navigator.plugins 和 navigator.mimetypes 中就不再公布对 Adobe Flash 的支持，但用户可单独针对某个网站重新启用 Flash 体验。
- 网站现在可以利用图像采集来源试用版拍摄照片以及配置缩放之类的相机设置。
- 现在，当内容发生变化，溢出到视口之上时，除非已设置 CSS overflow-anchor 属性，否则，Chrome 将会自动调整滚动位置，使内容在视口中保持固定。
- Notifications API 现在允许网站通过设置 image 属性在通知中加入图像。
- PaymentRequest API 具有各种新特性，包括 requestPayerName 和 JSON 串行化。
- 在移动设备上显示和隐藏网址栏时不再对使用 vh 等视口单位进行过尺寸调整的初始包含块或元素进行尺寸调整。
- 现在，在内存至少达到 512 MB 并具有系统词典的 Android 设备上，默认情况下将为 < input type=”text” /> 之类的文本输入元素启用拼写检查。
- 现已将用于让内容适应 UI 的通用字体系列标准化，并在所有平台上重命名为 system-ui。
- 新增的 Referrer-Policy HTTP 标头允许网站在不泄漏用户会话标识符或其他私有信息的情况下按网址转发网站流量。
- KeyboardEvent.isComposing() 让网站无需直接监控键盘事件，只需根据近期 KeyboardEvents 便可确定用户是否正在键入内容。
- 现在，使用蜂窝网络连接时，Chrome（Android 版）会将视频的默认 preload 属性设置为 metadata，从而显示预览图像和时间信息以匹配其他移动浏览器。
- Chrome 现在支持 TLS 1.3 并加入了基于 draft-18 的 1-RTT。
- 网站可以利用 ImageBitmapRenderingContext，通过以 ImageBitmap 形式渲染像素数据来减少内存消耗和合成开销。
- 网站可以利用pinch-zoom CSS touch-action 属性响应双指张合手势。
- ConstantSourceNode 是一个新增的音频源节点，可产生混合了 AudioParam 的恒定输出。
- Web Audio ChannelSplitterNode 接口新增了两个只读属性：channelCount，由 numberOfOutputs 在 createChannelSplitter() 中定义。
- PannerNode.rolloffFactor 现在固定在 PannerNode 距离模型的标称范围内，以描述在音源远离收听者时的音量下降率。
- 页面当前未处于前台时，window.prompt() 将不再让其上级标签获得焦点。
- 为与 Windows 上的行为保持一致，Chrome 扩展程序现在会在 Mac 上通过 Chrome Settings Overrides API 替换默认的搜索、启动和主页设置。
弃用和互操作性的改善
- WebAudio API 不再包含弃用的 Doppler API，包括 speedOfSound、dopplerFactor 和 setVelocity。
- 为改善标准性能，RTCPeerConnection 现在接受 iceTransportPolicy 以及 iceTransports 作为 RTCConfiguration 参数。
- 现在提供的 RTCPeerConnection 将不带 webkit 前缀，但仍保留 webkitRTCPeerConnection。
非空格 Unicode 控制字符现在将按照规范进行渲染，而不会被忽略。 - reflected-xss 指令已从 Content Security Policy 2 中移除，因为它只是 X-XSS-Protection 标头的包装器，不提供其他功能。
- 已取消对 MediaStreamTrack.getSources() 方法的支持，由 MediaDevices.enumerateDevices() 取代。
- 不再支持 CSP referrer 指令，由新增的 Referrer-Policy 标头取代。
- ShadowDOM 的 slotchange 事件会冒泡，但不再按 slot 的 assignedSlot 重新触发。
- 旧版 CBC 模式 ECDSA 加密套件 ECDHE_ECDSA_WITH_AES_128_CBC_SHA 和 ECDHE_ECDSA_WITH_AES_256_CBC_SHA 已移除，由 ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 之类的现代加密套件取代。
- 已移除同时使用 SHA-1 和 SHA-512 的 ECDSA，以减少对 SHA-1 的依赖，以及与 TLS 1.3 全新的 ECDSA 处理方式保持一致。
- Chrome 不再允许在代表触摸滚动（例如 touchstart 和 touchmove）的输入期间打开弹出式窗口。
网站不再启动对具有无效 type 或 language 属性（例如 type=”python”）的脚本的获取，但由使用link preload 的声明性获取触发者除外。 - MIDIMessageEvent.receivedTime 已弃用，由 Event.timeStamp 取代，因为 Event.timeStamp 现在支持使用高分辨率单调时间替代公元纪年时间。
（文｜Google 网络蓝牙矫正师 Vincent Scheib）
————————————— 氧分子网延伸阅读 —————————————
Android Wear 2.0中国版 – 开发者预览版发布！
在上海举办的 Google 开发者大会上，我们正式宣布了一款专门针对中国市场的 Android Wear 2.0 开发者预览版。Android Wear 2.0 系统，将是自我们的合作伙伴首次发布手表产品以来最重大的更新。
开发者预览版已于12月15日正式上线。与此同时，我们也计划在未来的几个月内持续进行更新。
请您将您遇到的问题在此提交反馈：
g.co/wearpreviewbug
或者在我们的 Android Wear 开发者论坛发表意见：
plus.google.com/communities/113381227473021565406
为中国市场开发应用
在 Android Wear 2.0 系统中，应用可以由 Android Wear 手表直接连接至互联网。因此，对于大多数应用来说，手机端的伴侣应用也就变得不再必要。这也意味着，多数为 Android Wear 2.0 开发应用的开发者将不再需要引用 Google Play services 客户端库。
目前，在两个情况下开发者仍然需要引入 Google Play Services 客户端库来为中国市场开发应用：
- 需要与手机直接进行通信的应用 – 有一些用例需要 Android Wear 手表与已配对手机直接连接。在这种情况下，Android Wear 1.0 中引入的 Data Layer API 仍然可以继续使用。
- 使用 FusedLocationProvider – 我们在最新的中国版 SDK 中加入了定位的支持。在用户的许可下，您的应用可以通过 FusedLocationProvider 来接收定位更新。
您可以在这里找到关于如何引入与中国版兼容的 Google Play service 的更多信息:
developer.android.google.cn/training/wearables/apps/creating-app-china.html
Android Wear 2.0 中国版产品测试
Android Wear 2.0 开发者预览版包括最新的 SDK 套件，手表测试系统镜像（基于华为手表）。
情按照以下步骤进行测试：
- 更新到 Android Studio 至 v2.1.1 以上版本
- 访问 Android Wear 2.0 开发者预览版，那里的文件下载与文档下载部分: developer.android.google.cn/wear/preview/index.html
- 下载手表系统镜像: developer.android.google.cn/wear/preview/downloads.html
- 在手表上测试您的应用
（文｜ 林海泉, Android Wear 开发平台负责人）
·氧分子网（http://www.yangfenzi.com）延伸阅读：
首先是系统方面的改进，在通知方面，Android Wear 2.0可根据信息的不同特性调整不同的背景色，以此提高使用者对信息的区分以及处理的效率。此外，通知的方式也将再次改良，它会在第一次抬起手后显示一段 时间，紧接着就会自动消失，保证操作界面的整洁。同时，谷歌也保持了以前的操作系统，用户可从底部上滑调出卡片，而且当需要回复信息的时候，你会发现除了 原有的语音、涂鸦（emoji）方式外，Google 还在新版本里加入了智能回复、手写辨识，以及一整套英文全键盘。（谷歌的意思是，如果你疯了，你还可以在表盘上用全键盘进行输入…）
同时，谷歌表示以上的所有输入方式都将会以机器人学习方案作为底层，其的智能回复的工作原理大概也还是基于谷歌助手，与Allo一致，可以针对部分信息提 供你即将会用到的那些快捷回复，如果都不适用，你还是可以选择全键盘输入的。（简单的说，就是一个基于机器人学习方案的词句联想方案）
在系统 UI 的操作方案中，Google 改进了上滑和下滑的手势。当你在应用内从顶部下拉的时候，会看到一个「wearable navigation drawer」，在里面你可以直接跳转到某个专门界面。而从下往上滑，则会调出「action drawer」，在这里你能找到对应不同功能的各类按钮。
至于应用方面，谷歌优化了Android Wear的应用交互方式。举个例子，基于Android Wear 2.0系统的手表可依靠 Wi-Fi 或 LTE来完成数据传输，如此一来不需要离线下载歌曲也可进行音乐的播放。
至于运动方面，谷歌加入了运动识别的全新API，这个改善能够使手表更好地判断你的运动状态从而进行更精准的记录，举个例子，在可识别的状态下，手表可以记录下你运动的时间、跑步的距离甚至是跑步的节奏。所谓可识别状态，目前这个 API 在初期似乎只支持识别步行、跑步和骑行状态。
最后，Google 还介绍了另一个能让第三方应用在表盘上显示自定义内容的 API。也就是说，用户如今可以更顺心地使用自定义的第三方表盘，与Android手机的主题一致，大量的第三方表盘估计能提供更优良的体验。
先从市场的角度分析，谷歌带来了Android Wear2.0。这离第一代智能手表操作系统发布已经过去两年有余。早已失去了市场先机！
既然已经失去了市场，那就得有拿得出来的产品。下面来分析一下产品有哪些创新点：
1、Android Wear2.0在操作系统方面也也沿用了谷歌在手机操作系统中的设计要素。
2、对手表的操作系统进行优化，如重新设计图标排列方式，让其更适应圆形的显示界面。
3、智能手表的人机交互方式也得到了改善。此前我们是通过左右滑动来找到我们需要的应用，但现在你只需按住手表旁的机械按钮，应用程序便会以轻微的弧线向你展示。
Android Wear2.0允许大量第三方应用同时在屏幕上显示。比如，现在用户可以在一个操作界面上对Spotify和Google Fit进行操作。
4、还有在通知功能方面做得一些优化！让消息通知显得更加简洁！
个人观点：
智能手表在市场上反应一直不是很好，苹果Apple Watch上市之前曾经被高度期待，但是发布之后却没有想象中那样惊人，甚至有不少机构唱衰这款产品，的确智能手表现在还是有点鸡肋，苹果的Apple Watch也没有能展现出特别之处。
能实现的功能手机上都能更好的实现，小屏幕也不方便操做！
静观智能穿戴设备的日后发展！
从公布的android wear 2.0特性来看，主要变化在这几个方面
1.增强了消息的互动
在当前的1.0版本中，消息往往隐藏在页面底部的扩展面板。现在，当你的手表有消息提醒时，你会看到消息全屏，你可以马上进行回复最大的变化是你如何回复消息。例如之前，你必须划到一边来回答。现在，你只需轻按消息，Wear就会出现一个小的应用程序，显示了更多的数据和可能采取的行动。
除了现有的语音和表情符号的答复，团队还加入了三项新功能。就像用Gmail收件箱一样，你现在可以使用谷歌的智能回复，它使用的是机器学习，针对新消息自动为你提供三种可能的答案。
2.支持键盘输入
一直以来，手表缺乏有效的文字输入方案，鉴于这些手表的尺寸，我们所说的是超小的键盘，所以它的功能仍有待观察。
3.手写输入
2.0另一个新功能就是手写识别，表现完全满足你预期。你可以写一个字母或一个完整的单词。该技术是基于谷歌为Android打造的手写输入工具。
4.增强健康统计功能
2.0增加新的健康平台活动识别API，例如它可以知道你是否正在行走，跑步或骑自行车。在此数据的基础上，手 表就可以自动启动合适的应用。例如，你开始跑步，它会自动启动打开Nike+ Running。
这听起来是一个很方便的功能，因为它可以节省你打开程序的几个步骤，并确保你更加严格地记录运动情况。
5.脱离手机
应用程序现在可以直接访问网络，不再需要经过手机。这意味着应用程序可以直接安装在手表上。降低了手表对手机的依赖性，虽然这可能会以损失手表的续航作为代价。同时也意味着使用ipone的用户也可以使用搭载android wear2.0的手表设备了。这是个很体现google公司价值观的特性，众所周知，apple是以打造闭环来创造价值，google则致力于开发创造更多价值。
总结来看，android wear 2.0体现了google一贯的做事风格，还是一个脚踏实地的优化版本，并没有带来更多爆炸性功能。
在大天朝，Chrome的体验当然是不能让它好的。
天朝对Chrome的干扰是全程覆盖的。
下载&安装：官网的下载器99.9%不能成功下载安装文件。怎么办呢？用下面教育版的MSI吧。
Chrome Web Store根本无法打开。即使是打开了，也是你等了2~3分钟以后。而且打开了，你也不一定能装的了一个应用。你能不能用，啥时候能用，得等多久，全由党妈妈亲手给你操办。还不谢谢人家~
书签同步：间歇性干扰。开2B会的时候就别想用了。
网页翻译：似乎是http://apis.google.com会受到一些干扰，导致有时候会只翻译到一半就卡住，或者直接翻译不能。
新标签页有谷歌搜索：请在“设置-搜索”里把谷歌改为其它的搜索引擎。
新标签页的 thumbnails 不能自定义：这是真的，但是你可以安装扩展来自定义，比如 Speed Dial 2。
chrome://settings/passwords 的密码明文显示：请确保 Chrome 是最新版本，并且给 Windows 帐户设置密码。
内存占用太大：的确，但是这也是为了提高渲染性能。对于内存小的用户是硬伤，但是现在内存那么便宜，你就买多一条吧。
双击不能关闭网页：的确，不过可以用鼠标中键单击。推荐使用 StrokesPlus，有了它你就不再用去找鼠标点哪里关闭了，任何时候都是一个手势。
不能恢复关闭的网页：方法一：“菜单-最近打开的标签页-最近关闭的标签页”；方法二：快捷键“Ctrl+Shift+T”；方法三：安装 Vimium 自己定义吧。
无法固定标签页：方法一：“右键标签-固定标签页”；方法二：安装 Vimium 自己定义吧。
兼容不好：我觉得这个逻辑好像反了…
大的方面都差不多是因为这两个浏览器都遵循W3C标准，对于HTML代码和CSS代码有着高度一致的表现方式（在一些小的地方还是有差异）。这样做的目的就是为了减低网站建设的成本，只要网站遵循W3C标准制作，那么就可以确保在不同的浏览器上面都达到同样的效果，而不需要为不同的浏览器编写不同的代码。而微软的IE浏览器因为历史原因，IE6、7在遵循标准方面做得很差，在IE8开始逐步改善，目前IE10和IE11已经有了很大的进步。
Mozilla基金会的Firefox浏览器的目的和Google开发出Chrome浏览器的目的是不一样的，这是这两个浏览器的第一个不同点。
Mozilla基金会（注意，这是一个非营利机构，其下属有一个Mozilla公司，是商业公司）的目的是让浏览器市场保持着竞争的压力，不会再出现像IE6时代这样一家独大的，用他们自己的说法就是“一个致力于在互联网领域提供多样化选择和创新的公益组织”。
Google开发Chrome则是为用户提供一个更好使用Google服务的环境。Google的搜索、地图、邮箱、文档、网盘等等产品，都是基于网络的，如果用户没有一个很方便很快的浏览器，毫无疑问会阻碍用户使用Google的服务。因此，Google除了自己开发Chrome，还有维护一个开源的项目Chromium，鼓励其他商业公司加入。还用Chrome OS，最终的目的都是为了让用户更容易使用Google的服务。
在功能上，这两家浏览器也是各有侧重。Firefox追求可定制性，Chrome则是追求浏览速度。
Firefox有很强大的扩展功能（注意，对于Firefox，增强功能的附加程序叫做“扩展”（add-on），而不是“插件”（plug-in））。通过扩展程度，用户可以很容易地定制Firefox，为其添加各种功能、改变浏览器的行为方式、改变浏览器的外观等等。
为了要支持扩展，老版本的Firefox牺牲了启动速度。虽然什么都没安装的Firefox启动挺快，但是如果用户安装了很多扩展（夸张的用户会装几十个甚至上百个扩展），那么Firefox启动就好花很长的时间（数十秒计，在比较老的电脑可能要以分钟计）。在新版本的Firefox（从Firefox4开始）开始，Firefox在不断改善启动速度。现在新版本的Firefox（比如Firefox20+）在启动上已经快了很多。
Chrome则是走浏览路线，它虽然也支持扩展（extension），但是对于扩展的放权远远无法和Firefox比，无法像Firefox那样通过扩展把浏览器改头换面。当然，毫无疑问，多数用户没有这个需求。
因为Chrome的主要使命是让用户更好地访问Google服务，因此Chrome：
追求界面简洁：用户不需要在浏览器上追求什么，他们的需求由Google服务满足。Chrome的很多高级设置都是隐藏起来的。
追求启动速度：如果用户想要看一下邮件，你最好马上就能打开。
追求运行速度：Google的网络服务是一个在网上运作的程序，而不是简单的页面，要和用户做很多互动，而这些功能对浏览器有依赖。所以Chrome的处理能力要足够强，不能让用户点了页面上的按钮半天都没反应。
追求稳定性：Chrome中的每个标签页都是一个独立的进程，某个页面崩溃了，其他页面都不会受到影响。如果用户正在用Google的在线文档写一个重要的文档，然后想查一下地图，接着地图挂断了，顺带也把用户的邮件页面用挂了，后果就会很严重。就算在线文档有自动保存，也会让用户觉得很不爽。
因为Chrome已经能够满足很大部分用户的网上需求，所以很快就开始动摇了IE和Firefox的地位。而浏览器商也被迫在性能上追赶Chrome。比如加快启动速度、加快运行javascript的速度等等，这些都是Chrome出现后的事情。也因为浏览器的性能快速提升，网站也可以做得越来越强大。
经过这些年的发展，Firefox和Chrome的最明显差异还是在扩展上面。
Firefox有着多年积累的强大扩展资源，加上自身对扩展的放权，有很多Chrome上无法实现的扩展。典型的如界面修改的扩展，比如Chrome刚出来的时候，无标题栏很惊艳，Firefox通过扩展可以把界面修改得和Chrome一样：把标签页弄到顶部、隐藏标题栏等。而你想要把Chrom弄成Firefox那样就不行了。可见Firefox的自由度。这些扩展一直吸引着一部分有独特需求的用户不放弃Firefox。
但是，正如上面说的，有这些需求的用户毕竟不算多数，因此很多仅仅是不想用IE的用户，都改用了简洁的Chrome，而不是选择复杂的Firefox。
firefox的复杂是因为你想去装扩展,安装上直接就用了,哪里来的复杂.2、chrome缺少关键的tabmix扩展.3、同样打开几十个页面chrome卡死,firefox切换依然很流畅,同样打开几十个页面chrome占用系统大量资源，firefox基本保持低占用量.4、浏览器、im等现在基本上是一天也就打开一次,讲启动速度实在太落伍了,倒不如拼标签切换速度,这一点chrome切换标签动不动就卡死的情况firefox后面的版本基本遇不到.
Chrome：内置Flash、翻译。可设置多个独立用户浏览器。（没有一定的技巧，国内应用商店打不开）
Firefox：可改造外观、调整位置、造型丰富。（应用商店可打开，简单设置好后反而没有chrome那么折腾）
启动：
Chrome：快
Firefox：较慢
搜索引擎：
Chrome：可输入常用的搜索引擎，浏览过的一些网站会出现在管理搜索引擎中的其他搜索引擎。
Firefox：设置里就默认几个搜索引擎，修改不了。添加其它要到附加组件里找，但在搜索栏方便切换(chrome也有优秀的扩展代替它)。
定制：
Chrome：可把浏览器的功能收藏的书签中快速打开。
Firefox：可移动一些菜单功能的位置。（定制性高，可对外观和位置进行大改造）
扩展：
Chrome：有很多优秀的扩展，而且分类较好，较易查找。
Firefox：找扩展较麻烦，没有chrome那么分类清晰，同样有优秀的扩展。
书签：
Chrome：书签效率高效灵活，书签栏中按住Ctrl可以连续打开（Firefox不能）
Firefox：书签有点繁琐，可添加分割条、关键词和描述。移动不够灵活，但移动书签栏后不会消失（chrome会）
不是隐身模式中不能用文件夹以隐身窗口中打开书签。
（火狐不适合用书签栏多开，是用侧边栏的，打开侧边栏固定不变，来直接切换书签或多开）
新标签：
Chrome：八宫格 （打开多标签闪瞎眼）
Firefox：不使用推荐页只有空白页，可用扩展New Tab Override或Stylish的样式来替换掉。打开过多标签页固定宽度，两边小箭头移动。
最后：两个都是不错的浏览器，各有优点、主用备用各选一个吧。
有了chrome不知道为什么还会有火狐浏览器的存在！
1、作为浏览器上网：火狐没任何优势，这导致了，我身边没有！没有！没有！一个人用火狐做为浏览器上网的！（骂我的人很多，但请你自己采访下周边的吃瓜群众）
2、作为开发工具：JS方面，v8吊打火狐！css方面，兼容性也比火狐好，html5方面，比火狐前卫的多。至于其他实用功能方面，火狐有的，chrome都有，至于谁的好，看习惯了，但使用火狐开发的人，一般都是10年前做开发时的古董级开发人员。
3、移动端：首先不管android还是ios的浏览器都是webkit，chrome移动端开发firefox方便太多，不服？我也不跟你撕！很多人抵触新事物我也不想改变你！
4、桌面应用开发：nw.js、electron，懂的人都懂，不懂的你来跟我撕。
5、外观：chrome简洁漂亮，火狐丑的一逼。
6、启动速度：chrome很快，火狐老版本呵呵呵呵呵呵呵呵呵，火狐新版本呵呵呵。
7、数据同步和用户量：chrome吊打火狐。
8、前景：知名度在那呢。。
9、其他：火狐完败！
10、总结：火狐完败！
按home键即可。老是退出退出，chrome和曾经的aosp浏览器除了同步的进程(aosp应该连这个也没有)外就没有额外服务了，同步服务你退不退它都会在系统调控下启动，你把chrome自动同步关了连这个东西都没有。
这时候，home键的效果是，进程转入缓存，ram低时就被系统释放，如果没被释放你再次打开速度还快。此外当前访问页面也不会清掉，下次可以接着看。需要开新页面也不算啥难事吧。而且缓存进程又不费电
满脑子退出、退出或者杀进程，如果不是还停留在android 2.3的印象里，就是被某些国产应用坑惨了
按home键和返回键的区别是，一个让应用停止，一个让应用摧毁。无论是哪个都不会继续占用资源。而停止应用在下次打开时直接从onStart方法开始调用，无需初始化，达到节约计算资源的优化目的。而摧毁要从onCreate重新初始化，再执行onStart，启动时间长是小事，反而更加耗电和卡顿。所以个人建议是，永远不要按返回键退出程序。
回到经典界面这个扩展下载量、排名飙升。在4月28日也就是 29.0 推送之前，Classic Theme Restorer几 乎没什么人用，每日下载量数据中显示9,132，但4月28日官方推送29.0后，这个自定义 29.0 界面的扩展就开始飙升达到每日下载量47,582次，下载量猛增至原来的5倍多，而且还在不断上升中。这也就意味着尽管用户升级了29.0但一部分人仍不 满意29.0的新界面，仍想回到29.0以前的界面中去。而还有一批，像我一样的仍在坚守28.0期待出个29.1来改进下。
接下来还有组官方的调查数据：2013年11月23日发表的博文：More than 80% are unhappy with Firefox’s Australis interface, Mozilla report states
80%的用户不满意Australis界面。
大部分用户不满意29.0的自定性。一个以自定性高著称的浏览器，大多数人竟然不满意其自定性？这个真的很嘲讽吧？
下面开喷
29.0官方宣传上一直在主推这个界面，而改进后的Firefox Sync却鲜少提及。主说其更加方便用户使用、更美观、吧啦吧啦……这一界面孕酿5年之久，期间一直有消息曝出，等了这么多年，黄瓜都等软了。用户从最初的期待到现在的不满，我想原因如下：
1. 太像Chrome！Chrome的出世并没有抢占多少IE的份额而是把Firefox的一部分份额抢占。一部分使用Firefox的用户对Chrome自定能力以及稍显“弱智”的扩展嗤之以鼻。本来就不喜欢Chrome的用户看了这界面自然心生不满之情。
2. 取消了附加组件栏、增加一个三条杠的汉堡图标，Firefox希望用户把不常用的扩展或UC脚本图标放进汉堡里，但这样带来的坏处就是会多一步操作，还得点开汉堡再点击自己想点的图标，稍显繁琐，原本附加组件栏存在时可以把东西全部放进附加组件栏，如果嫌占地方，还可以把附加组件栏放进地址栏里，即节省了空间，常用功能又一目了然，随点随到。有人会说如果我放工具栏里也一样啊，但从新界面来看Firefox增加了些图标，且取消了“使用小图标”功能，如果全放进工具栏里，本就拥挤不堪的工具栏那界面可想而知了，小屏电脑的噩梦啊。
3. 取消了App Button，最原始的Firefox并无App button曾推出时便遭到用户的反感，用户好不容易适应这个按钮后，往里面可以加些快捷方式：比如重启Firefox、UC脚本管理选项等，用户也是很 满意而且还可以把按钮改成自己想要的样式。取消后原本的功能没有一个新的方式去承载，用户自然不满。
4. 取消了“使用小图标”功能，我想说现在的屏幕越做越宽，一大部分人都想尽办法把天地空间增大，增加可视面积。使用小图标这是个最常用的方法，取消了我实在 是想不通啊，难道大点的图标更好看？那丑陋的倒三角图标就不可以改下吗？其实使用小图标并不是减小了图标显示，而是减小了工具栏的显示面积。
5. 将原本星星图标增加书签的按钮改成两个图标，两个图标中的一个功能原本可以通过双击星星图标来代替，所以这个又是个鸡肋。
6. 唯一值得称赞的就是改进了同步登陆方式。改进后的Firefox Sync取消了同步密钥这一反人类的方式，变成更为人性化的仅帐号登陆便可。但据大部分用户反应同步会出现问题比如ABP扩展的设置项。
1.如果你装了炫彩皮肤,基本上你是看不到标签项是圆角的还是钝角的,反正自打装了皮肤,就不太清楚是什么角了……
2.菜单的变化巨大,从左侧的单一菜单按钮,整合到右侧的单一菜单按键,菜单按键比以前更小,更难以发现,同时,我也认为FF为了网页浏览的时候使用者能够不被多余的项目所分散注意力而做出的改变.以前的FF按键是偏向于橙红色的(希望我不是有色盲).相当醒目.这个颜色即使在满屏状态下看视频和图片的情况下,都会有一种不断提醒你我在这里我在这里的感觉.
3.更自由的定制,我觉得这个完全是没什么可说的,以前的FF定制和现在相比,也是很自由的,只不过这次不通过额外扩展直接延伸到了菜单里.不过相比于学习Chrome,我觉得更偏向于Win8的扁平风格
最后的最后,我真不是话痨…界面的转变我觉得有两种主要的意义,
1.优化界面,用于提升效率
2.提升用户的新鲜度.从4开始到29,一直没有变化的界面,对于不喜欢折腾皮肤和主题的用户,难免会有一种审美疲劳,界面的改变最易于带给人一种新鲜和有活力的感觉.
firefox 29，对我来说，
优点：
1. 同步功能是最值得称赞的。只需要一个账号，所有扩展，设置不需要重装了，终于摆脱FEBE。
2. 以前的橘黄色图标太过醒目了，很容易分散注意力，这次终于不见了。
缺点：
1. 主菜单图标移动到了右侧： 这一设计绝对是firefox用户最不喜欢看到的！首先和chrome长的太像，令粉丝们反感。最重要的一点是，firefox图标一直是在左边的，突然出现在右边，这不是和用户习惯作对吗？等大家适应了菜单栏在右边后，是不是也就习惯用chrome了？
所以，我个人认为，三条杠的图标可以保留，但应该放在右侧。
2. 界面定制程度变低了。并不是所有人都喜欢把扩展图标放在上面的。为什么取消add-on工具栏呢？之前的界面定制，甚至可以将搜索栏放在diigo工具栏的，升级后不可以了。
3. 部分扩展不兼容了。
总体来说，同步功能改进，图标变小，我还是很喜欢的。配合Classic Theme Restorer扩展使用，我认为还是很不错的！最后也附上我的firefox界面吧：
首先是取消了附加组件栏这点，我是给好评的。
作为笔记本用户，为了节省珍贵的垂直空间，旧UI时我也是不开附加组件栏的。但是这样就不得不把需要用的的附加组件按钮全部放在地址栏上，导致地址栏非常拥挤。
现在有了这个三明治按钮，可以将不那么常用的附加组件按钮放在里面，地址栏舒服多了。
新的书签图标感觉影响不大。旧版的星星在地址栏里面，点起来确实不太方便。
至于标签栏像chrome，我觉得这根本不算个事。一定要纠结的话我觉得这个纯圆弧设计比原来的那个半圆不方的还稍微好一点。
圆角、直角、梯形只能说是喜好问题，功能性上没啥区别。【我个人还是喜欢opera的风格
新版本这么多差评其实也挺正常的。毕竟外观改动比较大，浏览器的外观变化一般都很难讨好，毕竟用户已经习惯了旧的UI，要重新适应新的。FF4、IE9的新界面，opera11.5的新快播界面最初出来的时候都是骂声一片，但是习惯了之后该用还是继续用。
这次只是新界面看上去和chrome有一点像，加上不少ff用户对chrome有着相当的优越感，反应特别大一点而已。
文 | IndexedDB 开发者 Victor Costan
除非另外注明，否则下面介绍的更改均适用于最新 Chrome Beta 渠道版（Android、Chrome 操作系统、Linux、Mac 和 Windows）。
IndexedDB 2.0
现在，Chrome 完全支持 IndexedDB 2.0 标准，在此浏览器中，可以更轻松地处理大数据集。IDB 2.0 采用新的架构管理和批量操作方法，故障处理方式也更标准化。
网站数据库的结构对性能的影响很大，而且很难改变。为简化更新操作，现在，在重构后，可以原地重命名对象存储和索引。网站也可以使用更多自然关键字，而无需担心性能受到影响，因为二进制关键字可压缩自定义关键字表示。
使用 getKey() 和 openKeyCursor() 方法，可以简化数据检索，在只需一个数据库关键字时，还可提升性能。使用新的 continuePrimaryKey() 游标方法，可以更轻松地分割跨事务、跨页面加载的大数据访问，而不必担心出现重复的主键。getAll() 和 getAllKeys() 方法无需使用游标，即可批量恢复整个数据集。
改进 iframe 导航
自动重定向页面的第三方内容（例如广告）可能给用户带来困扰，带来安全问题。因此，开发者可以将第三方内容置于沙盒化的 iframes 中，避免出现此状况。但是，在某些情况下，与标准广告类似，点击此类内容需要导航顶级页面。
为解决此问题，Chrome 58 现在支持新的 iframe 沙盒关键字 allow-top-navigation-by-user-activation。此关键字使沙盒化的 iframes 在用户交互操作触发时能够导航顶级页面，同时阻止自动重定向。
PWA 沉浸式全屏体验
当 Progressive Web App (PWA) 从 Android 主屏幕启动时，这些 PWA 会以一种类似于独立应用的模式启动，此模式下会隐藏多功能框。这有助于营造一种富有吸引力的用户体验，并释放屏幕空间，以显示更多内容。但是，对于游戏、视频播放器或其他富媒体内容等更沉浸式的体验，系统栏等其他移动 UI 元素仍然会分散用户注意力。
现在，PWA 可以在其网络应用清单中设置 display: fullscreen，在网站从主屏幕启动时隐藏非应用 UI，提供完全沉浸式的体验。
此版本中的其他特性
现在，工作线程和共享工作线程可以使用 data: 网址进行创建，通过为其赋予不透明的来源，可更安全地利用工作线程进行开发。
通过 PointerEvents.getCoalescedEvents()，开发者可以访问上次提交 PointerEvent 以来的所有输入事件，使绘图应用可以更轻松地使用精确的点记录绘制更平滑的曲线。
现在，开发者可以使用新的 ControlsList API，自定义 Chrome 的原生媒体控件，例如 download、fullscreen 和 remoteplayback 按钮。
对于 Chrome（Android 版），使用改进的添加到主屏幕工作流安装的网站将可以不受限制地自动播放通过清单范围中包含的来源提供的音频和视频。
对于 Chrome（Android 版），使用 autoplay 属性的视频在退出屏幕时将暂停播放，返回屏幕将继续播放，以保持跨浏览器的连贯性。
现在，网站可以使用 color-gamut Media Query，获取 Chrome 和输出设备支持的颜色的大致范围。
现在，无需手动重置 float 和 clear 等多种布局属性，网站可以使用 display: flow-root 添加一种新的块格式设置上下文。
为缩短 JavaScript 分析时间，SVGPoint、SVGRect 和 SVGMatrix 已转移至 Geometry 外部的新界面中。
使用新的 Selection API 函数 removeRange()，开发者现在可以通过编程移除指定的文本范围。
现在 Chrome（Mac 版）支持 PointerEvent.tangentialPressure 和PointerEvent.twist 属性，可为触控笔设备和绘画应用提供更多信息。
为简化开发者体验，现在 JavaScript 允许在形式参数和实际参数列表中使用终止逗号。
WebAudio API 新的播放AudioContextLatencyCategory 使开发者可以轻松地在延迟时间、功耗和 CPU 效率之间做出有意识的权衡。
弃用和互操作性的改善
Apple-interchange-newline、Apple-converted-space、Apple-paste-as-quotation、Apple-style-span 和 Apple-tab-span 已被弃用，因为它们是非标准 CSS 类。
usemap 属性现在使用区分大小写的匹配方式，而不使用兼容不区分大小写，以更好地符合相关规范。
现在，根据 Chrome 针对一些重要功能的政策，使用 Notifications API 请求通知权限或创建非永久本地通知时，网站必须使用 HTTPS。
为了更好地符合相关规范，现在当 cancelBubble 设置为 true 时被视为 stopPropagation() 的别名，在设置为 false 时则不执行任何操作。
VTTRegion 界面函数 addRegion() 和 removeRegion() 已从 WebVTT 规范中移除，因此也将从 Chrome 中移除。
导航至 data: 网址的顶级页面的功能已被弃用，以进一步防止用户受到欺骗和钓鱼式攻击。
HTMLEmbedElement 或 HTMLObjectElement 的实例不再可以作为函数调用，因为旧版调用程序已被移除。
在 IETF 将这些算法标准化为 RFC 7539 和 RFC 7905 以及随后在 Chrome 41 中发布标准版本后，移除了标准化前的 ChaCha20-Poly1305 密码。
为改善互操作性，如果增加的范围与现有范围重叠，Selection.addRange() 现在会忽略前者，而不是将两个范围合并。
根据 Chrome 针对一些重要功能的政策以及根据相关规范，已弃用通过不安全来源传输加密媒体扩展。
AudioBuffer 构造函数现在允许使用 AudioBufferOptions 词典的sampleRate 成员代替 context 参数，以简化界面，同时强调可以在 AudioContexts 之间共享 AudioBuffers。
现已在服务工作线程中弃用同步 FileReaderSync API，因为服务工作线程规范要求所有类型的同步请求都应在服务工作线程外部发起。
现在 abbr 和 acronym 元素默认添加点式下划线，以符合 HTML 标准。
现已移除 motion-path、motion-offset 和 motion-rotation CSS 属性，分别由以下新版本取代：offset-path、offset-distance 和 offset-rotate。
在访问 selectionDirection、selectionStart 和 selectionEnd 等 Selection API 属性时，Chrome 原本会引发 InvalidStateError DOMException，但现在返回 null。
现在，Selection API 的 setBaseAndExtent() 不会在无提示的情况下限制过大的偏移值，而是引发 IndexSizeError DOMException，以更好地符合相关规范。
现在，Selection API 的 setBaseAndExtent()、extend() 和 collapse() 不会因 DocumentType 节点输入而在无提示的情况下失败，而是引发 InvalidNodeTypeError DOMException，以更好地符合相关规范。
为更好地符合相关规范，getRangeAt() 现在始终返回新的位置规范化的 Range。
现已移除 AudioSourceNode 接口，因为它不再属于 WebAudio 规范。
现已移除 webkitdropzone 属性，因为它未得到广泛采用。