Update 项目优化.md

开发文档/项目优化.md

@@ -1,8 +1,8 @@
-本项目将根据我写的<a href="https://blog.csdn.net/qq_37205708/article/details/89737524">这篇文章</a>进行优化
-### 划分子域、DNS预解析
+本项目将根据我写的 <a href="https://www.kancloud.cn/chenmk/web-knowledges/1078353">这篇文章</a> 进行优化
+### 划分子域、DNS 预解析
 由于只有一个域名所以放弃
-### CND加速
-可以考虑把vuex、vue-router等插件不直接放到打包后的文件中而是通过外链来引入，比如
+### CND 加速
+可以考虑把 vuex、vue-router 等插件不直接放到打包后的文件中而是通过外链来引入，比如
 
 ``` javaScript
 const cdn = {
@@ -33,44 +33,72 @@ const cdn = {
 }
 ```
 另外，还可以把一些不变的图片什么的放在七牛云的图床上通过外链来加载。简单来说，就是找同样的资源你的服务器慢别人的服务器快；
-因为浏览器可以并行地建立多个TCP连接（5个还是6个来着？），所以应该不用怀疑额外的DNS解析和TCP握手所耗费的时间会比原来的多。
+
+因为浏览器可以并行地建立多个 TCP 连接（5 个还是 6 个来着？），所以应该不用怀疑额外的 DNS 解析和 TCP 握手所耗费的时间会比原来的多。
 ### 设置缓存---采纳
-考虑对图片和html资源等设置缓存，正在研究如何设置......
+对于不常改变的图片等静态资源，可以做缓存设置，因为使用 Nginx 做的静态资源服务器，所以只需要修改一下其配置项即可：
+
+```shell
+location ~* \.(jpg|jpeg|png|gif|webp)$ {
+    expires 30d;
+}
+location ~* \.(css|js)$ {
+    expires 7d;
+}
+```
+
+更多 Nginx 配置：<a href="https://www.kancloud.cn/chenmk/web-knowledges/1084961#_84">点击跳转</a>
 ### 图片懒加载---采纳
-书城页有大量图片目前是一次性加载的，又因为购买的阿里云服务器的网速贼慢，所以考虑图片懒加载，考虑使用vue-lazyloader<br>
-具体的使用可以参考<a href="https://segmentfault.com/a/1190000014928116">这篇文章</a>或者去看官方文档<br>
-- `cnpm install vue-lazyload --save` 因为是生产环境需要使用的不要用--save-dev<br>
-- main.js导入 `import import VueLazyLoad from 'vue-lazyload'` `Vue.use(VueLazyLoad)`
-- `<img class="item-pic" v-lazy="newItem.picUrl"/>` vue文件中将需要懒加载的图片绑定 v-bind:src 修改为 v-lazy 
+书城页有大量图片目前是一次性加载的，又因为购买的阿里云服务器的网速贼慢，所以考虑图片懒加载，考虑使用 vue-lazyloader
+
+具体的使用可以参考 <a href="https://segmentfault.com/a/1190000014928116">这篇文章</a>或者去看官方文档
+
+- `cnpm install vue-lazyload --save` 因为是线上环境需要使用的不要用 --save-dev
+- main.js导入
+```js
+import VueLazyLoad from 'vue-lazyload'
+Vue.use(VueLazyload)
+```
+- `<img class="item-pic" v-lazy="newItem.picUrl"/>` vue 文件中将需要懒加载的图片绑定 v-bind:src 修改为 v-lazy 
 
 当然也不是要把所有的图片都换成懒加载，这是吃力不讨好的，这里我只把书城部分需要滑动才能看到的图片使用了懒加载其他地方不换
+
 因为一点进去就能看到的话懒加载也没有意义，图片个数本来不多的话懒加载也没有意义，只有在一个页面加载了过多视图还看不到的图片这种场景再用懒加载。
-这个插件还提供了许多API可以满足不同需求，这里不再探讨了
+
+这个插件还提供了许多 API 可以满足不同需求，这里不再探讨了
+
 ### 预加载-采纳
-在阅读器部分可以考虑预先加载当前章节相邻的章节内容，这样切换时可以有更好的体验。电子书阅读器实现原理都是类似的，可以将epub电子书解压观察一下，每一章其实是一个html文件，阅读器每次加载一章就是这个道理，当翻阅到下一章时，阅读器需要再解析下一个html文件，可以考虑预先加载前后两章，这样在边界处翻页时，也能获得很好的阅读体验。
+在阅读器部分可以考虑预先加载当前章节相邻的章节内容，这样切换时可以有更好的体验。电子书阅读器实现原理都是类似的，可以将 epub 电子书解压观察一下，每一章其实是一个 html 文件，阅读器每次加载一章就是这个道理，当翻阅到下一章时，阅读器需要再解析下一个 html 文件，可以考虑预先加载前后两章，这样在边界处翻页时，也能获得很好的阅读体验。
 ### 链接位置
-这个Webpack帮我们处理了
-### 尽量减少回流与重绘---采纳
-CSS3动画全部使用`transform:translate3D()`启动GPU加速
-### 高效率的CSS，不要有过多的嵌套
-懒得改CSS了......
-### 减少DOM元素数量、DOM操作---采纳
-考虑把使用JS操作DOM实现的动画换成canvas实现
+这个 Webpack 帮我们处理了
+### 尽量减少回流与重绘---采纳 
+CSS3 动画全部使用 `transform:translate3D()`启动 GPU 加速
+
+将一些通过改变 top、left 值做位移的动画修改为 transform: translate() 来实现，后者不会触发回流与重绘，当然这只是很小的优化...
+
+### 高效率的 CSS，不要有过多的嵌套
+懒得改 CSS 了......
+### 减少 DOM 元素数量、DOM 操作---采纳
+考虑把使用J S 操作 DOM 实现的动画换成 canvas 实现...
 ### 函数节流---采纳
