本文由公眾號EAWorld翻譯發(fā)表，轉(zhuǎn)載需注明出處。

作者：Timo Railo

譯者：白小白

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

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

白小白：

文章翻好后，我請一位在移動(dòng)平臺領(lǐng)域工作多年的同事看了下，他的看法是，首先文中所講的一些內(nèi)容并不適合中國的國情。比如，從他接觸的客戶來看，多數(shù)大廠的技術(shù)路線已經(jīng)不考慮對基于WebView的應(yīng)用整合。從UI模型的角度看，RN、Flutter（谷歌推出的移動(dòng)框架，已經(jīng)發(fā)布到1.2版本）包括國內(nèi)一些業(yè)界的移動(dòng)平臺從未強(qiáng)調(diào)低代碼，但是強(qiáng)調(diào)代碼通過UI模型與設(shè)計(jì)盡可能連貫。

從文中所述的情況來看，國外的移動(dòng)平臺，至少在以私有方式部署的移動(dòng)平臺領(lǐng)域，技術(shù)上或者說技術(shù)的應(yīng)用上相對于國內(nèi)還是有所落后的，比如文中所說的未見有企業(yè)級實(shí)踐的React Native技術(shù)，就國內(nèi)來說，金證股份，韻達(dá)快遞，張家港農(nóng)商行，中信重工，陜西國土等行業(yè)用戶都已經(jīng)基于RN技術(shù)的移動(dòng)平臺建設(shè)了自己的移動(dòng)應(yīng)用。

從我個(gè)人的角度，我認(rèn)為文中關(guān)于選擇移動(dòng)平臺的考量要素，對開發(fā)者的體驗(yàn)重視，以及對遺留系統(tǒng)的整合等內(nèi)容的闡述，還是有一定的參考意義，因此還是推薦給大家看下。歡迎在文后給出評論，講下自己的看法。

簡單說一下背景：從Mac OS 9的時(shí)代（大概是1980年代末）以來，我一直在使用各種不同的快速開發(fā)平臺和低代碼開發(fā)工具。這些工具和平臺讓我愛恨交加。理想情況下，工具可以幫你節(jié)省80%的工作，但卻對剩余的20%無能為力。同時(shí)，從Sybian系統(tǒng)大行其道的時(shí)代開始，我就從事與移動(dòng)應(yīng)用開發(fā)相關(guān)的工作，那是蘋果公司尚未在移動(dòng)應(yīng)用領(lǐng)域掀起驚天革命的年代。

我的另一個(gè)身份是Appzio公司的CTO，公司的主業(yè)是為原生移動(dòng)應(yīng)用開發(fā)提供低代碼開發(fā)平臺。我們曾經(jīng)把Appzio的設(shè)計(jì)理念定義為“人人皆可開發(fā)應(yīng)用”，當(dāng)然，我們很快意識到這是一個(gè)嚴(yán)重的思維誤區(qū)，并摒棄了這個(gè)理念。

可以說，我對這個(gè)行業(yè)知之甚深，并愿意分享我的如下觀點(diǎn)：多數(shù)的低代碼平臺在高質(zhì)量的移動(dòng)應(yīng)用開發(fā)方面并不盡如人意。

依據(jù)以往的個(gè)人經(jīng)驗(yàn)，我會揭示一些低代碼平臺所固有的缺陷，并提出一些值得被關(guān)注的重要問題，這些問題往往會被大多數(shù)人所忽略。本文適用于iOS或者Android移動(dòng)應(yīng)用的開發(fā)。

一、可視化配置VS代碼開發(fā)：收益遞減的臨界點(diǎn)

能夠讓你以可視化配置的方式或者編輯器來開發(fā)移動(dòng)應(yīng)用的工具多如牛毛。像是Mobile Roadie、Good Barber、AppyPie、AppMachine這類工具還提供了預(yù)定義的功能模塊和基于網(wǎng)頁的配置工具。但這些工具的成熟性還存在一些問題，并且也無法提供額外的特性。

AppyPie的配置界面

諸如Mendix、Outsystem、Appian和Kony這些企業(yè)級工具提供了復(fù)雜的可視化編輯器。起初，這樣的產(chǎn)品設(shè)計(jì)可以讓人更快上手，至少可以更容易的完成一些Demo應(yīng)用。但用久了這些基于瀏覽器的可視化工具，你就會開始懷念傳統(tǒng)的編程界面了。

Mendix的可視化編輯器

