本文分为三个部分 JS 数字精度丢失的一些典型问题 JS 数字精度丢失的原因 解决方案（一个对象+一个函数） 一、JS数字精度丢失的一些典型问题 1. 两个简单的浮点数相加 1 0.1 + 0.2 != 0.3 // true Firebug 这真不是 Firebug 的问题，可以用alert试试 （哈哈开玩笑）。 看看Java的运算结果 再看看Python 2. 大整数运算 1 9999999999999999 == 10000000000000001 // ？ Firebug 16位和17位数竟然相等，没天理啊。 又如 1 2 var x = 9007199254740992 x + 1 == x // ？ 看结果 三观又被颠覆了。 3. toFixed 不会四舍五入（Chrome） 1 1.335.toFixed(2) // 1.33 Firebug 线上曾经发生过 Chrome 中价格和其它浏览器不一致，正是因为 toFixed 兼容性问题导致 二、JS 数字丢失精度的原因 计算机的二进制实现和位数限制有些数无法有限表示。就像一些无理数不能有限表示，如 圆周率 3.1415926…，1.3333… 等。JS 遵循 IEEE 754 规范，采用双精度存储（double precision），占用 64 bit。如图 意义 1位用来表示符号位 11位用来表示指数 52位表示尾数 浮点数，比如 1 2 0.1 […]
View Details背景： 这个问题不是一天两天了，有时候是网速不行，有时候是被墙了，有时候是github把node-sass的包转移目录导致下载失败。 Cannot download "https://github.com/sass/node-sass/releases/download/xxx/binding.node的问题 另附node-sass的binding.node各个版本的安装包，哪里少，就单独下载哪个，下载完了之后，跟着我，一起把文件放在指定位置即可解决这个问题 https://github.com/sass/node-sass/releases/tag/v4.7.2 1.本机位置 C:\Users\Administrator\AppData\Roaming\npm-cache\node-sass\ 这个里面是各种版本，报错提示你哪个版本下载失败，你就塞到哪个版本的文件夹里，如图所示 2.删除项目的node_moduls目录 3.重新npm install 4.另附全局安装命令
|
1 2 3 |
npm i sass-loader node-sass webpack <span class="hljs-comment">--g</span> npm i style-loader css-loader <span class="hljs-comment">--g</span> |
qq 43163707 落雨 本文地址:http://www.cnblogs.com/ae6623/p/8711853.html
View Details|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
var gulp = require('gulp'); var connect = require('gulp-connect'); var replace = require('gulp-replace'); function defaultTask(cb) { // place code for your default task here cb(); replaceTask(); connect.server({ root: "build", port:8888 }); connect.serverClose(); } function replaceTask(){ /*index*/ gulp.src(['./index.html']) .pipe(replace("@@{user_domain_url}", "http://user.domain.com")) .pipe(replace('@@{nickname}', 'gz')) .pipe(gulp.dest('build/')); /*js*/ gulp.src(['js/*.js']) .pipe(replace("@@{user_domain_url}", "http://user.domain.com")) .pipe(replace('@@{nickname}', 'gz')) .pipe(gulp.dest('build/js')); } exports.default = defaultTask; |
View Details
流程 1. 输入命令(可以使用git bash或者命令控制台cmd) npm install -g gulp 安装全局gulp命令 2. 创建一个项目文件夹, 当前项目文件夹下输入命令npm init 配置package.json文件, 这一部分看情况自己决定是否填, 不想填也可以, 直接按回车 当前项目文件夹下输入命令npm install gulp --save-dev 全局安装gulp后，还需要在每个要使用gulp的项目中都单独安装一次 开始使用gulp 其实, gulp的使用比webpack要简单很多. 配置gulpflie.js文件 在当前项目文件下创建文件名为gulpfile.js文件, 作为该项目配置文件.
|
1 2 3 4 5 6 |
//gulpfile.js var gulp = require('gulp'); gulp.task('default',function(){ console.log('hello world'); }); |
其实在项目文件夹下输入命令gulp时, 就是触发这个default任务, 因此, 我们定义多个自定义事件, 这样在输入gulp时, 就可以直接将我们写的命令也一起触发. gulp API gulp.src(globs[, options]) globs参数是文件匹配模式(类似正则表达式)，用来匹配文件路径(包括文件名)，当然这里也可以直接指定某个具体的文件路径。当有多个匹配模式时，该参数可以为一个数组。 options为可选参数。通常情况下我们不需要用到。 下面我们重点说说Gulp用到的glob的匹配规则以及一些文件匹配技巧。 名称 说明 * 匹配文件路径中的0个或多个字符，但不会匹配路径分隔符，除非路径分隔符出现在末尾 ** 匹配路径中的0个或多个目录及其子目录,需要单独出现，即它左右不能有其他东西了。如果出现在末尾，也能匹配文件。 ? 匹配文件路径中的一个字符(不会匹配路径分隔符) […] 匹配方括号中出现的字符中的任意一个，当方括号中第一个字符为^或!时，则表示不匹配方括号中出现的其他字符中的任意一个，类似js正则表达式中的用法 !(pattern|pattern|pattern) 匹配任何与括号中给定的任一模式都不匹配的 ?(pattern|pattern|pattern) 匹配括号中给定的任一模式0次或1次，类似于js正则中的(pattern|pattern|pattern)? +(pattern|pattern|pattern) 匹配括号中给定的任一模式至少1次，类似于js正则中的(pattern|pattern|pattern)+ *(pattern|pattern|pattern) 匹配括号中给定的任一模式0次或多次，类似于js正则中的(pattern|pattern|pattern)* @(pattern|pattern|pattern) 匹配括号中给定的任一模式1次，类似于js正则中的(pattern|pattern|pattern) 例子:
|
1 2 3 4 5 6 7 8 |
//转换html文件 gulp.task('html', function(){ gulp.src('./src/index.html') .pipe(connect.reload()) .pipe(gulp.dest('./dist'));//写入命令 }); 当有多种匹配模式时可以使用数组 |
|
1 2 3 4 |
//使用数组的方式来匹配多种文件 gulp.src(['js/*.js','css/*.css','*.html']) 使用数组的方式还有一个好处就是可以很方便的使用排除模式，在数组中的单个匹配模式前加上!即是排除模式，它会在匹配的结果中排除这个匹配，要注意一点的是不能在数组中的第一个元素中使用排除模式 |
|
1 2 |
gulp.src([*.js,'!b*.js']) //匹配所有js文件，但排除掉以b开头的js文件 gulp.src(['!b*.js',*.js]) //不会排除任何文件，因为排除模式不能出现在 |
数组的第一个元素中 此外，还可以使用展开模式。展开模式以花括号作为定界符，根据它里面的内容，会展开为多个模式，最后匹配的结果为所有展开的模式相加起来得到的结果。展开的例子如下： a{b,c}d 会展开为 abd,acd a{b,}c 会展开为 abc,ac a{0..3}d 会展开为 a0d,a1d,a2d,a3d a{b,c{d,e}f}g 会展开为 abg,acdfg,acefg a{b,c}d{e,f}g 会展开为 abdeg,acdeg,abdeg,abdfg gulp.dest(path[,options]) gulp.dest()方法是用来写文件的 path为写入文件的路径 options为一个可选的参数对象，通常我们不需要用到 要想使用好gulp.dest()这个方法，就要理解给它传入的路径参数与最终生成的文件的关系。 gulp的使用流程一般是这样子的：首先通过gulp.src()方法获取到我们想要处理的文件流，然后把文件流通过pipe方法导入到gulp的插件中，最后把经过插件处理后的流再通过pipe方法导入到gulp.dest()中，gulp.dest()方法则把流中的内容写入到文件中，这里首先需要弄清楚的一点是，我们给gulp.dest()传入的路径参数，只能用来指定要生成的文件的目录，而不能指定生成文件的文件名，它生成文件的文件名使用的是导入到它的文件流自身的文件名，所以生成的文件名是由导入到它的文件流决定的，即使我们给它传入一个带有文件名的路径参数，然后它也会把这个文件名当做是目录名，例如：
|
1 2 3 4 5 6 7 8 |
var gulp = require('gulp'); gulp.src('script/jquery.js') .pipe(gulp.dest('dist/foo.js')); //最终生成的文件路径为 dist/foo.js/jquery.js,而不是dist/foo.js 要想改变文件名，可以使用插件gulp-rename 下面说说生成的文件路径与我们给gulp.dest()方法传入的路径参数之间的关系。 gulp.dest(path)生成的文件路径是我们传入的path参数后面再加上gulp.src()中有通配符开始出现的那部分路径。例如： |
|
1 2 3 4 5 6 7 |
var gulp = reruire('gulp'); //有通配符开始出现的那部分路径为 **/*.js gulp.src('script/**/*.js') .pipe(gulp.dest('dist')); //最后生成的文件路径为 dist/**/*.js //如果 **/*.js 匹配到的文件为 jquery/jquery.js ,则生成的文件路径为 dist/jquery/jquery.js 再举更多一点的例子 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
gulp.src('script/avalon/avalon.js') //没有通配符出现的情况 .pipe(gulp.dest('dist')); //最后生成的文件路径为 dist/avalon.js //有通配符开始出现的那部分路径为 **/underscore.js gulp.src('script/**/underscore.js') //假设匹配到的文件为script/util/underscore.js .pipe(gulp.dest('dist')); //则最后生成的文件路径为 dist/util/underscore.js gulp.src('script/*') //有通配符出现的那部分路径为 * //假设匹配到的文件为script/zepto.js .pipe(gulp.dest('dist')); //则最后生成的文件路径为 dist/zepto.js 通过指定gulp.src()方法配置参数中的base属性，我们可以更灵活的来改变gulp.dest()生成的文件路径。 当我们没有在gulp.src()方法中配置base属性时，base的默认值为通配符开始出现之前那部分路径，例如： |
[…]
View Details为了防止客户端的静态资源缓存，我们需要每次更新css或js的时候，通过md5或时间戳等方式重新命名静态资源； 然后涉及到的html模板里的src也要做相应的修改，静态资源需要优化(压缩合并) 文件目录结构 html模板文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <html> <head> <!-- build:css styles/main.min.css --> <link rel="stylesheet" href="../styles/one.css"> <link rel="stylesheet" href="../styles/two.css"> <!-- endbuild --> </head> <body> <!-- build:js scripts/main.min.js --> <script type="text/javascript" src="../scripts/one.js"></script> <script type="text/javascript" src="../scripts/two.js"></script> <!-- endbuild --> </body> </html> gulp配置文件:gulpfile.js 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 […]
View DetailsStateOfJS 刚刚发布了 2018年的 JavaScript 现状调查报告，今年他们调查了超过 20000 名 JavaScript 开发者，以确定他们正在使用什么，他们对什么感到满意以及他们想要学习什么。 1、JavaScript 现状 —— “方言” 随着 JavaScript 的成熟，开发者基于 JavaScript 创建了许多其他语言，或者叫“方言”，如 ES6、TypeScript、Flow、Reason、Elm、ClojureScript 、CoffeeScript 等等。曾几何时，CoffeeScript 是该方向的唯一支持者，但如今它已被 ES6 、TypeScript、Flow 等取代。 StateOfJS 表示有充分的理由认为这是整个 JavaScript 的未来。因为随着像 Web Assembly 这样的项目的出现，直接使用 JavaScript 编写代码可能很快就会变得古怪。 2018年的两位大赢家是 ES6 和 TypeScript 。另外 Reason 也值得关注，它背后有 Facebook 的支持，并且拥有非常高的满意度和兴趣值。 2、JavaScript 现状 —— 前端框架 结果基本上和其他榜单类似，React 和 Vue 唱主角，Angular 有垮台的趋势。 StateOfJS 表示，两年前有 27％ 的受访者表示从未听说过 Vue ，但如今这一比例已降至 1.3％ ！虽然 React 仍然拥有更大的市场份额，但 Vue 的迅速崛起也没有停止的迹象。 Angular 本身拥有庞大的用户群，但也很难看到它重新登上前端框架的冠亚宝座。 3、JavaScript 现状 —— 数据层 毫无疑问，Redux 是使用最广泛的工具，82％ 的满意率也证明了它的成熟程度。不过 GraphQL 也并非没有冲击的可能，其用户在两年内从 5％ 上升到了 20％ 。 4、JavaScript 现状 —— 后端框架（服务端） JavaScript 在后端（服务端）领域近年来似乎没有取得任何重大突破，虽然每年都有无数的框架出现，但很少有能够获得很大的成功并挑战 Express 的地位的。 即便是拥有 Express 继任者称号的 Koa ，其满意度也相对较低，使用量也有大幅下滑。 该领域有一个有趣的参与者 —— Next.js，最近引起了很多人的兴趣。虽然它与功能齐全的 Node 后端不太可比，但它专注于解决 React 应用的服务器端渲染问题，使其成为一个非常实用的工具。 5、JavaScript 现状 —— 测试 […]
View Details这是一个非常有趣的 非主流前端领域，这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题，入行到现在一直在学习和实践中。 在我的印象中，facebook是这个领域的鼻祖，有兴趣、有梯子的同学可以去看看facebook的页面源代码，体会一下什么叫工程化。 接下来，我想从原理展开讲述，多图，较长，希望能有耐心看完。 让我们返璞归真，从原始的前端开发讲起。上图是一个“可爱”的index.html页面和它的样式文件a.css，用文本编辑器写代码，无需编译，本地预览，确认OK，丢到服务器，等待用户访问。前端就是这么简单，好好玩啊，门槛好低啊，分分钟学会有木有！ 然后我们访问页面，看到效果，再查看一下网络请求，200！不错，太™完美了！那么，研发完成。。。。了么？ 等等，这还没完呢！对于大公司来说，那些变态的访问量和性能指标，将会让前端一点也不“好玩”。 看看那个a.css的请求吧，如果每次用户访问页面都要加载，是不是很影响性能，很浪费带宽啊，我们希望最好这样： 利用304，让浏览器使用本地缓存。但，这样也就够了吗？不成！304叫协商缓存，这玩意还是要和服务器通信一次，我们的优化级别是变态级，所以必须彻底灭掉这个请求，变成这样： 强制浏览器使用本地缓存（cache-control/expires），不要和服务器通信。好了，请求方面的优化已经达到变态级别，那问题来了：你都不让浏览器发资源请求了，这缓存咋更新？ 很好，相信有人想到了办法：通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。好像这样： 下次上线，把链接地址改成新的版本，就更新资源了不是。OK，问题解决了么？！当然没有！大公司的变态又来了，思考这种情况： 页面引用了3个css，而某次上线只改了其中的a.css，如果所有链接都更新版本，就会导致b.css，c.css的缓存也失效，那岂不是又有浪费了？！ 重新开启变态模式，我们不难发现，要解决这种问题，必须让url的修改与文件内容关联，也就是说，只有文件内容变化，才会导致相应url的变更，从而实现文件级别的精确缓存控制。 什么东西与文件内容相关呢？我们会很自然的联想到利用 数据摘要要算法 对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。好了，我们把url改成带摘要信息的： 这回再有文件修改，就只更新那个文件对应的url了，想到这里貌似很完美了。你觉得这就够了么？大公司告诉你：图样图森破！ 唉~~~~，让我喘口气 现代互联网企业，为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径： 好了，当我要更新静态资源的时候，同时也会更新html中的引用吧，就好像这样： 这次发布，同时改了页面结构和样式，也更新了静态资源对应的url地址，现在要发布代码上线，亲爱的前端研发同学，你来告诉我，咱们是先上线页面，还是先上线静态资源？ 1.先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。 2.先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。 好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。 但是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！ 这个奇葩问题，起源于资源的覆盖式发布，用 待发布资源覆盖 已发布资源，就有这种问题。解决它也好办，就是实现非覆盖式发布。 看上图，用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。 所以，大公司的静态资源优化方案，基本上要实现这么几个东西： 1.配置超长时间的本地缓存 —— 节省带宽，提高性能 2.采用内容摘要作为缓存更新依据 —— 精确的缓存控制 3.静态资源CDN部署 —— 优化网络请求 4.更资源发布路径实现非覆盖式发布 —— 平滑升级 全套做下来，就是相对比较完整的静态资源缓存控制方案了，而且，还要注意的是，静态资源的缓存控制要求在 前端所有静态资源加载的位置都要做这样的处理 。是的，所有！什么js、css自不必说，还要包括js、css文件中引用的资源路径，由于涉及到摘要信息，引用资源的摘要信息也会引起引用文件本身的内容改变，从而形成级联的摘要变化，大概示意图就是： 好了，目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题，新的问题又来了：这™让工程师怎么写码啊！！！ 要解释优化与工程的结合处理思路，又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题，以上只是开了个头，解决方案才是精髓，但要说的太多太多，有空再慢慢展开吧。 总之，前端性能优化绝逼是一个工程问题！ 以上不是我YY的，可以观察 百度 或者 facebook 的页面以及静态资源源代码，查看它们的资源引用路径处理，以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平，跪舔了。 建议前端工程师多多关注前端工程领域，也许有人会觉得自己的产品很小，不用这么变态，但很有可能说不定某天你就需要做出这样的改变了。而且，如果我们能把事情做得更极致，为什么不去做呢？ 另外，也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决，大家总是把自己不关心的问题丢给别人，那么前端工程师的开发过程将受到极大的限制，这种情况甚至在某些大公司都不少见！ 妈妈，我再也不玩前端了。。。。5555 业界实践 Assets Pipeline Rails中的Assets Pipeline完成了以上所说的优化细节，对整个静态资源的管理上的设计思考也是如此，了解rails的人也可以把此答案当做是对rails中assets pipeline设计原理的分析。 rails通过把静态资源变成erb模板文件，然后加入<%= asset_path 'image.png' %>，上线前预编译完成处理，fis的实现思路跟这个几乎完全一样，但我们当初确实不知道有rails的这套方案存在。 相关资料： 英文版：http://guides.rubyonrails.org/asset_pipeline.html 中文版：http://guides.ruby-china.org/asset_pipeline.html FIS的解决方案 用 F.I.S 包装了一个小工具，完整实现整个回答所说的最佳部署方案，并提供了源码对照，可以感受一下项目源码和部署代码的对照。 源码项目：https://github.com/fouber/static-resource-digest-project 部署项目：https://github.com/fouber/static-resource-digest-project-release 部署项目可以理解为线上发布后的结果，可以在部署项目里查看所有资源引用的md5化处理。 这个示例也可以用于和assets pipeline做比较。fis没有assets的目录规范约束，而且可以以独立工具的方式组合各种前端开发语言（coffee、less、sass/scss、stylus、markdown、jade、ejs、handlebars等等你能想到的），并与其他后端开发语言结合。 assets pipeline的设计思想值得独立成工具用于前端工程，fis就当做这样的一个选择吧。 from:https://www.cnblogs.com/minigrasshopper/p/7694053.html
View Details每个参与过开发企业级web应用的前端工程师或许都曾思考过前端性能优化方面的问题。我们有雅虎14条性能优化原则，还有两本很经典的性能优化指导书：《高性能网站建设指南》、《高性能网站建设进阶指南》。经验丰富的工程师对于前端性能优化方法耳濡目染，基本都能一一列举出来。这些性能优化原则大概是在7年前提出的，对于web性能优化至今都有非常重要的指导意义。 然而，对于构建大型web应用的团队来说，要坚持贯彻这些优化原则并不是一件十分容易的事。因为优化原则中很多要求是与工程管理相违背的，比如“把css放在头部”和“把js放在尾部”这两条原则，我们不能让团队的工程师在写样式和脚本引用的时候都去修改一个相同的页面文件。这样做会严重影响团队成员间并行开发的效率，尤其是在团队有版本管理的情况下，每天要花大量的时间进行代码修改合并，这项成本是难以接受的。因此在前端工程界，总会看到周期性的性能优化工作，辛勤的前端工程师们每到月圆之夜就会倾巢出动根据优化原则做一次性能优化。 本文从一个全新的视角来思考web性能优化与前端工程之间的关系，通过解读百度前端集成解决方案小组（F.I.S）在打造高性能前端架构并统一百度40多条前端产品线的过程中所经历的技术尝试，揭示前端性能优化在前端架构及开发工具设计层面的实现思路。 性能优化原则及分类 笔者先假设本文的读者是有前端开发经验的工程师，并对企业级web应用开发及性能优化有一定的思考，因此我不会重复介绍雅虎14条性能优化原则。如果您没有这些前续知识，请移步这里来学习。 首先，我们把雅虎14条优化原则，《高性能网站建设指南》以及《高性能网站建设进阶指南》中提到的优化点做一次梳理，按照优化方向分类，可以得到这样一张表格： 优化方向 优化手段 请求数量 合并脚本和样式表，CSS Sprites，拆分初始化负载，划分主域 请求带宽 开启GZip，精简JavaScript，移除重复脚本，图像优化 缓存利用 使用CDN，使用外部JavaScript和CSS，添加Expires头，减少DNS查找，配置ETag，使AjaX可缓存 页面结构 将样式表放在顶部，将脚本放在底部，尽早刷新文档的输出 代码校验 避免CSS表达式，避免重定向 表格1 性能优化原则分类 目前大多数前端团队可以利用yui compressor或者google closure compiler等压缩工具很容易做到“精简Javascript”这条原则；同样的，也可以使用图片压缩工具对图像进行压缩，实现“图像优化”原则。这两条原则是对单个资源的处理，因此不会引起任何工程方面的问题。很多团队也通过引入代码校验流程来确保实现“避免css表达式”和“避免重定向”原则。目前绝大多数互联网公司也已经开启了服务端的Gzip压缩，并使用CDN实现静态资源的缓存和快速访问；一些技术实力雄厚的前端团队甚至研发出了自动CSS Sprites工具，解决了CSS Sprites在工程维护方面的难题。使用“查找-替换”思路，我们似乎也可以很好的实现“划分主域”原则。 我们把以上这些已经成熟应用到实际生产中的优化手段去除掉，留下那些还没有很好实现的优化原则。再来回顾一下之前的性能优化分类： 优化方向 优化手段 请求数量 合并脚本和样式表，拆分初始化负载 请求带宽 移除重复脚本 缓存利用 添加Expires头，配置ETag，使Ajax可缓存 页面结构 将样式表放在顶部，将脚本放在底部，尽早刷新文档的输出 表格2 较难实现的优化原则 现在有很多顶尖的前端团队可以将上述还剩下的优化原则也都一一解决，但业界大多数团队都还没能很好的解决这些问题。因此，本文将就这些原则的解决方案做进一步的分析与讲解，从而为那些还没有进入前端工业化开发的团队提供一些基础技术建设意见，也借此机会与业界顶尖的前端团队在工业化工程化方向上交流一下彼此的心得。 静态资源版本更新与缓存 如表格2所示，“缓存利用”分类中保留了“添加Expires头”和“配置ETag”两项。或许有些人会质疑，明明这两项只要配置了服务器的相关选项就可以实现，为什么说它们难以解决呢？确实，开启这两项很容易，但开启了缓存后，我们的项目就开始面临另一个挑战：如何更新这些缓存。 相信大多数团队也找到了类似的答案，它和《高性能网站建设指南》关于“添加Expires头”所说的原则一样——修订文件名。即： 最有效的解决方案是修改其所有链接，这样，全新的请求将从原始服务器下载最新的内容。 思路没错，但要怎么改变链接呢？变成什么样的链接才能有效更新缓存，又能最大限度避免那些没有修改过的文件缓存不失效呢？ 先来看看现在一般前端团队的做法： 或者 大家会采用添加query的形式修改链接。这样做是比较直观的解决方案，但在访问量较大的网站，这么做可能将面临一些新的问题。 通常一个大型的web应用几乎每天都会有迭代和更新，发布新版本也就是发布新的静态资源和页面的过程。以上述代码为例，假设现在线上运行着index.html文件，并且使用了线上的a.js资源。index.html的内容为： 这次我们更新了页面中的一些内容，得到一个index.html文件，并开发了新的与之匹配的a.js资源来完成页面交互，新的index.html文件的内容因此而变成了： 好了，现在要开始将两份新的文件发布到线上去。可以看到，index.html和a.js的资源实际上是要覆盖线上的同名文件的。不管怎样，在发布的过程中，index.html和a.js总有一个先后的顺序，从而中间出现一段或大或小的时间间隔。对于一个大型互联网应用来说即使在一个很小的时间间隔内，都有可能出现新用户访问。在这个时间间隔中，访问了网站的用户会发生什么情况呢？ 如果先覆盖index.html，后覆盖a.js，用户在这个时间间隙访问，会得到新的index.html配合旧的a.js的情况，从而出现错误的页面。 如果先覆盖a.js，后覆盖index.html，用户在这个间隙访问，会得到旧的index.html配合新的a.js的情况，从而也出现了错误的页面。 这就是为什么大型web应用在版本上线的过程中经常会较集中的出现前端报错日志的原因，也是一些互联网公司选择加班到半夜等待访问低峰期再上线的原因之一。此外，由于静态资源文件版本更新是“覆盖式”的，而页面需要通过修改query来更新，对于使用CDN缓存的web产品来说，还可能面临CDN缓存攻击的问题。我们再来观察一下前面说的版本更新手段： 我们不难预测，a.js的下一个版本是“1.0.1”，那么就可以刻意构造一串这样的请求“a.js?v=1.0.1”、“a.js?v=1.0.2”、……让CDN将当前的资源缓存为“未来的版本”。这样当这个页面所用的资源有更新时，即使更改了链接地址，也会因为CDN的原因返回给用户旧版本的静态资源，从而造成页面错误。即便不是刻意制造的攻击，在上线间隙出现访问也可能导致区域性的CDN缓存错误。 此外，当版本有更新时，修改所有引用链接也是一件与工程管理相悖的事，至少我们需要一个可以“查找-替换”的工具来自动化的解决版本号修改的问题。 对付这个问题，目前来说最优方案就是基于文件内容的hash版本冗余机制了。也就是说，我们希望工程师源码是这么写的： 但是线上代码是这样的： 其中”_82244e91”这串字符是根据a.js的文件内容进行hash运算得到的，只有文件内容发生变化了才会有更改。由于版本序列是与文件名写在一起的，而不是同名文件覆盖，因此不会出现上述说的那些问题。同时，这么做还有其他的好处： 线上的a.js不是同名文件覆盖，而是文件名+hash的冗余，所以可以先上线静态资源，再上线html页面，不存在间隙问题； 遇到问题回滚版本的时候，无需回滚a.js，只须回滚页面即可； 由于静态资源版本号是文件内容的hash，因此所有静态资源可以开启永久强缓存，只有更新了内容的文件才会缓存失效，缓存利用率大增； 修改静态资源后会在线上产生新的文件，一个文件对应一个版本，因此不会受到构造CDN缓存形式的攻击 虽然这种方案是相比之下最完美的解决方案，但它无法通过手工的形式来维护，因为要依靠手工的形式来计算和替换hash值，并生成相应的文件。这将是一项非常繁琐且容易出错的工作，因此我们需要借助工具。我们下面来了解一下fis是如何完成这项工作的。 首先，之所以有这种工具需求，完全是由web应用运行的根本机制决定的：web应用所需的资源是以字面的形式通知浏览器下载而聚合在一起运行的。这种资源加载策略使得web应用从本质上区别于传统桌面应用的版本更新方式。为了实现资源定位的字面量替换操作，前端构建工具理论上需要识别所有资源定位的标记，其中包括： css中的@import url(path)、background:url(path)、backgournd-image:url(path)、filter中的src js中的自定义资源定位函数，在fis中我们将其规定为__uri(path)。 html中的<script src=”path”>、<link href=”path”>、<imgsrc=”path”>、已经embed、audio、video、object等具有资源加载功能的标签。 为了工程上的维护方便，我们希望工程师在源码中写的是相对路径，而工具可以将其替换为线上的绝对路径，从而避免相对路径定位错误的问题（比如js中需要定位图片路径时不能使用相对路径的情况）。 fis的资源定位设计思想 fis有一个非常棒的资源定位系统，它是根据用户自己的配置来指定资源发布后的地址，然后由fis的资源定位系统识别文件中的定位标记，计算内容hash，并根据配置替换为上线后的绝对url路径。 要想实现具备hash版本生成功能的构建工具不是“查找-替换”这么简单的。我们考虑这样一种情况： 资源引用关系 由于我们的资源版本号是通过对文件内容进行hash运算得到，如上图所示，index.html中引用的a.css文件的内容其实也包含了a.png的hash运算结果，因此我们在修改index.html中a.css的引用时，不能直接计算a.css的内容hash，而是要先计算出a.png的内容hash，替换a.css中的引用，得到了a.css的最终内容，再做hash运算，最后替换index.html中的引用。 这意味着构建工具需要具备“递归编译”的能力，这也是为什么fis团队不得不放弃gruntjs等task-based系统的根本原因。针对前端项目的构建工具必须是具备递归处理能力的。此外，由于文件之间的交叉引用等原因，fis构建工具还实现了构建缓存等机制，以提升构建速度。 在解决了基于内容hash的版本更新问题之后，我们可以将所有前端静态资源开启永久强缓存，每次版本发布都可以首先让静态资源全量上线，再进一步上线模板或者页面文件，再也不用担心各种缓存和时间间隙的问题了！ 在本系列的下一部分，我们将介绍静态资源管理与模板框架的思路和用法。 作者简介：张云龙，百度公司Web前端研发部前端集成解决方案小组技术负责人，目前负责F.I.S项目，读者可以关注他的微博：http://weibo.com/fouber/。 from:http://www.infoq.com/cn/articles/front-end-engineering-and-performance-optimization-part1
View Details浏览器缓存主要有两类 缓存协商：Last-midified ，Etag 彻底缓存：cache-control，Expires 缓存协商的意思是需要去服务器端询问页面有没有修改过，没有修改过则返回304直接使用缓存内容，否则返回新内容 协商步骤： 1、服务器发送带Last-midified:GMTtime 头的http response 2、浏览器下次请求时带上if-modified-since:GMTtime http 请求头 3、服务端用本地Last-midified时间与if-modified-since比较，计算浏览器数据是否过期并发送响应 Etag的工作原理与Last-midified类似，不同点在于Etag的值是用户可自定义的 彻底缓存的意思是在缓存失效之前不再需要跟服务器交互 常用的是Expires，Expires的值是一个绝对时间，由服务器产生 这儿存在一个问题，就是服务器的时间可能给客户端的时间不一致导致缓存时间的偏差 要解决这个问题就要使用cache-control,它保存的是一个相对浏览器的时间 如果同时存在cache-control和Expires怎么办呢？ 浏览器总是优先使用cache-control，如果没有cache-control才考虑Expires expire: 如果apache开启了expire模块, 当浏览器发送该资源请求的时候, apache返回资源的同时,会返回一个名为expire的http头,expire头的内容是一个时间值, 这一个值就是资源在本地的过期时间, 这个值会存在本地. 也就是说,在本地缓存阶段,在本地找到了一个对应的资源值,而且当前时间还没超过资源的过期时间, 那么就直接使用这一个资源,不会发送http请求. cache-control: cache-control是http协议中常用的头部之一,顾名思义, 他是负责控制页面的缓存机制,如果该头部指示缓存, 缓存的内容也会存在本地, 操作流程和expire相似,但也有不同的地方, cache-control有更多的选项, 而且也有更多的处理方式. if-modified-since 和 last-modified: 当apache接收到一个资源请求(假设是用户是第一次访问,没有任何缓存), 服务器返回资源的同时,还会发送一个last-modified的http响应头, last-modified响应头的内容值是该资源在服务器上最后修改的时间.浏览器接受到这个http头后,会 把其内容值和资源同时保存起来. 当用户第二发送资源请求(假设这里expire没有生效或者已经过期), 浏览器在本地找到了一个相同的资源,但是不能确定该资源是否和服务器上的一样(有可能在两次访问期间,服务器上的资源已经被修改过),此时浏览器发送请求的时候,请求头内会 附带一个if-modified-since的请求头, 这个头部的内容就是上一次last-modified返回的值, 服务器把这个头的值和请求资源的最后修改时间对比,如果两个值相同,则认为资源没有修改,将会返回304,让浏览器使用本地资源.否则服务器将返回资源,而且 返回200状态 if-none-match 和 etag: 其实这两个头部和if-modified-since, last-modified的工作原理是一样的, if-none-match作为请求头, etag作为响应头.既然工作原理一样, 为什么etag这对头部会出现呢? 原因在于, last-modified请求头的内容是以文件最后修改的时间作为对比的,但是unix系统里面, 文件修改的时间只保存到了秒. 如果某些应用内存在1秒内对文件做了多次修改,这样last-modified是不能完成比较功能的.所以要引入一个新的机制(原因可能不止这一个); etag的值一般由3个数值组成,资源的inode值, 最后修改时间, 资源大小,以16进制组成一个字符串, 例如:1a-182b-10f; 但这个格式不是固定的, 只要保证该值的唯一性,但不限格式. 静态资源的更新：张云龙老师的blog写的很好移步这里 html5离线存储 步骤： 1、配置apache让apache支持manifest文件 2、创建manifest文件test.manifest
|
1 2 3 4 5 6 |
CACHE MANIFEST # wanz app v1 # 指明缓存入口（指明需要缓存的文件） CACHE: index.html style.css images/logo.png scripts/main.js # 以下资源必须在线访问 NETWORK: login.php # 如果index.php无法访问则用404.html代替 FALLBACK: /index.php /404.html |
3、关联manifest文件到html文档
|
1 |
<html manifest="test.manifest"> ... </html> |
注意：#是用来注释一行的，但它还有一个小作用，web应用的缓存只有在manifest文件被修改的情况下才会被更新，所以如果你只是修改了被缓存的文件，那么用户本地的缓存还是不会被更新的，但是你可以通过修改manifest文件来告诉浏览器需要更新缓存了。利用这点，你可以像上面的例子中那样，写一句这样的注释一个文件版本： # wanz app v1 优点：你可以很明确的了解离线web应用的版本 通过简单的修改这个版本号就可以轻易的通知浏览器更新 你可以配合JavaScript程序来完成缓存更新 CACHE: 这个是manifest文件的默认入口，在此入口之后罗列的文件 (或直接写在CACHE MANIFEST后的文件)在它们下载到本地后会被缓存起来 NETWORK: […]
View Details写在前面的 评价纯属个人主观感受，有夸张成分，只是一种表达，如有不喜请无视之。欢迎指正不足和提供更多更好的vue库，项目，方便参考和学习使用。 一、前台UI组件库 1.Element 优点：中文文档，ui种类比较全，ui设计简洁清晰 缺点：不够有特点 2.iView 优点：和element的UI很相似，有一些多的补充，可以相互替换 缺点：仍然没有什么特色 3.Vuetify 优点：时间选择器是时钟样式，比较有特色。中文文档 缺点：种类不如前面全 地址：https://vuetifyjs.com/zh-Hans/ 4.Vue-material 优点：日期选择器配色舒适，进度条样式有虚线形式，步骤条更清晰相比有创新。表单字段点击后文字会上浮 缺点：目前种类还比较少，遗憾没有时间选择器。非中文文档 5.Quasar 构建响应式网站，PWA，混合移动应用程序 打不开，应该是被墙了，无法评论，只有项目 6.Buefy 优点：时间选择器数字很大有特点 缺点：非中文文档 7.Vant 优点：移动端界面，轻量化，基本涵盖移动端交互的ui，和微信样式很像 8.At-ui 一款全新的平面UI套件，专门用于桌面应用程序 优点：颜色比较素雅，UI比较秀气 9.Vue-js-modal 关于模态框的ui库，配色和阴影上适合音乐娱乐类项目 10.Vuex-loading 等待相关进度的一些库 缺点：并不是那么好看，使用的话，最好手动调调整一下样式 11.Vue-js-grid 可移动方格子位置的库 12.Dockeron docker上的ui库，使用后再回补 13.mint-ui 优点：风格简洁，文档中移动端看的效果清晰 缺点：中文字体和间距比例上稍稍偏大 14.Keen-UI 优点：移动端框架，日期选择器比较好看。 缺点：非中文文档 15.VueCircleMenu 优点：提供各种从中间蹦跶出半圆形按钮的组件方案，主流ui库给的比较少，有了它可以不用自己写了 缺点：配色视图有点惨 16.vue-carbon 有点：很淡雅的风格，虽然颜色只有一种，但是字体和间距给的很好，一眼过去很舒服，ui相比要做的事情不会喧宾夺主。 缺点：在中国可能不是主流（国人喜欢花花绿绿，字体大大的） 17.vue-calendar 特别中国特色，排版稍稍有点拥挤，但是有农历，好评！ 18.vue-datetime-picker 19.vue2-calendar 优点：日期选择器中支持自定义事件的稀缺 ★181 – 支持lunar和日期事件的日期选择器 20.vue-datepicker 日期选择器简洁大气，希望可以有匹配的时间选择器 21.vue-datepicker 优点：很小巧，没有多余的装饰，不占版面 22.vue-date-picker ★59 – VueJS日期选择器组件 23.vue-fullcalendar 大格子化日期选择器，酒店入住等游玩类网站会用到 24.vue-datepicker-simple 月份选择排版蛮特别，极少数用这么正红配色的日期选择器 ★20 – 基于vue的日期选择 25.vue-chartjs 可视化图表的vue版本，主要饼形图，条形图，雷达图等都有 缺点：样式太简，使用还需调整，相比百度的Echart还是少太多图类 26.DataVisualization 提供四个最简单的图类，比较实用 缺点：配色上背景太花，前景色饱和度太低，需要调整 ★149 – 数据可视化 27.vue-charts 样式比较好看，但目前图标类型还是太少 ★101 – 轻松渲染一个图表 28.vue-chartkick […]
View Details