移动开发的跨平台技术演进

　　移动开发的跨平台技术演进

　　1. 跨平台技术的诞生

　　我是2010年开始从事的Android开发，当时会Android和iOS开发的不多，也不火，全部人都在“摸着河底过河”，项目更没有第三方框架一说，大都是本身写的，不像如今各类的框架满天飞。随着移动开发的发展，互联网公司也是层出不穷，有些公司迫于竞争，想要更迅速的更省成本的进行开发，就再也不知足Android端一套代码，iOS端一套代码。与此同时，其余技术领域和各大公司也都觊觎着这份大蛋糕，纷纷推出相关的技术，这样跨平台技术应运而生，而且开始在公司中生根发芽。

　　Android和iOS生态太大了，咱们能够把它们比做第一级生态，想要颠覆这两个系统的曾经出现过，但都失败了，所以创建次级生态是最稳妥的策略，Android平台更加开放，所以次级生态的中心就是Android，次生态的形式多种多样，好比在Android系统的基础上魔改创建本身的生态，再或者推出各类跨平台技术创建生态。跨平台技术产生的框架实在太多了，不少还没等咱们去学去了解，它们就没落了，成为了跨平台技术的发展的一个过分产物。跨平台技术的产物是不靠谱仍是趋势，我想读完本篇文章你会有本身的理解。

　　跨平台技术的分类没有标准的答案，这里把它们分类为5种，分别Web App、Hybrid App、语言编译转换、原生渲染、自绘UI。下面分别介绍它们。

　　2. Web App

　　Web App是指基于Web的应用，运行于网络和标准浏览器上，至关于一个网页而后加一个App的壳。2014年HTML5的标准规范制定完成，在网络舆论上Web App大有取代Native App的气势，但Web App有如下缺点，使得它始终是“主角的心，配角的命” ：

　　性能低，操做体验很差

　　没法调用原生API，不少功能没法实现，

　　依赖于网络，网速慢时体验不好，而且没有离线功能，优化很差的话会消耗流量

　　只能作为一个临时的入口，用户留存率低

　　在Web App的基础上，又出现了几个进化者，这里主要介绍PWA。

　　2.1 PWA

　　PWA（Progressive Web App）意为渐进式加强Web应用，它不是一门技术，而是一个概念，使用多种技术来加强 Web App的功能：

　　用Service Worker + HTTPS +Cache Api + indexedDB 等一系列web技术实现离线加载和缓存

　　实现了推送和通知

　　能够直接添加到手机的桌面上

　　使用Service Worker能够进行后台同步

　　总结起来，PWA的主要的能力就是离线、推送、桌面访问，能够说PWA赋予Web App原生的体验，可是PWA一直不温不火的缘由主要有如下几点：

　　游览器对PWA技术支持还不够全面， 不是每一款游览器都能100%的支持PWA

　　国内一些手机厂商对Android系统各类魔改，对PWA的兼容性很差，甚至不支持PWA

　　平台的竞争，iOS对PWA的支持力度远远低于Android，因此PWA在iOS上的体验打了折扣。PWA面对相似的微信小程序和快应用的竞争中，并无优点。

　　3. Hybrid App

　　除了采用原生和Web开发App，还能够采用HTML5+原生来进行混合开发，这就是Hybrid。

　　关于Hybrid的诞生有一个小故事，某个二线互联网公司的App是以原生为主，HTML5开发打酱油，随着应用愈来愈复杂，终于有一天发现原生有一个方法最大数限制，一些页面须要内嵌HTML5的页面，因而原生和HTML5团队一块儿作了第一个Hybrid项目，这一套代码兼容三端而且效率很高，所以Hybrid App就成了这个公司的主流，业界其余的公司也都纷纷效仿。

　　经过原生SDK提供的API，App能够与系统底层通讯，以建立 UI 组件或访问系统服务。这些组件被渲染到手机屏幕，屏幕产生的相应的事件会被传回给组件。由于每一个平台的系统组件是不一样的，你须要为每一个平台开发单独的 App，而Hybrid App没必要这样，Hybrid App的原生UI组件用来展现交互复杂和渲染要求高的界面，其余的能够交给HTML5来展现。

　　Hybrid App虽然开发效率高，能够跨平台，可是Hybrid体验比不上原生，对于须要快速试错、快速占领市场的团队来讲，Hybrid App是一个不错的选择，后期团队稳定下来后，最好仍是要作体验更好的原生APP或者使用其余体验更好的跨平台技术。

　　Hybrid相关的技术有不少，好比PhoneGap、Cordova、Ionic、VasSonic等等，咱们大概来了解一下。

　　3.1 Cordova

　　说到Cordova，不得不提到他的前身PhoneGap，PhoneGap面向Web开发人员，经过使用HTML、CSS和Javascript构建跨平台App。2011年，Apache收购了Nitobi Software和它的PhoneGap产品，并对PhoneGap进行开源，PhoneGap 2.0版本时，产品改名为Apache Cordova。目前Cordova支持的平台有Android、iOS、Windows、Mac OS X、Electron。