當(dāng)我們依據(jù)“人人皆可開發(fā)應(yīng)用”的理念重新定義Appzio平臺的產(chǎn)品功能的時(shí)候，設(shè)定了相當(dāng)高的指標(biāo)：我們希望平臺輸出一個(gè)實(shí)用的，完全原生的移動(dòng)應(yīng)用，擁有應(yīng)用內(nèi)購、實(shí)時(shí)位置等原生功能，最重要的是，提供完全原生的用戶體驗(yàn)。我們已知的是，可視化的構(gòu)建器并不足以滿足這樣的需求。

打造一個(gè)全原生的移動(dòng)應(yīng)用體驗(yàn)需要擁有用戶體驗(yàn)和最佳實(shí)踐方面的知識積淀，并深入理解業(yè)務(wù)邏輯的運(yùn)作方式。這就導(dǎo)致我們前述的那一大坨產(chǎn)品功能設(shè)定顯得過于復(fù)雜，簡單講，要想做到這一點(diǎn)，工具的使用者必須是一個(gè)程序員。而如果你是一名程序員，代碼開發(fā)對你來說，是解決復(fù)雜問題的最佳和最快的方式。

學(xué)習(xí)使用一個(gè)可視化的工具，意味著你不得不學(xué)習(xí)一種新的編程范式，并且這種范式本身不可避免的存在局限性。即使學(xué)會了工具的使用，也很快會到達(dá)收益遞減的臨界點(diǎn)。換句話說，在不同的菜單和配置項(xiàng)之間繞來繞去所花的時(shí)間甚至比你直接寫代碼來得還要長。而且最終還往往不能完成全部你想要的功能。

基于這樣的原因，我們放棄了可視化配置界面的理念，轉(zhuǎn)而把精力花在優(yōu)化基于代碼的開發(fā)過程，并且建立一個(gè)平臺，提供更高的開發(fā)速度且并不犧牲靈活性。

二、Gartner忽略了什么？

Gartner的“企業(yè)級高生產(chǎn)力aPaas”魔力象限研究報(bào)告實(shí)際上可以作為企業(yè)級低代碼開發(fā)平臺的白皮書。長期以來，Gartner使用頗具魅力的字母組合hpaPaaS作為High-productivity application platform as a service的縮寫。報(bào)告中有一段定義如下：

企業(yè)級高生產(chǎn)力aPaaS市場中活躍著很多的供應(yīng)商，他們致力于為企業(yè)級應(yīng)用以及服務(wù)的開發(fā)和部署提供從低代碼到無代碼的云端平臺。

十分有趣的是，在這一報(bào)告中，Gartner對于終端用戶的體驗(yàn)惜墨如金。報(bào)告中所提及的多數(shù)平臺工具不過是提供了一個(gè)基于PhoneGap（被收購后更名為Cordova）、JavaScript或者Web View的美化的Web打包器。我想，這也是在這些工具中少有“消費(fèi)者導(dǎo)向應(yīng)用”的主要原因。因?yàn)樗麄兏静辉谝膺@一點(diǎn)。

移動(dòng)應(yīng)用的個(gè)人用戶和企業(yè)用戶始終在每日使用的原生應(yīng)用間比較著用戶體驗(yàn)的差異。像是加載時(shí)間的長短，界面是否時(shí)尚，充滿創(chuàng)造力的原生用戶界面是最基本的要求，但這些要求往往超越了多數(shù)低代碼平臺的能力。

三、使用低代碼平臺來實(shí)現(xiàn)一個(gè)定制化的用戶體驗(yàn)的真正代價(jià)

說說為什么PhoneGap這類工具大勢已去。如果你想快速的把一堆東西攢在一起，他們是可以滿足要求的，但如果需要更復(fù)雜的用戶體驗(yàn)，你實(shí)際上最好以原生的代碼開發(fā)來進(jìn)行實(shí)現(xiàn)。或者也可以借助這樣的平臺來實(shí)現(xiàn)，前提是能夠提供原生的開發(fā)體驗(yàn)以及豐富的自定義功能。

在使用PhoneGap的時(shí)候，你不僅需要與JavaScript打交道，還需要與另外兩種解釋性語言HTML和CSS打交道。

而且，以這種方式建立的應(yīng)用，大體上就是基于WebView的機(jī)制嵌在應(yīng)用中的一個(gè)網(wǎng)頁。這將帶來如下的缺陷：

• 性能問題
• 缺少原生功能
• 高度依賴操作系統(tǒng)
• JS引擎的異構(gòu)性
• 多屏適配問題
• 多線程問題
• 同步方面的問題

