crossWalk替換webView集成 最近遇到一個盒子，性能有點差，設(shè)計出來的PSD效果那是史無前例的美。先說說我們的app架構(gòu)吧，我們現(xiàn)在的搞法都是沒有用androidTV原生寫的。因為我們做的是電視端的APP，與電視交互的只有遙控，所以焦點標(biāo)示很重要。我們的搞法就是webView瀏覽器加載我們的頁面，有視頻播放的就加個MediaPlay，這個自帶播放器目前我們還是夠用的，但是也有坑，后面說。 前端UI把這些切出來后，我們實現(xiàn)基本上是看盒子性能來寫我們的頁面的。差點的盒子，我們現(xiàn)在連jQuery都不敢引入。因為之前的經(jīng)歷說出來都是淚，所以目前我們都是最原始的寫法，更加不談什么ES6、ES7，css3的樣式UI都不敢瞎寫，總之就是大家都是內(nèi)心把它當(dāng)傳統(tǒng)盒子看，在這個前提下小心謹(jǐn)慎的加樣式，驗效果，就是這樣也發(fā)現(xiàn)還是入坑了。 當(dāng)我們實現(xiàn)完了，在瀏覽器跑完后，我們app殼加載頁面驗，出來的效果慘不忍睹，頁面就是想僵尸驗，卡，卡，卡的感覺。最后找來一個專門人士，刻苦攻關(guān)，一個晚上集成crosswalk，這里先說集成步驟，然后我們再來說那些坑。 1、項目環(huán)境下的build.gradle引入 在repositories里加入 maven { url 'https://download.01.org/crosswalk/releases/crosswalk/android/maven2' } 2、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' 注意他們是有區(qū)別的 api完全等價于compile ，在編譯性能上implementation 會有所提高的。但是模塊之間有依賴還是用api，下面來看看官方解釋: 在3.0版本中，compile 指令被標(biāo)注為過時方法，而新增了兩個依賴指令，一個是implement 和api，這兩個都可以進(jìn)行依賴添加，但是有什么區(qū)別呢？? api 指令 完全等同于compile指令，沒區(qū)別，你將所有的compile改成api，完全沒有錯。? implement指令 這個指令的特點就是，對于使用了該命令編譯的依賴，對該項目有依賴的項目將無法訪問到使用該命令編譯的依賴中的任何程序，也就是將該依賴隱藏在內(nèi)部，而不對外部公開。? 文不如圖 這里寫圖片描述?

用api指令編譯，Glide依賴對app Module 是可見的，app Module也可以使用Glide依賴?

