標籤：

如何看待 Progressive Web Apps 的發展前景？

01-04

Google 發的一些視頻講這個, Manifest, Service Worker, Offline, 各種, 讓 Web App 的體驗能更接近原生應用:

https://www.youtube.com/watch?v=a5X_Ot-R6lohttps://www.youtube.com/watch?v=cmGr0RszHc8https://www.youtube.com/watch?v=srdKq0DckXQhttps://www.youtube.com/watch?v=wLWVASD0dvU

看上去的挺厲害, 推廣方面怎麼樣呢? 前景如何?

本題已收錄至知乎圓桌：Google I/O 2017，更多「Google I/O」相關話題歡迎關注討論

看到 @題葉 問這道題時，我剛從 I/O 回來，當時就特想答，今天總算有時間了。

---

更新：

新文章……下一代 Web 應用模型 — Progressive Web App ，比較全面詳細的文章。其實每次寫都有一些重複的地方也有不少新東西，所以……自取自取 OTZ

11月20日在 GDG DevFest 2016 北京分享了「Service Worker 101」，Slides: Service Worker 101「GDG DevFest 2016 北京」，技術乾貨技術乾貨。

10月20日在 QCon 上海 2016 分享了 「Progressive Web App，復興序章」，Slides: Progressive Web Apps，復興序章「QCon 上海 2016」 ，不止是一場技術演講，更是關於 Web、開放、自由與信仰。有不少半年來 PWA 方面的更新，作為這個答案的補充吧～。

---

其實回來的兩周里，我對 Progressive Web App（以下簡稱 PWA）的理解也在不斷更新，現在來答反而是一個思考的更為全面的時候。

一、先從技術角度聊聊我的觀點。

6月5號，我在 I/O Redux 上分享了「Progressive Web App - in my points of view」(PWA 之我見) ，簡單介紹了 PWA，也聊了聊我的看法。這裡就用文字再粗略過一遍，搭配 Slides 觀看效果更佳: PWA-in-my-pov ;)

首先，什麼是 PWA？

官網 https://developers.google.com/web/ 上對 PWA 的宣傳是這四個關鍵字：可靠、快速、Engaging、安全；再點進去 PWA 的主頁，會發現還有 Instant Loading、添加自主屏、通知推送、響應式（誒？

而官方教程 https://codelabs.developers.google.com/codelabs/your-first-pwapp/ 就更棒了，一次性給了 10 個關鍵字！包括 Progressive, App-like, Fresh, Installable....

如果搜索下 PWA 的歷史就會發現，它第一次出現於 Googler Alex Russell 的博客文章《Progressive Web Apps: Escaping Tabs Without Losing Our Soul》中，其主要觀點是：Web 的發展方嚮應該是」在保留靈魂的基礎上漸進增強」，而非現在大行其道的 Hybrid App 方向。

總結一下，文章里的 Progressive 主要有這兩層含義：

  1. 如果用戶需要，網頁可以漸進式地變成 App，比如被添加到主屏幕、全屏方式運行、離線工作、推送通知消息等。但它仍是 Web 而非放到 App Store 里。
  2. 所有這些「使得 Web 更能與 App 匹敵」的特性都是以漸進的方式增強的，在比傳統網頁應用更好的同時也保證了降級兼容。

作者舉的一個 PWA 例子就是 Chrome Dev Summit 2014 的 Web App，Slides 里的 Gif 描述了其從網頁被「升級」為 App 的過程： 演說.io - 分享你的雲演說

我理解的 PWA，首先是一個「涵蓋性術語」：它泛指所有那些「利用現代 Web 技術以嘗試在移動設備上提供頂級體驗的 web app」；（ 這個名詞本身是發展且包容的，你不一定要使用到所有的現代 web 技術，而只要 cleverly take advantage of technologies 以提供優秀體驗就好了）

再者，為什麼瞄準移動端？顯然，因為目前移動仍是風口浪尖，而 Web 畢竟誕生於桌面端，歷史原因使得 Web 的最大短板還是在移動端。Chrome 團隊一直宣傳說 「PWA: Deliver an app-like UX」 ，在我理解看來，應該說 Chrome 團隊現階段推進 Web 的主要目標在 「匹敵 Native app」。（如果 VR 真能起來，說不定 Web VR 又會成為 Chrome 團隊的重心）

PWA 到底有哪些過人之處（特性）？