　　Cordova一样使用WebView来展现界面，插件是Cordova中不可或缺的一部分，Apache Cordova维护了名为Core Plugins的插件，这些核心插件为App提供访问设备功能，如电池，相机，联系人等。除了核心插件以外，还有一些第三方插件可使用，你也能够开发一个本身的插件。

　　3.2 Ionic

　　Ionic Framework是一个开源UI工具包，最先的目标是使用HTML，CSS和JavaScript等Web技术开发移动应用程序。因为Web技术的这一基础，Ionic能够在网络运行的任何地方运行，好比 iOS，Android，浏览器，Electron，PWA等等。

　　目前，Ionic Framework已与Angular正式集成，但对Vue和React的支持正在开发中。

　　3.3 VasSonic

　　VasSonic是由腾讯VAS团队开发的轻量级高性能混合框架，旨在加速在Android和iOS平台上运行的H5首屏。VasSonic不只支持服务器呈现的静态或动态网站，并且还完美兼容Web离线资源。VasSonic使用自定义的url链接而不是原始网络链接来请求索引html，所以它能够提早或并行请求资源以免等待视图初始化。在这种并行的状况下，VasSonic能够经过WebKit或Blink内核读取和呈现部分数据，而无需花费太多时间等待数据流的结束。

　　3.4 微信小程序

　　微信小程序的主要开发语言是 JavaScript ，小程序的开发同普通的网页开发相比有很大的类似性。

　　小程序的运行环境分红渲染层和逻辑层，这两层分别由2个线程管理，渲染层的界面使用了WebView 进行渲染，逻辑层采用JsCore线程运行JS脚本。这两个线程的通讯会经由微信客户端（Native）中的JSBridage作中转。逻辑层发送网络请求也经由Native转发。

　　其中 WXML 模板和 WXSS 样式工做在渲染层，JS 脚本工做在逻辑层。

　　微信小程序和PWA都是基于Web技术，原理的区别是小程序相似Hybrid架构，WebView渲染基本的网页内容，对渲染性能要求较高的组件，经过原生组件来实现，好比相机、视频、地图等等，另外传统Web没法访问的本地能力，须要经过JS SDK来实现，而PWA则是使用多种技术加强Web能力，以达到接近Native应用的体验。

　　微信小程序自己和App就不是竞争关系，更多的是一个推广渠道，它更像是一张海报，用于快速推广倒流，而App则是要推广的对象。微信小程序的缺点很明显，体验上没法跟App相提并论，功能依托并受限于微信，没法进行拓展。能够说微信小程序就是创建了次级生态，这个生态中微信说的算，其余对手的发展会受到威胁。

　　4. 语言编译转换

　　语言编译转换指的是直接将某个语言编译为一个平台下的二进制文件。比较有名的是Xamarin框架，虽然它在 Android平台是内嵌了Mono虚拟机来实现的，但在 iOS平台下是以AOT 的方式编译为二进制文件的，因此把它归到语言编译转换类型。

　　4.1 Xamarin

　　Xamarin始创于2011年，2016年被微软正式收购。Xamarin是Mono项目的一个分支，基于.NET的跨平台实现的一个开源项目。

　　与PhoneGap等框架不一样的是，Xamarin能够在iOS和Android刚推出新的功能时，第一时间调用相应的API，而使用PhoneGap则须要等待PhoneGap封装的新的功能后才能够调用相应的API。

　　C#代码写的Andriod应用在运行的在Mono虚拟机中，ART能够经过ACWs（Andriod Callable Wrappers）的方式执行到Mono中的C#代码。C#代码要是想调用系统功能或者Java的实现类库，能够借助MCW（Managed Callable Wrapper）的方式来实现。MCW是JNI的桥梁，可使用托管代码调用Andriod代码。

　　5. 原生渲染

　　原生渲染在本篇文章中指的是由JavaScript开发而且由原生控件渲染，表明有React Native、Weex、快应用。

　　5.1 React Native

　　Facebook曾在移动端寸步难行，他们认为能够不借助任何原生开发手段来实现Facebook的移动应用，所以在早期选择了HTML5，后来发现HTML5的效率始终没法和原生相比，所以在2015年发布了React Native。

　　React Native是Facebook早先开源的 Web UI框架React在原生移动应用平台的衍生产物，底层对Android和iOS平台的原生代码进行封装，经过使用JavaScript就能够编写出原生代码。

　　Virtual DOM是DOM在内存中的一种轻量级表达方式，能够经过不一样的渲染引擎生成不一样平台下的UI。React Native与原生框架经过Bridge进行通讯，若是使用Chrome浏览器进行调试，那么全部的JavaScript代码将运行在Chrome V8引擎中，经过WebSocket和原生代码进行通讯。

　　5.2 Weex

