本文目录
2022年你需要知道的跨平台应用开发框架总结
随着移动互联网的快速发展，微信小程序、Web、App、车载等各种形态的“端”悄然盛行。
而同一个业务需求往往又需要在多端上去实现，针对不同端去编写多套代码的成本显然非常高。
因此，“跨端”逐渐成为前端界比较流行的词汇。什么是跨平台应用开发框架？
开发人员可以使用一套相同的代码，一次性地编码即可在多个平台上面运行起来。
它减少了开发人员开发应用的时间，并且能够快速地交付。
所以目前为止，越来越多的人意识到跨平台应用程序和框架的好处和重要性。选择使用移动跨平台技术的原因？
作为用户来说，当然希望使用App的时候能够顺畅流利，不可否认的是，使用iOS和Android开发出来的应用非常流畅而且高效，但是缺点就是需要耗费较长的时间来开发。
比如同一个App，需要在Android和iOS两端各自开发一遍，确实比较耗费人力和财力。
所以人们希望选择使用跨平台应用开发框架来解决这一问题。
跨平台应用程序开发框架的好处：一个App适用于多个设备；一个App适用于多个平台；一个App可以在多个应用商店中发布；只需编写一次代码；代码可以跨平台复用；市场分析与测试；快速成型；快速开发；无缝产品维护；统一性、均匀性；为什么需要跨平台技术?
相信以上4点总结能够完全概括今天主要介绍几个主流的解决方案：Flutter、Weex、ReactNative、FinclipFlutter
Flutter由Google开发，它是一个牛逼的开源平台，可用于跨平台应用程序开发。
它具有吸引力的原因是：快速的开发，富有表现力的精美UI和类似本机的性能。
使用Flutter的一些公司是Google，eBay，宝马等。
选择Flutter框架进行跨平台应用程序开发的主要原因：高度稳定平稳的开发周期强大的热加载功能DART，AOT编译语言满足各种需求的UI套件
Flutter是最新的跨平台应用程序框架之一，由Google开发并于2017年发布。
Flutter是一个免费的开源跨平台框架，它允许你用一组代码创建一个移动应用程序。
它的独特之处在于它使用Dart编程语言，不同于其他跨平台应用框架，Flutter根本不使用JavaScript。
你可以改变你的代码并实时看到结果，只需片刻就可以升级应用程序。
您可以使用Flutter为iOS、Android和其他不太流行的移动平台创建跨平台的移动应用程序。
平心而论，就目前而言，这是为FuchsiaOS开发应用程序的唯一途径。优点：Flutter自带图形引擎，这意味着无需为iOS和Android分别制作界面。Dart使您能够编写额外的结构化程序代码，从而允许您创建更多层次结构和复杂功能。基于Flutter的移动应用程序快速高效。与其他跨平台应用程序框架相比，Flutter提供了更显着的性能提升。weex
Weex框架能够完美兼顾性能与动态性，让移动开发者通过简捷的前端语法写出Native级别的性能体验，并支持iOS、安卓、YunOS及Web等多端部署。
Weex致力于使开发者能基于通用跨平台的Web开发语言和开发经验，来构建Android、iOS和Web应用。
简单来说，在集成了WeexSDK之后，你可以使用JavaScript语言和前端开发经验来开发移动应用。
Weex渲染引擎与DSL语法层是分开的，Weex并不强依赖任何特定的前端框架。
目前Vue.js和Rax这两个前端框架被广泛应用于Weex页面开发，同时Weex也对这两个前端框架提供了最完善的支持。
Weex的一个主要目标是跟进流行的Web开发技术并将其和原生开发的技术结合，实现开发效率和运行性能的高度统一。
在开发阶段，一个Weex页面就像开发普通网页一样；在运行时，Weex页面又充分利用了各种操作系统的原生组件和能力。ReactNative
由Facebook在2015年开发的ReactNative可帮助企业使用Swift，ObjectiveC和Java等语言构建类似于本机的应用程序。
使用ReactNative框架的一些企业是Facebook，Skype，Tesla等。
选择React本机框架进行跨平台应用程序开发的主要原因：开源热加载社区驱动现成的组件
ReactNative是另一个流行的跨平台应用程序开发框架。
它与iOS和Android兼容。ReactNative于2015年初由Facebook开发，并由其自己的社区不断改进。
它是用React构建的，不使用WebView或HTML技术。它不是HTML，而是JSX中的平台组件，而不是CSS，它有类似CSS的polyfill。
此外，也没有DOMAPI。ReactNative由JavaScript和React.JS的组合组成。
它也允许开发H人员使用Swift、Java或Objective-C开发某些部分。优点：
ReactNative专注于用户界面，使应用程序开发人员能够构建高度可靠的界面。允许为各种平台创建应用程序，例如iOS、macOS、tvOS、Web、Windows、Android、AndroidTV和UWP开发工具Finclip
Finclip是凡泰极客研发的一套小程序容器技术，也可以说其实就是小程序SDK，可以兼容通过vue或react导出的小程序代码。
与Flutter、Reactive-Native等跨端语言不同的是，Finclip严格意义上讲是一项容器技术。
与上述的跨端技术不仅不冲突，还可以完美融合。不管是通过Flutter、Taro、kbone等开发出来的小程序均可在FinClip当中运行。
这种小程序容器技术也带来了许多好处：1、因为JS在Service层执行，所以JS里面操作的DOM将不会View层产生影响，所以小程序不能操作DOM结构的，这也使得小程序的性能比传统的H5更好。2、方便多个小程序页面之间的数据共享和交互。在小程序的生命周期中具有相同的上下文可以为具备原生应用程序开发背景的开发人员提供熟悉的编码体验；3、Service和View的分离和并行实现可以防止JS执行影响或减慢页面渲染，这有助于提高渲染性能；
而且FinClipSDK极其轻量，应用在集成后安装包的体积仅仅增大了不到3MB。
FinClip还自研了一个小程序IDE开发工具，界面与微信小程序的开发工具类似，自带调试和真机预览，简单易上手。
你可以在这个FIDE里面，对现有项目进行二次开发，扩展功能和接口。
同时，它还支持小程序一键转换成App，可以将已有小程序代码导出为IOS与Android中可用的工程文件,并上架至各应用市场。
由于导出的工程文件自动集成了FinClipSDK，所以直接拥有小程序的运行能力，后续可在这个APP上继续上架更多小程序，自建自己的小程序生态。
并且FIDE中还包含各类扩展插件和接口（支付、人脸识别、音视频、OCR等），开发者可自主勾选所需的支持插件，从而增强所生成App原生能力。
最后简单总结一下FinClip可以帮助企业/开发者实现什么：促进连接。只要把FinClipSDK嵌入到自己的App中，马上获得小程序运行能力。小程序已经在互联网上被充分证明是一个非常有效的促进连接的技术形态。动态更新。借助FinClip将应用中业务功能均以小程序形式替代，功能模块互相解耦，实现模块化开发，极大的提升开发效率，降低开发成本。多端支持。同一个业务场景，小程序化之后，可以展现在手机端、也可以运行在PC端、更可以出现在智能电视和车载大屏上，多端同步、转发分享、一致体验，甚至可以无缝对接至互联网公共平台，代码只写一次，多处运行。生态共建。让开发者、企业拥有自己的小程序应用商店，在这里可以实现与合作伙伴的资源整合-例如让合作伙伴把数字服务以小程序方式上架、投放到自己的App中。
FinClip的技术方案，目的就是要让任何行业的任何企业，均可以拥有自主打造小程序生态、发布管理小程序内容、在自己的各终端App中运行小程序的能力。
相信随着互联网浪潮的不断向前，会有越来越多的解决方案、框架会被提出，让我们拭目以待！
一个小程序的实施技术方案
微信小程序上线大半年，大部分技术原理也有文章介绍了，本文尝试从需求出发探讨微信小程序技术方案的来源，以及最近公测的支付宝小程序技术方案的考量。
微信小程序
微信小程序的需求是让第三方开发者可以接入，可以使用微信的提供的接口去开发应用嵌入在微信里。对于这个需求，最简单的实现方案是：让外部开发者开发纯H5应用，在微信的H5容器里打开，容器提供微信native接口，就行了。在有小程序之前，已经有很多这样的业务接入，像京东购物，钱包里的各种友商大众点评/滴滴出行等，都可以认为是一个“小程序”，内嵌在微信里，能调用微信native接口，是不是沿着这种模式下去，把相应的接口开放给第三方，再提供个入口就行了？
实际上这种简单的方案不能满足需求，在产品上微信小程序有另外两个很重要的需求：
管控。作为一个平台必须对接入的应用有管控能力，必须能尽量精确控制应用的内容和类型，毕竟若出现非法应用平台是要承担责任的，H5的方式太过自由，开发者可以随时改变整个应用的内容，平台难以检测到这些改变，无法管控。另外H5开发质量参差不齐，平台也无法管控，这对于一向有洁癖的微信来说无法接受。
体验。作为一个“小程序”需要让体验接近原生，而上述像京东购物这些普通H5页面的体验不太行，包括启动速度/页面切换流畅度都有问题，跟原生体验没法比。
所有小程序的技术方案都是为了这两个需求服务。
管控
为了满足管控的需求，技术上微信做了两个事情：小程序框架和分离JS运行环境。
框架/DSL
H5太自由，首先要做的就是限制它的自由，怎样限制？自然是做个框架套住，让开发者只能按框架的规则去开发。那应该使用怎样的框架？
在PCSNS时代，Facebook做开放平台时有类似的场景，为了第三方开发者能在Facebook平台上开发，同时又能限制住开发者的权限，Facebook要求开发者使用自定义的一套DSL(FBML)去开发，而这个DSL能怎么写，最终能转成什么，如何执行，都是平台说了算，同时也可以很方便做代码扫描和审查。
小程序正好能借鉴这样的设计思路，界面不使用HTML开发，而是自定义一套DSL，这样就可以很容易配合审核/代码扫描/域名限制等系列措施去做管控，这就是小程序这一套框架的来源。这套框架通过wxml去描述界面，wxss描述样式，js去处理逻辑和数据，再通过工具一系列处理把这些转为HTML/CSS/JS显示在webview上，并处理界面交互和数据更新。
这样用一套框架去限制开发方式，再造一层DSL，除了管控外还有一个好处，就是容易进行针对性优化，DSL最终转成什么，最终如何执行渲染都由框架决定，上层不感知，可以做成由webview渲染，有条件也可以用类似RN的方案自己实现渲染层。
JS环境
通过框架限定开发方式后，管控上还有个问题，就是如何限制应用端类JS语言调用domAPI？小程序跑在webview上，渲染时必然要通过JS操作dom，如果小程序框架和应用JS代码都有权限操作dom，应用可能会通过各种方式在上线后绕过检查，注入JS调用dom接口去修改页面结构和内容，变成跟审核时不一样的应用。怎样能限制应用的JS调用dom的权限？微信想了个比较创新的解决方案，就是：JS运行环境与浏览器分离，运行在单独的JS引擎上。
脱离了浏览器，JS自然没有dom的调用权限，任何跟webview界面相关的API都无法拿到。而小程序框架核心JS运行在webview上，可以自由操作dom，通过小程序框架定义的机制，应用端通过wxml/wxss定义固定的渲染样式，JS端只管数据绑定，数据可以通过native桥梁从JS引擎传递到webview，JS端无法做任何渲染相关的操作，可以对渲染的内容有完整的管控权。
独立的JS运行环境除了满足管控需求外，也额外带来一些好处和一些坏处，好处在于：
多个页面可以共享一个JS运行环境，数据可以很方便地共享，整个小程序生命周期里共享同一个上下文，更接近APP的开发体验。
JS与页面渲染分离并行执行，不会出现JS执行时卡住页面渲染的情况，提升渲染性能。
坏处在于：
多了数据序列化传输的开销，数据需要从JS传到webview给视图层渲染，需要序列化为字符串格式再进行传输。
iOS上WKWebview的JS引擎比JavaScriptCore多了JIT优化，执行速度快很多倍，小程序的JS运行在JavaScriptCore上无法享受到这个优化。
由于管控需求过于刚需，这个方案带来坏处可以接受。
体验
小程序最主要的两个技术点—框架和JS运行分离都是源自管控需求，而体验上的需求就是由各种细致的性能优化组成了，很多文章也分析过，这里简单说下，包括：
离线包：整个小程序打包下发，不需要打开每个页面都去请求，减少第二次打开时间以及页面切换时间。
预加载：预加载多一个wkwebview放后台，用户打开小程序时省去初始化wkwebview时间。另外对于一个小程序内的页面切换，得益于框架的设计，可以做到预渲染模板，切换时再填充数据，加快渲染速度。
缓存：退出小程序后不会立即销毁，会在后台继续跑5分钟，在这期间用户切回小程序时速度快。
视觉：小程序首次加载通过loading和动画的方式过渡，拒绝白屏，给人一种快的感觉，同时提升了小程序的标识度。
剩下的就是围绕小程序这个平台的周边建设了，像组件，native接口，IDE，后台管理，版本管理，权限控制等基础支持。
支付宝小程序
策略
微信小程序推出时主要面向的场景是线下，希望商家能开发小程序，做像点菜买票这样的即时性应用，提升线下商户体验，支付宝作为线下战场的主要竞争对手自然要跟进。
支付宝要做小程序应该怎么做？可以根据自身的情况，定义另一套技术体系，让第三方接入。但这样的话第三方如果要同时接入微信和支付宝，需要开发两套程序，成本很高，而微信有先发和平台优势，很可能变成只开发微信小程序而放弃接入支付宝小程序，所以最好的做法是降低这里的接入成本，让微信小程序的代码可以复用在支付宝小程序上。所以支付宝小程序对外的框架/API/组件必须是跟微信小程序接近或力求一致，技术上没得选择，所以可以看到支付宝小程序公测版的文档很多跟微信一致。
实现
支付宝小程序框架对外接口是跟微信一样，又因为同样有管控/安全和体验的需求，有些策略是类似的，像独立JS环境，离线包，缓存策略等，但在小程序框架的实现上就跟微信完全不一样。小程序框架作为一层屏蔽了实现细节的DSL层，最终通过什么技术手段实现都可以是由框架底层自由定制的，这边底层架构基于蚂蚁前端团队多年的积累，最终web版小程序是以react为基础实现。
ReactNative
除了对外的跟微信一致的web版小程序，内部一直在尝试ReactNative版小程序，渲染层不适用webview，而是用RN去渲染，提升性能和体验，这也是小程序DSL层带来的好处，底层渲染引擎可以很方便地替换实现方案，甚至同时存在多套方案。
很多人问为什么不用weex，按我理解首先是蚂蚁的前端技术栈基于react，切换成本高，另一个RN相对weex成熟度高，社区支持度高，并保持着不间断的更新，相对友好。
RN本身不跨平台，iOS/Android有各自的写法，在RN的使用上，业界很多人各自实现了基于RN的跨三端或两端的开发方式（例如JDReact），也就是一次开发，能同时支持RN在iOS/Android两端做原生渲染，也支持fallback到webview渲染。这里小程序也算是这样一套方案，上层通过自定义DSL开发业务，部署时通过工具分别转换成三个平台不同的代码，在三个平台运行。
内部应用
小程序是一套对外的方案，主要用于第三方应用接入，因为上文也说了，框架上很多技术方案都是为了满足对第三方管控和安全方面的需求，而小程序相关的很多体验优化其实用纯H5也可以做到，内部业务用web版小程序开发并没有带来什么好处，反而增加学习成本。但RN版小程序不一样，它有一些优势，包括：
RN相对webview性能优势明显，秒开率高，交互也更流畅。
相对于单纯使用RN开发，使用小程序可以屏蔽平台差异，实现跨平台一次开发。
小程序有配套的开发环境/IDE/包管理等基础设施支持，无需再重复建设。
对于业务开发者，小程序不是全新的一套开发方式，在业界可复用，对于框架实现者，RN也是业界流行开源方案，有强大的社区支持。对内对外都避免了另外创建一套只能在内部使用的技术体系，极大降低技术成本。
基于这些原因，在蚂蚁财富这边一些内部原本应该使用H5实现的业务，也正尝试更多地使用小程序实现，以提升用户体验，目前部分基于小程序RN版开发的业务已在线上稳定运行，后续也会继续尝试把小程序RN版持续打造成高性能稳定的三端统一动态化方案。
使用alita 将React Native项目转化为小程序
1.通过npm全局安装alita 2.官方文档说明可以直接通过react native init一份项目直接转化，不过试了试，有问题，小程序一直报未找到入口文件 app.js，所以尽量使用alita官方提供的examples文件，所以可以clone一份HelloWorldRN，将文件名改为你的项目名就可以了：比如Demo 3.使用命令转化为小程序 4.安装相关依赖 5.将Demowp导入到微信开发者工具运行即可！Alita生成的小程序使用了小程序的npm功能， 所以需要在微信开发者工具下构建npm， 工具 --》 构建npm 6.运行效果 ***隐藏网址***
小程序开发用什么框架
小程序开发可以使用以下框架： 1. 微信官方框架：使用微信官方提供的框架进行开发，可以快速上手，但功能相对较少。 2. uni-app框架：uni-app是一个基于Vue.js的开发框架，可以同时开发多个平台的小程序，如微信、支付宝、百度等。 3. Taro框架：Taro是一个多端开发框架，支持小程序、H5、React Native等多个平台，可以实现一次编写，多端运行。 4. mpvue框架：mpvue是一个基于Vue.js的小程序开发框架，可以使用Vue.js的语法进行开发，同时支持小程序原生API。如果没有编程代码经验，可以寻求第三方小程序平台进行鼠标拖拽式搭建小程序。
