跨平台开发已经不是什么新鲜的词了,现在再来整理这些有点为时过晚了,不过还是想把自己这两年投入在移动端跨平台开发上的一些经验和一些踩的头破血流的坑分享给大家,毕竟这块是自己第一个单独钻研与开发的一个方向,也希望通过这篇文章给正在选型的小伙伴带来些许的帮助。
在此郑重声明,本片文章没有什么实用的干货,只是一点点小小的见解,比较适合正处在开发前期选型阶段的小伙伴(*/ω\*)
1.前言
第一篇文章还是想先聊聊当前大环境下“五彩斑斓”的跨平台开发框架。由于这些框架越来越多的出现,我在这就聊三个具有代表性的移动端跨平台开发框架React Native、Flutter、Xamarin。不过在进入主题之前,有一些相关的话题还是想扯一下,本片只是简单的总结与比较分析,不是非常专业,有不当的地方欢迎指出。
2.移动端开发方式
这里先罗列一下当前移动端的三种开发方式
原生开发
这个对于大家来说一定不陌生,原生的开发目前来说就是Android(JAVA、Kotlin)和IOS(Object-C、Swift),这也就是最传统最原始的移动端开发。
优点 | 缺点 |
---|---|
速度快、性能高、稳定性强、用户体验好 | 前期开发费用高 |
可以访问手机所有功能 | 后期维护繁琐 |
支持大量图形和动画 | 上线时间无法固定 |
可线下使用 | 升级灵活性差 |
混合开发
混合开发也比较好理解,就是H5与原生开发的结合,主要是用js和原生技术相互调用,可以初步实现跨平台使用的效果,现在我们日常使用当中有很多App都是通过这种方式实现的。
优点 | 缺点 |
---|---|
兼容多平台 | 性能相对较差 |
节省人力成本,缩短开发周期 | 用户体验不如原生 |
学习成本较低 | 技术不成熟 |
跨平台开发
一次编写,多平台运行,不需要针对特定平台进行开发(不同的跨平台开发框架有一定的差异)。
优点 | 缺点 |
---|---|
缩短开发周期 | 性能稳定性低于原生 |
降低开发成本 | 用户体验不如原生 |
学习成本相对较低 (各个平台不同) | 技术不成熟 |
其实这中间还有一种叫WebApp,但从我个人角度来看,不愿意将其归类于App或者将WebApp归类于一种开发方式,因为从原理的角度来看,它的本质就是Web,就是用传统的H5开发而来,只不过是放在移动端的网页上显示而已,如果非要给其加上一个标签的话,我觉得“轻应用”再合适不过了。
时代在发展,社会在进步,人人都在追求高效的生活与工作方式,在许多用户都认为移动端的开发中本机语言、Objective-C、Swift 和 Java 是唯一的选择的时候,跨平台技术顺应着时代和人们的需求而产生。
3.跨平台开发技术
1.React Native 传送门
Facebook;JavaScript语言;JSCore引擎;React设计模式;原生渲染
“Learn once, write anywhere” ,代表着 Facebook对 react native 的定义:仅需学习一次,编写任何平台。这句话需要好好理解,这并不意味着我们可以只写一遍代码就可以在多个平台上面运行,这与“Write once,run anywhere”是有本质上的区别的。
RN使用Javascript语言,类似于HTML的JSX,以及CSS来开发移动应用,因此熟悉Web前端开发的技术人员只需要对应的学习移动端的一些知识就可以初步进入移动应用开发领域。
优点 | 缺点 |
---|---|
复用了 React 的思想,有利于前端开发者快速上手移动端 | 做不到write once,run anywhere,部分开发依然需要为 iOS 和 Android 平台提供两套不同的代码 |
组件化开发,复用率高 | 应用性能比不上原生 |
可以利用 JavaScript 动态更新的特性,快速迭代 | 对开发人员技术要求高,不单单需要前端开发经验 |
相比于原生平台,开发速度更快 | 文档还不够完整,学习曲线偏高 |
简单来说,React Native是利用 JS 来调用 Native 端的组件,从而实现相应的功能。
2.Flutter 传送门
Google;Dart语言;Flutter Engine引擎;响应式设计模式;原生渲染。
Flutter是谷歌的移动UI框架,作为Google的亲儿子,开发语言是Dart。同时Flutter也是构建未来的Google Fuchsia应用的主要方式。
本人有幸在18年年初尝试过Flutter的Bate测试版本,至于现在的正式版还未使用过,不过我相信肯定比Bate版本完善了很多东西。虽然Google也曾大肆宣扬过Dart语言,但就编写而言,代码的可读性并不是非常友好。最近在很多社区的观察,发现Flutter的好评不少。
优点 | 缺点 |
---|---|
一套代码开发 | 前期bug较多 |
一切都是widget,灵活性强 | 代码可读性相对不友好 |
动画处理强 | 对于没有移动端和前端经验的小伙伴来说上手较难 |
熟悉Java的小伙伴上手相对快一些,还是能从代码中感觉到Java的影子。
2.Xamarin 传送门
微软;C#语言;基于Mono;原生渲染
Xamarin采用C#作为开发语言对于很多.net工作者是一个福音,这意味着.net工作者们不用再去重新学习一门语言,仅仅用自己最熟练的语言就能开发移动端应用。
Xamarin的跨平台思路很简单,就是使用C#来完成所有平台共用的,和平台无关的 app 逻辑部分。由于各个平台的 UI 和交互不同,再使用由 Xamarin 封装好的 C# API 来访问和操控 native 的控件,分别进行不同平台的 UI 开发。
另外Xamarin还提供了Xamarin.Forms UI工具包,Xamarin.Forms可以帮助开发人员快速的构建跨平台的UI,通过一次编码,生成多个平台的原生UI界面。
优点 | 缺点 |
---|---|
生态系统庞大(支持Android、IOS、WP、MacOSAPP) | 国内社区不完善 |
可移植性强 | 除了官网外的相关文档较少 |
Xamarin.Forms代码复用高达94% | 新版SDK的封装更新不及时 |
近乎原生的体验 | 第三方SDK的引用相对复杂 |
简洁的代码,简洁的界面,.net开发人员也可以用C#来开发移动端应用。
总结:不管什么跨平台开发框架,都要去选择最合适自己的。但不管选择何种框架,前提还得对原生的开发环境以及开发模式有一定的了解,不然也是事倍功半。虽然现在市面上移动端的跨平台开发工具开发出来的App性能都和原生有一定的差距,但还是有他们自己的优势,并不是所有公司都能长期承担起原生App开发与维护的成本,这也是他们能长期存在的理由。
本人研究的时间也不长,肯定有总结的片面的地方,欢迎指出。
后续会持续更新Xamarin方面相关的技术文档与采坑经验,敬请期待。(つ•̀ω•́)つ