1. 前言
通過“藍牙協議分析(2)_協議架構”的介紹，大家對藍牙協議棧應該有了簡單的了解，但是，肯定還有“似懂非懂、欲說還休”的感覺。有這種感覺太正常了，畢竟藍牙協議是一個歷史悠久又比較龐大的協議，沒那么容易理解。
因此，本文將換個視角，從協議棧設計者的角度，思考如下問題：
| 為什么會有藍牙協議棧（Why）？ 怎樣實現藍牙協議棧（How）？ 藍牙協議棧的最終樣子是什么（What）？ |
另外，我們知道，當前的藍牙協議包含BR/EDR、AMP、LE三種技術，為了降低復雜度，本文將focus在現在比較熱門的BLE（Bluetooth Low Energy）技術上（物聯網嘛！），至於BR/EDR和AMP，觸類旁通即可。
2. Why
“Why”要回答的其實是需求問題，對BLE（藍牙低功耗）來說，其需求包含兩個部分：和傳統藍牙重疊的部分；BLE特有的低功耗部分。大致總結如下：
| 基於2.4GHz ISM頻段的無線通信； 通信速率要求不高，但對功耗極為敏感； 盡量復用已有的BR/EDR技術； 組網方式自由靈活，既可以使用傳統藍牙所使用的“基於連接的星形網絡（由1個master和多個slave組成）”，也可以使用“無連接的網狀網絡（由多個advertiser和多個scanner組成）； 參與通信的設備的數量和種類眾多，要從應用的角度考慮易於實現、互聯互通等特性； 有強烈的安全（security）需求； 等等。 |
3. How和What
“How”要回答的是設計思路，“What”是基於該思路設計出來的最終產品的樣子。
按理說，需要先介紹“How”，后介紹所產出的“What”。但以蝸蝸對藍牙的理解，顯然無法拋開“What”單獨回答“How”。所以，基於現有的協議框架（What），去理解背后的“How”，才是明智之舉。
開始之前，我們先總結一下BLE的協議框架，后面章節會根據該框架，采用自下向上的方法逐層分析介紹。
如下面圖片1所示，BLE的協議可分為Bluetooth Application和Bluetooth Core兩大部分，而Bluetooth Core又包含BLE Controller和BLE Host兩部分（有關概念可參考“藍牙協議分析(1)_基本概念”）。
圖片1 BLE協議框架
4. Physical Layer
任何一個通信系統，首先要確定的就是通信介質（物理通道，Physical Channel），BLE也不例外。在BLE協議中，“通信介質”的定義是由Physical Layer（其它通信協議也類似）負責。
Physical Layer是這樣描述BLE的通信介質的：
| 由於BLE屬於無線通信，則其通信介質是一定頻率范圍下的頻帶資源（Frequency Band）； BLE的市場定位是個體和民用，因此使用免費的ISM頻段（頻率范圍是2.400-2.4835 GHz）； 為了同時支持多個設備，將整個頻帶分為40份，每份的帶寬為2MHz，稱作RF Channel。 |
經過上面的定義之后，BLE的物理通道已經出來了，即“頻點分別是‘f=2402+k*2 MHz, k=0, … ,39’，帶寬為2MHz”的40個RF Channel。
除了物理通道之外，Physical Layer還需要定義RF收發雙方的一些其它特性，包括（不影響本文后續的討論，不用深究）：
| RF發射相關的特性（Transmitter Characteristics），包括發射功率（Transmission power、調制方式（Modulation），高斯頻移鍵控（Gaussian Frequency Shift Keying ，GFSK）、Spurious Emissions、Radio Frequency Tolerance等等。（不影響本文后續的討論，不用深究）； RF接收相關的特性（Receiver Characteristics），包括接收靈敏度等。 |
5. Link Layer
5.1 功能介紹
經過Physical Layer的定義，通信所需的物理通道已經okay了，即40個RF Channel（后面統一使用Physical Channel指代）。此時Link Layer可以粉墨登場了，它主要的功能，就是在這些Physical Channel上收發數據，與此同時，不可避免的需要控制RF收發相關的參數。但僅做這些，還遠遠不夠：
| 首先，Physical Layer僅僅提供了有限的40個Physical Channel，而BLE中參與通信的實體的數量，肯定不是這個數量級。Link Layer需要解決Physical Channel的共享問題； 其次，通信是兩個實體之間的事情，對這兩個實體來說，它們希望看到一條為自己獨享的傳輸通道（就是我們所熟悉的邏輯鏈路，Logical Link）。這也是Link Layer需要解決的； 再則，Physical Channel是不可靠的，任何數據傳輸都可能由於干擾等問題二損毀、丟失，這對有些應用來說，是接受不了的。因此Link Layer需要提供校驗、重傳等機制，確保數據傳輸的可靠性； 等等，等等，簡直是既當爹又當媽！ |
5.2 怎么解決Physical Channel的共享問題
BLE系統只有有限的40個Physical Channel，怎么容納多個通信實體呢？說來也簡單，Link Layer將BLE的通信場景分為兩類：
1） 數據量比較少、發送不頻繁、對時延不是很敏感的場景
例如一個傳感器節點（如溫度傳感器），需要定時（如1s）向處理中心發送傳感器數據（如溫度）。
針對這種場景，BLE的Link Layer采取了一種比較懶的處理方式----廣播通信：
| 從40個Physical Channel中選取3個，作為廣播通道（advertising channel）； 在廣播通道上，任何參與者，愛發就發，愛收就收，隨便； 所有參與者，共享同一個邏輯傳輸通道（廣播通道），之間的 |
當然，這種方法存在很多問題，例如：
| 不可靠，是否會相互干擾？發送是否成功？不知道！接收是否成功？不知道！ 效率不高，如果同一區域有很多節點在廣播數據，某一個接收者是不是要接收所有的數據包，不管是不是它關心的？ 安全問題，怎么解決？ |
確實，問題多多，不過Link Layer定義了一些策略，盡可能的提高了這種通信方式的便利性，后面我們會介紹。至於無法解決的，簡單，兩種方案：
| a）忍，廣播通信需要占用的資源實在太少了，正對物聯網中的那些小節點們的胃口啊。 b）使用基於連接的通信方式（就是給你倆建立一個專線），具體可參考下面5.2.2的介紹。 |
2）數據量較大、發送頻率較高、對時延較敏感的場景
BLE的Link Layer會從剩余的37個Physical Channel中，選取一個，為這種場景里面的通信雙方建立單獨的通道（data channel）。這就是連接（connection）的過程。
同時，為了增加容量，增大抗干擾能力，連接不會長期使用一個固定的Physical Channel，而是在多個Channel（如37個）之間隨機但有規律的切換，這就是BLE的跳頻（Hopping）技術。
5.3 狀態（state）和角色（role）的定義
基於上面5.2小節的思路，BLE協議在Link Layer抽象出5種狀態：
注1：從橫向看，協議的每個層次（如這里的Link Layer）都可以當做可相互通信的實體。這里的狀態，就是指這每一層實體的狀態。因此，在協議的多個層次上，都可能有狀態定義，甚至名字也一樣，我們閱讀協議棧的時候，一定要留意，不要被繞暈了。
| • Standby State • Advertising State • Scanning State • Initiating State • Connection State |
並以如下的狀態機進行切換（設備在同一時刻只能處於這些狀態的一種）：
圖片2 Link Layer狀態機
Standby狀態是初始狀態，即不發送數據，也不接收數據。根據上層實體的命令（如位於host軟件中GAP），可由其它任何一種狀態進入，也可以切換到除Connection狀態外的任意一種狀態。
Advertising狀態是可以通過廣播通道發送數據的狀態，由Standby狀態進入。它廣播的數據可以由處於Scanning或者Initiating狀態的實體接收。上層實體可通過命令將Advertising狀態切換回Standby狀態。另外，連接成功后，也可切換為Connection狀態。
Scanning狀態是可以通過廣播通道接收數據的狀態，由Standby狀態進入。根據Advertiser所廣播的數據的類型，有些Scanner還可以主動向Advertiser請求一些額外數據。上層實體可通過命令將Scanning狀態切換回Standby狀態。
Initiating狀態和Scanning狀態類似，不過是一種特殊的接收狀態，由Standby狀態進入，只能接收Advertiser廣播的connectable的數據，並在接收到數據后，發送連接請求，以便和Advertiser建立連接。當連接成功后，Initiater和對應的Advertiser都會切換到Connection狀態。
Connection狀態是和某個實體建立了單獨通道的狀態，在通道建立之后，由Initiating或者Advertising自動切換而來。通道斷開后，會重新回到Standby狀態。
通道建立后（通常說“已連接”），處於Connection狀態的雙方，分別有兩種角色Master和Slave：
| Initiater方稱作Mater； Advertiser方稱作Slave。 |
5.4 Air Interface Protocol
狀態和角色定義完成后，剩下的事情就簡單了，主要包括兩類：提供某一狀態下，和其它實體對應狀態之間的數據交換機制；根據上層實體的指令，以及當前的實際情況，負責狀態之間的切換。BLE協議中，這些事情是由一個叫做空中接口協議（Air Interface Protocol）的家伙負責，主要思路如下。
5.4.1 定義在Physical Channel上收發的數據包的格式（packet format）
在BLE中，兩種類型的Physical Channel（advertising channel和data channel）統一使用一種packet format，如下：
Preamble(1 octet) | Access Address(4 octets) | PDU(2 to 257 octets) | CRC(3 octets)
| 關於packet format，我們可以關注如下內容： 1）Access Address，用於識別。 2）PDU，BLE在Link Layer的PDU長度最大為257 octets（不知道octets是神馬意思？當做bytes就行了）。這決定了上層實體，如L2CAP、Application等，需要拆分、重組才能支持更大數據量的傳輸。 3）Link Layer總packet長度是9~264bytes。 |
5.4.2 定義不同類型的PDU及其格式
由5.3小節的描述，Link Layer有5種狀態，每種狀態下所傳輸數據的功能不盡相同，基於此，Air Interface Protocol定義出如下的PDU類型（這里只簡單列舉一下，不深入討論）：
1）Advertising channel中Advertising有關的PDU
| ADV_IND，Advertiser發送的、可被連接的、無方向的廣播數據（connectable undirected advertising event）。 ADV_DIRECT_IND，Advertiser發送的、可被連接的、單向廣播數據（connectable directed advertising event）。 ADV_NONCONN_IND，Advertiser發送的、不可被連接的、無方向的廣播數據（non-connectable undirected advertising event）。 ADV_SCAN_IND，Advertiser發送的、可接受SCAN_REQ請求的、無方向的廣播數據（scannable undirected advertising event）。 |
2）Advertising channel中Scanning有關的PDU
| SCAN_REQ，Scanner發送的、向Advertiser請求額外信息的數據包（一般需要在收到ADV_SCAN_IND后才可發送）。 SCAN_RSP，Advertiser發送的、響應SCAN_REQ請求的數據包。 |
3）Advertising channel中Initialing有關的PDU
| CONNECT_REQ，Initiater發起的、請求建立連接的數據包。 |
4）Data channel中LL data有關的PDU
| 已連接的雙方進行數據通信所用的PDU，有效的payload長度為0~251bytes。 |
5）Data channel中LL control有關的PDU
| 用於管理、維護、更新已連接的數據通道的PDU，包括： LL_CHANNEL_MAP_REQ，請求更改所使用的Physical Channel的數據包； LL_TERMINATE_IND，告知對方此次連接即將結束，以及結束的原因； 等等。 |
5.4.3 以白名單（White List）的形式定義Link Layer的數據過濾機制
主要針對廣播通道，因為隨着通信設備的增多，空中的廣播數據將會呈幾何級的增長，為了避免資源的浪費（特別是BLE Host），有必要在Link Layer過濾掉一些數據包，例如根據藍牙地址，過濾掉不是給自己的packet。
5.4.4 執行廣播通道上實際的packet收發操作
上層軟件只需要定義一些參數，例如：
| Advertising State下的Advertising Channel的選擇、Advertising的間隔、Advertising PDU的類型等； Scanning State/Initialing State下的scanWindow、scanInterval等。 |
Link Layer將會自動發送或者接收數據包。
5.4.5 定義連接建立的方式及過之后的應答、流控等機制
具體不再詳細描述。
5.5 Link Layer Control
經過Air Interface Protocol的抽象，BLE實體已經具備廣播通信、點對點連接的建立和釋放、點對點通信等基本的能力。除此之外，Link Layer又抽象出來一個鏈路控制協議（Link Layer Control），用於管理、控制兩個Link Layer實體之間所建立的這個Connection，主要功能包括：
| 更新Connection相關的參數，如transmitWindowSize、transmitWindowOffset、connInterval等等（具體意義這里不再詳述）； 更新該連接所使用的跳頻圖譜（使用哪些Physical Channels）； 執行鏈路加密（Encryption）有關的過程。 |
6. HCI
定義Host和Controller（通常是兩顆IC）之間的通信協議，可基於Uart、USB等物理介質，對理解藍牙協議來說，是無關緊要的，這里暫不介紹。
7. L2CAP Protocol
7.1 功能介紹
經過Link Layer的抽象之后，兩個BLE設備之間可存在兩條邏輯上的數據通道：一條是無連接的廣播通道，天高任鳥飛；另一條是基於連接的數據通道，是一個點對點（Master對Slave）的邏輯通道。
廣播通道暫且不表，這個數據通道（后面簡稱邏輯通道，Logical Channel），要怎么使用，還需要一番思索，例如：
| Logical Channel只有一條，而要利用它傳輸數據的上層應用卻不止一個（例如圖片1中的ATT和SMP），怎么復用？ Logical Channel所能傳輸的有效payload長度最大只有251bytes，怎是否意味着上層應用每次只能傳輸少於這個長度的數據？（顯然不能！） Logical Channel僅提供了簡單的應答和流控機制，如果傳輸的數據出錯怎么辦？ 等等… |
以上問題，都是由L2CAP，一個介於應用程序（Profile、Application等）和Link Layer之間的protocol，負責回答，這也是它的縮寫（Logical Link Control and Adaptation Protocol）的意義所在。它提供的功能主要包括：
| Protocol/channel multiplexing，協議/通道的多路復用； Segmentation and reassembly，上層應用數據（L2CAP Service Data Units，SDUs）的分割（和重組），生成協議數據單元（L2CAP Packet Data Units，PDUs），以滿足用戶數據傳輸對延時的要求，並便於后續的重傳、流控等機制的實現； Flow control per L2CAP channel，基於L2CAP Channel的流控機制； Error control and retransmissions，錯誤控制和重傳機制； Support for Streaming，支持流式傳輸（如音頻、視頻等，不需要重傳或者只需要有限重傳）； Fragmentation and Recombination，協議數據單元（PDUs）的分片（和重組），生成符合Link Layer傳輸要求的數據片（長度不超過251，具體可參考5.4.1中有關的介紹）； Quality of Service，QoS的支持。 |
鑒於篇幅問題，本文重點介紹有利用理解上層協議（ATT、GATT等）的“Protocol/channel multiplexing”功能，其它部分會在后續L2CAP的分析文章中重點說明。
7.2 Protocol/channel multiplexing
所謂的multiplexing（多路復用），還是很好理解的：
| 可用於傳輸用戶數據的邏輯鏈路只有一條，而L2CAP需要服務的上層Profile和Application的數目，肯定遠不止這個數量。因此，需要使用多路復用的手段，將這些用戶數據map到有限的鏈路資源上去。 |
至於multiplexing的手段，簡單又直接（稱的上“協議”的標配）：
| 數據發送時，將用戶數據分割為一定長度的數據包（L2CAP Packet Data Units，PDUs），加上一個包含特定“ID”的header后，通過邏輯鏈路發送出去。 數據接收時，從邏輯鏈路接收數據，解析其中的“ID”，並以此判斷需要將數據轉發給哪個應用。 |
這里所說的ID，就是多路復用的手段，L2CAP提供兩種復用手段：
7.2.1 基於連接的方法（這里的連接為L2CAP connection，不要和Link Layer的connection混淆了）
這里的連接，是指基於L2CAP的應用程序，在通信之前，先建立一個基於Logical Channel的虛擬通道（稱作L2CAP channel，和TCP/IP中的端口類似）。L2CAP會為這個通道分配一個編號，稱作channel ID（簡稱CID）。
L2CAP channel建立之后，就可以把CID放到數據包的header中，以達到multiplexing的目的。這些基於CID實現的多路復用，就稱作channel multiplexing（基於通道的多路復用）。
那CID是怎么確定的呢？有一些固定用途的L2CAP Channel，其CID是固定值，另外一些則是動態分配的，具體如下：
圖片3 BLE CID分配
有關CID的具體數值可參考：Core_v4.2.pdf, Volume 3, Part A - Logical Link Control and Adaptation Protocol Specification
7.2.2 無連接的方法
另外，為了提高數據傳輸的效率，方便廣播通信等應用場景，L2CAP在提供基於連接的通信機制之外，也提供了無連接的數據傳輸方法。基於這種方法，CID不存在了，取而代之的是一個稱作Protocol/Service Multiplexer(PSM)的字段。
這種多路復用的手段則成為Protocol multiplexing（基於協議的多路復用）。
由於Protocol multiplexing只允許在BR/EDR controller中使用，本文就不再詳細介紹了。
8. Attribute Protocol
由上面章節的描述可知，在BLE協議棧中：Physical Layer負責提供一系列的Physical Channel；基於這些Physical Channel，Link Layer可在兩個設備之間建立用於點對點通信的Logical Channel；而L2CAP則將這個Logical Channel換分為一個個的L2CAP Channel，以便提供應用程序級別的通道復用。到此之后，基本協議棧已經構建完畢，應用程序已經可以基於L2CAP歡快的run起來了。
談起應用程序，就不得不說BLE的初衷----物聯網。物聯網中傳輸的數據和傳統的互聯網有什么區別呢？拋開其它不談，物聯網中最重要、最廣泛的一類應用是：信息的采集。
| 這些信息往往都很簡單，如溫度、濕度、速度、位置信息、電量、水壓、等等。 采集的過程也很簡單，節點設備定時的向中心設備匯報信息數據，或者，中心設備在需要的時候主動查詢。 |
基於信息采集的需求，BLE抽象出一個協議：Attribute protocol，該協議將這些“信息”以“Attribute（屬性）”的形式抽象出來，並提供一些方法，供遠端設備（remote device）讀取、修改這些屬性的值（Attribute value）。
Attribute Protocol的主要思路包括：
1）基於L2CAP，使用固定的Channel ID（0x004，具體可參考“圖片3”）。
2）采用client-server的形式。提供信息（以后都稱作Attribute）的一方稱作ATT server（一般是那些傳感器節點），訪問信息的一方稱作ATT client。
3）一個Attribute由Attribute Type、Attribute Handle和Attribute Value組成。
| Attribute Type用於標示Attribute的類型，類似於我們常說的“溫度”、“濕度”等人類可識別的術語，不過與人類術語不同的是，Attribute Type使用UUID（Universally Unique IDentifier，16-bit、32-bit或者128-bit的數值）區分。 Attribute Handle是一個16-bit的數值，用作唯一識別Attribute server上的所有Attribute。Attribute Handle的存在有如下意義： Attribute Value代表Attribute的值，可以是任何固定長度或者可變長度的octet array（理解為字節類型的數組即可）。 |
4）Attribute可以定義一些權限（Permissions），以便server控制client的訪問行為，包括：
| 訪問有關的權限（access permissions），Readable、Writeable以及Readable and writable； 加密有關的權限（encryption permissions），Encryption required和No encryption required； 認證有關的權限（authentication permissions），Authentication Required和No Authentication Required； 授權有關的權限（authorization permissions），Authorization Required和No Authorization Required。 |
5）根據所定義的Attribute PDU的不同，client可以對server有多種訪問方式，包括：
| Find Information，獲取Attribute type和Attribute Handle的對應關系； Reading Attributes，有Read by type、Read by handle、Read by blob（只讀取部分信息）、Read Multiple（讀取多個handle的value）等方式； Writing Attributes，包括需要應答的writing、不需要應答的writing等。 |
9. Generic Attribute Profile
9.1 功能介紹
ATT之所以稱作“protocol”，是因為它還比較抽象，僅僅定義了一套機制，允許client和server通過Attribute的形式共享信息。而具體共享哪些信息，ATT並不關心，這是GATT（Generic Attribute Profile）的主場。
GATT相對ATT只多了一個‘G‘，但含義卻大不同，因為GATT是一個profile（更准確的說是profile framework）。
在藍牙協議中，profile一直是一個比較抽象的概念，我們可以將其理解為“應用場景、功能、使用方式”都被規定好的Application。傳統的BR/EDR如此，BLE更甚。上面我們講過，BLE很大一部分的應用場景是信息（Attribute）的共享，因此，BLE協議棧基於Attribute Protocol，定義了一個稱作GATT（Generic Attribute）的profile framework（它本身也是一個profile），用於提供通用的、信息的存儲和共享等功能。
9.2 層次結構
作為一個Profile framework，GATT profile提出了如下的層次結構：
圖片4 GATT Profile hierarchy
由上面圖片可知，GATT profile的層次結構依次是：Profile—>Service—>characteristic。
“Profile”是基於GATT所派生出的真正的Profile，位於GATT Profile hierarchy的最頂層，由一個或者多個和某一應用場景有關的Service組成。
一個Service包含一個或者多個Characteristic（特征），也可以通過Include的方式，包含其它Service。
Characteristic則是GATT profile中最基本的數據單位，由一個Properties、一個Value、一個或者多個Descriptor組成。
Characteristic Properties定義了characteristic的Value如何被使用，以及characteristic的Descriptor如何被訪問。
Characteristic Value是特征的實際值，例如一個溫度特征，其Characteristic Value就是溫度值就。
Characteristic Descriptor則保存了一些和Characteristic Value相關的信息（比較抽象，后續文章會根據實例做進一步的理解）。
以上除“Profile”外的每一個定義，Service、Characteristic、Characteristic Properties、Characteristic Value、Characteristic Descriptor等等，都是作為一個Attribute存在的，具備第8章所描述的Attribute的所有特征：Attribute
Handle、Attribute Types、Attribute Value和AttributePermissions。
9.3 重要的思考
藍牙4.0之后所引入的GATT profile，是一個非常有“心計”的profile，其中有三點，需要我們重點關注：
| 1）基於GATT架構，Application的存在形式，不再是單一的Profile，很多簡單的應用場景，可以直接以Service的形式存在（profile的概念隱藏在了GATT中），這大大簡化了一些傳感器節點的設計復雜度。 2）仔細瞅一下圖片4中的Service，然后回憶一下藍牙BR/EDR中的服務發現協議（Service Discover Protocol，SDP）中的“Service”，是否有什么關聯？你猜對了，非常有關聯，在存在GATT的實現中，SDP就沒有存在的必要了。Service也是一個普通的Generic Attribute。也正是因為這樣的抽象，才使得以往藍牙協議中的“Service”實例化了。 3）所謂的“Service”實例化，指的是，任何一個profile，都是由service和對應的profile功能組成。 |
10. Security Manager（SM）
Security Manager負責BLE通信中有關安全的內容（毫無疑問，在物聯網時代，安全變得更重要，誰也不想卧室的燈在深夜的時候會無緣無故的亮吧），包括配對（pairing,）、認證（authentication）和加密（encryption）等過程。
該部分的內容比較獨立，這里先不過多介紹，后面會有單獨的分析文章。
11. Generic Access Profile（GAP）
上面7到10章的內容，都是和基於連接的data channel有關，至於無連接的advertising channel，以及連接建立的過程，好像被我們忽略了。雖然Link Layer已經做出了定義（具體可參考第5章的介紹），但它們並沒有體現到Application（或者Profile）層面，畢竟Link layer太底層了。
因此，BLE協議棧定義了一個稱作Generic Access（通用訪問）的profile，以實現如下功能：
1）定義GAP層的藍牙設備角色（role）
| 和5.3中的Link Layer的role類似，只不過GAP層的role更接近用戶（可以等同於從用戶的角度看到的藍牙設備的role），包括： Broadcaster Role，設備正在發送advertising events； Observer Role，設備正在接收advertising events； Peripheral Role，設備接受Link Layer連接（對應Link Layer的slave角色）； Central Role，設備發起Link Layer連接（對應Link Layer的master角色）。 |
2）定義GAP層的、用於實現各種通信的操作模式（Operational Mode）和過程（Procedures），包括：
| Broadcast mode and observation procedure，實現單向的、無連接的通信方式； Discovery modes and procedures，實現藍牙設備的發現操作； Connection modes and procedures，實現藍牙設備的連接操作； Bonding modes and procedures，實現藍牙設備的配對操作。 |
3）定義User Interface有關的藍牙參數，包括：
| 藍牙地址（Bluetooth Device Address）； 藍牙名稱（Bluetooth Device Name）； 藍牙的pincode（Bluetooth Passkey）； 藍牙的class（Class of Device，和發射功率有關）； 等等。 |
4）Security有關的定義，暫不介紹
12. Applications
暫不介紹了，后續其它文章會結合某些Profile及應用場景的室例，作進一步分析。
原創文章，轉發處蝸窩科技，www.wowotech.net。