看了諸多 Session 後，其實總結起來主要就四個：

1. Add to Homescreen

說白了就是可被添加自主屏與全屏運行。對於這個，我就發一張圖不說話：

2. App Shell

其實就是第一次渲染渲個殼、等非同步數據來了再填充，包括阿里旅行在內的很多 web app 應該很早就在用了。

3. Offline （離線能力）

離線和弱網環境也能秒開的能力，但是這個就牛逼了。Hybrid 架構搞了那麼久，不就為的這個嗎？之前有個東西叫 Application Cache，但是那貨就是個 shit。

所以這次 Chrome 搞了個 Service Worker 出來，給了 Web 一個可以跑在後台的線程，它可以搭配非常靠譜的 CacheStorage API 做緩存、可以攔截所有 HTTP 請求並使用 Fetch API 進行 response，一個非常完備的 Proxy 就這麼誕生了。

不得不說，這貨跟 Hybrid架構下，載入本地H5資源後，如何處理Ajax請求？ - 黃玄的回答 這裡提到的淘寶旅行 Hybrid 架構的思路真是太像了……

不過當這種離線能力出現在瀏覽器層面時，意義就完全不一樣了。

4. Re-engageable

喚回/保持用戶的能力，其實目前主要就是推送通知（Push Notification）。

推送通知依賴 Service Worker 與不限定的 Push 機制，Chrome 目前只支持 GCM …在國內覆蓋率肯定是捉急的，不過未來各瀏覽器會推進 規範的 Web Push Protocol，允許各種推送服務提供商提供服務。

Slides 里還提到了幾個示例和幾個推薦 Session、有興趣的可以自己去看，我這裡就提兩個：

  1. PWA 當然不是 Polymer only，只能說 Polymer 幫你封裝了不少。PWA 的所有特性都是 web 標準都是 Framework-agnostic 的。
  2. AliExpress 作為 Keynote 里唯一展出的 PWA 還是值得小自豪一下的；並且，它好像是唯一不搭梯子就可以體驗到的……

那麼技術角度上，我對 PWA 的看法？

缺點

  • 門檻不低（要求 HTTPS；Service Worker 的 API 比較 low-level）
  • 瀏覽器支持不夠完美（Safari 短期內不會支持，在 5 年計劃里提了一嘴）
  • 用戶習慣 （讓用戶習慣於網頁可以離線工作並不是短期可以達到的）

優點

  • 剛才提到的，所有這些現代 Web 能力。
  • 由於這些都是 「優雅降級、漸進增強」 的，給支持的設備更好的體驗，不支持的設備也不會更差。
  • 代表著 Web App 自身的一種進化方向

可以看出來，其實我對 PWA 的評價也並不是那麼積極的：

除了 Service Worker 帶來的諸多可能性外，其他幾個在能帶來的體驗上都不算是什麼新鮮事；而就連 Service Worker，還面臨著瀏覽器支持這個 Web 發展的千古難題。

那麼，為什麼我們還要擁護並 stick on Web 呢？

我特別同意《The Mobile Web: State of the Union》這個 Session 里 Chrome 產品團隊 Leader Rahul 所說到的：Dicoverable、Linkable、Low Friction、Broad Reach 等等，這些都不是 Web 最大的優點，Web 最重要的意義在於 Open（開放）與 Decentralized （去中心化），這才是萬維網（WWW）的初衷。

是啊，縱使強如 Chrome 都不能對 Web 一手遮天，這才是 Web 真正與眾不同的地方。這也是我在 Introducing 演說.io Beta - 一生想做浪漫極客 - 知乎專欄 里所說的：「Web 背後開放與分享的力量」。

(從答案第一次發布到現在，Google 和社區對 PWA 的宣傳口徑也一直在變。目前主推的應該是 Reliable, Secure, Reengagable)

二、再說 PWA 的意義，技術與技術之外的。

PWA 看上去並不是那麼 breakthrough，但這可能只是站在開發者的角度之上的。

大家都很熟悉 「Ajax」 這個說法，它出現於 2005 年，用於描述 Gmail (2004) 或者 Google Maps (2005) 這樣的網頁應用，這個詞不但宣告了 Web 客戶端技術的全面復興與流行，也成為了 Web 2.0 的最大技術推動。然而事實是，早在 「Ajax」 這個詞出現的 5 年前，IE5 已經廣泛支持了 XMLHTTPRequest 並實現了 Outlook Web App (2000) 。

