班会第 15 期 #17

ufologist · 2016-07-01T09:35:15Z

技术
- weex 正式开源了
  
  将所有 demo 跑了一遍, 觉得 HTML5 渲染引擎下比较卡(特别是 list-demo.we), 感觉好像施加了太多魔法有点罩不住...
- 使用Flexible实现手淘H5页面的终端适配
  简述基于 Flexible 的适配方案
  - 在页面中使用 flexible.js
  - 不要设置 <meta name="viewport">
  - 设计稿的宽度(px 单位), 例如: 750px(iPhone6)
  - 测量元素在设计稿中的尺寸(px 单位), 例如: 120px * 150px
  - 页面中的元素使用 rem 单位
  - 单位计算公式: 元素尺寸rem = 元素设计稿尺寸px / (设计稿宽度px / 10)
  - 例如:
    // 页面中的元素使用 rem 单位 120px / (750px / 10) = 1.6rem // 适配的 rem 基准值 html font-size = deviceWidth / 10 // flexible.js 会先设置 meta viewport scale, 再设置 html font-size // 注意这里取 getBoundingClientRect 是在 width=device-width 没有 scale 的情况下 html font-size = (docEl.getBoundingClientRect().width * dpr) / 10 // flexible.js 设置了 meta viewport scale 后, 不需要乘以 dpr, 即为 deviceWidth // 例如 iPhone6 的 dpr 为 2, 即 scale = 1 / 2 = 0.5 // 主要是通过整体缩放来做出 0.5px 边框的效果, 否则出来的 1px 边框像是 2px // 在 scale 为 0.5 的情况下, docEl.getBoundingClientRect().width 得到的是 750px html font-size = docEl.getBoundingClientRect().width / 10 // 所以页面中的元素最终才能转回到正确的 px 单位 120px = 1.6rem * (375px * 2 / 10) 120px = 1.6rem * (750px / 10) 120px = 1.6rem * (设计稿的宽度 / 10)
  日常工作当中，视觉设计师给到前端开发人员手中的视觉稿尺寸一般是基于 640px(iPhone5)、750px(iPhone6)以及 1125px(iPhone6 Plus) 宽度为准。至于为什么？大家应该懂的（考虑Retina屏）。
  
  iPhone6的设备宽度和高度为 375pt * 667pt,可以理解为设备的独立像素；而其dpr为2，根据上面公式，我们可以很轻松得知其物理像素为 750pt * 1334pt。
  
  在不同的屏幕上，CSS像素所呈现的物理尺寸是一致的，而不同的是CSS像素所对应的物理像素具数是不一致的。在普通屏幕下1个CSS像素对应1个物理像素，而在Retina屏幕下，1个CSS像素对应的却是4个物理像素。
  
  为了应对这多么的终端设备，设计师和前端开发之间又应该采用什么协作模式？
  
  手淘设计师和前端开发的适配协作基本思路是：
  - 选择一种尺寸作为设计和开发基准
  - 定义一套适配规则，自动适配剩下的两种尺寸(其实不仅这两种，你懂的)
  - 特殊适配效果给出设计效果
  大致流程:
  - 手淘设计师常选择 iPhone6 作为基准设计尺寸
  - 交付给前端的设计尺寸是按 750px * 1334px 为准(高度会随着内容多少而改变)
  - 前端开发人员通过一套适配规则自动适配到其他的尺寸
  - 移动端适配的方案——flexible方案
    - 动态改写 <meta> 标签(不需要在代码中写 viewport)
    - 给 <html> 元素添加 data-dpr 属性，并且动态改写 data-dpr 的值
      
      只对 iOS 设备进行 dpr 的判断，对于 Android 系列，始终认为其 dpr 为 1
      
      主要是因为安卓的 dpr 分类太多了(不只是有1,2,3还有1.5之类的)
    - 给 <html> 元素添加 font-size 属性，并且动态改写 font-size 的值
    - 页面中的元素通过 rem 单位来设置尺寸
    - 将视觉稿分成100份（主要为了以后能更好的兼容vh和vw），而每一份被称为一个单位a。同时1rem单位被认定为10a
    - 如无特殊情况，width/height/padding/margin 都使用 rem，border-width 和 font-size 使用 px
    - 文本字号不建议使用rem, 而是使用 px 作为单位。只不过使用[data-dpr]属性来区分不同dpr下的文本字号大小
      
      我们在iPhone3G和iPhone4的Retina屏下面，希望看到的文本字号是相同的
      
      我们不希望文本在Retina屏幕下变小
      
      我们希望在大屏手机上看到更多文本
      
      绝大多数的字体文件都自带一些点阵尺寸，通常是16px和24px，我们不希望出现13px和15px这样的奇葩尺寸
      
      并不是绝对, 还是需要分场景的来决定是使用 px 还是 rem
    - 请不要再使用 CSS Sprites, 移动互联网时代需要合理利用 Sprite 不然反对性能造成影响(解码内存消耗)
  示例:
  - 750px 的设计稿: 1rem = (750 / 100) * 10 = 750 / 10 = 75, <html> 对应的 font-size 即 75px
  - 对于视觉稿上的元素尺寸换算，只需要原始的 px 值除以 rem 基准值即可
  - 例如视觉稿中的图片尺寸是 120px * 120px, 120(原始px) / 75(rem基准值), 即 1.6rem * 1.6rem
  移动端高清、多屏适配方案
  
  很明显可以看出，rem适配的各个区块的宽高都会随着手机屏宽而改变，最最明显的可以看一下图片列表那部分，最后一张图视觉稿要求只出现一点点，rem布局在任何屏幕下都显示的很好。