-项目中监听了很多的vuex变量，考虑从连续的监听换成有间断的监听
-### iconfont图标---已使用
+项目中监听了很多的 vuex 变量，考虑从连续的监听换成有间断的监听
+### iconfont 图标---已使用
 
 ### 文件体积优化
-可以通过安装webpack的一些插件以及配置vue.config.js来减小打包后的文件的体积，这里先给出未做打包优化前的文件大小<br>
-未打包优化前，文件大小：**4.79MB**<br>
+可以通过安装 webpack 的一些插件以及配置 vue.config.js 来减小打包后的文件的体积，这里先给出未做打包优化前的文件大小
+
+未打包优化前，文件大小：**4.79MB**
+
+优化1：配置 productionSourceMap 选项，只需要在 vue.config.js 中增加` productionSourceMap: false`
+
+官网解释如下：如果你不需要生产环境的 source map，可以将其设置为 false 以加速生产环境构建；
 
-优化1：配置productionSourceMap选项，只需要在vue.config.js中增加` productionSourceMap: false`<br>
-官网解释如下：如果你不需要生产环境的 source map，可以将其设置为 false 以加速生产环境构建；<br>
-网上找到的解释是：map文件是js文件压缩后，文件的变量名替换对应、变量所在位置等原信息数据文件。
-个人理解是对js压缩过程的记录，如浏览器支持等，可以通过map文件还原文件到未压缩之前。<br>
-重新打包后文件大小为**1.54MB**，可以发现体积大大减小
+Source Map 的用途简单来说就是检查错误，它建立了 webpack 打包生成的文件与源代码之间的映射关系，这样你在 Chrome 上点击看到的报错信息就能帮你对应
+到你的源代码的 xxx 行。如果你已经确保了线上环境不再报错，可以把它去掉。
 
-优化2：使用图片压缩插件<br>
+重新打包后文件大小为 **1.54MB**，可以发现体积大大减小
+
+优化2：使用图片压缩插件
 `npm install image-webpack-loader --save-dev`
 
 ``` javaScript
@@ -85,21 +113,35 @@ chainWebpack: config => {
       .end()
 },
 ```
-这段代码做了两件事：一是压缩，二是转Base64可以发现在dist/img下面的图片少了一部分，
-原因是：不超过4096字节会被转换成Base64编码,用require引用的也会被转成和base64，超出这个限制则会被打包在img文件夹下。
+这段代码做了两件事：一是压缩，二是转 Base64 可以发现在 dist/img 下面的图片少了一部分，
+
+原因是：不超过 4096 字节会被转换成 Base64 编码,用 require 引用的也会被转成和 base64，超出这个限制则会被打包在 img 文件夹下。
+
 重新打包后文件大小为**1.40MB**，少了将近0.1MB
 
+base64 格式其实是把图片以 URL 的形式压缩到 JS 代码中，这样可以节省网络请求（本来要发送一个 HTTP 请求来请求图片），使用 url-loader 也能实现
+同样的效果。
+
+就文件体积而言，整体来说并不会有优化（可能还会增大）。
 
 ### SPA SEO or SSR?
 - SPA(Single Page Application)：单页面富应用，动态地重写页面的部分与用户交互而不是重新加载新的页面
 - SEO(Search Engine Optimization)：搜索引擎优化
 - SSR(Server-Side Rendering)：服务端渲染
 
-本项目属于SPA，不需要SEO，SSR理论上来说不仅会有更快的首屏加载时间，同时也能获得更好的SEO但是其会占用服务器更多的CPU和内存资源，且
-一些常用的浏览器API可能无法使用，如window、document、alert等；对于一个已经上线的项目来说修改成本也挺大的（感觉），且本项目不想
-电商网站之类的对首屏加载速度有太高的要求，因为首屏是书架页面，只显示自己选定的图书，所以不考虑SSR。
+本项目属于 SPA，不需要 SEO，SSR 理论上来说不仅会有更快的首屏加载时间，同时也能获得更好的 SEO，但是其会占用服务器更多的 CPU 和内存资源，且
+一些常用的浏览器 API 可能无法使用，如 window、document、alert 等；
+
+对于一个已经上线的项目来说修改成本也挺大的（感觉），且本项目不像电商网站之类的对首屏加载速度有太高的要求，因为首屏是书架页面，只显示自己选定的图书，所以不考虑 SSR。
+
+SSR 感觉就像 JSP 开发？其完成了部分的本来该由用户浏览器完成的解析和渲染的操作，这样本来由所有用户浏览器分担的压力全部转到了服务器上，
+再考虑一下阿里云 1M 小水管和 40 GB 的空间......
 
 ### 用户体验优化
-1. 添加书签的操作增加PC端适配
-2. 增加对屏幕宽度的监听以实现响应式布局
-3. localStorage和IndexedDB的使用似乎仍然有一些问题
+1.添加书签的操作增加 PC 端适配
+
+2.增加对屏幕宽度的监听以实现响应式布局
+
+3.使用 localStorage 保留用户操作，如选择的皮肤，语言类型等
+
+4.使用 IndexedDB 实现电子书的缓存，这样点击阅读时将会有更快的加载速度（一本 epub 电子书可能达到 5MB!）