12 月 28 日早上，也就是剛剛，張曉龍在微信公開課上正式宣布，微信小程序將在1月9日正式發布！

張小龍在演講中提到了關于微信小程序最關鍵的10件事，為大家整理如下：

10個微信小程序的最新消息

1、沒有運行過小程序，就沒有入口。

張小龍表示，推薦不是一個好事情，小程序沒有推薦，這點能更好的保護用戶，讓小程序完全根據用戶的喜好去使用，完全體現去中心化的結構思想。小程序就像一個工具，靜靜地在那等你去使用，很好的保護了用戶的使用習慣。

2、小程序啟動來自于掃二維碼，小程序不存在一個小程序商店。

張小龍說：以春運做例子， 希望出現小程序幫助人們，無需去火車站購票，和使用小程序進行車票購買和進出站。小程序這樣的形態更像是一種網頁，用戶用完即走，用戶無需在類似app sore去選擇。二維碼是互聯網時代實現線上線下的一個重要媒介，小程序通過二維碼掃碼展現能夠為線下推廣和線下服務帶來重要的機遇。企業可以通過二維碼，不論線上線下即可輕松推廣自己的小程序，也可以通過二維碼輕松實現對用戶的服務。

3、小程序不是一種公眾號，不應該訂閱，沒有粉絲，只有訪問量。

小程序這樣的一種形態完全體現了微信的理念：用完即走。可能未來小程序會以二維碼用戶的相冊或者收藏。對于小程序擁有者來說，他們想的應該是如何優化小程序，提高用戶體驗來提升訪問量。

4、小程序不能隨意推送消息。

小程序可以提供有限的通知，類似郵箱通知，可發送用戶需要的通知，不是誰來過就能收到，用戶確認希望收到消息，才會收到消息，限制非常嚴格。這樣的做法告訴我們小程序不再像傳統app那樣，小程序不會去騷擾用戶，只有你需要想起來才去使用。

5、小程序不能分享到朋友圈，但是可以分享給朋友和聊天群。

這點體現了未來社群運營的重要性，對于企業需要更多去建立自己的社群而不是通過朋友圈鋪天蓋地的廣告去吸引用戶。朋友和聊天群已經讓我們有了更多的想象空間，它拉近了人與人的關系，它就是一個即時的形態。

6、小程序頁未來應該是“活”的。

張小龍表示：我只是分享了一個活的信息過去，而且在未來我們更希望的是，當然現在還沒有做到，我們更希望的是我分享到群里面這一頁的信息它是活的，所謂活的意思就是當它出現在一個聊天里的時候，你甚至不用點進去你就能看到這個小程序的表現。例如說我分享一個時鐘的小程序到群里面，那么群里面每個人看到這個小程序，不用點進去就可以看到已經有一個時鐘在那里運轉。暫時這個形態還沒有實現出來，但是我個人非常期待。我相信這種協作式的任務，對于小程序的分享會起到一個很大的幫助，我們可以在里面構思出非常多的需要群組一起完成任務的小程序。

7、小程序不能輕易被搜索。

小程序搜索會被限制，不會濫用，當用戶觸達，需要的時候，才能被精準搜索到。

8、小程序和公眾號具有關聯性。

當一個企業做了一個公眾號，就能看到該公司做的小程序；當一個企業做了一個小程序，也能看到該公司做的公眾號。或許未來公眾號可以作為推廣小程序的一個媒介，企業可以通過引導讓用戶到達小程序。

9、小程序可以基于地理位置讓用戶看到附近的小程序。

這樣的做法讓商家有了更多的想象空間，他們可以通過附近的小程序做到很好的一個推廣。

10、小程序將于1月9日正式發布。

2017年1月9日，微信小程序就會正式出現在我們的手機里了。

今天的微信公開課將持續一天，后續可能還會有關于微信小程序的更多新消息，我們將為大家實時報道。只要點開下面的鏈接，就可以看到微信小程序的最新消息：

為什么要搶占微信小程序的

市場機遇？

根據艾瑞數據App指數，截至2016年11月微信App的月度獨立設備已經達到90627萬臺。在這個驚人的龐大數量背后，無疑隱藏著巨大的商機。既然經過這幾年訂閱號和服務號的市場已經趨于飽和，那么現在新的紅利期就落到了微信小程序上線的這段時間上。

