[[210174]]

今天在瀏覽知乎的時(shí)候，看到這么一個(gè)問(wèn)題，感覺(jué)很有意思，有點(diǎn)分享價(jià)值，如下：

APICloud 能都替代 Android 原生開(kāi)發(fā)嗎？

APICloud 現(xiàn)在好像蠻火，但是能替代比如在 Eclipse，AndroidStudio 來(lái)做的 App 開(kāi)發(fā)嗎？本來(lái)在 Eclipse 上做 App 開(kāi)發(fā)的程序員有必要轉(zhuǎn)到 APICloud 上開(kāi)發(fā)嗎，畢竟還是簡(jiǎn)單，快速些。

說(shuō)實(shí)話，這個(gè)問(wèn)題本身就問(wèn)的就有問(wèn)題，沒(méi)有說(shuō)一種技術(shù)可以完全替代另外一種技術(shù)，每種技術(shù)的側(cè)重點(diǎn)和優(yōu)勢(shì)都不一樣，不同的需求和場(chǎng)景，不同的體驗(yàn)可以選擇不同的技術(shù)，技術(shù)之間其實(shí)沒(méi)有什么完全替代之說(shuō)。這是我們面臨產(chǎn)品，項(xiàng)目，和整個(gè)團(tuán)隊(duì)技術(shù)能力時(shí)，需要做的一種技術(shù)選型罷了。

我之所以說(shuō)，很有分享價(jià)值，是因?yàn)槲铱吹搅酥醮笊瘛赣箤?xiě)的回答，很全面，他從原生開(kāi)發(fā)、hybrid 開(kāi)發(fā)、RN/Weex 為代表的 “偽 hybrid 開(kāi)發(fā)”，以及 APICloud 這些技術(shù)選型中做了不同的優(yōu)勢(shì)和劣勢(shì)，以及技術(shù)特點(diǎn)的分析，而這些回答，可以讓大家更深入，更清晰的了解這些技術(shù)。為以后的開(kāi)發(fā)，技術(shù)選型能夠有一定的參考和學(xué)習(xí)價(jià)值。

知乎大神「欲三更」的回答

APICloud 和原生應(yīng)用開(kāi)發(fā)，不是互相替代的關(guān)系。

不同的場(chǎng)景不同的需求，自然采用不同的技術(shù)，我們需要認(rèn)清的是我們處于什么場(chǎng)景，選用了不同的技術(shù)會(huì)有什么優(yōu)勢(shì)，什么痛點(diǎn)。

嚴(yán)格的講，這個(gè)問(wèn)題應(yīng)該是個(gè)四方比較的技術(shù)選型問(wèn)題：原生開(kāi)發(fā)、hybrid 開(kāi)發(fā)、RN/Weex 為代表的 “偽 hybrid 開(kāi)發(fā)”，以及 APICloud。

為什么將 hybrid 開(kāi)發(fā)和 APICloud 分開(kāi)？因?yàn)?APICloud 是一個(gè)包含跨平臺(tái) APP 開(kāi)發(fā)引擎、開(kāi)發(fā)工具、云服務(wù)、模塊市場(chǎng)等服務(wù)的完整 APP 開(kāi)發(fā)生態(tài)。目前 APICloud 已經(jīng)推出面向 Web 開(kāi)發(fā)者的 Deep 引擎、面向已有 native 應(yīng)用的 SuperWebView、模塊市場(chǎng)，以及數(shù)據(jù)云、運(yùn)營(yíng)云等云服務(wù)快速開(kāi)發(fā)環(huán)境。不能僅僅作為一種 “工具” 或者單一技術(shù)看待。

下面我們簡(jiǎn)單列舉一下四種技術(shù)選型的優(yōu)勢(shì)和劣勢(shì)：

原生開(kāi)發(fā)

優(yōu)勢(shì)：

• 廠商原生技術(shù)，自由度***。

• 社區(qū)和文檔化都非常完善，各種技術(shù)資料和解決方案相當(dāng)豐富。

• 歷史比較久，具備一定資歷的開(kāi)發(fā)人員比較好招（并不意味著便宜）。

劣勢(shì)：

• 開(kāi)發(fā)成本高，技術(shù)難度高。

• 項(xiàng)目無(wú)法跨平臺(tái)，需要兩支團(tuán)隊(duì)。

• 需要投入的開(kāi)發(fā)、測(cè)試力量以及周期都比較長(zhǎng)，這會(huì)導(dǎo)致迭代節(jié)奏偏慢（要想快就得加人），不一定更得上產(chǎn)品的迭代節(jié)奏。

