部分观点较为主观，无引战意思，还望海涵，请勿撕逼。

引言

说起中文编程，易语言绝对是领导者。尽管其有着数不清的槽点，也因此被专业人士嘲讽，但事实胜于雄辩——易语言至今还拥有相对活跃的社区，众多非科班的业余开发者照样使用易语言做出了优秀的软件，也在不少接单平台拿到了足以维系生活甚至不菲的收入。易语言也算是我入开发坑的引路人，最初小学四年级时接触过 VB，本来英语就很差的我差点昏厥 🤪。别看区区几个关键字，光是 int, float, bool 之流就已经很头疼了。后来五年级试用易语言像是打开了新世界的大门，一直持续到初三才转的 JAVA。

转 JAVA 的契机就是 PC 流量逐步迁移至移动设备，再加上中学生使用电脑本来就不多，上课玩手机到是不少 😜。在迁移的过程中，一匹黑马打乱的这一进程——E4A。这是一个第三方仿照易语言开发的面向 Android 的中文开发工具，最初是基于已经停止维护的 Google Simple 语言开发而来。开发 Android 应用是许多易语言用户的心愿，当然也包括我在内。幸好当时的 E4A 还是萌芽时期，各种支持库非常不完善，甚至达不到「可用」的标准，否则或许我就错失了转向正规军的最后机会。（此处正规军指的是对应平台官方支持的原生开发，无歧视含义）

现在是2020年了，吴涛先生憋了多年的大招虽然姗姗来迟，但也在稳步发展——火山软件开发平台。显然这与 E4A 不是一个量级的产品，也体现了吴涛先生宏大的理想：做一款中间语言，能够编译到各个平台从而实现真正的大一统。这个想法并不罕见，但打出中文的口号倒是首家，吴涛先生将其称为语言之上的语言。尽管早已转向更大众的技术栈，但仍情不自禁地关注中文开发的动向，近期在研究 libGDX 相关东西无意中又搜到了火山安卓开发平台的相关内容，或许这就叫羁绊吧。

偶遇&现状

libGDX 是一款采用 JAVA 的跨平台游戏框架，近年来由于国内环境问题，个人独立游戏渐渐没落，而大型游戏通常需要更专业的游戏引擎，因此 libGDX 国内资料奇缺。而在搜索引擎给出的结果中，几个近期发布的页面格外醒目：LibGDX引擎里面有没有封装box2d库? - 火山安卓俱乐部 - 火山软件...。没想到火山官方团队也瞄准了这一开源框架，在 Volcano3D 游戏引擎较为专业、入门困难的背景下，或许引入这一小巧的框架能大幅提升火山安卓开发平台在游戏方面的表现。

老友邂逅定当叙叙旧，我花了近2天时间大致了解了下 E4A 与火山安卓的现状，也重点关注了 libGDX 支持库发布后的市场反应。结论有点遗憾，目前看来整体不尽如人意。

火山安卓官方论坛日均帖子数在50左右，其中还包括很多官方的模板式回复，与易语言难以相提并论，相当于小众中的小众。

火山安卓曾也有引以为傲的作品— Pandownload 安卓版，随着不久前 PC 版开发者被逮捕，安卓版相关帖子也被迅速撤掉，尴尬的是，在此之前，火山甚至使用官方账号对 Pandownload 大肆赞扬，并赠送其一套正版火山密钥以资鼓励（原帖已被删除，当时截图不完整没有体现发帖账号）。除此之外，官方账号还为一个疑似炒共享经济概念的产品做推广，原帖备份在此)。当然，作为平台的开发方对自家平台开发出的著名软件鼓励推广是无可厚非的，但类似 Pandownload 之类处于灰色地段的程序，竟然毫不避讳地用官方账户表扬着实值得商榷。这也侧面表明火山开发平台遇到了和易语言类似的情况，即用户多是非专业人士，所开发的产品往往也是非专业产品。常规的小工具基本上没有发展空间，唯独灰色产品（例如采集、破解、外挂）或者打一枪换一炮类产品有增长的可能。毫无疑问这种生态对平台的发展是非常不利的，火山官方不清楚是真的不知道，还是没有办法，竟然将这一不利因素视为救命稻草，妄想借此来壮大生态，其后果难以想象。