- 提升你的CSS姿势
  CSS的学习是一个典型的低门槛，高瓶颈的过程，第一次接触CSS的时候觉得一切是如此简单，直到后面越学越发现自己一无所知。本文则是从四个方面来讨论如何编写可扩展、可维护的CSS代码：
  - 使用合理的语义化命名
  - 模块化
  - 遵循命名规范
  - 遵循单一职责原则
    所以说理解 BEM, 用好 BEM, 你就是高手了
- css3d动画学习心得：一个小游戏实践
  
  游戏的demo
- JavaScript 节流函数 Throttle 详解
  
  给相应事件添加延迟执行的逻辑
- 从被误解到最流行：聊聊 JavaScript 的那些闪光点
  JavaScript 曾经是一门兼容性最糟糕、升级最困难的语言。然而在最近几年，随着 Babel 等编译器的兴起，越来越多的 JavaScript 开发者们都放开了手，开始在生产环境中使用那些尚未被纳入标准的语言特征了。使用了 Babel 的项目需要在发布之前引入一个「构建」的步骤，将使用了较新的语言特征的源代码转译为兼容性更好、被所有浏览器所支持的早期版本的 JavaScript，所以开发者就不必再去关心用户的浏览器是否支持这项新特征了。
  
  除了对 JavaScript 本身的增强，社区中还有着上百种编译成 JavaScript 的「方言」: CoffeeScript, TypeScript...
  
  JavaScript 的标准库仅包含了非常有限的功能，某种程度上来说这也是件好事 —— 精简的标准库给第三方库留出了充分的竞争空间，真正得到大家认可的库才会被广泛使用，而不仅仅因为它被包含在了标准库中。
  
  JavaScript 语言本身并没有定义得非常好的「范式」，你可以使用函数式的风格，还可以使用面向对象的风格
  
  JavaScript 不仅可以在浏览器中运行，因为它精简的语言核心（甚至不包括任何 IO 相关的功能），现在已经被移植到了其他很多平台：
  - Node.js：提供了访问文件系统、进行网络操作的 API，用于构建 Web 后端等服务器程序。
  - Ionic / Cordova：提供访问移动设备的 API，使用 Web 技术来构建移动应用。
  - Electron：让 JavaScript 可以同时访问 Web 和 Node.js 的 API，以便用 Web 技术来构建桌面应用。
  - React Native：用 JavaScript 去操作原生 UI 组件来构建移动应用。
- 去哪儿网司徒正美：avalon及通用MVVM的设计原理分析
  - MVVM出现的必然性: MVVM带来了维护性大大提高
  - MVVM与backbone等库的比较: MVVM的代表大概是angular, 而MVC则是backbone
  - MVVM的实现: 解决重点是如何实现最小化刷新, 核心是绑定系统
    - 定时器
    - 函数包裹
    - 属性劫持
    - 上帝setter,getter
    - 编译系统
    - 组件系统
