标签：流程图 衣服 开场动画 bundle 观察 存储 cache 底部 事件
2016 年天猫前端相比去年有了非常多不同维度的突破，主要可以分为四大类大类：
稳定性、监控
极致的性能优化
业务创新 / 平台建设
技术创新 / 互动
商品到每个用户浏览的每个环节都有监控，尤其在针对消费者体验上的 TES，让前端在消费者真实浏览的过程当中也能够有更进一步的分析在不同环境下消费者实际的体验。以及从服务器 Wormhole 渲染层进行了一系列的稳定性、监控。
Wormhole承载了2016天猫，淘宝等BU的双11会场页面渲染职能，整个体系链路横跨了前端开发、存储、渲染、CDN等不同的领域，在双11活动中系统可访问性变得尤为重要。为了确保双11会场页面能够在各种极端场景下还能够顺利打开，wormhole做了非常多的稳定性容灾方案。包括去除单点依赖、HTTPS防劫持，动态调节CPU利用率、数据链路OSS依赖容灾以及集群完全无法服务后的终极打底方案等。
Wormhole 是一个CDN前置的无状态静态页面渲染服务，从简单和维护成本角度出发，没有接入集团的单元化部署策略，而是采用异地多机房部署的模式，借助CDN回源策略实现异地多活。
为了避免用户访问链路被IDC劫持，Wormhole 完成了全HTTPS的改造，包括从CDN到用户端以及从CDN回渲染源站的链路，实现完整的HTTPS 访问链路，避免中间被劫持，造成用户访问故障。1源站负载动态调节
在双11的场景下，为了保证0点时刻用户端能够及时访问到最新的页面（活动发布、价格透出、秒杀等），CDN的缓存和用户端缓存都要求即时实效，在瞬间产生大量的回源请求，给 Wormhole 渲染源站带来短时间的高负载，在保证渲染实时性的同时，Wormhole 根据当前系统的负载动态的使用历史渲染缓存（本地磁盘、远程OSS），来降低应用的渲染负载，保障服务的稳定性。
Wormhole 依赖阿里集团的OSS作为数据存储服务，包括模块、页面以及投放数据，以尽可能简单的架构来保障服务的可扩展性，提升可维护性。对于OSS的依赖，Wormhole 提供了两层稳定性保障：
为了避免在 Wormhole 渲染服务异常的情况，我们针对渲染的结果也做了两层的容灾策略，即
在应用异常时，可以通过本地Tengine的容错设置，读取本地磁盘的渲染结果提供服务，或者在极端严重的情况下，通过切换CDN回源的方式，将CDN整体回源到灾备OSS，使用历史渲染页面继续提供服务。
TES技术体验平台，致力于提供让技术及业务同学都能准确及直接观察、了解及分析业务前台页面状态的能力。从稳定性、性能、体验三个维度来全面掌握业务的运行及使用情况，同时从多维度定义一套符合用户实际体验的指标体系，来描述一个页面的使用运行状态。
纵观在前端领域，都会存在性能监控及页面监控等多类系统，但存在几个未考虑或不足的问题：
TES吸取了基础性能及监控系统的功能，同时提供了体验维度的监控及数据展现，分别从FPS、CPU、电量使用等可能影响体验的因素进行监控和汇总。提供全局实时监控能力，监控页面的稳定性，如资源加载、接口异常、JS报错及crash等。丰富性能展示维度。
TES平台的设计是从业务的角度出发，当页面发布上线后 TES 自动能分析及归纳页面所属的业务，同时从垂直业务及活动进行分类，方便开发及业务同学进行查看对应业务的运行情况。
双11期间通过TES系统实时发现多处线上图片链接、资源连接以及接口稳定性等问题，同时提供了多端的监控埋点，统计分析接口数据打底以及链路情况等。
双11会场在客户端内以WEEX状态呈现，同时支持WEB浏览器访问，从整体可以观察到双11所有页面的整体性能的情况，是否达标，同时从在对单个页面有较详细的性能分析。
目前所有的页面监控对体验都没有比较好的采集以及评估方式，目前TES会结合各类影响体验的因素，如FPS、大图大资源、CPU执行情况以及耗电量等，同时后续会完善更多合理的指标来完善体验指标的整理，目前以FPS数值为主。
从H5到React Native，再到Weex，阿里在性能、体验优化的道路上尝试了各种方案，从去年双11到今年双11，在底层上我们完成了许多重要优化，保障双11的秒开目标。
页面加载时间pageLoad
天猫Mobile性能优化的核心衡量指标是pageLoad，它是一个webview实现的类似JS的onload的事件，在iOS下对应webViewDidFinishLoad，在android下对应onPageFinished。
onload和pageLoad的差异主要是在onload事件里同步执行的js、加载的资源都会被计入到pageLoad内，而onload事件里执行代码通常就是特意做了懒加载处理，我们可以在onload里包一层setTimeout来解决：
window.addEventListener(‘load‘, ()=>{
setTimeout(()=>{
//load assets\data...
}, 0)
})
天猫pageLoad目标经历了多个阶段，从15年2月之前的2s到15年5月的1.5s，一直到目前的1s。
pageLoad和onload一样都是一个浏览器实现的通用事件，和onload一样事件促发不等于页面真实加载完成。我们需要又一个可以衡量用户真实感受的首屏渲染时间指标，最终选择了基于代码埋点，代码中加入埋点并上报，在模块加载容器上添加setter来监听模块加载状态变化的方案尽可能减少对业务的侵入，且不受模块删减、调整影响，模块的大致写法如下：
class Module{
constructor(){
...//数据加载 & 渲染
this.readyState = ‘rendered‘; //标识该模块已经渲染完成
...//事件绑定
this.readyState = ‘complete‘; //标识该模块已经处于可交互状态
}
}
除了以上2个描述加载速度的指标以外，我们还实现了一个FPS指标，用户衡量页面的滚动流畅性。对于FPS的统计方案和业界一致，根据requestAnimationFrame之间的时间差值来计算。
因为用户浏览的过程会持续滚动，而埋点上报的数据量有限，我们选择在客户端完成统计计算，上报计算后的统计学指标的方案，包括：最小值、最大值、均值、众数和中位数，而上报的时机选在了每一次页面离开的时候，实现上结合了visibilitychange和pagehide这2个事件，保证覆盖各个移动端环境。
HTTP2可以带来多路复用、头部压缩、服务端推送能力、请求优先级控制等优点。这一年我们完成了阿里CDN和统一接入层的HTTP2部署，同时在客户端优化了HTTP2的命中率，目前天猫核心域名的HTTP2命中率已经达到97%+，再加上我们完成了大范围的域名收敛，整个页面的域名收敛到了5个以内，更好得发挥了HTTP2多路复用的优势，最终HTTP2带来的性能收益在250ms+。
域名解析在移动端是一个非常耗时的过程，且根据网络情况波动很大，手淘猫客对此做了优化：由服务端下发一份域名和ip的对应关系，然后客户端直接通过ip访问，跳过域名解析的过程，在这套现成技术上，我们完成了天猫核心域名的下发，同时完成域名收敛，保证页面用到的域名均在HTTPDNS执行列表之中，最终性能提升100ms+。
手淘猫客提供了2种预加载方案zcache和packageApp，目前用的主要是zcache，因为平台默认提供的是人肉的发布流程，导致线上使用率很低，即使用了也难以坚持长期更新，为此我们开发了一套自动化的预加载策略：按页面访问流量进行排序，自动预加载前N个页面用到的资源，大致流程如下：
在技术上Weex整个页面只有一个bundle.js，所有的数据都异步获取，通过预加载技术将bundle.js提前下发到客户端以后，除了数据以外整个加载过程就不再存在任何assets加载，双11会场中基于Weex的会场占比：99%+，整体秒开率在90%以上：
? Weex 主会场秒开率
? 秒开率峰值（00:00）：整体 96.9%（278.8ms）、iOS 99.4%（146.4ms）、Android 93.4%（411.1ms）
? 秒开率均值：整体 94.4%（367.6ms）、iOS 99.0%（177.0ms）、Android 91.8%（473.3ms）
? Weex 所有会场秒开率
? 秒开率峰值（00:49）：整体 92.4%（490.7ms）、iOS 97.4%（291.6ms）、Android 87.5%（689.8ms）
? 秒开率均值：整体 83.9%（651.9ms）、iOS 94.5%（368.0ms）、Android 78.6%（797.4ms）
天猫H5页面主要分为2种模式，一种是静态页面+异步数据，另外一种是服务端同步渲染：
1. 对于第一种模式，运用的页面较少，以天猫首页为例，落地各个优化点以后秒开率达到90%+，pageLoad均值在800ms+。
2. 对于绝大部分服务端同步渲染的页面，目前优化后的pageLoad极限在1.1s左右，和同步渲染的首屏内容的复杂度正相关，在1.1s~1.6s之间波动。
面对日益复杂的业务上透过产品化的方式解决当前的问题，从过去静态化千人一面的货架形式走向千人千面的个性化，商品个性化到楼层个性化，全网单统一投放到区域定投等，结合现有平台方式解決更复杂的业务问题。
各个行业统一区域化逻辑，形成一套通用的可扩展的区域化服务，包括区域优惠、区域库存、区域定投等，而这些能力都依赖城市定位，所以我们要做的第一步就是统一各个行业的定位逻辑，这里的统一包含几个层面：
定位的判断来源主要包括以下几个：用户选择、ip、默认收货地址、gps、打底城市，需要统一这几个判断来源的组合规则和顺序，统一后的规则如下图所示:
区域化底层能力之上，实现了斑马平台级的模块区域定投功能，运营可以针对任意一个模块开启区域定投，并在双11会场中投入使用，业务流程如下：
一个模块是完整的最小业务粒度单位，通常用一个模块来展现一批相关联的商品，如『国际食品』会场的『早餐拍档』就是一个模块，为用户展现麦片、奶粉等早餐相关商品。
由于是否个性化并非由开发者决定，因此最好的方式就是透过共通的组件来处理数据，增大复用性，大致流程图如下：
当然，这只是数据流通的基本原理，要实现以上功能，还有以下细节需要处理：
以上模块内个性化效果还是有限，若能在模块顺序个性化能够达到更好的效果，如下图所示：
1754 张双11会场页面中（统计了天猫和淘宝），Weex 页面数为 1747 占比 99.6%。手淘 iOS/Android 分别有 83.5%/78.3% 版本（UV）启用了 Weex 会场，手猫 iOS/Android 分别为 91.7%/87.9% 版本（UV）。Weex 覆盖了包括主会场、分会场、分分会场、人群会场 等在内几乎所有的双11会场业务。
双11的会场结构大致为：会场框架（框架 + 主会场、全部会场、必抢、清单、我的双11）、分会场、其他会场（分分会场、人群会场等）。
Weex 支撑双11业务首要解决的是会场框架及其交互形式：
1. 交互主流程：
1. 非 push 方式（框架Tab 切换）：主会场 - 全部会场 - 必抢 - 清单 - 我的双11
2. push 方式：主会场 - 分会场 - 主会场
2. iOS 考虑到内存开销，需严控打开的主分会场weex页面，定为 n 级可配，默认为 5；同时 iOS 会场框架为单实例，也是出于内存的考虑；Android 连续打开 30 级以上 Weex 页面，未见内存异常增长，无需特殊方案
图 - 会场框架交互
Weex 的首要挑战就是稳定性，或者说保障 Weex 会场最大限度不降级。
* 压测场景
1. 5个200 坑位的普通会场页面，1 全景图会场页面，1 曝光埋点压测页面，1 直播会场页面
2.页面中提供链接，能够按顺序进行 push 跳转
* 压测方案
1. 主链路（首页->店铺->详情->购物车）做一遍操作，让内存缓存占满，记下内存值 M0
2. 进入Weex 页面，滑动到底部，滑动到顶部，记下 M1；点击跳转按钮，跳转到下一个页面
3. 重复步骤 2，让所有的页面进行压栈；全景图->p1p2p3p4->直播->p1p2p3p4->UT
* 压测结果：iOS 通过，Android 通过
1. 测试过程手淘手猫均未出现因为压栈导致的 Crash，稳定性可以保证；
2. Android低端机压栈过多会导致体验较差，之后也会引入类似 iOS VC 层级控制；
2016.11.11，Weex 在手淘中的 Crash 占比情况：
2016年的天猫双11晚会互动与往年一样是由天猫互动技术团队负责开发，在去年红黑PK的经典玩法的基础之上增加双向AB剧与AR跨屏抢新衣的两个玩法，同时增加了舔屏版和后台揭秘版两个场景。对于前端技术的挑战就是需要让呈现的效果『更实时、更真实』，玩法和场景上的增加也要求开发团队『更高效』。
本次晚会升级了前后端的数据传输方式，以轮训为打底，通过powermessage和关键帧技术使数据更轻量准确的实现前后端通讯，来实现复杂的高实时性互动。
1. powermessage
通过powermessage技术，建立客户端与后端的长链接，待后端数据有增量变化时，通知前端做出相应的互动状态变更，这样做的好处是减少轮训带来的压力，实时性高。
2. 关键帧技术
传统的，我们通过人工切节目表的方案，来实现流内容与前端页面的实时同步，必然会有少许误差，通过关键帧技术，OBS推流时，在流中增加一段增强信息SEI，播放器底层捕获后，以通知形式抛给iOS和Android层，客户端这层获取对应的字符串，组织成json通过argoWebView提供的hybird接口传递给前端，即可实现由流内容触发前端互动操作，达到可控的、精准的实时操作。
为了给用户更奇特的用户的体验，实现酷炫的互动营销手法，晚会的一个亮点就是由AR技术实现的“明星丢衣服”环节，用户在开电视直播的过程中，明星在电视端丢出一件衣服，主持人会口播提示用户使用手淘或者猫客的摄像头对准屏幕，客户端通过 AR 识别技术进行识别和定位，识别成功后，用户在手机上会看到衣服从电视中浮出，砸碎手机屏幕的特效，效果见：
http://download.taobaocdn.com/freedom/29927/pic/p1b1lk13um1h1p15ti1v99utf1scv4.gif
AR识别功能可以划分为业务层和识别层两部分，这两部分具体实现的功能如下：
1. 业务层：主要包括摄像头数据展示层和WebView层。摄像头数据展示层主要负责进行摄像头数据的展示。WebView层位于整个界面的最上层，负责Markers（识别物）数据的下发以及根据识别层返回的识别物位置信息进行渲染（可以根据前端的需要进行2D，3D以及各种特效的实现）。
2. 识别层：基于Markers的位置识别，实时扫描摄像头中的帧数据以判断是否命中识别物，若命中则将识别出的3D位置信息返回给上层业务方。
（AR识别方案）
（手机天猫AR识别流程）
开场动画、摇一摇、AR丢衣服等多处动画特效有非常高的要求，素材制作上，给设计师带来挑战的同时，也给前端同学带来不小困难，即酷炫的动画过于复杂，如果按照视觉稿一帧一帧还原的话，需要耗费极大的人工成本，而且一旦动画出现需求变更，对前端来讲简直就是灾难。去年设计师使用的是Flash进行开发，前端工程师采用自研的Flash插件导出Hilo动画，而2016年设计师使用 After Effector(AE) 制作动画，我们又通过写 ExtendScript 脚本导出动画数据，优化、解析动画数据后，使用 canvas 来播放动画，行成了新的AE2Html5的动画生成工具。
天猫在每年双11预热期都会发布汇集众多品牌、效果酷炫的狂欢城互动页面，2016年和往年不一样的最大亮点是首次同时推出了2D和3D两个版本。3D版狂欢城开启了电商行业首次在大场景下应用Web3D技术。
在做场景展示选择的时候，我们首先想到的是3D巡航场景，和多数第一人称游戏类似，使用第一人称的视角在品牌场景中边逛边玩，但这种方式面临品牌透出和性能挑战。
经过多次简化场景，保留品牌模型，设计师同学提出一种近似滚筒的场景——纸片风格的广告牌方案。这种纸片自带一些3D感，实际上我们看到很多2D图案，因为有透视效果，当我们审视的角度和设计师设计的视角吻合时，会感觉那是3D的。Billboard在现实生活里也比较常见，比如大型购物地带，繁华路段等。
Billboard的策略很简单，尽可能正对着用户，正对着人流（流量）。在一些建筑的边界区域，Billboard能够利用多个面达到尽可能大的曝光。
在技术实现上，CSS3和Canvas也能模拟类似的效果。同时，根据手机淘宝和手机天猫当前的WebView的环境，CSS3的支持会比WebGL好很多，但是在CSS3在处理这种大场景时存在一些无法回避的问题——分割贴图、形状拼接后的“黑边”问题、transform的白屏黑屏问题。
在底层实现上，WebGL比CSS3更稳定，CSS3更适合一些小场景。另外，在3D表达上，物体的形状和纹理是我们最能直接感受的两个特征，形状就是我们看到的样子，纹理就是表面的附着。除了这些光照，环境（雾、雨），反射，材质都能通过和材质表面的颜色做若干次运算，最终通过算出来的RGBA来使物体呈现丰富的外观。在构建复杂3D物件形状上，CSS3会显得捉襟见肘。所以，最后我们选择WebGL。
第八章 交互技术，8.3 2016双11前端突破(作者：天猫前端团队)
标签：流程图 衣服 开场动画 bundle 观察 存储 cache 底部 事件
原文地址：http://www.cnblogs.com/hujiapeng/p/6236869.html
