Shiba的第0步——构想

之前的一篇文章说了要写个跨平台的框架叫Shiba,现在已经初步完成了功能,是时候来回顾一下Shiba开发过程中的点点滴滴。

写程序最重要的是事前的思考和规划,不要急于立即开始编写代码。

那么要明确三个问题:是什么?为什么?怎么做?

首先,这个框架是什么?这是个跨平台的UI框架,定位于轻量级,需要原生来混合开发,要求完全动态化,并且支持数据绑定。以UI为主,脚本仅仅是作为辅助使用。

第二,为什么要写这个框架?市面上已有的跨平台方案或性能堪忧,或生态堪忧,或开发体验不佳。将原生开发的优点与跨平台相结合或许是个不错的解决方案。

最后,怎么写这个框架?

说实话,我之前还没写过框架,跟别说是跨平台框架了,于是便开始分析现有的跨平台框架的组织结构。

于之前的文章可以看到,诸如React Native这类基于前端技术栈构建的跨平台框架并不是一个理想的参考对象,一是其性能并不是最理想的状态,二是与原生的交互并不是非常好。但仍然有参考价值,例如一个网页的渲染过程是非常具有参考价值的。

而基于自绘的跨平台框架如flutter,也是类似,与原生的交互并不是很好,这些都是旨在取代原生开发而诞生的框架,与我的初衷不太相符。

最后是基于控件映射,相比之下这是与原生最为接近的解决方案,而目前使用这一方案的Xamarin.Forms性能并不理想。在分析中发现,Xamarin.Forms主要表现在应用体积过大和启动时间过长,再进一步分析,Xamarin在启动时花费了大量的时间在载入mono上,同时mono也占用了大量的应用体积。所以只要去除这一部分,就可以解决大部分问题。

首先确定下技术栈,必须使用native开发,那么就意味着如果不是用C++,那就基本上只能每个平台都写一遍很多东西。最开始的定位是轻量级,如果一上来就使用C++未免有些杀鸡牛刀,万一牛刀没用好弄伤了就更不好了。所以这里决定一些东西就每个平台都写一遍吧。

其次,要确定下语言如何解析。如果不想自己每次改语法都手写parser的话最快的办法是利用现有的parser generator,并且要求能够生成出swift、Java、.Net都能正常使用的代码,Wiki一下,Antlr就出来了。

确定了解析方案之后,就是确定语法了,一开始是想像anko那样,于是照着抄了一下,接着被人提醒这是在重新发明QML,结果一看还真像……

接着,语法确定了,parser也有了,接下来就是如何规划的问题了。

前文有提到,网页的渲染过程是有参考价值的,之前找到一个Google的演讲视频,简单的介绍了一下chrome是如何渲染网页的,简说就是一个网页首先被解析成DOM,接着再不断地transform到其他的tree最终被渲染出来。所以整体架构就以这个为参考,拿到AST之后再经过一些transform最终生成native层的layout tree,整个流程就完成了。

到此为止,这个框架大概的构想已经完成,接下来就是各个平台踩坑的阶段,下篇再进行介绍

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据