百度Clouda的初步探索
最近一直比較關注百度Clouda，參加了數次百度Clouda團隊舉辦的技術沙龍，也利用了一些時間讀了開發文檔，下面談談我對這個框架的初步理解：
1.輕應用和Clouda的區別和聯系：
“輕應用”這個詞是百度提出的，但是輕應用的概念并不新，是在原來HTML5 WebApp加入了即搜即用的特色，其他的特點與HTML5 WebApp是完全一樣的。
輕應用 = HTML5 Web App + 即搜即用
百度世界大會上所講的：“移動搜索+輕應用”是滿足海量中長尾需求的最佳模式，可以有效解決應用開發和用戶需求的對接。 其實就是講即搜即用的特點。
一般意義上的HTML5應用的特點：
不需要下載，直接可以使用
不需要安裝，即不占用手機存儲空間
多平臺兼容
目前百度輕應用有三個途徑開發，AppBuilder、SiteApp、Clouda。
AppBuilder是一個App模板，用戶只需要灌入內容，生成的應用基本沒有吸引力，意義不大，是為App開發小白準備的。
SiteApp是為了讓傳統的PC網站轉化為應用，本質上也是一種自動化生成工具，可以快速的把大型網站轉為移動應用，雖然相比AppBuilder要靈活方便，但是需求固定，只適用于少數場景。
Clouda才是百度為開發者提供的輕應用開發框架，靈活有意義。
但經過一段時間對百度輕應用的跟蹤，我發現在百度手機客戶端中已經開始推廣的輕應用中還包含了第4類，也就是傳統的HTML5應用，這些應用并不是使用Clouda框架開發，而是使用傳統Web App方式開發，例如：今日頭條。對于HTML5應用其實UC等廠家已經做了一些嘗試，在手機UC客戶端可以看到首頁中可以添加網頁應用，應用的數量已經很多，包括糗百、奇藝、貓撲、掃一掃等等。實際上這些應用也完全可以進入百度輕應用的列表中，但是這種方式的輕應用與Clouda輕應用的差別就在于缺失了Clouda幾個重要的特色：隨動反饋和部分SEO能力。
一般的公司開發一款應用需要兩類開發者，服務器開發和客戶端開發，這兩者的技術差異很大，即使是服務器使用Java，客戶端用Android，除了基本語言是Java外沒有其他的聯系，而且服務器和客戶端交互的時候，仍然需要將Java對象序列化為json數據，客戶端接收到在進行反序列化。服務器使用什么語言對于客戶端來說都一樣，都需要再寫解析程序。對于我們來說，之前我們采用服務器端通過反射機制自動生成接口代碼的方式節省客戶端的工作，也節省了修改接口文檔的工作。但是Clouda開發方式更加徹底，完全不需要糾結于此，徹底的打通了服務器和客戶端，不需要再書寫接口文檔，不需要生成接口代碼，服務器和客戶端代碼本身就在一起編寫，這也就是百度所說的云端統一，實際就是服務器和客戶端統一，好像現在大家都喜歡把服務器稱為“云”，可能聽起來更拉風吧。
百度對Clouda的開放態度
從Clouda的github項目sumeru所采用的協議MIT來說，在這個協議控制下的開源程序基本沒有法律風險，使用者可以修改、再發布、商業化等等都不需要知會百度，這個角度來說對個人還是公司都沒有風險。但有的公司發布的開源項目在開源一段時間后同步發布商業版本，公司不再對開源版本進行更新，完全交給社區，僅更新商業版本，這回導致開源項目受到極大的影響，目前來看，百度有著更大的抱負，沒有理由為從Clouda項目拿少量收入而使自身名譽受損，而且如果Clouda模式成功，這種做法也會推動社區開源版本的去百度化，嚴重影響百度的戰略布局。所以綜合兩種情況來看使用Clouda都是安全的。
初步使用感受
Clouda框架實現了MVC架構，應用代碼結構清晰條理，作為最重要的樞紐，Controller，三個主要時態分工明確，onload()函數中用來執行數據的訂閱，是MVC中Controller和Model建立聯系的過程；這個函數中的代碼如果開啟了Server渲染，則很可能會在Server端執行，這也就是為什么Clouda框架開發的應用冷啟動速度優于一般的HTML5應用，因為在onload()函數中，服務器執行了部分js代碼，使得客戶端節省了這部分代碼在服務器上執行的時間。
onrender()函數負責對View的渲染和轉場，是MVC中Controller和View建立聯系的過程；
onready()函數負責在View渲染完成后，完成事件的綁定、DOM操作等業務邏輯，其中的代碼都是運行在客戶端的，所以可以使用前端js中的變量和函數，比如window, document等。在百度技術交流會上童遙大牛也解釋過，他們正在做服務器端執行剩下部分js代碼的工作，我的理解是dorender()代碼中的js部分，所以如果真的實現的話，應用的冷啟動速度會進一步提升。當然這個技術是在用空間換時間，服務器執行了js代碼，渲染了HTML，結果會一起發送給客戶端，相比原來的頁面，HTML內容應該更多。
下面是todolist例子中的代碼片段：
- App.todos = sumeru.controller.create(function(env, session){
- // 第一時態：Controller需要使用的數據都在這個時態加載，訂閱發布數據
- env.onload = funtion(){
- return [getMsgs]; // 這里返回一個fuction
- };
- // 第一時態講解：如果您開啟了Server端渲染，那么在onload函數中需確保onload中，沒有使用前端的js中的變量或函數，比如window，document，Localstorage等
- // 第二時態：負責對View的渲染和轉場
- env.onrender = function(doRender){
- doRender('todos', ['push', 'left']);
- // 第一個參數定義了Controller和view視圖的綁定
- };
- // 第三時態：在View渲染完成后，事件綁定、DOM操作等業務邏輯在此時態中完成
- // 每段邏輯使用session.event包裝，從而建立事件和視圖Block的對應關系
- evn.onready = function(){
- };
為什么相比于普通的HTML5 Web App，Clouda框架開發的應用可以實現即搜即用？
從上面的說明可以看出由于數據綁定在onload函數中運行，而Server渲染是默認開啟的，也就是這段代碼是可以在Server端運行的，所以搜索引擎的網絡爬蟲是可以再次運行這段代碼，獲取到應用內的數據，而傳統的數據只有在客戶端才可以訪問，如果搜索引擎要抓出應用內的數據，那就意味著他必須重建環境，在服務器端運行客戶端程序，現在看來只有在搜索服務器上搭建移動端虛擬機，例如android虛擬機、iphone虛擬機，好像目前還沒聽到有公司使用這樣的方式抓取內容。
Clouda框架中沒有UI部分
Clouda框架更偏向于數據層，沒有UI部分，用戶可以使用網絡上通用的UI框架，比如jQuery mobile, Kendo UI, Sencha touch等。
我認為未來越來越多的創業團隊會選擇Clouda進行快速研發，短期內就可以得到產品驗證和反饋，大公司由于有歷史原因，原有的服務都是使用java或PHP編寫，數據庫是mysql或者mongodb，和Clouda對接有一定的難度，即使數據庫采用的是mongodb，原有的客戶端改寫了mongodb數據，如果不進行進一步開發，Clouda是無法感知數據庫中數據的變化，失去了實時性這個特色。另一方面，大公司在原有的平臺上已經考慮了HTML5 Web應用，從UC的網頁應用數量可以看出，一般的HTML5 Web應用開發方式和傳統的Android，ios，Winphone開發方式類似，web獨立代碼，作為第四個平臺，服務器端復用，使用ajax方式請求接口，可以滿足目前移動網頁端的布局。
傳統從來都會短期消失，習慣也不會一天改變，對于新興的優秀技術，只要先進，能加快研發進度，實現效果，最終一定會成為一股潮流，至于是否能成功還有很多因素，希望百度能夠堅持下去，有大公司支持的開源項目生命力會更頑強，有百度的大力宣傳，才會有更多的開發者知道Clouda。
之后希望從更加技術的角度討論Clouda平臺開發。