技術並不是不需要包裝。如果沒有 「H5」 這樣易於傳播的爛詞， Mobile Web 乃至前端工程師在所有中國群眾、新手開發者、產品經理、創業者中也不會得到如此重視。

身為開發者我們知道，Web 這幾年發展迅猛，我們能做的事情越來越多。但是在大量群眾的心裡可能並不是這樣，如果你做出一個體驗足夠優秀的 Web 產品，可能大家的第一反應是：「這肯定是一個 App，怎麼可能是網頁？」。

而這正是 「PWA」 希望解決的問題，Chrome 團隊希望用一個新的 buzzword（流行詞）來影響、改變用戶的期待。PWA 歸根結底還是個網頁，雖然是體驗更好的網頁，但是 Chrome 希望讓用戶感受到更多的不一樣：「哦這是個普通網頁」； 「 哦這個 Chrome 告訴我可以添加到主屏幕上，告訴我可以離線、可以推送，這是個 PWA，我可以把它當作 App 來期待。」

這也是為什麼 Rahul 一直在強調 Mobile Web 已經 Business ready，並積極與企業合作去推出 PWA 的原因，Chrome 團隊希望用實際的產品來進行推廣。看看華盛頓郵報的這個新版就可以發現，「PWA」 這個名詞是對用戶的。沒有哪個產品會對開屏提醒用戶，嘿我這個是 Isomorphic JavaScript App！但是 PWA 可以，這個概念是希望被用戶接受的，而不止是開發者。

同樣，另一個 Google 大力鼓吹的印度第一電商 FlipKart 也很有意思，他們把自己的官網改為 PWA 後，乾脆就命名叫 FlipKart Lite，然後還拍了宣傳片兼教程來公開介紹這種新體驗以及新技術。（技術營銷也是會對普通用戶產生效果的，看看小米）

在發現了這幾點後，我對 PWA 的理解才終於到了一個新的維度。

推動一個技術的發展其實是多因素的，你要吸引的不止是開發者、還有用戶、還有公司（讓它們使用這個技術）、最終才能讓整個生態建立起來。所以無論 App Store 還是 Google Play 總是要說我們幫助了多少公司/開發者獲得了成功，就是這個道理。

從這個角度來說，「PWA」 可能比單純的技術突破對 Mobile Web 整個生態的影響要更大。開發者之間希望說服對方一個技術比另一個技術更好都是一件很難的事情，跟不要說說服用戶了。我們不能說 「PWA」 完全是個營銷辭彙，但我真心希望這輪對用戶的營銷能夠成功，讓用戶對 Mobile Web 有所改觀，這才能真正解決我上面提到的「用戶習慣難以養成」的問題。

Web 的開放與去中心化在商業角度經常陷入「沒爹又沒媽」的窘境，Rahul 在台上大聲對下面喊 「Google Love the Web!」，然後觀眾席響起了稀稀拉拉的掌聲，看得我很是心酸。

上一輪有著類似可能性的 Web App 推動來自咒死 Flash 的 Steve Jobs ，老喬在 2008 年的 WWDC 上對著世界說：即將發售的 iPhone 沒有 SDK，但是 iOS 1.0 有 Safari，你們可以用 Ajax + Web2.0 創造媲美原生應用的 web app，下面連掌聲都沒有，後來被罵到打臉，不了了之。

最後說說 PWA 的地域性。

一個很有意思的現象是：「Apple 親中，Google 親印」。這可不止是管理層的組成問題，而是對市場環境的「自然選擇」。

全世界都知道中國人土豪有錢能買愛慕虛榮，剛好和 iPhone 的土豪打法臭味相投；雖然天朝網路條件現在相當可以，但偏偏 Google 再遇上個不能描述的問題，兩者地位一下子天上地下。

再看印度，整體還處於「第三世界」，網路條件差，沒錢買 Apple，但也沒有中國的特色問題；於是 Google 一直在打低價、低硬體環境牌，在印度做的風生水起。

