过完年了也是一直拖到了现在才有时间补交一下作业, 去年出差出了一年, 是时候好好沉淀一下了
目录
前言
设计角度
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 不让动的图片
这种情况也是很常见的, 产品渲染图之类的, 例如刚出的米酒手机, 官网上的海报
这种图片你压缩减少个像素点呐, 减少每个像素点展示的颜色啊, UI 不来砍你, TF 粉丝也会来砍你, 是吧.
这时候果断:"老板, 给我拿钱我去买个 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 监控交流》
《前端安全问题交流》
沉淀一下去年在开发流程方面的一些知识. 谢谢各位.
来源: https://juejin.im/post/5c74a1ec6fb9a049e063fd20