WEB 版本对 AWTK 是很重要的，主要原因有：
-
让用 C 语言开发的 AWTK 应用程序，在不需要修改源码的情况下，能在浏览器中运行。这样做的好主要在于，可以很方便的向客户展示项目。你只需分享一个链接，客户就可以在浏览器中打开，并看到实际的运行效果，这是一种非常棒的体验。
-
把 AWTK 编译成一个 JS 库，你可以用 JS 开发 AWTK 应用程序，并在浏览器中运行。AWTK-JS 让 AWTK 支持用 JS 来开发 AWTK 应用程序，并在嵌入式系统中运行，但不能在浏览器中运行。而 AWTK-WEB 则是让 AWTK 支持用 JS 来开发 AWTK 应用程序，并且能够在浏览器中运行，这打通了嵌入式和 WEB 之间的壁垒。
-
开发各种小程序也是 AWTK 的目标之一。而小程序无一例外都是用 javascript 开发的，WEB 版本移植好了，支持小程序开发也就非常容易了，所以我们需要先迈过这个坎。
要将用 C 语言开发的 AWTK 移植到 WEB 上，就得将 C 语言编译成 Javascript 或者 WebAssembly，emscripten 为这个编译提供切实可行的途径，emscripten 是一个伟大的工具，经过不少大型项目的验证，已经非常成熟了，可行性是没有问题的。
但是可行和实际能否搞定是有差距的，写个 RTOS 内核是可行的，但是实际成功的并不多。能用和好用也是有差距的，甚至是成功与失败的差别，GUI 引擎很多，但是 90%以上的都只能算是 demo。AWTK 的 WEB 不但要能用，而且要好用才行，所以整个移植过程就变得有趣了。
我把在移植过程遇到的问题，面临的各种选择做个笔记，以供有需要的朋友参考。
简单粗暴的将 AWTK 编译成 WEB 版本，中间遇到的问题和要做的工作可能少很多（当然也许有些问题更难解决）。但那只能让 AWTK 的 WEB 版本可用，离好用还有不小差距。为了让 AWTK WEB 好用，在移植之初就定了以下目标：
WEB 版本要从网上加载资源，体积大小关系 APP 的加载时间，对用户体验造成直接影响。为了减小 JS 的体积，我们做了如下选择：
-
不使用 SDL 作为移植层。使用 SDL 作为移植层，就得加入 SDL、navavg、stbimage 和 stbfont 等一大堆东西，这会让代码量加倍，而且字体只能使用 APP 自己的字体，资源体积就更没法容忍了。
-
缺省字体使用浏览器自带的字体。字体文件很大，动辄就是几 M 甚至十几 M。缺省字体使用浏览器自带的字体，可以大大降低资源的体积。而特殊字体通常很小，仍然采用 APP 自己的字体。
-
图片采用独立资源。这样可以减小显示第一个界面前所加载的资源的大小，等到第一个界面出来之后，可以显示加载资源的进度，这样大大增强用户体验。
-
UI 和 Style 数据采用二进制常量，编译到代码中，以减少访问网络的次数，这些数据不大，对代码加载时间产生的影响可以忽略。
-
图片解码使用浏览器本身的功能。这样解码速度会更快，也避免使用 stbimage 解码库，减小代码体积。
-
字体解码使用浏览器本身的功能。这样解码速度会更快，也避免使用 stbfont 解码库，减小代码体积。
-
窗口动画采用 WebGL 贴图，可以提高窗口动画的效果。
-
启用脏矩形算法。不变不画，有变只画变的部分。
- 窗口动画采用 WebGL 贴图，正常绘制采用 Canvas 2D 接口。
-
少用或不用第三方库。比如 SDL 有 WEB 版本的移植，但是移植到各种小程序可能就有问题，修改第三方的库是非常麻烦的事情，后期维护和升级也是一个难题。
-
隔离浏览器特定的功能。事件和输入法，各个小程序处理方式不同，Canvas 接口有小的差异，必须把它们隔离开来。
-
保守的使用浏览器提供的功能，避免移植到其它平台时遇到麻烦。
-
自动适配支持 WebAssembly 和不支持 WebAssembly 的平台。WebAssembly 很快很小，但是部分浏览器和小程序并不支持，必须自动检查，并加载不同的程序。