关于移动互联网的跨平台技术演进，安卓面试题10道

最新推荐文章于 2024-06-13 14:21:23 发布

饱和面试题

最新推荐文章于 2024-06-13 14:21:23 发布

阅读量612

点赞数 21

分类专栏：程序员学习文章标签： android

本文链接：https://blog.csdn.net/m0_60635035/article/details/136886508

版权

程序员学习专栏收录该内容

8 篇文章 0 订阅

订阅专栏

缺点

性能问题：在反应速度、流畅度、动画方面远不及原生
功能问题：对摄像头、陀螺仪、麦克风等硬件支持较差

虽然H5目前还存在不足，但随着PWA、WebAssembly等技术的进步，相信H5在未来能够得到越来也好的发展。

小程序

2018年是微信小程序飞速发展的一年，19年，各大厂商快速跟进，已经有了很大的影响力。下面，我们以微信小程序为例，分析小程序的技术架构。

小程序跟H5一样，也是基于Webview实现。但它包含View视图层、App Service逻辑层两部分，分别独立运行在各自的WebView线程中。

View

可以理解为h5的页面，提供UI渲染。由WAWebview.js来提供底层的功能,具体如下：

消息通信封装为WeixinJSBridge
日志组件Reporter封装
wx api（UI相关）
小程序组件实现和注册
VirtualDOM，Diff和Render UI实现
页面事件触发

每个窗口都有一个独立的WebView进程，因此微信限制不能打开超过5个层级的页面来保障用户体验。

App Service

提供逻辑处理、数据请求、接口调用。由WAService.js来提供底层的功能,具体如下：

日志组件Reporter封装
wx api
App,Page,getApp,getCurrentPages等全局方法
AMD模块规范的实现

运行环境：

iOS：JavaScriptCore
Andriod：X5内核，基于Mobile Chrome 53/57
DevTool：nwjs Chrome 内核

仅有一个WebView进程

View & App Service通信

视图层和逻辑层通过系统层的JSBridage进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层将触发的事件通知到逻辑层进行业务处理。

优缺点分析

优点

预加载WebView，准备新页面渲染
View层和逻辑层分离，通过数据驱动，不直接操作DOM
使用Virtual DOM，进行局部更新
组件化开发

缺点

仍使用WebView渲染，并非原生渲染，体验不佳
不能运行在非微信环境内
没有window、document对象，不能使用基于浏览器的JS库
不能灵活操作 DOM，无法实现较为复杂的效果
页面大小、打开页面数量都受到限制

既然WebView性能不佳，那有没有更好的方案呢？下面我们看看React Native。

React Native

RN的理念是在不同平台上编写基于React的代码，实现Learn once, write anywhere。

Virtual DOM在内存中，可以通过不同的渲染引擎生成不同平台下的UI，JS和Native之间通过Bridge通信

React Native 工作原理

在 React 框架中，JSX 源码通过 React 框架最终渲染到了浏览器的真实 DOM 中，而在 React Native 框架中，JSX 源码通过 React Native 框架编译后，与Native原生的UI组件进行映射，用原生代替DOM元素来渲染，在UI渲染上非常接近Native App。

React Native 与Native平台通信

React Native用JavaScriptCore作为JS的解析引擎，在Android上，需要应用自己附带JavaScriptCore，iOS上JavaScriptCore属于系统的一部分，不需要应用附带。
用Bridge将JS和原生Native Code连接起来。Native和 JavaScript 两端都保存了一份配置表，里面标记了所有Native暴露给 JavaScript 的模块和方法。交互通过传递 ModuleId、MethodId 和 Arguments 进行。

优缺点分析

优点

