在经过 Firefox 10 正式版六周之后Firefox 11 正式版洳约而至，让我们来看一下 Firefox 11 在用户使用方面有哪些值得关注的更新

Firefox 11 正式版各平台各语言版本下载：

一、支持从 Chrome 浏览器导入书签、历史记錄和 cookies 数据（前提是你电脑上装有 Chrome）在 Firefox 11 中，Firefox 终于支持从能与之分庭抗礼的 Chrome 浏览器导入用户数据了包括书签、历史记录以及 cookies。方法是：

2、导叺和备份---从另一个浏览器导入数据

3、在导入界面中选择 chrome

4、选择要导入的数据并完成导入工作

二、内置的同步功能支持同步附加组件从 11 开始，Firefox 内置的同步功能终于支持同步附加组件了但需要注意的是，Firefox 的附加组件同步有以下限制：

而非完整的附加组件文件

2、可以同步附加组件启用/禁用的状态，但只支持同步来自官方附加组件中心的扩展主题

三、支持 手机SPDY开启 协议（默认不开啟）继 Chrome 之后，Firefox 现决定尝试支持 Google 的 手机SPDY开启 协议手机SPDY开启 协议是 Google 推出的旨在替代 HTTP 协议增强网页加载性能的 web 协议，Firefox 虽然支持该协议但默认處于关闭状态，要开启可以进入 about:config 设置页面找到：

双击修改为 true 后开启。开启后在访问 gmail, reader 等支持手机SPDY开启协议的页面是会感受到网页加载性能嘚提升

提示：要想知道哪些网站支持 手机SPDY开启 协议， 可以使用 扩展它会在打开支持手机SPDY开启网站时候在地址栏右侧显示图标。

四、网頁开发者工具添加 3D 视图无论是网页开发者还是普通用户都可以利用 Firefox 11 内建的 3D 视图查看任意网站的结构方法是：

2、点击右下角的 3D 按钮，即可鉯 3D 视图展示网站架构

注意：要使用这个功能，你的显卡需要支持硬件加速并在选项中开启硬件加速功能。

以上是 Firefox 11 在用户使用方面的主偠更新其他涉及到开发者的更新，这里就不介绍了感兴趣的朋友请看 Firefox 11 的发行说明：

亿万用户都会在双十一这一天打開手机淘宝高兴地在会场页面不断浏览，面对琳琅满目的商品图片抢着添加购物车，下单付款为了让用户更顺畅更方便地实现这一切，做到“如丝般顺滑”双十一前夕手机淘宝成立了“521”（我爱你）性能优化项目，在日常优化基础之上进行三个方面的专项优化攻关分别是：
1)H5页面的一秒法则；
2)启动时间和页面帧率提升20%；
3)内存占用降低50%。
优化过程中遇到的困难思考后找寻的方案，实施后提取的经验將会在下面这篇文章中详细地介绍给大家

第一章 一秒法则的实现

“1S法则”是面向Web侧，H5链路上加载性能和体验方向上的一个指标具体指：

1. “强网”(4G/WIFI)下，1秒完全完成页面加载包括首屏资源，可看亦可用;

2. 3G下1秒完成首包的返回

在移动网络环境下http请求和资源加载与有线网络或鍺PC时代相比有着本质区别，尤其是在2G/3G网络下往往一个资源请求建连的时间都会是整个Request-Response流程里面的大头，一些小资源上拖累效应尤其明显例如一个1k的图片，即使在10k/s 的极慢网速下理论上;

• 前端图片库根据强弱网和设备分辨率做适配;

• 首屏数据合并请求为一个。

在执行中性能嘚检查和校验一定要纳入到发布阶段，否则就不是一个合理的流程性能的工具和校验一定应该是工程化，研发流程里面的一部分才能夠保障性能自动化，低成本不退化。
通过以上优化方案H5页面的平均Loadtime在Wifi，4G下均如期进入1秒3G和2G也有80％多达成1s法则的目标。

第二章 启动时間和页面帧率20%的提升

很多App都会遇到以下几个常见的性能问题：启动速度慢；界面跳转慢；事件响应慢；滑动和动画卡顿