千億級市場這個說法或許聽起來有些唬人，但是小程序的未來發展趨勢確實不容小覷。很多人對微信小程序這個新事物的印象還停留在一個簡單的層面，并沒有思考其背后帶來多大程度的行業生態變革。其實仔細想想，當時微信官方提出微信應用號（小程序最初的名字）的概念后，卻在喧鬧的輿論中沉寂了將近一年的時間，才正式丟出了撼動整個移動互聯網生態的重磅炸彈。既然微信團隊愿意用這么長的時間打磨一個互聯網產品，那就絕不是一個普通的微信新功能那么簡單。

首先，我們必須先認清一個顯而易見的事實：在本質上，微信小程序就是內置于微信里的應用。那么微信小程序和原生App有什么區別呢？其實，微信小程序就是區別于原生App的另外一種App形式。它可以直接在微信里面打開，并且擁有和原生App幾乎一樣的功能和形式，在保持使用體驗流暢的前提下卻不會占用太多的手機內存。

從微信小程序的后臺更新日志中可以看到，小程序于2016年12月就已經為開發者和體驗使用者更新了新增分享、模板消息、客服消息、掃一掃、帶參數二維碼（當前僅限開發者和體驗者使用）等多項重要功能。這意味著小程序充分體現了微信環境下的特點，并且擁有與原生App媲美的各種強大功能。不得不說，微信小程序的推出，可以說是移動互聯網的又一次巨大變革。搶占微信小程序的市場機遇所帶來的價值，就不言而喻了。

微信小程序上線后會有哪些機遇？

微信小程序的初期紅利集中在工具類應用上，因此充分利用設備訪問能力，例如：視頻處理、訪問相機、重力感應、定位這類的功能，讓小程序有別于服務號，更具有實用價值。公眾號要求推送消息在短時間內的時效性，而小程序則要求回歸到服務價值本身。這一方面要求小程序要功能純粹、簡單，沒有多余信息干擾，另一方面，還要保證良好的體驗，符合用戶需求、方便獲得。借助小程序向線下、傳統行業滲透，針對垂直行業，提供專業技術、內容服務的小程序更容易抓住風口。

當然，電商類小程序也會緊隨其后，迅速進入這個龐大的生態。小程序的帶參數二維碼、支付交易和客服等功能，就是為了這一類應用量身打造的。可以說，電商行業必然會面臨一次大規模洗牌。但在這樣的情況下，很多中小企業會面臨一個短板：難以承受高昂的開發成本以及專業的技術開發團隊。這也是為什么越來越多的企業開始涌向“即速應用”這樣的小程序第三方開發服務平臺的原因。畢竟，省去繁瑣的繁瑣代碼開發過程以及大量的人力資金成本，對希望快速進入小程序這個市場的中小企業來說，是有很大幫助的。

除此之外，餐飲、旅游、婚慶、金融、房地產、汽車……各行各業都會紛紛進入小程序這個市場，進一步擴大這個生態。微信小程序是微信對服務的一種延伸，它會在現有的微信生態和新媒體格局上，引導用戶形成新的交互習慣，滲透進我們生活的方方面面。在這個市場中，中小企業必須找準自己的位置，快速展開應對市場的戰略，才能在小程序的市場中占據一席之地。

中小企業怎樣才能抓住微信小程序紅利期？

一、進入市場一定要迅速。

在一個剛剛拓展的新市場中，越早進入，往往就能獲得更迅速的發展機會。在推廣過程中，既要參考原生App線上線下活動結合的推廣思路，也要充分考慮微信環境下的社交網絡傳播環境。提前制定好市場戰略，在合適的時機迅速進行推廣，才能事半功倍。

二、充分借助小程序第三方開發平臺。

一個行業的蓬勃發展，必然會帶來第三方服務平臺的興起。例如現在的微信公眾號行業，就有135編輯器、西瓜公眾號助手、微頁H5制作工具等第三方服務平臺。現在微信小程序上線后，類似“即速應用”這樣適用于零基礎開發者的小程序制作平臺也迅速涌現。借助這樣的開發平臺，可以直接在無需代碼的情況下快速生成小程序，這能讓中小企業省去不少麻煩，跟上小程序發展的節奏。

三、利用公眾號積累的影響力。

如今絕大部分企業都已經有了自己的公眾號。用小程序獲取用戶，訂閱號進行用戶運營，進行二次轉化，是利用小程序驅動營銷的基本思路。如今，微信用戶活躍數用戶數已達8.06億，微信成為了我們日常最重要的流量入口，微信小程序的出現為我們提供了跨平臺傳播的更多可能。要想利用小程序營銷品牌，最關鍵是要做好小程序的服務，以及切準行業方向，這樣可以保證有源源不斷的流量，還可以獲得精準的用戶。

未來小程序會成為一個怎樣的生態？