Google 的技術在國內推進本身就是很痛苦的，Android 搖身一變「安卓」得以在國內馳騁，但 PWA 在中國的發展則困難重重：

  1. 國內 iPhone 居多，首先就不支持 PWA
  2. 各路 Android ROM 中的瀏覽器早都已經被改的沒有人形了，大家在支持 PWA 這件事情上肯定毫無興趣 —— 什麼添加主屏，與我的利益毫不相關啊。(Android Webview 雖然是基於 Chromium 的，但是版本號差得老遠了)
  3. 原生 Chrome 雖然在國內桌面端的市佔率還不錯，但是移動端應該差到不行。
  4. 在 Web Push Protocol 普及之前，依賴 GCM 的通知推送直接再見
  5. 國內的 Web 環境非常複雜、首先是各種 Webview，然後才輪得到瀏覽器
  6. 國內的互聯網公司大都「技術深厚」，各種黑科技大行其道，哪裡輪得到 PWA

而再看印度，PWA 簡直就是神器：

  1. 由於都是 Google 服務健全的 Android 設備，標配 Chrome，PWA 一推，用戶到達率簡直直逼 100%
  2. 印度網差，下載一個 App 痛苦，一個可以「流式下載」的 PWA 在「用戶初次訪問」這點上就可以完爆 Native App
  3. 互聯網環境還比較原始，公司大都直接親 Google，技術的支持率也會非常高。

所以你看，AliExpress 率先支持了 PWA，但在國內，這一天不知道要等到猴年馬月了。

一不小心扯得有點多，以上。

## 更務實的方向

不再是當年轟轟烈烈要取代 Native App 的架勢了，那一撥熱潮為了模擬比拼 Native App 的體驗真是費老了勁，後來大家明白這個大坑在可預見的時間裡是填不完的，而 Web 本就有自己的優勢和領域，何必去人家地盤死磕？

PWA 的提法更加務實，提倡漸進式地應用新技術，讓 WebApp 變得更加對移動環境友好，體驗自然順滑。PWA 提到的所有的技術都是獨立可選、漸進增強的（可以預見隨著瀏覽器飛快實現新特性，PWA 所包含的技術項目也不會局限於目前這些），都是為了比現在更好，沿著 Web 的康庄大道持續進化，而非瞄準那個「取代 Native App」 的目標。

## 關於兼容性

仔細看的話，PWA 的各項技術都遵循這兩個原則：

  • 獨立的。各項技術之間互相沒有依賴，可以逐個實施，無需全盤推進。

  • 增強的。如果某項技術在客戶端上不支持，那就對其無效，僅此而已。實施新特性並不需要做出破壞向後兼容的改動。

這兩點體現了 PWA 中 P（progressive）的含義——漸進式增強：不行的環境就放它不行，行的環境要讓它發揮出行的價值。這個價值立竿見影可衡量（https://developers.google.com/web/showcase/），並且會隨著時間推移，被瀏覽器新特性的普及給進一步放大。

總的來說，

## PWA 不是一套固定的技術或規範，而是個理念。

Web是開放的，自由的，互聯的。問題國內各家互聯網公司哪家要想要開放，自由，互聯來著，都想著自己的應用佔用最多的CPU時間（用戶可見或者不可見的時間）...

Progressive Web App在國內沒有太多前景基本上是可以預見的，單就說Splash，WTF，只能靜態畫面？不能搞動畫，活動推廣，打廣告，播放視頻，一點卵用也沒有嘛。

國內應用需要的是原生應用所有的許可權能力和使用體驗，加上 Web 的內容部署靈活性。

雖然 PWA 這種形態的應用在國內幾乎毫無價值，不過它背後，Chromium 所付出的內核性能的改進，新標準/特性的支持還是很有價值的，這些技術最終也會改善移動網頁的用戶體驗。

Progressive Web Apps 其實是一系列的 Web 功能和技術的集合，其目的在於增強 Web Apps 的功能和體驗，使之更像 Native Apps。

PWA 並不只是移動設備上，有現代瀏覽器存在的地方就可以 PWA。

PWA 也不是 Chrome Only 的，現代瀏覽器基本都支持

Progressive Web Apps isn』t a Google-only thing https://medium.com/@nekrtemplar/progressive-web-apps-aint-google-s-thing-31ca581e7a1

Progressive Web App是Google今年著重推的一個產品，而同時神秘的東方，微信也推出了一款叫做「小程序」的產品。這個回答著重講講PWA，再扯扯小程序。

Progressive Web App其實嚴格說來不是一個產品，而是一種理念，或者叫打包產品，因為他是把眾多能讓WEB產品APP化的能力的一個集合。

從Google官方網站介紹內容提煉一下，PWA的三大基本能力分別是：

  • 類APP交互
  • 消息推送
  • 離線緩存