hybrid 開(kāi)發(fā)

優(yōu)勢(shì)：

• 網(wǎng)頁(yè)迭代速度快，這個(gè)是公認(rèn)的。

• 跨平臺(tái)性突出，有利于節(jié)省人力，1 到 1.5 人可以維護(hù)兩大平臺(tái)的應(yīng)用。

• 前端社區(qū)的技術(shù)演進(jìn)非?？欤鐓^(qū)活躍。

• 當(dāng)下而言，前端工程師人力資源比較豐富。

劣勢(shì)：

• 性能劣于原生開(kāi)發(fā)，容易出現(xiàn)性能問(wèn)題。

• 嚴(yán)格的說(shuō) hybrid 只是一種技術(shù)理念，而并不是具體的技術(shù)解決方案。應(yīng)用開(kāi)發(fā)商常常需要自行構(gòu)建維護(hù)技術(shù)棧。

• 雖然有封裝了 native 接口的 hybrid 框架（比如 ionic）可選擇，但是對(duì)于相對(duì)復(fù)雜的應(yīng)用，現(xiàn)有的 hybrid 框架并不能滿足需要，所以使用 hybrid 方式開(kāi)發(fā)的應(yīng)用，常常需要原生補(bǔ)充，這種情況下不同模塊的用戶體驗(yàn)難以統(tǒng)一。

RN/Weex

優(yōu)勢(shì)：

• 使用系統(tǒng)原生 UI 組件，性能和體驗(yàn)相比 hybrid 更接近于原生。

• 由于 RN 和 Weex 都是一線互聯(lián)網(wǎng)廠商的產(chǎn)品，除了組件和 api 封裝之外，還會(huì)對(duì)熱更新一類的工程需求給出明確解決方案。

劣勢(shì)：

• 不使用 html5 自然有好處，但是也會(huì)帶來(lái)壞處。比如，需要分別搭建 Android 和 IOS 開(kāi)發(fā)環(huán)境，分別 Release。RN 的核心理念是 “learn once write anywhere” 而非 “write once run anywhere”。

• 再比如針對(duì) RN/Weex 的設(shè)計(jì)并不像 hybrid 那么靈活，并且會(huì)一定程度上產(chǎn)生平臺(tái)分化。

• 學(xué)習(xí)曲線可能不像大家想像中那么平滑，不管是前端還是移動(dòng)開(kāi)發(fā)工程師，進(jìn)入 RN/Weex 領(lǐng)域還是需要一個(gè)學(xué)習(xí)期的。

• RN/Weex 的可調(diào)式性比純?yōu)g覽器還是要差上一截，開(kāi)發(fā)體驗(yàn)并不那么好，這也一定程度上增加了開(kāi)發(fā)成本。

APICloud

說(shuō)優(yōu)勢(shì)劣勢(shì)之前，我們先來(lái)解釋一下 APICloud 和原始 hybrid 的區(qū)別。hybrid 技術(shù)是 APICloud“端” 開(kāi)發(fā)的核心技術(shù)手段，但是 APICloud 基于 hybrid 做了很多事。從項(xiàng)目開(kāi)發(fā)過(guò)程來(lái)看，使用現(xiàn)有開(kāi)源的 hybrid 技術(shù)或者自建 hybrid 框架，更像是自己買菜做飯，建立和維護(hù)技術(shù)棧，以及針對(duì)各種問(wèn)題積累 know how 的成本是比較高的，而使用 APICloud 開(kāi)發(fā)，其體驗(yàn)更像是使用. net、java 這樣的企業(yè)級(jí)開(kāi)發(fā)技術(shù)棧，或者說(shuō)去飯店點(diǎn)餐，你拿到手的東西已經(jīng)相當(dāng)完整，可以直接聚焦于應(yīng)用。

優(yōu)勢(shì)：

• 傳統(tǒng) hybrid 開(kāi)發(fā)的優(yōu)勢(shì)，APICloud 基本是具備的。

• 相比傳統(tǒng) hybrid，APICloud 提供的是整體解決方案以及標(biāo)準(zhǔn)化的技術(shù)平臺(tái)，不需要自行搭建熱更新等外圍技術(shù)。

• 技術(shù)支持體系，開(kāi)發(fā)者社區(qū)，有全面的產(chǎn)品、技術(shù)文檔、視頻教程等，技術(shù)論壇中有活躍的開(kāi)發(fā)者，也有官方一線產(chǎn)品人員提供技術(shù)支持，這在國(guó)內(nèi)的社區(qū)中，維護(hù)度算認(rèn)真的了。

