2移动端跨平台开发方案的演进.pdfVIP

移动端跨平台开发⽅案的演进 我们先来了解⼀下移动端跨平台开发⽅案的演进历史。 从 Android、iOS 推出⾄今， 有⼗⼏年，移动端的开发技术也在 不断发展，最开始的时候，都是使⽤原⽣开发，但却有⼀个明显的痛 点，就是相同的功能需要在不同的平台上都实现⼀遍，所以就有了⼀ 个很迫切的需求，能否只需要写⼀次代码，就可以在各个端都运⾏？ 本节就回顾⼀下跨平台开发⽅案的演进历史，我们根据跨平台⽅案所 ⽤的技术分为以下⼏种： WebView 流 第⼀种⽅案，我们称之为 WebView 流。因为 WebView 作为⼀个显 示 web ⻚⾯的容器，它本身是跨平台的，所以利⽤ WebView 跨平 台属性的技术⽅案就称之为 WebView 流。WebView 流的发展也经 历了如下的过程： 1. 纯 H5 最开始的时候，是在 APP ⾥嵌⼊⼀个 WebView ，负责显示 H5，可能是独⽴的⼀个⻚⾯，也有可能是 Native ⻚⾯的⼀部 分。 但在这个阶段，⼀⽅⾯，WebView 的性能没有 Native 的好， 另⼀⽅⾯，H5 ⻚⾯和 Native 的⻚⾯⼏乎是没有交互的，使得 Native 的开发和 H5 的开发是彼此独⽴的，Native ⽆法使⽤ H5 的特性，H5 也⽆法使⽤ Native 的特性，这些都限制了 WebView 的使⽤场景。 2. Hybrid 为了打破 Native 和 H5 割裂的情况，就出现了 J SBridge ， J SBridge 是 Native 代码与 J avaScript 代码的通信桥梁。 J SBridge 的出现，使得 H5 可以使⽤ Native 的能⼒，Native 也能 使⽤ H5 的能⼒，使 Native 和 H5 能完美融合在⼀起，出现了⼀系 列的 Hybrid 开发框架，⽐如 Phone ap 等，这些架构具有开发成 本低、简单、跨平台的优点。但是这些 Hybrid 框架都是基于 WebView 实现的，所以⽆法避免 WebView 本身的劣势：内存占⽤ 多、⽹⻚加载速度慢、渲染慢、J avaScript 执⾏慢等，因为这些性能 问题，所以⼤多数⼈在开发过程中，主要⻚⾯都是使⽤ Native 开 发，只有少数⻚⾯才采⽤ Hybrid 的框架。 3. 基于 Hybrid 的优化改进⽅案 针对具体的性能问题，开始有了不同的优化⽅案，⽐如：⽹⻚ 加载速度慢，则采⽤离线包的⽅案；⽹⻚渲染效率低，则优化 dom 树等。虽然性能上有很⼤提升，但是始终绕不过两⼤问 题，第⼀个是，WebView 的渲染性能⽐ Native 差，第⼆个就 是，J avaScript 是解释执⾏语⾔，运⾏效率也⽐ Native 差。 所以⽆论怎么优化，使⽤ Hybrid 开发的⻚⾯的性能肯定不会 ⽐ Native 的好。所以，如果是你，你会在⾃⼰的 APP 中全部 采⽤ Hybrid 吗？答案是肯定不会。 ReactNative 流 第⼆种是 ReactNative 流，ReactNative 流是从 WebView 流发展 ⽽来，典型的⽅案是 ReactNative 和 Weex，这两种⽅案，都抛弃 了 WebView 这个累赘，但仍然使⽤ H5 的技术栈开发，使⽤ J avaScript 开发，那是如何做到跨平台的呢： 跨平台的布局引擎 ReactNative 内置了跨平台的布局引擎，可以将 H5 的布局转化为 Native 的布局。 使⽤ Native 原⽣组件渲染 将 ReactView 组件使⽤ Native 原⽣组件渲染。 JavaScript 引擎 ReactNative 内置 J avaScript 的引擎，从⽽可以在不同平台上运⾏ J avaScript 代码。 ReactNative 流采⽤ J avaScript + J avaScript 引擎+ Native 的技术 ⽅案，利⽤了 J avaScript 的跨平台特性实现了移动端的跨平台⽅ 案。 编译流/虚拟机流 第三种是编译流/虚拟机流，这种的⽅案是 Xamarin (/item/Xamarin)。这种⽅案⼤家可能不 熟悉，因为 Xamarin 在国内⽤的很少，但在国外⽤的⽐较多。 Xamari