- 链家网前端总架构师杨永林：我的8年架构师成长之路
  
  前端架构师就是那种在前端领域提出开发的指导原则，在原则下设计开发框架和开发工具，让更多的开发者可以协同工作的人。
  
  前端构建工具哪个更好？你能掌握哪个，哪个就是最好的。因为说到底，工具是为你的业务服务的，你可能需要对它做些改造或者是写一些扩展，在这个时候你发现你对他的熟悉变的很重要。构建工具的迁移成本还是挺高的，我不太推荐频繁地变更它，所以最好不要追着流行走，还是要根据自己团队的特点，因地制宜地选择一款合适的。如果不是超大型的应用，其实build的结果的影响并没有太大的差异，与其想着哪个更好哪个更牛逼，不如将其中一个玩熟玩透。
  
  您认为对Web访问性能的优化需要关注哪些方面？一是你所服务产品的形态，用户关心什么。二是评测标准，用什么来测量性能的好坏。
  
  度量前端性能的指标有哪些？我们一般用首屏时间来评估，一般的性能检测服务商都能提供这个指标。在监控的过程中，一是要关注长期趋势的变化，如果不是突发状况，单点的数据的绝对值是没有意义的，要收集长期的数据，分析其中的变化，当有变更的时候尤其要关注数据的变化。二是关注最差25%的状况
  
  我们知道，解决一个问题的手段有很多，在这个过程中取舍就很重要了，我们也知道，没有银弹，很少能遇见那种全面优势的解决方案，大部分方案都是牺牲掉一部分东西来换取一部分东西。因此，作为架构师，不仅要对各个技术方案的特点、成本要熟知（也就是编程能力和架构知识），还要学会如何选择。显然，架构师需要根据产品的特点和发展方向做出决定，在前端领域的架构要能让配合的团队对接的顺畅。那么在这个过程中，良好的沟通能力、同理心、利他的思维方式，就显得很重要了。因为我们不仅要完成开发任务，也要思考在自己的领域内如何帮助项目解决问题。
- 15年双11手淘前端技术巡演 - H5性能最佳实践
  - 68.67%无线交易
  - 系统&网络环境统计数据(手淘2015)
  - 传统优化(PC时代YAHOO 23条web性能优化军规)
  - 请求数优化
  - 合理使用 iconfont
  - 首屏多个动态接口合并请求
    
    日常的业务中，一个页面往往拆分出多个异步数据接口（后端开发说：解耦），甚至首屏也需要3-5个接口（如动态banner区块，推荐内容，商品列表等），有些还有嵌套关系。但是这些对页面性能造成不小的影响
  - 禁止重定向
    
    页面&静态资源的重定向会造成巨大的性能损耗。特别使用前端JS脚本来实现页面跳转的。
  - 图片优化
    - 使用WebP格式, 为公司省 70% 的流量费用
    - CDN服务上生成各个尺寸和质量的图片（近100个规格）
      
      合理的使用CDN图片尺寸可以带来下载图片的性能提升，还可以减少不必要的内存消耗。我们日常中会用到的尺寸，每浪费10像素的宽高都可以造成很大的内存资源浪费。
    - 合理的生成紧凑的Sprite图片，即可以带来更少的请求数，又高性能低消耗
      
      解码内存消耗: w * h * 4(宽 * 高 * 每个像素4个字节)
  - 域名最终形态（建议）
    - 页面请求域名一个(html)
    - 静态资源(css, js)一个
    - 图片资源一个(img)
    - 动态数据一个(api)
    - 数据统计一个(stat)
  - 预加载和离线化方案
  2015 双11 战绩
- 好RESTful API的设计原则
  你所能做的最重要一件事来提高服务的价值就是创建一个API。因为随着其他服务的成长，有这样一个API会使你的服务或者核心应用将有机会变成一个平台。
  - 版本化
  - 过滤器
  - 预期的返回文档
  - 认证
  - 认识原始的HTTP封包
- Node.js
  Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine.
产品
- 微信用户属性
  - 总体设备比例
  - iOS版本比例
  - iOS设备比例
  - Android设备前5
  - Android版本比例