還有一個(gè)流行的替代方案，是使用JS渲染引擎。但這種方式的缺陷在于跨系統(tǒng)多版本和多屏適配的體驗(yàn)一致性。實(shí)際上，此處我們還是遇到了一個(gè)收益遞減的臨界點(diǎn)。通常情況下，在原生應(yīng)用的開發(fā)過程中，我們花時(shí)間最多解決的往往是如何在不同的屏幕尺寸下顯示相同的外觀。尤其是在需要原生級應(yīng)用性能的場景。

當(dāng)我們在原生代碼/Web配置器/JS渲染之間做出選擇時(shí)，原生代碼開發(fā)的優(yōu)勢顯而易見，所以，一個(gè)好問題是：為什么所有的低代碼平臺都不采用原生代碼的方式？這樣的架構(gòu)決策背后有很多原因：

1、遺留系統(tǒng)的問題。很多低代碼平臺已經(jīng)存在了很長時(shí)間。5年以前，移動(dòng)開發(fā)領(lǐng)域的跨平臺框架與其后數(shù)年的原生代碼開發(fā)方式水平相當(dāng)，然而形勢已經(jīng)發(fā)生了逆轉(zhuǎn)，PhoneGap已經(jīng)慢慢被時(shí)代所拋棄。ReactNative在當(dāng)下炙手可熱并且前景廣闊，但就我所知，還沒有企業(yè)級平臺基于ReactNative來構(gòu)建其移動(dòng)應(yīng)用。

2、工程師的技能。使用低代碼平臺來進(jìn)行工作的工程師大多來自Web開發(fā)和后端開發(fā)。PhoneGap對于Web開發(fā)者來說是一個(gè)很自然的工具。而使用原生代碼來構(gòu)建一個(gè)平臺需要完全不同的技能棧。

3、對Web應(yīng)用的支持。很多低代碼平臺可以不只生成移動(dòng)應(yīng)用客戶端，并且可以生成Web應(yīng)用或者一個(gè)改良的Web應(yīng)用。采用這樣的方法，以打包器的方式來解決移動(dòng)應(yīng)用開發(fā)的問題成為最佳實(shí)踐。事實(shí)上就是這樣。如果我們自己生成可以在原生的iOS系統(tǒng)和安卓系統(tǒng)上提供一致功能的應(yīng)用，需要付出四倍的努力。

然而，時(shí)至今日，原生的移動(dòng)應(yīng)用遠(yuǎn)比以往更加強(qiáng)大。我相信，一些低代碼平臺的供應(yīng)商應(yīng)該重新審視他們的架構(gòu)并摒棄PhoneGap。

四、好的低代碼平臺是什么樣子？

根據(jù)操作環(huán)境的不同，評價(jià)移動(dòng)應(yīng)用開發(fā)工具的維度并不相同。為了簡化起見，我制作了一張圖表來描述低代碼平臺所需要具備的一些關(guān)鍵特性。也許并不完備，但至少可以在你面臨一些關(guān)鍵決斷時(shí)提供一些決策參考。

圖片由EAWorld編譯

五、如何加速移動(dòng)開發(fā)？

為了理解低代碼平臺的價(jià)值，最好的方式就是審視一下如何加速移動(dòng)開發(fā)。我將對這個(gè)話題做一些擴(kuò)展，把傳統(tǒng)的原生開發(fā)納入討論。

1、如何加速傳統(tǒng)的原生移動(dòng)應(yīng)用開發(fā)？使用提供了第三方SDK和現(xiàn)成的代碼模塊的框架實(shí)現(xiàn)功能擴(kuò)展。

2、如何加速跨平臺的移動(dòng)應(yīng)用開發(fā)？使用同時(shí)支持iOS和安卓系統(tǒng)的客戶端代碼庫，使用現(xiàn)成的包和模塊以及第三方SDK擴(kuò)展應(yīng)用功能。

3、如何加速移動(dòng)應(yīng)用的后端開發(fā)？選擇恰當(dāng)?shù)腂aaS（backend as a service）供應(yīng)商和框架，謹(jǐn)慎的選擇編程語言，建立從模型直接生成API的自動(dòng)化方式，使用不同的模塊和組件來擴(kuò)展功能。

4、如何加速移動(dòng)開發(fā)的規(guī)劃過程？主要得益于如Invision一樣的可視化的原型工具，來建立可實(shí)際點(diǎn)擊的原型，以及使用提供現(xiàn)成用戶界面的UI工具。