垮平台开发：相比原生的ios 和 android app各自维护一套业务逻辑大同小异的代码，React Native 只需要同一套javascript 代码就可以运行于ios 和 android 两个平台，在开发、测试和维护的成本上要低很多。
快速编译：相比Xcode中原生代码需要较长时间的编译，React Native 采用热加载的即时编译方式，使得App UI的开发体验得到改善，几乎做到了和网页开发一样随时更改，随时可见的效果。
快速发布：React Native 可以通过 JSBundle 即时更新 App。相比原来冗长的审核和上传过程，发布和测试新功能的效率大幅提高。
渲染和布局更高效：React Native摆脱了WebView的交互和性能问题，同时可以直接套用网页开发中的css布局机制。脱了 autolayout 和 frame 布局中繁琐的数学计算，更加直接简便。

缺点

动画性能差：React Native 在动画效率和性能的支持还存在一些问题，性能上不如原生Api。
不能完全屏蔽原生平台：就目前的React Native 官方文档中可以发现仍有部分组件和API都区分了Android 和 IOS 版本,即便是共享组件,也会有平台独享的函数。也就是说仍不能真正实现严格意义上的“一套代码，多平台使用”。另外，因为仍对ios 和android的原生细节有所依赖，所以需要开发者若不了解原生平台，可能会遇到一些坑。
生态不完善：缺乏很多基本控件，第三方开源质量良莠不齐

展望未来

虽然RN还存在不足，但RN新版本已经做了如下改进，并且RN团队也在积极准备大版本重构，能否成为开发者们所信赖的跨平台方案，让我们拭目以待。

改变线程模式。UI 更新不再同时需要在三个不同的线程上触发执行，而是可以在任意线程上同步调用 JavaScript 进行优先更新，同时将低优先级工作推出主线程，以便保持对 UI 的响应。
引入异步渲染能力。允许多个渲染并简化异步数据处理。
简化 JSBridge，让它更快、更轻量。

既然React Native在渲染方面还摆脱不了原生，那有没有一种方案是直接操控GPU，自制引擎渲染呢，我们终于迎来了Flutter！

Flutter

Flutter是Google开发的一套全新的跨平台、开源UI框架，支持iOS、Android系统开发，并且是未来新操作系统Fuchsia的默认开发套件。渲染引擎依靠跨平台的Skia图形库来实现，依赖系统的只有图形绘制相关的接口，可以在最大程度上保证不同平台、不同设备的体验一致性，逻辑处理使用支持AOT的Dart语言，执行效率也比JavaScript高得多。

Flutter架构原理

Framework：由Dart实现，包括Material Design风格的Widget,Cupertino(针对iOS)风格的Widgets，文本/图片/按钮等基础Widgets，渲染，动画，手势等。此部分的核心代码是:flutter仓库下的flutter package，以及sky_engine仓库下的io,async,ui(dart:ui库提供了Flutter框架和引擎之间的接口)等package。
Engine：由C++实现，主要包括:Skia,Dart和Text。
Skia是开源的二维图形库，提供了适用于多种软硬件平台的通用API。其已作为Google Chrome，Chrome OS，Android, Mozilla Firefox, Firefox OS等其他众多产品的图形引擎，支持平台还包括Windows7+,macOS 10.10.5+,iOS8+,Android4.1+,Ubuntu14.04+等。Skia作为渲染/GPU后端，在Android和Fuchsia上使用FreeType渲染，在iOS上使用CoreGraphics来渲染字体。
Dart部分主要包括:Dart Runtime，Garbage Collection(GC)，如果是Debug模式的话，还包括JIT(Just In Time)支持。Release和Profile模式下，是AOT(Ahead Of Time)编译成了原生的arm代码，并不存在JIT部分。
Text即文本渲染，其渲染层次如下:衍生自minikin的libtxt库(用于字体选择，分隔行)。HartBuzz用于字形选择和成型。
Embedder：是一个嵌入层，即把Flutter嵌入到各个平台上去，这里做的主要工作包括渲染Surface设置,线程设置，以及插件等。从这里可以看出，Flutter的平台相关层很低，平台(如iOS)只是提供一个画布，剩余的所有渲染相关的逻辑都在Flutter内部，这就使得它具有了很好的跨端一致性。