筆者在車聯網行業任職HMI視覺設計師，由于HMI設計發展的較晚，所以基本上在開始進入到這個領域的人，大多來自于互聯網行業。由于互聯網行業發展的比較早，形成了一套成熟的工作流程，即：分工明確的遞進式協作：交互設計師要等到產品PRD評審結束才開始介入需求，然后交付黑白線框稿等給到視覺設計師繼續跟進。這種工作模式可以讓每個人在自己的崗位上做得更加專業，成為垂直領域的專家。在車聯網行業發展初期的時候，這種工作模式對于傳統行業的來講，比較新穎、高效，所以在一定程度上促進了行業發展，但汽車操作系統的設計還是有很多不同于互聯網設計的地方，所以本文旨在討論HMI工作流程，如何分工，怎樣高效的進行設計協同，以期望探索更適合車聯網行業的設計協同方案，希望對你可以有所助益。
對于HMI設計來講，需要了解很多專業知識，比如：屏幕、硬件、三電、法規……這些東西都會影響到設計的視覺表達，所以設計協同就顯得尤為重要，那么什么是設計協同呢？指設計師在設計之初，即可開啟分享與協作，讓協同者盡可能早的參與到設計中，通過提供一系列工具，讓協同者有更加友好地體驗，保證每個人都可以準確找到相應需求的內容，并且快速提出修改意見與反饋。簡單地講，就是讓每個人都參與到設計過程中，以使最終的結果能夠滿足用戶的需求。
從產品功能邏輯層面來講，HMI設計的“復雜度”是具有有一定的“限制性”的，即保證安全第一，過度復雜的設計必然影響駕駛和乘坐人的安全。所以對于設計，是需要進行全方位評估的，必然會涉及到不同的角色。同時隨著項目的不斷發展，設計團隊也在不斷壯大，設計師之間的協作也越來越多，相應的溝通和協作成本就會不斷增加。如何才能更高效的合作，并把設計質量和一致性做得更好，是我們需要解決的問題。所以設計協同的最終目的是為了解決問題，做正確的事，讓設計師做真正該做的事情。
讓設計師專注于真正重要的事情，而不是把精力放在可以自動化處理的事情上。對所有人員的工作進行集中化管理，所有人員基于統一數據源進行協作。
通過構建團隊資產庫，比如設計規范、控件組件庫等，通過建立健全設計規范，讓數據沉淀，一方面讓設計師的設計有據可依，提升設計的專業性，另一方面，減少因為人員變動造成的數據丟失。
在設計之初，就讓協同者參與到設計之中，保證每個人都可以準確的找到他們的需求內容，并快速提出修改意見與反饋，讓設計師更有針對性的解決問題，讓設計師無需做重復性的工作。
在HMI設計的工作流程中，主要涉及到的角色有產品經理、交互設計師、視覺設計師、研發工程師、測試工程師、項目經理。
不同角色主要工作內容是：
圍繞著HMI設計的整個工作流程是：
產品經理確認需求，輸出PRD文檔；交互設計師收到PRD文檔以后，基于需求，梳理功能，完善業務流程，完成交互文檔的制作，輸出UE文檔；視覺設計師在收到UE文檔以后，針對交互文檔中的流程頁面，進行視覺設計，輸出UI文件給到研發同學；研發同學根據UI文件和交互文檔進行代碼化，完成以后進入測試環節，測試工程師和產品、交互、視覺都需要參與到測試過程中，當完成測試工作以后進行發版。
涉及角色
自己、設計師小團隊。
痛點
工作中很多重復的內容，比如：Button、List等使用的地方很多，如果每個元素都重新繪制，勢必會投入很多時間，同時因為人為因素，難免會出現不統一的地方。那么怎么樣解決這個問題呢？
協同方式
當團隊初期發展的時候，或者整個團隊只有少數幾個設計師的時候，通過匯總通用樣式和組件，形成視覺指導Guide，方便通用樣式的復用，減少重復工作量，達到快速完成視覺設計的目的。
優點
通過樣式庫和控件組件庫的搭建，形成了一定的共有樣式，方便復用，有效的減少了重復工作量。
缺點
由于控件組件庫是在設計進行到一定程度以后提煉的，會存在滯后性，并且隨著設計工作越來越往后，會發現前期的控件組件存在不合適的地方，需要對之前的工作進行修正。
涉及角色
設計團隊內部。
痛點
當公司發展到一定的階段：
當設計團隊越來越大，大家分工越來越細，想法越來越多，就會發現，復制粘貼guide的方式，已經無法滿足團隊的發展了，經常出現組件不能滿足使用的情況，或者是組件相似但不知道怎么選擇等問題。
同時因為沒有統一的流程，會發現不同的業務對于同一功能交互邏輯的不統一現象，比如：搜索是很多業務都會使用的功能，因為沒有統一定義，有的業務會采用即時搜索模式，有的業務必須點擊搜索以后才可以進行搜索，并且這種問題，前期很難發現，只有到了中后期走查的時候才會發現。
所以在后期會針對每一個差異點進行統一，需要全流程重新來一遍，費時費力。那么怎么才可以避免這種情況的發生呢？答案就是構建設計系統。
協同方式
設計系統不同于guide的地方是：樣式，控件組件只是設計系統中的兩個組成部分，除此以外，設計系統還包括了一系列的標準來指導設計。比如：圖標、動效、音效等。這些標準記錄了設計團隊內達成一致的一系列的決定，比如如何選擇控件，如何在不同的控件中選擇。正是這些標準才確保了設計方案不僅僅只解決一個問題，而是可以被復用的。這些標準也是為什么用戶能獲得一致的體驗的原因。
通過設計系統的建立，讓設計規?；?，繼而進一步強化車機系統的統一性，同時為設計師在做設計時提供一個很好的指導方向，讓團隊內不同成員的設計在風格上保持一致，提升設計團隊的專業度。關于設計系統的建立本文就不再過多描述，后續會出專門的文章進行詳述，這里主要是講述設計系統搭建以后的協同方式。
設計系統的搭建需要專門的人或者團隊進行，當搭建完成以后，需要輸出的資源有：UE控件組件庫、顏色/字體樣式庫、UI控件組件庫、UI控件組件說明文檔。這些資源各有什么用呢，接下來進行詳細說明：
UE控件組件庫
提供給交互設計師，基于提供的內容，交互可以快速的構建界面、交互和流程等，就像搭樂高一樣?？梢钥焖俚臉嫿ㄒ恍┊a品原型或者是實驗性的功能，來進行測試以快速驗證想法。
顏色/字體樣式庫、UI控件組件庫
提供給UI設計師，形式可以是Sketch Libraries，一方面方便設計師調用，使不同的設計師的設計變得更加統一，且更加可預測，同時組件也可以讓設計師更多的時間專注于如何構建更好的用戶體驗，而不是去糾結于樣式的調整。
UI控件組件說明文檔
提供給研發，可以是pdf之類的文檔形式，主要是詳細的描述每一個組件的各種屬性，以及里面包含的交互邏輯等，幫助研發搭建起研發自己的底層代碼平臺。
那么這些資源和不同的角色之間是怎么協作呢？UE控件組件庫不需要常常更新，完成后給到交互設計團隊，供交互設計師使用搭建UE文檔。在項目開始之前，負責設計系統的UI團隊進行顏色/字體樣式庫、UI控件組件庫制作，完成以后分享到團隊內，供業務設計師使用進行界面設計，同時進行UI控件組件說明文檔的編撰，完成以后提供給相應的平臺研發，讓平臺研發進行組件代碼化。當代碼實現以后進行走查，檢查是否按照UI準確的實現。當業務設計師完成了業務的界面設計以后，進行評審，輸出給對應的業務研發，研發對于相應的視覺界面進行對應的代碼化，使用組件的地方直接調用平臺代碼，剩下的由業務研發進行代碼化。
優點
組件由專門的UI設計師和研發團隊負責，當出現設計變更以后，業務設計師可以快速通過組件庫更新最新的視覺樣式，同時和平臺研發對接，進行代碼修改，而不需要每個業務研發單獨修改，大大減少了跨部門的協作溝通成本。
缺點
團隊內需要專門的設計師構建設計系統并負責日常維護。
涉及角色
設計、交互團隊。
痛點
由于需求的不確定性，以及車聯網項目周期較長等特點，會出現需求經常變更的情況，那么交互就需要不停的更新交互文檔，UI也需要不停的輸出視覺文檔，往往一個項目結束以后，會有幾十份甚至上百份的設計文檔的情況出現。
協同方式
隨著云端化辦公軟件Figma的興起，為多角色協作提供了可能性，目前主流的工具有：Figma、MasterGo、Pixso、即時設計等在線軟件。
設計文件現在是一個鏈接，這意味著：
UI設計師不必再等到交互完成評審，輸出交互文檔以后進行視覺設計，交互和設計完全可以合二為一，輸出一份高保真交互流程文檔，并且輸出的文檔可以供研發直接瀏覽器查看，而不需要像之前一樣，不停的進行設計資源的輸出。極大的節省了設計師輸出時間。優化了協作工作流。
優點
協作設計，云端辦公，多角色參與。
一鍵獲取文件，不需要通過其他平臺轉化，步驟簡單；自動生成代碼與標注。設計稿修改后自動更新，無需重復下載。
缺點
云端保存，會有數據泄露的風險。
必須在線操作。
涉及角色
UE、UI、研發。
痛點
由于公司發展，業務線增加了很多適配線，這塊的工作基本上屬于：把已有的UI適配到另一個屏幕尺寸下，需要設計的地方不太多，需要花更多的時間去重新按照最新的屏幕尺寸搭建一遍UI界面，屬于用時間換業績，為了達到這個目標，可以采取的方式大致分為兩種：
第一種是增加更多的人力，不管是招更多的人，還是增加更多的供應商人員，都會增加業務支出，并且由于業務無法一直保證飽和，所以會出現一段時間忙的要命，招了很多人員，過了這段時間，業務不太多了，大家都閑了下來，但是開支還是必要的，所以這算是一種沒有辦法的辦法，對于團隊或是公司來講，并不可持續。
另外一種方式就是重新梳理工作流，減少一些重復無意義的工作，比如像是系統設置等瀑布流式的界面，不同車型下的區別只來自于功能的有無，界面上并無太大區別，這里所說的工作，不僅僅指設計師的界面設計工作，同時也包括了研發同學的研發落地工作，同時因為研發同學的適配，也會造成測試走查環節，這些都是一些重復性的工作量，所以是否有一種更好的協作方式可以避免這種情況的發生呢？
答案就是我們接下來要講的一種全新的工作模式：C2D2C模式。
協同方式
由于設計團隊在早期的發展中，積累了大量的設計資產。這些設計資產的沉淀就是設計標準化的基礎，將設計資產轉為封裝好的代碼組件，也就是C2D的過程。然后將封裝好的組件通過低代碼平臺進行屬性配置、搭建頁面、布局調整實現頁面的設計就是 D2C 的過程。通過平臺設定交互行為和綁定后臺數據，完成整個系統，最后再進行站點發布，就實現了 C2D2C 的完整流程。
C2D2C（Code to design to design）的模式，簡單講就是研發同學把設計資產通過設計標準化和研發工業化的方式完成代碼化，然后讓設計師調用已經代碼化的設計資產進行設計工作，這樣子當設計師完成了界面設計的時候，相當于同時完成了前端開發，接下來研發同學只需要根據拿到的界面添加簡單的邏輯就算完成了研發工作，實現中后臺設計研發流程的整體提效。
優點
由于樣式、組件已經完成了代碼化，那么在適配工作中，控件組件化高的界面就可以直接生成代碼，不需要設計師重復設計，同時由于減少了設計師和研發的參與，節省了大量溝通成本，也減少了很多因為人為因素而產生的bug。
由于設計師減少了重復工作量，可以有更多的時間集中在視覺表現上，有效提升了設計輸出的質量，保證了產品的設計感。
對于大量適配項目的團隊，可以由設計師直接配置項目組件，無需經過研發，減少出錯概率，極大提升工作效率。
缺點
前期需要研發同學代碼化基礎控件，所以需要投入人力、精力進行前期的工作。
由于控件提前進行了代碼化，后續可能會出現無法滿足業務需求等情況出現，所以需要有人及時對代碼進行維護更新。
涉及角色
產品、UE、UI、研發、測試。
痛點
基于上面講述的C2D2C模式，已經完成了一個共享平臺的搭建，由于配置需要研發的參與，所以始終需要研發同學作為集成人員，并不利于其他角色的使用，那么怎么樣可以讓產品同學，設計同學，或者說是普通用戶使用呢？
協同方式
一個優秀的共享平臺是需要所有人都可以在其中使用的，所以，當公司或者團隊發展到穩定階段，我們需要重構工作流，以需求為導向，搭建全員工作平臺，基于設計師和研發搭建的平臺基礎上，提煉需求，強化個性化和定制化，滿足品牌產品的個性化需求，具體來講，就是把UI界面中元素提煉出相應的功能，生成功能清單，通過選擇不同的功能，生成相對應的界面。
當完整的共享平臺搭建完成以后，團隊中的每個角色的工作內容都發生了變化，產品的工作是構建更多的需求，交互設計師的工作是構建更多的交互形式，產品架構，UI設計師的工作是設計更多更好的界面布局，視覺表現，然后研發把上述內容通過代碼匯總進我們的需求池中，擴展我們的平臺豐富度。
HMI設計工作，就變成了：客戶在我們的配置面板中選擇需要的需求，喜歡的布局，想要的視覺，點擊完成，就可以即刻看到高度定制化的一套系統。
優點
讓每個人回歸工作的本質，不需要為了一些重復的繁雜的內容而疲于奔命，做更有價值的工作，實現工作的價值
賦能行業，可以滿足車企定制化的需求，提供車企一套完整的車機系統解決方案。
缺點
投入大，對于小體量的業務來講短期無法創造價值。
對于現在的行業環境，增速提效已經達成了基本共識，設計協同就成了一個大課題，但是不同的企業，不同的團隊面對的具體問題不一樣，可使用的資源也不太一樣，那么采用哪種協同方式并無定式，需要根據實際情況，進行具體分析，畢竟效率的提升是為了創造最大的價值。我們所有的努力最終目的是為了解決問題，做正確的事。
作者：菘藍C 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
最近 AI 繪畫越來越成熟，能做的事情也越來越多，很多同學經常在群里或私信中問我關于對 AI 繪畫的觀點和看法，以及 AI 繪畫對 UI 設計師有什么影響，所以今天獨立寫一篇內容，來具體討論下這個話題。
首先輸出一個太長不看版的結論：
AI 繪圖可以協作 UI 設計師更快地完成一些邊角料工作，但無法取代 UI 設計師的核心價值，不會對 UI 崗位造成大范圍沖擊……
那下面就來具體討論吧！
相信大家都有這種感覺，2022年開始，AI 繪畫突然就毫無征兆地火起來了，用火遍大街小巷來形容一點也不過分，當我走在地鐵和機場等公共場所都能隨處可見 AI 繪畫作品的展示。
其實AI繪畫這個技術一直都有，比如 OpenAi 的 Dall·E，但真正產生質變的時候是從 2022 年2月 Disco Diffusion 發布以后，讓 AI 繪畫的能力得到了質的飛躍。
隨后一些使用它創作的作品開始流通，且在美國的某數碼繪畫比賽中由 AI 作品獲得冠軍，徹底吸引了公眾的視線。隨后，一系列新的 AI 繪畫工具開始開發和上線，包括目前為大家所熟知的 Stable Diffusion 和 Midjourney、NovelAI。
從上線到現在不到1年的時間里，這些軟件都完成了多次的大版本更新和迭代，讓 AI 繪圖的能力越來越強，準確性越來越高，我們甚至很難想象再過五年以后會發展到什么可怕的地步。
除了目前已經正式發布的繪圖工具外，還有很多新的產品正在熱火朝天的開發階段，如巨頭 Adobe 的 Firefly ，Stability 的新產品 REimagine 等。
產品的多樣性，差異化，以及本身的進化，為視覺設計和藝術創作提供了全方位的支持和可能性，也對相關行業產生了巨大的沖擊。
我們不得不面臨一個很現實的問題，AI 是不是會取代大多數插畫、設計師？
這是很有可能的，不管是從網上，還是認識的朋友學員那邊獲得的反饋，高度依賴插畫、場景建模的行業，都在受到 AI 的劇烈沖擊，有的將接入 AI 制定成 KPI 要求全團隊 ALL IN，有的在跑通AI工作流以后直接啟動裁員進程或關閉外包渠道。
AI 的出現對于美術行業，就像燃油車出現對馬車的革命，照相機的出現對手繪的沖擊，是非常值得思考的，因為我們或多或少也身在其中。
因為在產品方向，Midjourney 已經可以通過指令生成用戶界面了，試用 ChatGPT-4 已經可以用指令10秒創建一個可以操作和訪問的網頁，看起來未來已經提前朝我們走來。
所以 UI 設計師是不是很快也要被取代直至消亡？
相信有長期看我們公眾號分享和公開課的同學，應該知道我一直在強調，界面對于 UI 設計師的工作只是必要但占比并不高的部分，如果認為我們的工作價值僅僅是最后產出的視覺界面，那淘汰多數 UI 設計師的方式根本輪不到 AI 來動手，按目前市面流通的前端框架和組件庫就夠了。
之所以有大量的現成素材、模版、組件庫，還不能淘汰 UI 設計師，原因就是整個項目設計過程中所需的變通、靈活性、抽象思維要求，是它們完全無法覆蓋的。
一個稍微成熟點的項目設計圖產出和交付，是需要經過下面這個流程的：
從這個簡化的流程模型里，大家要明白專業的設計稿輸出是有 “黑箱” 加工步驟的，要在這階段，對工作的需求進行大量的研究、分析，并做出決策確定出設計目標或者方案。
在現代設計團隊中，直接拿到需求就做設計稿的模式是很難產出高質量設計的，或者應對更專業嚴格的要求。設計師需要在這個階段投入大量精力，盡可能提升設計產生的價值，減少出現不良影響的風險，以及 —— 說服團隊接受當前的設計思路。
而這是 AI 繪圖完全無法實現的東西，我們使用 AI 繪畫僅僅是輸入做好的決策，讓它生成結果，但沒辦法通過輸入業務、需求的疑問，讓它給出一個有詳盡理由和邏輯的設計成果。
可能有同學會下意識的想到，那我們用 ChatGPT 這樣的工具，提出問題，讓它自己給出解答并直接給出繪圖指令操作繪圖工具生成界面，順帶再自己開發號產品，不就行了，一個人就是一個團隊，人人都是產品經理終于實現……
這個業務模型非常合理，看起來似乎完全可以實現。但真的有項目經驗的自己去思考一下，就會發現中間存在的問題無窮無盡。
第一點，“黑箱” 是給出問題答案的分析處理過程，ChatGPT 再怎么神通廣大，也需要我們去給到有效的問題和需求，它才能給你有用的答案。那么問題來了，你怎么和它描述具體的業務需求、產品需求、體驗問題和各類用戶痛點？
以上一篇分享為例，我們優化 Stable Diffusion 的輸入框，光和 AI 說優化輸入框約等于廢話，你得告訴它怎么優化，那怎么優化這件事不就是得去找出原產品問題的缺陷嘛？如果我自己去找完缺陷了，那最后畫那點圖例的工作量有什么了不起的呢？
更何況一些復雜的業務，尤其是B端行業，完全無法用簡單的幾句話描述清楚，要搭配各種框架圖和流程圖，光開一個業務評審和培訓的會議，可能就要花非常長的時間。
所以該用什么形式去和 AI 描述這些抽象的信息內容？
第二點，還是以上面案例為例，在這個輸入框中，包含很多交互的小細節，輸入框內光標的操作，鍵盤的操作邊界在哪里，輸入文字后提示關聯的邏輯，不同輸入指令類型要區分怎么和 AI 描述，全都成為問題。
所以光生成一個界面是沒有意義的，這個界面做的再好看再美觀，也不代表它有真實落地的可能，只是完成了設計工作的一小部分而已。所以看到這里是不是感覺很熟悉？和我們在追波上看到的各類飛機稿案例沒有太大的區別。
第三點，上面的模型只是一個非常簡化的流程，有過真實的項目經驗就應該知道流程中會有反復拉鋸的事件，需求的變動，設計稿的修改，方案的調整，這些零碎的工作去和 AI 提，你會發現有輸入問題的時間，可能設計早就修改完了。
尤其在最終的標注和切圖環節，涉及到設計時對設計稿的制定，標注和切圖實際上有很多主觀性和經驗化、場景化的輸出要求，它需要設計師在經歷整個項目流程后自行判斷。
除了以上三點，還有很多其它的問題難以解決，而這些問題的總和，決定了沒有出現真正的人工智能之前，使用 AI 來輸出 UI 界面是一件不靠譜的事情。
只有視覺領域沒有前期那么多條條框框，也沒有后續一系列交付和維護需求的場景，才是 AI 真正產生價值和影響的方向。
用 AI 做 UI 設計不靠譜，但是不代表對UI設計師沒價值。這話聽著可能挺拗口的，但事實如此，因為在國內的UI設計環境中，UI 設計師的工作內容往往不局限于產品設計一個領域內。
還包含下面這些操作：
我相信大多數 UI 設計師做平面和運營設計的感受就和上墳的狀態是一樣的，上墳起碼是懷有對先人獻花，做平面和運營設計只會產生對自己深深的唾棄……
所以 AI 的出現可以很好的處理這部分的需求，比如一些雖然用處不大，但就是甲方還是老板就是想用的 3D 風格圖標。
或者，在登陸頁用的比較濫俗的 3D 場景背景，為了這樣的東西花很長的時間去建模和渲染，投入和收益是完全不成正比的。所幸使用 AI 也可以幫助我們非常短的時間內獲取想要的效果。
還有就是各類運營設計圖，互聯網運營設計和一般的品牌廣告視覺比較起來，就是對創意性的忽視，畫面并不需要埋伏大量的隱喻、內涵或故事，就是單純的應景和吸引用戶注意力，這恰恰也是 AI 最適合輸出的東西。
包括廣告 Banner、H5、啟動頁等，都可以通過 AI 快速生成一些高質量的插畫，來替代我們自己從頭開始繪制的苦惱。
所以你看，對于我們職業價值不高的這些雜活，AI 都可以很好的去完成，而且可以肯定未來可以完成得越來越好，我們就可以節省更多的時間，不管是投入精力給體驗和交互，還是準點下班，都符合我們自身的利益。
所以，UI 設計師對 AI 的態度并不是敵視和悲觀，而是要把它當作救星和幫手，把我們從運營設計的水火中拯救出來……
不僅是觀念上的調整，掌握一定的 AI 繪制技巧也是必要的，將他們融入到你正式的工作流程中，所需投入的精力也遠遠小于你從頭開始學插畫和 3D 渲染。
相信不久的將來，UI 設計師的招聘中部分要求手繪和建模的 JD，會替換成熟練使用 AI 繪圖。
作者：酸梅干超人 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
看完本篇文章，你會學到以下內容：
1，什么是彈窗？
2，彈窗的規范如何定義？
3，彈窗使用規則是什么？
4，什么是抽屜？和彈窗對比優缺點是什么？
一、什么是彈窗？
彈窗是在保留當前頁面狀態的情況下，告知用戶并承載相關操作。
思考：彈窗里面哪些構成原件可以根據業務屬性可以有可以沒有呢？
答案：標題區和操作區。
二、彈窗的規范如何定義？
1、定義彈窗的大小規范
彈窗的的大小有兩種定義方式。一種是固定大小，一種是自定義大小。需要根據自己的業務場景二選一。
彈窗寬度一般定義為三種。分別為560px，720px，960px，都是8的倍數方便記憶。尺寸并不是定死的，可以根據自身業務場景調節。
彈框固定高度會有一個最小高度200px，一個最大高度560px。在其之間的高度是由內容區的內容決定，超過最大高度560px時出滾動條。
彈窗自定義高度，只定義最大高度，隨著頁面拉升縮小，彈窗邊距不變。
2、定義彈窗內容規范
定義：標題欄操作欄高度，內容區邊距。
3、彈窗類型
彈框類型是根據使用場景區分提示彈窗，自定義彈窗兩種
彈窗優點：沒有跳出父級頁面，彈窗任務完成后仍然會留在父頁面進行操作，減少用戶操作中步驟體感
彈窗缺點：信息承載量少，信息內容過多的時候會出現上下左右滾動條，彈窗會降低用戶操作效率
三、彈窗使用規則是什么？
1、不超過兩種操作選項
假如承載的操作項比較多，建議新跳轉一個落地頁。
2、多步驟操作，選擇用頁面承載
3、盡量避免彈窗疊彈窗
第一個彈窗的內容考慮用頁面承載或者第二個彈窗是否可以用氣泡或者下拉來承載。
假設一定要疊，二級彈窗的復雜度要低于一級彈窗，滿足形式上的平衡，遵循從大到小的邏輯或者是覆蓋上級，完成任務后點“返回”返回。
四、什么是抽屜？和彈窗相比優缺點是什么？
抽屜是信息承載量和頁面比肩，又兼具彈窗的優點。
作者：鯤sky 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
看完本篇文章，你會學到以下內容：
1， 什么是表單頁？
2，表單頁設計原則
3，表單的構成
4，表單的交互
5，頁面布局
6，提升表單易用性
7，體驗衡量指標
1、采集/錄入數據信息。2、編輯數據信息。3、特殊的條件設置。后臺產品的本質是針對數據的增、刪、改、查。而增、改、查都可以用表單完成。
OA系統里面的請假申請，報銷申請，錄入員工，新建會議。教育類的創建課程。HRM系統里面發布職位以及物聯網管理系統新建設備等等。
用戶快速定位重要信息和目標選項同時文案和組件能夠準確傳達相應含義
整體表單排布有合理的交互形式；科學的信息布局和組織形式；盡可能“少操作一步”用戶在面對50和表單和500個表單的心理壓力是不一樣的。
操作前：提示和防錯。
操作中：實時反饋與糾錯
操作后：合理的保存、清空、取消、撤銷機制。
表單通常由表單標簽、表單域、提示提示、操作按鈕四部分構成。
左標簽
優點：表意明確，節約縱向空間，多用于web端
缺點：不太適用于移動端等狹長空間
頂標簽
優點：對齊舒適，節約橫向空間，多用于移動端及英文場景下。
缺點：縱向空間利用率不高
行內標簽
優點：最節省空間，多用于注冊登錄
缺點：輸入狀態標簽消失，用戶陷入迷茫
左對齊標簽
視線從標簽移動到表單域時間為500ms，這比右對齊標簽所用的時間長的多，所以更適合閱讀，用于詳情的陳列。
特點：閱讀效率高，操作效率較低；
右對齊標簽
視覺動線參差不齊，不適合高效閱讀，但適合高效操作，更適合表單填寫。
特點：閱讀效率不高，標簽指向明確，操作效率高
步驟一：根據業務已經有的字段長度定義4-5種寬度規范，建議寬度可以是8或者是40的倍數。
步驟二：根據你要搭建的表單，選用合適的規范，長度與輸入預期成正比。有人會說排出來的表單左邊沒對齊，右邊也沒對齊，其實這就是B端產品特征那就是是好用大于好看，就要給用戶一種心智那就是給你的這個長度那就是要輸入一個這么長的內容。
避免“正確的廢話”：給不到用戶任何的幫助還增加了用戶的閱讀成本。
按鈕常見位置：一般出現在頁面頂部、跟隨表單里的內容、表單內容底部、頁面底部。
按鈕閱讀順序：按鈕出現頁面右上角或右下角時，閱讀順序是從右往左，這符合pc端操作習慣以及人閱讀習慣。按鈕跟隨表單內容或在表單內容底部時，閱讀順序為從左往右，這符合人的填寫順序從上往下，從左往右。
底部按鈕右對齊：一般用在彈框，因為彈框頁面比較小，右對齊比較符合操作習慣。
底部按鈕居中：一般用在頁面中，因為右下角操作距離會有點遠，所以表單用頁面承載的話按鈕建議居中。
表單中字體全部統一采用14px。表單上下間距一般有三種，1.內容與內容間距為24px。2.內容與說明文案間距為4px。3.內容與子內容間距以及及子內容之間的間距為8px。
表單交互方式有四種。1.原位編輯；2.氣泡卡片；3.彈窗/抽屜；4.頁面跳轉。
原位編輯
編輯內容即為展示內容，容量低于5個時使用。
氣泡卡片
設置項與看板內容緊密相關時使用氣泡卡片，建議設置項低于5個。
彈窗/抽屜
設置項與看板內容可以有關聯也不可以沒有，大于三個以上的錄入項使用。
如果錄入項較多，用彈框承載出現翻頁的情況下可考慮使用抽屜。
頁面跳轉
如果容量超出了彈框/抽屜的承載量并且錄入項與看板沒有那么強的關聯性可采用頁面跳轉的方式。
頁面布局方式有四種。1.分組；2.錨點定位；3.標簽頁；4.分步驟
5.1.1標題分組
設置項超過7個；彼此間的關聯性較弱且可以分類去歸納
5.1.2卡片分組
有多個設置項，多個分類；彼此之間的關聯性更弱，分類明確
有多個分類的情況可通過錨點定位迅速找到相關信息
彼此之間沒有特定的相關性，可以獨立設置。每個設置包含了多個錄入項且使用了標題分組。
小結
當錄入項少于7個時使用基礎布局；當錄入項在7-15個時可采用標題分組，卡片分組、錨點定位布局；當錄入項大于15個時需采用標簽頁布局。
利用步驟條將大型，復雜任務拆解為多個部分，并按照相關性分組。
建議3種分組依據
1.采用必填項劃分，把必填的選項分在一起；2.采用相關性劃分；3.以操作成本劃分。把好填的簡單的表單放在前面，復雜的放在后面。
提升表單易用性方式有5種。1.信息降噪；2.清晰易讀；3.高效智能；4.防錯糾錯；5.所見即所得
場景一：當表單中大多數都是必填只有極少數非必填時
場景二：表單項非必填項比較多，可將低頻的非必填項收起
場景一：盡量采用單列布局，視覺動線流暢，不容易遺漏信息；按enter鍵換行。
場景二：如果出于業務方需要，必須在橫向添加內容，那最好有一定的分組依據。但這樣就不應該出現豎向分組，以免遺漏信息。
6.3.1根據上下文信息可以自動獲取的，無需用戶再次填寫。
例如根據手機號帶出用戶姓名；根據地址帶出郵政編碼；根據身份信息帶出生日。
6.3.2提供合適的“默認項”。
例如根據行業現狀提供常規的比例分配；根據定位把地區做默認的填充。
6.3.3提供搜索、聯想，自動顯示匹配的信息
用戶在進行輸入等操作時可以提供智能輔助，例如表單填寫時對需要錄入信息的區域提供輔助提示，通過自動補全或聯想詞來幫助用戶快速錄入信息，在保持用戶的操作自由度的情況下提效。
6.3.4 OCR識別文件內容
對于一些標準證件信息的錄入，可以通過OCR識別文件內容。當用戶上傳圖片后，運用圖像識別技術提取關鍵信息并自動填入結果。
6.4.1對于長數字，四位一空格，用來分段
例如輸入銀行卡號；充值場景下輸入手機號等
6.4.2為用戶封閉不正確道路
將超出時間選擇范圍的日期置灰。電話號、身份證錄入時只允許輸入數字同時設置字數上限。
6.4.3告訴用戶哪里錯了，而非簡單粗暴的錯誤提示
表單頁對填寫的物料內容進行映射，展示真實效果預覽，降低用戶心理的不確定性。適合對移動端、小程序、H5頁面的設置。
體驗衡量指標有4種。1.任務完成率；2.任務完成時長；3.必填項目數；4.易用度評分
7.1任務完成率
7.2任務完成時長
7.3必填項目數
結合業務場景給出最適合的必填項設定，提高用戶填寫效率。
7.4易用度評分（用戶完成某項任務的難易程度）
易用度可通過調研問卷和評分量表獲取。
作者：鯤sky 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
設計做到極致注重的就是對于細節的把控力，大廠的設計師之所以比較優秀，就是他們具備很好的細節把控力。想要提高產品設計的能力，發現設計細節和思考設計深入的能力至關重要。
最近在體驗產品的時候，發現了一些設計細節做得比較好的優秀案例，分享給大家學習一下。
分享目錄
一、Banner 輪播轉場的品牌化
二、情感化的彈窗設計
三、最小化顯示提高空間利用率
四、動態化的設置引導
五、沉浸式的活動氛圍設計
六、人性化的提示設置
七、動態感知的溫度設計
八、無處不在的廣告位開發
九、主題化的圖標設計
十、新穎的卡片式設計
一、Banner 輪播轉場的品牌化
立足于品牌做設計，才能強化自身產品的差異化。如何在更多設計場景中融入品牌基因，是設計師需要深入思考的關鍵。
最近在使用騰訊視頻 APP 時，發現首頁 Banner 圖在輪播的轉場過程中，以品牌 LOGO 造型作為轉場過度。一個小小的細節強化了用戶對于品牌的記憶度，也體現出專屬的設計差異。
二、情感化的彈窗設計
通過彈窗設計可以提高用戶操作效率，也是傳播信息（活動/廣告）最直觀的形式。但是體驗多了用戶便會開始排斥，提高彈窗的情感化設計變得尤為重要，降低用戶的排斥感才能提高彈窗的作用。
很多娛樂影視等 APP 都會有“青少年模式”彈窗提示，抖音將彈窗視覺表達融入了精美的國風插畫。也通過針對性的內容作為設置的引導，提高了用戶對“青少年模式”的深入理解，增強了體驗的積極性。
插畫的形式在彈窗設計中表現比較突出，比如嘀嗒出行 APP 將“推送通知”的彈窗設計運用插畫增強情感化表達。相較于生硬的表達方式用戶更能接受，通過營銷的文案引導用戶授權，提高了產品的感官體驗。
三、最小化顯示提高空間利用率
對于工具型產品不同用戶的操作焦點不同，更多定制化的體驗才能提高用戶的操作效率。
釘釘 APP 在協作欄目中，默認展示的各類工具可以進行收起，實現最小化顯示。用戶可以根據使用習慣和操作方式選擇收起/展開，提高了當前空間的利用率，自定義的功能設計可以提高用戶的操作體驗。
四、動態化的設置引導
為了提高用戶隱私權益，手機系統針對產品調用權限進行了阻力設計，需要用戶的授權操作。提高用戶的各類功能授權就需要設計師探索，降低用戶的排斥感和提高授權的利好政策才能獲得授權。
抖音在引導用戶開啟通知權限的設計中，采用了動態畫面的表達來強調開啟通知的利好政策，以此來攻破用戶的心理防備。相較于生硬的彈窗提示，動態的表達和引導性的文案更能拉近與用戶的距離感。
五、沉浸式的活動氛圍設計
沉浸式的體驗可以帶給用戶更好的場景感，提高用戶的參與度。在活動的設計中，不斷向游戲化和沉浸式方向加強體驗，提高活動的趣味性和強化用戶參與的積極性。
騰訊視頻在情人節的互動活動設計中，就將搶紅包的活動融入到當前的界面中，紅包雨鋪滿整個屏幕，以趣味性的形式滿足用戶心理。不隔斷與界面之間的聯系，降低活動對用戶的干擾，進而提高活動氛圍感和參與度。
六、人性化的提示設置
短視頻近些年改變了大家的生活方式和娛樂形式，也有用戶容易過度依賴進而影響休息質量。
抖音作為短視頻領域的頭部產品之一，在增強用戶體驗的同時也要起到良性的引導作用。當用戶刷短視頻一定時間后會彈窗提示休息，而提示時間用戶可以根據自己的實際情況進行設置，靈活的設置可以讓用戶合理分配時間。健康使用的引導可以讓用戶感受到產品的溫度，提高用戶體驗的認可度。
七、動態感知的溫度設計
天氣預報是用戶關注度較高的信息，對于溫度的感知可以讓我們出行更容易把控。在產品中顯示天氣情況也是一種情感化的升級，可以帶給用戶更有溫度的體驗。
利用餓了么 APP 點餐之后，首頁會顯示配送情況和當前的天氣溫度，背景以動態的天氣畫面增強視覺感知。也希望用戶可以根據天氣情況對外賣員多一份理解，加強人與人之間的寬容心，帶給用戶更強的情感化體驗。
最近在使用愛奇藝 APP 時，發現左上角的品牌位置也結合了天氣情況，結合頂部視覺區域的流體漸變，新增的天氣預報和品牌 LOGO 完美的通過動效過度。整個設計表達流暢自然，感官體驗也是非常值得學習的。
八、無處不在的廣告位開發
廣告是眾多產品實現流量變現的方式之一，廣告位的開發也是見縫插針，如何在僅有的空間增加更多廣告位，產品設計師也在不斷探索。
最近在使用騰訊視頻 APP 時，進入到個人中心時會默認有個下拉廣告。這個見縫插針的廣告位新增，對于設計師來說讓我感受到了廣告的無處不在，不過對于用戶來說是否會心生排斥感得通過數據去驗證。但是作為產品設計師這也是一個啟發，將有限的空間進行深度開發，還不會影響已有的結構布局，這也是一個啟發性的案例。
九、主題化的圖標設計
圖標是產品中不可或缺的存在，圖標設計的研究也是設計師需要重點對待的技能范圍。精美的圖標不僅可以提高產品的感官體驗，也能吸引用戶的關注度，進而提高業務模塊的點擊欲。
最近在使用順豐速運小程序時，寄快遞欄目的各業務入口圖標設計非常引人注目，結合主題化的圖標設計突出了活動傳播力度。對于工具型產品而言，強化氛圍感可以打破用戶原有的認知，不僅可以突出活動主題，也能強化用戶對產品的視覺感知。
十、新穎的卡片式設計
卡片式設計已經流行好幾年了，目前依然是非常普及的 UI 設計趨勢之一。如何進一步強化卡片式設計的創新度，我們需要不斷的嘗試和總結。
嘩哩嘩哩 APP 的創作中心設計也許是一個不錯的啟發，卡片內部右上角的視覺強化使得原本普通的表達變得更有視覺感。突出的設計也成功的吸引了 UP 主的注意力，強化了該入口的點擊欲。這樣的設計表達在保留卡片式設計的基礎上，也是一種新穎的視覺表現，可以作為突出業務入口的表現方式進行探索。
作者：黑馬青年 來源：站酷網
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
背景：項目中通過攝像機提供的rtsp流來顯示畫面，但是在編寫項目中，需要將rtsp實時流畫面傳輸到web前端頁面中。于是找了很多方法，都是后臺轉碼轉成rtmp來播放，現在大部分插件和瀏覽器都是支持使用rtmp播放視頻流。而rtsp隨著flash的退出而被復雜化了。網上都是1、通過ffmpeg轉碼后輸出，2、通過攝像機指定的web插件轉碼輔助播放，如?？担笕A攝像機；3、還有個猿大師播放器基于猿大師中間件提供的內嵌網頁播放（沒用過，不知道行不行，原本想用現在這個方法行不行的，若不行就用這個猿大師了的）
安裝成功以后，你重新打開一個命令行終端，輸入：ffmpeg -h，如果能輸出 ffmpeg 的相關信息出來，則證明你的電腦安裝 ffmpeg 成功。
創建了一個vuecli（vue2）項目，名稱不要起rtsp2web，與src文件夾同級
下創建一個serve文件夾
-|public
|-favicon.ico
|-index.html
-|src
-|serve
-|.gittignore
-.....
npm init --yes
npm install rtsp2web
//index.js
const RTSP2web = require('rtsp2web')
//服務端的端口號，端口號可以自定義
const port = 8033
new RTSP2web({
port
)}
運行命令：node index.js
在public的index.html中
其中jsmpeg.min.js通過src引入，可以用jsmpeg.js或者jsmpeg.min.js都行
<!DOCTYPE html>
<html lang="">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
<link rel="icon" href="<%= BASE_URL %>favicon.ico">
<!--v jsmpeg.min.js文件用在這 v-->
<script src="https://jsmpeg.com/jsmpeg.min.js" charset="utf-8"></script>
<title><%= htmlWebpackPlugin.options.title %></title>
</head>
<body>
<noscript>
<strong>We're sorry but <%= htmlWebpackPlugin.options.title %> doesn't work properly without JavaScript enabled. Please enable it to continue.</strong>
</noscript>
<div id="app"></div>
<!-- built files will be auto injected -->
</body>
<script>
var rtsp = 'rtsp://username:password@ip:port/live'
window.onload = () => {
//這里的port要與index.js的port保持一致
new JSMpeg.Player("ws://localhost:8033/rtsp?url="+btoa(rtsp), {
canvas: document.getElementById("canvas")
})
}
</script>
</html>
#####在vue頁面中用canvas中播放視頻
如 在App.vue中這樣用：
<template>
<div id="app">
<!-- <img alt="Vue logo" src="./assets/logo.png">
<HelloWorld msg="Welcome to Your Vue.js App"/> -->
<canvas id="canvas" style="width: 600px; height: 600px;"></canvas>
</div>
</template>
為什么node index.js之后沒反應？
—檢查端口號是否填寫對應，index.js中的端口要與script里的端口保持一致
|
為什么長時間未顯示圖像？
—需要等待大概1-2分鐘，就會顯示畫面。至于這么長時間未顯示，小弟也不知道啊。。希望大佬指點。。
完事了就，這是我歷經千辛萬苦找到的方法，弄這個vue中播放rtsp搞了好久，技術太拉了我，只能用這些小玩意來搞。原本打算用java或者python通過拉rtsp流解析成rtmp的，奈何能力不足，也懶得思考懶得搞懶得弄，所以擺爛了QAQ
若哪里有講的不妥和使用不當的地方還請您告知一下，萬分感謝大佬指點，小弟深表感謝<抱拳>
-----------------------------------------------------------------------------------------------------------
https://zhuanlan.zhihu.com/p/531899593 ??
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
搜索“視頻傳輸協議”，一般會搜出來RTP，RTSP，UDP等等。光看這些協議，可能有些人會覺得奇怪為什么要把udp也往上放一起，rtp不是可以基于udp？！同時，很多文章主要去講解各個協議之間的差異，而沒有從更為宏觀的角度來考慮。本文將結合OSI的分層思路，將不同協議之間的關系都梳理清楚；同時也從視頻傳輸與組網角度進行介紹。
再者，視頻有很多封裝格式，比如m3u8，mp4等；也有很多音視頻編碼格式，比如h264，h265等，那為何有這么多的封裝格式類型和音視頻編碼格式類型呢？一方面是解決存儲的問題；另一方面是支持不同播放器的解析；但更重要的是不同的傳輸協議可以支持的音視頻編碼格式有差異，這也是由于不同的應用場景下形成的歷史原因。
流媒體（streaming media），是指將一連串的媒體數據包從服務器端發送到客戶端，可以實現邊下邊播，此技術使得數據包可以像流水一樣發送。傳統的方式需要在使用前下載整個文件，存儲到本地后才能進行播放；而流媒體只允許下載一小部分（存在視頻關鍵幀）就能進行播放。
流媒體技術不是一種單一的技術，它將網絡技術、音視頻技術還有終端緩存技術等有機地結合。也就是說，在網絡上要實現流媒體技術，必須要先制作、發布、傳輸和播放等，這需要服務器端、終端以及網絡都要能支持。當前很多的視頻軟件或者網站都是用到了這種技術。歸結下來是：
1.內容的產生。這里是指將視頻源制作成為可以對外發布的視頻格式，以及適合在網絡上傳播的分辨率和碼率。這主要用到了視頻的編解碼技術。考慮的輸出參數，如分辨率、碼率、音視頻編碼格式、封裝格式等都需要結合應用場景和傳輸方式統一考慮。
2.對外發布。這里主要是指能夠支撐服務器對外輸出視頻資源的技術，常見的有各種流媒體網絡傳輸協議技術及其需要服務器端支撐的技術。這里的流媒體網絡傳輸協議比如：
3.組網和傳輸。
這里的傳輸還得考慮一個概念，是服務器對外主動推數據，還是等待終端到服務器端拉數據，這是兩個完全相反的處理方式。對于組播或者廣播的組網方式，往往采用的是服務器主動對外推送數據；而對于單播來說主要是終端向服務器端主動拉數據。
這里涉及到的IP組網方式中的傳輸類型有：廣播、單播、組播。
不管是什么類型的組網方式，在傳輸層就有UDP和TCP。下面也將從OSI等層面講講這些底層傳輸協議之間的關系。
4.視頻播放。這里主要是從終端側角度說，在不同操作系統中能夠進行播放視頻的播放器，比如vlc等，不同的播放器支持對不同類型的視頻數據進行播放。
從圖中也可以看到IP層（網絡層）的上層是傳輸層，通過TCP和UDP等方式進行數據包的傳輸。
（PS：下圖為網絡中所找https://blog.csdn.net/yaopeng_2005/article/details/7064869）
結合上圖，再補一個wiki上的互聯網協議套組圖，一看就更明白了。
從上面兩個圖中也可以很清楚地看到，TCP和UDP在接下去的內容有很重要的地位，這里也簡單介紹下，深度知識請自行搜索。
組播（multicast）
又稱為多點廣播或群播，或多播，主要是指將信息同時傳遞給一組目的地址。消息在每個網絡鏈路上只需傳遞一次，而且只有在鏈路分叉時，消息才會被復制，使用的效率是最高的。也正是因為這個原因，以前的廣電網絡中，針對直播多采用組播方式，流量的傳輸成本明顯降低很多。
單播：
其實是組播的一種特殊方式，即常規的點到點信息傳遞。如果所有傳輸中是以單播的方式傳遞給多個接收方，必須向每個接收者都發送一份數據副本這么多。
廣播
其實也算是組播的一種特殊方式，就是一對所有的通信方式，對每一臺主機發出的信號都進行無條件復制并轉發，所有的接收點都可以收到所有信息。
注意，組播一般指的是IP組播，常與RTP等音視頻協議相結合。雖然組播的設計理念很好，但是它需要對網絡內部的狀態比單播要多得多。實際商用中，組播主要應用在較為簡單的、只有單個源斷的情況，如之前提到廣電網絡內部用到的組播方式，UDP組播。
以上是不同類型的IP組播方式，實際在采用中要結合具體情況進行調整。比如，如果非要使用廣播，但是采用的場景不合適，也有可能產生廣播風暴。
組播、廣播、單播也介紹了基本的概念，但是他們與視頻傳輸有什么關系呢？
文章上面也提到了，組播是從IP層面的傳輸策略，而所有的視頻傳輸協議其數據包大部分都經過UDP和TCP，經由IP層進行傳輸到目的地。因此不同的IP傳輸策略與傳輸協議進行結合，就能夠落地到具體的應用場景。
同時需要注意的是，采用組播方式可以通過設置網卡為混雜模式或為多播模式，具體也是根據網卡的特性進行差異處理。如果處理方式不當，比如設置成了廣播，可能會導致在同網絡下，你在播放視頻，然后其他相同網絡下接收端也將有相應的流量，而導致他們的對外服務網口的流量被占滿。
從下圖中可以看到，標紅色的就是大家經常說的視頻傳輸協議。但是從圖中可以看到他們其實是有基于的關系，比如HLS都是基于HTTP進行傳輸，而HTTP在傳輸層都是依賴tcp數據包，再經由ip層進行分發。
1）UDP
基于UDP傳輸的視頻數據，比如udp://238.123.45.1:3001，在網絡可達的情況下，即可進行播放?？梢圆捎胿lc等播放器進行播放。
UDP視頻數據傳輸可以采用單播，組播或廣播的方式，具體采用哪種方式根據具體的組網情況進行控制。
上面也有提到過，廣電網絡中多采用組播的方式進行直播數據傳輸，這也是得益于廣電網絡的專網特性以及視頻源輸出可以控制到單一等特性。
UDP的組播大部分是采用MPEG TS流，廣電網絡中很多視頻，其視頻編碼格式也大部分是mepg2
2）RTP
整個RTP協議包括RTP數據協議和RTP控制協議（RTCP）。此外，這里也將經常一起提的RTSP介紹下。
RTP（實時傳輸協議，Real-time Transport Protocol），是一種網絡傳輸協議
RTP協議說明了傳遞音頻和視頻的標準數據包的格式。最早是作為多播協議的，后來主要應用在單播中。RTP是創建在UDP協議之上的，主要應用于流媒體、視頻會議等系統業務上。
RTP為端到端的數據傳輸提供了時間信息和流同步，但不保證服務質量，而是由服務質量由RTCP。
在RTP的數據包封裝中，包含了時間戳、標記位、同步源標識等信息。
RTP從上層接收到流媒體的數據（如H264），封裝成RTP數據包，并將其發往UDP端口中的偶數端口。
RTCP（實時傳輸控制協議，Real-time Transport Control Protocol或RTP Control Protocol）
RTP的姐妹協議。RTP使用的是偶數UDP端口，RTCP采用的是RTP下一個端口，也就是下一個奇數的端口。RTCP也是基于UDP進行傳輸的。
RTCP本身不做數據傳輸，主要與RTP協作，將視頻媒體數據打包和發送，并定期在流媒體會話參與者之間傳輸控制數據，并為RTP提供QoS反饋，簡單點說是主要保證音視頻的同步。
RTCP接收到控制信息后，封裝為RTCP控制包，并發往RTP端口下一個偶數端口。
RTSP（實時流協議，Real Time Streaming Protocol）
RTSP是一種網絡應用協議，主要來創建和控制流媒體服務器與終端之間的會話?？刂祁惖恼埱笾饕逿CP協議。
通過RTSP對流媒體數據進行控制和播放，比如進行播放、暫停、快進等操作，它定義了具體的控制消息、操作方法和狀態碼等。
與RTP、RTCP配合，在廣電網絡內部主要應用在點播場景比較多，而直播主要走UDP組播。在互聯網場景下，也有用于直播和點播的，但是相對來說使用較少。
請求的url為：rtsp://testdomain/test.mp4/streamid=0
需要服務器端和客戶端都能夠支持RTSP的控制。一般客戶端采用vlc即可，而服務器端采用Darwin Streaming Server，ffmpeg等建立流媒體服務。
3）RTMP（實時消息協議，Real-Time Messaging Protocol）
包括RTMP、RTMPT等一系列的協議，Adobe為flash播放器和服務器之間音視頻數據傳輸的協議。
4）HTTP
而基于HTTP協議的就更多了，如上圖。如果服務器部署了流媒體的服務，如Nginx等，就可以對外提供視頻播放服務了。
這里也需要說明，視頻的播放一般分為點播和直播，有些協議作為直播的傳輸協議反而是更好的，比如RTMP，時延就比較低，但RTMP做CDN成本相對較高。CDN支持很好的HTTP如果能支持直播，當前也有很多協議能支持通過HTTP的方式實現直播流媒體。
自適性流媒體（adaptive bitrate streaming，ABS）也叫碼流自適應，是流媒體服務器準備各種碼流的視頻流，所有的視頻碼流都是相同時段完全統一圖像的音視頻數據，客戶端根據網絡情況和CPU使用情況等進行動態調整。
主要有MPEG-DASH、HLS、HDS、MSS等技術方案，這幾個也是上圖中最上層的流媒體傳輸協議技術。通過這些傳輸協議封裝的視頻源，可以支持有多種碼率，并支持播放器客戶端在播放時，根據帶寬情況自動調整碼率以適應用戶的最佳觀看效果——不卡頓，不重新加載等。
這里也僅僅對碼流自適應技術做了簡單介紹，由于現在這種技術應用相當廣泛，后面將詳細介紹這種技術。
【說明】
文章轉自，華為云社區，作者Higeeon，相關版權解釋權歸原作者所有。https://bbs.huaweicloud.com/blogs/fed3df04b1e011e9b759fa163e330718
藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作，也請與我們聯系01063334945。
分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。
藍藍設計的小編 http://www.syprn.cn