有理有據(jù)，有面有料，是一個設計作品的專業(yè)體現(xiàn)。之前花了四篇小文（鏈接在文末），講述如何提升設計師設計作品的內(nèi)在含金量和外在形式感，今天，我們將用最后的篇幅，聊聊如何給設計作品創(chuàng)造一個盡可能完美的終局——交互文檔的細節(jié)。
千里之堤毀于蟻穴，再專業(yè)的交互設計，如果在后期交付時頻繁出現(xiàn)細節(jié)的缺失和補充，其實還是很容易遭受研發(fā)和測試同學diss的。甚至有可能因為一個細節(jié)的疏忽，導致整體交互方案的崩盤，不得不從頭再來。
如果研發(fā)過程中發(fā)生這樣的設計事故，其實是非常影響團隊士氣和個人專業(yè)影響力的。
設計細節(jié)篇，分兩個維度來闡述，一個是文檔外,一個是文檔內(nèi)。
文檔外，其實是要回歸設計的初衷，很多設計師包括我自己，設計久了，總愿意把自己當作是用戶的代言人，盡可能的為用戶體驗著想，絞盡腦汁的尋求最佳體驗的設計，并以此為傲。
這如果是在產(chǎn)品發(fā)展的成熟期，功能相對穩(wěn)定，體驗同質(zhì)化嚴重，這個時候追求的體驗，尋求體驗的突破是非常有意義的，可以讓產(chǎn)品獲得更多的口碑，從而帶來更多的用戶和收益。
但是如果是在探索期和成長期，過度的追求單一維度的體驗，可能反而會成為一種產(chǎn)品發(fā)展的桎梏，阻礙產(chǎn)品的成長，而在衰退期追求的體驗，則完全背離了公司作為商業(yè)組織的利益點，會顯得和整個項目組格格不入。
產(chǎn)品生命周期與用戶體驗要求
所以對于探索期和衰退期的產(chǎn)品來說，設計師要盡可能考慮商業(yè)性和技術可行性。用最小的設計代價，快速的迭代，完成產(chǎn)品的目標（驗證價值或解決問題）。
如果設計師在這兩個階段太揪細節(jié)，可能會因為得不到項目的支持而心灰意冷。
技術可行性和商業(yè)收益，不是我們所擅長的領域，通過前面的設計法則和用戶埋點也不能準確推算，所以還需及時向技術及商務同學確認，別人家能做的產(chǎn)品形態(tài)，咱們家技術框架不一定支持。別人家能做的精簡，可能會損害咱們家的主營業(yè)務。
涉及到這兩點，除非有自上而下的旨意，否則單憑設計之力無異于蚍蜉撼樹，很容易讓自己費力不討好。
文檔內(nèi)的交互細節(jié)，主要在于文檔的完整性和閱讀體驗，既要面面俱到，又要清晰簡潔。
面面俱到是指要盡量包含所有流程、頁面及狀態(tài)，避免遺漏。它體現(xiàn)了一個交互設計師設計思維的嚴謹性和設計態(tài)度。
網(wǎng)上有很多關于交互走查表的模板，非常的全面，但就是因為太過全面，反而讓很多新人設計師望而生畏，避而遠之，這就失去了交互走查表本身的意義。
我認為，交互走查表其實就是提供給設計師的一份幫助文檔，大家都知道在設計的時候，提示要盡可能的簡短，要適時出現(xiàn)，要清晰簡潔，遺憾的是我看到的交互走查表往往都不滿足這一條。
冗長的交互走查表，就像是冗長的幫助文檔一樣，把責任都推給了設計師，仿佛在說：誰讓你不按照我逐條檢查呢？
如果出現(xiàn)細節(jié)的遺漏，就變成了設計師自己的錯。
誰都不想遺漏，但是后期設計時間往往真的就很緊迫，設計師除了細節(jié)的補充，可能還有其他很多任務需要做，大家只是想確認一下而已，哪有時間和精力去看那么冗長的“幫助文檔”。
所以發(fā)揮一下設計師的同理心，根據(jù)二八原則，80%設計師可能遺漏的問題都只是認知走查表里20%的內(nèi)容，這20%的內(nèi)容也真正意義上影響我們80%的用戶和體驗，是設計者最為關心的。
那么，我們是不是先把這20%的設計解決好呢？這才是真正急設計師之所急，站在設計師的角度考慮問題。
所以本文精心篩選出最容易被大家所忽略，且大多數(shù)設計又必須要考慮的異常分支，為大家整理了一份《設計細節(jié)check表》，以確保主體流程的主要設計“面面俱到”。（流程設計、布局設計，以及互動設計，如果大家在前期有遵守對應的設計原則，再加上數(shù)據(jù)的支持，應該大方向都是正確的。我也希望大家盡量通過前期的理論和數(shù)據(jù)，去保證流程和整體設計的正確性，而不是要等到最后細節(jié)確認的時候，才來審視檢驗整體，讓細節(jié)篇，真的是在完善細節(jié)。）
設計細節(jié)Check表
我把這份《設計細節(jié)check表》按照從整體到局部進行了歸類：
最大的單元是指每個任務流程的檢查，然后是頁面單元，因為頁面涉及到加載的異常分支比較多，所以單獨拆出來和頁面狀態(tài)并列分別闡述。最后是組塊單元，主要包括輸入類和非輸入類的組件操作及反饋。
下面我們逐一來看：
流程檢查主要包括三點：
秉承一致性原則，同一個產(chǎn)品，能保持一致的地方，要盡可能保持一致。
在實際項目中，同一個產(chǎn)品，往往有多個設計師，每個設計師都負責相對獨立的一大模塊，偶爾就會涉及到相似功能的設計，因為是不同人在進行，所以設計出來的形態(tài)就可能不一致；
但對于用戶來說，使用相似功能的人，往往可能是同一撥人，設計的不一致，體驗就會有差異，不僅對于用戶來說學習成本高，而且對于項目組來說同時維系兩套不同的設計，成本也比較高。
如果一個流程的正向流程和逆向流程是完全一致的，一般無需特別說明，但是如果返回時需要跳過某些頁面或者狀態(tài)快速返回，則需要進行特殊標注，否則可能會被研發(fā)同學遺漏。
當遇到特殊情況，程序崩潰，后臺殺死，斷電等，進度是否能夠能自動保存并恢復，如果需要，就需要考慮恢復的時機和形式。
說完流程，再來說單獨的頁面。談到頁面時，首先要談的是加載狀態(tài)，畢竟頁面不是憑空就有的。
加載狀態(tài)主要要考慮以下幾點：
預加載的時機是什么時候，預加載的內(nèi)容有多少？（對于用戶會長時瀏覽的內(nèi)容，一般建議預加載，預加載的內(nèi)容一般會結合內(nèi)容大小、瀏覽時長、甚至網(wǎng)絡狀態(tài)綜合決定）
在信息未加載出來前，界面是顯示空白引導，還是默認占位符，還是顯示上一次的緩存內(nèi)容？（一般有緩存優(yōu)先顯示緩存，無緩存先顯示默認占位符，等內(nèi)容加載完成后再進行替換）
是否顯示加載圖標，進度條，是否可以取消加載？（一般情況下等待超過0.1s，就能夠被用戶感知到，就建議顯示加載圖標，以便用戶知道程序已經(jīng)接收到并在響應用戶的操作指令。如果等待超過1秒，就建議顯示進度條，并提供取消操作，便于用戶自主控制）
是全部加載，還是分布加載顯示？（一般情況下，在2~3屏內(nèi)的有限內(nèi)容，或者完全非同類的內(nèi)容，是可以一次性全部加載的，因為用戶可能就是沖著某一類內(nèi)容進來的，很可能會快速滑動到目標內(nèi)容。
而對于同類型的圖文信息，而且是內(nèi)容比較多時，一般都會采取分布加載的形式，避免浪費多數(shù)用戶的流量。
視頻播放機制、廣告圖片加載等，一般還要考慮網(wǎng)絡情況，一般WIFI情況下，因為對流量及網(wǎng)速的要求低，所以采用自動播放視頻，自動顯示圖片、播放廣告等，更容易被用戶所接收）
是否自動重試加載，何時進行超時提示等。（很多產(chǎn)品在設計時，如果不是完全無網(wǎng)絡，僅僅是網(wǎng)絡信息不穩(wěn)定，會嘗試自動加載，以避免用戶手動操作。如果自動加載超過上限，才會提示讓用戶稍后再試）
頁面加載出來后，就要要考頁面本身的狀態(tài)了。
需要考慮的異常頁面狀態(tài)主要有以下幾種：
考慮完整體頁面后，最后再來考慮一下頁面內(nèi)的組件狀態(tài)。先來看一下輸入類。
輸入框/文本框要考慮的主要有三點：
最后看一下非輸入類的操作組件。
“文本/圖標按鈕、鏈接、可操作的卡片/列表”要考慮一下幾點：
如果設計完成后，初步檢查以上五項內(nèi)容，基本上可以確定主題流程的主要設計內(nèi)容已經(jīng)面面俱到了。
文章來源：人人都是產(chǎn)品經(jīng)理
HMI是什么？這又和我有什么關系，如果你想置身于智能時代，HMI的認知是一個不可錯過，而海哥把這一生的精力投身于該領域，下面我們開始開啟這條認知之路。我將分三個部分闡述HMI，分別是：HMI是什么？HMI有什么用？誰在做HMI？
HMI，是英文Human Machine Interface的首字母縮寫，中文意思為“人機界面”，或“人機接口”，在國內(nèi)用“人機界面”多，HMI是“人與機器之間傳遞和交換信息的媒介和對話接口”，可以簡單理解為是一臺微型的電腦，外形像平板電腦，比如蘋果的iPad，但是她有很多插口，像傳統(tǒng)辦公桌上的臺式電腦（后面稱PC電腦），有usb接口、網(wǎng)線接口、串行接口。通常HMI像個積木一樣，嵌入到機器上的，一般是自動化大機器，通過HMI來控制和監(jiān)視機器的運作，你可以理解為HMI是一臺電腦，她控制打印機打印東西這樣的關系。海哥帶你看看HMI廬山真貌：
看起來是不是一個平板電腦嗎？對的，外形看起來像平板，但是它比較厚，而且很多電腦用的接口，而大家在生活中接觸最多的兩種HMI有兩種，一種是取款機，另外一種就是汽車中控。
下面，海哥帶你了解HMI組成，它是由兩大部分組成的，就是硬件和軟件。
HMI硬件方面，像PC電腦一樣，有五大模塊：處理器（如CPU）、顯示單元（如顯示器）、輸入單元（如鼠標、鍵盤）、通訊接口（如網(wǎng)卡）、數(shù)據(jù)存儲單元（如硬盤），那一個優(yōu)質(zhì)的HMI硬件主要看哪方面呢？就是處理器，處理器有8位、16位、32位，數(shù)字越高，處理能力越強。接下來看看硬件周邊的接口，HMI可以連接很多種設備，比如可編程控制器（簡稱PLC）、變頻器、直流調(diào)速器、儀表和工業(yè)設備等，它們連接到HMI的串口接口，串口的類型有RS232、RS485等。
好了，上面大概對HMI的硬件有初步了解，下面海哥帶你看看軟件部分，軟件部分包括兩部分，就是系統(tǒng)和畫面組態(tài)軟件。系統(tǒng)就像PC電腦的windows系統(tǒng)一樣，有自身硬件運作正常的系統(tǒng)，比如我們?nèi)A為的鴻蒙OS系統(tǒng)。接著就是畫面組態(tài)軟件，其實就是像windows里面的Word軟件，叫法上不一樣而已，常規(guī)情況下畫面組態(tài)軟件只有一個，不能像windows那樣裝很多種類型軟件，而HMI固定是裝一種，我們常規(guī)叫他為“工程”，當然汽車上的HMI，就像平板電腦上，功能和軟件都很豐富，因為它是滿足消費者人群的，而只運行一個軟件的，多用在工業(yè)機器上，可以減少HMI資源消耗，還能保證整個HMI的穩(wěn)定性。
海哥剛開始對組態(tài)軟件不太懂，組態(tài)到底是什么？“組態(tài)”（Configure）是“配置”、“設定”等意思，它讓用戶像搭積木一樣，把所需要的軟件功能搭建起來，不需要編寫計算機程序。目前常用的組態(tài)軟件有：iFix、Vijeo Designer、WinCC、組態(tài)王、MCGS，不同廠家的HMI硬件使用不同的組態(tài)軟件，所以他們連接要有不同的驅(qū)動程序，這對技術人員來說，學習成本還是比較高，因為目前還沒有一個巨頭來定義這個通用標準，而最近華為的鴻蒙OS系統(tǒng)，開始定義行業(yè)的平臺標準，海哥個人覺得這是一件了不起的事情。下面看看常用的組態(tài)軟件長什么樣子，我們用WinCC作為例子。
接下來，海哥告訴你HMI的分類，大概可以分三種：
（1、薄膜鍵輸入的HMI，顯示尺寸小于5.7ˊ，畫面組態(tài)軟件免費，屬初級產(chǎn)品。
（2、觸摸屏輸入的HMI，顯示屏尺寸為5.7ˊ～12.1ˊ，畫面組態(tài)軟件免費，屬中級產(chǎn)品。
（3、基于平板PC計算機的、多種通訊口的、高性能HMI，顯示尺寸大于10.4ˊ，畫面組態(tài)軟件收費，屬高端產(chǎn)品。
對于高端HMI產(chǎn)品，面對5G的個性化定制的市場特征，HMI的“配方功能”會很重要，所謂配方功能，就是一臺設備完成不同種類工件的加工，這需要人機界面上具備配方功能，在加工A產(chǎn)品時，執(zhí)行A配方，加工B產(chǎn)品時，執(zhí)行B配方，比如西門子公司的MP系列，而如果要實現(xiàn)千人千面的生產(chǎn)需求，也許配方更是一個海量級的，這也是自動化所面臨的機遇與挑戰(zhàn)。
下面說說工作流程，一個HMI制作應用的制作過程大概是這樣的流程：
海哥簡短解釋一下這些流程，在日后海哥會在每個模塊都會有細節(jié)教程。
市場調(diào)研：了解到市面上的數(shù)據(jù)量，比如手機用戶數(shù)量，大部分用戶使用時長，競爭對手處于什么樣的狀態(tài)等；
用戶畫像：了解用戶的年齡、地區(qū)、行為習慣、心理習慣等，并賦予到一個場景中，了解用戶在場景中的整個活動和心理的過程；
需求定位：了解到目標用戶的特征后，定制產(chǎn)品或的重點價值，用戶為什么需要你，你有什么不一樣；
頭腦風暴：由不同崗位人員，一起想點子，先暢所欲言，再根據(jù)調(diào)研和需求來判斷合適的點子；
原型設計：原型簡單理解為手工紙質(zhì)品，或模型，可以用塑料泡沫或電腦的Axure等軟件，做出實體或虛擬的產(chǎn)品，這需要快速簡單進行；
可用性測試：測試原型是否可行，讓一些陌生人用用，看他們能理解這是什么，會不會用等；
高保真設計：就是把“毛坯房”變成精裝修，開始做最終的視覺效果；
開發(fā)制造：開發(fā)與機器制造，實現(xiàn)功能；
測試修復：用一種極端條件來檢查產(chǎn)品有沒有問題，比如24小時運作會不會有問題，突然斷電有沒有問題；
版本迭代：第一代產(chǎn)品做出來不等于成功了，因為市場在變，用戶也在變，需要保持變化，優(yōu)化產(chǎn)品。
下面是一些問題，可以幫助大家更好了解HMI：
問：HMI看起來不就是一個很厚的觸摸屏嗎？
答：HMI是由兩部分組成，分別是硬件和軟件，而像手機或平板的那種觸摸屏，只是一個觸摸的硬件，這種只是讓你能觸摸的部件而已，可以理解為臺式電腦上的顯示器，只是這個顯示器可以觸摸。
問：PC電腦能當HMI設備用嗎？
答：當然可以，只是PC電腦不在會嵌入到機器上，而是通過很長的線或者無線網(wǎng)絡連接到機器，而PC電腦需要通過HMI的軟件，來操控機器。
問：SCADA與HMI的區(qū)別？
答：SCADA是監(jiān)控和數(shù)據(jù)采集系統(tǒng)，英文是Supervisory Control And Data Acquisition，它包含HMI，SCADA是整局的工業(yè)控制系統(tǒng)，范圍更大。
HMI有什么用？海哥認為，有機器的地方就有HMI存在的可能性，特別是5G物聯(lián)網(wǎng)的“萬物互聯(lián)”的到來，數(shù)據(jù)不只是在電腦上流動，還會在機器、衣服、鞋子、碗、車等場景中串聯(lián)，而把目光放在當下，HMI應用領域已經(jīng)在機器、工廠、建筑物、汽車、高度監(jiān)管的制藥和食品行業(yè)、石油/天然氣、采礦等領域已經(jīng)有運作，從這些行業(yè)屬性來說，你有沒發(fā)現(xiàn)從事HMI的行業(yè)的人，它的市場體量有足夠大的想象空間？哈哈，別拉后腿了，與海哥一起跟上。
目前的HMI可以做些什么呢？
（1、實時的信息狀態(tài)與趨勢顯示；
（2、圖形化、流程化控制生產(chǎn)線監(jiān)控和控制；
（3、警報的產(chǎn)生和記錄；
（4、歷史信息的自動記錄、報表自動生成；
HMI的意義有哪些呢？
（1、發(fā)揮機器應有的功能，因為你可以通過數(shù)據(jù)顯示上了解到；
（2、人工合理調(diào)節(jié)機器參數(shù)，讓機器間的協(xié)作、使用效率提高；
（3、HMI預警能確保安全與經(jīng)濟提升；
（4、讓使用者操作機器和系統(tǒng)更友善，符合他們的生理、心理的需求，提高使用者的滿意度；
想在這個行業(yè)有所作為，我們怎么能不知道行業(yè)的頂尖高手在哪呢？有了標桿，起碼可以衡量我們自身的水準，還有我們?nèi)笔裁?，從另外一個角度來說，你如何作戰(zhàn)略選擇，讓自己也能從差異化中，變成另外一個頂尖高手，下面我們看看專注于HMI的企業(yè)，海哥找來自動化制造類的和汽車類的，行業(yè)很深很大，日后海哥繼續(xù)挖掘新的。
下面是自動化領域HMI企業(yè)。
三菱
網(wǎng)址：www.mitsubishielectric.com
三菱奉行的企業(yè)經(jīng)營理念“Changes for the Better”，“One三菱電機”為中國“更好的未來”和實現(xiàn)“更好的社會”做貢獻為經(jīng)營理念。e-F@ctory靈活運用IT技術，將生產(chǎn)現(xiàn)場與上層信息系統(tǒng)直接相連。即可實現(xiàn)工廠的“可視化”，同時又能促進生產(chǎn)設備的高性能化和最優(yōu)化，縮短開發(fā)及調(diào)試周期，降低運用及維護成本，從而削減生產(chǎn)工序的整體成本，實現(xiàn)“工廠全面最優(yōu)化”
西門子
網(wǎng)址：www.industry.siemens.com.cn
面對日益復雜的機器和系統(tǒng)過程，作為一站式供應商，西門子專門設計開發(fā)出了 SIMATIC HMI 人機界面技術。SIMATIC HMI 采用開放式、標準化硬件和軟件接口，可快速集成到用戶的自動化系統(tǒng)中，從而滿足用戶的特定人機界面需求。
施耐德
網(wǎng)址：www.schneider-electric.cn
施耐德電氣是家居、樓宇、數(shù)據(jù)中心、基礎設施和工業(yè)領域能源管理與自動化技術數(shù)字化轉(zhuǎn)型的領先企業(yè)?！拔覀兊目萍?，無處不在”，施耐德電氣確保每一個人，在任何時間，在任何地方都能盡享能效之利。
歐姆龍
網(wǎng)址：www.omron.com.cn
創(chuàng)立于1933年的歐姆龍集團是全球知名的自動化控制及電子設備制造廠商，掌握著世界領先的傳感與控制核心技術。通過不斷創(chuàng)造新的社會需求，歐姆龍集團已在全球擁有超過35,000名員工，營業(yè)額達8,595億日元。產(chǎn)品涉及工業(yè)自動化控制系統(tǒng)、電子元器件、汽車電子、社會系統(tǒng)、健康醫(yī)療設備等廣泛領域，品種多達數(shù)十萬種。
BEIJER 北爾
網(wǎng)址：www.beijerelectronics.cn
北爾電子成立于1981年，總部在瑞典南部的Malm?。北爾電子是上市公司北爾集團三大事業(yè)部之一。北爾集團的客戶包括 阿法拉法(Alfa Laval)、龐巴迪(Bombardier)、阿爾斯通(Alstom)和艾默生(Emerson)等要求苛刻的大型跨國企業(yè)。2018年北爾電子集團銷售額達到14億瑞典克朗。
臺達
網(wǎng)址：www.deltaww.com
臺達成立于1971年，總部在臺灣，為全球提供電源管理及散熱解決方案，秉承“Smarter. Greener. Together.”的品牌理念，自動化模塊中，專注于交流馬達驅(qū)動器、電源治理、感測、控制與運動等產(chǎn)品領域的創(chuàng)新研發(fā)，同時整合工業(yè)自動化產(chǎn)品，繼而開發(fā)工業(yè)控制網(wǎng)絡，為全球客戶提供全方位的解決方案服務。
汽車中控領域HMI服務企業(yè)中，海哥找了三家，他們分別是：HARMAN、INTELLIAS、ELEKTROBIT。
HARMAN
網(wǎng)址：www.harman.com
1980年成立，總部在美國，它是三星的子公司，公司員工規(guī)模過萬，開發(fā)聯(lián)網(wǎng)汽車系統(tǒng)，音頻和視頻產(chǎn)品，企業(yè)自動化和互聯(lián)服務。北美，歐洲和亞洲汽車制造商是哈曼的客戶。該公司還是HMI軟件開發(fā)服務的先驅(qū)提供商。
INTELLIAS
網(wǎng)址：www.intellias.com
Intellias是一家定制軟件工程公司，專注于汽車、基于位置的服務和金融技術行業(yè)。公司員工規(guī)模上千人。Intellias被Inc. 5000公認為歐洲最有前途，發(fā)展最快的私營公司之一。該軟件開發(fā)公司也被列入全球外包100。
ELEKTROBIT
網(wǎng)址：www.elektrobit.com
作為汽車軟件行業(yè)的領導者，憑借 30 多年為本行業(yè)服務的經(jīng)驗，EB 的軟件為 1 億多輛汽車中的逾 10 億臺設備提供支持，并提供針對互聯(lián)汽車基礎設施、人機界面 (HMI) 技術、導航、輔助駕駛、電子控制單元 (ECU) 和軟件工程服務的靈活、創(chuàng)新的解決方案。
總結一下，今天的《海哥HMI人機交互》，海哥帶你了解了HMI是什么，可以簡單理解HMI就是一個平板PC，既包含了硬件，又包括了軟件系統(tǒng)，硬件方面核心是看處理器，而軟件方面需要用組態(tài)軟件來開發(fā)，針對項目來做定制開發(fā)，開發(fā)出來的工程文件，通過串口下載到HMI的處理器上，這樣HMI就可以管控自動化生產(chǎn)的設備，HMI是SCADA總要組成部分。
文章來源：站酷
Struts2中轉(zhuǎn)發(fā)和重定向的區(qū)別以及實現(xiàn)方法
最近遇到一個問題，就是在設置struts2的攔截器以后，想要訪問必須登錄，想要的效果是轉(zhuǎn)到登錄頁面，也就是轉(zhuǎn)到xxx.jsp，但是發(fā)現(xiàn)沒有轉(zhuǎn)到，而是action結尾的，后來發(fā)現(xiàn)是因為在struts.xml里面配置的時候，沒有在result中配置type屬性，struts默認的是重定向，就是網(wǎng)址不變，解決辦法就是在result中加type=”redirect”,就可以了
轉(zhuǎn)發(fā)和重定向的區(qū)別：
重定向是不共享request的東西，重定向后的頁面中無法接收request里的東西，另外dispatcher結果類型的default屬性為TRUE，故<result- type/>缺省為dispatcher 所以如果沒有設置type屬性的話，那么默認的是請求轉(zhuǎn)發(fā)，就是說你要是什么都不寫的話，默認就是這樣的
1
<result name="list" type="dispatcher">/admin/jsp/userAction/list.jsp</result>
1
重定向的兩個屬性：
redirect是在處理完當前Action之后，重定向到另外一個實際的物理資源，以.jsp結尾這樣的
redirectAction也是重定向，但它重定向到的是另外一個Action，就是以action結尾這樣的
只要是重定向，那么之前凡是保存在request里面的東西就全都消失了
因為重定向?qū)嶋H是發(fā)送第二個請求，故請求中的東西也就不會出現(xiàn)在第二個請求里面了
也就是說重定向是不共享request的東西，重定向后的頁面中無法接收request里的東西，
藍藍設計( sillybuy.com )是一家專注而深入的界面設計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務。
Sketch 58 Beta 版本已于近期推出（其實最近一段時間已更新了好幾個測試版），官方終于推出 Smart Layout 智能布局，讓 Symbol 組件獲得響應功能，變得更加靈活和強大。
之前我們只能使用第三方插件來制作響應式組件，比如之前介紹的 Kitchen 和 Anima。不過畢竟不是官方親生的，難免會包含一些 bug 和不足。
比如 Kitchen 插件在制作 Symbol 組件的時候，其自動排版功能會出錯。Anima 插件對上傳到藍湖的標注會有顯示問題。關鍵是在團隊協(xié)作的時候，其他使用源文件的同學也必須安裝對應的插件，否則沒有效果。
那么這次 Sketch 58 Beta 版本新推出的 Smart Layout 智能布局功能，能否解決長期困擾設計師的響應布局問題呢？一起來看下。
如果想體驗 Sketch Beta 版本，請進入 Sketch 測試版主頁下載→https://www.sketch.com/beta/。但是要記住，一定不要用在自己的正式文件中，防止修改后，低版本打不開。
Sketch 58 要求 Mac 系統(tǒng)版本是 macOS High Sierra 10.13.4 及以上，下面是 Sketch 各大版本對應的 Mac 系統(tǒng)版本，如果遇到新版的 Sketch 打不開就需要檢查下自己的系統(tǒng)版本。
本次 Sketch 58 Beta 最大的更新就是 Smart Layout。
在新建 Symbol 組件時，彈窗新增 Layout 選項，總共有 7 個屬性，分別對應不同的圖標，下面是每個屬性的簡單介紹。
1. No Layout
正常布局，也就是和原先一樣，沒有特殊效果。
2. Left to Right Layout
賦予 Symbol 組件智能布局效果，組件尺寸會根據(jù)內(nèi)容變化，方向是水平從左往右布局。
3. Horizontally Center Layout
同上，方向是中間往左右兩端布局。
4. Right to Left Layout
同上，方向是從右往左布局。
5. Top to Bottom Layout
賦予 Symbol 組件智能布局效果，組件尺寸會根據(jù)內(nèi)容變化，方向是垂直從上往下布局。
6. Vertically Center Layout
同上，方向是中間往上下兩端布局。
7. Bottom to Top Layout
同上，方向是從下往上布局。
另外在選擇好 Layout 屬性后，Symbol 頁面的畫板組件圖標會發(fā)生變化，除了 No Layout 布局還是之前的畫板圖標之外，其余 6 個都有對應的新圖標，看下圖。
此外，選擇畫板后，右側(cè)的屬性面板中會新增布局選擇功能，包含上面講的7種屬性，可隨時對 Layout 布局進行更改。
看上面的描述還是比較迷惑，實際上智能布局簡單來說，就是賦予 Symbol 組件內(nèi)容邊距的功能，尺寸隨內(nèi)容變化而變化，有點類似于前端 CSS 中的 padding 屬性。下面用實際例子展示。
以前我們使用過 Kitchen 和 Anima 制作過彈性按鈕。需求是，文字兩端的邊距（即CSS中的padding）保持固定，文字數(shù)量不固定，按鈕寬度隨文字內(nèi)容走。
那么在 Sketch 58 中，我們先制作一個按鈕，文字兩端的邊距是 20。
轉(zhuǎn)化為 Symbol，出現(xiàn)彈窗，在新增的 Layout 下拉中，選擇 Left to Right Layout，這樣文字變化時，左邊是固定不動的，內(nèi)容往右邊延展。
這樣一個彈性按鈕就做好了，不管文字有多少，兩端邊距永遠保持固定 20。和前端 CSS 中的 padding-left 和 padding-right 功能一樣。
如果這個時候我們再拉伸 Symbol，右側(cè) Overrides 會出現(xiàn)一個新的圖標：縮小實例以適配內(nèi)容。點擊后，被拉伸的組件會還原為文字內(nèi)容長度。
注意，這個和原先的重設覆蓋層圖標不同，不會清除覆蓋的文本內(nèi)容，只會還原為適合內(nèi)容大小。
以上是從左往右的布局，水平兩端和從右往左也是一樣的道理，只是方向不一樣，下圖是從右往左的布局。
這就是智能布局的主要功能，賦予 Symbol 組件 CSS 代碼 padding 屬性，具備響應特征。還需要注意的是，智能布局目前只針對 Symbol 組件，Kitchen 插件是可以作用于普通組的。
上面是單個組件的智能布局，如果是嵌套組件呢？也是可以的，一起試下。
我們把剛才做的按鈕橫向分布三個，再一起做成新的按鈕組 Symbol 組件，結構看下圖。
新的按鈕組內(nèi)，每個按鈕已經(jīng)是響應式的，那么做成組后就會保持組內(nèi)元素的間距固定，更改下文字內(nèi)容看下圖。
非常棒，已經(jīng)滿足了我們剛開始的需求。但是不建議嵌套過多，要保持組件化設計思維。當然了，間距問題，Sketch 57 已經(jīng)提供了多元素間距調(diào)整功能，只多了一步，但是不用把整體再次轉(zhuǎn)化 Symbol，大家可以根據(jù)自己的需要靈活選擇。
以上講的是水平方向布局，同理垂直方向布局道理也一樣，我們以最常見的信息卡片為例子。一般情況下卡片圖片不變，標題和內(nèi)容文字的不固定會導致卡片整體高度也會發(fā)生變化。利用智能布局我們可以讓卡片變成響應式擴展。
確定好上下左右的間距，例子中用的 16，然后建立組件，Layout 選擇從上往下布局，這樣標題和內(nèi)容文字增多，上下的間距是保持不變的，內(nèi)容高度自動增加。
以上就是 Sketch 58 Beta 版本新增的 Smart Layout 智能布局介紹。關于這個新功能，我們還可以做很多響應式的組件，提升設計效率。Sketch 的更新速度也在加快，很多之前第三方插件才可以實現(xiàn)的效果也被官方一一收入囊中。希望 Sketch 的發(fā)展越來越好，成為設計師真正的設計利器。
58 版本的歡迎界面也做了大更新，至于好不好看就因人而異了。最后來一睹芳容。
文章來源：優(yōu)設
vue 1.0.3 中 $set 函數(shù)是動態(tài)改變或添加一個 data 中的屬性值時 屬性 key 不可以使用純數(shù)字。
例如：
var app = new Vue({
el:"#app",
data:{
test:{
k1:'v1',
k2:'v2'
}
},
methods:{
changeTestValue:function{
// 動態(tài)改變 test 中某一屬性的值
var key = 'test.k1'; // 改變 test 屬性中的 k1 的值
this.$set(key,'changev1'); // 此處執(zhí)行沒有問題
// 改變 整個 test 的值可以使用
this.$set('test',{k1:'change-demo-v1',k2:'change-demo-v2'}); // 此處執(zhí)行沒有問題
// 動態(tài)給 test 增加一個屬性 k3
this.$set('test.k3','test-add-value3'); // 此處執(zhí)行沒有問題
// 此處有坑 當你的 屬性為全數(shù)字的時候，則 函數(shù)無效，不報錯，但是也添加不上值。
// 例如
this.$set('test.123','test-add-123'); // 此處執(zhí)行不報錯，但是也沒有效果。
// 所以在使用老版本vue的時候盡量避免 屬性 key 未純數(shù)字，或其他特殊字符。
}
}
});
除了這個坑以外還有另外一個坑，不過沒有具體試驗，
watch 監(jiān)聽某一值得變化，好像有點問題， 實際結果是只要 data 中的任意一個值發(fā)生變化都會被捕捉到。
最后還是使用 vue 2.x 以上版本吧，bug 少很多。
另外 $set 函數(shù)在2.x 中使用方式有所變化。
this.$set(target,key,obj);
target 對象類型，是需要賦值或修改的對象，
key 是字符串類型， 是 target 對象的屬性
obj 可以是字符串，可以是對象類型，是 你要修改的或增加的值
藍藍設計( sillybuy.com )是一家專注而深入的界面設計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務。
這幾天，各個產(chǎn)品群設計群又被「綠洲」的話題刷屏了，自從8月29日新浪悄悄上架了這款產(chǎn)品后，一時間中國版ins、意圖稱霸圖片社交、趁小紅書下架搶占用戶等等說服層出不窮。今天我們就從一個設計師的角度，看看綠洲這款產(chǎn)品有什么不同。
綠洲是一款社交產(chǎn)品，從已經(jīng)看到的產(chǎn)品功能和內(nèi)容上，類似ins，也就是說他是一款圖片社交產(chǎn)品，由新浪推出，目前處于內(nèi)測階段，除官方邀請的kol外只能通過邀請碼注冊使用。
社交產(chǎn)品在國內(nèi)難做大家都知道，原因也不必再說，但社交產(chǎn)品一旦做成產(chǎn)生的巨大利益和助推力又讓國內(nèi)大大小小的公司都在向這個寶藏發(fā)起沖擊。那么為什么新浪選擇的是圖片社交產(chǎn)品呢？
首先是基于國內(nèi)市場，還沒有出現(xiàn)一家獨大的圖片社交產(chǎn)品，不像國外已經(jīng)有了ins，國內(nèi)的圖片社交領域勉強還能算作是「藍海」，加上最近小紅書下架導致市場有短暫的空白，大批kol和內(nèi)容生產(chǎn)者出走。也正是推出這款產(chǎn)品的良好時機。
當然也有一種說法是：國內(nèi)的社交產(chǎn)品形態(tài)存在「跳代」的現(xiàn)象，從文字社交直接跳到了視頻社交，并已經(jīng)有了很成熟、用戶規(guī)模極大的產(chǎn)品抖音，所以從產(chǎn)品發(fā)展形態(tài)來看，圖片社交產(chǎn)品在國內(nèi)并沒有什么生存土壤。這里我直接說出自己的觀點：我認為圖片社交在國內(nèi)還是有機會的，而且機會不小。對此我有以下幾個維度的思考：
1. 信息含量和傳達效率
首先不可否認的是圖片的信息含量是遠遠大于文字的，使用圖片能夠更的傳達信息和更豐富的情感，想一想過去很多偉大的文學作品往往需要用一本書來體現(xiàn)某些情感和精神。但是在科技社會里，往往是一張攝影作品更能震撼人心，圖片中包含的信息更加直觀，人物、場景、顏色、故事都可以直接呈現(xiàn)在用戶面前，而不需要通過文字進行描寫，也不需要運用很多寫作技巧進行鋪墊。這并不是說圖片比文字更優(yōu)秀，而是說圖片的形態(tài)在互聯(lián)網(wǎng)產(chǎn)品中可以更的傳達信息和情感。
說到這可能有朋友會說：圖片的信息和情感的傳達更，那視頻也同樣比圖片的信息含量更多，更，為什么圖片社交還有機會呢？這就要說到下一個維度—內(nèi)容生產(chǎn)門檻。
2. 內(nèi)容生產(chǎn)門檻
無論是圖片社交還是視頻社交，內(nèi)容都是產(chǎn)品中極重要的一部分，例如現(xiàn)在大家在看抖音時，大部分高質(zhì)量內(nèi)容都是由專業(yè)的內(nèi)容生產(chǎn)者制作的，其中涉及到選題、劇本、拍攝、剪輯、后期、壓縮等等流程，即使不是專業(yè)的團隊生產(chǎn)也是身兼數(shù)職的多面手生產(chǎn)者。流程一長，工作量也就大大增加了。工作量一增加，門檻就會變高。如果不是為了靠抖音賺錢、如果不是為了增粉變現(xiàn)，又有多少人能投入這么多精力和時間去生產(chǎn)內(nèi)容？內(nèi)容不多、質(zhì)量不高又怎么吸引更多用戶來使用-參與-生產(chǎn)最后形成閉環(huán)？
綠洲則不是這樣，雖然用戶可以上傳視頻，但主要的內(nèi)容還是圖片，拍一張圖片的各種成本要比拍一段視頻小太多啦，結果就是有更多的內(nèi)容生產(chǎn)者可以參與進來，而不是被高門檻攔在產(chǎn)品之外，當你生產(chǎn)了一段內(nèi)容，至少要發(fā)給幾個親朋好友來看看吧？即使只在產(chǎn)品內(nèi)部發(fā)個動態(tài)，如果有人為你點贊、評論、又關注了你，至少再拍一點的動力會大一些吧？這樣循環(huán)下去，內(nèi)容、用戶就全部都有了。舉個極端一點的例子，如果微信只能發(fā)圖片，那么還會有這么多人使用嗎？原因也是圖片的生產(chǎn)成本要大于文字（非文學作品的文字）。所以我認為，內(nèi)容生產(chǎn)門檻也是綠洲的優(yōu)勢之一。
3. 信息接收程度
最后一點則是大眾用戶的信息接受程度。我們可能從新聞報道上經(jīng)常能看到體育記錄的突破，例如幾十年前科學家預言了人類短跑極限早就被突破幾十次了。或者是看到人類平均壽命在過去幾百年的時間里提高了幾十歲。這里我想說的是：當互聯(lián)網(wǎng)尤其是移動互聯(lián)網(wǎng)普及之后，人類對于信息可接收量增加了多少？過去看紙質(zhì)書和現(xiàn)在拿著手機，每天閱讀文字圖片視頻等等能達到過去的多少倍？這里我沒有找到專業(yè)機構的研究報告。但是這個增長程度我想大家的意見應該會十分一致。
信息接收能力的提高會倒逼著改變產(chǎn)品形態(tài)、過去我們每天只能接收2000個文字和50張圖片，所以我們習慣看報紙?，F(xiàn)在我們每天能接受10000個文字和300張圖片，所以我們在用頭條用微信用微信用抖音。當用戶有了適應一項改變的基礎，那么必然會出現(xiàn)滿足用戶這種進化的產(chǎn)品。抖音是，綠洲可能也是。
4. 磨刀霍霍的kol和網(wǎng)紅
前幾年無論公眾號、頭條號、直播很是催生了一批實現(xiàn)財務自由的幸運者們，但更多的確實沒有抓住平臺早期紅利的玩家，在眾多自媒體和直播平臺都成熟之后，想要從中獲利是越來越難了。這時候出現(xiàn)了一個新興的、并且很有潛力的新平臺。那這些錯過了上一波機會的預備役kol和網(wǎng)紅們會不會蜂擁而至呢？而更多的現(xiàn)有kol和網(wǎng)紅為了鞏固自己的地位、擴大影響力和粉絲規(guī)模也同樣會去參與一番。去了之后為了自己的利益更是會給更多人安利這個產(chǎn)品。
說他有潛力是因為它占據(jù)的天時、地利與人和。天時已經(jīng)說過，市場潛力巨大又縫小紅書下架，地利則是國內(nèi)暫無一家獨大的圖片社交產(chǎn)品，人和則是擁有幾億活躍用戶的微博作為后盾。如此的產(chǎn)品，再加上利益驅(qū)動。想必內(nèi)容方面已經(jīng)問題不大了。
5. 內(nèi)測+邀請的機制
這幾天下載了綠洲的朋友們應該都知道，如果你沒有邀請碼的話即使下載了也是不能注冊的，整個產(chǎn)品還處于「內(nèi)測階段」 。只有前期官方邀請的部分kol和少量內(nèi)測用戶才能使用，每個內(nèi)測用戶又只能邀請一定數(shù)量的更多用戶。并且整體內(nèi)測數(shù)量也有限制。截止9月4日下午內(nèi)測人數(shù)已經(jīng)滿了，之后即使有邀請碼也不能注冊使用。那么這個內(nèi)測+邀請機制有什么好處呢？
有種說法是饑餓營銷，利用用戶越得不到越想要的心理來獲取更多用戶。但這種說法有點說不通，因為內(nèi)測總?cè)藬?shù)是有限制的。并且現(xiàn)在不是幾年前了，可能今天你內(nèi)測限制注冊人數(shù)那明天用戶就把你忘了，畢竟現(xiàn)在產(chǎn)品這么多，娛樂活動數(shù)不勝數(shù)，已經(jīng)不是十年前那個產(chǎn)品稀缺的時代了。我大概有兩點猜想，一是產(chǎn)品方希望通過內(nèi)容試水，看看產(chǎn)品在市場上的反饋，進而做出符合國內(nèi)用戶習慣的修改再大規(guī)模推廣（嗯，之所以要做符合國內(nèi)用戶習慣的修改是因為他太像ins了~），二是產(chǎn)品方希望變「爆火三天死」為「細水長流」，之前的馬桶MT、聊天寶、包括子彈短信等等產(chǎn)品在剛剛發(fā)布的時候都是非常火爆、用戶在短短幾天之內(nèi)就過了百萬大關，但是現(xiàn)在呢？還有多少人在繼續(xù)用？增長曲線還敢貼出來嗎？而使用了內(nèi)測+邀請機制則不同，一方面可以保持用戶維持一定數(shù)量的增長，一方面又不會因為用戶的三分鐘熱度而快速冷卻，對于社交產(chǎn)品而言，如果你身邊有朋友在用，那你繼續(xù)用的概率就會大很多。如果你發(fā)現(xiàn)你身邊的朋友在用，那即使你已經(jīng)卸載了也有一定可能重新下載回來再用一用，也就是用細水長流的方式不斷召回之前的用戶，用留存做增長。
上面說了一些我為什么認為綠洲（或其他圖片社交產(chǎn)品）有一定生存空間的原因。下面我們來看看綠洲中一些很不錯的設計細節(jié)。
1. 條目巨大，更重視內(nèi)容質(zhì)量
用戶的一條動態(tài)（在產(chǎn)品設計中我們一般習慣稱之為條目，下面以條目稱呼它）往往占據(jù)了一整屏的空間，作者使用的還是長度較長的全面屏手機依然如此。這種設計可以在一定程度上說明產(chǎn)品方比較重視內(nèi)容。做產(chǎn)品設計的朋友應該都知道：條目占據(jù)的空間越大一般包含的信息量就越多，也更容易形成轉(zhuǎn)化，對應到綠洲中這個轉(zhuǎn)化就是點贊、評論、關注等等用戶的操作。一旦用戶做出這些操作，就會對產(chǎn)品形成更深度的使用習慣，也就有更多可能性變成活躍用戶。當然條目占據(jù)空間過大同樣有風險，也就是如果這一條內(nèi)容的質(zhì)量不夠高的話用戶可能會產(chǎn)生流失，因為用戶可能并不會繼續(xù)向下滑動去看下一條內(nèi)容了。所以一般內(nèi)容質(zhì)量較高的產(chǎn)品條目占據(jù)的空間較大，質(zhì)量較低的產(chǎn)品條目占據(jù)空間較小，希望一屏之中能夠容納更多數(shù)量的條目，用戶數(shù)量換質(zhì)量希望其中能有一條對用戶形成轉(zhuǎn)化。所以綠洲的這個設計細節(jié)作者猜測是產(chǎn)品方重視內(nèi)容的體現(xiàn)。
2. 上傳圖片，實時看到效果
如下圖：
當我們在上傳圖片時，頁面上部為圖片的放大展示圖，頁面下部分為縮略圖，用戶可以在選擇圖片時實時看到自己選擇的圖片的細節(jié)，舉個例子，如果某漂亮妹子想發(fā)張自拍，但是相機里保存的是幾十張連拍照片，此時她就可以在選擇圖片時直接看到自己當前選擇的圖片是否是自己最滿意的一張。而不需要上傳后才能看到，或是切換到系統(tǒng)相冊中去查看，再記住那張自己最滿意的照片的位置再回來重新上傳。
我們常見的產(chǎn)品中上傳照片時一般都是直接顯示縮略圖，好處是頁面效率高一屏可以展示更多圖片，壞處是不能直接看到照片的細節(jié)。這種設計比較好的平衡了這個問題。關于上傳圖片的優(yōu)秀設計我們前幾天還分享了ZAO里面的一個設計案例，下圖是ZAO核心流程中的兩個頁面，是選擇「影視劇片段」和「上傳替換素材」的頁面:
在此頁面選擇要替換的人物，點擊后進入下圖上傳素材，選擇從相冊選擇。
我們可以看到，當我們選擇從相冊上傳素材進行替換時，系統(tǒng)已經(jīng)自動對相冊內(nèi)的圖片進行了判斷，在用戶上傳照片之前就對照片清晰度是否合適進行了提示，而不是上傳后再給一個彈框。
作者對這個設計細節(jié)大致想法如下：
與上面案例相關的東西作者還想起了閑魚：
一是閑魚中，當用戶上傳的商品圖片比較模糊時系統(tǒng)會提示用戶重新上傳，以提高二手物品的賣出速度。這里的設計是在用戶上傳圖片進行提示，作者覺得就沒有ZAO中這個設計體驗更好。
3. 更強、更方便的互動方式
社交產(chǎn)品中，用戶之間的互動率是一個十分重要的指標，對內(nèi)容的點贊評論可以很大程度上加強用戶粘性，使用戶與用戶之間產(chǎn)生關系鏈，這樣用戶流失的概率就會小很多。一般的產(chǎn)品中常見的功能像點贊評論在綠洲里也有了不一樣的變化，并且體驗還真的不錯，如下：
當用戶對某一條消息產(chǎn)生了互動的傾向時，可以直接使用三個表情表示不同的情緒，分別是愛心、鼓掌和笑哭，如果想要評論的話只需要點擊WOW按鈕系統(tǒng)就可以自動生成一句評論，不需要用戶自己思考寫什么內(nèi)容，這樣用戶進行評論操作的成本就大大的降低了。如果對生成的評論不滿意的話還可以再次點擊生成不同的評論。
4. 不足的用戶認知負荷
當然作者同事也看到了體驗不是很好的設計細節(jié)，如下圖產(chǎn)品中使用了太多無文字按鈕，導致根本不知道這些都是什么功能，綠洲對自己的介紹是更清爽的朋友圈，如果說是為了讓界面更干凈簡約才使用了這樣設計的話我覺得有些本末倒置了，國內(nèi)用過ins的用戶畢竟還是少數(shù)，對于大部分用火狐來說綠洲還是一款陌生的產(chǎn)品，在陌生的產(chǎn)品中使用這種不能明確表達功能含義的無文字按鈕則讓用戶十分迷茫，大大增加了認知負荷。
昨天晚上作者在家附近的面館吃飯，正在等著自己的油潑面、羊肉串、拍黃瓜、小酥肉、酸梅湯的時候看到了一件事：某50歲左右的大叔點菜說想要一份涼皮。
服務員問：您是要麻醬涼皮的還是秘制涼皮？
大叔猶豫一下，問：秘制涼皮是什么的？
服務員答：就是有涼皮和面筋摻一塊，放上醋、鹽、香油、辣子，酸甜口的可辣可不辣。
大叔繼續(xù)猶豫了一下說：那給我來個麻醬涼皮吧。
故事到這開始有點意思了，這個用戶(大叔)對秘制涼皮是沒有概念的，雖然經(jīng)過服務員解釋之后明白了是什么，也知道了口味，但是對于「秘制涼皮」這個概念的熟悉程度還是比較低，所以最終沒有選擇它。這和我們在進行產(chǎn)品設計時對一些文案的設計很像。大家第一眼看過之后能明白是什么意思嗎？反正我是沒有明白。不明白就會產(chǎn)生認知負荷。也就會影響向下的轉(zhuǎn)化率。當用戶點擊幾次沒有找到自己想要的東西之后，他也就走了，去哪了呢？可能是「商城」「歷史文章」「限時促銷」這些他明白是什么意思的地方。
你只是綠洲，你還不是微信，這樣的設計有些為時過早了。
昨天我故意吃的比較慢，觀察了一下麻醬涼皮和秘制涼皮的購買人數(shù)，在大約40分鐘的時間里，大約有7人選擇了麻醬涼皮，2人選擇了秘制涼皮。服務員大約解釋了4次什么是秘制涼皮，每次大約需要20秒，加上顧客猶豫的時間，這40分鐘里服務員大約多花了3分鐘時間解釋、等待用戶做選擇。
如果把這種場景放到我們的產(chǎn)品設計中則意味著更低的效率、更少的使用時間、更低的轉(zhuǎn)化率。以及推出新功能之后更少的使用率?，F(xiàn)在很多產(chǎn)品中對功能的命名都基本一致、一些常規(guī)圖標的樣式也都基本一樣。目的也就是為了減輕用戶的認知負荷。
簡單介紹
多個頁面和 servlet 組成了一個基于 Java 的 web 應用程序。JSP 使用轉(zhuǎn)發(fā)和重定向兩種方式將控制權從一個 servlet 傳遞到另一個 servlet 或者 JSP。
轉(zhuǎn)發(fā)（Forward）方法： 將請求從一個 servlet 轉(zhuǎn)發(fā)到 web 應用程序中的另一個資源，這個資源可以是一個 servlet、JSP 頁面、或者 HTML 文件。
重定向（Redirect）方法： 方法將請求重定向到另一個 web 應用程序。使用轉(zhuǎn)發(fā)（ Forward ）方法無法完成此操作。如果一個重定向命中了同一個 web 應用程序的不同資源，那么它使用的 URL 將與原始請求的 URL 不同。如果你不想響應一個請求，你可以將請求重定向到一個不同的 URL，然后瀏覽器將會將你的新請求重定向到你提供的新的 URL。這篇文章詳細解釋了兩種方式的不同之處。
什么是轉(zhuǎn)發(fā)（Forward）
在基于 web 的系統(tǒng)或者應用程序中，通常需要在不同的資源或 JSP 之間轉(zhuǎn)移控制權。例如：你如希望從電子商務網(wǎng)站下單，則需要先進行注冊，然后才可以繼續(xù)。如果你還未在他們的系統(tǒng)中注冊，那么購物車界面可能會將控制權轉(zhuǎn)移到負責注冊過程的 JSP 表單。轉(zhuǎn)發(fā)（ Forward ）方法即是用于此目的。它用于將請求從一個 JSP 轉(zhuǎn)發(fā)到統(tǒng)一上下文中的另一個資源。
什么是重定向（Redirect）
此方法也用于轉(zhuǎn)發(fā) HTTP 請求，但與轉(zhuǎn)發(fā)（ Forward ）不同的是：它是一個兩步過程，其中重定向發(fā)生在客戶端到不同的應用程序。Redirect 方法將用戶重定向到新的 URL?？蛻舳说臑g覽器會自動對來自服務器中的重定向表頭中指定的 URL 發(fā)出新的請求。它需要與客戶機進行往返通訊，因此相對來說會比轉(zhuǎn)發(fā)（ Forward ）方法慢些。
轉(zhuǎn)發(fā)（Forward）與重定向（Redirect）區(qū)別
轉(zhuǎn)發(fā)（Forward）與重定向（Redirect）的描述
Forward() 方法用于將請求從一個 JSP 轉(zhuǎn)發(fā)到另一個 JSP，或從一個 JSP 轉(zhuǎn)發(fā)到另一個 servlet，或從一個 JSP 轉(zhuǎn)發(fā)到 web 應用程序的另一個資源?？刂剖窃谌萜鞯膬?nèi)部傳遞的，瀏覽器/客戶機不參與此過程。Forward( )方法在 RequestDispatcher 中聲明。
Sendredirect () 方法在 HttPServletResponse 中聲明，用于將客戶端請求重定向到不同服務器或上下文中可用的不同 URL。 通過重定向，您可以將瀏覽器重定向到完全不同的應用程序。
客戶端是否參與轉(zhuǎn)發(fā)（Forward）和重定向（Redirect）
這兩種方法之間的一個關鍵區(qū)別是 web 容器在 Forward() 情況中處理了所有的內(nèi)部進程，而且 URL 在客戶端的瀏覽器中不會改變，因此客戶端/瀏覽器不會參與其中，從而使它們完全不知道動作已經(jīng)發(fā)生。
而在 Sendredirect () 的情況中，該方法設置適合的頭部信息和正文內(nèi)容以將請求重定向到不同的 URL 中，瀏覽器付負責將新的請求發(fā)送到客戶端可見的 URL。
執(zhí)行控制
當在請求時執(zhí)行 Forward() 方法，當前的請求會被轉(zhuǎn)發(fā)到另一個 JSP 頁面，對當前 JSP 的處理也會被終止。請求可能會被轉(zhuǎn)發(fā)到另一個用 Java 編程語言編寫的 servlet，或者一個靜態(tài)的 HTML 頁面。
一個 SendRedirect() 請求只是簡單告知瀏覽器轉(zhuǎn)到另一個 URL，將執(zhí)行控制發(fā)送到 web 應用程序之外。它使用一個兩步的過程來指示瀏覽器的 URL 發(fā)出另一個將控制轉(zhuǎn)發(fā)到另一個客戶端的請求。
速度
Forward () 在服務器內(nèi)運行，執(zhí)行速度比 SendRedirect () 快。
重定向必須通過瀏覽器，然后等待瀏覽器發(fā)出新的 HTTP 請求。 一個重定向使得服務器發(fā)送 HTTP 響應狀態(tài)代碼 302 和一個包含新的 URL 的位置頭到瀏覽器，并且在瀏覽器收到狀態(tài)代碼 302 之后，它對位置頭中的 URL 發(fā)出一個新的請求。 這需要與客戶機進行往返通信，這使得它比 Forward () 相對慢一些。
轉(zhuǎn)發(fā)（Forward）和重定向（Redirect）比較圖表
轉(zhuǎn)發(fā)（Forward） 重定向（Redirect）
用于將請求從一個 JSP 轉(zhuǎn)發(fā)到另一個 JSP，或從一個 JSP 轉(zhuǎn)發(fā)到另一個 servlet，或從一個 JSP 轉(zhuǎn)發(fā)到 web 應用程序的另一個資源。 用于將客戶端請求重定向到不同服務器或上下文中可用的不同 URL。
Forward( )方法在 RequestDispatcher 中聲明。 Sendredirect () 方法在 HttPServletResponse 中聲明
不涉及客戶端/瀏覽器，web 容器在內(nèi)部處理該過程。 當客戶端將 URL 作為一個新的請求后，控制權將會轉(zhuǎn)移至客戶端或瀏覽器。
當一個組件執(zhí)行業(yè)務邏輯并與另一個組件共享結果時，它最有效。 當客戶端應從一個頁面重定向到另一頁面時，此方法效果最佳。
它在服務器內(nèi)運行，并且比重定向執(zhí)行得更快。 它比轉(zhuǎn)發(fā)慢，因為它需要與客戶端進行往返通信。
使用時，原來的 URL 請求不變。 原始的 URL 請求會改變。
兩種資源都必須屬于同一上下文。 將請求重定向到不屬于當前上下文的其它 URL。
轉(zhuǎn)發(fā)（Forward）和重定向（Redirect）總結
學習轉(zhuǎn)發(fā)方法和重定向方法之間的區(qū)別是 Java 開發(fā)人員最重要的部分之一。 雖然控制器可以在處理請求結束時執(zhí)行轉(zhuǎn)發(fā)（Forward）或重定向（Redirect）方法，但它們有自己的一組用途。
大多數(shù)情況下，您會使用 Forward () 方法，因為它比 SendRedirect () 稍微快一點，而后者實際上需要與客戶機進行往返通信，使其比 Forward() 更慢。 通過重定向，你可以將瀏覽器導向到另一個應用程序。 這是轉(zhuǎn)發(fā)無法做到的。
簡而言之，當一個組件必須執(zhí)行業(yè)務邏輯并與另一個組件共享結果時，轉(zhuǎn)發(fā)（Forward）工作效果最好，而當客戶端應該從一個頁面重定向到另一個頁面時，重定向（Redirect）工作效果最好。
以上內(nèi)容翻譯自：
Difference Between Forward and Redirect。
能力有限，還望斧正。
藍藍設計( sillybuy.com )是一家專注而深入的界面設計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務。
2019年7月20日，UXRen北京舉辦了《如何通過體驗設計賦能產(chǎn)品增長》的沙龍分享，本文基于嘉賓 何曉頔（搜狗高級用戶研究工程師）的現(xiàn)場分享總結而成。
何曉頔2015年開始從事用研工作，2018年加入搜狗，目前在搜狗搜索擔任用戶研究工程師；期間支持搜狗搜索相關產(chǎn)品的用戶研究工作，完成搜狗閱讀app、搜狗搜索app、搜狗圖片搜索改版研究，搜狗醫(yī)療搜索系列研究，搜狗翻譯app調(diào)研等項目；擅長全局思考問題，綜合考慮各方訴求，通過研究方法的熟練運用，需求的深度解讀，結果的產(chǎn)出，不斷提升用研的影響力及價值。
由于用研資源的緊張，傳統(tǒng)研究模式周期長，使得用研游離在項目邊緣，融入難，導致時效性跟不上整個項目的推進，出現(xiàn)信息不對等的情況，從而造成研究方向的偏差，而且研究結果也會和設計、產(chǎn)品的需求脫節(jié)，造成落地難的問題。
敏捷用研可以很好的解決這個問題，它可以很好地融入在項目的各個階段中，能夠在3-5天內(nèi)地完成調(diào)研需求，真正融入到整個項目的流程中，在每個階段都以結果導向的解決問題，形成每個階段的連接器。所以說他以用戶思維為核心，通過用研的驅(qū)動性，增加用戶在整個項目中的參與度和體驗感，不僅能夠?qū)崿F(xiàn)成本的減少，還能提高響應的效率，實現(xiàn)信息層面的對等，還原用戶的真情實感，性價比高的同時還提升了用研的價值。
敏捷用研可以在敏捷項目的各環(huán)節(jié)中發(fā)揮作用，而且在不同階段可以有針對性的解決問題。
2.1 改版前
需求分析
用戶點擊行為研究
書城結構布局研究
2.2 改版中
用戶需求挖掘
搜索行為探索
2.3 改版后：改版效果評估
2.4 項目合作模式
3.1 招募策略——健全流程
招募問卷設計
招募渠道
招募用戶特征及數(shù)量
獎勵機制
3.2 研究策略——模板化、透明化
模板化：搭建問題包，分門別類、系統(tǒng)整理，隨時調(diào)用、整合
過程透明：邊訪談邊總結，根據(jù)需求，隨時調(diào)整、直到數(shù)據(jù)樣本趨于穩(wěn)定
3.3 溝通策略——循序漸進
結合迭代研究模式，從小范圍調(diào)研起步，與客戶及時共享研究進度和成果，循序漸進：
3.4 參與策略
3.5 小結
敏捷調(diào)研不是為了快而快，而是快速解決產(chǎn)品需求和設計問題打造好的體驗！
問題1：內(nèi)部用戶招募。國企，公司logo優(yōu)化調(diào)研， 因為時間和成本的關系，邀約的是公司的內(nèi)部員工（年齡集中在40-50歲區(qū)間段），調(diào)研的結果內(nèi)部員工更偏好原logo的微小變化的版本，與設計方期望差別非常大，想知道是否是不應該找內(nèi)部員工測試。
回答：就上述問題，不建議找內(nèi)部員工測試。
內(nèi)部招募是一種短平快的用戶招聘渠道，但是，
問題2：概念測試。概念型產(chǎn)品可以用電話訪談的形式進行測試么
回答：概念型產(chǎn)品，由于屬于市場上未出現(xiàn)產(chǎn)品，很難在電話中通過語言描述的方式讓用戶理解和想象出來，因此，概念類測試不建議用問卷和電話訪談的方式，建議通過面對面訪談+高保真原型展示的方式進行測試，如果實在滿足不了高保真，哪怕線框的示意圖都比單薄的語言描述更強。
問題3：用研考核機制。用研的輸出建議，有些被采納，有些不被采納，采納的建議到產(chǎn)品成型很多已不是建議的“原型”了，如何衡量用研結果的直接作用。
回答：
每一次學習改版案例，不僅僅只是去看在視覺層面的變化，更多的應該是要學習到作者改版背后的思考。為什么要這么改，原因是什么，目的又是什么，怎么做，有哪些限制等等，有很多東西要去思考。所以，帶著問題并結合自己實際中所做的項目來看案例，應該會是一個很有收獲的過程。
Booking.com繽客 是一家荷蘭初創(chuàng)公司，并已經(jīng)發(fā)展成為全球最大的旅游電子商務公司之一。
在Booking上，旅客可以選擇世界上任何一處的住宿地點，包括公寓，度假酒店，民宿，五星級豪華度假村，樹屋甚至冰屋等等。每天，通過平臺預訂的房間數(shù)超過155萬。無論是商務旅行還是休閑旅行，人們都可以快速輕松地預訂到理想的住處。
自從Booking發(fā)布以來，許多競爭對手都采用類似的商業(yè)模式瘋狂跟進，搶占市場，并且在某些方面比Booking本身做的還好。
在調(diào)研的前期階段，我去搜集了一些競爭對手和類似的平臺，分析UI，用戶體驗，用戶地圖，信息架構和關鍵功能。但是我并不會花太多時間過于深入的去分析這些產(chǎn)品，因為我希望將重點放在Booking這個產(chǎn)品本身的訴求上。
在之前的調(diào)研過程中，我發(fā)現(xiàn)了許多不同的使用場景，經(jīng)過匯總歸集，我集中關注以下3個場景：
在進一步的研究中，我明確了4位具有不同需求和不同目標的典型用戶，這些數(shù)據(jù)對于改善不同用戶的體驗非常有用。
這個分析的目的是通過梳理最佳的用戶流程并提升產(chǎn)品體驗，來為不同需求的用戶提供最好的用戶體驗。
△ 數(shù)據(jù)來源：在線研究和用戶訪談（30個用戶樣本）
收集用戶評論，從中我收到了很多有價值的反饋，這些評論中沒有特別明確指出是可用性或功能性的問題。我將這些反饋分為4類（譯者注：對反饋的問題進行提煉整理）：
毫無疑問，最相關的是預訂被取消的問題。太多用戶會注意到不合理的費用或與房間的主人取得聯(lián)系時遇到困難。
基于30個用戶樣本，我試圖獲得進一步的用戶反饋，從中注意到以下的幾點事實：
我想引用一段話，來總結這里面遇到的問題，這段話也蠻有意思的，它說的是：
「與其他應用比較來看，套路顯得有點多，會讓你覺得一切看起來都蠻劃算，總是想多賣一些東西給你?！?
總結之前的分析，我提出了以下幾點觀點：
從用戶痛點出發(fā)，嘗試找到合適的解決方案，來提升產(chǎn)品體驗。
1. 主頁
總的來說，我對首頁進行了大手術。主頁的搜索功能已經(jīng)完全重新設計，減少過多的干擾信息。
導航：我設計了一個新的導航欄，剝離出「已保存」功能，這樣用戶就可以快速找到自己所收藏的商品。此外，我也優(yōu)化了「交易」的模塊，后面我會詳細的說說這塊的改動思路。
其它功能 :至于之前的版本，我保留了搜索和相關推薦的功能，重新設計界面以改善UI的可用性。
2. 社交功能
如今，社交網(wǎng)絡在用戶的生活中扮演重要的角色，那沒理由在booking中做的這么差。我搞了一個新功能，允許用戶關聯(lián)自己的好友并查看他們的選擇，包括他們的評價（喜歡/不喜歡）。我已將此功能放置到主頁的下方，因為我希望在將其推廣到其他模塊之前收集更多有關它的數(shù)據(jù)。
3. 搜索功能
把這個功能分解為多個步驟。在輸入第一個詞后，即使沒有指定日期或其他信息，也能顯示相匹配的酒店。此外，我也加入了語音搜索，使搜索更容易?；谥拔覍Σ煌脩艚巧亩x，搜索的結果將根據(jù)最后的信息進行推薦：
4. 列表頁面
列表頁針對易用性方面做了整體的優(yōu)化：
5. 詳情頁
我列出許多可以在詳情頁面中加入的修改。將總價格突出顯示，以免有些隱形消費用戶可能會被忽略。
增強了一個與評論相關的次要功能，允許用戶通過不同標簽篩選它們。
6. 交易功能
在優(yōu)化開始時，我確定了操作場景2—— 「用戶還不知道自己的目的地」作為優(yōu)化方向。為了提供更好的用戶體驗，我增加了一個新的功能，用戶可以在其中找到不同目的地的區(qū)間。利用篩選功能，用戶可以選擇最適合其需求的區(qū)間（區(qū)間 – 大陸 – 國家等…）
最后，我還設計了一個整個項目的動效原型，把之前所有重設計的頁面串聯(lián)起來。
由于時間限制，分析和結果是基于我的個人經(jīng)驗和少量數(shù)據(jù)，需要進行深入分析和其他測試，以便完善和驗證解決方案。
文章來源：優(yōu)設網(wǎng)
vue-cli3發(fā)布自2018年8月，距離現(xiàn)在還不是特別久，最好搭建項目剛好用到，所以寫下這篇文章，記錄一下踩坑經(jīng)歷。
vue的作者說過，vue-cli的本質(zhì)是模
版的拉取，太多的配置導致了模版的難以維護，所以重構后的版本提供了插件的功能，一個插件對應一個功能，這樣避免了多個模版，也使得cli維護性得到提高，這也是本篇文章的核心介紹內(nèi)容。
我對cli3的理解是，一方面擴展了cli2的核心能力 ，一方面封裝了webpack邏輯和配置。在過去要去做一個cli，通常需要閱讀cli2的代碼，cli2的核心模塊分別是 generator,prompts,template，git-repo,并用同樣的方法去做一個cli，這樣其實成本不小，cli3的插件就是提供了這樣一種能力，你用他的規(guī)則，去做一個npm包，并發(fā)到倉庫，就可以獲得這種能力。
首先，先介紹一下vue-cli3，他的發(fā)布帶了哪些新功能呢？我總結一下，大概有以下5點：
1.功能豐富。這點相信大家都很好理解，他實在太好用了，模版里包含了大多數(shù)業(yè)界比較新的功能，可以一鍵集成typescripts等類型定義工具, eslint/tslint等語法檢驗工具，風格規(guī)范，prettier，husky等格式化工具，還有postcss、pwa、vue-cli-server等等。
2.提高封裝性和擴展性。這點指的是vue-cli-server，在過去webpack的邏輯和配置在項目里獨立維護，各個項目之間就像孤島，vue-cli-server就像一個紐帶，連接起了各個項目，為項目升級webpack提供便利性，并且通過一份配置，提供個性化配置。
這里順帶扯一下vue.config.js, 這個東西就是用來個性化配置webpack的，他提供了很多的配置項，具體可以看官方文檔：
https://cli.vuejs.org/zh/config/
我們挑幾個常用的來講：
configureWebpack，這個幾乎是用的比較多的，簡單的方法，可以通過配置的方式配置，如下所示：
-
module.exports = {
-
configureWebpack: {
-
plugins: [
-
new MyAwesomeWebpackPlugin()
-
]
-
}
-
}復制代碼
這份配置，最終會被合并到原來的配置里，不會覆蓋。
復雜的方法，可以往這個字段傳一個函數(shù)，如下所示：
-
module.exports = {
-
configureWebpack: config => {
-
if (process.env.NODE_ENV === 'production') {
-
// 為生產(chǎn)環(huán)境修改配置...
-
} else {
-
// 為開發(fā)環(huán)境修改配置...
-
}
-
}
-
}復制代碼
這樣就可以在一個函數(shù)里做一些簡單的邏輯，config是webpack config，你可以直接修改config對象，也可以返回一個對象，這個對象最終也會被合并會webpack對象。
第三種方式，是通過webpack-chain來鏈式調(diào)用，代碼如下所示：
-
module.exports = {
-
chainWebpack: config => {
-
config.module
-
.rule('vue')
-
.use('vue-loader')
-
.loader('vue-loader')
-
.tap(options => {
-
// 修改它的選項...
-
return options
-
})
-
}
-
}復制代碼
3.提供圖形化管理界面，最所周知，gui易懂，cli，vue在降低學習門檻這方面，已經(jīng)是非常好了。
通過vue ui指令，可以查看編譯各個模塊的情況，模塊依賴情況，插件的情況，非常便于管理。
4.便捷性。vue-cli-server不僅支持項目的編譯，也支持單文件的編譯，具體的方法可以看官網(wǎng)介紹。
5.提供了cli的核心能力，也就是問詢，模版渲染，文件生成這幾大核心功能。具體的示意圖可以看如下：
以上是cli2的核心模塊，需要引用hbs,inquirer.js,metalsmit等基本模塊，cli3的插件機制基本幫我們封裝好了，我們只需要根據(jù)插件的規(guī)范，就可以獲取這種能力。
由于有的讀者可能對cli2的流程比較陌生，所以我想簡單描述一下cli2的工作流程，如下圖所示：
首先，cli2提供init指令，執(zhí)行這個指令，會去遠程拿模版文件，并拉到本地用戶目錄的.vue-template的文件夾，然后通過meta里問題，去問你，然后生成最終模版到你執(zhí)行命令的目錄。
說完vue-cli2，我們來看看vue-cli3的插件是怎么樣的？
首先根據(jù)插件的位置，我們分成了cli插件，和service插件。cli的插件有完整的開發(fā)目錄，所能做的事情也比較多一點，service插件是一份js文件，導出一個函數(shù)。
cli插件的目錄如下所示：
具體的用發(fā)可以在官網(wǎng)了解到：
https://cli.vuejs.org/zh/dev-guide/plugin-dev.html#cli-%E6%8F%92%E4%BB%B6
那么他們是怎么工作的呢？
cli的代碼主要在@vue/cli 下面，他的大概的流程如下圖所示：
@vue/cli/bin/vue.js:
-
program
-
.command('add <plugin> [pluginOptions]')
-
.description('install a plugin and invoke its generator in an already created project')
-
.option('--registry <url>', 'Use specified npm registry when installing dependencies (only for npm)')
-
.allowUnknownOption()
-
.action((plugin) => {
-
require('../lib/add')(plugin, minimist(process.argv.slice(3)))
-
})
-
-
program
-
.command('invoke <plugin> [pluginOptions]')
-
.description('invoke the generator of a plugin in an already created project')
-
.option('--registry <url>', 'Use specified npm registry when installing dependencies (only for npm)')
-
.allowUnknownOption()
-
.action((plugin) => {
-
require('../lib/invoke')(plugin, minimist(process.argv.slice(3)))
-
})復制代碼
首先，執(zhí)行vue指令，會執(zhí)行@vue/cli/bin/vue.js，這里定義了vue add , vue invoke，vue build，vue serve，等指令，可以看出，add指令其實是包含invoke指令的，add指令主要是安裝一個包，并且觸發(fā)generator.js，invoke主要是觸發(fā)generator.js。
然后再來看@vue/cli/lib/add.js，
-
const packageManager = loadOptions().packageManager || (hasProjectYarn(context) ? 'yarn' : 'npm')
-
await installPackage(context, packageManager, options.registry, packageName)復制代碼
-
const generatorPath = resolveModule(`${packageName}/generator`, context)
-
if (generatorPath) {
-
invoke(pluginName, options, context)
-
} else {
-
log(`Plugin ${packageName} does not have a generator to invoke`)
-
}復制代碼
add.js主要安裝包，然后執(zhí)行invoke模塊，我們再看看invoke模塊做了什么。
@vue/cli/lib/invoke.js
-
const generator = new Generator(context, {
-
pkg,
-
plugins: [plugin],
-
files: await readFiles(context),
-
completeCbs: createCompleteCbs,
-
invoking: true
-
})復制代碼
invoke里主要實例化generator類，然后把你的插件當成參數(shù)傳給類，generator類算是vue-cli的核心類了。
@vue/cli/lib/generator.js
-
plugins.forEach(({ id, apply, options }) => {
-
const api = new GeneratorAPI(id, this, options, rootOptions)
-
apply(api, options, rootOptions, invoking)
-
})復制代碼
這個類主要負責執(zhí)行你的插件，然后把generatorapi作為參數(shù)傳入插件的generator.js導出的函數(shù)。
具體的vue-cli插件的開發(fā)是怎么樣的呢，我寫了一個demo，用在模擬多項目的ci模版管理，通常每個項目都有一份.gitlab-ci.yml模版，所以我們一般可以抽出一個公共的ci模版來管理，這里我用cli插件來管理，真正的項目可能不具備可行性，這里我只是用來寫一個例子。
目錄結構大概如上所示，執(zhí)行vue add foo后，就會出現(xiàn)propmts對話框，然后選擇答案后，就會根據(jù)配置生成模版到你的根目錄下。
_gitlab-ci.yml ,根據(jù)問題選擇是否用私有npm倉庫：
-
script:
-
<%_ if (options.config === 'npm') { _%>
-
- nrm add companynpm http://xxx.y.cn:XXXXX/
-
- nrm use companynpm
-
<%_ } _%>復制代碼
prompts.js,主要一些問題的設計：
-
module.exports = [
-
{
-
name: 'config',
-
type: 'list',
-
message: `是否需要切換內(nèi)部源:`,
-
choices: [
-
{
-
name: '需要',
-
value: 'npm',
-
short: ''
-
},
-
{
-
name: '不需要',
-
value: 'npm',
-
short: ''
-
}
-
]
-
}
-
]復制代碼
generator.js 這個模塊很簡單，直接渲染模版
-
module.exports = (api, options, rootOptions) => {
-
// 復制并用 ejs 渲染 `./template` 內(nèi)所有的文件
-
api.render('./template')
-
}復制代碼
service插件主要放在項目本地，是一份js代碼，然后導出一個函數(shù)，通過package.json配置指向這個js文件的路徑，
service主要依賴的代碼在@vue/cli-service里，首先先執(zhí)行@vue/cli-service/bin/vue-cli-service.js文件，
-
const Service = require('../lib/Service')
-
const service = new Service(process.env.VUE_CLI_CONTEXT || process.cwd())
-
-
.....
-
-
service.run(command, args, rawArgv).catch(err => {
-
error(err)
-
process.exit(1)
-
})復制代碼
該文件實例化Service類，這個類是service插件的核心類，然后再執(zhí)行run方法。
再來看看@vue/cli-service/lib/Service.js的代碼：
首先構造函數(shù)執(zhí)行resolvePlugin，把官方提供的插件和項目里的插件都加載進來，
-
constructor (context, { plugins, pkg, inlineOptions, useBuiltIn } = {}) {
-
this.plugins = this.resolvePlugins(plugins, useBuiltIn)
-
}復制代碼
resolvePlugin這個函數(shù)主要在這里引入本地的插件：
-
resolvePlugins (inlinePlugins, useBuiltIn) {
-
// Local plugins
-
if (this.pkg.vuePlugins && this.pkg.vuePlugins.service) {
-
const files = this.pkg.vuePlugins.service
-
if (!Array.isArray(files)) {
-
throw new Error(`Invalid type for option 'vuePlugins.service', expected 'array' but got ${typeof files}.`)
-
}
-
plugins = plugins.concat(files.map(file => ({
-
id: `local:${file}`,
-
apply: loadModule(file, this.pkgContext)
-
})))
-
}
-
-
return plugins
-
}復制代碼
run方法又會執(zhí)行init方法，在該方法內(nèi)部執(zhí)行插件：
-
init (mode = process.env.VUE_CLI_MODE) {
-
// apply plugins.
-
this.plugins.forEach(({ id, apply }) => {
-
apply(new PluginAPI(id, this), this.projectOptions)
-
}
-
}復制代碼
那么service插件要如何來實踐，我們來看如下的例子：
首先在package.json配置一下，指向本地的插件my-service.js
-
"vuePlugins": {
-
"service": [
-
"my-service.js"
-
]
-
}復制代碼
my-service.js的代碼如下所示：
-
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
-
const webpack = require('webpack');
-
-
module.exports = (api, projectOptions) => {
-
api.registerCommand(
-
'analyze',
-
{
-
description: 'start analyze server',
-
},
-
(args) => {
-
// 注冊 `vue-cli-service analyze`
-
let options = projectOptions.pluginOptions.demoOptions
-
console.log(options);
-
// resolve webpack config
-
const webpackConfig = api.resolveWebpackConfig();
-
webpackConfig.plugins.push(new BundleAnalyzerPlugin());
-
-
-
webpack(webpackConfig,(err,stats)=>{
-
if(!err) console.log('打包成功')
-
})
-
},
-
);
-
};復制代碼
該插件主要擴展vue-cli-service的指令，加了analyze指令，這個指令主要會向webpack的配置增加一個BundleAnalyzerPlugin的插件，用來分析包的大小，當然，這里也是沒有太大的現(xiàn)實可行性的，vue-cli 提供了vue ui的Gui界面讓你看到打包后各個模塊的大小，或者cli的命令，vue-cli-service build --report，也能生一個報告，效果也是一樣。
至此，vue-cli和service插件的使用和實現(xiàn)都介紹完了，如果有哪里寫的不到位，希望各位大神能提出指正
藍藍設計的小編 http://sillybuy.com