📖 ZKIZ Archives


微信突變!騰訊將深度布局

來源: http://www.guuzhang.com/portal.php?mod=view&aid=1150

本帖最後由 三杯茶 於 2015-1-19 11:58 編輯

微信突變!騰訊將深度布局

作者:王安


2015 年剛剛開始,微信 JS SDK 發布,驚爆眾人,HTML5 產業好事連連。

JS SDK 這個概念,其實微博和淘寶的開放平臺很早前就有,包括手機 QQ 前段時間也推出了幾個增強 API,但都未產生很大的影響。小巫之後終見大巫,這次微信開放的 SDK,站在了另一個高度,web 到底能有多強?

HTML5的逆襲

其實之前微信也是有一些 JS API 的,比如分享。但這次一股腦開放了拍攝、錄音、語音識別、二維碼、地圖、支付、分享、卡券等幾十個 API,這條消息不需宣傳,瞬間就占滿了 HTML5 從業者的朋友圈。

因為微信給所有做 web 開發的人打開一扇新窗戶:使用 js,你也可以調用各種強大的原生能力了!

客觀的講,微信的很多能力組件非常強,比如掃碼,很多原生應用的掃碼效果都不如微信。現在 HTML5 開發者瞬間成功逆襲,他們原本無法實現掃碼,現在卻能輕松的開發掃碼應用,而且效果比很多原生應用都好(當然前提是你的 web 應用運行在微信的管理之下)。

首先受益的是微信內置的騰訊系 App,比如大眾點評、滴滴打車、京東購物等。

以前微信在錢包欄目下以很別扭的方式內嵌了滴滴打車的 HTML5 版本,那個版本的體驗比滴滴的原生版本差太多,不能說話只能打字,沒有地圖看不到司機在哪。在體驗為王的移動互聯網時代,這個將就能用的版本出現在微信的錢包分類下,其實是微信的敗筆。

但如今不同了,滴滴打車的微信版本,將擁有不輸於其原生 App 的能力。而且不用下載 App 就可以秒開應用。

大眾點評的受益就更大了,不止是其微信內嵌版本的能力將大幅增強。因為使用場景的不同,滴滴在朋友間分享的只能是紅包,離打車這個業務場景有點遠;而大眾點評在朋友間可以分享優惠或推薦商家,直接形成消費,通過關系鏈導流的效果會非常明顯。

HTML5 定稿時,我寫過的一篇文章,提到過 HTML5 的一大優勢就是打破 App 孤島,直穿應用子頁面。一張大眾點評的優惠券,通過朋友分享,就可以通過點擊分享內容直接到達這個商戶的界面,進而直接購買,這點連大眾點評的原生 App 也做不到。

微信給我們展示了一個新的 web 世界:能力和原生一樣強,但在應用的獲取、流量的轉換上進一步領先於原生應用。

很快,我們就會看到各種公眾號、微店全面升級支持微信 JS SDK。然後我們就會發現,原來市占率最高的手機瀏覽器,是這個沒有地址欄的微信。

瀏覽器的傳統思維被突破

微信這個巴掌把瀏覽器廠商拍的不輕。但是瀏覽器廠商又很難還擊,因為這挑戰了他們的思維傳統。

在 HTML5 規範制定時,很多人都有一種思維:web 是開放的,地址欄和超鏈接可能帶來任意惡意網頁,所以我們不能把 HTML5 的能力做到太強,會引發安全問題。

微信給了這些人不同的答案。

首先微信開放的能力沒有涉及過於隱私的 API,比如個人敏感信息或好友關系,當然這個估計永遠也不會開放。最關鍵的是,所有使用微信 JS SDK 的網站,都必須實名到微信認證、繳費。它采取了類似 Apple App Store 的策略,由系統運營方來保障用戶的安全。

這個由微信構建的新 web 世界,不再開放,由微信所管理,他根本就沒有地址欄,所有能使用微信增強能力的網頁都是經過認證權限的。

