百度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平台开发。