一、跨平台开发技术介绍
入门路线
2015年Facebook 推出了React Native让跨平台开发技术火了一把,去年阿里开源了weex也朝着越来越热的趋势发展。为了节省开发成本,我们也得默默的跟上他们的步伐。
接下来我们会畅谈各类跨平台开发技术的优劣,告诉大家为什么要选择RN进行开发。
-
Native App(原生)
即传统的原生APP开发模式,Android基于Java语言,底层调用Google的 API;iOS基于OC或者Swift语言,底层调用App官方提供的API。体验最好。- 优点
- 直接依托于操作系统,交互性最强,性能最好
- 相比于其它模式的交互,原生APP体验是最优的
- 功能最为强大,特别是在与系统交互中,几乎所有功能都能实现
- 得益于原生是直接依托于系统的,所以可以直接调用官方提供的api,功能最为全面(比如本地资源操作,通知,动画等)
- 缺点
- 开发成本高,无法跨平台,不同平台Android和iOS上都要各自独立开发
- Android上基于Java开发,iOS上基于OC或Swift开发,相互之间独立,必须要有各自的开发人员
- 门槛较高,原生人员有一定的入门门槛,相比广大的前端人员而言,较少
- 原生的一个很大特点就是独立,所以不太容易入门,不像web前端一样那么广泛,而且Android,iOS都需要独立学习
- 优点
Web App
即移动端的网站,将页面部署在服务器上,然后用户使用各大浏览器访问,不是独立APP,无法安装和发布
Web网站一般分两种,MPA(Multi-page Application)和SPA(Single-page Application)。而Web App一般泛指后面的SPA形式开发出的网站(因为可以模仿一些APP的特性)-
优点
- 开发成本低,可以跨平台,调试方便,web app一般只需要一个前端人员开发出一套代码,然后即可应用于各大主流浏览器(特殊情况可以代码进行下兼容),没有新的学习成本,而且可以直接在浏览器中调试
- 维护成本低,如果代码合理,只需要一名前端就可以维护多个web app
- 更新最为快速,由于web app资源是直接部署在服务器端的,所以只需要替换服务器端的文件,用户访问是就已经更新了(当然需要解决一些缓存问题)
- 无需安装App,不会占用手机内存,通过浏览器即可访问,无需安装,用户就会比较愿意去用
-
缺点
- 性能低,用户体验差,由于是直接通过的浏览器访问,所以无法使用原生的API,操作体验不好
- 依赖于网络,页面访问速度慢,耗费流量,Web App每次访问都需要去服务端加载资源访问,所以必须依赖于网络,而且网速慢时访问速度很不理想,特别是在移动端,如果网站优化不好会无故消耗大量流量
- 功能受限,大量功能无法实现,只能使用Html5的一些特殊api,无法调用原生API,所以很多功能存在无法实现情况
- 临时性入口,用户留存率低,这既是它的优点,也是缺点,优点是无需安装,确定是用完后有时候很难再找到,或者说很难专门为某个web app留存一个入口,导致用户很难再次使用
Hybrid App
即混合开发,由Native通过JSBridge等方法提供统一的API,然后用Html5+JS来写实际的逻辑,调用API,这种模式下,由于Android,iOS的API一般有一致性,而且最终的页面也是在webview中显示,所有有跨平台效果-
优点
- 开发成本较低,可以跨平台,调试方便。Hybrid模式下,由原生提供统一的API给JS调用,实际的主要逻辑有Html和JS来完成,而由于最终是放在webview中显示的,所以只需要写一套代码即可,达到跨平台效果,另外也可以直接在浏览器中调试,很为方便,最重要的是只需要一个前端人员稍微学习下JS api的调用即可,无需两个独立的原生人员,一般Hybrid中的跨平台最少可以跨三个平台:Android App,iOS App,普通webkit浏览器
- 学习成本较低,这种开发模式下,只需要前端人员关注一些原生提供的API,具体的实现无需关心,没有新的学习内容,只需要前端人员即可开发。
- 功能更加完善,性能和体验要比起web app好太多,因为可以调用原生api,所以很多功能只要原生提供出就可以实现,另外性能也比较接近原生了
- 部分性能要求的页面可用原生实现,这应该是Hybrid模式的最多一个好处了,因为这种模式是原生混合web,所以我们完全可以将交互强,性能要求高的页面用原生写,然后一些其它页面用JS写,嵌入webview中,达到最佳体验
-
缺点
- 相比原生,性能仍然有较大损耗,这种模式受限于webview的性能桎梏,相比原生而言有不少损耗,体验无法和原生相比
- 不适用于交互性较强的app,这种模式的主要应用是:一些新闻阅读类,信息展示类的app;但是不适用于一些交互较强或者性能要求较高的app(比如动画较多就不适合)
-
React Native App
Facebook发起的开源的一套新的APP开发方案,使用JS+部分原生语法来实现功能。初次学习成本较高,但是在入门后,经过良好的封装也能够实现大部分的跨平台。而且体验很好。- 优点
- 虽然说开发成本大于Hybrid模式,但是小于原生模式,大部分代码可复用,相比于原生模式,这种模式是统一用JS写代码,所以往往只需要一名成员投入学习,即可完成跨平台app的开发,而且后续代码封装的好,很多功能可复用
- 性能体验高于Hybrid,不逊色与原生,这种模式和Hybrid不一样,Hybrid中的view层实际上还是dom,但是这种模式的view层是虚拟dom,所以性能要高于Hybrid,距离原生差距不大
这种模式可以认为是用JS写原生,即页面用JS写,然后原生通过Bridge技术分析JS,将JS内容单独渲染成原生Android和iOS,所以也就是为什么性能不逊色原生 - 开发人员单一技术栈,一次学习,跨平台开发,这种模式是统一由JS编写,有着独特的语法,所以只需要学习一次,即可同时开发Android和iOS
- 社区繁荣,遇到问题容易解决,这应该是React Native的很大一个优势,不像Hybrid模式和原生模式一样各自为营,这种模式是Facebook统一发起的,所以有一个统一的社区,里面有大量资源和活跃的人员,对开发者很友好
- 缺点
- 虽然可以部分跨平台,但并不是Hybrid中的一次编写,两次运行那种,而是不同平台代码有所区别
- 这种模式实际上还是JS来写原生,所以Android和iOS中的原生代码会有所区别,如果需要跨平台,对开发人员有一定要求
当然了,如果发展了有一定时间,组件库够丰富了,那么其实影响也就不大了,甚至会比Hybrid更快 - 开发人员学习有一定成本,虽然社区已经比较成熟了,但是一个新的普通前端学习起来还是有一定学习成本的,无法像Hybrid模式一样平滑
- 优点
-
Weex app
Weex最底层的原理是和React-Native相同的,就是将JS代码渲染成原生组件,只不过在业务代码层面,Weex和React-Native有差别- 优点
- 一套代码跨平台,只要遵循特定的语法规则,完全可以达到一套代码多个平台运行
- 核心就是在web环境下,将源码编译成web中显示的Html dom对象等,在原生环境下编译成原生组件。而React-Native中,它是JS写原生代码,不同平台代码是不一样的,虽然有大部分可以复用,但并不是完全一套代码多个平台。
- 语法接近H5,基本用法和H5一致,特别是后来改成了支持VUE.JS后,使用起来更是很方便。
- 缺点
- 社区相比React-Native不足,是一个比较大的缺点,目前相比React-Native是新生,坑更多一点
- 优点
-
Web 流:也被称为 Hybrid 技术,它基于 Web 相关技术来实现界面及功能
Web 流最常被吐槽的就是性能慢(这里指内嵌 HTML 的性能,不考虑网络加载时间),以下是主要原因- 早期浏览器实现比较差,没有进行优化
- CSS 过于复杂,计算起来更耗时
- DOM 提供的接口太有限,使得难以进行优化
除了性能问题, Web 流更严重的问题是功能缺失,比如 iOS 8 就新增 4000+ API,而 Web 标准需要漫长的编写和评审过程,增加 4000 API 这辈子是等不到了。
-
代码转换流:将某个语言转成 Objective-C、Java 或 C#,然后使用不同平台下的官方工具来开发
- 为了保证APP体验,写原生代码是必须的,但不同平台下的官方语言不一样,这会导致同样的逻辑要写两次以上,于是就有人想到了通过代码转换的方式来减少工作量,比如将 Java 转成 Objective-C。
这种方式虽然听起来不是很靠谱,但它却是成本和风险都最小的,因为代码转换后就可以用官方提供的各种工具了,和普通开发区别不大,因此不用担心遇到各种诡异的问题,不过需要注意生成的代码是否可读,不可读的方案就别考虑了。 - 虽然代码转换这种方式风险小,但我觉得对于很多小 APP 来说共享不了多少代码,因为这类应用大多数围绕 UI 来开发的,大部分代码都和 UI 耦合,所以公共部分不多。
在目前的所有具体方案中,只有 j2objc 可以尝试,其它都不成熟。
- 为了保证APP体验,写原生代码是必须的,但不同平台下的官方语言不一样,这会导致同样的逻辑要写两次以上,于是就有人想到了通过代码转换的方式来减少工作量,比如将 Java 转成 Objective-C。
-
编译流:将某个语言编译为二进制文件,生成动态库或打包成 apk/ipa/xap 文件
编译流比前面的代码转换更进一步,它直接将某个语言编译为普通平台下的二进制文件,这种做法有明显的优缺点:- 优点
- 可以重用一些实现很复杂的代码,比如之前用 C++ 实现的游戏引擎,重写一遍成本太高
- 编译后的代码反编译困难
- 或许性能会好些(具体要看实现)
- 缺点
- 如果这个工具本身有 Bug 或性能问题,定位和修改成本会很高
- 编译后体积不小,尤其是如果要支持 ARMv8 和 x86 的话
- 优点
-
虚拟机流:通过将某个语言的虚拟机移植到不同平台上来运行
除了编译为不同平台下的二进制文件,还有另一种常见做法是通过虚拟机来支持跨平台运行,比如 JavaScript 和 Lua 都是天生的内嵌语言,所以在这个流派中很多方案都使用了这两个语言。- 不过虚拟机流会遇到两个问题:一个是性能损耗,另一个是虚拟机本身也会占不小的体积。
- React Native 的思路简单来说就是在不同平台下使用平台自带的 UI 组件。同时 React Native 和 Web 扯不上太多关系,我们熟知的 Web 是指 W3C 定义的那些规范,比如 HTML、CSS、DOM,而 React Native 主要是借鉴了 CSS 中的 Flexbox 写法,还有 navigator、XMLHttpRequest 等几个简单的 API,更别说完全没有 Web 的开放性,所以 React Native 和 HTML 5 完全不是一回事。
- React Native 比传统 Objective-C 和 UIView 的学习成本低多了,熟悉 JavaScript 的开发者应该半天内就能写个使用标准 UI 的界面,而且用 XML+CSS 画界面也远比 UIView 中用 Frame 进行手工布局更易读
- 它目前已经有组件仓库了,而且在 github 上都有 500 多仓库了,其中有 sqlite、Camera 等原生组件,随着这些第三方组件的完善,基于 React Native 开发越来越不需要写原生代码了。
二、RN开发环境搭建
React Native (简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架,是Facebook早先开源的UI框架 React 在原生移动应用平台的衍生产物,目前支持iOS和安卓两大平台。RN使用Javascript语言,类似于HTML的JSX,以及CSS来开发移动应用,因此熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域
- RN通信机制
- 开发工具
- WebStorm ( webstorm激活码)
- Xcode(只有mac系统才能开发iOS应用)
- Genymotion安卓模拟器
- Android Studio
- 开发论坛
- 环境搭建
React Native 环境搭建 官方提供了详细的搭建教程 - 环境搭建注意
- React Native 更新操作
- 更新项目版本 npm(Node Package Manager)
$npm update -g react-native - 查询网上RN最新的版本
$npm info react-native - 升级或者降级RN 版本
$npm install --save react-native@0.XX.X
- 更新项目版本 npm(Node Package Manager)
- 工欲善其事,必先利其器
ReactNative 代码智能提醒: ReactNative-LiveTemplate。
将ReactNative.xml复制到~/Library/Preferences/WebStorm/templates然后重启。 (没有templates手动创建,WebStorm名字可能不一样) -
iOS允许http请求设置(不然第一次运行会报错)
-
iOS RN 0.45以上版本所需的第三方编译库
OR(https://sourceforge.net/projects/boost/files/boost/1.63.0/)
- React Native 更新操作
三、创建我们第一个RN项目
- React Native项目创建
react-native init YochiProject
cd YochiProject
react-native run-ios(运行iOS应用)
react-native run-android(运行安卓应用)
-
打开WebStorm,导入我们的项目即可开始开发了