百度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平臺開發。