cnblogsArticle
cnblogsArticle copied to clipboard
chokcoco
自己博客园一些写得比较好的文章移植，欢迎订阅。
## 区块链1.0 区块链1.0是以比特币为代表的数字货币应用，其场景包括支付、流通等货币职能。 主要具备的是去中心化的数字货币和支付平台的功能，目标是为了**去中心化**。 #### 去中心化存在的误区 当然，现在很多人对去中心化存在很大的理解偏差。 去中心化的英文单词是 Decentralized 。但其实翻译过来为**分散**，而非**去中心化**。 区块链是一种软件系统，而软件系统的网络架构一般有三种模式：单中心、多中心、分布式。单词 Decentralized 只是表明不是单中心模式，可能为多中心或弱中心，也可能是分布式的。 在中国台湾地区，大多将 Decentralized 翻译为“分散式的”而不是“去中心化”。 所以关于去中心化，绝大多数人还是误解颇深。 所谓的去中心化，并不是“消灭所有的中心”。在现实里，实际上是这样的：由“原本只有少量的大中心”，慢慢演化成“有大量的更小规模的中心”。也就是分散，Decentralized 的原意。 #### 区块链1.0架构  典型: 1. BTC 2. LTC ### 区块链1.0的局限 +...
最近有关区块链的文章越来越多，发现现在很多人对区块链，比特币存在很多理解误差，遂打算好好全面的捋一捋相关知识。感兴趣可以继续读下去，可能会涉及到： + 区块链基本知识 + 区块链1.0到3.0的进化 + 疯狂的虚拟货币 + 区块链应用及 ICO 比特币是由一系列概念和技术作为基础构建的数字货币生态系统。 先介绍一些相关概念： ## 区块链与比特币 大部分人提及到区块链，第一反应肯定是比特币，只不过，区块链发展到现在，经历了区块链1.0 到 3.0 。甚至已经有打着区块链4.0口号的区块链应用出现。 区块链早已不再是比特币这么简单，我们通常习惯将不是比特币的其他区块链币种统称为山寨币，那么现在一共有多少种山寨币呢？ 不完全统计，上[非小号](https://www.feixiaohao.com/)可以查询到的山寨币，截止至本文撰写的时候，已经达到了1900+ 多种。并且，这个数字还在以日为单位飞涨中。 ## 到底何为区块链 那么，到底何为区块链呢？ 区块链是一种**不可篡改**的、**去中心化**的、共享的数字化**分布式账本**，用于记录公有或私有对等网络中的交易。账本分发给网络中的所有成员节点，在通过哈希密码算法链接的区块的顺序链中，永久记录网络中的对等节点之间发生的资产交易的历史记录。 所有经过确认和证明的交易都从链的开头一直链接到最新的区块，因此得名区块链。区块链可以充当单一事实来源，而且区块链网络中的成员只能查看与他们相关的交易。 当然，区块链还有一些其他特定，譬如**匿名性**、**全球性**。 ## 不可篡改 不可篡改这个很好理解，区块链记录的信息无法被篡改。对于传统中心化的服务来说，我们为客户提供服务，每个应用有自己的服务器，我们的信息存储在服务器的数据库上，要篡改我们的信息只需要修改数据库就好了。...
在上一篇文章中，我们初步实现了一些利用基本图形就能完成的线条动画： [【Web动画】SVG 线条动画入门](http://www.cnblogs.com/coco1s/p/6225973.html) 当然，事物都是朝着熵增焓减的方向发展的，复杂线条也肯定比有序线条要多。 所以，很多时候，我们无法人工去画出一些十分复杂动画的线条，这个时候，就要借助我们前端的好帮手 PS 和 AI：  好了，假定我们现在要制作下图 GIF 这样的一个 loading 图：  上面这个 SVG 线条动画的路径 `path` ，如果靠自己手工一个点一个点定位调试画出来的话，嘿嘿嘿你去试试。  ## 使用 PS 导出路径 估计靠手工能画出来，也没了大半条命。好，轮到工具上场，看看我们的原图在 PS 下长什么样子（支持透明通道的 PNG、GIF 为佳）：...
我们知道，动画其实是由一帧一帧的图像构成的。有 Web 动画那么就会存在该动画在播放运行时的帧率。而帧率在不同设备不同情况下又是不一样的。 有的时候，一些复杂或者重要动画，我们需要实时监控它们的帧率，或者说是需要知道它们在不同设备的运行状况，从而更好的优化它们，本文就是介绍 Web 动画帧率（FPS）计算方法。 ## 流畅动画的标准 首先，理清一些概念。FPS 表示的是每秒钟画面更新次数。我们平时所看到的连续画面都是由一幅幅静止画面组成的，每幅画面称为一帧，FPS 是描述“帧”变化速度的物理量。 理论上说，FPS 越高，动画会越流畅，目前大多数设备的屏幕刷新率为 60 次/秒，所以通常来讲 FPS 为 60 frame/s 时动画效果最好，也就是每帧的消耗时间为 16.67ms。 >当然，经常玩 FPS 游戏的朋友肯定知道，吃鸡/CSGO 等 FPS 游戏推荐使用 144HZ 刷新率的显示器，144Hz 显示器特指每秒的刷新率达到...
性能优化一直是前端工作中十分重要的一环，都说从 10 到 1 容易，从 1 到 0 很难。而随着前端技术的飞速发展，没有什么技术或者法则是金科玉律一沉不变的。 很佩服那些勇于挑战权威，推陈出新的勇者，是他们让我们的技术不断的变革更加的卓越。好像扯远了，本文主要想谈谈两个名词，域名发散和域名收敛。 ## 域名发散 这个很好理解，前端er都知道，PC 时代为了突破浏览器的域名并发限制，遵循这样一条定律： ###### http 静态资源采用多个子域名 嗯，为什么要这样做呢，目的是充分利用现代浏览器的多线程并发下载能力。 由于浏览器的限制，每个浏览器，允许对每个域名的连接数一般是有上限的，附图一枚：  上图展示了各浏览器的并行连接数（同域名），可以看到在一些现代浏览器内每个 hostname 的最大连接数基本都是6个，IE 稍显傲娇，总体而言并发数不高。 所以 PC 时代对静态资源优化时，通常将静态资源分布在几个不同域，保证资源最完美地分域名存储，以提供最大并行度，让客户端加载静态资源更为迅速。 另外，为什么浏览器要做并发限制呢？ - 究其根本原因，在以前，服务器的负载能力差，稍微流量大一点服务器就容易就崩溃。...
本文是内部的一次分享沉淀，偏向基础但是涉及了一些有意思的细节，文笔有限，才疏学浅，文中若有不正之处，万望告知。 前端的一大工作内容就是去兼容页面在不同内核的浏览器，不同的设备，不同的分辨率下的行为，使页面的能正常工作在各种各样的宿主环境当中。 而本文的主题 -- **移动端开发的兼容适配与性能优化**，就是希望能从一些常见的移动端开发问题出发，厘清 Web 移动端开发的前前后后，一些技术的发展过程，一些问题的优化手段以及给出一些常见的兼容性问题的解决方案。 ## 什么是响应式设计 首先先聊聊响应式设计，这个与移动端开发有着密切的联系。 响应式设计即是 RWD，Responsive Web Design。 这里百度或者谷歌一下会有各种各样的答案。这里一段摘自知乎上我觉得很棒的一个答案：[什么是响应式布局设计？](https://www.zhihu.com/question/20976405) 根据维基百科及其参考文献，理论上，响应式界面能够适应不同的设备。描述响应式界面最著名的一句话就是“Content is like water”，翻译成中文便是“如果将屏幕看作容器，那么内容就像水一样”。 ### 为什么要设计响应式界面 为什么要费神地尝试统一所有设备呢？ + 即便是PC或Mac用户，有查显示只有一半的人会将浏览器全屏显示，而剩下的一般人使用多大的浏览器，很难预知； + 台式机、投影、电视、笔记本、手机、平板、手表、VR……智能设备正在不断增加，“主流设备”的概念正在消失； + 屏幕分辨率正飞速发展，同一张图片在不同设备上看起来，大小可能天差地别； + 鼠标、触屏、笔、摄像头手势……不可预期的操控方式正在不断出现。...
之前学习 react+webpack ，偶然路过 [webpack 官网](https://webpack.github.io/) ，看到顶部的 LOGO ，就很感兴趣。 最近觉得自己 CSS3 过于薄弱，想着深入学习一番，遂以这个 LOGO 为切入口，好好研究学习了一下相关的 CSS3 属性。webpack 的 LOGO 动画效果乍看不是很难，深入了解之后，觉得内部其实大有学问，自己折腾了一番，做了一系列相关的 CSS3 动画效果。 先上 [demo](http://chokcoco.github.io/demo/css3demo/html/index.html) ，没有将精力放在兼容上，请用 chrome 打开。 本文完整的代码，以及更多的 CSS3 效果，在我 [github](https://github.com/chokcoco/css3-) 上可以看到，也希望大家可以点个...
最近在研究页面渲染及web动画的性能问题，以及拜读[《CSS SECRET》](https://github.com/cssmagic/CSS-Secrets)（CSS揭秘）这本大作。 本文主要想谈谈页面优化之滚动优化。 主要内容包括了为何需要优化滚动事件，滚动与页面渲染的关系，节流与防抖，pointer-events:none 优化滚动。因为本文涉及了很多很多基础，可以对照上面的知识点，选择性跳到相应地方阅读。 ## 滚动优化的由来 滚动优化其实也不仅仅指滚动（scroll 事件），还包括了例如 resize 这类会频繁触发的事件。简单的看看： ``` javascript var i = 0; window.addEventListener('scroll',function(){ console.log(i++); },false); ``` 输出如下：  在绑定 scroll 、resize 这类事件时，当它发生时，它被触发的频次非常高，间隔很近。如果事件中涉及到大量的位置计算、DOM 操作、元素重绘等工作且这些工作无法在下一个 scroll 事件触发前完成，就会造成浏览器掉帧。加之用户鼠标滚动往往是连续的，就会持续触发...
这篇文章实在是很难下笔，因为网上相关文章不胜枚举。 巧合的是前些天看到阮老师的一篇文章的一句话： “对我来说，博客首先是一种知识管理工具，其次才是传播工具。我的技术文章，主要用来整理我还不懂的知识。我只写那些我还没有完全掌握的东西，那些我精通的东西，往往没有动力写。炫耀从来不是我的动机，好奇才是。" 对于这句话，不能赞同更多，也让我下决心好好写这篇，网上文章虽多，大多复制粘贴，且晦涩难懂，我希望能够通过这篇文章，能够清晰的提升对apply、call、bind的认识，并且列出一些它们的妙用加深记忆。 ## apply、call 在 javascript 中，call 和 apply 都是为了改变某个函数运行时的上下文（context）而存在的，换句话说，就是为了改变函数体内部 this 的指向。 JavaScript 的一大特点是，函数存在「定义时上下文」和「运行时上下文」以及「上下文是可以改变的」这样的概念。 先来一个栗子： ``` javascript function fruits() {} fruits.prototype = { color: "red", say: function() {...
前端同学可能向来对爬虫不是很感冒，觉得爬虫需要用偏后端的语言，诸如 php ， python 等。 当然这是在 nodejs 前了，nodejs 的出现，使得 Javascript 也可以用来写爬虫了。由于 nodejs 强大的异步特性，让我们可以轻松以异步高并发去爬取网站，当然这里的轻松指的是 cpu 的开销。 要读懂本文，其实只需要有 - 能看懂 Javascript 及 JQuery - 简单的 nodejs 基础 - http 网络抓包 和 URL...