過完年了也是一直拖到了現在才有時間補交一下作業，去年出差出了一年，是時候好好沉澱一下了
目錄
- 前言
- 設計角度
- 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監控交流》
- 《前端安全問題交流》
沉澱一下去年在開發流程方面的一些知識。 謝謝各位。