第01课:混合移动应用开发和

第01课:混合移动应用开发和 Ionic 介绍

要介绍 Ionic,就一定要先介绍 Apache Cordova。Apache Cordova 的前身是 PhoneGap,最早由 Nitobi 公司开发。Adobe 在2011年收购了 Nitobi,并在 PhoneGap 的基础上提供了商业化服务,成为目前的 Adobe PhoneGap。PhoneGap 的源代码同时被贡献给 Apache 基金会,成为了新的开源项目 Apache Cordova。这也就是 Cordova 的由来。

Apache Cordova 介绍

Apache Cordova 的核心卖点在于使用 Web 的标准技术:HTML5、CSS3 和 JavaScript,来开发移动应用。Cordova 应用实际上是运行在 WebView 中的 HTML 页面。Cordova 应用中的 HTML 页面与我们通常所开发的面向浏览器的 HTML 页面并没有太大的区别,只不过屏幕的大小受到限制。除此之外,Cordova 应用可以通过插件来访问底层系统中的原生功能,包括重力感应器(Accelerometer)、摄像头、GPS、罗盘(Compass)、文件系统、消息通知和麦克风等。这些插件提供了 JavaScript 的 API,可以直接在页面中调用。Cordova 的插件生态系统也很健全。目前已经有近3000种不同的插件可供使用。很多常用的功能都可以在社区中找到适合的插件。

需要说明的是,Cordova 本身并不适合直接用来开发移动应用。Cordova 可以运行任何类型的 HTML 页面,而用户对于移动应用有自己的使用习惯和期待。这样的使用习惯和期待来源于对已有原生应用的使用体验。不同的移动平台,如 Android 和 iOS,都有自己独特的用户界面风格和交互模式。使用这些平台上的原生应用的用户,已经养成了独特的使用习惯。iOS 有自己独有的用户界面风格,Android 上也有 Material Design 这样的设计规范。从交互模式上来说,应用中的列表应该支持下拉刷新(Pull-to-Refresh)。Android 上的回退键,应该让应用回到上一个页面。

Cordova 应用如果需要满足用户对于原生应用的期待,就必须遵循这些已有的使用模式。这样的需求就催生了很多基于 Cordova 的移动应用开发框架。这些框架以 Cordova 为基础,增加了常用的 UI 组件,并支持类似原生应用的交互模式。Ionic 就是这些框架中的佼佼者。熟悉了 Ionic 之后,对于其他类似的框架也能很快上手。

Ionic介绍

说 Ionic 是一个流行的框架并不过分。作为一个开源项目,它在 GitHub 上的加星数(Star)有近3万2千。Ionic 已经从一个单纯的开源框架,发展成了一套完整的移动应用开发的解决方案。Ionic 背后的公司 Drifty Co 提供 Ionic 相关的商业化服务,这对维持 Ionic 开源社区的健康发展是大有好处的。

从框架本身来说,它包含如下几个部分:

  • 丰富的组件库:这些组件具有与原生组件相似的外观和交互模式。同一个组件在不同的平台上的外观是不同的。这就做到了“编写一次,到处运行”。组件库中包括非常多实用的组件,如菜单、列表、对话框、表单控件、日期和时间选择器、工具栏、标签式布局、搜索框和图标等。
  • 命令行工具:命令行工具可以完成很多任务,比如生成脚手架代码、运行构建任务、生成应用资源文件等。命令行工具基于 Node.js。
  • Ionic Native:Ionic Native 是基于 TypeScript 实现的对 Cordova 和 PhoneGap 插件的封装,方便在 Ionic 应用中使用。由于 Ionic Native 添加了插件 API 的类型信息,比在代码中直接使用 Cordova 插件的 JavaScript API 要方便很多。
  • 本地存储:本地存储可以保存名值对或 JSON 对象。Ionic 会根据底层平台的能力选择合适的存储方式。实际的存储方式可能是 SQLite、localStorage 或 IndexedDB。
  • Ionicons:平台相关的图标库。同样的图标名称,在不同的平台上产生的是与平台相关的不同图标。有了内置的图标库,就再也不用满世界的去找合适的图标了。

除了框架本身,Ionic 提供的完整解决方案还包括下面几个产品,作为 Ionic Pro 的一部分。

  • Ionic Creator:Ionic Creator 是一个桌面应用,可以用拖放的方式来创建 Ionic 应用。可以帮助非技术人员创建简单的应用或是应用的原型。
  • Ionic View:Ionic View 可以在手机上直接查看其他人分享的 Ionic 应用,方便进行测试,也可以与客户沟通需求时进行演示。
  • Ionic Deploy:Ionic Deploy 可以对应用进行热更新,并绕过应用商店的审核机制,快速更新内容。
  • Ionic Package:Ionic Package 可以构建 Ionic 应用,生成可以发布到应用商店的包。有了 Ionic Package,就相对于把构建工作转移到了云端,不需要在本地维护构建所需的工具链。
  • Ionic Monitor:Ionic Monitor 可以对应用进行监控,并报告运行时产生的错误。

