本文作者:文蔺
本文地址:http://www.wemlion.com/2016/velocity-2016-note-1/
本文由 @文蔺 创作,转载请保留此声明。
所有权利保留,请勿用于商业目的。

有幸得到老大给的 Velocity 大会门票,屁颠屁颠跑去听分享。下面是今天(第一天)的笔记。记得比较简略,凑合看吧。PPT 下载通道已经放出来了,感兴趣的可以自己跟踪一下。

UseThePlatform —— Web 组件介绍

分析者:来自 Youtube 的 Mikhail Sychev

感觉就是对 Polymer 和 Web Components 的科普。期待明天更详细的分享。

其实关于 Polymer,打开 Chrome 的 chrome://downloads/ 查看源码,就能学到不少东西:CSS 变量、Shadow DOM、Polymer 等等。之前打算就这个写篇博客,一直没动手。

(略….)


搜索引擎性能优化的未来 —— 搜索极速浏览框架

分享者:来自百度的陶清乾

听到最后才发现,原来是搞了套自己的后端工具,你“打开”的页面,可能只是百度缓存、处理过的。(免责声明:理解可能有偏差)还提了下使用的 工具 MIP。

全流程优化

  • 展现交互
  • 加载策略
  • 页面渲染

框架解决问题

  • 创建容器视图,提升交互体验
  • 异步加载渲染,提升页面渲染速度
  • prefetch 实例,优化网络、服务开销
  • 优化机制,优化细粒度模块速度

感知交互时间

点击搜索结果 => 页面响应

加速原理

传统页面

点击。连接。响应。基础渲染。内容渲染。组件加载。

加速

点击

​ A => 交互响应。基础渲染。。。。

​ B => 连接。响应。 。。。

。。。。内容渲染、组件加载

应用性能数据可视化

分享者:来自 mmTrix 的朱建锋

先是对可视化、性能等做了一些介绍,之后讲数据处理,科普了几种平均数,之后科普了各种常用的图(如雷达图、南丁格尔玫瑰图 etc.)。

前面

  • 尽量使用抗干扰性更好的方法计算性能数据
  • 标准差衡量性能标准

可视化是一个编码过程

  • 基本的简单的图。
  • 目的:表达数据。

请求理想时间小于 1s

  • DNS: 50ms
  • TCP shakes: 100ms
  • SSL(https): 300ms
  • Waiting for Response: 250ms(网络请求 => First Byte)
  • 接收 Data: 300ms

Hulu 的 React / Redux 构架实践

分享者:来自“美国的爱奇艺” Hulu 的程墨

较基础,但对于 Constraints vs Conventions 相关的内容非常不错,很值得思考。

Challenges

  • System Complexity
    • Legacy code in jQuery & Backbone
    • UI non-predictable
    • Lack of component isolation
  • Performance Bottleneck
    • Initial AJAX roundtrip

Tech Stack

  • Before: jQuery + Backbone + Ruby on Rails
  • After: React + Redux + Node & Express

Other Notes

  • React APP = Keep Rndering
  • UI = f(state)
  • Constraints vs Conventions

数亿级用户规模下的 React Native 应用实践

分享者:来自百度的雷志兴

做过一段时间的 RN,所以基本能听懂。

其他的内容,个人感觉可算干货满满。没提到热更新。

结合此前 58 同城 RN、携程 RN 等文章一起看,会更好的哈哈

手机百度

  • 迭代周期: 4周
  • 主要 features:数十个
  • 开发工时:数千人时
  • 跨部门,沟通成本高
  • 业务种类多,集成成本高
  • 过去的解耦方案
    • APK 插件 / SDK
    • Hybrid
  • 迭代速度:native 的 5-8 倍

RN 工程实践

  • 与现有业务融合
    • Android 4.1 以上
    • v0.32 以上不支持 iOS 7
    • 降级兼容:随时回撤;AB Test
    • 性能方面: 空间换时间,便利性换性能;减少重绘,减少通讯
    • 统一交互协议:RN 和 Native 相互之间的调用
  • 融入迭代流程
    • 首先,前提是业务方明确提出 RN 产品需求,明确哪些能够做到
    • 容灾方案:报错率较高怎么办?
    • 开发
    • 发布:打包、测试后由 PM 从平台发布
    • 监控:一定要能够监控到 RN 层,尤其是 js 层的报错信息(Note:坑!!!!!!!!)
  • 性能优化
    • 通讯频繁 by design: js 足够的灵活性
    • 易导致卡顿
      • 事件频率高
      • js 运行时间长
      • UI 绘制频繁
    • 初始化成本高
      • 生成模块配置表
    • ListView 优化
      • View 无法复用,内存紧张
      • DOM diff: 大量重新渲染
      • 业务层优化:预留空白单元;大量内容时重新渲染
      • 解决 1:删除非可视区 View
      • 解决 2:模板复用(item 可能跳动、闪烁)
      • 建议:产品进行限制,超过一定数量时重新刷新
    • 动画
      • 16ms,容易丢帧
      • 实验特性 userNativeDriver: true —— 将动画数据算好全部发给 Native,减少通讯
    • 启动速度优化
      • 预初始化:APP 启动后,立即 instance Init,用户点击的时候,就可以直接开始 js 业务
      • 首页业务多,instance 初始化过多,开销太大。
      • 单 Instance 多业务:Component 方法加载业务,无法使用 global
      • 按需加载:公用部分在初始化时加载,业务部分在交互时才开始加载
    • 延迟加载、渲染
  • 跨端方案对比
    • RN 适用场景
      • 超级 APP
      • 体验平台级 APP
    • Hybrid:…
    • APK 插件:…
  • Summary
    • 发版周期、开发成本和使用体验之间找到平衡
    • 系统性工程:有机融入 APP