其實 HTML5 強化這個領域已經發展多年,也已經有了行業規範,HTML5Plus.org,微信此次把這些標準都拋在一邊,就是一心建設自己的生態系統。

除了管理模式不同,微信的設計體現了他對於用戶體驗的不同理解。其實我們大多數人都會認可一點,在手機瀏覽器里輸入 url 是一個體驗比較糟的事情,但是瀏覽器廠商卻一直墨守成規。

我們來解構下微信的設計。

在微信里,既然沒有地址欄,那麽如何到達一個 web 應用,它有幾個 web 入口?答案是 5 個。

    消息內容里的超鏈接;
    公眾號的文章;
    朋友圈;
    掃一掃;
    預置入口的web應用,如錢包、購物等欄目。

這 5 個入口里,沒有傳統的地址欄,甚至也沒有搜索。

web 初生時,人們獲取 web 信息是主動式的,通過地址欄訪問網站,網站太多後開始使用搜索引擎。Google 的 page rank 算法告訴網民,被鏈接的網頁越多,這個網頁的價值越高。微信的理解里,大多數人們獲取 web 信息是被動的,這里沒有地址欄、沒有搜索、沒有 page rank,朋友發給你的、你訂閱的公眾號發給你的,就是你需要的 web 內容。

如果你真的想要主動獲得內容,那也沒有地址欄,但是有掃一掃。

可是掃一掃就不在微信的管理之下了嗎?當然不會。很多 App 開發者頭疼的就是他們的 APK 地址變成二維碼後,微信是不能下載安裝的,這可是瀏覽器不會幹的事情,用戶要下載什麽那就允許下,最多給一個可能不安全的提示。但是微信說,APK 只能是來自應用寶的鏈接才可以下載。你不接受?那就別用掃一掃。

就這樣,微信構建了一個獨特的 web 生態系統。它有關系鏈推薦,不需要搜索引擎;它有消息系統,不需要電子郵件;它有增強的瀏覽器,有支付等業務閉環手段。最終一個完整而又封閉的 web 世界出現在微信里。信息在這里產生、在這里流轉、在這里變現。手機上只需一個微信就夠了,什麽都能幹了。

騰訊的戰略


微信是僅僅強化了一批能力 API 嗎?不是,大家還記得前段時間騰訊發布的 X5 瀏覽器內核嗎?

X5 內核內置於 QQ 瀏覽器,在安裝了 QQ 瀏覽器後,微信有著不同的表現,它將調起 X5 內核,與 JS SDK 協作實現更好的體驗。X5 和 JS SDK,這究竟是一盤什麽棋呢?

微信其實很早就能開放這些 JS SDK,甚至一度曾開放幾個又收了回去,為何此時如此大力發展 web 生態系統?

我想到了前段時間馬化騰的話,微信只是張“站票”,他還給騰訊提出的一個新願景:連接一切。張小龍也曾仔細研讀 KK 的《失控》,提出微信要營造一個森林,而不是造一個宮殿。

其實這些事情是相關聯的。有戰略需求,才會出現 X5、微信 JS SDK 這些支撐戰略的產品。要論站票和臥鋪的區別,那就是一個可以躺著掙錢。如何才能躺著掙錢,看看阿里巴巴就知道了。在阿里建立的龐大生態系統里,每天無數人努力賺錢,阿里坐享其成。

騰訊曾經數次努力電商,但怎麽也賺不到阿里的錢。它只能走自己的路。就是馬化騰所說的,回歸本源,連接一切。

電商搞不定,那就不搞了,剝離和註資給京東。搜索搞不定,那就不搞了,剝離和註資給搜狗。不再天天盯著阿里、百度,騰出全部精力,在移動互聯網時代,達成連接一切的願景。

沒錯,基於微信這張站票,騰訊最終要打造出一個由他掌控的生態系統,而對於一個工具而言,構建生態系統的最佳技術路線就是 web,強化 HTML5 是打造更優質生態系統的必由之路。