類APP交互是指，PWA是Google提出並推廣的，而採用Google定義了PWA需使用Material Design的設計風格，因此目前大部分網站都採取的是MD的設計（然而這種限制反而是對PWA本身的違背）。除了MD的設計，其中還包括app cache shell（分模塊載入）、添加到桌面、全屏瀏覽、任務切換器中以單獨任務存在，智能app引流橫幅等一系列相關的東西。

消息推送，這個也不是新鮮的產品了，PC上很多網站都可以藉助瀏覽器來發送通知，但PWA的消息推送還是有些區別的，由於他是走的GCM（FCM）通道，因此不依賴於瀏覽器和頁面本身是否打開，就可以直接通過Android底層的通道觸達用戶，並且整個消息的展示和點擊流程和app幾乎一模一樣。通過這個產品，之前web端無法主動觸達用戶的問題得到了極大的解決，但遺憾的是，這個消息推送是需要用戶主動訂閱的，那麼這個漏斗....

離線緩存，這塊整體比較偏技術，大概就是可以把網站的內容緩存在本地，下次訪問時如果是弱網或斷網的情況下就可以不走網路請求，而直接將本地緩存的內容展示給用戶，優化用戶的弱網及斷網體驗。

說了這麼多，那麼Google為什麼會和微信一樣在今年重點推這類WEB APP呢？個人淺見，Google掌握了Android的應用商店分發Google Play，但在iOS這邊一直挺難有建樹，甚至Chrome在iOS中也只能用Safari內核。但iOS中還是有非常多的搜索流量，這部分流量如果能更好的變現對於Google本身來說將是一件好事。流量的背後則是各家公司的wap站點，如何優化這些站點的體驗，讓用戶更願意在手機上使用Google搜索則是痛點。

PWA的出現恰好幫助Google完美的解決了這個問題，那麼不論之後移動互聯網的發展是向web app還是native app發展，Google都有了自己的一張牌。那這也可能是iOS不願意跟進PWA的重要原因之一。

那麼再說說微信小程序，這個已經有很多文章提到了，微信想在自己的生態圈中打造一個app分發的市場，就是所謂的wechatOS。這個和Google的考慮是比較雷同的，我有流量入口以及巨大的流量，如果在我app內後續的web產品體驗更好，用戶就不會離開微信而去使用其他app了。如果小程序真的能幹掉其他app，那這個生態帝國真的是比iOS或者Android更恐怖的一個存在。

P.S. https://m.alibaba.com 是全球第一家實現PWA的B2B網站，歡迎各位體驗。

Google 11月PWA CASE STUDY alibaba.com

首先，PWA 是啥？ PWA 全稱是: Progressive Web Apps。這是 2016 年，Google I/O 大會上提出一個 Next Web Generation 的概念。這並不是描述一個技術，而是一些技術的合集。PWA 是專門應對手機 Web 開發而提出的，通過新技術的成熟，實現最好的 Web + 手機 APP。也就是說，能讓你在使用 Web 的時候感覺像是在使用 APP。

如果是初創公司想推出一款新的產品，首選型是 Native APP，那麼，可以預計該公司在吸引流量的時候，一定會感覺到 這真 TM 難。不過，我這也並不是說，你選型使用 Web 就一定容易。本質上還是需要該產品打磨的足夠好才行。不過，我們話說回來，在初期，Native APP 和 Web APP，在傳播上的難度還真不是一回事。

首先，Native APP 需要經過反覆審核，滿足不同平台的各種奇怪機制以後，才能正式上線。然後到用戶端，小白用戶通過公司的宣傳了解到該 APP 之後，他需要經過去各個 APP Store 搜索，找到之後再下載，下載之後再安裝，安裝之後再授權，下了差不過幾十兆(MB)的 APP 之後，才正式的能使用。

那 Web APP 就簡單嗎？恩，相比上面那些繁瑣的步驟來說確實簡單，我們先不說 Web 不需要審核（在中國，有一種痛，叫做備案），最能體現它優勢的地方就在於，只需要一個網址即可（任何平台都會自帶瀏覽器）。那有人可能會問，但，Web 並不能在桌面端創建啥 icon 來直接跳到網址上去啊？不過，這只是針對以前的 Web，PWA 實際上就是幫助我們完成上面提到的事，並且它做的更多。

