Blog
Blog copied to clipboard
berwin
记录成长的过程
# 聊聊我对现代前端框架的认知 最近看到一篇国外的文章，说现代JS框架存在的根本原因是保持UI与状态同步、这其实与我这篇文章的思想是一致的，同时也印证了我对现代前端框架的认知是正确的。 --------------------------- 我是分割线 2018年6月18 更新，下面是原文 ---------------------- 现在前端界有三大框架横行，Vue，React，Angular，几乎是所有身为一名前端工程师所必备的一项技能。 但是我不知道有多少人仔细思考过为什么会这样？ 现在的一些应届生和刚入行的人们，在刚一踏入前端这个行业起就会面临着是学习Vue还是学习React又或者是学习Angular等这样的选择问题。 事实上在早几年是没有这个问题的，我们不需要选择，那时候我们写前端就是jQuery一把梭，就是干，干就完了。  ### 那为什么现在人们需要选择各种框架了呢？ 其实之所以现在我们需要选择框架，本质上是因为我们面临的需求变了。大家肯定都明白如果我们只写一个纯展示信息的页面，没有任何交互功能的页面，其实即便是现在，我们也是不需要选择框架的，我们只需要写几行CSS和HTML就可以完成任务。 所以是因为我们面临的需求变得复杂了，我们的应用经常需要在**运行时**做一些交互。 这里面有三个很重要的字我标了粗体，叫做运行时（Runtime）。现代的前端开发，我们开发的应用经常需要在**运行时**来做一些交互，这些交互在早期只是个幻灯片或者Tab切换下拉菜单等一些简单的交互，这些交互用jQuery实现完全没什么问题。但现代的前端我们的目标是用Web去PK原生应用，去和Native进行PK。 那这个时候我们会发现用jQuery来开发应用，我们的代码变得很难以维护，那为什么使用现代框架比如Vue，React等就变得容易维护了呢？ 这里面请容我讲一个故事，一个小插曲，前几天我在一个微信群里面有人讨论，Vue和jQuery的区别是什么，有人非常强烈的说什么差别是Vue有组件，有什么这个那个的一些特性。 当时我在微信群里说了我的观点，我说Vue和jQuery之间的区别只有一点，**声明式与命令式**。 我们可以想一下，我们用jQuery去操作DOM的目的是什么？是为了**局部更新视图**，换句话说是为了**局部重新渲染**。 jQuery是命令式的操作DOM，命令式的局部更新视图，而现代主流框架Vue，React，Angular等都是声明式的，声明式的局部更新视图。 为什么声明式的操作DOM就可以让应用变得好维护了呢？ 弄明白这个问题首先我们先简单介绍下什么是命令式，什么是声明式。 ### 命令式 命令式，像jQuery，我们都是想干什么然后就去干就完了，例如下面的代码： ```javascript $('.box')...
# 关于“放量” 所谓放量其实就是灰度发布，不过在我们组内部喜欢叫“放量”。关于放量其实有很多种规则：时间、地区、用户区间、随机放量等。 ## 为什么要放量 放量只有在大流量的C端项目中才有这个需求，流量小的产品或者公司内部使用的管理系统通常不需要做放量。 这里衍生出一个问题“为什么大流量C端项目需要做放量？”。 以某门户网站为例，假设去年日均PV是二个亿，一年的总收入是30亿人民币。 那么可以推算出，如果不做任何改动的情况下，今年的收入和去年比不会有太多的波动；但是部门给规定的目标通常要高于去年的收入，所以产品需要做一些事情来增加收入。  图1 - 某门户网站简笔画 经过一系列调研与讨论，最终决定把图中红圈的位置做一个改动，希望这个位置可以得到更好的商业化效果，提升一些收入。 但我们并不知道这个改动的结果是正面的还是负面的，如果这个改动上线之后导致了负面效果（用户很讨厌这个改动，疯狂骂我们），不但没增加收入反而降低了收入，这个后果是非常严重的。 所以我们通常会做一件事就是“放量”，先小规模放10%的量看看效果如何。 这里的放量通常又根据不同的情况分好几种： 1. 按用户区间放量（这是我们最常用的放量方案）。 2. 按地域放量（例如某些功能只放量给北京地区的用户）。 3. 按时间放量（双十一期间页面会做一些开屏动画之类的活动效果，一般都是提前开发好，在指定的时间段内放全量）。 地域放量与时间放量很容易理解，这里主要解释下什么是按**用户区间**放量。  图2 - 放量10%的用户 假设我们的产品总共有10亿个用户，放量10%，那么我们可以选择一个区间，是放给`0~1亿`这个区间的用户还是放给`1亿~2亿`这个区间，这个就是**用户区间**。 >...
# 让你的网页更丝滑（一） 前段时间，我将精力专注在Web性能领域；在这个领域下有个重要的课题是如何让网页更丝滑（流畅）。 想让网页变得丝滑，首先，我们需要一个标准来判断什么样的网页是丝滑的；其次，我们要准确的测量出网页的性能数据；最后，使用有效的方法让网页变得丝滑。 本篇文章将针对这三个方面进行详细的介绍。 ## 1. RAIL 到底怎样的网页是丝滑的？我们需要一个标准来辅助判断我们的网页是否丝滑。 Chrome团队提出了一个以用户为中心的性能模型被称为RAIL，它为工程师提供一个目标，只要达到目标的网页，用户就会觉得很流畅；它将用户体验拆解为一些关键操作，例如：点击，加载等；并给这些操作规定一个目标，例如：点击一个按钮后，多长时间给反馈用户会觉得流畅。 RAIL将影响性能的行为划分为四个方面，分别是：Response（响应）、Animation（动画）、Idle（空闲） 与Load（加载）。没错，RAIL这个名字来自于这四个单词的首字母，方便记忆。 ### 1.1 响应（Response） 研究表明，**100ms**内对用户的输入操作进行响应，通常会被人类认为是立即响应。时间再长，操作与反应之间的连接就会中断，人们就会觉得它的操作有延迟。例如：当用户点击一个按钮，如果**100ms**内给出响应，那么用户就会觉得响应很及时，不会察觉到丝毫延迟感。 ### 1.2 动画（Animation） 现如今大多数设备的屏幕刷新频率是60Hz，也就是每秒钟屏幕刷新60次；因此网页动画的运行速度只要达到60FPS，我们就会觉得动画很流畅。 F（Frames） P（Per） S（Second） 指的画面每秒钟传输的帧数，60FPS指的是每秒钟60帧；换算下来每一帧差不多是16毫秒。 ``` (1 秒 = 1000 毫秒)...
# 深入浅出 - vue之State 本文讲的内容是 vue 1.0 版本~ 有些同学可能不知道state是什么，可能还会有疑问，这个跟vuex中的state是不是有啥联系？ 在vue文档当中没有在任何地方提到过关于`state`这个单词，所以同学们发蒙是正常的，不用担心 所以在一开始我先说说state是什么以及它都包含哪些内容。 ## State state 是源码当中的一个概念，State中包含了大家非常熟悉的`Props`、`Methods`、`Data`、`Computed`，vue内部把他们划分为state中方便管理 所以本篇文章会详细介绍State中这四个大家常用的api的内部是怎样工作的 ## Methods Methods 在我们日常使用vue的时候，使用频率可能是最高的一个功能了，那么它的内部实现其实也特别简单，我先贴一段代码 ```javascript Vue.prototype._initMethods = function () { var methods = this.$options.methods...
2017年终总结
# 2017年终总结 转眼间又是一年，还有三天2017年就过去了，时间过的还真快，我甚至一度觉得2017年一月份才刚过去没多久的样子，去年写年度总结时的画面在我脑海中还那么的清晰。 ## 关于技术 关于技术我自己感觉今年最大的成长是**抽象能力**的提升。 去年的这个时候我曾拼命的想知道如何写出更优雅的代码，为此我看了好几本设计模式的书和一些文章。结果不是特别的理想，但也不能说没有用，模仿着也能写出类似的代码，但是总觉得代码缺少了什么，后来我才知道，缺少的是**灵魂**。 今年，我慢慢的发现我写的代码开始慢慢的具备一些灵性了，已经不再是模仿设计模式来写代码，而是真正的可以按不同的需求去合理的抽象与组织代码，学习过的设计模式也已经忘了，但写出的代码反而具备了设计模式的精髓，有一种无招胜有招的感觉，自己与自己写出来的代码之间莫名的有一丝丝的感应，我觉得这就是有灵魂的代码吧。 ### javascript 今年读完了 You-Dont-Know-JS 系列的书，对 JS 的一些细节，之前没有关注到的部分进行了一个知识补充。 ### ES6 去年读过了《understanding ECMAScript6》后，今年有人把这本书翻译成了中文的，我就买了一个本把中文版的又重新读了一遍。反复读过几次在加上平时工作中经常用，已经可以熟练应用了。 ### Vue 今年把 Vue2.0 的代码重新读了一遍，Vue2.0 新增了很多特性。 我学习了其中的 **模板编译原理** 和 **virtualDOM** 原理。...
图像优化原理
# 图像优化原理  我们都喜欢有图片的网页，图片很美好，很有趣，同时它涵盖了丰富的信息。所以，在加载网页时，大部分流量被图像资源所占据（平均60%，数据可能不准确）。 图像资源不只占用网络资源，它也会占用网页中大量的视觉空间。所以图像渲染的速度会直接影响用户体验。图像优化其实就是最大限度地减少图像的字节数，从而最大化地缩减网络资源占用，使浏览器下载速度变的更快。下载速度越快，在屏幕上渲染的时间就越早，所以视觉上就会有一个更好的体验。 当然，优化图像最佳的方式就是**不用图像**，例如使用CSS效果（渐变，阴影，圆角等）代替图像。使用CSS比同等视觉效果的图像资源的字节数要小非常多，这是毋庸置疑的。另一个好处是CSS不受分辨率影响，使用CSS渲染出的视觉效果可以在任何分辨率和缩放级别下始终清晰地显示。 但必须使用图像资源时，对图像进行合理的优化将对性能有着至关重要的影响。 本文不会介绍如何进行图像优化，有大量在线工具和开源项目供我们使用，使用起来非常的简单。本文将重点介绍图像优化的原理。 首先，本文会介绍两种图像资源：矢量图与栅格图（位图），并分别介绍优化它们的原理。随后介绍无损压缩与有损压缩以及它们的区别。在本文的最后，我们会介绍什么是高分辨率屏幕。 希望通过本篇文章的介绍，可以让您对图像优化的原理有一个直观的感受。 ## 1. 矢量图与栅格图（位图） 矢量图与栅格图（位图）是两种不同的图像格式。  图1-1 矢量图与栅格图 * 矢量图形是计算机图形学中用点、直线或者多边形等基于数学方程的几何图元表示图像。 * 栅格图（英语：Raster graphics），又称位图（Bitmap）或点阵图，是使用像素阵列(Pixel-array/Dot-matrix点阵)来表示的图像。 以矢量图为例，程序绘制一个半径为`r`的圆所需的主要信息是： 1. 半径r 2. 圆心坐标 3. 轮廓样式与颜色（可能是透明） 4....
# 前端日志上报的新姿势“Beacon”  在前端应用越来复杂的今天，为了监控前端应用是否正常运行，通常会在前端收集一些错误与性能等数据，最终我们会将这些数据上报到服务端。 上报的方式有很多，理论上我们只要能把数据发给服务端就行了。在浏览器中可以发送请求的方式非常多，包括不限于：`xhr`、`fetch`、`script`标签、`img`标签、`link`标签、CSS背景图等。 不同的上报方式之间存在很大的差异。目前主流的上报方式是利用`img`标签的`src`属性发送请求，例如： ```javascript (new Image).src = `/haopv.gif?a=xx&b=xxx` ``` 因为日志上报不需要响应处理，只需要把数据发过去就行。并且大部分接收日志的服务器地址与业务方可能不是一个部门，甚至可能不是一个公司，所以会涉及到跨域问题。使用`img`标签的`src`属性既可以把数据发送给服务端又不需要接收响应，同时解决了跨域问题，所以是目前比较受欢迎的日志上报实现方式。 但是这样就真的没问题了么？ 日志上报并不是应用的主要功能逻辑，也就是说，日志上报是低优先级的，它不应该与其他高优先级操作（例如：获取关键资源、输入响应、运行动画等）去竞争网络与计算资源（通俗的说就是日志上报行为不应该影响业务逻辑，不应该占用业务计算资源）。但是这种单向请求又负责传递应用的错误与性能数据，所以我们必须要确保它会被交付到服务端。 通常，为了提高交付率，我们会选择立即交付每个收集到的数据，而不是合并与推迟交付。延迟传递可能意味着请求没有足够的时间来成功完成，这可能导致重要的应用数据丢失。并且推迟上报会影响下一个页面的下载与渲染，因为`unload`事件中的代码会阻塞下一个页面渲染。 这就意味着我们的交付行为有可能会被插入到正在忙碌工作的事件循环中，从而抢占了其他高优先级的任务的资源，因为JS是单线程的。这有可能会损害用户体验。 我们如何确保日志数据会被交付的同时，尽可能地减少与其他关键操作的资源争用呢？答案是信标（Beacon）。 ## 信标（Beacon） 信标（Beacon）可以异步与非阻塞的数据传输，从而最大限度地减少与其他关键操作的资源争用，同时它可以确保这些请求一定会被处理并将其传递到服务端： * 信标请求优先避免与关键操作和更高优先级的网络请求竞争。 * 信标请求可以有效地合并，以优化移动设备上的能量使用。 * 保证页面卸载之前启动信标请求，并允许运行完成且不会阻塞请求或阻塞处理用户交互事件的任务。 信标的使用非常简单： ```javascript...
深入浅出 - Redux
# 深入浅出Redux 最近在学习redux，现在把自己对redux的理解总结出来分享给大家。 ## 介绍 redux是管理State的一个东东，所有State都需要经过redux来操作。 ## 基本概念 redux中有三个基本概念，Action，Reducer，Store。 ### Action #### 官方的介绍： Actions are payloads of information that send data from your application to your store. They are the...
css元素隐藏
``` css { display: none; /* 不占据空间，无法点击 */ } ``` ``` css { visibility: hidden; /* 占据空间，无法点击 */ } ``` ``` css { position: absolute; clip:rect(1px 1px 1px 1px); /*...
# Git ## 版本控制系统 版本控制系统（version control system，VCS）,版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。历史上出现过各种各样的VCS：如1982年的RCS，现在你还可能在Unix的发布中找到它,1985年的PVCS,1990年底的CVS,1992年的clearcase,微软的VSS（welcome to Hell）,90年代中期的Perforce，以及SVN和BitKeeper，还有我们即将介绍的git. 版本控制系统出现的原因是由实际需求推动的。在没有VCS的情况下，我们维护版本的方法是复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就没法撤销恢复。解决这个问题的方法是开发版本控制系统，采用某种简单的数据库来记录文件的历次更新差异的来实现。 ### 集中式版本控制系统 集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ），有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连接到这台服务器，取出最新的文件或者提交更新。这类系统，诸如 CVS，Subversion 以及 Perforce 等。优点是每个人都可以在一定程度上看到项目中的其他人正在做些什么，而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易；缺点是中央服务器的单点故障有丢失数据的风险。 ### 分布式版本控制系统 分布式版本控制系统（ Distributed Version...