從以往的發展可以看出，微信團隊的目光是相當長遠的。一直以來，微信每一次推出的功能在移動互聯網行業內都有著里程碑式的意義：公眾號的推出，開啟了新媒體的全盛時代；紅包功能的推出，在電子支付領域里和支付寶分庭抗禮；朋友圈廣告的開放，建立了移動社交廣告投放的全新模式……現在，微信小程序的推出，無疑將會是更為震撼的移動互聯網變革。

很多人認為微信想做一個和App Store一樣的應用商店，這也太小瞧微信了。其實微信小程序更接近于一個操作系統。從技術上來說，微信小程序確實是按OS標準打造的，開發語言和IDE都是自成體系，而且是和iOS一樣的封閉生態。看起來，手機原生OS才是老大，微信小程序這種二級生態是很難做起來的。但是拿Windows里的互聯網應用做對比，就可以很清晰地看到二級生態是非常強大的。微信小程序的設計目標就是這樣一個大生態，所有現在做App的人，最后都難免會被卷進來，或者受到巨大的沖擊。

不可否認，微信小程序的發展動向將會涉及很多企業的命運，雖然微信本身的盈利未知，但整個微信生態還是很龐大的，僅僅是現有的微信公眾號數量就超過1000萬以上，其中涉及到的人員更是多不勝數，不少創業者、開發者、創業公司都是圍繞微信生態而活的，微信的任何一舉一動，都間接決定部分人的利益。

而微信小程序的推出，相當于推倒了整個移動互聯網的規則，并重新建立起新的規則。很有可能，未來都不會再出現滿屏幕的手機App了，取而代之的是嵌入到微信里的各種小程序。到那個時候，傳統的手機App生存環境將會越來越艱難，而微信小程序將會越來越被重視。

JITSI開源視頻直播

JITSI開源視頻直播

徐景周

WebRTC被認為是一種點對點技術，瀏覽器可以直接通信而無需任何類型的基礎設施。此模型足以創建基本應用程序，但難以在其之上實現諸如組通信、媒體流記錄、媒體廣播或媒體轉碼之類的功能。

2.1 Mesh架構模式

下面是WebRTC Mesh（網格P2P）模式下，1對1的視頻通訊如圖一所示。

2.2 Mesh事件序列

如圖二所示，Mesh模式下1對1模式下的事件序列圖。其中，Coturn Server為開源的NAT穿透服務器(支持STUN/TURN/ICE)；Signal Server為信令服務器（可采用開源的/SkyRTC/）；

2.3 WebRTC框架

如圖三、圖四所示。

3.1 概述

WebRTC規范只定義了實時通信中客戶端的行為，而沒有規范服務端（包括哪些信令、數據如何流轉）的行為。所以，你可以使用WebRTC庫方便的實現1:1 實時通信，但對于多人實時互動，通常會使用WebRTC + 流媒體服務器的方案。WebRTC流媒體服務器類似“多媒體中間件”，從源到目的地時，媒體流量會通過該中間件。流媒體服務器能夠處理媒體流并提供不同的類型，包括組通信（將一個對等方生成的媒體流分配給多個接收方），混合（將多個傳入流轉換為一個單一的復合流），轉碼（在不兼容的客戶端之間適應編解碼器和格式），錄制（以持久的方式存儲對等體之間交換的媒體）等。

如圖五所示。WebRTC媒體服務器包括SFU( Unit，可選擇轉發單元)，MCU（ Control Unit，多點控制單元）或混合模式。

3.2 媒體流

如圖六、圖七所示。WebRTC由語音引擎，視頻引擎和網絡傳輸三大模塊組成。其中，WebRTC音頻處理（）默認編解碼是ISAC（ Speech Audio Codec），源碼目錄“/”；視頻處理（）默認采集與編解碼是I420和VP8（源碼目錄“/”）。

3.3 流媒體服務器

基于WebRTC流媒體服務器有很多，如表一所示。下面針對主流的開源服務器進行介紹。

3.3.1 Janus

Janus 采用C語言實現，是一個非常有名的開源WebRTC流媒體服務器，它是以Linux風格編寫的服務程序。支持Linux/MacOS下編譯和部署，但不支持Windows環境。

Janus架構如圖七所示。Janus分為兩層：應用層和傳輸層。整體架構采用了插件的方案，用戶可以根據自己的需要非常方便地在上面編寫自己的應用程序。Janus 所有信令的格式都是采用JSON格式。

3.3.2

使用C++和NodeJS語言實現，底層使用libuv處理I/O事件。

