整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
同時支持SPP和BLE 。但是只能任選其中一個協議使用。
備注：這款芯片最大的特點，就是成本低，使用簡單，生產簡單。無其他。同時支持低功耗詳見3.7章節
細節 | 參數說明 |
UART接口 | 標準串口，TTL電平,波特率可設，連接PC需要電平轉換[如：CH340G--USB轉TTL] |
輸入電壓 | 建議給3.3V的電壓【2.2V--3.4V】 |
額定電流 | 芯片上電啟動是20mA，馬上進入低功耗廣播20uA 和喚醒4mA交替。 連接成功就一直都是4mA |
低功耗電流 | 芯片算的是平均電流，因為內部是不斷的低功耗、喚醒交替進行 |
工作溫度 | [-40度] -- [80度] |
濕度 | 5% ~ 95% |
主芯片型號 | KT6368A[SOP8][管裝出貨]-----KT6328A[SOP8][管裝出貨] |
1、我們目前分KT6368A 和 KT6328A兩個版本 （1）、KT6368A版本，是不帶低功耗，雙模的版本，開機15mA ，后續一直穩定在6mA左右 （2）、KT6328A版本，低功耗版本，只有BLE，詳細參數，如：3.7章節 （3）、這兩個芯片版本的硬件一模一樣，KT6328A存在的目的就是滿足需要低功耗的客戶 2、KT6368A版本的特點如下： （1）、雙模SPP + BLE，手冊里面的全部功能具備 。就是不具備低功耗 （2）、但是這個版本，成本更低一些。 3、KT6268A版本的特點如下： （1）、功耗更低，詳見3.7章節描述 （2）、成本略高一點點 。 ==》不同的版本，通過藍牙名是可以識別出來的 |
序號 | 操作說明 |
第一步 | 搭建好芯片的外圍電路，供電3.3V即可。藍牙天線可以直接焊一根線即可 |
第二步 | 查詢芯片的2腳是否開機有1秒鐘的高電平輸出，接個指示燈出來 |
第三步 | 連接好電腦的串口助手，看看芯片的TX腳是否有數據返回，115200的波特率 |
第四步 | 做自己實際的板子，搭配MCU進行調試 |
序號 | Layout的注意事項 |
UART注意點 |
|
電源注意點 | 芯片的供電電壓，最高位為3.4V 。一定不能超過這個電壓，最好給3.3v |
2腳注意點 | 第2腳，為連接狀態腳。連接成功輸出高電平。未連接則是高組態。調試時建議接一個指示燈出來。或者連接到外部MCU 。注意下拉一個10K電阻到地 |
細節描述 |
升級的測試點排列，建議是 1/7/8/3 這4個腳順序排列。引出測試點，很重要 |
(1)、注意芯片的藍牙天線引腳，出去，要預留安全間距
(2)、天線四周，一定要注意，包地處理
(3)、天線周邊一定要隔空，不要鋪綠油，背面和正面不要有金屬
(1)、由于藍牙對頻偏要求比較高，所以晶振的品質對藍牙的性能至關重要，選型過程中
必須保證晶振的一致性和穩定性。晶振的頻率偏差必須≤±10ppm，負載CL 推薦12pF。
(2)、體積無要求的，推薦我DEMO上面的晶振，成本低，性能好
(3)、體積要求小的，推薦24M-3225的，成本稍高，性能好
建議直接用我們配套的晶體，相信比外面隨意采購的要優惠和質量保障
AT串口指令作為一種在控制領域常用的通信，我們進行了優化和定制，這樣大大簡化了用戶使用的難度，請嚴格按照我們給出的指令格式進行操作
支持異步串口通訊模式,通過串口接受上位機發送的命令 注意：所有的指令的設計，都是有規律的，不是隨意劃分的，可以對照下面找一下規律 | |
控制指令格式：AT+<CMD>[<param>]\r\n ---- 所有的都是字符，不是十六進制數 數據反饋格式：<IND>[<param>]\r\n | |
數據反饋格式：<IND>[<param>]\r\n | |
數據特性 | 詳細說明 |
AT+ | 控制指令是控制主機給BT201的控制命令，以“AT+ ”開始 |
<CMD> | 后面緊跟<CMD>控制 ，通常是2個字符 指令 |
[<param>] | 如果CMD后面有參數，則緊跟著[<param>] |
\r\n | 最后以”\r\n”結束，字符型為換行，windows就是回車鍵。十六進制為0x0D，0x0A |
<IND> | 1、數據反饋是藍牙把各種狀態和數據信息反饋給主機，以<IND>作為開頭 ，<IND>是反饋指 數，則緊跟<IND>之后繼續傳輸<param>參數。 |
2、后面緊跟著的是芯片回傳的參數 | |
這里<CMD>重點說明： 由于芯片內部是跑的系統，主體的程序劃分如下： | ||
功能劃分 | 命令 | 備注 |
公共指令特性 | AT+C? | 公共指令是以AT+C開頭，后面的“？”就是具體細化的功能命令 |
音樂指令特性 | AT+A? | 音樂指令是以AT+A開頭，后面的“？”就是具體細化的功能命令 |
藍牙指令特性 | AT+B? | 藍牙指令是以AT+B開頭，后面的“？”就是具體細化的功能命令 |
這里<CMD>重點說明： 由于芯片內部是跑的系統，主體的程序劃分如下： | ||
舉例 | 命令 | 備注 |
控制指令1 | AT+CZ\r\n | 代表系統復位 |
查詢返回的結果1 | QA+01 | 詳見4.4.1 返回的查詢信息永遠是Qn+xx 其中n和前面是相對應的 |
查詢返回的結果2 | QG+01 | 詳見4.2.12 |
公共部分--控制指令 -- 說明 | ||
CMD | 對應的功能 | 詳細說明 |
AT+CT | 設置波特率 | 后面有參數，詳見3.3 舉例：AT+CT01/r/n |
AT+UT | 設置藍牙BLE的廣播間隔 | 后面有參數，詳見3.11 舉例：AT+UT01/r/n |
AT+CZ | 芯片復位 | 芯片軟件復位，詳見3.3 舉例：AT+CZ/r/n |
AT+CW | 芯片恢復出廠設置 | 恢復出廠設置，清除所有之前記憶的參數 ，詳見3.3 舉例：AT+CW/r/n |
AT+CL | 芯片低功耗設置 | 詳見3.7章節 |
AT+CR | 芯片上電回傳信息關閉 | 詳見3.10章節 .注意默認是開啟的 |
AT+BM | 設置BLE藍牙名稱 | 詳見3.4章節 |
AT+BN | 設置BLE的MAC地址 | 詳見3.4章節 |
AT+BD | 設置SPP藍牙名稱 | 詳見3.4章節 |
AT+BS | 設置BLE連接密碼 | 詳見3.4章節 ，此功能沒有實現，主要在于手機的兼容性不行 |
AT+QT | 查詢系統的波特率 | 詳見3.3章節.返回的數據為 |
AT+QL | 查詢系統的低功耗狀態 | 詳見3.7章節.返回的數據為QL+00 |
AT+TM | 查詢BLE藍牙名稱 | 詳見3.5章節 |
AT+TN | 查詢BLE藍牙地址 | 詳見3.5章節 |
AT+TD | 查詢SPP藍牙名稱 | 詳見3.5章節 |
AT+TS | 查詢BLE藍牙連接密碼 | 保留 |
測試推薦的指令
AT+BM1234\r\n -- 設置BLE的名稱 AT+BN112233445566\r\n --ble的地址 AT+BD223344\r\n -- 設置SPP的名稱 AT+CT01\r\n AT+CZ\r\n AT+CW\r\n AT+QT\r\n AT+TM\r\n AT+TN\r\n AT+TD\r\n |
AT+CT01\r\n == 9600 | AT+CT06\r\n == 256000 | AT+CT11\r\n == 31250 |
AT+CT02\r\n == 19200 | AT+CT07\r\n == 512000 | AT+CT12\r\n == 2400 |
AT+CT03\r\n == 38400 | AT+CT08\r\n == 230400 | AT+CT13\r\n == 4800 |
AT+CT04\r\n == 57600 | AT+CT09\r\n == 460800 | |
AT+CT05\r\n == 115200 | AT+CT10\r\n == 1000000 | |
1、一旦設置了波特率之后，芯片會記憶。下一次開機，波特率就變成了您所設置的.當然可以查詢[AT+QT] | ||
2、設置完波特率之后，請等待1秒鐘，再發送復位[AT+CZ]，或者斷電一下即可 | ||
3、如果要恢復默認的波特率，請發送恢復出廠設置的命令，此時芯片會自動擦除所有的配置 | ||
4、由于我們芯片的主頻很高，所以盡量把串口的波特率調高，越高越好 | ||
AT+BMBLE-1234\r\n | 設置藍牙名稱為“BLE-1234” |
AT+BN112233445566\r\n | 設置BLE的地址。手機端顯示的地址是：66 55 44 33 22 11 |
AT+BDSPP-1234\r\n | 設置藍牙名稱為“SPP-1234” |
1、設置藍牙名稱之后，需要讓芯片復位，發指令或者斷電上電都可以，這樣會顯示新的藍牙名稱。我們默認的藍牙名為“KT6368A-BLE”。設置的藍牙名最長為“30”個字節，請不要超過這個范圍 |
2、如果AT指令修改藍牙名稱之后，注意，你的手機端可能沒有同步更新，還是顯示之前的名稱
(3)、只要設置了藍牙名，藍牙名一定是更新過來了的，不用懷疑。芯片上電也會返回藍牙名給您查看 |
AT+TM\r\n | 返回TM+1234\r\n 代表藍牙名為1234 |
AT+TN\r\n | 返回TN+12345678AABB\r\n BLE的藍牙地址：0xBB、0xAA、0x78、0x56、0x34、0x12 |
AT+TD\r\n | 返回TD+SPP1234\r\n 代表藍牙名為SPP1234 |
2、SPP的地址，是在BLE地址的最高字節加1處理的 。所以只用設置BLE的地址即可。SPP的地址也就沒做查詢指令，可以自己計算一下 |
測試環境：KT6368A測試板 串口軟件：串口調試助手_aithinker_serial_tool_v1.2.3 | |
==》這個數據的返回，無任何意義。主要是方便客戶，上電測試串口是否連接正常，以及查看芯片運行狀態 ==》芯片上電是一定會返回的，如果沒有返回，說明硬件連接有誤 | |
TM+KT6368A-BLE-1.7 | 代表的是當前芯片的BLE的名稱，以及對應手冊的版本為1.7 |
TN+220CB1C8A22C | 代表的是當前芯片的BLE的地址 |
TD+KT6368A-SPP-1.7 | 代表的是當前芯片的SPP的名稱，以及對應手冊的版本為1.7 |
TS+220CB1C8A22D | 代表的是當前芯片的SPP的地址 此地址是根據BLE的地址計算得來的 |
T4+01 | 代表的是當前BLE功能是打開的，詳見3.8章節 |
T5+01 | 代表的是當前SPP功能是打開的，詳見3.8章節 |
QL+00 | 代表的是當前是正常工作模式，詳見3.7章節 |
這里面的很多返回的信息，用戶可以不必關注，因為這個存在的目的是方便客戶初次調試的時候看
AT+CL00\r\n | 不進入低功耗模式。下次上電有效 。設置之后注意要重新上電 |
AT+CL01\r\n | 進入低功耗模式 。下次上電有效。設置之后注意要重新上電 --- 芯片默認進入此狀態，不用設置 |
|
4、當然芯片，出廠上電默認是，正常工作模式。 |
|
而這5秒之類，是可以正常識別AT指令的
|
序號 | 電流 | 說明 | |
AT+CL01 狀態，進入低功耗工作模式 | 開機瞬間 | 11mA | 1、芯片開機需要初始化外設。瞬間電流比較大 2、這個時間維持300ms，就進入低功耗狀態了 |
工作狀態-未連接 | 20uA 4mA 交替 | 3、芯片正常工作狀態，正常對外廣播，處于一個睡眠、喚醒廣播、睡眠這樣的周期性狀態 。目的為了節省功耗 4、周期500ms。100ms廣播一次，400ms睡眠 5、廣播一次電流就是4mA。進入睡眠，就變成20uA | |
工作狀態-以連接 | 4.3mA | 6、當連接成功之后，芯片就不再進入睡眠。而是一次處于工作狀態了 | |
AT+CL00 進入正常工作模式 | 開機瞬間 | 25mA | 1、芯片開機需要初始化外設。瞬間電流比較大 2、這個時間維持300ms，就進入5mA工作狀態 |
不管連接還是未連接。 | 5mA | 3、芯片一直處于工作狀態。電流很小的波動，忽略不計 |
AT+VER2.0-20211111 TM+KT6328A-BLE-2.0 --- 手機端會搜索到這個名字 TN+3031E54D77D9 T4+01 T5+00 QL+01 -- 進入低功耗模式 |
AT+B401\r\n | 開啟BLE的功能。當然AT+B400\r\n則是關閉了 |
AT+B500\r\n | 關閉SPP的功能。當然AT+B501\r\n則是開啟了 |
AT+T4\r\n | 查詢BLE功能是否開啟。芯片會返回T4+01或者T4+00 |
AT+T5\r\n | 查詢SPP功能是否開啟。芯片會返回T5+01或者T5+00 |
|
只用設置一次，芯片自動保存參數，下一次不用設置了。關閉SPP功能之后，手機就搜不到SPP的名稱了 |
ER+1\r\n | 接收的數據幀不對 |
ER+2\r\n | 接收的命令不存在，也就是你發的AT+KK這樣的字符串查找不到 |
ER+3\r\n | 接收的AT指令，沒有收到回車換行，也就是\r\n |
ER+4\r\n | 發送的指令給的參數超范圍了，或者指令的格式不對 。請檢查您的AT指令 |
ER+7\r\n | MCU發送數據給手機，但是手機端沒有打開notify 。在ble連接成功狀態下 |
ER+8\r\n | 保留--無意義 |
芯片內部對一些錯誤的狀態，會進行實時的反饋。具體的請對照上面的表格
重點描述一下notify [監聽]，手機端的測試APP連接上藍牙芯片之后，必須打開notify。藍牙芯片才能發送數據給手機。手機發數據給藍牙芯片，用write這個特征就足夠了。
AT+CR00\r\n | 關閉上電的回傳信息 。設置之后注意要重新上電 |
AT+CR01\r\n | 開啟芯片上電的回傳信息 。下次上電有效。設置之后注意要重新上電 |
|
目前此功能，僅限于KT6328A的版本，也就是單模BLE的低功耗版本
對應的指令 | 代表的含義 | 參考的功耗 |
AT+UT00\r\n | 0--對應--250ms 廣播間隔 | 平均功耗是300uA |
AT+UT01\r\n | 1--對應--500ms 廣播間隔 | 平均功耗是180uA |
AT+UT02\r\n | 2--對應--750ms 廣播間隔 | 平均功耗是140uA |
AT+UT03\r\n | 3--對應--1000ms 廣播間隔 | 平均功耗是100uA |
AT+UT04\r\n | 4--對應--1500ms 廣播間隔 | 平均功耗是70uA |
AT+UT05\r\n | 5--對應--2000ms 廣播間隔 | 平均功耗是62uA |
AT+UT06\r\n | 6--對應--3000ms 廣播間隔 | 平均功耗是40uA |
AT+UT07\r\n | 7--對應--4000ms 廣播間隔 | 平均功耗是30uA |
1、一旦設置了廣播間隔參數之后，芯片會記憶。下一次開機，廣播間隔就變成了您所設置的.不支持查詢 |
2、但是芯片每次上電會主動的返回當前的連接間隔參數，詳見上面的截圖 |
3、如果要恢復默認的廣播間隔，請發送恢復出廠設置的命令，此時芯片會自動擦除所有的配置 |
4、具體的間隔時間，還是要根據自己的產品，來定義。因為廣播間隔越長，手機搜索到的時間就越長 |
目前支持BLE純數傳，芯片可以實現透傳。目前BLE和SPP均只能作為從。也就是“SERVER”端。
請注意，一旦藍牙被連接之后，芯片自動進入透傳模式。不再識別AT指令 。一定要在app里面去搜索
1、單次吞吐的數據最大為1024個字節，支持16位或者128位的UUID --- 128位的需要特別定制 |
2、如果使用BLE作為數傳，請連接模塊的“KT6368A-BLE”這個藍牙名 |
3、當然可以自己修改BLE的藍牙名以及MAC地址了，通過AT指令 |
1、主UUID是“FFF0” |
2、特征1的UUID是“FFF1”，特征是“WRITE_WITHOUT_RESPONSE ”“NOTIFY” |
3、特征2的UUID是“FFF2”，特征是“READ ”“NOTIFY” |
4、特征3的UUID是“FFF3”，特征是“WRITE_WITHOUT_RESPONSE” |
BLE透傳效果演示：https://v.qq.com/x/page/q07660m1bta.html |
1、安卓手機的ios手機[蘋果]，推薦使用“BLE調試寶”軟件 |
2、蘋果的可以直接在“APP Store”里面搜索下載 |
3、安卓的，我們會在資料包里面提供安裝的程序 |
4、請注意，安卓的手機也是可以測試BLE的，測試BLE不是一定只能用蘋果的手機 |
5、安卓的BLE不是不能用，而是不好用，安卓的版本必須是在4.3版本以上的才支持BLE |
6、正因為安卓的BLE不好用的原因，所以才會有雙模，安卓用SPP。蘋果用BLE |
7、因為蘋果如果要用SPP，這需要買MFI認證芯片，超級貴，目前也沒人用了 |
8、如果默認沒有修改過藍牙名稱的，連接“KT6368A-BLE”這個藍牙名 |
9、BLE測試說明演示視頻：https://v.qq.com/x/page/o0766ubm78n.html |
第一步：
| 第二步
| 第三步：
| 第四步：
|
1、注意測試的時候，最好打開手機的定位權限，因為很多app需要這個權限 |
2、無論是用戶自己開發app還是微信小程序，操作的步驟和上面截圖也是一樣的 |
3、推薦用戶只用第一個特征，也就是FFF1 .他的特征是寫和監聽，足夠使用了 |
4、基礎的問題，請自行百度解決。其實這些描述，網上也是很容易找的，不復雜 |
上位機通過uart單次發送1832 個字節的數據 | 這個是接收完成的截圖 總共的耗時：220ms的樣子 |
以上測試的數據，是建立在我們芯片設置的連接間隔基礎上的測試
其實縮短連接間隔，也是可以加快數據的通信。但是同時也增加的功耗
注意，這里手機收到的數據，還是基本遵循20個字節分包。因為我們芯片內部默認設置的最大包的長度是20個字節
正常的流程，是APP那邊連接完藍牙芯片之后，可以主動發起請求MTU【最大通信包長度】--網上可以自己搜搜
設置了MTU之后，單次的數據包，就不再是20個字節了。從而加快的數據交互的速度
這里我們在廣播包里面，添加了芯片藍牙的MAC地址 對比右邊的截圖，即可知道規律 這里我們稱之為：advertisData 做這個的目的，有如下原因
|
Spp走的還是經典藍牙的2.1的協議，不推薦使用了，新產品建議直接使用BLE 。要在系統里面先連接KT6368A-SPP
1、單次吞吐的數據最大為1024個字節。需要連接“KT6368A-SPP-04” |
2、如果使用SPP作為數傳，請不要主動連接模塊的“KT6368A-BLE”這個藍牙名，或者自己設置的BLE藍牙名 |
3、注意SPP是屬于經典藍牙里面的一個子鏈路而已。 |
4、SPP數傳和BLE是互斥的，如果你只用SPP的數傳，那么請關閉掉BLE。 |
1、安卓手機的測試使用“藍牙串口”這個app，可以在“應用寶”里面下載 |
2、如果默認沒有修改過藍牙名稱的，連接“KT6368A-SPP”這個藍牙 |
3、SPP測試說明演示視頻：https://v.qq.com/x/page/e0766bz15fw.html |
SPP的大數據量的透傳演示視頻：
https://v.qq.com/x/page/c0843j975hl.html
測試的方法，可以看一下我們資料包里面的視頻演示。
1、目前我們的串口指令，支持AT指令，同時支持藍牙數據透傳
問題1 | 什么是藍牙透傳，有什么特點呢？ |
答疑 |
3、我們的方案中，藍牙透傳，是不需要任何的指令或者設置的 |
問題2 | 芯片是如何區分AT指令和透傳的數據呢？ | ||||||||||||
答疑 |
至于這些透傳的數據，如何去處理，就留給聰明的您去自由發揮啦
藍牙芯片收到之后，也是不會處理的，只會串口輸出給MCU |
問題0 | KT6368A是什么？有什么功能？特點是什么？適用于什么場景？配什么晶振呢？ KT6368A批量有優惠嗎？ 藍牙天線預留的元器件怎么辦，焊還是不焊？ |
回答 |
==》支持常用的AT指令，如：設置名稱、設置地址、設置波特率等等。詳見手冊
晶振的選擇，直接影響的是藍牙的頻偏，也就是藍牙距離，所以別隨便用，到時候搜不到藍牙名，就又跑來問為什么了，我們有提供晶振的樣品。可以順便拿幾個回去測試 晶振的電容不用焊，建議預留，我們開機芯片會自動校準晶振的負載電容，軟件處理的 8、芯片批量基本沒什么優惠了，價格超級敏感的，請選擇其它 9、藍牙天線腳，預留的元器件，做樣品直接不焊，接一個C1的電容即可。批量建議預留，預防做認證，或者天線要求極高的場合 。只接C1電容藍牙距離也是妥妥的超過10米以上 |
問題1 | KT6368A有測試板嗎？ 拿到芯片如何開始測試呢？ 有什么硬件上的注意事項？ |
回答 | 芯片是SOP8封裝的，總共的引腳就很少很少，使用也很簡單。暫時沒有測試模塊
|
問題2 | KT60368A支持微信小程序嗎 ？ 默認的uart波特率是多少？ |
回答 | 1、微信小程序，只是用到了BLE而已。也就是說支持BLE就可以支持微信小程序 2、芯片是BLE5.0的協議，微信小程序需要客戶自己開發。我們只是透傳，無其他作用 3、芯片給的uart緩存是1K字節 。默認的波特率是115200 |
問題3 | KT6368A這顆芯片供電電壓多少V？電流多少？ 透傳的速率是多少BLE和SPP |
回答 |
|
問題4 | 如何區分AT指令和串口透傳數據？ 如何知道藍牙是否連接？ |
回答 |
3、這個要看芯片的第2腳。未連接輸出低電平。連接成功輸出高電平 4、當然，你可以接一個指示燈來看。或者也可以連接到mcu的gpio上面 |
問題5 | 如何確定芯片是否工作正常呢？以及串口接線正常呢？ |
回答 |
|
問題6 | 支持單芯片出貨嗎？ 芯片是什么參數？什么包裝？芯片出貨穩定嗎 |
回答 |
所以成本就很低， 4、另外不支持講價。價格也沒什么空間了，請留意 |
問題7 | 支持修改uuid ，以及藍牙名和藍牙MAC地址嗎 |
回答 |
|
問題8 | 支持單芯片出貨嗎？ 芯片是什么參數？什么包裝 |
回答 |
|
問題9 | 硬件設計，有什么需要注意的地方嗎？ |
回答 |
|
問題10 | 支持買幾個樣品，幫我修改波特率到9600嗎？ |
回答 |
|
問題11 | 支持按照我們特定的uuid，以及服務，然后修改出樣品嗎？ |
回答 |
測試芯片的性能。不可能幾塊錢的東西，我們都要工程師參與配合修改，這樣效率太低了 2、實在需要修改的，可以，收人工費500修改 |
輯導讀：新客戶要了解一家企業或產品，通常都是通過他們的官網網站。區別于C端的官網，TO B的企業官網有更重要的商業價值。因此，如何在官網中展現企業的產品與服務，傳達品牌價值呢？本文作者對此進行了分析，希望對你有幫助。
企業產品是商業產品的一種，即面向企業市場且以盈利為目的的產品，通常有著業務門檻高、決策鏈復雜、輸出壓力大的特征。企業的官網服務于商家、客戶以及有興趣了解該領域的潛在客戶，展示企業的產品、服務，傳遞品牌價值等各種能力。區別于C端的官網，TO B的企業官網有更重要的商業價值。
改版迭代類的項目，核心是要明確改版的動機，現狀如何，解決什么問題，以及最終要達成改版的目標是什么。脫離商業目標的改版是沒有意義的，B端的商業目標通常是提高企業收入、提升業務效率、降低運營成本等。
企業官網是潛在客戶了解企業、了解產品和服務、聯系企業的媒介，如何讓客戶通過官網提升業務的轉化，是官網改版最核心的目標。這里我們可以從用戶、業務和品牌視覺層面來拆分目標。
區別于C端產品的界面體驗，TO B產品更重服務體驗，所以用戶層的目標就是圍繞產品提供什么服務，給用戶解決什么問題，比如：產品核心功能介紹，用戶使用產品的場景，產品如何解決行業痛點，用戶痛點，產品的價格是否具有競爭力，產品提供的服務和支持是否全面，解決了用戶的需求，等等。
相較于C端的單一類型用戶，B端的用戶類型比較豐富，也更垂直，不同類型的用戶看產品的視角和目標完全不同。在官網產品的改版項目中，我們將B端用戶類型劃分為決策者和使用者，來輔助我們確定用戶層。
在B端C化的趨勢，很多產品的轉化是由使用者有了試用的機會，進而推薦給決策者，還有決策者和使用者的邊界越來越模糊的現象，因此，我們不但要服務好高價值的決策者用戶的核心訴求，同時也不能忽視產品使用者的痛點，對于低價值的次要使用者、間接使用者這類用戶，不用專門考慮為其設計，以通用的信息版塊支持即可。
獲取用戶目標的方式可以采用深度訪談、電話采訪、問卷等形式，或者公司資源有限的情況下，結合行業信息和公司的線上數據進行整理。
將用戶群體的目標分類規整后，可以確定官網相應的內容和信息層級，達到有目的的傳達和有效轉化。
從業務角度來說，結合對目標群體的痛點和需求點，展示企業的產品價值，核心優勢，投入產出等，將這類信息「貨」通過在特定的頁面/版塊「場」內，推送給相應的用戶「人」，所以打造信息分層，讓不同需求的目標用戶快速匹配并認同產品價值，從而引導訪客留資，完成轉化。
如何打造頁面的信息分層，引導用戶快速轉化，在下面版塊具體改版步驟中會做詳細拆解。
官網的價值除了直接的轉化目標之外，還有打造專業性，樹立品牌形象，影響了用戶對企業/產品的認知和感受。
網站整體的色系、設計風格、品牌元素、圖標風格、版塊內容布局等等組成最終呈現給用戶的品牌形象。好的品牌形象會給用戶留下深刻印象，是獲得認同感的基礎，影響用戶最終的轉化。
品牌風格和視覺表現需要考慮到企業及產品的整體定位，公司戰略業務場景等等。
在我們著手改版前，對當前線上官網的問題梳理一下，確定目前存在的問題，才可以知道如何針對性的去改版優化。通常會有以下幾個典型的問題：
官網的框架結構，版塊布局就是給用戶講故事，用戶進入到官網，讓用戶從初步了解到產生興趣、價值認同最后成為付費用戶，是官網該有的敘事邏輯，如果只是根據業務的需求，在頁面上只是功能版塊的堆疊，沒有邏輯，沒有差異化的信息層級區分，那將很難有轉化。
官網的設計語言構建，品牌定位、風格是用戶對企業、產品最直接的印象，TO B的企業官網通過頁面的風格體現產品的定位，傳遞專業度、信任感。同時，隨著互聯網設計的發展，也出現了更多的表現形式，比如3d風、輕質感，還有實時渲染互動的交互，讓用戶更容易理解業務場景，加深認知。
轉化低是數據的呈現，也是衡量官網亟需改版的最直接原因，用戶的轉化路徑越長跳失率越高，轉化的目標最好只定一個，在官網的設計中，所有的元素有為轉化目標服務，但是現實情況可能不能避免多個目標，那么這種情況就一定要分好主次，在信息分層、內容布局、視覺處理上都要突出最主要的轉化目標。
1）頁面重構，信息層級優化
官網的首頁至關重要，是訪客進入的第一個頁面，內容上信息精準并高效傳達給用戶，說白了就是放什么和怎么放，要有清晰的敘事邏輯，這里我們借助營銷中的AIDA模型，構建官網的頁面版塊搭建：
Andrew Chak在“Sumit Now：Designing Persuasive Websites”（立即提交：設計有說服力的網站）一書中把這四個階段對應到網站的四類用戶：
瀏覽者：Attention階段，瀏覽信息，引起注意，但沒有深入了解
評估者：interest階段，開始有興趣了解詳情，關注價格
交易者：Desire階段，有購買意愿，甚至物品都放入了購物車
購買者：Action階段，已經達成購買行為
我們可以看到市面上的優秀TOB官網的首頁信息結構也是大多按照這樣的“套路”進行信息結構設計的，模仿用戶進入到首頁后，按照這樣的瀏覽順序層層深入：產品初識——逐步了解——強化認知——打消疑慮——轉化付費。
首焦——通常展示企業的產品/服務，給來訪者一個初步印象，核心業務——展示企業的核心價值，差異化競爭力優勢，同下一版塊的產品介紹，給用戶一個加深的印象，產品的詳細的功能、應用場景的展示讓用戶更了解產品，做出心理預期，是否滿足了用戶訴求。
緊接著用業務數據，案例佐證，售后服務，品牌背書這些版塊一步步，循序漸進讓用戶打消疑慮，加深對產品的信任，產生購買欲望，這時候，再及時給予留資入口，進而達到轉化目的。
2）突出重點版塊，縮短轉化路徑
企業官網除了露出產品的功能，還要打造產品差異化的核心價值，結合頁面整體來看，提升高價值信息展示優先級，讓用戶更快發現有利于轉化的內容，所以在表現形式上，為了提升信息呈現與觸達的效率，可以用更加豐富的信息緯度替換單一的表格、圖文的信息呈現形式，比如視頻、動圖，讓用戶能在單位時間里獲取更多的信息量，也更易理解，加深對產品的記憶。
還有可人機交互的模塊，實時與用戶互動，親自體驗產品的業務場景，和產品性能。
輕流首屏的視頻動態，更形象的演示了業務流程和場景
在成功引起用戶的興趣，想要在該節點做出行動時，要看時機適時“收網”，有幾種方式引導用戶快速轉化：
（1）設置即時行為召喚按鈕，比如首焦banner上的產品試用按鈕，頁面右側懸浮的客服聯系入口，首屏吸底的留資快速入口等等。
這里在文案上可以有一點“小心機”，讓用戶更多的點擊CTA按鈕，比如創造一種稀缺感，人們在面對稀缺性資源的時候都會有一種緊迫感，讓用戶想要趕緊先占位，快速做決定。
另外提高價格錨定也是一種快速讓用戶下單的方法，TO B的用戶會考慮投入產出，性價比，購買是否劃算，這時候如果給用戶一個對比下有價格優勢的產品，用戶就會容易接受。
（2）信息錄入精簡，需要用戶錄入信息填寫的內容，盡量簡單、清晰、高效，避免流程復雜、繁瑣讓用戶在錄入過程中感到枯燥乏味，容易流失。比如在留資的表單填寫模塊，盡量把無用、不重要的信息做刪減，縮短用戶填寫的信息量和時長，提高用戶填寫任務的完成效率。
1）官網常見布局樣式
（1）版心式布局
版心式布局就是頁面的內容展示在頁面的中央，首焦的視圖可能會根據瀏覽器寬度進行適配，但是有效顯示區域是頁面的中間區域。
這種布局樣式通常是基于前端實現考慮的，設計也只需出一套方案，雖然屏幕的利用率沒有達到最高，但是不需要考慮適配的問題，也很少會出現兼容出錯的情況，是很多傳統企業、政府類網站常常采用的布局方式。也有很多企業出于自身情況，本身內容較精簡，或開發資源的問題，也會采用這種布局。
這種布局方式的優點是對于設計師和前端開發都是最簡單的，按照標準寬度一種px尺寸設計，低于顯示屏寬度就居中展示，兩邊留白。超過屏幕寬度時橫滑，不用考慮適配的問題，也沒有兼容性問題。
缺點也是顯而易見的，在大屏的顯示器上不能利用好空間，浪費屏效。小屏幕被遮擋的畫面影響用戶的瀏覽體驗和閱讀效率。
（2）自適應布局
這種布局樣式就是考慮到了差別較大的屏幕尺寸上的展示效果，在視覺風格中我們可以明顯感覺到這種布局會因為頁面寬度的不同而呈現不同的布局樣式。
這種布局的優點正好是固定布局所達不到的，可以在不同尺寸顯示屏中都有最佳的屏效和展示效果，缺點是在實際項目實踐中，對設計來說，需要輸出多張設計圖和設計規范。同時，前端開發也要面臨復雜的判斷和條件限制。
（3）分屏布局
分屏布局的特點是一屏只展示一個重點信息，翻頁時自動切換一屏，適合多個同等權重信息的展示。常見的應用場景有奢侈品、電子產品、酒店民宿類的官網。
這種布局樣式的優點是信息非常聚焦，一屏詮釋一個重點，讓用戶沉浸式瀏覽，弊端也是很明顯的，單屏的信息密度太低，想要展示更多信息需要用戶主動下拉切換，同時這類布局沒有普適性，僅限某些特定行業和為了達到某些品牌定位和風格。
緊湊、適中和寬松的內容排版，在同樣的屏幕尺寸內展示的信息量是遞增的，恰當的信息密度，展示不同的信息差異化，比如門戶網站，電商類的首頁作為一個平臺，業務的訴求應該是在有限的空間內給最多的商家曝光，給用戶最大化的瀏覽效率，最快定位到目標入口，快速進行流量分發，那么可以采用緊湊型的內容密度。
而大部分的企業官網是展示自己的核心產品和服務，沒有那么多的信息量需要占據首屏，因此適中的內容密度適用于大多的企業官網。
那寬松的內容密度適合什么樣的企業呢？當企業以宣傳品牌影響力為官網主要目標，首頁的信息量比較少，想要突出品牌調性，這時，以大量的圖片、場景為元素，詮釋公司的品牌理念，給用戶有沉浸式的體驗。比如電子產品的官網，奢侈品行業，簡約風的家居品類，民宿、酒店產業等等。
B端的企業與產品有明顯的行業特性，所以在視覺風格上，不僅要體現行業性質，品牌風格，產品屬性，還要避免同質化，視覺上要有記憶點，與同行業競品拉開差距。TO B的產品用戶群體更多是偏向理性的購買者，更關注品牌的權威性、可信度以及帶來的價值。
隨著我們B端市場的產品多樣化，新興產業的崛起和被關注，還有設計流行趨勢的更新迭代，開發技術的成熟，設計師可發揮的空間也更加自由和靈活，以下為大家介紹幾種流行的官網視覺風格類型。
1）3D風
C4D、Blender等設計軟件的普及帶火了游戲行業、運營設計3D風的流行，逐漸在C端市場如野火燎原的趨勢占領高地，受到追捧。超現實的質感、3維立體的空間感，如臨其境的既視感確實將表現力拉滿，帶來很強的視覺沖擊和沉浸感。在Z時代逐漸成為時代主流時，B端的一些企業也開始重視用戶的偏好，設計師之間的較量也卷到了B端的視覺表現。
B端企業運用3D風格較多是在云產品、物聯網、大數據、數字孿生等行業，這類官網對視覺的表現要求很高，但產品又很難用具象的實物來表現，所以3D技術的成熟為這類企業的官網呈現帶來了曙光。
比如騰訊云官網的設計，在Banner、圖標、核心產品模塊展示、業務場景應用上，3D元素將云平臺的行業屬性、科技感的產品特征，以及傳遞給用戶的空間感都完美表達出來，同時在首焦用可人機交互的互動效果，PC端用鼠標hover時圖形變化，交互反饋，讓用戶有很好的互動感。
騰訊云的首焦用3D風塑造了云產品的具體形象，鼠標交互，能與之互動
2）插畫風
同樣有產品實物展示難題的困擾，但基于行業性質、品牌定位問題、技術實現等方面的原因，還可以采用插畫的表現形式。在擬物化向扁平風格轉型的10年來，扁平插畫的設計早已深入人心，用插畫的元素表現抽象的，模糊的產品/服務，塑造品牌品牌形象。
將信息用圖形化方式直觀的傳達給用戶，不僅降低了理解門檻，還能將品牌形象更深入人心，比如像教育類、人工智能、車載類的系統會塑造一個IP形象，以具象化、擬人的形象拉近與用戶的距離，也傳達了品牌的定位和認知。
有了IP形象，可以在一切可以展示的場合體系化的表現情感化設計，比如聯系客服的對話彈窗，錯誤提示、空狀態等等。將品牌的形象更加深化，給用戶深刻的品牌認知。
3）實景配圖
文字配合實景圖的設計方式在官網的設計上也是非常常見的，這種風格能傳遞真實感，能拉進與用戶距離，從而給用戶信任感。比如一些傳統實業，展示企業實力，企業的效能。家居、酒店類的企業，用實景圖給用戶打造了身臨其境的氛圍感，舒適、溫馨的家居質感，高級、有調性的設計風格，是可以直抵用戶的內心訴求的。
還有科技產品的企業官網，也會喜歡用產品的實物圖展示，這也是抓住了用戶的核心訴求，一些電子產品發燒友，最關注的就是產品本身。加上明星代言的形象和產品結合，將粉絲效應帶動產品銷量，是一波成功的營銷。
實拍圖的設計風格，對圖片的質量要求非常高，不但要體現產品的核心價值，功能場景，還要詮釋品牌的定位、調性，構圖如何呈現視覺美感，產品品質和質感的體現，傳遞的品牌形象都是需要考慮的重點。
因為TO B企業的產品服務成本一般都較高，在對產品未知的線上平臺，官網必須最大化透傳品牌的行業知名度，業務穩定性等差異化優勢，才能在用戶心理增強購買的決心。官網的整個設計語言系統應包含品牌基因+設計規范+多場景應用。
品牌升級并不是倉促的改改顏色、樣式，優化一下logo之類，而是在充分理解業務、用戶、品牌三方的背景之下，定義設計規則，落地設計元素。
品牌升級策略有其獨特性，本文中不作贅述，在此延展說一下設計規則應該如何落地。
我們常見一些設計團隊通用一套“清晰、簡潔、高效”以不變應萬變，但這僅僅是基礎的原則，太過看寬泛，無法很好的應用落地在實際的項目中。
設計原則應該貼近業務，真實有效，比如工業類實業的企業，應突出其智造、安全、有實力的產品定位，云平臺的企業突出其專業、效率、先進，這才是更貼近業務的設計規則，然后根據精準定位的關鍵詞進行設計延伸。
避免同質化的設計元素：圖標、配圖、文字設計等，應結合品牌找到記憶點，讓用戶一眼能識別，留下深刻印象。比如IP形象的流行，衍生出的一套設計語言，帶給用戶很強的品牌記憶。
在團隊合力完成官網項目的改版上線之后，除了關注改版的業務目標、設計目標是否達到預期，還應該注意搜集線上的數據，與改版前的用戶行為路徑，PV/UV、停留時長、點擊率等多方面對比，看數據上是否與預期的設計有出入，并針對問題分析原因，給出優化方案作為下次優化的依據。
除了線上的數據，如果再進一步完善信息搜集，可通過問卷調研，明確用戶畫像，了解用戶對新版本的滿意度、線上問題的針對性調研，同時在企業內部，征集運營、產研、市場等職能部門的建議和反饋，整理需求，分析反饋意見的合理性，是否真實落地，對合理的意見、需求給出解決方案，與團隊內部溝通進優化迭代，進一步完善線上官網。
官網改版的項目是公司內部眾多項目的一個縮影，考驗團隊從戰略分解，到落地執行的能力，這里希望每個職能的小伙伴擁有主人翁意識，靠譜的合作伙伴、踴躍積極的為共同目標出謀劃策，發揮其專業特長，認真負責，有極客精神，在客觀條件有限的情況下，可以攻克逆境，發揮凝聚力，那么最后的結果一定帶來可喜的回饋，同時安利大家可以寫復盤的文章，設計同學整理設計資產沉淀，在后期項目中能夠再次復用。輸出是最好的輸入方式，項目的積淀也會讓你成為發揮最大價值的人，助力你的成長。
資料參考：
https://www.zcool.com.cn/article/ZMTEzNzkzMg==.html
https://mp.weixin.qq.com/s/_MOSy5v3JfW_ajIJB3kikg
https://jelly.jd.com/article/5fd59636afd56f0142e4bc1f
https://blog.csdn.net/YeChaDeChenFu/article/details/124493574
本文由 @體驗設計 笑笑 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
者｜狼叔（阿里前端技術專家，Node技術布道者）
編輯｜覃云
你好，我是阿里巴巴前端技術專家狼叔，在上一篇文章中，我分享了大前端的現狀和未來，接下來的這篇文章，我將會分享一些大前端跟 Node.js 結合比較密切的點。
Node.js 在大前端布局里意義重大，除了基本構建和 Web 服務外，這里我還想講兩點。
首先它打破了原有的前端邊界，之前應用開發只分前端和 API 開發。但通過引入 Node.js 做 BFF 這樣的 API proxy 中間層，使得 API 開發也成了前端的工作范圍，讓后端同學專注于開發 RPC 服務，很明顯這樣明確的分工是極好的。
其次，在前端開發過程中，有很多問題不依賴服務器端是做不到的，比如場景的性能優化，在使用 React 后，導致 bundle 過大，首屏渲染時間過長，而且存在 SEO 問題，這時候使用 Node.js 做 SSR 就是非常好的。
當然，前端開發 Node.js 還是存在一些成本，要了解運維等，會略微復雜一些，不過也有解決方案，比如 Servlerless 就可以降級運維成本，又能完成前端開發。直白點講，在已有 Node.js 拓展的邊界內，降級運維成本，提高開發的靈活性，這一定會是一個大趨勢。
2018 年 Node.js 發展的非常好，InfoQ 曾翻譯過一篇文章《2018 Node.js 用戶調查報告顯示社區仍然在快速成長》。2018 年 5 月 31 日，Node.js 基金會發布了 2018 年用戶調查報告，涵蓋了來自 100 多個國家 1600 多名參與者的意見。報告顯示，Node.js 的使用量仍然在快速增長，超過?的參與者期望在來年擴展他們的使用場景，另外和 2017 年的報告相比，Node 的易學程度有了大幅提升。
該調查遠非 Node 快速增長的唯一指征。根據 ModuleCounts.com 的數據，Node 的包注冊中心 NPM 每天會增加 507 個包，相比下一名要多 4 倍多。2018 年 Stack Overflow 調查也有類似的結果，JavaScript 是使用最廣泛的語言，Node.js 是使用最廣泛的框架。
本節我會主要分享一些跟 Node.js 結合比較密切的點：首先介紹一下 API 演進與 GraphQL，然后講一下 SSR 如何結合 API 落地，構建出具有 Node.js 特色的服務，然后再簡要介紹下 Node.js 的新特性、新書等，最后聊聊我對Deno 的一點看法。
書本上的軟件工程在互聯網高速發展的今天已經不那么適用了，尤其是移動開發火起來之后，所有企業都崇尚敏捷開發，快魚吃慢魚，甚至覺得 2 周發一個迭代版本都慢，后面組件化和熱更新就是這樣產生的。綜上種種，我們對傳統的軟件工程勢必要重新思考，如何提高開發和產品迭代效率成為重中之重。
先反思一下，開發為什么不那么高效？
從傳統軟件開發過程中，可以看到，需求提出后，先要設計出 ui/ue，然后后端寫接口，再然后 APP、H5 和前端這 3 端才能開始開發，所以串行的流程效率極低。
于是就有了 mock api 的概念。通過靜態 API 模擬，使得需求和 ue 出來之后，就能確定靜態 API，造一些模擬數據，這樣 3 端 + 后端就可以同時開發了。這曾經是提效的非常簡單直接的方式。
靜態 API 實現有很多種方式，比如簡單的基于 Express / Koa 這樣的成熟框架，也可以采用專門的靜態 API 框架，比如著名的 typicode/json-server，想實現 REST API，你只需要編輯 db.json，放入你的數據即可。
{
"posts": [
{ "id": 1, "title": "json-server", "author": "typicode" }
],
"comments": [
{ "id": 1, "body": "some comment", "postId": 1 }
],
"profile": { "name": "typicode" }
}
啟動服務器：
$ json-server --watch db.json
此時訪問網址 http://localhost:3000/posts/1，即我們剛才仿造的靜態 API 接口，返回數據如下：
{ "id": 1, "title": "json-server", "author": "typicode" }
還有更好的解決方案，比如 YApi ，它是一個可本地部署的、打通前后端及 QA 的、可視化的接口管理平臺：http://yapi.demo.qunar.com/
其實，圍繞 API 我們可以做非常多的事兒，比如根據 API 生成請求，對服務器進行反向壓測，甚至是 check 后端接口是否異常等。很明顯，這對前端來說是極其友好的。下面是我幾年前畫的圖，列出了我們能圍繞 API 做的事兒，至今也不算過時。
通過社區，我們可以了解到當下主流的 API 演進過程。
1.GitHub v3 的 restful api，經典 rest；
2. 微博 API，非常傳統的 json 約定方式；
3. 在 GitHub 的 v4 版本里，使用 GraphQL 來構建 API，這也是個趨勢。
GraphQL 目前看起來比較火，那 GitHub 使用 GraphQL 到底解決的是什么問題呢？
GraphQL 既是一種用于 API 的查詢語言也是一個滿足你數據查詢的運行時。
下面看一個最簡單的例子：
很明顯，這和靜態 API 模擬是一樣的流程。但 GraphQL 要更強大一些，它可以將這些模型和定義好的 API 和后端很好的集成。于是 GraphQL 就統一了靜態 API 模擬和和后端集成。
開發者要做的，只是約定模型和 API 查詢方法。前后端開發者都遵守一樣的模型開發約定，這樣就可以簡化溝通過程，讓開發更高效。
如上圖所示，GraphQL Server 前面部分，就是靜態 API 模擬。GraphQL Server 后面部分就是與各種數據源進行集成，無論是 API、數據還是微服務。是不是很強大？
下面我們總結一下 API 的演進過程。
傳統方式：Fe 模擬靜態 API，后端參照靜態 API 去實習 rpc 服務。
時髦的方式：有了 GraphQL 之后，直接在 GraphQL 上編寫模型，通過 GraphQL 提供靜態 API，省去了之前開發者自己模擬 API 的問題。有了 GraphQL 模型和查詢，使用 GraphQL 提供的后端集成方式，后端集成更簡單，于是 GraphQL 成了前后端解耦的橋梁。
集成使用的就是基于 Apollo 團隊的 GraphQL 全棧解決方案，從后端到前端提供了對應的 lib ，使得前后端開發者使用 GraphQL 更加的方便。
GraphQL 本身是好東西，和 Rest 一樣，我的擔心是落地不一定那么容易，畢竟接受約定和規范是很麻煩的一件事兒。可是不做，又怎么能進步呢？
2018 年，有一個出乎意料的一個實踐，就是在瀏覽器可以直接調用 grpc 服務。RPC 服務暴漏 HTTP 接口，這事兒 API 網關就可以做到。事實上，gRPC-Web 也是這樣做的。
如果只是簡單透傳，意義不大。大多數情況，我們還是要在 Node.js 端做服務聚合，繼而為不同端提供不一樣的 API。這是比較典型的 API Proxy 用法，當然也可以叫 BFF(backend for frontend)。
從前端角度看，渲染和 API 是兩大部分，API 部分前端自己做有兩點好處：
1. 前端更了解前端需求，尤其是根據 ui/ue 設計 API；
2. 讓后端更專注于服務，而非 API。需求變更，能不折騰后端就盡量不要去折騰后端。這也是應變的最好辦法。
構建具有 Node.js 特色的微服務，也主要從 API 和渲染兩部分著手為主。如果說能算得上創新的，那就是 API 和渲染如何無縫結合，讓前端開發有更好的效率和體驗。
盡管 Node.js 中間層可以將 RPC 服務聚合成 API，但前端還是前端，API 還是 API。那么如何能夠讓它們連接到一起呢？比較好的方式就是通過 SSR 進行同構開發。服務端創新有限，搞來搞去就是不斷的升 v8，提升性能，新東西不多。
今天我最頭疼的是，被 Vue/React/Angular 三大框架綁定，喜憂參半，既想用組件化和雙向綁定（或者說不得不用），又希望保留足夠的靈活性。大家都知道 SSR 因為事件 /timer 和過長的響應時間而無法有很高的 QPS（夠用，優化難），而且對 API 聚合處理也不是很爽。更尷尬的是 SSR 下做前后端分離難受，不做也難受，到底想讓人咋樣？
對于任何新技術都是一樣的，不上是等死，上了是找死。目前是在找死的路上努力的找一種更舒服的死法。
目前，我們主要采用 React 做 SSR 開發，上圖中的 5 個步驟都經歷過了（留到 QCon 廣州場分享），這里簡單介紹一下 React SSR。React 16 現在支持直接渲染到節點流。渲染到流可以減少你內容的第一個字節（TTFB）的時間，在文檔的下一部分生成之前，將文檔的開頭至結尾發送到瀏覽器。當內容從服務器流式傳輸時，瀏覽器將開始解析 HTML 文檔。渲染到流的另一個好處是能夠響應背壓。
實際上，這意味著如果網絡被備份并且不能接受更多的字節，那么渲染器會獲得信號并暫停渲染，直到堵塞清除。這意味著你的服務器會使用更少的內存，并更加適應 I / O 條件，這兩者都可以幫助你的服務器擁有具有挑戰性的條件。
在 Node.js 里，HTTP 是采用 Stream 實現的，React SSR 可以很好的和 Stream 結合。比如下面這個例子，分 3 步向瀏覽器進行響應。首先向瀏覽器寫入基本布局 HTML，然后寫入 React 組件<MyPage/>，然后寫入</div></body></html>。
// 服務器端
// using Express
import { renderToNodeStream } from "react-dom/server"
import MyPage from "./MyPage"
app.get("/", (req, res) => {
res.write("<!DOCTYPE html><html><head><title>My Page</title></head><body>");
res.write("<div id='content'>");
const stream = renderToNodeStream(<MyPage/>);
stream.pipe(res, { end: false });
stream.on('end', () => {
res.write("</div></body></html>");
res.end();
});
});
這段代碼里需要注意stream.pipe(res, { end: false })，res 本身是 Stream，通過 pipe 和<MyPage/>返回的 stream 進行綁定，繼而達到 React 組件嵌入到 HTTP 流的目的。
上面是服務器端的做法，與此同時，你還需要在瀏覽器端完成組件綁定工作。react-dom 里有 2 個方法，分別是 render 和 hydrate。由于這里采用 renderToNodeStream，和 hydrate 結合使用會更好。當 MyPage 組件的 html 片段寫到瀏覽器里，你需要通過 hydrate 進行綁定，代碼如下。
// 瀏覽器端
import { hydrate } from "react-dom"
import MyPage from "./MyPage"
hydrate(<MyPage/>, document.getElementById("content"))
可是，如果有多個組件，需要寫入多次流呢？使用 renderToString 就簡單很多，普通模板的方式，流卻使得這種玩法變得很麻煩。
偽代碼：
const stream1 = renderToNodeStream(<MyPage/>); const stream2 = renderToNodeStream(<MyTab/>); res.write(stream1) res.write(stream2) res.end()
核心設計是先寫入布局，然后寫入核心模塊，然后再寫入其他模塊。
1) 布局 (大多數情況靜態 html 直接吐出，有可能會有請求)；
2) Main（大多數情況有請求）；
3) Others。
于是：
class MyComponent extends React.Component {
fetch(){
// 獲取數據
}
parse(){
// 解析，更新 state
}
render(){
...
}
}
在調用組件渲染之前，先獲得 renderToNodeStream，然后執行 fetch 和 parse 方法，取到結果之后再將 Stream 寫入到瀏覽器。當前端接收到這個組件編譯后的 html 片段后，就可以根據 containerID 直接寫入，當然如果需要，你也可以根據服務器端傳過來的 data 進行定制。
前后端如何通信、服務端代碼如何打包、css 如何直接插入、和 eggjs 如何集成，這是目前我主要做的事兒。對于 API 端已經很成熟，對于 SSR 簡單的做法也是有的，比如 next.js 通過靜態方法 getInitialProps 完成接口請求，但只適用比較簡單的應用場景（一鍵切換 CSR 和 SSR，這點設計的確實是非常巧妙的）。但是如果想更靈活，處理更負責的項目，還是很有挑戰的，需要實現上面更為復雜的模塊抽象。在 2019 年，應該會補齊這塊，為構建具有 Node.js 特色的服務再拿下一塊高地。
簡單地說，Serverless = FAAS + BaaS ，服務如果被認為是 Serverless 的，它必須無需顯式地配置，并能自動調整擴縮容以及根據使用情況進行計費。云 function 是當今無 Serverless 計算中的通用元素，并引領著云的簡化和通用編程模型發展的方向。
2015 年亞馬遜推出了一項名為 AWS Lambda 服務的新選項。Node.js 領域 TJ 大神去創業，開發了 http://apex.run。目前，各大廠都在 Serverless 上發力，比如 Google、AWS、微軟，阿里云等。
這里不得不提一下 Eventloop，Node.js 成也 Eventloop，敗也 Eventloop，本身 Eventloop 是黑盒，開發將什么樣的代碼放進去你是很難全部覆蓋的，偶爾會出現 Eventloop 阻塞的情況，排查起來極為痛苦。
而利用 Serverless，可以有效的防止 Eventloop 阻塞。比如加密，加密是常見場景，但本身的執行效率非常慢。如果加解密和你的其他任務放到一起，很容易導致 Eventloop 阻塞。
如果加解密服務是獨立的服務呢？比如在 AWS 的 Lambda 上發布上面的代碼，它自身是獨立的，按需來動態擴容機器，可以去除 CPU 密集操作對 Node.js 的影響，快速響應流量變化。
這是趨勢，對于活動類的尤其劃算。你不知道什么時候是峰值，需要快速動態擴容能力，你也不會一直使用，按需付費更好。就算這個服務掛了，對其他業務也不會有什么影響，更不會出現阻塞 Eventloop 導致雪崩的情況。
在前端領域，Serverless 會越來越受歡迎，除了能完成 API Proxy，BFF 這種功能外，還可以減少前端運維成本，還是可以期望一下的。
2018 年有一個大家玩壞的梗：想提升性能，最簡單的辦法就是升級到最新 LTS 版本。因為 Node.js 依賴 v8 引擎，每次 v8 發版優化，新版 Node.js 集成新版 v8，于是性能就被提升了。
其他手段，比如使用 fast-json-stringify 加速 JSON 序列化，通過 Schema 知道每個字段的類型，那么就不需要遍歷、識別字段類型，而是可以直接用序列化對應的字段，這就大大減少了計算開銷，這就是 fast-json-stringfy 的原理，在某些情況下甚至可以比 JSON.stringify 快接近 10 倍左右。
在 2018 年，Node.js 非常穩定的前進著。下面看一下 Node.js 發版情況，2018-04-24 發布 Node.js v10，在 2018-10-23 發布 Node.js v11，穩步增長。下圖是 Node.js 的發布計劃。
可以看到，Node.js 非常穩定，API 也非常穩定，變化不大，一直緊跟 V8 升級的腳步，不斷的提升性能。在新版本里，能夠值得一說的，大概就只有 http2 的支持。
在 HTTP/2 里引入的新特性有：
目前，HTTP/2 已經開始落地，并且越來越穩定，高性能。HTTP/2 在 Node.js v8.4 里加入，在 Node.js v10 變為 Stable 狀態，大家可以放心使用。示例代碼如下。
const http2 = require('http2');
const fs = require('fs');
const server = http2.createSecureServer({
key: fs.readFileSync('localhost-privkey.pem'),
cert: fs.readFileSync('localhost-cert.pem')
});
server.on('error', (err) => console.error(err));
其他比如 trace_events，async_hooks 等改進都比較小。Node.js 10 將 npm 從 5.7 更新到 v6，并且在 node 10 里增強了 ESM Modules 支持，但還是不是很方便（官方正在實現新的模塊加載器），不過很多知名模塊已經慢慢支持 ESM 特性了，一般在 package.json 里增加如下代碼。
{
"jsnext:main": "index.mjs",
}
另外異常處理，終于可以根據 code 來處理了。
try {
// foo
} catch (err) {
if (err.code === 'ERR_ASSERTION') { . . . }
else { . . . }
}
最后再提 2 個模塊：
node-clinic 性能調試神器
https://clinicjs.org
這是一個 Node.js 性能問題的診斷工具，可以生成 CPU、內存使用、事件循環（Event loop) 延時和活躍的句柄的相關數據折線圖。
Lowjs 使用 Node.js 去開發 IoT
https://www.lowjs.org/
Node-RED 構建 IoT 很久前就有了，這里介紹一下 Lowjs。Low.js 是 Node.js 的改造版本，可以對低端操作有更好的支持。它是基于內嵌的對內存要求更低的 js 引擎 DukTape。Low.js 僅需使用不到 2MB 的硬盤和 1.5MB 的內存。
Ry 把 Deno 用 Rust 重寫了之后，就再也沒有人說 Deno 是下一代 Node.js 了。其中的原因大家大概能夠想明白，別有用心的人吹水還是很可怕的。Deno 基于 ts 運用時環境，底層使用 Rust 編寫。性能、安全性上都很好，但舍棄了 npm 生態，需要做的事兒還是非常多的，甚至有人將 Koa 移植過去，也是蠻有意思的事兒。如果 Deno 真的能走另一條路，也是非常好的事兒。
不知道還有多少人還記得，Google 的 ChromeOS 的理念是“瀏覽器即操作系統”。現在看來，未來已經不遠了。通過各種研究，我們有理由堅定 Web 信仰，未來大前端的前景會更好，此時此刻，只是剛剛開始。
這里我再分享一些參加 Google IO 時了解到的信息：
為什么會產生這樣的改變？原因在于：
這里首先要感謝 Chrome+Android 的嘗試，使得 PWA 擁有和 Android 應用同等的待遇和權限。谷歌同時擁有 Chrome 和 Android，所以才能夠在上面做整合，進一步擴大 Web 開發的邊界。通過嘗試，開放，最終形成標準，乃至是業界生態。很明顯，作為流量入口，掌握底層設施能力是無比重要的。
Chrome 還提供了相應 Web 端的 API，如 web pay、web share、credential management api、media session 等。
Chrome 作為入口是可怕，再結合 Android，使得 Google 輕松完成技術創新，繼而形成標準規范，推動其他廠商，一直領先是可怕的。
前端的爆發，說來也就是最近 3、4 年的事情，其最根本的創造力根源在 Node.js 的助力。Node.js 讓更多人看到了前端的潛力，從服務器端開發，到各種腳手架、開發工具，前端開始沉浸在造輪子的世界里無法自拔。組件化后，比如 SSR、PWA 等輔助前端開發的快速開發實踐你幾乎躲不過去，再到 API 中間層、代理層到專業的后端開發都有非常成熟的經驗。
我親歷了從 Node 0.10 到 iojs，從 Node v4 到目前的 Node v11，寫了很多文章，參加過很多技術大會，也做過很多次演講，有機會和業內很多高手交流。當然，我也從 Qunar 到阿里，經歷了各種 Node 應用場景，對于 Node 的前景我是非常篤定的。善于使用 Node 有無數好處，想快速出成績，想性能調優，想優化團隊結構，想人員招聘，選擇 Node 是不會有錯的，諸多利好都讓我堅定的守護 Node.js，至少 5 年以上。
我想跟很多技術人強調的是，作為前端開發，你不能只會 Web 開發技術，你需要掌握 Node，你需要了解移動端開發方式，你需要對后端有更多了解。而擁有更多的 Node.js 和架構知識，能夠讓你如魚得水，開啟大前端更多的可能性。
如果前面有二輛車，一輛是保時捷一輛是眾泰，如果你必須撞一輛，你選哪個？
理性思維是哪個代價最低撞哪個，前提是你能夠判斷這兩輛車的價值，很明顯保時捷要比眾泰貴很多。講這個的目的是希望大家能夠理解全棧的好處。全棧是一種信仰，不是拿來吹牛逼的，而是真的可以解決更多問題，同時也能讓自己的知識體系不留空白，享受自我實現的極致快樂。另外，如果你需要了解更多的架構知識，全棧也是個不錯的選擇。
以我為例，我從接觸全棧概念到現在，經歷了以下四個階段：
不忘初心，堅持每天都能寫代碼，算是我最舒服自豪的事兒了吧，以前說越大越忙，現在要說越老越忙了，有了孩子，帶人，還想做點事兒，能安靜的寫會代碼其實不容易。
說了這么多，回到大前端話題，至少目前看 2019 年都是好事，一切都在趨于穩定和標準化，大家不必要過于焦慮。不過，掌握學習能力始終是最重要的，還是那兩句話：“廣積糧，高筑墻，緩稱王”，“少抱怨，多思考，未來更美好”。
做一個堅定的 Web 信仰者，把握趨勢，選擇比努力更重要！
推薦閱讀
2019年大前端技術趨勢深度解讀
作者簡介
狼叔（網名 i5ting），現為阿里巴巴前端技術專家，Node.js 技術布道者，Node 全棧公眾號運營者。曾就職于去哪兒、新浪、網秦，做過前端、后端、數據分析，是一名全棧技術的實踐者，目前主要關注技術架構和團隊梯隊建設方向。即將出版《狼書》3 卷。
最后給自己打一個廣告，今年 6 月 20 日北京舉辦的 GMTC 大會上，我會擔任 Node 專場出品人，主要關注 Serverless，TypeScript 在 Web 開發框架里相關實踐，以及性能，SSR，架構相關的 topic，如果你有想法，想分享的話，歡迎聯系我。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
