Hybrid就不多说了.除非是到后期各种拼用户体验拼特效拼交互,否则各个公司都要用上一用.

产品经理:这个可以随便改需求,动态发布,我喜欢.

android/ios:终于不用做需求了,我们安心研究技术好了.我喜欢

UI/UX:可以只出一套图了,交互也统一了.我喜欢

测试:不用两台手机对比着测试了.我喜欢

前端开发:我屮艸芔茻!

然而实际使用中,android总是遇到各种问题,兼容性,响应速度等等.

于是CrossWalk出现了…简单粗暴.直接打包浏览器内核.喜不喜欢?

So,尝(zuo)鲜(si)开始

其实官网上面的使用说明大可不看,各种搭环境,下载依赖的太烦人.直接下载so和jar包吧.

把这两个文件放到对应位置,直接使用XwalkView替代WebView就可以了.

看起来似乎很简单?下面是遇到的最大问题:

包太大了!!!

一个so文件居然有32M!!!

32M是什么概念…我一个完整的native应用才5M而已…

于是使用所谓的Lite版…

lite版的so文件只有9M.主要是阉割了一些不常用的功能,使用lzma压缩.最终将文件保持在9m多.

这个还可以接受.

于是包太大这个问题的解决方案是:

1.使用lite版.
2.只打包arm版的so.

---

前面既然说到lzma压缩.如此高的压缩比也不是没有代价的…代价就是

解压时间很长!!!

而且是用到的时候才开始解压!

在我nexsu5机器上,居然要13秒左右…

虽说只需要解压一次,但是想象一下.用户第一次打开某个h5模块的时候,要面对一个loading框长达10多秒…

不能忍…于是查源码.

原来是有一个叫XWalkActivityDelegate的类,onresume方法主要执行两件事,activate和decompress
activate主要是加载so的工作在里面.这部分耗时不多.
decompress是解压.罪魁祸首就在这一步.

decompress中做了什么事呢?除了漫长的java方法以外,需要重点关注的就是:

它怎么解压成功之后保存状态,下一次就不需要解压的?

继续翻源码,原来是SharedPreferences中libxwalkcore.xml里面一个叫version的值.
解压完成以后,会设置为5.下次就不用解压,直接activate了.

那我们就在application中开始解压吧.

解决方案:

复制XWalkLibraryDecompressor,在application的oncreate中就开始解压.

---

虽然解压时间提前了,但是还是有很大可能在解压完成之前用户就进入hybrid模块.

有两种方案:

1.使用loading progress.解压完成以后,再加载h5页面.
2.进入时判断解压状态,如果还未解压完成,使用自带webview加载.

考虑之后决定还是使用方案2.主要是解压的进度无法获知.单纯的loading progress用户体验太差.

真的不能得到解压进度么?如果以百分比显示解压进度不是很好,就不用又回到普通webview上面来了.

虽然只是第一次进入h5模块的时候可能还未解压完,但是毕竟自带webview问题太多了.也很难跟用户解释这个事情.

既然解压也是java写的,那就继续扒jar包吧.

然而这次是无能为力了.lzma解压的java代码写得异常复杂.加上jar包里面命名混乱.再加上对这种算法一无所知.

复制Decoder类以后还是无法插入代码进行进度回传.

于是在网上寻找能提供进度显示的lzma解压库.

然后就发现这货.使用native方法来解压!

虽说需要加上一个1.5m的so文件.但是经过试验,解压时间缩短到只需要23s.因缺斯汀

于是crosswalk包过大的问题算是解决了.

1.使用crosswalk-lite.核心so文件降低至9m
2.使用native方法进行so文件解压.

---

然而第三个(也许是最后一个)问题又来了:

不支持加载web页面时带上自定义header.

是不是很坑?估计作者只想到把参数放在url后面.却忽略了天朝重视接口安全的国情.

好在标准版最近的两个release-19,20中已经加上了对应的代码,支持这个需求了.

但是lite版号称几个月更新一次.鬼知道什么时候才能跟上这个节奏.也给加上啊…

看来如果等不及的话,还是要上标准版的节奏…

于是看看这个lite版到底是怎么变成这么小的:

可以看到,通过阉割功能带来的体积缩小并不明显.更多的还是通过lzma压缩.

那么我自己来压缩一下试试?以最高比例压缩模式,通过lzma方式对标准版进行压缩.

mac上的压缩软件实在没几个好的,压缩过程在windows机器上用7zip工具完成.此处略过

结果就是:标准版so压缩以后比lite的so大了3.5m…

那么最终方案来了:

1.说服前端人员,放弃在加载h5页面时携带自定义header.

2.使用标准版so,最终apk大约增加4m.(当然,还有可能带来的性能提升,毕竟完整版)

3.等待lite更新至19以上的版本.(当前标准版的beta分支已经到21,stable分支到了18).
具体用哪种,看项目需要吧.

至此,crosswalk的介绍就暂时结束了.如果有新的坑和进展再来更新.