本文由公众号EAWorld翻译发表，转载需注明出处。

作者：Timo Railo

译者：白小白

原题：Why most low-code platforms fall short on mobile development

原文：http://t.cn/Exd4Gg1

白小白：

文章翻好后，我请一位在移动平台领域工作多年的同事看了下，他的看法是，首先文中所讲的一些内容并不适合中国的国情。比如，从他接触的客户来看，多数大厂的技术路线已经不考虑对基于WebView的应用整合。从UI模型的角度看，RN、Flutter（谷歌推出的移动框架，已经发布到1.2版本）包括国内一些业界的移动平台从未强调低代码，但是强调代码通过UI模型与设计尽可能连贯。

从文中所述的情况来看，国外的移动平台，至少在以私有方式部署的移动平台领域，技术上或者说技术的应用上相对于国内还是有所落后的，比如文中所说的未见有企业级实践的React Native技术，就国内来说，金证股份，韵达快递，张家港农商行，中信重工，陕西国土等行业用户都已经基于RN技术的移动平台建设了自己的移动应用。

从我个人的角度，我认为文中关于选择移动平台的考量要素，对开发者的体验重视，以及对遗留系统的整合等内容的阐述，还是有一定的参考意义，因此还是推荐给大家看下。欢迎在文后给出评论，讲下自己的看法。

简单说一下背景：从Mac OS 9的时代（大概是1980年代末）以来，我一直在使用各种不同的快速开发平台和低代码开发工具。这些工具和平台让我爱恨交加。理想情况下，工具可以帮你节省80%的工作，但却对剩余的20%无能为力。同时，从Sybian系统大行其道的时代开始，我就从事与移动应用开发相关的工作，那是苹果公司尚未在移动应用领域掀起惊天革命的年代。

我的另一个身份是Appzio公司的CTO，公司的主业是为原生移动应用开发提供低代码开发平台。我们曾经把Appzio的设计理念定义为“人人皆可开发应用”，当然，我们很快意识到这是一个严重的思维误区，并摒弃了这个理念。

可以说，我对这个行业知之甚深，并愿意分享我的如下观点：多数的低代码平台在高质量的移动应用开发方面并不尽如人意。

依据以往的个人经验，我会揭示一些低代码平台所固有的缺陷，并提出一些值得被关注的重要问题，这些问题往往会被大多数人所忽略。本文适用于iOS或者Android移动应用的开发。

一、可视化配置VS代码开发：收益递减的临界点

能够让你以可视化配置的方式或者编辑器来开发移动应用的工具多如牛毛。像是Mobile Roadie、Good Barber、AppyPie、AppMachine这类工具还提供了预定义的功能模块和基于网页的配置工具。但这些工具的成熟性还存在一些问题，并且也无法提供额外的特性。

AppyPie的配置界面

诸如Mendix、Outsystem、Appian和Kony这些企业级工具提供了复杂的可视化编辑器。起初，这样的产品设计可以让人更快上手，至少可以更容易的完成一些Demo应用。但用久了这些基于浏览器的可视化工具，你就会开始怀念传统的编程界面了。

Mendix的可视化编辑器

当我们依据“人人皆可开发应用”的理念重新定义Appzio平台的产品功能的时候，设定了相当高的指标：我们希望平台输出一个实用的，完全原生的移动应用，拥有应用内购、实时位置等原生功能，最重要的是，提供完全原生的用户体验。我们已知的是，可视化的构建器并不足以满足这样的需求。

打造一个全原生的移动应用体验需要拥有用户体验和最佳实践方面的知识积淀，并深入理解业务逻辑的运作方式。这就导致我们前述的那一大坨产品功能设定显得过于复杂，简单讲，要想做到这一点，工具的使用者必须是一个程序员。而如果你是一名程序员，代码开发对你来说，是解决复杂问题的最佳和最快的方式。

学习使用一个可视化的工具，意味着你不得不学习一种新的编程范式，并且这种范式本身不可避免的存在局限性。即使学会了工具的使用，也很快会到达收益递减的临界点。换句话说，在不同的菜单和配置项之间绕来绕去所花的时间甚至比你直接写代码来得还要长。而且最终还往往不能完成全部你想要的功能。

基于这样的原因，我们放弃了可视化配置界面的理念，转而把精力花在优化基于代码的开发过程，并且建立一个平台，提供更高的开发速度且并不牺牲灵活性。

二、Gartner忽略了什么？

Gartner的“企业级高生产力aPaas”魔力象限研究报告实际上可以作为企业级低代码开发平台的白皮书。长期以来，Gartner使用颇具魅力的字母组合hpaPaaS作为High-productivity application platform as a service的缩写。报告中有一段定义如下：

企业级高生产力aPaaS市场中活跃着很多的供应商，他们致力于为企业级应用以及服务的开发和部署提供从低代码到无代码的云端平台。

