Crosswalk Android运行环境踩坑报告

2018-08-04 本文已影响236人雪松87

按官网配置方法遇到的坑

官方的说明文档还是在Crosswalk-17版本（最新23）的基础上给出的，大概时间是在2015年到2016年的文档，使用的IDE还是eclipse，在集成过程中还是遇到了不少的坑的

坑1 studio 依赖环境

project下的build.gradle需要添加Crosswalk的maven地址

allprojects {
    repositories {
        google()
        jcenter()
        maven { url "https://download.01.org/crosswalk/releases/crosswalk/android/maven2"}
    }
}

module下的build.gradle需要添加依赖库

    compile ('org.xwalk:xwalk_core_library:23.53.589.4')

坑2 xwalk_core_library 与工程的support冲突

以工程依赖的support为主

    compile ('org.xwalk:xwalk_core_library:23.53.589.4'){
        exclude group: 'com.android.support', module: 'appcompat-v7'}

坑3 API版本说明

Minimum Required SDK: ~~API 14~~ --> API 16 (Crosswalk-20)
Target SDK: ~~API 19~~ --> API 21 (2014.12.22)

what? 最低只支持API16？不然都编译不过？那些android 4.0.0 的机器咋办，就连APK都没法安装了？别慌，稳住，我们能赢。

兼容 API 14

从Crosswalk的github上能看出Crosswalk是在20版本的时候弃用的API14 API15版本，估计是版本太老太难维护了吧

Since we've dropped Android 4.0 support from Crosswalk-20, change the
minSdkVersion from 14 to 16.

如果我们工程里面选择的android:minSdkVersion="14"，编译的时候会有报错，提示Manifest合并冲突

Manifest merger failed with multiple errors

原因是因为 org.xwalk.core SDK 的 Manifest 中已经写死了

<uses-sdk android:minSdkVersion="16" android:targetSdkVersion="21" />

为了解决该冲突，我们可以在我们module下的Manifest添加

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="com.xxx.xxx">
    <uses-sdk tools:overrideLibrary="org.xwalk.core"/>

然后，我们再在代码逻辑中增加API14 API15版本的特殊处理

if (Build.VERSION.SDK_INT > Build.VERSION_CODES.ICE_CREAM_SANDWICH_MR1) {
    createXWalkView();
} else {
    createWebView();
}

APK瘦身分案

不出意外的话，我们应该能够编译出APK了，但是APK大小却有27M，比原来APK的大小增加了 20+M！我们来试试官方给出瘦身的方案

方案1 共享模式

“共享模式”允许多个Crosswalk应用共享一个运行时环境。如果设备还没有安装运行时环境，它将会从Google Play Store或者一个由开发者规定的具体地址处下载。因为Crosswalk二进制文件不包含在应用的APK包中，所以它会明显小很多（~20MB）。

需要修改module下的build.gradle依赖库

compile ('org.xwalk:xwalk_shared_library:23.53.589.4')

也就是说专门有个APK来提供库的运行环境，其他的APK来引用这个库APK中的库。
这个方案基本上也没有节省内存，反而增加多个应用间的关联性，使我们1个混合APK变成了1个库APK+1个混合应用展示，维护难度增加
第一次运行时，有一个下载安装的过程，这个交互体验上也存在一些弊端

方案2 下载模式

下载模式为缩小APK的大小提供了另一种与共享模式相似的解决方案。你的应用仍然绑定仅包含Crosswalk API层的xwalk_shared_library。当应用第一次在客户端设备上运行时，后台将会从你规定好的服务器上下载Crosswalk核心库和资源。与共享模式相比，你的应用可以独享Crosswalk运行时，因此你便可以控制运行时的生命周期。Crosswalk运行时可以不需要用户交互，在后台完成下载。

这个方案和共享模式方案类似，可以理解为将库APK内置到小程序展示APK内部了
同样第一次运行时，有一个下载（20s）安装（25s）的过程，这个交互体验上也存在一些弊端
安装成以后会占用额外的data空间大小，下载的APK（27M）、解压的大小（47M）
优势是后续升级壳子不需要再次对运行库进行升级，只需要升级体积较小的壳子

方案3 Lite版库

Crosswalk Lite，或者称为"Lite", 均表示精简版的Crosswalk运行时，通过移除较不常见的库和特性，压缩APK实现将Crosswalk运行时的容量尽量减少。

status	Crosswalk	Crosswalk Lite
APK	20MB	10-15MB
Installed	55MB	40MB

需要修改project下的build.gradle maven 配置

maven { url "https://download.01.org/crosswalk/releases/crosswalk-lite/android/maven2/"}

需要修改module下的build.gradle依赖库

compile ('org.xwalk:xwalk_core_library_canary:17.46.460.1')

这个方案删除了共享模式的功能，不支持64位系统，也删除了部分不常用的特性。
更新频率很低，目前只存在Crosswalk-lite-17版本（最新23），最后更新时间为2016.08.15，可能存在更多意外的bug。
第一次运行时，会对so库进行解压，运行环境准备大概需要30s左右

结论

目前几种瘦身的方案交互体验上都存在比较严重的问题，难怪官方后期都没有继续维护lite版本了

安利工具 Depencencies Version Checker

在这次踩坑的过程中，我陆陆续续使用了Crosswalk和Crosswalk-lite的进十来个版本，进行功能差异性验证，找到这些sdk的历史版本，Depencencies Version Checker 工具的作用功不可没。他可以很方便的查看我们工程所依赖的第三方库的最新版本和所有历史版本。

使用方案 https://www.jianshu.com/p/bf45663433b4