• 模塊市場(chǎng)。模塊是 APICloud 的核心優(yōu)勢(shì)之一，編碼時(shí)拿來(lái)即用，無(wú)需重復(fù)造輪子，目前有五六百個(gè)模塊，涵蓋了 APP 開(kāi)發(fā)過(guò)程中 90% 以上的功能，同時(shí)聚合了國(guó)內(nèi)主流第三方服務(wù)，比如 IM，推送，人工智能，物聯(lián)網(wǎng)，直播等等。原生開(kāi)發(fā)者還可通過(guò) APICloud 的模塊擴(kuò)展機(jī)制，開(kāi)發(fā)模塊在模塊 Store 上進(jìn)行售賣。

• APICloud 利用高效的 “混合渲染” 和模塊化機(jī)制，為 APP 提供與原生一致的性能，同時(shí)還繼承 Html5 開(kāi)發(fā)簡(jiǎn)單的優(yōu)勢(shì)，二者對(duì)開(kāi)發(fā)人員來(lái)說(shuō)基本上是透明的。

劣勢(shì)：

• 由于 APICloud 是基于標(biāo)準(zhǔn) html5 擴(kuò)展的技術(shù)，API 比較新，開(kāi)發(fā)人員需要一定的時(shí)間熟悉、學(xué)習(xí)其擴(kuò)展的 API（個(gè)人認(rèn)為相對(duì) RN/Weex 來(lái)說(shuō)要容易一點(diǎn)）。

• 在 APICloud 中開(kāi)發(fā) APP，原則上不提倡使用 JQuery 等傳統(tǒng) Web 開(kāi)發(fā)常用的庫(kù)和框架。習(xí)慣使用框架的前端開(kāi)發(fā)人員使用 APICloud 開(kāi)發(fā) APP 時(shí)，可能還需要花時(shí)間去適應(yīng)。

• APICloud 的技術(shù)引擎和大部分的模塊沒(méi)有開(kāi)源，這其實(shí)算是一把雙刃劍，但從開(kāi)發(fā)者角度講，開(kāi)源平臺(tái)，會(huì)降低項(xiàng)目開(kāi)發(fā)中的一定風(fēng)險(xiǎn)，尤其是可調(diào)試性。

就技術(shù)而言，目前 APICloud 的客戶端技術(shù)，很像是桌面端的混合開(kāi)發(fā)方案 electron，立足于 html5，通過(guò)統(tǒng)一標(biāo)準(zhǔn)的 API 消除不同平臺(tái)、不同操作系統(tǒng)之間的差異，達(dá)到 APP 跨平臺(tái)的目的。但是相比純技術(shù)方案，APICloud 是一個(gè) “有產(chǎn)品有生態(tài)有運(yùn)營(yíng)” 的商業(yè)級(jí)開(kāi)發(fā)平臺(tái)。今天我們看到的特色，也主要是因此誕生的。

回到開(kāi)始的觀點(diǎn)，APICloud 并不是原生開(kāi)發(fā)的代替技術(shù)，APICloud 實(shí)質(zhì)上是一個(gè)為移動(dòng)端 app 開(kāi)發(fā)提效和賦能的平臺(tái)體系。基于 APICloud 做應(yīng)用，還是在原生應(yīng)用中內(nèi)嵌 APICloud，其實(shí)是針對(duì)不同場(chǎng)景的不同技術(shù)選擇，背后的核心理念就是 “因地制宜”，什么樣的場(chǎng)景，我采用什么樣的技術(shù)能達(dá)到提效和附能的目的，是技術(shù)選擇的唯一標(biāo)準(zhǔn)。

多說(shuō)一句，國(guó)內(nèi)大型互聯(lián)網(wǎng)公司普遍采用了 “大中臺(tái)” 戰(zhàn)略，期望建設(shè)強(qiáng)大的中臺(tái)去支撐業(yè)務(wù)。同樣的，作為中小型團(tuán)隊(duì)，選擇一種技術(shù)，并不是說(shuō)靜態(tài)地去看當(dāng)下這個(gè)技術(shù)有哪些好處壞處，而是要放在 “外置中臺(tái)” 的角度，動(dòng)態(tài)的去審視。一個(gè)技術(shù)棧長(zhǎng)遠(yuǎn)的看能決定你的研發(fā)模式和團(tuán)隊(duì)構(gòu)成，所以這不是那個(gè)工具最省事。