5、使用低代碼平臺來加速移動(dòng)開發(fā)。需要綜合使用多種方式，包括使用模板、現(xiàn)成的模塊、自動(dòng)化的代碼生成機(jī)制、配置化編程、自動(dòng)化的云端部署、自動(dòng)化測試、更便捷的開發(fā)者協(xié)作 、緊耦合的后端和前端開發(fā)過程等。

無論使用哪一種方式來加速移動(dòng)開發(fā)，都存在著權(quán)衡。比如，如果使用現(xiàn)成的模塊，平臺是否提供了豐富的配置和定制化功能來滿足需要？如果后端使用了無服務(wù)器架構(gòu)，在需要實(shí)現(xiàn)更復(fù)雜的業(yè)務(wù)邏輯的場景之下，是否會存在局限性？

六、開發(fā)者體驗(yàn)

當(dāng)今世界，作為雇主，在全球范圍內(nèi)都面臨著對開發(fā)者的激烈競爭。如果你的開發(fā)者不喜歡你選擇的平臺，這就成為一個(gè)問題。無論選擇哪一個(gè)平臺，都存在著難以評估的學(xué)習(xí)曲線。因此，更易上手的平臺將在競爭中有更大的優(yōu)勢。開發(fā)者是否能夠在平臺上快樂的工作，將顯著的影響你從平臺中所獲得的收益。

聰明的開發(fā)者可以基于傳統(tǒng)的開發(fā)模型以一種更加敏捷的方式來開發(fā)移動(dòng)應(yīng)用。畢竟傳統(tǒng)移動(dòng)開發(fā)大多遵循瀑布式的開發(fā)模式。低代碼平臺可以很好的做為敏捷開發(fā)工具來使用。

有一個(gè)維度可能在評估體系中看來無關(guān)緊要，但卻對開發(fā)者體驗(yàn)產(chǎn)生著顯著的影響，即，如何在設(shè)備上預(yù)覽應(yīng)用程序的變更。對于預(yù)覽，有三種不同的層次：

1、重新構(gòu)建：使用Xcode或者Android Studio來進(jìn)行預(yù)覽，需要重新構(gòu)建整個(gè)移動(dòng)應(yīng)用。這意味著每次變更都需要花費(fèi)一些時(shí)間來看到變更的結(jié)果。同時(shí)，需要開發(fā)者在設(shè)備上安裝了Xcode或者Android Studio并且配置正確。

2、熱重載：仍舊需要重新加載整個(gè)應(yīng)用，但至少不需要在設(shè)備上安裝什么東西，而且也不會有代碼編譯的過程。

3、實(shí)時(shí)編輯：保存變更 ，刷新屏幕，就可以預(yù)覽變更的效果。

為了更好的闡述從開發(fā)者視角看來的不同，下面我給出了兩個(gè)簡短的動(dòng)態(tài)圖片，來體現(xiàn)一個(gè)簡單的文本變更是如何在設(shè)備上進(jìn)行預(yù)覽的。

熱重載(用時(shí)2分鐘)打開鏈接http://t.cn/EJtrmtJ查看動(dòng)圖

實(shí)時(shí)編輯(用時(shí)11秒)打開鏈接http://t.cn/EJtFzYW查看動(dòng)圖

七、當(dāng)價(jià)格成為阻礙

如果你為世界財(cái)富500強(qiáng)工作，通?？梢哉J(rèn)為公司不存在錢不夠花的煩惱。但在為移動(dòng)應(yīng)用開發(fā)申請預(yù)算時(shí)，情況又不盡相同。無論對于哪種規(guī)模的企業(yè)來說，花費(fèi)都必須與預(yù)期的回報(bào)相適應(yīng)。

許可證的花費(fèi)，尤其是應(yīng)用存在許多用戶的的情況下，是很昂貴的。低代碼平臺的供應(yīng)商通常按席位、開發(fā)者、開發(fā)實(shí)例來進(jìn)行收費(fèi)。很難評估最終所付的價(jià)格（這還不包括二次開發(fā)的費(fèi)用）。你的業(yè)務(wù)收益和時(shí)間成本的節(jié)約需要與價(jià)格相一致。

并且，通常來說，平臺越是具有專業(yè)性，對于新的使用者越是需要花費(fèi)更長的時(shí)間去熟悉。你需要為此做出時(shí)間規(guī)劃，畢竟想找到熟悉平臺的現(xiàn)成的開發(fā)者基本上是個(gè)不可能的任務(wù)。