十分有趣的是，在这一报告中，Gartner对于终端用户的体验惜墨如金。报告中所提及的多数平台工具不过是提供了一个基于PhoneGap（被收购后更名为Cordova）、JavaScript或者Web View的美化的Web打包器。我想，这也是在这些工具中少有“消费者导向应用”的主要原因。因为他们根本不在意这一点。

移动应用的个人用户和企业用户始终在每日使用的原生应用间比较着用户体验的差异。像是加载时间的长短，界面是否时尚，充满创造力的原生用户界面是最基本的要求，但这些要求往往超越了多数低代码平台的能力。

三、使用低代码平台来实现一个定制化的用户体验的真正代价

说说为什么PhoneGap这类工具大势已去。如果你想快速的把一堆东西攒在一起，他们是可以满足要求的，但如果需要更复杂的用户体验，你实际上最好以原生的代码开发来进行实现。或者也可以借助这样的平台来实现，前提是能够提供原生的开发体验以及丰富的自定义功能。

在使用PhoneGap的时候，你不仅需要与JavaScript打交道，还需要与另外两种解释性语言HTML和CSS打交道。

而且，以这种方式建立的应用，大体上就是基于WebView的机制嵌在应用中的一个网页。这将带来如下的缺陷：

• 性能问题
• 缺少原生功能
• 高度依赖操作系统
• JS引擎的异构性
• 多屏适配问题
• 多线程问题
• 同步方面的问题

还有一个流行的替代方案，是使用JS渲染引擎。但这种方式的缺陷在于跨系统多版本和多屏适配的体验一致性。实际上，此处我们还是遇到了一个收益递减的临界点。通常情况下，在原生应用的开发过程中，我们花时间最多解决的往往是如何在不同的屏幕尺寸下显示相同的外观。尤其是在需要原生级应用性能的场景。

当我们在原生代码/Web配置器/JS渲染之间做出选择时，原生代码开发的优势显而易见，所以，一个好问题是：为什么所有的低代码平台都不采用原生代码的方式？这样的架构决策背后有很多原因：

1、遗留系统的问题。很多低代码平台已经存在了很长时间。5年以前，移动开发领域的跨平台框架与其后数年的原生代码开发方式水平相当，然而形势已经发生了逆转，PhoneGap已经慢慢被时代所抛弃。ReactNative在当下炙手可热并且前景广阔，但就我所知，还没有企业级平台基于ReactNative来构建其移动应用。

2、工程师的技能。使用低代码平台来进行工作的工程师大多来自Web开发和后端开发。PhoneGap对于Web开发者来说是一个很自然的工具。而使用原生代码来构建一个平台需要完全不同的技能栈。

3、对Web应用的支持。很多低代码平台可以不只生成移动应用客户端，并且可以生成Web应用或者一个改良的Web应用。采用这样的方法，以打包器的方式来解决移动应用开发的问题成为最佳实践。事实上就是这样。如果我们自己生成可以在原生的iOS系统和安卓系统上提供一致功能的应用，需要付出四倍的努力。

然而，时至今日，原生的移动应用远比以往更加强大。我相信，一些低代码平台的供应商应该重新审视他们的架构并摒弃PhoneGap。

四、好的低代码平台是什么样子？

根据操作环境的不同，评价移动应用开发工具的维度并不相同。为了简化起见，我制作了一张图表来描述低代码平台所需要具备的一些关键特性。也许并不完备，但至少可以在你面临一些关键决断时提供一些决策参考。

图片由EAWorld编译

五、如何加速移动开发？

为了理解低代码平台的价值，最好的方式就是审视一下如何加速移动开发。我将对这个话题做一些扩展，把传统的原生开发纳入讨论。

1、如何加速传统的原生移动应用开发？使用提供了第三方SDK和现成的代码模块的框架实现功能扩展。

2、如何加速跨平台的移动应用开发？使用同时支持iOS和安卓系统的客户端代码库，使用现成的包和模块以及第三方SDK扩展应用功能。

3、如何加速移动应用的后端开发？选择恰当的BaaS（backend as a service）供应商和框架，谨慎的选择编程语言，建立从模型直接生成API的自动化方式，使用不同的模块和组件来扩展功能。

4、如何加速移动开发的规划过程？主要得益于如Invision一样的可视化的原型工具，来建立可实际点击的原型，以及使用提供现成用户界面的UI工具。

5、使用低代码平台来加速移动开发。需要综合使用多种方式，包括使用模板、现成的模块、自动化的代码生成机制、配置化编程、自动化的云端部署、自动化测试、更便捷的开发者协作 、紧耦合的后端和前端开发过程等。

无论使用哪一种方式来加速移动开发，都存在着权衡。比如，如果使用现成的模块，平台是否提供了丰富的配置和定制化功能来满足需要？如果后端使用了无服务器架构，在需要实现更复杂的业务逻辑的场景之下，是否会存在局限性？

六、开发者体验