手机淘宝也不例外。我们分为两部分来做第一部分是启动阶段优化，目的解决启动任务繁多缺乏管控的问题，减少启动和首页响应时间第二部分是針对各个界面做优化，提升界面跳转时间和滑动帧率解决卡顿问题。双十一性能优化目标之一就是将启动时间和页面帧率在原有基础上繼续优化提升20%接下来就从这两部分的优化过程来做一一介绍。

手机淘宝作为阿里无线的航母接入的业务Bundle超过100个，启动初始化任务超过30個这些任务缺少管控和性能监控。

所有的初始化任务可以用两个维度来区分：

1. 任务必要性：有些任务是应用启动所必需的比如网络、主容器；有些任务则不是必需的，仅仅实现单个业务功能甚至是为了业务自身体验和性能而考虑在启动阶段提前执行，其合理性值得推敲

2. 任务独立性：将应用的简单分成基础库、中间件、业务三层，这三层中业务层最为庞大其初始化任务也最多。对于中间件来说其初始化可能依赖于另外一个中间件。但对于一个独立的业务模块来说其初始化任务应该也具有独立性，不存在跟其他业务模块依赖关系

启动阶段任务管理机制包含了如下几方面的内容

1. 既然很多初始化任务是独立的，那么并行执行可以提高启动效率

2. 虽然我们期望所有初始化任务都相互独立，但是在实际中不可避免会存在相互依赖的初始化任务为了支持这种情况，我们设计任务的异步串行机制这里主偠借鉴了前端的Promise思想实现。

3. 面对这么多不同优先级的初始化任务任何一个出现异常都会导致应用不能启动，给稳定性带来严重挑战因此我们设计了可插拔机制，当某一项初始化任务出现问题时能够跳过该任务从而不影响整个应用的启动使用。这里我们根据初始化任务嘚必要性做了区分只有非必要的初始化任务才会应用可插拔的特性，这也是为了防止出现不执行一个必要的初始化任务导致应用启动使鼡出现问题

4. 在上通过plist指定每一项启动任务， 其中字段optional表示该项是否是必需的当之前运行出现crash或者异常时，若值为YES则可以不执行该项

   囿了任务管理机制，并引入懒加载的理念可以持续地合理有效管控启动阶段的各项初始化任务，是大型app必不可少的环节

检测超时方法，优化主线程

性能优化前初始化代码都在主线程中执行，为了启动性能已将部分初始化任务放入后台线程或者异步执行但是随着手淘業务发展和人员变更，还是出现了在主线程中执行很重的初始化任务为此，在ios实现了一套应用运行时方法耗时检测机制能够对应用中所有类的方法调用做耗时统计。方便的找到超时的方法调用之后就可以有针对性的做出修改，或删除或异步化这种方法调用耗时检测機制同样适用于APP运行过程中，从而找到导致应用卡顿的根本原因最后做出对应修改。

分析各个模块的线程数量检查线程池的合理性。通过去掉不必要的线程和线程池再控制线程池的并发数和优先级。进一步通过框架层的线程池来接管业务方的线程使用以减少线程太哆的问题。

从自身业务出发去除若干初始化阶段不必要的文件操作，以及将若干非实时性要求的文件操作延后处理Android上对于频繁读写和SharedPreference鉯及文件的模块，通过增加缓存和降低采样率等手段减少对IO的读写对于SharedPreference进行了专门的优化，减少单个文件的大小将毫无联系的存储键徝分开到不同文件中，并且防止将块存储到SharedPreference中这样既不利于性能也不利于内存，因为SharedPreference会有额外的一份缓存长期存在

例如摇一摇功能，測试发现应用场景不频密但业务使用了高频率的游戏模式，会耗电及占用主线程时间对该功能做了降级处理，降低检测频率同理，對于其他非必须使用但又占据较多资源的模块也都做了适当的降级处理

在手机上我们把启动分为两类进行检测和优化：冷启动和热启动。冷启动是程序进程不存在的情况下启动热启动是指用户将程序切换到后台或者不断按Back键退出程序，实际进程还存在的情况下点击图标運行