而此時能做這事,還恰逢 HTML5 即將崛起的機會。一方面手機硬件的不斷提升使得 HTML5 表現更好,另一方面,就是 Apple 對 HTML5 的態度在開放,或者說 Apple 整體都在開放。一方面 iOS 設備的市場份額遠低於 Android,另一方面庫克確實沒有喬布斯強勢,所以目前 Apple 的整體態度是開放的。前段時間 iOS8 發布,Apple 給第三方廠商開放了自己的 js 加速引擎 Nitro,以強化 iOS 設備上 HTML5 的表現。此時的微信 JS SDK 上線,不必再像以前那樣擔心無法通過 Appstore 審核。

而且事實實際上是反過來的,帶有微信 JS SDK 的版本其實早已更新到 Appstore 了,只是前幾天才給開發者公布了調用接口。

但是不管怎麽樣,這帶有試探 Apple 底線的味道。如果僅僅在中國倒也是區域行為,但微信事實上已經遍布全球,當海外開發者也大量開發微信專屬的增強 web 時,Apple 和 Google 會如何看待這個新的跨平臺霸主?

開發者的機會

whatever,巨頭們的煩惱讓他們自己操作吧,我等創業者和開發者還是要抓緊這個機會快速發展自己,快速利用微信 JS SDK 開發出驚艷的 HTML5 應用,搶先占有用戶。後面的比較技術,有興趣開發 JS SDK 的開發者可以繼續往下看。微信本次開放的 JS SDK 分類清單如下:


    分享類接口;
    圖像類接口;
    音頻類接口;
    智能類接口;
    設備信息類接口;
    地理位置類接口;
    界面操作類接口;
    微信掃一掃接口;
    微信小店接口;
    微信卡券接口;
    微信支付接口。


滴滴打車、大眾點評這些微信內置應用的增強路線,將基本照著其原生 App 的模樣演進。其他的開發者,還是要運營好自己的公眾號,目前公眾號分為訂閱號和服務號。

訂閱號的開發者提供的大多是資訊,那麽對於資訊而言,可以利用 JS SDK 做的事情什麽?

豐富內容形式,即除了圖文,新增音頻能力。類似電臺的訂閱號將有機會興起。但微信暫時還沒有開放視頻能力,朋友圈里的小視頻是原生實現的。在 Android4.0 以上的手機,安裝了 QQ 瀏覽器後,微信網頁里的視頻播放才能被 X5 引擎優化。而目前使用 HTML5 標準的視頻,會在低端手機上遭遇性能問題。所以視頻還是緩緩再搞。

不管是做圖文還是做音頻,都應該利用新提供的設備 API 獲取網絡狀態,WIFI 和 2G 下應該給予用戶不同的內容以增強用戶體驗。

根據地域分發信息。資訊也是有地域性的,類似地方臺的訂閱號以後也會占有一席之地,而這也非常符合微信打造森林的生態初衷。

服務號就五花八門了,很多大企業有自己的掌上客服 App,這回可以整體搬遷到微信上了,這也給企業服務開發商很多新商機;

對於可線上交易的微店,微信小店和支付這些 API 必不可少。微店的商品,這下可以直接被分享出去,只要東西好,傳播更容易、銷量也會高升;

對於線下消費的 O2O,地圖和卡券很重要。卡券對微信而言是個新東西,之前 iOS 已經有了 passport,大眾點評也有自己的會員卡體系,但微信自己做了一套,相信體量會做的更大,以後大家出門不用在錢包里塞那麽多卡了,都在微信里了。

微信官方還推薦了幾個 App 供開闊思路。

印美圖是一個雲打印 App,自拍的美圖,可以直接提交給這個 App 的後臺,運營方打印好照片快遞給你。微郵筒是一個語音明信片,在明信片里留下自己的聲音,再發給朋友,並且可以長期保存在服務器。

微信官方沒有提供開發和調試配套的服務,客觀地講,開發和調試的便利性很不好。推薦一個免費開發工具 HBuilder,可以完美支持微信 JS SDK 的語法提示,大幅提升開發效率。下圖中敲 wxc 回車就能生成一段完整的微信 API 初始化的長長代碼,還能給予各種參數的值域提示。