話不多說，先給大家放一個，將 Web 添加到桌面的 gif 感受一下，並且添加之後，重新打開，會發現 Web 展示的效果變為全屏展示了！

（由於知乎這邊無法載入相關的 gif 在此，我直接放一個鏈接哈：http://static.zybuluo.com/jimmythr/rf2bxrnma3b6utkcteqei6me/add-to-home-screen.gif

）

PWA 原則

當然，並不是所有的 Web 都叫做 PWA。根據 google 定義，PWA 應該具有一下特性：

  • 漸進式：能確保每個用戶都能打開網頁
  • 響應式：PC，手機，平板，不管哪種格式，網頁格式都能完美適配
  • 離線應用：支持用戶在沒網的條件下也能打開網頁，這裡就需要 Service Worker 的幫助
  • APP 化：能夠像 APP 一樣和用戶進行交互
  • 常更新：一旦 Web 網頁有什麼改動，都能立即在用戶端體現出來
  • 安全：安全第一，給自己的網站加上一把綠鎖--HTTPS
  • 可搜索：能夠被引擎搜索到
  • 推送：做到在不打開網頁的前提下，推送新的消息
  • 可安裝：能夠將 Web 想 APP 一樣添加到桌面
  • 可跳轉：只要通過一個連接就可以跳轉到你的 Web 頁面

可以看出 Web 小弟想要成為 PWA 黑幫老大還是有一定難度。那 PWA 到底又需要哪些技術呢？直接上一張圖吧：

入門指南

相關學習，可以參考 JimmyVV/PWA-cookbook。或者可以直接參閱我的 blog：

  • PWA guider
  • 響應式開發
  • Service Worker
  • Web 推送技術
  • PWA 實踐指導

看完不贊的，我們來過兩招：

招聘硬廣

春天來了，大家有沒有想出去看看的慾望呢？
現在，騰訊招聘季一如既往的來了。不管你是技術大牛也好，產品喬布斯更好，當然還有很多很多厲害的運營、運維。想要來騰訊試一試的，可以聯繫我。
本人現在在 騰訊 Now 直播項目組的 ivweb 團隊。團隊文化氛圍好，顏值高，沒有其他不良嗜好，歡迎甩簡歷給我，謝謝老闆們！

郵箱地址：villainthr@gmail.com

實際上Office Web Apps也是可以接入自己開發的系統的。下面介紹一下整合Office Web Apps的一些理論知識。

要想讓自己的系統與Office Web Apps整合就一定要清楚一些概念，首先要理解什麼是」WOPI」。
WOPI的英文全稱是「Web Application Open Platform Interface」，中文名為「Web應用程序開放平台介面協議」。

WOPI協議提供一系列基於web方式的，使文檔能在Office Web Apps中查看與編輯的介面服務（Web Service）。
只要web application按照標準，實現了WOPI的介面，那麼就可以調用Office Web Apps。例子很多，比如SharePoint，Exchange，SkyDriver，Dropbox集成Office Web Apps。
如果自己做的web應用也實現了相應介面，也是可以調用Office Web Apps的。實現文檔的在線編輯查看。

這樣比市面上的一些基於ActiveX的在線Office產品有很大的優勢。
首先Office Web Apps是基於網頁技術，所以是跨平台的，可以在iOS，安卓，WP及PC使用，實現多屏一體。
其次Office Web Apps實現了桌面Office的大部分功能，能在客戶機沒有安裝Office的情況下，實現雲端上的文檔編輯查看。

下面介紹的內容都是基於http協議下的，https也是類似的。

在WOPI結構中，
我們把存放Office文檔的web應用叫WOPI Host或者WOPI Server。
把查看編輯操作Office文檔的web應用叫WOPI Client或者叫WOPI applications。
所以，Office Web Apps充當的就是WOPI Client的角色。
SharePoint，Exchange，自己開發的文檔管理系統充當的就是WOPI Host的角色。

下圖為瀏覽器，server，client三者的請求順序及關係：

從上圖可知，WOPI Client 向WOPI Server發送了兩次請求
1. Tell me about the file
2. Give me the file

所以WOPI client至少要提供兩個Web服務。
1. 一個是CheckFileInfo服務
此服務返回的是請求文件的基本信息，WOPI Host以json方式返回給WOPI Client.
服務URI格式一般為
http://server/&<...&>/wopi*/files/&?access_token=&