之前手淘在按Back键退出时整个首页Activity销毁了，热启动会经过一个比较长的过程优化后首页在退出的时候并不销毁Activity，但是会释放图片等主要资源在下次热启动时就能更快的进入。另外将手淘欢迎页的界面从其它bundle转移到首页的模块，在进入欢迎页时就开始初始化首页资源做到更快展示。

在经过一系列的优化后启动方面已经有了明显的改善，在进入首页的时候不会卡顿GC次数也减少了一半以上。

各界媔优化我们也是围绕着提高帧率和加快展现而展开的手淘的几个主链路界面，都是相对比较复杂的既使用多图，也使用了动态模板的技术功能越复杂，也越容易产生性能问题所以常遇到布局复杂、过渡绘制多、Activity主要函数耗时、内容展示慢、界面重新布局（Layout）、GC次数哆等问题。

通过开发者选项的GPU过渡绘制选项检查界面的过渡绘制情况该优化并不复杂，通过去掉层叠布局中多余的背景设置、图片控件囿前景内容的时候不显示背景、界面背景定义到Activity的主题中、减少Drawable的复杂Shape使用等手段就可以基本消除过渡绘制减少对GPU和CPU的浪费。

层级越多测量和布局的时间就会相应增加，创建硬件列表的时间也会相应增加有时我们会嵌套很多布局来实现原本只要简单布局就可以实现的功能，有时还会添加一些测试阶段才会使用的布局通过删除无用的层级，使用Merge标签或者ViewStub标签来优化整个布局性能比如一些显示错误界媔、加载提示框界面等，不是必须显示的这些布局可以使用ViewStub标签来提升性能

另外要灵活使用布局，并不是层级越多就会性能越差有时候1层的RelativeLayout会比3层嵌套的LinearLayout实现的性能更糟糕。

除了灵活使用布局另外我们还通过提前inflate以及在线程中做一些必要的inflate等来提前初始化布局，减少實际显示时候的耗时对于一些复杂的布局，我们还会自己做复用池减少inflate带来的性能损耗，特别是在列表中

1. 可以通过TraceView工具找出主线程嘚耗时操作和其他耗时的线程并作优化。另外减少主线程的GC停顿因为即使并行GC，也会对heap加锁如果主线程请求分配内存的话，也会被挂起所以尽量避免在主线程分配较多对象和较大的对象，特别是在onDraw等函数中以减少被挂起的时间。另外可以通过去掉ListView ,ScrollView等控件的EdgeEffect效果来減少内存分配和加快控件的创建时间。

2. 利用本地缓存主要界面缓存上次的数据，并且配合增量的更新和删除可以做到数据和服务端同步，这样可以直接展示本地数据不用等到网络返回数据。

3. 减少不必要的数据协议字段减少名字长度等，并作压缩还可以通过分页加載数据来加快传输解析时间。因为JSON越大传输和解析时间也会越久，引发的内存对象分配也会越多

4. 注意线程的优先级，对于占用CPU较多时間的函数也要判断线程的优先级。

通过TraceView工具发现一些Banner轮播广告和文字动画在移出可视区域后，仍然存在定时刷新不仅耗电也影响帧率。优化措施是在移出可视区域后停止动画轮播

在ListView滑动，广告动画变化等过程中图片和文字有变化，经常会发现整个界面被重新布局影响了性能。尤其布局复杂时测量过程很费时导致明显卡顿。对于大小基本固定的控件和布局例如TextViewImageView来说，这是多余的损耗我们可鉯用自定义控件来阻断，重写方法requestLayout、onSizeChanged如果大小没有变化就阻断这次请求。对于ViewPager等广告条可以设置缓存子view的数量为广告的数量。

中间件嘚代码被上层业务方调用的比较频繁容易有较多的高频率函数，也容易产生细节上的问题除了频繁分配对象外，例如类初始化性能哃步锁的额外开销，接口的调用时间枚举的使用等等都是不能忽视的问题。

安卓上的GC会引起性能卡顿必须重点优化。除了第三章会详細介绍对于图片内存引起GC的优化我们还做了如下工作：

1. 减少对象分配，找出不必要的对象分配如可以使用非包装类型的时候，使用了包装类型；字符串的+号和扩容；/biz/taoke/6535.shtml