AWTK WEB版移植笔记-序

AWTK WEB版移植笔记-序

一、WEB版本对AWTK意义

AWTK-WEB版本对AWTK是很重要的,主要原因有:

  • 让用C语言开发的AWTK应用程序,在不需要修改源码的情况下,能在浏览器中运行。这样做的好主要在于,可以很方便的向客户展示项目。你只需分享一个链接,客户就可以在浏览器中打开,并看到实际的运行效果,这是一种非常棒的体验。

  • 把AWTK编译成一个JS库,你可以用JS开发AWTK应用程序,并在浏览器中运行。AWTK-JS让AWTK支持用JS来开发AWTK应用程序,并在嵌入式系统中运行,但不能在浏览器中运行。而AWTK-WEB则是让AWTK支持用JS来开发AWTK应用程序,并且能够在浏览器中运行,这打通了嵌入式和WEB之间的壁垒。

  • 开发各种小程序也是AWTK的目标之一。而小程序无一例外都是用javascript开发的,WEB版本移植好了,支持小程序开发也就非常容易了,所以我们需要先迈过这个坎。

二、如何实现WEB版本的移植

要将用C语言开发的AWTK移植到WEB上,就得将C语言编译成Javascript或者WebAssembly,emscripten为这个编译提供切实可行的途径,emscripten是一个伟大的工具,经过不少大型项目的验证,已经非常成熟了,可行性是没有问题的。

但是可行和实际能否搞定是有差距的,写个RTOS内核是可行的,但是实际成功的并不多。能用和好用也是有差距的,甚至是成功与失败的差别,GUI引擎很多,但是90%以上的都只能算是demo。AWTK的WEB不但要能用,而且要好用才行,所以整个移植过程就变得有趣了。

我把在移植过程遇到的问题,面临的各种选择做个笔记,以供有需要的朋友参考。

三、WEB版本的目标及策略

简单粗暴的将AWTK编译成WEB版本,中间遇到的问题和要做的工作可能少很多(当然也许有些问题更难解决)。但那只能让AWTK的WEB版本可用,离好用还有不小差距。为了让AWTK WEB好用,在移植之初就定了以下目标:

1.体积要小。

WEB版本要从网上加载资源,体积大小关系APP的加载时间,对用户体验造成直接影响。为了减小JS的体积,我们做了如下选择:

  • 不使用SDL作为移植层。使用SDL作为移植层,就得加入SDL、navavg、stbimage和stbfont等一大堆东西,这会让代码量加倍,而且字体只能使用APP自己的字体,资源体积就更没法容忍了。

  • 缺省字体使用浏览器自带的字体。字体文件很大,动辄就是几M甚至十几M。缺省字体使用浏览器自带的字体,可以大大降低资源的体积。而特殊字体通常很小,仍然采用APP自己的字体。

  • 图片采用独立资源。这样可以减小显示第一个界面前所加载的资源的大小,等到第一个界面出来之后,可以显示加载资源的进度,这样大大增强用户体验。

2.速度要快。

  • UI和Style数据采用二进制常量,编译到代码中,以减少访问网络的次数,这些数据不大,对代码加载时间产生的影响可以忽略。

  • 图片解码使用浏览器本身的功能。这样解码速度会更快,也避免使用
    stbimage解码库,减小代码体积。

  • 字体解码使用浏览器本身的功能。这样解码速度会更快,也避免使用stbfont解码库,减小代码体积。

  • 窗口动画采用WebGL贴图,可以提高窗口动画的效果。

  • 启用脏矩形算法。不变不画,有变只画变的部分。

3.功耗与性能兼顾。

  • 窗口动画采用WebGL贴图,正常绘制采用Canvas 2D接口。

4.最大化兼容性。

  • 少用或不用第三方库。比如SDL有WEB版本的移植,但是移植到各种小程序可能就有问题,修改第三方的库是非常麻烦的事情,后期维护和升级也是一个难题。

  • 隔离浏览器特定的功能。事件和输入法,各个小程序处理方式不同,Canvas接口有小的差异,必须把它们隔离开来。

  • 保守的使用浏览器提供的功能,避免移植到其它平台时遇到麻烦。

  • 自动适配支持WebAssembly和不支持WebAssembly的平台。WebAssembly很快很小,但是部分浏览器和小程序并不支持,必须自动检查,并加载不同的程序。

你可能感兴趣的:(ZLG开源GUI,AWTK,AWTK)