此服務返回的json格式類似為：
{

"BaseFileName": "Sample Document.docx",

"OwnerId": "tylerbutler",

"Size": 300519,

"SHA256": "+17lwXXN0TMwtVJVs4Ll+gDHEIO06l+hXK6zWTUiYms=",

"Version": "GIYDCMRNGEYC2MJREAZDCORQGA5DKNZOGIZTQMBQGAVTAMB2GAYA===="

}

Json中至少要包括五個屬性：BaseFileName, OwnerId, Size, SHA256, 和 Version
BaseFileName: 文件名。
OwnerId: 文件所有者的唯一編號。
Size: 文件大小，以bytes為單位。
SHA256: 文件的256位bit的SHA-2編碼散列內容。
Version: 文件版本號，文件如果被編輯，版本號也要跟著改變。
更多參數介紹請參考：[MS-WOPI]: Response Body(v=office.12).aspx

2. 一個是GetFile服務
此服務返回的是請求文件的內容，WOPI host以數據流的方式返回給WOPI Client.
服務URI格式一般為
http://server/&<...&>/wopi*/files/&/contents?access_token=&

注意：CheckFileInfo與GetFile服務的URI格式只差了一個/contents，其他地方的格式是沒有不同的。這麼做是為了讓WOPI client可以通過CheckFileInfo服務URI推導出GetFile服務的URI，千萬不要別出心裁，寫出的服務URI格式破壞了這層關係。
在上述URI格式中，都有一個access_taken身份驗證令牌。這個身份驗證令牌是必須要有的，WOPI client會把此令牌回發給WOPI Host，由WOPI Host驗證當前用戶對當前文件的許可權。所以實際上Office Web Apps根本不涉及文檔的許可權管理。

我們在WOPI client上打開一個Office文檔的url地址類似如下：
http://wopi-app-server.contoso.com/wv/wordviewerframe.aspx?WOPISrc=

http%3A%2F%2Fmy-wopi-host%2Flocal%2Fwopi

%2Ffiles%2F1-Sample%2520Document.docxaccess_token=

dc172034-c6f9-4a43-bc3f-d80dd93c1de1

這個裡面有兩個傳遞參數：WOPISrc和access_token
WOPISrc參數的內容為：http://my-wopi-host/local/wopi/files/1-Sample%20Document.docx
實際上這個是WOPI Host上的CheckFileInfo服務地址。
WOPI client會通過這個地址加上access_token從WOPI host上獲取到1-Sample%20Document.docx文件的信息；
並且通過這個地址推導出WOPI Host上的GetFile服務地址，通過GetFile服務獲取到1-Sample%20Document.docx文件的內容。

WOPI host上判斷什麼類型的文件應該怎麼用WOPI client打開，WOPI client會提供一個xml文件給WOPI host，這份xml文件叫WOPI Discovery。格式類似如下：
&

&

&

&

&

&

……

&

……

&

&

如上所述，打開doc文件，應該使用https://wopi-app-server.contoso.com/ wv/wordviewerframe.aspx的url打開。
WOPI host應該獲取這份文件一次，以後打開什麼類型的文件，調用什麼url自己判斷。

個人認為web app前途可期。現在在手機上面其實在走著和PC上面一樣的道路。當年因為網路不發達和各種硬體限制。PC上就是app起步的。因為app就是省流量，就是運行流暢。但是到了後期，實際上大多數的流量已經是網頁版帶來的了。因為網路已經很好了，硬體已經有些過剩了。app的完善實際上在這個時候已經不是優勢而是臃腫劣勢了。只有少數的遊戲這種非常吃硬體的產品是app了。大部分人聽個音樂看個電影看看新聞什麼的，瀏覽器就能解決問題了，根本沒必要安裝軟體，用軟體還等更新什麼的。有人拿出當初喬布斯的預言來說。但實際上，當初喬老爺子提出這個想法的時候，html5還沒有定稿，網路硬體設施其實也還不是很完善。天時地利人和都還沒有到位。當然這也從另一個側面看出喬布斯看的其實還是長遠的。但是當前各項條件已經滿足條件大半了。我認為PWA應該是吹響手機端app流量向web流量轉移的號角了。