八、檢查表

在為你的移動(dòng)應(yīng)用項(xiàng)目尋找潛在的低代碼開發(fā)平臺的時(shí)候，下面這個(gè)列表可供參考。嘗試首先按照業(yè)務(wù)需要回答問題，然后再看一下所選擇的平臺是否可以滿足要求，這樣將有利于比較候選者的差異。

1、用戶體驗(yàn)有多重要？是否僅應(yīng)用于小團(tuán)隊(duì)用戶，并且可以接受更長的加載時(shí)間和不那么時(shí)尚的用戶界面？是否需要將應(yīng)用發(fā)布于AppStore和PlayStore？是否需要開發(fā)消費(fèi)者導(dǎo)向的應(yīng)用？

2、哪些開發(fā)者將在這個(gè)項(xiàng)目中工作？是否是你自有的團(tuán)隊(duì)？他們此前熟悉哪些技術(shù)棧？對于你所準(zhǔn)備選擇的平臺，他們的態(tài)度是激動(dòng)的、擔(dān)心的還是消極的？如果你完全依賴于外部團(tuán)隊(duì)，平臺的選擇變得不那么重要，而讓你的需求得以滿足反而是決定因素。

3、是否同時(shí)需要Web應(yīng)用版本的移動(dòng)應(yīng)用？

4、包含開發(fā)成本在內(nèi)的總擁有成本如何？

5、你是否需要在本地還是云端的環(huán)境運(yùn)營這些移動(dòng)應(yīng)用？對這一問題的回答可能會淘汰很多低代碼平臺或者是略微提升平臺的使用成本。如果計(jì)劃將應(yīng)用基于云端運(yùn)營，是否有哪些安全考量？

6、基于待選擇的低代碼平臺，是否存在示例的應(yīng)用，與你所要開發(fā)的移動(dòng)應(yīng)用的質(zhì)量和功能需求大體近似？

7、團(tuán)隊(duì)的開發(fā)過程是基于瀑布式還是敏捷式的開發(fā)模式？如果是基于敏捷的開發(fā)，平臺在多大程度上滿足這樣的場景？是否在每一次功能更新時(shí)，用戶都需要重新下載新版本的應(yīng)用，還是說，你可以將更新推送給用戶而不需要更新客戶端的二進(jìn)制文件？

8、當(dāng)項(xiàng)目中存在多個(gè)開發(fā)者協(xié)作開發(fā)的場景時(shí)，如何對開發(fā)過程進(jìn)行組織？

9、你希望平臺的供應(yīng)商提供哪些支持？平臺對于新的使用者上手難度如何？

九、最后的思考

低代碼或者無代碼方法，對于移動(dòng)應(yīng)用開發(fā)來說是一條捷徑，前提是平臺可以滿足你的期待，并且提供足夠的與你的需求相一致的功能特性。對于熟悉平臺的開發(fā)者來說，時(shí)間成本的節(jié)省相對于傳統(tǒng)的移動(dòng)應(yīng)用開發(fā)來說是數(shù)量級的提升。

如果你對所需要開發(fā)的項(xiàng)目已經(jīng)有了大致的構(gòu)想，我的建議是你去找到潛在的平臺供應(yīng)商并獲得一個(gè)反饋的列表，列表中應(yīng)該逐項(xiàng)列出對于你需求規(guī)格的滿足程度。更進(jìn)一步，如果你已經(jīng)設(shè)計(jì)好了UI界面，這一反饋列表將幫助你找到潛在的問題。

如果你已經(jīng)為移動(dòng)應(yīng)用項(xiàng)目選定了低代碼平臺，最好從界面設(shè)計(jì)階段開始就明確平臺的功能邊界和局限性。在某些情況下，克服平臺的局限性來滿足設(shè)計(jì)師所設(shè)計(jì)的絢爛的UI界面的需要，甚至比采用傳統(tǒng)開發(fā)方式所需要的花費(fèi)更多。

最后，并且特別重要的是，找到基于低代碼平臺的示例應(yīng)用。只要看到現(xiàn)成的功能和用戶體驗(yàn)，則對于你的應(yīng)用來說就是可實(shí)現(xiàn)的。如果找不到這樣的示例，請謹(jǐn)慎從事并且在簽約前獲取一些額外的保證。

關(guān)于EAWorld：微服務(wù)，DevOps，數(shù)據(jù)治理，移動(dòng)架構(gòu)原創(chuàng)技術(shù)分享