APICloud 渲染机制

前言

近些天公司要求用apicloud进行APP开发。
在转载这篇博文之前我想说说我自己的看法，用APIcloud进行开发，开发周期很短，甚至一个不是很多功能的APP，一两周就能搞的定，而这种框架的出现，离不开webapp 流行的趋势。

apicloud 仿照native app 的渲染方式，让原生的h5的渲染能力提高了很多，但是相比原生android 还是有很大局限的，渲染速度大概趋于浏览器渲染与native app渲染之间了，对于webapp 来说已经对是很好了。

现在来大致的说说我遇到的apicloud 的一些小坑。
1、在开发的过程中，不免会遇到加载字体的情况，但是在apicloud中，并不允许我加载字体，也可能是我的操作方式不对

2、对webGL的支持不是很好，包括引入three.js 也不能完美的支持，但是听说倒是对openGL的支持好像很好，可能是因为webGL出现时间太短是新玩意儿，可能支持不是很好吧。

下面是我转载的博友的一篇博文，简单明了的说了一下apicloud的渲染机制，利用js桥接和native app桥接的一些机制，图是apicloud官网给出的图。

附上原文地址 : http://blog.csdn.net/a897958480/article/details/53448898
如果对APICloud有过了解的人，应该很容易知道，APICoud是什么，说简单点：APICloud其实就是一个平台，一个专门为从传统WEB开发向移动端转型而定制的平台，你只需会HTML+CSS+js这些你就可以开发出一个满足基本需求的应用，那么我下边主要谈的就是既然都是使用这些前段技术，那么他们在页面渲染方面是一样的吗？
浏览器的渲染机制：首先加载一个页面之后，我们会对该页面进行解析，解析之后我们会产生一个DOM树(即把不同的标签解析成Token)，然后再按照HTML的标准我们产生一些对应的Element；那么同时我们会对js和css进行解析和执行，那么解析完之后，我们会对照着DOM树和相应的css样式，我们会产生一个layout树，其实这个layout树是由许多block组成的(这些block我们可以理解成内存上边的一个一个的块)，那么这些块就包括了宽高、属性、颜色、以及其他各种样式信息，那么有了这些样式信息的layout树之后，我们就要进行一个render，render就是把每一个block理解成一个buffer，那么最终我们会进行一个绘制的过程，会将所有的这些buffer绘制在一张image上，并且贴到屏幕上。(下图非原创)

原生开发的渲染机制：在原生中一个页面是由所多层组成的，大到一个view小到一个button，他都是一个独立的层次，每个层次之间是相互独立的，就是说如果我们一个应用有50个界面，那么这50界面是相互独立的，那用APICloud的方式其实现，你不用去建一个很大的DOM树，由50个DIV由50个DIV来进行切换，那么用APICloud方式去做，你有50个View，你就去创建50个窗口或50window或frame，那么这些窗口或frame之间完全独立的并且每一个window或frame有它自己的DOM树，只是这个DOM树是非常的小，那么所有的这些窗口之间是完全独立的，例外APICloud我们也支持HTML和原生的这种界面混合式的渲染，不管是这种WEB View的界面还是自定义的我们扩展的UI模块，其实他们之间都是相互独立的，并且我们给它提供了一套统一的渲染排版的机制，所以APIClound的这种渲染机制跟原生的渲染机制是完全一样的。