过完年了也是一直拖到了现在才有时间补交一下作业，去年出差出了一年，是时候好好沉淀一下了
目录
- 前言
- 设计角度
- UI 角度
- 开发角度
一、前言
我一直对我负责的项目成员讲，项目交付给客户的前提是不卡，之后是对用户的友好度必须要高。因为无论你的项目做的有多好，如果用着卡，用户终究会不认可，大家估计也是深有体会。随着时代节奏加快，人们趋向于快速便捷，容易上手的事物。
1、优质的用户体验
这一点很重要然而又让用户在一般情况下感觉不到，在产品界有一句话，最好的用户体验就是让用户没感觉，信手拈来。
就大家手机里的app来说，大多数的用户体验都是极好的，产品团队每天都在维护调研，时时刻刻监测着用户需求的走向。
那么有没有反例呢：
某网购app你好：我买了一款榨汁机，并不代表我需要更多的榨汁机。
相信你也有这种体会，我虽然逛了很长时间为了买台榨汁机，但是在我买了之后，还是会铺天盖地的给我“智能”推送榨汁机的产品，我看了这些推送产品之后，总会让我纠结。
后悔买内台了，我应该买这台
一种人工智能离我们越来越远的感觉。
2、简洁明了的界面
前端发展到现在，大多数客户端都已趋近于扁平化界面，还有很多公司的logo也设计成了扁平化，就是因为简洁明了。
随着显示屏的发展，可视区域可以展示的内容越来越多，用户找到自己需要的东西的花费的时间会越来越长，所以如何设计简洁明了的界面成为了大势所趋。
如果打开一个网站看几分钟觉得刺眼，那么就可能就不够简洁
3、方便快捷的操作流程
这一点也是每个产品必须考虑的一部，能用两步完成的步骤就不要让用户操作三步，能让用户少点一下是一下，除非你开发的是扫雷。
举个例子：
现在大多数登录系统，都是注册完直接登录系统，然后慢慢引导用户完善个人信息，如果反过来的话。注册完，还需要填写一堆个人信息才能登入系统，用户已经在崩溃的边缘了是吧，默默骂着街，你为什么要查我户口。
中心思想是简化用户操作
二、设计角度
表面上的性能问题，本质上是用户反馈的体验差
1、数据加载等待
- loading效果
在我看来，每个请求数据接口，加载loading效果是必不可少的，绝对不可能让用户默默的看着一片空白愣神几秒钟，至少得盯着一个antd的菊花。别说用户了，你家产品经理也受不了。 - 预加载
在开发中，可能会遇到这样的情况。有些资源不需要马上用到，但是希望尽早获取，这时候就可以使用预加载。
预加载其实是声明式的 fetch ，强制浏览器请求资源，并且不会阻塞 onload 事件，可以使用以下代码开启预加载<link rel="preload" href="http://example.com" />
预加载可以一定程度上降低首屏的加载时间，因为可以将一些不影响首屏但重要的文件延后加载，唯一缺点就是兼容性不好。
2、首页加载等待
- 首页单独维护
我曾经做过一个设备商城可下单的系统，首页做的很炫酷，但是身后的管理系统十分庞大，所以会拖延首页加载时间。这时我们给出了解决方案就是首页单独维护，首页单独用原生html编写，采用双页面应用的结构，让用户访问首页的时候可以秒进，配合系统路由入口处做拦截认证 - 首页加载动画
这个场景也很普遍，这时候就得找一个就算系统加载很慢，但是让用户看3分钟这个加载动画也不会感觉到焦虑的效果。例如：
- 骨架屏
京东惯用方式，针对一下网速过慢的情况，先弄了个“假”界面。
3、页面切换过渡
业务跟业务之间切换时候加上过场动画效果，会给用户一种很丝滑的感觉，要调试出一种下雨天跟angelababy一起吃巧克力的感觉。
曾经有个项目中，因为时间比较富裕，也是产品展示类网站，我做了全套的页面切换过渡效果，在项目路由切换的时候封装一层，跳转之前，让当前组件淡出，跳转之后让下一个组件淡入。最终效果很好，无缝衔接。
4、适当的动画效果
每个项目或多或少都会添加动画效果用来当做操作的过渡，一个很经典的案例，购物车抛物线问题，想当初淘宝天猫的购物车 点击商品右下角购物车图标的时候会有一个圆球，以一条优美的抛物线落在页面右下角购物车tab上，效果非常好，让人忍不住想多买几个产品，就想多看几次动画。极大的提升了用户体验。
三、UI角度
我们得知道我们能压榨UI多少资源
1、大型图片
减少像素点
减少每个像素点能够显示的颜色
-
png8
这里我就直接推荐png8质量格式，直接让UI把图片压缩为png8 像素点64即可，然后注意一点，我们开发时候用的图片都是需要200%大小的，因为需要适配高清屏，但是UI的宗旨呢是越大越高清越好，如果UI给你的图片尺寸大于200%，需要提出图片尺寸的问题。
当然，UI没时间的时候，推荐fireworks，操作及其简单，为前端而生的photoShop。只需几步，UI就会爱上你。 -
webp
见怪不怪，刚出webp的时候自己吹的大小缩小了60%，图片效果上没有变化，纯算法压缩。因为兼容性不够好没有流行起来，最近我又查了一下，网上很多跨浏览器兼容解决方案有很多，比如webp.js。已经很好的解决了兼容性问题，可以投入使用。
2、中小型图片
-
sprite
北方称 精灵图，南方叫
雪碧图，通过请求一次大照片，通过background—position定位小图片的位置，节省带宽，一种经久不衰的方式。 -
iconfont
不多解释了，感谢iconfont -
base64
这个很有争议，争议在于多大的图片用base64才好，争论着争论着后来就没人用了。。。，webpack中可以配置多大以下的图片编码成base64打进js中。module中配置的limit为大小控制
{ test: /\.(png|jpg)$/, loader: "url?limit=0" } -
svg
小技巧之：当你用到一张gif的时候，UI可以导成svg格式的给你。我说的是线性的。
3、UI不让动的图片
这种情况也是很常见的，产品渲染图之类的，例如刚出的米酒手机，官网上的海报
这时候果断：“老板，给我拿钱我去买个CDN”。
CDN 内容分发网络，这个我听过一个通俗的例子。
以前买火车票大家都只能去火车站买，后来我们买火车票就可以在楼下的火车票代售点买了。
大家自己悟一下就懂了。
这里注意一下，注册CDN的账号用老板的不要用自己的，不然不好离职（我就是）
4、图片渲染
- 懒加载
老生常谈，只加载可视窗口的图片。 - 预加载
新生没谈，提前加载下一个可视窗口的图片，并非全部，只是下一个可视窗口。做过瀑布流的应该知道。没做过的可以按照这个思路自己探索一下。
四、开发角度
1、选择适合项目成本的架构
为什么这么说呢，一般来说pc站的项目架构对于移动站来说就显得沉重，越往前追忆越注重这一点，尤其在jquery年代。为了解决此问题，很多框架都会出一款mobile版本、轻量版本。现在的UI框架大多都没有此问，例如antd，打包的时候只会把你引用到的组件打包到文件中，没引用到的组件不会被打包到文件中。bootstrap就正好相反。
我想这也是响应式项目逐渐gg的原因，并没有抗住2G 3G时代，我相信如果5G普及了，移动端项目也不用考虑框架大小的问题了。
然而，成本一说，还有一个比较基础的概念，按照开发周期来说，理论上开发周期短的项目，我们采用一些高度封装的开源组件高效完成。缺点就是，高度封装的开源组件引用之后不方便以后需求更新迭代。反之，较长的开发周期是我们正想要的。
2、降低算法复杂度
我身边大多数人对算法的理解：
没有我两遍循环处理不了的数组！
最终我们处理1w条数据的时候，底层一些组件render了100w+次，导致浏览器间歇性崩溃。
这种情况首先从组件角度来说，并没有做好拦截render的处理。类似于react的shouldComponentUpdate。
之后则是算法复杂度的问题。并没有优化。
就好比最基础的查找算法，大家应该也该了解穷举法和二分法哪一个好一些
算法复杂度是指算法在编写成可执行程序后，运行时所需要的资源，资源包括时间资源和内存资源。
这个值得单拿出一篇文章来讲，但是我这边暂时直接给出一个现在很多大公司的招人规范，leetcode算法题库，腾讯前端要求leetcode easy难度。大家可以去刷刷题，很有帮助。
3、按需加载
注意一下：这个并不是每个项目都适合
那么，什么样的项目才适合按需加载呢？
展示类项目，例如小米官网，每次发布一款手机后，我都需要加个菜单，加一个独立的展示类业务。
那么，什么样的项目不适合按需加载呢？
管理系统，系统为一个整体，中间参数串联太狠，本地开发没什么问题，按需打包之后扔到测试环境就各种undefined。
4、数据的预加载
在开发中，可能会遇到这样的情况。有些资源不需要马上用到，但是希望尽早获取，这时候就可以使用预加载。
预加载其实是声明式的 fetch ，强制浏览器请求资源，并且不会阻塞 onload 事件，可以使用以下代码开启预加载
<link rel="preload" href="http://example.com" />
预加载可以一定程度上降低首屏的加载时间，因为可以将一些不影响首屏但重要的文件延后加载，唯一缺点就是兼容性不好。
还有一种，比如说我有两个tab页签。通常情况，用户点击第二个tab的时候才会去获取数据。其实当用户鼠标放上去的时候就可以获取数据了，点击操作结束后，数据已经请求回来了。这种方式也是非常不错，但是注意一下节流，鼠标来回晃，发起一万个请求，后台会以为谁攻击服务器了。
5、缓存
资源文件走缓存，见怪不怪，用得好是利器。
我的项目统一，万年不变的文件统统走缓存，放在public中手动加hash，其他src下面的自动hash。
webpack可以配置，可以控制哪些文件加hash，哪些不加，也可以控制哪些文件的hash需要变，哪些不需要变。大家可以了解一下。
END
今年还没安排出差的任务，但是有预感也快了，有人就问了，为什么你出差不写文章呢？ 有时间都出去玩了好嘛，哈哈。 沉淀了一波，我这边3月底之前会写4篇文章，分别为
- 《前端性能优化交流》
- 《前端代码质量优化交流》
- 《前端code监控交流》
- 《前端安全问题交流》
沉淀一下去年在开发流程方面的一些知识。 谢谢各位。
