结合Native优化

经过几轮的常规前端性能优化后，页面性能有进步，但是离目标还远远不够。我们也不断的问自己到到底那里慢，那里瓶颈最大。我们开始试着CaseByCase的分析页以及梳理H5在手淘中的全链路性能消耗。 最终做了一些和native结合的优化思路。 ## HTTPDNS DNS解析想必大家都知道，在传统PC时代DNS Lookup基本在几十ms内。而我们通过大量的数据采集和真实网络抓包分析（存在DNS解析的请求），DNS的消耗相当可观，2G网络大量5-10s，3G网络平均也要3-5s。 案例：iPhone5s 联通3G [](https://camo.githubusercontent.com/058a788d258b2608ff22ad452aa95dae4ebb31ff/687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f343234303366623363363362333334396438343564643035633065363331653538656364626538662e6a706567) [](https://camo.githubusercontent.com/48d8202405c1f4742edae175ae4195f46d55739b/687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f353066366630666337356331653335333763383736656364356138333534316465626632373636372e6a706567) 针对这种情况，手淘开发了一套httpdns，httpdns是面向无线端的域名解析服务，与传统走UDP协议的DNS不同，httpdns基于HTTP协议。 基于HTTP的域名解析，减少域名解析部分的时间并解决DNS劫持的问题。 手淘httpdns服务在启动的时候就会对白名单的域名进行域名解析,返回对应服务的最近ip（各运营商），端口号，协议类型，心跳 等信息。 ### 优点 * 防止域名劫持 传统DNS由Local DNS解析域名，不同运营商的Local DNS有不同的策略，某些Local DNS可能会劫持特定的域名。采用httpdns能够绕过Local DNS，避免被劫持；另外，httpdns的解析结果包含HMAC校验，也能够防止解析结果被中间网络设备窜改。 * 更精准的调度 对域名解析而言，尤其是CDN域名，解析得到的IP应该更靠近客户端的地区和运营商，这样才能有更快的网络访问速度。然而，由于运营商策略的多样性，其推送的Local DNS可能和客户端不在同一个地区，这时得到的解析结果可能不是最优的。httpdns能够得到客户端的出口网关IP，从而能够更准确地判断客户端的地区和运营商，得到更精准的解析结果。 * 更小的解析延迟和波动 在2G/3G这种移动网络下，DNS解析的延迟和波动都比较大。就单次解析请求而言，httpdns不会比传统的DNS更快，但通过httpdns客户端SDK的配合，总体而言，能够显著降低解析延迟和波动。httpdns客户端SDK有几个特性：预解析、多域名解析、TTL缓存和异步请求。 * 额外的域名相关信息 传统DNS的解析结果只有ip，httpdns的解析结果采用JSON格式，除了ip外，还支持其它域名相关的信息，比如端口、spdy协议等。利用这些额外的信息，APP可以启用或停止某个功能，甚至利用httpdns来做灰度发布，通过httpdns控制灰度的比例。 ## SSL+SPDY协议 在经过以上的优化方案后，H5页面的性能始终离目标还远。在移动端建连的消耗非常大，在业界也只有SPDY 这个玩意儿比较新颖。 理论上SPDY协议可以完成多路复用的加密全双工通道，显著提升非wifi环境下的网络体验。 [](https://camo.githubusercontent.com/294d646852cab2d6cf010629290c7251d464ec37/687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f336132323433323437663262656333373764326432326135633730346537356666623438646263362e6a706567) * 多路复用请求优化 * 服务器推送技术 * SPDY压缩http头 看着很牛逼的技术，但是等我们第一期上线后发现，从数据上几乎察觉不了变化。 ## 域名收敛 域名收敛是指尽量控制一个页面中使用的域名数量。为什么要这么做呢？我们前面提到DNS解析，减少域名数量可以降低DNS解析的成本。上文还提到SPDY协议，其中一个特性就是复用请求，使用同一个域名可以更多的复用请求。这个PC时代正好相反，我们原先用多个域名提升并发请求量已提升性能。 PC时代的域名数量类似这样的 [](https://camo.githubusercontent.com/1f73cb08243fc3e2482114714e790cbf79105f54/687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f346364316232346563623561396132346562363633313633663161643661316165633136646464372e6a706567) ### 域名最终形态（建议） * 页面请求 域名一个 * 静态资源（css，js） 一个 * 图片资源 一个 * 动态数据一个 * 数据统计一个 最终结合SSL+SPDY+域名收敛 才发挥出真正的作用。下图是各网络下SSL 和 非SSL 的性能情况。 [](https://camo.githubusercontent.com/e487a70f01c1e84583381babaf555de0cb35556f/687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f396337333664373266343265653966636262333963316564303864366431643065643262373339612e6a706567) ## 动态数据复用状态 动态数据部分，相信各个公司都差不多，动态数据会有专门的API提供出来。手淘（mtop平台）也一样，接口总会有各种状态，登录失效，令牌过期，签名失效等。手淘使用了重发请求的方式来获取新的签名令牌等。导致如下的情况（始料未及）： 在手淘真实环境中发现一次令牌过期，可以造成10多秒的延迟。 [](https://camo.githubusercontent.com/758fdc95c52f86d89d4b9b853a009439a1e9d6f5/687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f363937323634306163343934353934623963633762316431306333663636326265383263323939322e6a706567) 手淘在启动的时候Native已经做了很多的数据请求，这些也是mtop请求，只是由native程序发出。 我们判断到页面是在手淘客户端中就会使用native发出mtop数据请求，这样就规避了令牌失效，签名失效的问题。 直本次优化后，我们第一次看到了非常激动人心的数据:`第一次里程碑式的提升` `优化前` [](https://camo.githubusercontent.com/2b6b5a9819aa37d14a9b1b90bf9e01b89cc8a24d/687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f666134636139636434343164353166623537353439646263663135666262316361383036343831312e6a706567) `优化后` [](https://camo.githubusercontent.com/a7c08004b528de6650823fc5a71d4ed12fa21e56/687474703a2f2f696d67322e746263646e2e636e2f4c312f3436312f312f643334616437336464663661613037666237306562643162353466616530353834333736356137652e6a706567) ## 预加载和离线化方案 手淘中加载H5页面的首屏白屏时间较长，基于此，集团各BU都内部产生了离线包的方案（手淘，航旅，钱包），将静态资源通过Hybrid的方式提前加载到本地。大量了资源预加载给H5页面带来了极大的提升，资源加载时间降到30ms内。 今年双11前，针对预加载方案，在技术上解决了3个痛点 * 开发成本（开发方式侵入性强） * 静态资源解Combo * 更新到达率 关于 预加载&离线化方案详细技术细节很多，这里先简单阐述这个功能带来的性能提升价值。 下图案例： * 第一个HTML没有预加载，阻塞页面时间较长 * 静态资源部分几ms 级别加载，加载性能非常好 [](https://camo.githubusercontent.com/86ac7a72849c7ff2313219a24c90c9aaaf005484/687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f643335336137653630383635636438643466393636346331326462353365393936303737326263332e6a706567) `这是第二次里程碑式的提升，3G，4G，WIFI网络性能全面提升。` 截至到这个时间点为止，我们个别业务的性能有了显著的提升。以下是其中一个业务的3个性能优化节点的性能优化对比。其中10s以上加载完成的占比大大的缩小，1s以内的占比上升较高。 [](https://camo.githubusercontent.com/8f5896ed527e002e1e136db49e5af2b0bdc685aa/687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f613233323062303931323462393832666531353865666531613938326436386430613365666131352e6a706567) ## 统计方案优化 业务数据统计在日常工作中是必不可少的部分，因统计部分量级不大，往往会忽视掉。其中我们对一个业务CaseByCase的分析后发现。一个中国移动 2G/3G.Edge的用户在请求H5页面的时候 log.mmstat.com 的日志埋点花了近`6s`才加载完成。 [](https://camo.githubusercontent.com/e6afbf6af8119b7fc9c69f4b15a4e20e6d4c5651/687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f643461353364323536383662316139313264373136653361383166666636383337343362316238652e6a706567) [](https://camo.githubusercontent.com/ca9a49b3b73905f6e845adfb16818532c3e9a996/687474703a2f2f696d67312e746263646e2e636e2f4c312f3436312f312f626231336364396362363438383363336431376533376134373239633139343633366139303162302e6a706567) 后面我们对数据统计部分做了Native的异步上传。效果是这样滴： iOS： [](https://camo.githubusercontent.com/507e83bcfcd5baff314e06777ee34d6961529fb5/687474703a2f2f696d67332e746263646e2e636e2f4c312f3436312f312f636162663861616666373539663862373033363264616132376636643061343661623434316561632e6a706567) Android： [](https://camo.githubusercontent.com/00b96e2ce63cd201b0782da46fc3dfb5bd73eda8/687474703a2f2f696d67342e746263646e2e636e2f4c312f3436312f312f366461636632643337656433636630373437363435383865616235333033663630386165373435352e6a706567) `第三次里程碑式的提升，2G网络性能全面提升`