僅從中國來說，有人說流量和網速的問題，但實際上，現在中國大部分手機用戶已經是3G和4G用戶了，拿本人來說，套餐流量已經是1G了，家裡公司還有WiFi，流量根本就用不了。開一個網頁可能也就1到2秒。起步網速和流量已經不能和幾年前相比了。手機硬體上面，實際上運行web應用已經可以很流暢了。打開一個網頁可能也就1到2秒。但是開一個app，算上有的還有啟動屏幕廣告。沒個5秒左右根本不可能真正能用到。實際上真正的app已經有相當的數量實際上就是app套了個殼。大部分利用的還是html5的技術了。PWA技術其實就是phonegap之流的進一步web化的版本。除了google服務無法在大陸使用這一點之外，實話說，我個人是沒看出來為什麼不上船。需要注意的是，最近微軟也已經鬆口edge瀏覽器馬上也要支持PWA，按照這個趨勢，只要把把消息推送這一條開放出來形成標準，html5開發者的第二個「春天」馬上就會來了。將來手機上可能最終也和PC一樣形成大部分用PWA，小部分對性能要求特別高的，例如遊戲之類的繼續app。

最後說說微信小程序。個人認為很難成功。第一，騰訊公司畢竟不是系統開發商，騰訊可以開發爆款商品，但是這種技術的變革，個人認為還是需要微軟谷歌這樣的系統提供商來推進的。第二，騰訊想做web的app store，但實際上，凡是有競爭關係的廠商都不可能入駐這是必然的。阿里和百度之類的廠商必然要推自己的小程序商店，騰訊的小程序不可能一統天下。這樣一來，必然還是中立技術（類似html5）占開發主導。一流廠商（微軟、谷歌、蘋果）定標準，二流廠商定產品（騰訊、阿里、百度），三流廠商只能跟隨。

ie8

polymer只是搞個pwa概念

並不一定要polymer

另外 我已經投入polymer懷抱

後台系統需要快速迭代 不需要考慮兼容

我早就已經使用 新技術帶來新感受

我就使用webrtc構建了辦公室跨部門交流平台

我特地做了文檔站

http://139.196.210.78:3000/1.0/

貼出一個視頻地址

2016 google I/O 使用 Polymer 開發 Progressive Web Apps_演講?公開課

google 真拼 都修改開發者工具來推了

今天下午看了下Google I/O上關於Progressive web app相關視頻，簡單的說下自己的一些看法吧！

亮點在與ServiceWorker，可以在web app下註冊個ServiceWorker(以下簡稱sw)。

1.sw可以將要緩存的頁面靜態文件放在瀏覽器的cache中，緩存版本通過設置cachename來管理。

2.註冊sw成功後，web app的靜態文件請求可以被sw所捕捉，判斷是否是緩存中存在的，不存在就然瀏覽器去伺服器抓取，存在就從緩存中抓取。

3.使用sw的web app只能使用https協議訪問。

其他就不一一介紹了，貼個鏈接吧！https://developers.google.com/web/fundamentals/getting-started/your-first-progressive-web-app/。

progressive web app提出的是一種開發模式，使用sw，減少http請求數，來提升web app的性能，然後達到native app的體驗，離線也能愉快的玩耍。但悲劇的是，DOM的增、刪帶來的repaint/reflow的性能依然是個瓶頸。所以，要想達到native app的體驗，progressive web app還是有點差距的。

作為一個用node-webkit+sqlite開發pc應用的程序狗來說，PWA的前景真的很不錯

解決了我們很多產品上的問題 比如，我們用c#寫了前端登陸程序，離線產品載入等問題

應用PWA在現有的支持的瀏覽器狀態下給予用戶更好的體驗，這個就和當初的Hybrid app一樣需要很長的時間來推進演變

WebVR網頁的基本原理其實是通過瀏覽器的WebVR API獲取用戶輸入，進而控制相機的視角，在VR模式下通過VR控制器和VR分屏器以二分屏+gyroscope(使用水平陀螺儀)的方式顯示畫面，裸眼情況下提供全屏+touchmove/gyroscope。黑板報

去年穀歌和火狐針對WebVR提出了WebVR API的標準，顧名思義，WebVR即web + VR的體驗方式，我們可以戴著頭顯享受沉浸式的網頁，新的API標準讓我們可以使用js語言來開發。

國內的實踐可以看看阿里的 m.aliexpress.com,Google

Io 上有過案例介紹。

實在沒看到什麼乾貨。

不就是移動Web么，之前的homescreen app，換個說法又出來啦。

推薦閱讀：

TAG:GoogleChrome | 前端開發 | Web應用 | pwa |