从点子到App -- 用ionic构建混合移动应用最新章节_李永强著

第二节
为什么选择Ionic？

为什么选Ionic的这个问题可以扩展为： 如果要互联网创业/创新，该走那条技术路线？ 再扩一步，就是： 如果要互联网创业/创新（不断试错），如何有效解决痛点（真实需求）？

这个问题可以从多个维度去考量，比如实际需求、设计协作、技术框架比选、团队擅长、外部资源、发展趋势等等。这里，我想先从两三年前实际项目中的痛点说起。

业务驱动

例子：一款电商App，为了原生App的体验，考虑到种子用户iPhone居多，第一版App的前端代码使用Objective C编写。之后为了覆盖更多的用户、启动了AndroidAPP的开发。在迭代过程中，需要增加导购内容、以及微信H5页面分享内容的特性，为此， 产品经理和iOS的前端工程师、Android前端工程师、后端工程师 沟通讨论，画mockup、敲定模块展示需求和数据交换接口，投入开发，测试上线。上线之后取得种子用户的反馈再进行优化（新一轮的团队沟通讨论->敲定需求->开发测试->上线）。

如果此项目采用了Ionic作为开发框架，会有一些什么样的不同？

首先， 实现同样的功能，核心团队只需要 产品经理和Javascript全栈工程师 即可。发布至Android市场不用再次投入开发； 仅需维护一个Javascript/TypeScript开发栈，不仅每一次迭代都能提速、而且减少很多沟通成本；

其次，不会丧失原生App的用户体验， 不仅因为Ionic是跨平台的原生开发框架、而且ionic是得到市场认可的app框架；

其三，与现有的社交网络容易集成， 因为ionic是基于javascript的nodejs应用、SNS分享这些Web需求对于ionic来说轻而易举。

总体来说，选择Ionic将事半功倍。 而这对于创新创业公司来说至关重要，创新就是不断试错，然而残酷的现实一再发生：某某创业团队在试错过程中把钱烧光了、然后就是各种版本的When Bad Thing Comes。当需求方向对了，比得是市场响应速度；当方向错了，比得是账面上的钱还能错几次、每次几个月。

设计/体验驱动

看过不少讲技术的文章，提及设计得很少，多是纯技术；讲设计的文章也是不一而同地很少掰扯技术。可能搞技术的多是理工科、搞设计的多是创意和文艺，是两种截然不同的专业背景的人。

然而，自从iPhone诞生的那一天起，互联网应用的用户体验就被重定义了；人们都知道一件事情了： App如果还要培训才能用、那就没有人会用了。 不是技术不好，而是体验差。用过SAP的都知道企业级应用的体验有多差劲——虽然SAP服务80%的500强，其系统的用户体验已经是企业级应用里好的了，但系统用户不接受培训肯定还是不会用的。2017年初SAP和苹果的CEO就提升用户体验合作一事还上了新闻。

从当下移动互联+B端应用升级更新的趋势来看，选择Ionic/Angular这样的框架是企业应用拥抱移动互联网的很好的选择（当然，SAP也有基于Cordova写得移动框架，欢迎有经验的朋友一起交流）。用Ionic不仅可以实现优秀的App交互体验，而且代价较小。

比如若要让业务环节的提醒能通知到不同用户的设备上并及时得到处理，那么ionic实现起来只需轻量开发团队、编写一套代码，还能有接近原生的体验。能让企业用户不论用什么设备都用着舒服，关键业务流程无停歇、跨时区甚至跨国地运转，企业自然愿意掏钱升级提升效率了。

技术框架与理念

在ionic之前，跨平台的移动应用开发框架就有phonegap/cordova,APPcelerator的titanium等存在了，但体验不够时尚。目前混合app的开发者社群已然被ionic及react native分走了，phonegap和titanium这两个框架在github上关注度都维持在几K这个量级。

当下，跨平台的移动应用开发框架主要是两个：facebook背书的react native；Drifty Co.创建的ionic框架（基于google和微软联合背书的angular）。facebook就不多说了，react native这两年发展迅速，目前github上关注在5万左右；与此同时，react关注度在6.6万左右；对比google的angular关注度2.4万以及微软的Typescript关注2万，facebook的react框架可以说很成功。“Learn Once, Write Anywhere”也就成为了流行。

但是，Drifty Co.是个啥公司？压根没有听过额。大厂出好车容易接受，Drifty Co.这么个小团队出得Ionic能行么、他们在ionic之前没啥成功案例吧？ 2012年成立 之初只有 Ben Sperry 和 Max Lynch 两位创始人；在2017年，Drifty Co.也就20多人。但是，请注意，目前在github上ionic的关注度是3万左右，是仅次于react native的热门框架、而且比angular关注度还高。这么个小团队简直是酷炫啊，对比2017年facebook有近2万员工，Drifty Co.就是个让人心向往之的小而美团队。

