《crossWalk替换webView集成》由会员分享，可在线阅读，更多相关《crossWalk替换webView集成（6页珍藏版）》请在金锄头文库上搜索。
1、crossWalk替换webView集成crossWalk替换webView集成最近遇到一个盒子，性能有点差，设计出来的PSD效果那是史无前例的美。先说说我们的app架构吧，我们现在的搞法都是没有用androidTV原生写的。因为我们做的是电视端的APP，与电视交互的只有遥控，所以焦点标示很重要。我们的搞法就是webView浏览器加载我们的页面，有视频播放的就加个MediaPlay，这个自带播放器目前我们还是够用的，但是也有坑，后面说。前端UI把这些切出来后，我们实现基本上是看盒子性能来写我们的页面的。差点的盒子，我们现在连jQuery都不敢引入。因为之前的经历说出来都是泪，所以目前我们都是最
2、原始的写法，更加不谈什么ES6、ES7，css3的样式UI都不敢瞎写，总之就是大家都是内心把它当传统盒子看，在这个前提下小心谨慎的加样式，验效果，就是这样也发现还是入坑了。当我们实现完了，在浏览器跑完后，我们app壳加载页面验，出来的效果惨不忍睹，页面就是想僵尸验，卡，卡，卡的感觉。最后找来一个专门人士，刻苦攻关，一个晚上集成crosswalk，这里先说集成步骤，然后我们再来说那些坑。1、项目环境下的、项目环境下的build.gradle引入引入在repositories里加入maven url https:/download.01.org/crosswalk/releases/crosswa
3、lk/android/maven22、app下的下的build.gradle引入依赖引入依赖在dependencies里加入compile org.xwalk:xwalk_core_library:23.53.589.4这个compile 需要说明一下，AS3.0之前是这样引入的，如果使用的AS3.0，那么引入可以改为api org.xwalk:xwalk_core_library:23.53.589.4或implementation org.xwalk:xwalk_core_library:23.53.589.4注意他们是有区别的api完全等价于compile ，在编译性能上implemen
4、tation 会有所提高的。但是模块之间有依赖还是用api，下面来看看官方解释:在3.0版本中，compile 指令被标注为过时方法，而新增了两个依赖指令，一个是implement 和api，这两个都可以进行依赖添加，但是有什么区别呢？ api 指令指令完全等同于compile指令，没区别，你将所有的compile改成api，完全没有错。 implement指令指令这个指令的特点就是，对于使用了该命令编译的依赖，对该项目有依赖的项目将无法访问到使用该命令编译的依赖中的任何程序，也就是将该依赖隐藏在内部，而不对外部公开。 文不如图这里写图片描述 用api指令编译，Glide依赖对app Modu
5、le 是可见的，app Module也可以使用Glide依赖 用implement指令编译依赖对app Module 是不可见的，app Module不可以直接使用Glide 建议在Google IO 相关话题的中提到了一个建议，就是依赖首先应该设置为implement的，如果没有错，那就用implement，如果有错，那么使用api指令，这样会使编译速度有所增快。Ps:关于引入依赖的版本号怎么找最新的，在浏览器打开maven引入的地址，依次进入目录org/xwalk/xwalk_shared_library/，最终url地址：https:/download.01.org/crosswalk/
6、releases/crosswalk/android/maven2/org/xwalk/xwalk_shared_library/最下面的就是最新版了，至少国内是最新版，如果翻墙，可能有新版，但是国外的maven地址速度不一定靠谱，国内最新版应该够用了。从上面看来，从intel在iWeb大会上吹过牛后，到现在对版本的维护貌似有所延期，最近一次已经是10个月之前的了。用第三方的玩意就怕版本变更。扯远了。3、 AndroidManifest.xml引入权限application节点里加入android:hardwareAccelerated=true这个是硬件加速，也就是如果盒子有GPU，设置这个
7、会有更好的表现，同时分担CPU的压力，下面是官方解释：从Android3.0 (API level11)开始，Android的2D显示管道被被设计得更加支持硬加速了硬加速使用GPU承担了所有在View的canvas上执行的绘制操作启用硬加速最简单的的方法是对整个应用启用硬件速如果你的应用只使用标准的view和Drawable，全局启用硬加速将不会带来任何负面影响然而，因为硬加速不是被所有的绘制所支持，所以启用它时可能对你的自定义绘制产生影响出现的问题经常是不可见的，也可能是异常，或错误地显示了像素为了避免这些问题，Android提供了在以下各级别上启用或禁止硬加速的能力：Application
8、ActivityWindowView我们这里简单粗鲁的对整个APP使用了硬件加速，也就是在Application节点里加的这个设置。Activity级级与Application一样，也是在Activity节点设置即可。Window级级如果你需要更高颗粒度的控制，你可以使用以下代码为一个window启用硬加速：getWindow().setFlags(WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED); 注：现在你还不能在window级
9、别禁止硬加速这个在写文档之前我们的app里是没有设置这个的，后来在代码中加入这几行代码，验证没有产生任何异常，但是貌似肉眼也没感觉出啥效果。View级级你可以在运行时使用以下代码禁止个别的View的硬加速：myView.setLayerType(View.LAYER_TYPE_SOFTWARE,null);注：当前你不能在View级别启用硬加速View层有除禁止硬加速之外的其它功能判定一个View是否能被硬加速有时一个应用了解是否启用了硬件速是很有用的，对那些自定义View之类的东西尤其重要在你的应用做了一些不被最新的管线所支持的自定义绘制时这更加重要有两种方法可以检查应用是否被硬加速：Vie
10、w.isHardwareAccelerated()：如果View附加到一个硬加速的window上就返回trueCanvas.isHardwareAccelerated()：如果Canvas被硬加速了就返回true如果你必须在你的绘制代码中做这个，应使用Canvas.isHardwareAccelerated()而不是View.isHardwareAccelerated()当一个view附加到一个硬加速的window上，它仍可以使用非硬件速的Canvas进行绘制操作比如当为了高速缓存而把一个view画到一个bitmap中以上代码在onCreated里验证，没看出明显效果。不过我想现在的盒子应该都
11、有GPU，打开硬件加速也没有什么影响吧。这些不是因为引入crossWalk才有的，这里只是顺便科普下，我自己也没有用过除了Application的硬件加速，今天写文档顺便也学习了。4、布局引入使用到此，crossWalk的webView引入就完成了，它的API与webView惊人的相似，只是在有些处理上做了细化，感觉intel就是来研究google开源的android的，说不定intel以后也要出手机盒子智能系统了，YY下，大佬们的世界我反正不懂。做完这些你就可以编译了，让这个apk打开个网页看看效果吧。如果你在编译中遇到专门人士应该一看，就应该知道这是SDK的版本低了，设置修改下crossW
12、alk目前要求的SDK最低版本是16，也就是对应Android 4.1、4.1.1 （JELLY_BEAN）5、下面就来说说我跟同事在哪个晚上遇到的坑吧（我目前对这个坑依然无解，第二天同事找到一个方法规避，我也找到一个猥琐的方法规避，但是目前都依然还有坑，主要是因为我们的壳只有一个Activity(盒子apk的常规搞法)，视频播放使用的是MediaPlayer，有全屏和小屏播放切换）网上描述的说：返回按钮，它是会不用你写逻辑，而自己去执行网页的跳转的。在webView里，你可能在dispatchKeyEvent方法里判断按钮键值，如果是返回，我们就调用webView.goBack(),执行页面
13、返回。但是在crossWalk里，你按返回按键，还没有进dispatchKeyEvent页面就已经执行返回，跳到上一个历史页面了。对于这一点网上还有开发者叫好，我。我们这里的返回做的不一定是返回上一个页面啊，我们还肩负MediaPlayer的全屏退出。当我在页面上小屏播放时，获得焦点按OK键是全屏播放并显示进度条时长，进入播控逻辑的，比如快进快退暂停。当我在全屏播放怎么退出呢？操作惯性肯定是会下意识的按返回，那问题就来了，这时候按返回。我希望的是像在webView里一样，我可以判断播放是否全屏的状态，然后决定是加载上一个页面还是退出全屏。事实上是页面先加载上一个页面了，我调用页面的js方法居然
14、是调用的上一个页面的方法。也许有人会说那你全屏播放怎么不跳页面，在新页面做啊？那我现在说下为什么，首先跳新页面是不是有加载时间？直接当前MediaPlayer调整配合它的SurfaceView大小全屏，播放不用中断，是不是给人一种很“快”的感觉？如果你跳页面，在再页面的js方法里写请求，获取播放串，调用MediaPlayer，那播放位置怎么做到跟原来小窗口连贯一致？（写到这我突然想到，如果我全屏播放页面是加载一个新页面（空页面或随便什么页面，反正被SurfaceView遮住在），但是播放的MediaPlayer我如果还是原先的逻辑直接调整当前SurfaceView的大小，我再按返回键是不是我页
15、面返回也正确了，窗口我也可以调整了？需要验证，过后找专门同事讨论下）同事的做法是参考网上的做法，自己在包一层，写个MyXwalkView继承XWalkView，重写父类的几个方法：public MyXWalkView(Context context) super(context);public MyXWalkView(Context context, AttributeSet attrs) super(context, attrs);public MyXWalkView(Context context, Activity activity) super(context, activity);O
16、verridepublic boolean dispatchKeyEvent(KeyEvent event) if (event.getKeyCode() = KeyEvent.KEYCODE_BACK)return false; /这里很关键说是要return truereturn super.dispatchKeyEvent(event);按照android的思维是我返回true就是告诉你我已经处理了，后面不用你再处理，同事的想法是在这里return true。然后我的Activity上的dispatchKeyEvent就不再处理了，我们再在onKeyDown里处理，结果是无论我们返回true，false效果是一样的，页面确实按照我们的思路跳了，但是页面实际还是没有交由交由我们页面上的js自己控制（我们的url是用cookie的存储，类似栈先进后出，地址是否加到栈里也是我们自己控制，我可以请求多个地址但是这个地址不加到栈里，我返回就
