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

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

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

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

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

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

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

一、可視化配置VS代碼開發(fā)：

收益遞減的臨界點

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

AppyPie的配置界面

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

Mendix的可視化編輯器

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

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

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

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

二、Gartner忽略了什么？

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

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

十分有趣的是，在這一報告中，Gartner對于終端用戶的體驗惜墨如金。報告中所提及的多數(shù)平臺工具不過是提供了一個基于PhoneGap（被收購后更名為Cordova）、JavaScript或者Web View的美化的Web打包器。我想，這也是在這些工具中少有“消費者導(dǎo)向應(yīng)用”的主要原因。因為他們根本不在意這一點。

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

三、使用低代碼平臺來實現(xiàn)

一個定制化的用戶體驗的真正代價

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

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

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

性能問題

缺少原生功能

高度依賴操作系統(tǒng)

JS引擎的異構(gòu)性

多屏適配問題

多線程問題

同步方面的問題

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

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

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

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

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

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

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

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

圖片由EAWorld編譯

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

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

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

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

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

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

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

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

六、開發(fā)者體驗

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

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

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

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

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

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

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

熱重載（用時2分鐘）

打開鏈接http：／／t．cn／EJtrmtJ查看動圖

實時編輯（用時11秒）

打開鏈接http：／／t．cn／EJtFzYW查看動圖

七、當價格成為阻礙

如果你為世界財富500強工作，通常可以認為公司不存在錢不夠花的煩惱。但在為移動應(yīng)用開發(fā)申請預(yù)算時，情況又不盡相同。無論對于哪種規(guī)模的企業(yè)來說，花費都必須與預(yù)期的回報相適應(yīng)。

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

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

八、檢查表

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

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

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

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

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

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

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

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

8、當項目中存在多個開發(fā)者協(xié)作開發(fā)的場景時，如何對開發(fā)過程進行組織？

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

九、最后的思考

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

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

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

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