最近有关“APICloud能都替代Android原生开发吗?”的话题在知乎论坛引起了大家的广泛关注，很多开发者在详细了解之后对自己的职业规划重新做了调整，同时也给企业在项目合作上提供了更多选择。今天，转来分享给大家，这位KOL还给我们列举了4种开发技术的优势、劣势作参考。

APICloud和原生应用开发，不是互相替代的关系

　　不同的场景不同的需求，自然采用不同的技术，我们需要认清的是我们处于什么场景，选用了不同的技术会有什么优势，什么痛点。

　　严格讲，这个问题应该是个四方比较的技术选型问题：原生开发、hybrid开发、RN/Weex为代表的“伪hybrid开发”，以及APICloud。

　　为什么将hybrid开发和APICloud分开?因为APICloud是一个包含跨平台APP开发引擎、开发工具、云服务、模块市场等服务的完整APP开发生态。目前APICloud已经推出面向Web开发者的Deep引擎、面向已有native应用的SuperWebView、模块市场，以及数据云、运营云等云服务快速开发环境。不能仅仅作为一种“工具”或者单一技术看待。

　　下面我们简单列举一下四种技术选型的优势和劣势：

　　01 原生开发

　　优势：

　　厂商原生技术，自由度最大。

　　社区和文档化都非常完善，各种技术资料和解决方案相当丰富。

　　历史比较久，具备一定资历的开发人员比较好招(并不意味着便宜)。

　　劣势：

　　开发成本高，技术难度高。

　　项目无法跨平台，需要两支团队。

　　需要投入的开发、测试力量以及周期都比较长，这会导致迭代节奏偏慢(要想快就得加人)，不一定跟得上产品的迭代节奏。

　　02 Hybrid开发

　　优势：

　　网页迭代速度快，这个是公认的。

　　跨平台性突出，有利于节省人力，1到1.5人可以维护两大平台的应用。

　　前端社区的技术演进非常快，社区活跃。

　　当下而言，前端工程师人力资源比较丰富。

　　劣势：

　　性能劣于原生开发，容易出现性能问题。

　　严格说hybrid只是一种技术理念，而并不是具体的技术解决方案。应用开发商常常需要自行构建维护技术栈。

　　虽然有封装了native接口的hybrid框架(比如ionic)可选择，但是对于相对复杂的应用，现有的hybrid框架并不能满足需要，所以使用hybrid方式开发的应用，常常需要原生补充，这种情况下不同模块的用户体验难以统一。

　　03 RN/Weex

　　优势：

　　使用系统原生UI组件，性能和体验相比hybrid更接近于原生。

　　由于RN和Weex都是一线互联网厂商的产品，除了组件和api封装之外，还会对热更新一类的工程需求给出明确解决方案。

　　劣势：

　　不使用html5自然有好处，但是也会带来坏处。比如，需要分别搭建Android和IOS开发环境，分别Release。RN的核心理念是“learn once write anywhere”而非“write once run anywhere”。

　　再比如针对RN/Weex的设计并不像hybrid那么灵活，并且会一定程度上产生平台分化。

　　学习曲线可能不像大家想像中那么平滑，不管是前端还是移动开发工程师，进入RN/Weex领域还是需要一个学习期的。

　　RN/Weex的可调式性比纯浏览器还是要差上一截，开发体验并不那么好，这也一定程度上增加了开发成本。

　　04 APICloud

　　说优势劣势之前，我们先来解释一下APICloud和原始hybrid的区别。hybrid技术是APICloud“端”开发的核心技术手段，但是APICloud基于hybrid做了很多事。从项目开发过程来看，使用现有开源的hybrid技术或者自建hybrid框架，更像是自己买菜做饭，建立和维护技术栈，以及针对各种问题积累know how的成本是比较高的，而使用APICloud开发，其体验更像是使用.net、java这样的企业级开发技术栈，或者说去饭店点餐，你拿到手的东西已经相当完整，可以直接聚焦于应用。

　　优势：

　　传统hybrid开发的优势，APICloud基本是具备的。

　　相比传统hybrid，APICloud提供的是整体解决方案以及标准化的技术平台，不需要自行搭建热更新等外围技术。

　　技术支持体系，开发者社区，有全面的产品、技术文档、视频教程等，技术论坛中有活跃的开发者，也有官方一线产品人员提供技术支持，这在国内的社区中，维护度算认真的了。

　　模块市场。模块是APICloud的核心优势之一，编码时拿来即用，无需重复造轮子，目前有五六百个模块，涵盖了APP开发过程中90%以上的功能，同时聚合了国内主流第三方服务，比如IM，推送，人工智能，物联网，直播等等。原生开发者还可通过APICloud的模块扩展机制，开发模块在模块Store上进行售卖。

　　APICloud利用高效的“混合渲染”和模块化机制，为APP提供与原生一致的性能，同时还继承Html5开发简单的优势，二者对开发人员来说基本上是透明的。

　　劣势：

　　由于APICloud是基于标准html5扩展的技术，API比较新，开发人员需要一定的时间熟悉、学习其扩展的API(个人认为相对RN/Weex来说要容易一点)。

　　在APICloud中开发APP，原则上不提倡使用JQuery等传统Web开发常用的库和框架。习惯使用框架的前端开发人员使用APICloud开发APP时，可能还需要花时间去适应。

　　APICloud的技术引擎和大部分的模块没有开源，这其实算是一把双刃剑，但从开发者角度讲，开源平台，会降低项目开发中的一定风险，尤其是可调试性。

　　就技术而言，目前APICloud的客户端技术，很像是桌面端的混合开发方案electron，立足于html5，通过统一标准的API消除不同平台、不同操作系统之间的差异，达到APP跨平台的目的。但是相比纯技术方案，APICloud是一个“有产品有生态有运营”的商业级开发平台。今天我们看到的特色，也主要是因此诞生的。

　　回到开始的观点，APICloud并不是原生开发的代替技术，APICloud实质上是一个为移动端app开发提效和赋能的平台体系。基于APICloud做应用，还是在原生应用中内嵌APICloud，其实是针对不同场景的不同技术选择，背后的核心理念就是“因地制宜”，什么样的场景，我采用什么样的技术能达到提效和附能的目的，是技术选择的唯一标准。

　　多说一句，国内大型互联网公司普遍采用了“大中台”战略，期望建设强大的中台去支撑业务。同样的，作为中小型团队，选择一种技术，并不是说静态地去看当下这个技术有哪些好处坏处，而是要放在“外置中台”的角度，动态的去审视。一个技术栈长远的看能决定你的研发模式和团队构成，所以这不是那个工具最省事。