按说，ionic和titanium的开发团队是类似的——人不多，做到超过titanium就已然不错了；毕竟facebook已然是巨头，react这样级别的创新对于小团队来说很难做成功（react站在多少试错的项目成本上）。Drifty Co.在弄ionic之前仅是做了个叫做Codiqa的Web拖拽mockup工具，自2015年ionic第一版发布以来能和react native受欢迎程度接近简直是个奇迹（想想facebook做个发布会有多少开发者关注）。Drifty Co.就是个典型的草根创业成功团队，虽然没有WhatsApp团队那么有名，但也已是世界级的了（毕竟框架仅面向开发者、而C端应用可覆盖每个人）；在致敬的同时我很好奇为什么ionic就成了、而且发展势头良好。

请允许我在展开技术框架对比之前，深入ionic框架背后的团队及所秉持的价值观。因为对于创业者来说，技术选型固然重要，但借鉴成功创业团队的理念和做法往往更具价值。

在 ionic官网上的列出价值观的一共六点，我就不一一翻译每点的详述了，写点感受：

1. 赋能他人。 免费、开源地赋能他人的理念使得ionic和titanium区别开来。举个小例子，想用titanium的开发中App预览功能需要每月支付99美元，而ionic View免费。ionic框架不仅体验好、而且免费开源，后来居上超越titanium这样的工具靠得是协作的互联网精神。

2. 少即是多。 ionic的用户体验和开发体验都不错，不仅上手快、而且可高度扩展，既能造轮子也能造车子。这一理念的落地使得开发生产力得到提高，比如一套代码多设备部署、比如简洁的用户交互体验。比react native的Lean Startup还要精益。

3. 真诚。 不搞粉丝营销、轰炸式推广；专注于教授、分享、倾听。匠人的口碑就是好产品，ionic基本是靠使用者的口碑传播开的。ionic没有FB那样的内部用户群，全是服务他人。这点能做到太可贵了。

4. 以同理心构建。 从工具的使用者角度考虑ionic如何为开发者解决实际问题。比如ionic也可以热更新App，即使用Live Update不用再次审核就可更新App。

5. 团队为先。 “不是个体有多牛，而是整体合起来互补、互助，如一家人”。换句话说没有大公司病。

6. 世界级。 “不是我们比谁更强，而是能不断突破自我、而且助力他人也能如此”。对比一些团队在东西还没做好得时候就弄竞争分析、打嘴仗，做不成就说进入了红海，ionic团队用奥林匹克精神做软件先进得多。

写到这里，我更加尊敬ionic团队，也知道了3万github关注背后的原因。

技术框架对比——Ionic V.S. React Native

图1.2.1

开发App的框架选型，这里我们扼要对比react native和ionic这两个热门框架的特点，实际项目中的选型当然还要综合考虑团队、产品、市场等因素。

混合与原生

从实现原理上来说，ionic开发的app是hybridAPP，而react native开发的app是原生app。ionic的HTML5, CSS以及angularjs前端代码结合ngCordova（v2中命名为ionic native）达到了跨设备一致的体验以及操纵GPS及相机等原生设备的功能；react native虽然也是javascript代码，但是其使用JSX来渲染界面时是直接调用原生的UI组件，这就使得其响应速度几乎与原生代码写成的app几乎一样流畅。

关于混合与原生App的性能对比，你可能会说Facebook抛弃H5转向原生后才有的React Native；混合App不如原生流畅，还是原生的好。这个观点在2、3年前还是很主流的，但目前混合的app运行效率低已然是过去式了。拿ionic来说，就不卡顿；v2版本(基于typescript)的app启动及运行效率比v1还提高了几倍（有ts编译为js时优化运行效率的机会）。这里既有摩尔定律的因素、也有框架演进的因素。

退一步说，如果单纯以运行效率为选型依据，混合app永远火不起来。必须指出的是：实际场景中，单设备跑得快的因素比重在逐年下降。以企业应用为例，企业的协同效率提升的价值远远超过了终端app能快到飞起。换个角度想：既然SAP系统使用体验那么差，咋还那么多企业用，这是为什么呐。

然而，也必须指出，世上没有万能药，适合你自己的、能有效解决问题的就是好的选择。ionic或者react native也只是选项之一。

代码重用

ionic是Write Once, Run Anywhere；react native是Learn Once, Write Anywhere。

从技能掌握的角度来说，ionic开发仅需懂javascript/typescript，而react native由于需要考虑不同设备的因素，虽然代码能大部分重用、或者也可以不写一行原生代码就能开发原生App，但是也需要开发者了解设备相关原生组件并具备构建iOS, Android, Windows不可重用部分的代码的能力。这也意味着ionic项目的开发、测试、部署成本较低。

