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

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

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

簡(jiǎn)單說一下背景：從Mac OS 9的時(shí)代（大概是1980年代末）以來，我一直在使用各種不同的快速開發(fā)平臺(tái)和低代碼開發(fā)工具。這些工具和平臺(tái)讓我愛恨交加。理想情況下，工具可以幫你節(jié)省80％的工作，但卻對(duì)剩余的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ā)平臺(tái)。我們?cè)?jīng)把Appzio的設(shè)計(jì)理念定義為“人人皆可開發(fā)應(yīng)用”，當(dāng)然，我們很快意識(shí)到這是一個(gè)嚴(yán)重的思維誤區(qū)，并摒棄了這個(gè)理念。

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

依據(jù)以往的個(gè)人經(jīng)驗(yàn)，我會(huì)揭示一些低代碼平臺(tái)所固有的缺陷，并提出一些值得被關(guān)注的重要問題，這些問題往往會(huì)被大多數(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è)級(jí)工具提供了復(fù)雜的可視化編輯器。起初，這樣的產(chǎn)品設(shè)計(jì)可以讓人更快上手，至少可以更容易的完成一些Demo應(yīng)用。但用久了這些基于瀏覽器的可視化工具，你就會(huì)開始懷念傳統(tǒng)的編程界面了。

Mendix的可視化編輯器

當(dāng)我們依據(jù)“人人皆可開發(fā)應(yīng)用”的理念重新定義Appzio平臺(tái)的產(chǎn)品功能的時(shí)候，設(shè)定了相當(dāng)高的指標(biāo)：我們希望平臺(tái)輸出一個(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í)踐方面的知識(shí)積淀，并深入理解業(yè)務(wù)邏輯的運(yùn)作方式。這就導(dǎo)致我們前述的那一大坨產(chǎn)品功能設(shè)定顯得過于復(fù)雜，簡(jiǎn)單講，要想做到這一點(diǎn)，工具的使用者必須是一個(gè)程序員。而如果你是一名程序員，代碼開發(fā)對(duì)你來說，是解決復(fù)雜問題的最佳和最快的方式。

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

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

二、Gartner忽略了什么？

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

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

十分有趣的是，在這一報(bào)告中，Gartner對(duì)于終端用戶的體驗(yàn)惜墨如金。報(bào)告中所提及的多數(shù)平臺(tái)工具不過是提供了一個(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í)間的長(zhǎng)短，界面是否時(shí)尚，充滿創(chuàng)造力的原生用戶界面是最基本的要求，但這些要求往往超越了多數(shù)低代碼平臺(tái)的能力。

三、使用低代碼平臺(tái)來實(shí)現(xiàn)

一個(gè)定制化的用戶體驗(yàn)的真正代價(jià)

說說為什么PhoneGap這類工具大勢(shì)已去。如果你想快速的把一堆東西攢在一起，他們是可以滿足要求的，但如果需要更復(fù)雜的用戶體驗(yàn)，你實(shí)際上最好以原生的代碼開發(fā)來進(jìn)行實(shí)現(xiàn)。或者也可以借助這樣的平臺(tái)來實(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í)間最多解決的往往是如何在不同的屏幕尺寸下顯示相同的外觀。尤其是在需要原生級(jí)應(yīng)用性能的場(chǎng)景。

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

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

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

3、對(duì)Web應(yīng)用的支持。很多低代碼平臺(tái)可以不只生成移動(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)大。我相信，一些低代碼平臺(tái)的供應(yīng)商應(yīng)該重新審視他們的架構(gòu)并摒棄PhoneGap。

四、好的低代碼平臺(tái)是什么樣子？

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

圖片由EAWorld編譯

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

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

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

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

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

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

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

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

有一個(gè)維度可能在評(píng)估體系中看來無關(guān)緊要，但卻對(duì)開發(fā)者體驗(yàn)產(chǎn)生著顯著的影響，即，如何在設(shè)備上預(yù)覽應(yīng)用程序的變更。對(duì)于預(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è)備上安裝什么東西，而且也不會(huì)有代碼編譯的過程。

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

為了更好的闡述從開發(fā)者視角看來的不同，下面我給出了兩個(gè)簡(jiǎn)短的動(dòng)態(tài)圖片，來體現(xiàn)一個(gè)簡(jiǎn)單的文本變更是如何在設(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)工作，通常可以認(rèn)為公司不存在錢不夠花的煩惱。但在為移動(dòng)應(yīng)用開發(fā)申請(qǐng)預(yù)算時(shí)，情況又不盡相同。無論對(duì)于哪種規(guī)模的企業(yè)來說，花費(fèi)都必須與預(yù)期的回報(bào)相適應(yīng)。

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

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

八、檢查表

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

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

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

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

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

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

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

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

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

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

九、最后的思考

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

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

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

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