当今世界，作为雇主，在全球范围内都面临着对开发者的激烈竞争。如果你的开发者不喜欢你选择的平台，这就成为一个问题。无论选择哪一个平台，都存在着难以评估的学习曲线。因此，更易上手的平台将在竞争中有更大的优势。开发者是否能够在平台上快乐的工作，将显著的影响你从平台中所获得的收益。

聪明的开发者可以基于传统的开发模型以一种更加敏捷的方式来开发移动应用。毕竟传统移动开发大多遵循瀑布式的开发模式。低代码平台可以很好的做为敏捷开发工具来使用。

有一个维度可能在评估体系中看来无关紧要，但却对开发者体验产生着显著的影响，即，如何在设备上预览应用程序的变更。对于预览，有三种不同的层次：

1、重新构建：使用Xcode或者Android Studio来进行预览，需要重新构建整个移动应用。这意味着每次变更都需要花费一些时间来看到变更的结果。同时，需要开发者在设备上安装了Xcode或者Android Studio并且配置正确。

2、热重载：仍旧需要重新加载整个应用，但至少不需要在设备上安装什么东西，而且也不会有代码编译的过程。

3、实时编辑：保存变更 ，刷新屏幕，就可以预览变更的效果。

为了更好的阐述从开发者视角看来的不同，下面我给出了两个简短的动态图片，来体现一个简单的文本变更是如何在设备上进行预览的。

热重载(用时2分钟)打开链接http://t.cn/EJtrmtJ查看动图

实时编辑(用时11秒)打开链接http://t.cn/EJtFzYW查看动图

七、当价格成为阻碍

如果你为世界财富500强工作，通常可以认为公司不存在钱不够花的烦恼。但在为移动应用开发申请预算时，情况又不尽相同。无论对于哪种规模的企业来说，花费都必须与预期的回报相适应。

许可证的花费，尤其是应用存在许多用户的的情况下，是很昂贵的。低代码平台的供应商通常按席位、开发者、开发实例来进行收费。很难评估最终所付的价格（这还不包括二次开发的费用）。你的业务收益和时间成本的节约需要与价格相一致。

并且，通常来说，平台越是具有专业性，对于新的使用者越是需要花费更长的时间去熟悉。你需要为此做出时间规划，毕竟想找到熟悉平台的现成的开发者基本上是个不可能的任务。

八、检查表

在为你的移动应用项目寻找潜在的低代码开发平台的时候，下面这个列表可供参考。尝试首先按照业务需要回答问题，然后再看一下所选择的平台是否可以满足要求，这样将有利于比较候选者的差异。

1、用户体验有多重要？是否仅应用于小团队用户，并且可以接受更长的加载时间和不那么时尚的用户界面？是否需要将应用发布于AppStore和PlayStore？是否需要开发消费者导向的应用？

2、哪些开发者将在这个项目中工作？是否是你自有的团队？他们此前熟悉哪些技术栈？对于你所准备选择的平台，他们的态度是激动的、担心的还是消极的？如果你完全依赖于外部团队，平台的选择变得不那么重要，而让你的需求得以满足反而是决定因素。

3、是否同时需要Web应用版本的移动应用？

4、包含开发成本在内的总拥有成本如何？

5、你是否需要在本地还是云端的环境运营这些移动应用？对这一问题的回答可能会淘汰很多低代码平台或者是略微提升平台的使用成本。如果计划将应用基于云端运营，是否有哪些安全考量？

6、基于待选择的低代码平台，是否存在示例的应用，与你所要开发的移动应用的质量和功能需求大体近似？

7、团队的开发过程是基于瀑布式还是敏捷式的开发模式？如果是基于敏捷的开发，平台在多大程度上满足这样的场景？是否在每一次功能更新时，用户都需要重新下载新版本的应用，还是说，你可以将更新推送给用户而不需要更新客户端的二进制文件？

8、当项目中存在多个开发者协作开发的场景时，如何对开发过程进行组织？

9、你希望平台的供应商提供哪些支持？平台对于新的使用者上手难度如何？

九、最后的思考

低代码或者无代码方法，对于移动应用开发来说是一条捷径，前提是平台可以满足你的期待，并且提供足够的与你的需求相一致的功能特性。对于熟悉平台的开发者来说，时间成本的节省相对于传统的移动应用开发来说是数量级的提升。

如果你对所需要开发的项目已经有了大致的构想，我的建议是你去找到潜在的平台供应商并获得一个反馈的列表，列表中应该逐项列出对于你需求规格的满足程度。更进一步，如果你已经设计好了UI界面，这一反馈列表将帮助你找到潜在的问题。

如果你已经为移动应用项目选定了低代码平台，最好从界面设计阶段开始就明确平台的功能边界和局限性。在某些情况下，克服平台的局限性来满足设计师所设计的绚烂的UI界面的需要，甚至比采用传统开发方式所需要的花费更多。

最后，并且特别重要的是，找到基于低代码平台的示例应用。只要看到现成的功能和用户体验，则对于你的应用来说就是可实现的。如果找不到这样的示例，请谨慎从事并且在签约前获取一些额外的保证。

关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享