开发栈

两者都是javascript栈，支持live reload。ionic基于angular，遵从经典HTML/CSS的代码风格，且以MVC方式解耦合前端和业务逻辑。react native推荐使用 JSX ，而其前端逻辑是耦合在业务逻辑内的。同样的todolist的前端代码，两者的参考代码如下（左边react，右边ionic）：

图1.2.2

对于react native开发团队来说，需要掌握JSX，一旦掌握了这种代码风格，使用起来也会比较轻松；对于ionic开发团队来说，不用学习JSX这种新东西，意味着启动更快速。

从协作的角度来看，ionic的项目的前端设计师不用了解业务逻辑代码、即可制作模板、修订CSS/SCSS文件；而react native项目的前端设计师需要在业务代码中找到各个前端组件的代码，自定义App的风格。虽然JSX不难，但是对于设计师来说，还是要有个适应的周期。

原生控件集成

网络上有一些声音：混合App只能使用Web View来集成原生控件，因此这种情形下使用原生为宜而非ionic。其中一些比较随着框架的演进有些过时，有必要更新认知。这里举一个ionic使用Google原生地图的例子，让我们可以重新权衡。

下面是ionic集成原生Google地图的截屏以及实现原理，可以看到3D原生地图也可用于ionic的应用中。这里的ionic顶层页面（browser view）需要设备透明背景，除了导航栏、将前端交互完全交由原生的地图控件。虽然这看起来有些tricky，但可以看到ionic也可以集成原生控件、而不单单是个Web Wrapper。

图1.2.3

图1.2.4

上例中使用的cordova的原生地图插件

https://github.com/mapsplugin/cordova-plugin-googlemaps

后端集成

两者都是javascript的前端框架，所以在与后端框架集成方面没有太大的不同。两者都可以使用目前流行的meteor，firebase，parse server，或者其他的BaaS/PaaS平台；当然也可以通过Restful API等Web Service对接任何已有的系统后台。本书的实例中将涉及ionic与parse server以及wordpress后台集成，供读者参考。

部署与升级

两者均可生成iOS, Android以及Windows平台的App。Ionic由于支持Progressive WebAPP方式部署，使得其可以利用SEO、社交广告等方式引流、也可以作为网页小程序嵌入到微信或者Facebook中。

说到react native，其热更新App的特性被热捧，其实ionic v1就也已经支持热更新了。ionic官方文档把热更新叫做Live Updates，属于ionic Cloud服务的一部分。而且不仅支持热更新、而且支持多个快照（Snapshots）分别部署到不同的发布通道（Deploy Channels），可支持A/B测试。这个特性有点类似于iOS的TestFlight，而且不局限于内测/外测多版本发布；这对于App上线后进行目标客群市场活动（e.g.Campaign by Customer Segment）等试错验证来说很有用。

总之，这两个框架都比较先进，能让开发者省去不少hot fix或升级的抓狂。

社区生态

从社区现有代码的角度看，两者自身社区都有相当的积累，ionic还有在线市场、可以助开发者快速构建高质量App。ionic基于的Phonegap/Cordova已然有大量原生组件，而react native甚至也有直接调用Cordova的组件，所以两者的社区代码都足够用。

从解决问题角度看，这两个框架的社区支持都比较完善。不仅开发者在stackoverflow和quora上互助，ionic的团队中也有专人负责官方社区答疑解难。

发展趋势

已经使用ionic的应用有：

图1.2.5

已经使用react native的应用有：

图1.2.6

来源： https://facebook.github.io/react-native/showcase.html

可见，不差钱的巨头大厂用react native比较多；而ionic不仅谷歌、微软在用，各种大中小微团队也在广泛应用。

就现在angular的发展状况看，typescript这几年还将保持上升的势头、贴近ES6标准，而ionic和angular团队定期沟通，发布的版本也是及时跟进，所以应该会不断演进；类似地，react native由于继承了具有先发优势的react框架（2013年发布），2015年发布时相当于是热启动，目前的发展势头良好，可预见未来几年的热度依然不太可能下滑。

互助群

以上说了这么多，可能对于自己的项目，选择哪个框架你已经心中有数了。如果你也选择ionic，不妨加入我们的交流群【QQ群：302915811】，互助互补。

【参考】

Ionic on Angel List

https://angel.co/ionic-2

Why did the Angular team choose TypeScript over Dart?

https://jaxenter.com/angular-typescript-dart-115426.html

如何看待Google和Microsoft在AngularJS2和TypeScript上的合作？

https://www.zhihu.com/question/28563233

Angular 4.0发布，致力于减小代码体积

http://www.infoq.com/cn/news/2017/04/angular-4-released

如何评价React Native？