Q&A

  • h5 和 RN 迭代的问题:两端齐头并进,各自开发
  • Native Module 问题上报:….
  • 非结构化 ListView 优化:RN 做的话,很难解决,结构样式尽量简单一些
  • RN 版本升级应对:RN 的 持续交付。。。

双十一 Weex 会场极致性能优化

分享者:阿里的冯成晓、周婷婷

终于面对面接触到 Weex 分享了。很久之前逢阿里面试官必问 Weex,想必他们烦极了。

和百度同学关于 RN 的分享两场一起听下来,真的收获多多。

印象非常好的一点是,分享过程中,反复提到 W3C 标准,提到希望补齐和 W3C 性能优化相关的 feature。这种思路应该是非常棒的。

  • f(HTML/CSS/JS) = Native UI
  • DSL(HTML/CSS/JS) -> Virtual DOM -> Renderer -> UI
  • Transformer: DSL -> JS Bundle
  • JSFramework: DOM Tree
    • 模板编译,数据绑定
  • Render:参照 Webkit
    • Build Tree
    • Compute Style
    • CSS Layout (… Reflow, Relayout)
    • Create View
    • Update Frame
    • Set View Props (… RePaint)
    • Native View

优化

  • 下载 js: 预加载
  • 执行 js:单 context 共享
  • 解析 DOM: Node & Tree 解析结合
  • 渲染 UI: List & 异步渲染(内存复用,只会渲染可见部分)
  • 全局污染治理 + JSCore 内存管理

性能优化指标

  • 秒开率:加载时间+首屏时间 < 1s
    • 加载时间:js bundle 加载时间
  • Weex 会场页面数:1700+,占比 99.6%
  • 主会场 FPS:低端机 53, 高端机58
  • 动画、视频、直播、全景图都是 Weex

实战部分

  • 列表过长,WebView 内存不好控制,容易 crash
  • 加载 js bundle:本地 IO 最快
    • APP 启动,预先下载 js
    • 长连接通道 Push
    • 全量/增量,被动/强制更新结合
  • 预加载使用策略
    • 根据业务特性斟酌
    • 1700 个页面,由相同模板自由组合变成的
    • 模块化,小粒度缓存
    • 原来:1600 * 55 = 93 M
    • 模块 + 配置:1700 5 + 30 10 = 8.8 M
    • 但是模块 +配置这样的秒开率低了 10%
    • 业务个性化预加载,根据进入场景下载:类似
    • preload & prerender:
      • dns-prefetch
      • preconnect(DNS + TCP connect)
      • prefetch
      • subresources(depreciated)
      • preload
      • prerender
  • js 执行
    • 安卓下 V8 解析 js 耗时
    • 减少 bundle size:去重,分离,通用组件内置
    • 减少 VDOM 更新
      • shouldComponentUpdate
      • pureRenderMixin
  • 动态数据并行预加载
    • 点击时直接请求,然后存储在 storage 中(文蔺注:这块儿好像可以参考手机 QQ 家校 or 兴趣部落 React 的优化的文章)
    • storage LRU 策略
    • 首屏数据请求参数不固定?。。。
    • jsbundle 走本地,效果如何?。。。
    • 优化效果 80% 以上
  • 首屏 UI 渲染
    • 使用 list 代替 scroller
    • 尽量减少布局嵌套
    • 首屏以外的模板延迟初始化
    • 新方案:requestIdleCallback
  • 最佳实践
    • 尽量 prefetch
    • use list
    • cell 细粒度拆分
    • 减少首次加载内容
    • 减少 js 大小
  • 工具
    • Xcode simulator
    • Safari 10 Remote Inspector
  • 性能指标优化流程(图)
    • 发布基线
    • 预发检测
    • 线上监控
    • 生成报表 <=== 业务达标基线
    • 问题分析
    • 开发修复
    • 预发检测
    • 。。。。
  • Week 下一阶段
    • W3C 性能优化 feature 补齐
    • 性能 profile
    • 完整开发模式
    • 更丰富的交互体验
    • 更丰富的 module 和 component

本文作者:文蔺
本文地址:http://www.wemlion.com/2016/velocity-2016-note-1/
转载请注明来源