libGDX 类库或许因为发布较晚，目前社区还没有太多的讨论，同样没有成功案例出现。论坛里仅有的帖子则全部是封装 bug 的反馈。这不禁让我想起 Cocos2d-js 引擎的困难处境。Cocos2d 一开始是 IOS 端游戏引擎，后来发展为跨平台，进而引入了 Lua 脚本后期又引入了 js 脚本，并实现 js 绑定。Cocos2d 曾希望将开发的重点转移到 js 来实现对 html5 的支持，对于 Native 设备则是将 js 绑定到原生 API。不巧，原生 API 经过多轮改变已经非常混乱，于是又引入了绑定生成框架在自动化这一繁琐的任务。折腾了许久，Cocos2dX 原生引擎，以及衍生引擎基本上都停滞了，重点转向了 Cocos Creator 这一对标 Unity3d 的全新平台。我最后接触 Cocos2d-js 是在2018年，那时 js 绑定非常不完善，众多 API 在 web 端与本地端行为不一致，甚至函数参数都不一致，对于一个一跨平台为卖点的产品，这是致命的打击。

类似的，火山平台也面临了同样的问题。

理想&现实

毫无疑问，火山开发平台的设计理念是先进的，理想是宏大的，可是现实是骨感的。多平台的大一统微软曾实践过，但是失败了，原因是新兴系统的生态无法与成熟的 Android IOS 相匹敌。火山平台似乎很聪明，它无意挑战任何一个已有平台的地位，而是作为一个中间语言屏蔽各个平台之间的差别，向上提供统一的 API。同时这种想法并不是建立在任何一个行业标准之上，竟然自己设计了一套接口，并以封装类库的形式实现。这也可以理解，毕竟行业标准都有其适用范围，自己的轮子则是完美兼容的，这才能支撑起如此宏大的理想。

一切似乎都很合理，除了工作量。目前，跨平台的东西基本有以下几个思路：

• 借助 web 标准实现。
• 借助行业标准实现。例如游戏引擎多是借助 Open GL。
• 仅有逻辑实现。例如 Lua 脚本语言。

Flutter 是 Google 主导的跨平台框架，尽管是 Google 这种巨型公司，Flutter 目前来看也仅仅是火山开发平台的一个子集。火山平台没有使用 web 标准—它直接对接目标平台的原生接口；也没有使用行业标准—它直接对接目标平台的原生组件；也不仅仅是逻辑实现—包括了UI、传感器等平台相关的特性。理论上火山平台拥有最高的灵活性，任何原生平台拥有的功能都可以封装到火山，听起来好像很完美，却有以下几个缺点：

封装工作量

全部对接原生平台意味着每一个平台的每一个接口都需要封装一遍，我粗略浏览了一下封装手册，这是个极其复杂繁琐的过程，出错率极高，上述官方对 libGDX 封装多处出错印证了这个问题。封装开发者需要同时掌握火山平台与目标平台的知识，还得有足够的耐心，短时间内还需“用爱发电”，最终工作成果还依赖一个不开源的商业平台，我不知道这究竟会挫伤多少积极性，但就现在来看，除了官方团队以及官方认证的培训团队，罕见有人自愿承担这一工作。

JAVA、Kotlin、Android 本身已经组成了庞大的生态，火山平台现在想靠官方的力量进行包装实在是不敢苟同。何况这还是一个开源社区，每天都有无数代码被贡献、审查、合并，就连很多生态圈内部的框架都跟不上更新速度，更别提一个外来者。

现在火山视窗平台（PC端）已经蓄势待发，这将又是另一片生态的海洋。随之而来的还有 IOS、WEB 等本身就非常复杂的平台，即便是发动整个社区的力量都算是十分艰巨的任务，难以想象火山官方如何应对。

UI 设计

对接平台原生组件意味着将 UI 的主导交给了别人，原生组件又依赖原生环境，火山平台还希望在一个统一 IDE 中进行开发，这本身就是矛盾的。于是出现了非常影响开发效率的问题：UI 无法实时预览。例如火山安卓的视图编辑器，所有组件都只是一些条条框框，样式完全丢失，更别提 ConstraintLayout 这种现代化的布局了。这一点与易语言有很大区别，移动设备的硬件属性注定了其界面设计与 Windows 的绝对定位不同，不同平台有自己的布局方案，这本身就是一个大的话题。将这些布局原样整合到一个 IDE 中实时渲染，还要跟进更新，几乎就是不可能的事情。原来是为了简化开发，结果却连屏幕适配都要消耗不少时间。

跨平台可用性