Janus架構如圖八所示。流媒體服務器是由NodeJS和 (C++) 兩部分組成。其中，NodeJS負責的信令接收與業務管理。(C++)負責媒體數據流的轉發工作。

3.3.3 Medooze

Medooze使用C++和NodeJS語言實現。Medooze的整體架構與類似，不過它的信令處理、業務管理以及媒體數據的轉發功能都是放在NodeJS下進行統一管理的。

Medooze的業務功能要比強大，像服務端錄制、推流這些沒有的功能它都支持。但它性能沒有好，因為Medooze的底層使用的poll來處理I/O事件，poll與epoll性能差距大。除此之外，Medooze的業務邏輯也沒有簡潔；另外與 Janus 相比，它的業務管理不如Janus靈活，Janus的插件管理方式顯然要優于Medooze和。

Medooze架構如圖九所示。

3.3.4 Licode

Licode是由C++和NodeJS語言實現。既可以用作SFU類型的流媒體服務器，也可以用作MCU類型的流媒體服務器。Licode不僅僅是一個流媒體通信服務器，而且還是一個包括了媒體通信層、業務層、用戶管理以及客戶端 SDK 等功能的完整系統，并且該系統還支持分布式部署。

Licode架構如圖十所示。其中，媒體通信部分由C++語言實現，而信令控制、用戶管理、房間管理用NodeJS實現。Licode從功能層面來講分成三部分，即Nuve、和三部分，它們之間通過消息隊列進行通信。

3.3.5 Kurento

Kurento使用C++開發，有豐富的文檔和示例。Kurento是真正完整的多功能媒體服務器，不僅提供媒體服務器功能，還提供其它很多工具（人臉識別，二維碼接口，對象追蹤等）。

Kurento架構如圖十一所示。

3.3.6Jitsi

Jitsi是使用Java構建的服務端，底層也是使用C/C++。Jitsi是比較活躍的開源視頻會議平臺，是一個處理XMPP（前身是Jabber）信號流的SFU，適用于SIP/XMPP視頻通話、會議、聊天、桌面共享、文件傳輸。

Jisti核心組件如圖十二所示。

Jisti分布式部署示例（單Jitsi-Meet, 多Video-Bridges），如圖十三所示。

Jitsi SDK

3.4 小結

對流媒體服務器的選擇，沒有最好，只有最合適。每個開源實現都有其各自的特點，需要根據自身特點以及項目特點選一個最合適的。

四、Jitsi架構

4.1 網絡拓撲

如圖十四所示。分為二類用戶接入：WebRTC和SIP。其中，Web Server可以理解為Nginx + Jitsi Meet。

4.2 技術架構

如圖十五所示。可分為訪問層、應用層和媒體層。

訪問層（Access Layer）：接入端。例如：Web瀏覽器。應用層（ Layer）：內含Jitsi重要組件。例如：Jicofo提供基本信令服務、負載均衡等；Jirecon和Jipopro是負責錄制視頻相關的功能。媒體層（Media Layer）：-Bridge負責中繼視頻流，是一個選擇性轉發單元(SFU)。

備注：是一個開源的電話交換平臺，類似一個背靠背的用戶代理，用來幫助通信的雙方進行實時的語音視頻通信。支持多種通訊技術標準，包括SIP、H.323、IAX2以及，可以方便的與其他開源的PBX系統進行對接，可以用作交換機引擎、PBX、多媒體網關以及多媒體服務器等。

4.3 事件交互

一個簡單示例，如圖十六所示。

4.4 分布式方案

如圖十七所示。一種示例方案，多區域分布式部署（美國東部/西部、歐洲中部/西部、亞太區域）。

五、Jitsi部署

Jitsi官方開源子項目有100多個，必備項目有5個：Prosody、Jitsi-Meet、Jicofo、Jitsi-Video-Bridge（jvb）、Turn Server。

官方文檔提供三種部署方式，具體安裝過程請參見官網示例。

1） 快速安裝（即打包安裝）。

2) 基于Docker的安裝。

3) 手工安裝（即依次逐個安裝）。

注意事項

經安裝測試，Windows環境下采用Docker容器方式，需要安裝Hyper-V，Win10家庭版會遇到一些問題（例如：沒有Hyper-V，容器啟動不了等）。Windows環境下采用VMWare虛擬機安裝Debian/Ubuntu的方式，則需要禁用Hyper-V；先修改Linux默認來源地址（例如：Debian下的/etc/apt/sources.list）到國內鏡像地址（例如：清華/阿里）。可切換到root權限（終端輸入：sudo -i），再按官網步驟安裝。終端輸入：sudo ，將以界面方式打開root文件夾。