　　Weex 是阿里开源的一款跨平台移动开发工具，它可以完美兼顾性能与动态性，让移动开发者经过简捷的前端语法写出原生级别的性能体验，并支持iOS、Android、YunOS及Web等多端部署。目前 Vue.js 和 Rax 这两个前端框架被普遍应用于 Weex 页面开发，所以Weex支持Vue语法和Rax语法，而React Native只支持JSX语法。

　　Weex首先将编写的Weex源码，经过transformer转换成JS Bundle。而后将JS Bundle部署在服务器，当接收到终端（Android、Web端、iOS端）的JS Bundle请求时，将JS Bundle下发给终端。在终端中，由Weex的JS Framework 接收和执行JS Bundle代码，而且执行数据绑定、模板编译等操做，而后输出JSON 格式的 Virtual DOM，JS Framework发送渲染指令给Native ，提供 callNative 和 callJS 接口，方便 JS Framework 和 Native 的通讯。

　　5.3 快应用

　　2018年3月份，由小米，OPPO，VIVO，华为等10家国内主流厂商成立了快应用联盟。快应用介于移动网页和原生应用之间，第三方应用以移动网页的形式进行开发，最终获得原生渲染的效果体验。快应用框架深度集成进各手机厂商的手机操做系统中，能够在操做系统层面造成用户需求与应用服务的无缝链接，不少只用在原生应用中才能使用的功能，在快应用中能够很方便的实现，享受原生应用体验，同时不用担忧分发留存等问题，资源消耗也比较少。对于每台手机设备，应用能够从多个系统入口，引用用户体验产品。

　　与React Native和Weex相比主要有两点不一样：

　　快应用自身不支持Vue或React语法，它采用的是JavaScript开发。

　　React Native和Weex的渲染引擎是集成到框架中的，每个APP都须要打包一份，安装包体积较大，快应用渲染引擎是集成到ROM中的，应用中无需打包，安装包体积小。

　　和微信小程序很像，快应用本质上也是要创建次级生态。

　　快应用实现划分为编译时、运行时两个方面，UX页面源码通过编译时获得JS，而后通过运行时获得界面UI。每个页面由HTML+CSS+JS组成，编译运行后获得内存中的DOM树。多个页面组成一个项目，编译后获得rpk文件，最终运行时以应用形态呈现。

　　快应用推出1年后仍然不温不火，面对微信小程序，快应用在流量和入口等关键数据都没法与小程序匹敌，将来发展堪忧。

　　6. 自绘UI

　　自绘UI指的是经过在不一样平台实现一个统一接口的渲染引擎来绘制UI，而不依赖系统平台的原生控件，这样作能够保证不一样平台UI的一致性。不用像React Native同样，随着不一样平台系统版本的变化，开发者还须要处理不一样平台的差别，甚至有些特性只能在单个平台上实现，这样没法保证不一样平台UI的一致性。自绘UI框架的表明有Qt和Flutter。

　　6.1 Qt

　　Qt产生的时间很早，Qt 初版于 1991 年由 Trolltech 发布。后来在 2008 年，Nokia 斥资 1.5 亿美圆收购 TrollTech，将 Qt 应用于 Symbian 程序开发。2012 年 8 月 9 日，Nokia 将 Qt 以 400 万欧元的价格出售给 Digia。2016年Qt Group Plc从Digia分拆出来，2014年Qt开始支持移动端的Android、iOS、Wp平台。虽然Qt在PC领域发展良好，但在移动端表现不佳，不多有人说起或者用Qt去开发移动端。

　　6.2 Flutter

　　Flutter是谷歌的移动UI框架，能够快速在Android和iOS上构建高质量的原生用户界面， 它的前身是谷歌试验项目Sky。

　　Futter提出了一切皆为控件（Widget）的概念，除了基本的文本、图片、卡片、输入框等Widget，布局方式和动画等也都是Widget。经过使用不一样类型的Widget，就能够实现复杂度的界面。

　　Flutter框架采用了分层设计，此设计的目标是帮助开发者使用更少的代码完成更多工做。例如，Material层是由widgets层的普通widget组成的，而widgets层自己是经过来自rendering层的低级对象构建的。

　　目前在Flutter基础上开发的框架已经开始出现，这也证实了业界广泛开始承认Flutter，并开始进行尝试。

　　总结

　　跨平台技术的分类没有标准的答案，这里也只是粗略的进行分类，并对每一个分类的主流框架进行介绍，实际上还有不少框架没有提到，它们不是没落了，就是缺点明显难以使用，再就是大公司的KPI产物。跨平台技术的演进比如百家争鸣，极大的促进了跨平台技术的发展。在我看来，这些技术让不一样技术分支的程序员均可以参与到移动开发中，享受移动开发的乐趣，从这个角度来看这些跨平台技术的优劣之分是很难去评判的。我更但愿有一个框架能统一移动端跨平台，这个框架会是Flutter吗？仍是下一个未知的框架？你更看好哪一个跨平台技术呢？