6.3.4 容器化框架的弊端
容器化技术可以实现动态加载、热更新，那么是不是所有 App 都应该接入这种技术呢？其实不然，要知道 Google 是禁止 App 使用这种动态加载框架技术的。国内之所以容器化框架盛行，是因为 Google 退出中国市场，所以当下流行的容器化框架，大多是由国内开发者开发的。
那 Google 为什么要禁用这种技术呢？
容器化技术看起来很高端，但其实也存在很多弊端。其中，可能对用户造成影响的就是安全性。
应用程序想要上架 Google Play 商店，让用户能够使用，都必须经过 Google 严格的审核。Google 绝不允许其商店存在某些未经审核的 App 上线。为了对用户负责， Google 不允许任何具备动态更新、热更新、热修复及自更新能力的 App 上架。
想象一下，某些黑灰产 App，在某一次你没注意的运行过程中，运用动态加载技术偷偷加载了某些功能，比如，上传了你手机上 SD 卡的所有内容，然而你却无法查证，这将是多么可怕的事情啊。
因此，安全性才是容器化框架不被 Google 接受的最重要的原因，而非该技术没有价值或不可取。其实在有监管的情况下，容器化技术是非常不错的解决方案。
6.3.5 Android P 下的容器化技术前进方向
众所周知， Android 系统是朝着保护用户隐私以及抑制 App 权限的方向发展的。 Android P被拎出来，并不是因为它是比较新的系统，而是因为 Google 在 Android P 上推出了 Hidden API机制。这个机制一出来，基本宣告了容器化框架的末路，让黑灰产 App 开发者汗颜。
所谓的 Hidden API，其实就是系统没有开放出来的，只给系统自己使用的 API。禁止反射调用 Hidden API，就是在系统层进行限制，不让应用程序通过反射调用 Hidden API，以保证调用的接口都是 Google 开放的安全接口。我们知道， Android 系统运行的是 Java 程序代码，除使用开放接口，只要了解源码，就可以反射调用系统方法，为相应的业务服务，甚至可以通过反射调用， Hook 系统方法或者成员变量，更改系统的行为特性。因此，这可能导致不安全的行为出现。
Android P 版本最大、最严格的特性变更应该非 SDK 接口限制莫属了。非 SDK API 名单总共分为 3 类：浅灰名单（ Light Grey List）、深灰名单（ Dark Grey List）、黑名单（ Dark List），详情如下。
浅灰名单： 可以访问的非 SDK 函数/字段。
深灰名单： 对于目标 SDK 低于 API 级别 28 的 App，允许使用深灰名单接口。对于目标 SDK 为 API 28 或更高级别的 App，行为与黑名单相同。
黑名单： 所有第三方应用不允许调用的灰名单（浅灰+深灰）之外的其他所有非 SDK都将添加到黑名单中，如果 App 使用到黑名单接口，须马上整改或反馈给 Google 申请能否将此黑名单接口加入灰名单。
那么为什么禁止调用的 Hidden API 会对容器化造成影响呢？
这是因为容器化框架为了实现动态加载、热插拔、温插拔等，都必须通过反射 Hook 系统的 API，将系统的 ClassLoader、 ServiceManager、 ActivityThread 等关键组件给替换掉，换成自己的组件，从而绕过系统限制，实现相应的功能。但是，这些系统关键组件的方法或类都是Hidden API，而且大部分都在深灰名单中，一旦 Hidden API 被拒绝调用，那么容器化框架就不能正常运行。因此，禁止调用 Hidden API 会对容器化框架的前进方向造成重大影响。虽然2018 年是第一年禁止调用 Hidden API，但是影响已经非常大，很多应用程序都无法正常运行了，以至于 Google 在发布 DP3 和正式版的时候，放宽了禁止调用 Hidden API 的限制条件。但可以预见，在 Android 系统接下来的版本中，对 Hidden API 的限制将越来越严格，容器化之路也会越来越难走。
综上所述，在 Android P 禁止调用 Hidden API 的这一大前提下，容器化的发展出现了分歧，各个解决方案如下。
与 Google 沟通协商，看能否将部分黑名单或深灰名单移除，这里需要因业务、市场等情况与 Google 反复沟通，沟通成本相对来说比较高。
移除容器化方案。这个方案对现有的超级 App 会有很大的影响。
6.3.6 App Bundle 解析
App Bundle 并不是容器化方案，之所以放在这里介绍，是因为它解决了容器化方案想解决的主要问题之一——包体过大问题。
App Bundle 采用新的服务模型（被称为 Google Play 的动态交付机制）来编译和交付已针对每项设备配置进行过优化的 APK。这样你可以从下载内容中移除其他设备所需而本设备不使用的代码和资源，使用户能安装更小的应用。
与 APK 相比，如图 6-16 所示， App Bundle 具有以下优点。
缩小了应用的大小。
向用户提供所需的功能和配置。
不需要编译和发布多个 APK，降低了开发的复杂性。
在你将 App Bundle 上传到 Google Play 管理中心后， Google Play 会为设备发送一个经
过优化的二进制文件。
针对 Android 5.0 及以上版本： Google Play 将生成基本 APK、配置 APK 和动态功能APK（如果适用）。
针对 Android 5.0 以下版本： Google Play 将在服务端生成多个 APK。
综合来看， App Bundle 解决方案是一整套包括 App 客户端、 Play Store 服务器、平台识别匹配的综合平台，目的是尽可能地缩减包体，让用户以更低的成本完成下载任务。
第 7 章 移动混合前端技术
移动互联网发展至今一直不断在效率和产品体验创新的方向发展。 Android 系统很好地解决了用户体验（尤其是手机上的用户体验）的问题，但也面临着效率问题，开发者面临着不同的终端设备，可能需要编写针对不同平台的多套代码。 H5 虽天生具备跨平台特性，但其在移动终端设备上的体验不佳，这也同时困扰着开发者，因此一种介于 H5 和 Android（或 iOS 及其他系统）的开发模式应运而生，这就是移动混合前端技术。
7.1 H5 方案
天生具备跨平台特性的 H5 方案在努力地提升自己的用户体验，而且随着将来 5G 的普及，相信 H5 方案会得到越来越广泛的应用。
7.1.1 轻量化方案—— H5 应用
自从 HTML5 诞生那一刻起， Web 方案就大有要一统江湖的意思。的确，在移动互联网时代， HTML5 以其强跨平台能力，受到了各方的追捧。这里所说的 H5 并不是传统意义上的HTML5 标签，而是由 JavaScript、 CSS 以及 DOM 标签组合形成的 In App 或者 Web App 的形式。 H5 最显著的优势在于跨平台特性，用 H5 搭建的站点与应用可以兼容 PC 端与移动端、Windows 与 Linux、 Android 与 iOS。它可以被轻易地移植到各种不同的开放平台、应用平台上，打破了各平台各自为政的局面。这种强大的兼容性可以显著地降低开发与运营成本，可以让企业（特别是创业者）获得更多的发展机遇。
在移动端，我们讨论的移动混合开发技术更多的是指 Hybird App，即原生界面嵌套 Web页面。在原生 App 中运行 Web 程序（对应图 7-1 中的 WebView），并给 Web 程序开放接口，让 Web 程序能够获取原生 App 的一些 API，以此增加原生 App 的灵活性，如图 7-1 所示。
7.1.2 H5 交互与接口实现
H5 Hybrid 方案最重要的部分就是实现 H5 跟 Native 的交互，通过 JavaScript 调用 Native 方法实现部分 Native API 接口调用。因此在 H5 Hybrid 解决方案中，必然需要维护一个庞大的接口列表。
首先，看看移动 App 中内嵌的小型浏览器的代码实现：
1. private void initWebView() {
2. webView = new WebView(this);
3. WebSettings webSettings = webView.getSettings();
4. //设置支持 JavaScript 脚本语言
5. webSettings.setJavaScriptEnabled(true);
6. //支持缩放按钮——页面支持才显示
7. webSettings.setBuiltInZoomControls(true);
8. //设置客户端——不跳转到默认浏览器中
9. webView.setWebViewClient(new WebViewClient());
10. //设置支持可以通过 JavaScript 脚本调用客户端 Java 程序
11. webView.addJavascriptInterface(new AndroidAndJSInterface(),
"Android");
12. //加载本地资源
13. webView.loadUrl("file:///android_asset/JavaAndJavaScriptCall.html");
14. //显示页面
15. //setContentView(webView);
16. }可以看到，我们在设置 WebView 的时候，设置了 setJavaScriptEnabled = true，即允许JavaScript 调用。接着通过 webView.addJavascriptInterface(new AndroidAndJSInterface(), “Android”)设置 JavaScript 的响应接口类为 AndroidAndJSInterface，这样 H5 通过调用 JavaScript 代码便可以在 AndroidAndJSInterface 中做出响应，实现了初步的交互通信。
接下来简单实现 Native 接口，让我们的 H5 可以调用 Native 接口：
1. /**
2. * JavaScript 接口类，调用该类的方法
3. */
4. class AndroidAndJSInterface{
5. @JavascriptInterface
6. public void showToast(String str){
7. Toast.makeText(getContext(), str Toast.LENGTH_SHORT).show();
8. }
9. }如上所示，通过实现 showToast 接口， H5 便可以通过 JavaScript 接口实现对 Android 原生Toast 的调用。 H5 所需的 Native 接口，都必须在这个接口页面实现后，才可以被 H5 调用。
7.1.3 H5 的缺点
当然， H5 并不是无所不能的， H5 有其高灵活性，但相应地也有很多缺点，分别如下。
（ 1）每次打开页面，都需要重新加载和获取数据。
（ 2）过于依赖网络，速度无法保证。特别在弱网环境下，不仅耗费流量而且加载缓慢，就算在 Wi-Fi 环境下情况也不容乐观。
（ 3）只能使用有限的设备底层功能（无法使用摄像头、方向传感器、重力传感器、拨号、GPS、语音、短信、蓝牙等功能）。
（ 4）仍处于发展阶段，部分功能无法在基于现有技术的浏览器上实现，而且无法全面地提供最完美的用户体验，只能用现有技术弥补和寻找最佳解决方案。
（ 5）性能比原生 App 差， WebView 相当于运行在原生 App 上的虚拟机，而 H5 则是运行在 WebView 这个虚拟机上的，需要经过多层转换，效率较低，体验也较差。在对用户体验要求非常高的本地 App 中， H5 的缺点比较明显。
综上所述，因 H5 存在诸多不完善，以致很多应用开发者放弃 H5 而转向 Weex 和 React Native。其中， Facebook 早在 2016 年就宣布， H5 性能体验问题严重，公司将全面转向Native，并推出了替代性方案——React Native。
7.2 Weex 和 React Native
跨平台一直是老生常谈的话题， Cordova、 Ionic、 React Native、 Weex、 Kotlin Native、Flutter 等跨平台框架百花齐放，颇有一股推倒原生开发者的势头。 React Native、 Weex 均使用JavaScript 语言作为编程语言，目前 JavaScript 在跨平台开发中可谓占据半壁江山，大有“一统天下”的趋势，接下来就重点进行介绍。
7.2.1 Weex 和 React Native 简介
Weex， Alibaba 出品，使用 JavaScript 语言、 JavaScript 的 V8 引擎、 Vue 设计模式，原生渲染。 React Native， Facebook 出品，利用 JavaScript 调用 Native 端的组件，从而实现相应的功能。
1． Weex
Weex 是 Alibaba 于 2016 年推出的大前端框架，是一个使用 Web 开发技术来开发高性能原生应用的框架。 Weex 致力于使开发者能基于现在先进的 Web 开发技术，使用同一套代码来构建 Android、 iOS 和 Web 应用。
Weex 的设计理念是一处开发，多处运行（ Write once, run anywhere）。
2． React Native
React Native（简称 RN）是 Facebook 于 2015 年 4 月开源的跨平台移动应用开发框架，是Facebook 早先开源的 JavaScript 框架 React 在原生移动应用平台上的衍生产物，目前支持 iOS和 Android 两大平台。 React Native 使用 JavaScript 语言（类似于 HTML 的 JSX）和 CSS 来开发移动应用，因此熟悉 Web 前端开发的技术人员只需少量学习就可以进入移动应用开发领域。 React Native 使你能够在 JavaScript 和 React 的基础上获得完全一致的开发体验，构建世界一流的原生 App。 React Native 着力于提高多平台开发的开发效率——仅需要学习一次，即可在任何平台上编写代码（ Learn once, write anywhere）。
暂无评论内容