文章翻好后，我請一位在移動平臺領域工作多年的同事看了下，他的看法是，首先文中所講的一些內容并不適合中國的國情。比如，從他接觸的客戶來看，多數大廠的技術路線已經不考慮對基于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強工作，通?？梢哉J為公司不存在錢不夠花的煩惱。但在為移動應用開發申請預算時，情況又不盡相同。無論對于哪種規模的企業來說，花費都必須與預期的回報相適應。

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

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

八、檢查表

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

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

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

3、是否同時需要Web應用版本的移動應用？

4、包含開發成本在內的總擁有成本如何？

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

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

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

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

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

九、最后的思考

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

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

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

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