显而易见的，这种类似于 API 绑定的实现方式不可能跨平台，也即：凡是用到了对应类库的代码都只能在对应平台才能运行。火山平台的目标用户是非专业的个人开发者，他们大概率不会懂得 MVC、MVP、MVVM 之类的架构，编码过程中也不会过多考虑什么「单一职责原则」，于是代码耦合非常严重，数据、算法、界面几乎整合在一起。界面肯定是平台相关的，那么最终结果是整个程序失去了跨平台的特性。但为了跨平台，火山的设计又非常复杂，最终功亏一篑。花费了极大的代价层层封装，屏蔽了底层差别，结果一个 UI 就打回原形。

如果一个产品给用户期望太高，那么落差就会很大。火山视窗呼之欲出，社区的声音也此起彼伏。不仅希望火山安卓的工程能直接跑在 PC 上，还希望能把易语言甚至 C++ 的代码直接转为火山代码。这也是意料之中，火山屏蔽了底层实现，让很多用户误以为一切的一切都是火山的功劳，而同为火山平台，安卓与视窗（PC）的互通也就水到渠成了。但现实不是这样，火山官方也没有任何引导或暗示告知用户事情不是他们想的那样，那么当火山视窗真正发布，用户发现几乎所有代码都不能重用时，将会是怎样的心态？

飞机很大，但需要飞行员

要想真正发挥火山跨平台的优点，必须做到程序的结构化、模块化。然而现实是很多火山开发者连继承、多态、重载都还搞不清楚。众多封装的 bug 需要开发者自行查阅目标平台的英文文档，理解目标语言的语法，再来修复封装问题。火山论坛一位用户在多次查阅文档修复 libGDX 封装问题后发觉自己已经不需要火山了，火山没有给他的开发带来便利，反而成为了累赘。

火山像是一架笨重的飞机，非常庞大、包罗万象，但细节又严重缺失，速度不如战斗机、容量不如运输机、样式不如特技机。本意是让一个非专业的飞行员可以轻松驾驶，结果飞是能飞，但是摇摇晃晃。若想飞的好，必须同时掌握战斗机、运输机、特技机的飞行技巧，这与设计目的完全相反。如果真的有人掌握了所有技巧，那自然是没有必要驾驶这个庞然大物了。根据自己的需求选择不同的飞机岂不美哉？

中文移动开发还有没有可能？

肯定有。移动开发的市场只会与比易语言更大，而不是更小。针对火山平台现状，私以为从用户角度，其最大的问题是它跨平台特性未能傻瓜式地发挥作用，却要求用户具备较多的专业知识。同时为了做到这一实际上没有什么意义的特性，还花费了巨大的代价，以至于 UI 功能十分的山寨甚至连 E4A 都不如。从平台角度，火山设计的过于灵活，灵活性超出了官方的维护能力，甚至也超出了社区的维护能力。就算火山平台后续拥有2倍于易语言社区的活跃度，也不可能维护那么多库的封装。相对而言，采用类似 Flutter 自主渲染的方式也许能降低跨平台的 UI 维护成本，同时显著提高布局编辑的易用性。也为真正的跨平台打下了良好基础，不再要求用户将 UI 与数据彻底分离。

也许在行业内显得「不入流」，中文编程依然有他的意义，至少在当下有他的意义。但希望在这片土地耕耘的拓荒者们，梦想虽然要有，但也多考虑一下社区的现状、用户群体的规模以及未来的可持续性。多一些务实的设计，少一些什么民族文化，社会价值之类的噱头，爱国营销已经不是那么好使了。

我非常理解一个新的平台的发展需要时间，类库的完善更是需要时间，但这不是理由。理解归理解，但用户不会买账，市场也不会买账。现在儿童编程已经流行开来，OI 竞赛逐步低龄化，机器人编程如火如荼地发展，python 更是作为一个工具被越来越多办公族接受。这种情况下未来一个与主流平台脱节、依赖自主适配的中文编程平台不知道还有没有壮大的机会。与其大费周折地过度设计，给自己的适配工作挖坑，还不如做好眼下的事情，把 Android 与 IOS 平台尽快完善。PC 端已经有了易语言，何况 PC 与移动终端开发差距还比较大。实在不行把 WEB 技术栈汉化一下然后做一些封装，借助 WEB 的统一标准去开发混合应用也不错。

PS：本来就小众的群体，又出现火山安卓、E4A、猎码这种分化，甚至有用户开始接这三者类库翻译工作的单子，尽管属于市场行为，也合乎道理，但严重地浪费了本身就非常有限的资源，同一个类库被翻译来翻译去，充满了「窝里斗」的韵味。这种社区该如何去融入开源社区？