用implement指令編譯依賴對app Module 是不可見的，app Module不可以直接使用Glide? 建議 在Google IO 相關(guān)話題的中提到了一個建議，就是依賴首先應(yīng)該設(shè)置為implement的，如果沒有錯，那就用implement，如果有錯，那么使用api指令，這樣會使編譯速度有所增快。 Ps:關(guān)于引入依賴的版本號怎么找最新的，在瀏覽器打開maven引入的地址，依次進(jìn)入目錄 org/xwalk/xwalk_shared_library/，最終url地址： https://download.01.org/crosswalk/releases/crosswalk/android/maven2/org/xwalk/xwalk_shared_library/
最下面的就是最新版了，至少國內(nèi)是最新版，如果翻墻，可能有新版，但是國外的maven地址速度不一定靠譜，國內(nèi)最新版應(yīng)該夠用了。從上面看來，從intel在iWeb大會上吹過牛后，到現(xiàn)在對版本的維護(hù)貌似有所延期，最近一次已經(jīng)是10個月之前的了。用第三方的玩意就怕版本變更。。。扯遠(yuǎn)了。 3、?AndroidManifest.xml引入權(quán)限 <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.READ_PHONE_STATE" /> <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" /> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> application節(jié)點里加入android:hardwareAccelerated="true" 這個是硬件加速，也就是如果盒子有GPU，設(shè)置這個會有更好的表現(xiàn)，同時分擔(dān)CPU的壓力，下面是官方解釋： 從Android3.0 (API level11)開始，Android的2D顯示管道被被設(shè)計得更加支持硬加速了．硬加速使用GPU承擔(dān)了所有在View的canvas上執(zhí)行的繪制操作． 　　啟用硬加速最簡單的的方法是對整個應(yīng)用啟用硬件速．如果你的應(yīng)用只使用標(biāo)準(zhǔn)的view和Drawable，全局啟用硬加速將不會帶來任何負(fù)面影響．然而，因為硬加速不是被所有的２Ｄ繪制所支持，所以啟用它時可能對你的自定義繪制產(chǎn)生影響．出現(xiàn)的問題經(jīng)常是不可見的，也可能是異常，或錯誤地顯示了像素．為了避免這些問題，Android提供了在以下各級別上啟用或禁止硬加速的能力： Application Activity Window View 我們這里簡單粗魯?shù)膶φ麄€APP使用了硬件加速，也就是在Application節(jié)點里加的這個設(shè)置。 Activity級 與Application一樣，也是在Activity節(jié)點設(shè)置即可。 Window級 　　 如果你需要更高顆粒度的控制，你可以使用以下代碼為一個window啟用硬加速： getWindow().setFlags( WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);? 注：現(xiàn)在你還不能在window級別禁止硬加速． 這個在寫文檔之前我們的app里是沒有設(shè)置這個的，后來在代碼中加入這幾行代碼，驗證沒有產(chǎn)生任何異常，但是貌似肉眼也沒感覺出啥效果。 View級 你可以在運行時使用以下代碼禁止個別的View的硬加速： myView.setLayerType(View.LAYER_TYPE_SOFTWARE,null); 注：當(dāng)前你不能在View級別啟用硬加速．View層有除禁止硬加速之外的其它功能． 判定一個View是否能被硬加速 　　有時一個應(yīng)用了解是否啟用了硬件速是很有用的，對那些自定義View之類的東西尤其重要．在你的應(yīng)用做了一些不被最新的管線所支持的自定義繪制時這更加重要． 　　有兩種方法可以檢查應(yīng)用是否被硬加速： View.isHardwareAccelerated()：如果View附加到一個硬加速的window上就返回true． Canvas.isHardwareAccelerated()：如果Canvas被硬加速了就返回true． 　　如果你必須在你的繪制代碼中做這個，應(yīng)使用Canvas.isHardwareAccelerated()而不是View.isHardwareAccelerated()．當(dāng)一個view附加到一個硬加速的window上，它仍可以使用非硬件速的Canvas進(jìn)行繪制操作．比如當(dāng)為了高速緩存而把一個view畫到一個bitmap中． 以上代碼在onCreated里驗證，沒看出明顯效果。不過我想現(xiàn)在的盒子應(yīng)該都有GPU，打開硬件加速也沒有什么影響吧。這些不是因為引入crossWalk才有的，這里只是順便科普下，我自己也沒有用過除了Application的硬件加速，今天寫文檔順便也學(xué)習(xí)了。 4、布局引入使用 <org.xwalk.core.XWalkView android:id="@+id/xwalkWebView" android:layout_width="fill_parent" android:layout_height="fill_parent" android:orientation="vertical" /> 到此，crossWalk的webView引入就完成了，它的API與webView驚人的相似，只是在有些處理上做了細(xì)化，感覺intel就是來研究google開源的android的，說不定intel以后也要出手機盒子智能系統(tǒng)了，YY下，大佬們的世界我反正不懂。 做完這些你就可以編譯了，讓這個apk打開個網(wǎng)頁看看效果吧。如果你在編譯中遇到
專門人士應(yīng)該一看，就應(yīng)該知道這是SDK的版本低了，設(shè)置修改下
crossWalk目前要求的SDK最低版本是16，也就是對應(yīng)Android 4.1、4.1.1 （JELLY_BEAN）
5、下面就來說說我跟同事在哪個晚上遇到的坑吧（我目前對這個坑依然無解，第二天同事找到一個方法規(guī)避，我也找到一個猥瑣的方法規(guī)避，但是目前都依然還有坑，主要是因為我們的殼只有一個Activity(盒子apk的常規(guī)搞法)，視頻播放使用的是MediaPlayer，有全屏和小屏播放切換） 網(wǎng)上描述的說：返回按鈕，它是會不用你寫邏輯，而自己去執(zhí)行網(wǎng)頁的跳轉(zhuǎn)的。 在webView里，你可能在dispatchKeyEvent方法里判斷按鈕鍵值，如果是返回，我們就調(diào)用webView.goBack(),執(zhí)行頁面返回。但是在crossWalk里，你按返回按鍵，還沒有進(jìn)dispatchKeyEvent頁面就已經(jīng)執(zhí)行返回，跳到上一個歷史頁面了。對于這一點網(wǎng)上還有開發(fā)者叫好，我。。。。。 我們這里的返回做的不一定是返回上一個頁面啊，我們還肩負(fù)MediaPlayer的全屏退出。當(dāng)我在頁面上小屏播放時，獲得焦點按OK鍵是全屏播放并顯示進(jìn)度條時長，進(jìn)入播控邏輯的，比如快進(jìn)快退暫停。當(dāng)我在全屏播放怎么退出呢？操作慣性肯定是會下意識的按返回，那問題就來了，這時候按返回。我希望的是像在webView里一樣，我可以判斷播放是否全屏的狀態(tài)，然后決定是加載上一個頁面還是退出全屏。事實上是頁面先加載上一個頁面了，我調(diào)用頁面的js方法居然是調(diào)用的上一個頁面的方法。。。。 也許有人會說那你全屏播放怎么不跳頁面，在新頁面做啊？ 那我現(xiàn)在說下為什么，首先跳新頁面是不是有加載時間？直接當(dāng)前MediaPlayer調(diào)整配合它的SurfaceView大小全屏，播放不用中斷，是不是給人一種很“快”的感覺？如果你跳頁面，在再頁面的js方法里寫請求，獲取播放串，調(diào)用MediaPlayer，那播放位置怎么做到跟原來小窗口連貫一致？（寫到這我突然想到，如果我全屏播放頁面是加載一個新頁面（空頁面或隨便什么頁面，反正被SurfaceView遮住在），但是播放的MediaPlayer我如果還是原先的邏輯直接調(diào)整當(dāng)前SurfaceView的大小，我再按返回鍵是不是我頁面返回也正確了，窗口我也可以調(diào)整了？需要驗證，過后找專門同事討論下） 同事的做法是參考網(wǎng)上的做法，自己在包一層，寫個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); }
@Override public boolean dispatchKeyEvent(KeyEvent event) { if (event.getKeyCode() == KeyEvent.KEYCODE_BACK){ return false; //這里很關(guān)鍵說是要return true } return super.dispatchKeyEvent(event); } 按照android的思維是我返回true就是告訴你我已經(jīng)處理了，后面不用你再處理，同事的想法是在這里return true。然后我的Activity上的dispatchKeyEvent就不再處理了，我們再在onKeyDown里處理，結(jié)果是無論我們返回true，false效果是一樣的，頁面確實按照我們的思路跳了，但是頁面實際還是沒有交由交由我們頁面上的js自己控制（我們的url是用cookie的存儲，類似棧先進(jìn)后出，地址是否加到棧里也是我們自己控制，我可以請求多個地址但是這個地址不加到棧里，我返回就不用一級級返回。我們在頁面的返回按鈕上寫我們自己的邏輯，也就是瀏覽器正常了，那就是我們就可以開始加apk殼了，殼里值針對上下左右返回，調(diào)用我們頁面的js方法就行）。 我們項目里有一個場景是看完一條圖文信息，點擊下一條，頁面加載下一個，下一個下下個。。。。這樣進(jìn)入的頁面，我們都不加到url棧里，大家可以想象，我們用?？刂频目隙ㄊ钦５?#xff0c;但是APK殼實際是頁面一個個疊起來了的，那么我按“返回”，差異就顯而易見了。 就應(yīng)為發(fā)現(xiàn)這個，我的想法就是在殼里還是根據(jù)鍵值調(diào)用對應(yīng)的js方法，我沒加載一個頁面我就把apk加載的記錄清理掉，這樣就保證它自己沒有頁面可以返回，從而調(diào)用我的js方法執(zhí)行我們url棧的邏輯。具體做法： @Override public void onPageLoadStopped(XWalkView view, String url, LoadStatus status) { super.onPageLoadStopped(view, url, status); xWalkWebView.getNavigationHistory().clear(); //清理歷史記錄 mHandler.sendEmptyMessageDelayed(HIDE_UI_LOADING_IMG, 500); } 但是還是事與愿違，如果操作過快，不知道是不是清理歷史記錄需要時間還是怎么的，操作過快的返回還是偶現(xiàn)不正常的現(xiàn)象。這里清理歷史記錄我在shouldOverrideUrlLoading、onLoadFinished、onPageLoadStarted也都做了，不知道是不是還有什么地方?jīng)]有做到位，導(dǎo)致返回還是偶現(xiàn)不正常，看來這個方法不靠譜。 上面是返回的坑，下面在說說布局的坑。 對于android布局，是寫在xml下面的會在頁面上面一點，越下面頁面層級越靠上。這次我們是頁面上有播放的，所以是webView在最上面，下面是MediaPlayer的SurfaceView，進(jìn)度條SeekBar、時間TextView等。這樣布局后發(fā)現(xiàn)播放窗口不出來，但是有聲音，所以我們懷疑是webView擋住了，于是我們調(diào)整順序結(jié)果還是不行，最后現(xiàn)場的同事發(fā)現(xiàn)如果按下“禁音”鍵，視頻是一致可以展示，而按音量加減當(dāng)音量的條條消失，視頻就有被遮住了。說到這里不得不佩服同事的專業(yè)敏感度，他敏銳的想到這個調(diào)聲音展示的條條、禁音時的圖標(biāo)展示不就是跟Toast一樣嗎？于是，他想到自己造一個在頁面上，設(shè)置它透明，這樣就。。。。不過不知道別人有沒有遇到這樣的問題，目前我這水槍反正是沒整明白的。 綜上所述，對于crossWalk的坑規(guī)避方法 1、返回采用包一層重寫幾個方法實現(xiàn)比較靠譜 2、布局一般不會有問題，如果有視頻布局那就造個透明的Toast吧，期待更好的解決辦法。 另外，這個開源的2017年前的版本更新基本是1-2月一個，今年最近的版本是1.20號的，現(xiàn)在11月21了，還沒有更新，不知道后面intel的規(guī)劃是怎么樣的。用開源第三方的就這點不好，有些不可控，之前公司用的金山云的播放器，現(xiàn)在金山云要收費了。。。感覺我們應(yīng)該還是讓公司的專門人事開始常用組件的開發(fā)。比如webView、MediaPlayer，之前同事也提到過播放器要自己寫，就目前看貌似已經(jīng)全民RN了。安卓原生都轉(zhuǎn)RN了，原生寫的越來越少了，我覺得吧RN應(yīng)該讓我們這種非專門人士上手，曾經(jīng)環(huán)境都搭了沒有機會。。。。 扯遠(yuǎn)了，以上就是all。還有很多不明白的地方，這里可能沒有遇到，期待crossWalk的第二階段分享。

總結(jié)

以上是生活随笔為你收集整理的crossWalk替换webView集成的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。