接下來會如何

我們都很確信,JS SDK 的這個版本只是一個開始,未來騰訊還為了強化其 web 生態系統建設而不停升級產品。

1. 會顛覆原生 App 嗎?

微信 JS SDK 繼續升級下去,真的會顛覆原生 App 嗎?目前的微信 JS SDK,屬於 web 增強,它依然還不能離線使用,還沒有解決網頁跳轉間白屏的體驗,也不能在手機桌面創建快捷方式,暫時它並沒有向著努力做到和原生一模一樣體驗而前進。

就騰訊連接一切的願景而言,它應該沒有顛覆原生這個戰略目標。但是這個月活 4 億的平臺勢必會更大程度占有用戶使用手機的時間,自然也會大幅影響原生 App 的流量。對於普通用戶而言,每天使用手機的時間是有限的,之前每天看著手機屏幕的總時長里可能 60% 是被微信占去的,那麽微信未來可能會占去 80% 的時間。

另外微信雖然沒有顛覆原生 App 的願景,不代表其他人不會做這件事。IT 行業總是在持續創新和突破的,除了微信,還會有其他大型 HTML5 的平臺出現,可以預見 HTML5 成為主流已是不可阻擋的趨勢。

2. 微信會重構移動搜索嗎?

這個概率其實很高。在微信現在的 API 里,有一個智能語義的接口,傳入“查一下明天從北京到上海的南航機票”,就會返回結果。很像 siri 是不是?其實微信完全可以現在就在掃一掃下面加一個說一說,但是他目前沒有這麽做,是因為搜狗還不夠強大?還是因為不想過早刺激百度?

確實相比起來,騰訊在手機上搶奪百度份額的勝算是遠高於搶奪阿里的。但是手機端廣告市場一直沒起來,搶掉搜索份額又如何?
3. 微信會重構移動電商嗎?

其實單純的套 PC 互聯網的模式給移動互聯網是不對的。騰訊最關心的不是移動電商,它更關心移動支付。所以易迅才會被剝離給京東。騰訊十年總結時曾說,是互聯網網民的高速增長紅利造就了騰訊的今天。其實類似於雷軍風口的理念。

移動支付,是一個大風口,是未來若幹年高速增長的產業。

我們可以預見,未來移動支付的用戶數會越來越多,交易額會越來越多,直到顛覆現金的地位。但移動支付可不只是在電商網站買東西付款,更多場景在 O2O 範疇里。

移動支付大戰里,騰訊一方面通過微信紅包發展用戶,另一方面通過資本手段控制支付場景,其投資的滴滴打車、大眾點評、京東電商,這些合作夥伴的業務都是高頻的支付場景,其成功的幫助騰訊發展了移動支付體系。

當然阿里也不甘示弱的支持快的和美團。滴滴和快的的補貼大戰、大眾點評和美團補貼大戰,看似瘋狂,其實都是為了移動支付這張船票,為了未來十年的繼續高速增長是任何一個巨頭都不願錯過的。

在未來人們的衣食住行里,買衣服花錢用阿里和騰訊,吃飯花錢用阿里和騰訊,出門打車結帳用阿里和騰訊,就是買房好像不太好做移動支付。

另外近期在醫療領域,移動支付之爭也打響了,那意味著以後看病,也用移動支付。

微信的 JS SDK,其實很大程度上就是為了把這些需要花錢的 App 控制在自己的生態下,微信給這些 App 提供流量、提供更強大的運行環境,大家努力掙錢,然後微信躺著分錢。

4. 不管怎麽樣,HTML5 會大火特火

騰訊的這條構建 web 生態系統的路,還是有很多高手已經看懂了的。很快各大互聯網巨頭都會有自己的對策。但不管是什麽對策,都是要基於 HTML5 來做了。

對於 HTML5 的開發者和從業者,這都將是一個最好的時代。(來自互聯網交易圈)
PermaLink: https://articles.zkiz.com/?id=127966

Next Page

ZKIZ Archives @ 2019