从技术栈的角度来说,Ionic 应用基于 Angular,并使用 TypeScript 来编写。在样式方面,Ionic 使用的是 Sass。Ionic 应用使用的是典型的 Angular 应用的架构和技术栈。已有 Angular 经验的开发人员转到 Ionic,上手会非常容易。

为什么选择 Ionic?

和所有其他的移动应用开发解决方案一样,Ionic 也有自己的长处和短处,也有其适合使用的场景。抛开具体的使用场景来评价任何一种方案都是不客观的,而是应该根据需求来选择最合适的解决方案。

首先从 Ionic 的长处来说。Ionic 应用本质上是 Angular 应用,使用的是标准的 Web 技术。Web 开发人员的基数大,相关技术上手也比较容易。这给广大 Web 开发人员转到移动应用开发提供了一个跨度最小的选择。这对于选择 Ionic 的团队来说,也是有相应的好处。开发人员基数大就意味着可以更容易的找到有着相关经验的开发人员。即便是只有 Web 开发经验的人员,也能很快上手。Ionic 的学习曲线比其他框架要平滑不少。Ionic 是一种跨平台的移动应用开发解决方案。只需要维护一个代码库,就可以适配多种不同的平台。与跨平台相关的工作,都由 Ionic 来负责完成。Ionic Native 和Cordova 插件也让与底层系统交互变得平台无关。这就极大的降低了开发的复杂度。团队中也不需要为每个底层平台配置相应的开发人员。

Ionic 最大的短处就是性能了。这也是 Cordova 的架构和实现机制所带来的必然结果。Cordova 在追求平台无关性和通用性时,必然会对性能有所牺牲。Cordova 应用本质是运行在 WebView 上的 Web 应用。WebView 其实就是浏览器中渲染网页的组件。Cordova 应用与底层系统的交互,都需要通过这么一个中间层次来完成。毫无疑问,这样的中间层次肯定会增加额外的开销,限制应用的性能。另外,受限于 WebView 渲染时的性能,对于使用了大量 CSS 动画的应用来说,使用时会有相对明显的迟滞感。

关于 Ionic 性能的短处,可以从两个方面来看。从第一个方面来说,性能固然重要,但并不是移动应用开发中的唯一考量因素。开发时间和成本、上线时间(Time to Market)和团队的技能水平都是需要考量的。从另一个方面来说,随着技术的不断进步,浏览器本身的性能也在不断优化。移动终端本身的性能也在不断提升。Ionic 团队也投入了大量的精力在性能优化上。可以预见的是,Ionic 应用的性能在将来会不断提升。至于引入 Ionic 所带来的性能损失,是需要开发团队结合各方面因素,谨慎权衡的。片面的以性能方面的劣势来“黑”Ionic,是非常不客观的。就像我们不可能要求所有的应用都使用 C/C++ 或汇编语言来编写一样。

因为 Cordova 自身架构和性能方面的限制,Ionic 目前不适合用来开发某些类型的应用,主要是对性能要求比较高的,或是与用户的交互模式比较复杂的,以及与底层系统的原生功能交互很多的应用。Ionic 的强项在于信息展示类的应用,比如公司或个人的信息介绍类的应用、新闻展示类应用等。这些应用侧重的是信息的展示,与用户的交互相对比较简单,最多就是填写表单之类的动作。由于 Ionic 应用开发速度快,可以在应用的早期阶段来开发原型。在应用的设计早期阶段,会需要频繁对应用的设计进行讨论,或者与用户沟通需求。一个可以直接使用的原型,远比枯燥的设计文档或是图片来得直观。Ionic 开发的原型可以从用户获取到更有价值的反馈信息。即便是应用本身最终并不使用 Ionic 开发,使用 Ionic 开发的原型也很有价值。

Ionic 应用提交到应用商店是没有任何问题的。在 Apple 的2017年度最佳应用中,就两个 Ionic 应用被提到:健身应用 Sworkit 和情绪管理应用 Pacifica。

对于一个开发团队来说,应该根据项目的实际需求,以及团队成员的技能水平,来选择最适合的移动应用开发方案。这其中既有技术因素,也有非技术因素需要考量。

下一章中将介绍如何搭建 Ionic 开发环境和创建应用的骨架代码。

上一篇
下一篇
目录