題葉與敖天羽的Weex實戰案例解析

問：請問頁面間跳轉傳參數是如何實現的？Weex跳Weex，web跳web？

答：我們這邊試過跳轉到 Weex 頁面在 bundleUrl 里加上一個 queryString, Weex 里通過解析 bundleUrl 獲得參數。而跳轉到 Web 也可以同樣處理，區別是解析 location.search 。Web 跳 Weex 的話，需要 App 的開發人員提供一種特別的 Scheme，比如你可要求 App 方支持 myapp://weex?url=http://example.com/weex.js?a=3 這種類型的 Scheme。同理，也可以要求 App 方支持 myapp://web?url=http://example.com/?a=3這種類型的 Scheme，這樣就支持了 Weex 中打開 Web。也就是通過 url 當中的狀態去實現了, 比較常用的一個辦法。（也就是說要原生開發人員支持這種方式？）是的。

問：這兩天蘋果禁用jspatch事件是否會影響Weex？

答：現在還沒有確定的結論。我們詢問過勾三股四，在蘋果發布了通知之后，依然有使用 Weex 的應用通過了審核。使用了 Weex 的 App 發版比較著急（比如一周內上線），可能需要先移除 Weex 相關的代碼去提交審核。這一點我覺得跟上官方的消息會更快一點, 比說 issue 上或者開發團隊的微博。

問：如何更精準的適配是如何做的？關于Weex只支持px這一點，比如圖片的展現就必須要寫出寬高。

答：圖片必須寫出寬高是 Weex 的硬性要求，這和 AMP 的要求是一致的，這樣帶來的好處是，圖片的加載不會帶來頁面的跳動，同時也有助于減少系統繪制時的布局計算。如果圖片的高寬無法事先確定，可以先設置為0，從后端獲取圖片高寬之后再動態設置, 有個例子可以參考。AMP 是 Google 的一個技術, 在 PWA 之前, 類似的也做了優化網頁加載。好像 Weex 會以總寬 750 px 為依據自動計算實際需要的大小，不存在更精確的適配問題。

問：文章中提到業務開發只用了三天，報錯和性能監控用了兩周。使用Weex是不是需要花很多時間用于性能的優化？使用Weex需要熟悉Android 和 iOS 開發嗎，還是只要了解即可？

答：Weex 的性能很優異，不用特別的去優化。同時因為是第一個采用 Weex 的項目, 相對謹慎并不是一個很復雜的頁面。監控和降級是互聯網公司的通用措施，用來降低線上事故對用戶的影響。我們初次使用 Weex，肯定也有很多疑慮，所以花了很多時間在監控和降級上。由于 Weex 不少程度復用了 HTML5 開發當中開發方式, 其實也有小部分棧是可以復用的.使用 Weex 需要 iOS、Android 程序員集成到你們 App 中，這個估計 2 天工作量就可以搞定了。前端程序員在使用 Weex 的時候，用到的 iOS、Android 知識最多是怎么啟動一個模擬器。甚至如果是純粹 js 部分的開發的話, 比如借助 Weex Playground, 其實也就是掃碼打開一個 Weex 頁面的地址那么簡單,可能在查看 log 或者使用 debugger 方面確實要注意熟悉一下, 但總體上不用深入了解 Native 的開發(Native 組件的開發除外的話).

問：請問Weex中可以進行熱修復，熱更新這種處理嗎？

答：如果你知道 WebView，可以按照 WebView 的方式去理解 Weex。WebView 加載的是 HTML 作為入口，WeexView 加載的是 JS 文件做入口。Weex 原生就支持加載遠程的 JS 文件。所以如果想實現熱更新，只要把自己的 JS Bundle 放到遠程的 HTTP 服務器上就可以了。而且嘗試過 Weex Playground 的話, 你會知道它掃碼打開的就是一個 .js 的文件.所以熱更新的話, 由于 Weex 的運行機制就是獲取一個 JavaScript 文件, 只要重新獲取這個文件, 就能達到更新的目的.

問：現在正在做一個項目，使用的是Android原生開發，打算后面的功能使用Weex開發，這樣可行嗎，我看一些Weex的入門資料，但都是點到為止，關于原生功能和Weex頁面怎么傳參，Weex怎么跳轉到原生等等，都覺得沒有可參考的實現。有沒有比較好的資料供初學者學習和參考呢？

答：Weex 頁面的傳參上面的問題已經回答過了，關于初學者資料，我覺得首先是文檔，Weex 的文檔總體跑個 Hello World 還是沒問題的。還有一些 Weex 的非官方寫的教程，比如說我們的《Weex 新手指南》系列，針對于前端開發者寫 Weex 我覺得基本夠用了，如果是 Native 開發者寫 Weex，可能需要再看一下 Vue.js 的官方文檔了解一下 Vue。參考代碼的話我們之后可能會出我們的仿餓了么教程，目前 GitHub 中也有一些比較有參考價值的文章。

問：本人電商應用，原來打算接入Weex的，然而呢？發現在三星galaxy上面有一些問題不顯示，而我們的用戶呢大部分是三星的。當時是同樣代碼，在華為、小米、魅族都可以，可是原生系統就不行，所以后面放棄了。不知道，您那邊檢測的時候有沒有用戶反饋這種問題，我們市場主要在美國那邊。

答：我們上線的 Weex 版本的發現頁崩潰率很低，我們的監控系統也并沒有上報三星機型上的錯誤。非常抱歉，這個問題求助于 Weex 官方可能能獲取到一些有用的信息。?粗體文字

問：綜合Weex的技術成本和學習成本，目前看Weex是否具備了大型app構建的能力？Weex實現拖動交互困難,是困難在那個地方了？

答：Weex 的學習成本不高，前端工程師學習一周都能勝任。目前的 Weex 可以看成是 WebView 的性能改善版，完全使用 Weex 構建一個大型 App 并不現實。Weex 實現一些滾動效果的困難之處在于 Weex 的組件沒有提供相應的事件，你無法得知用戶正在滾動以及 Scroller 的當前位置。

問：Weex可以與原生的控件共存嗎，還是用了Weex開發，所有控件都得用js來寫了？

答：還是剛才那個問題的概念，你把 Weex 理解成類似 WebView 的技術。是可以在 App 中局部嵌入一個 WeexView 的，你可以參考下這個項目：https://github.com/dengjunwen/WeexPageDemo。

問：Weex listView 怎么優化的？

答：Weex 的 List 組件在 Android 端直自帶的 RecyclerView；在 iOS 端自己實現了一個 List 組件，具體實現可以參考這里，我們看過一點代碼，也是對不可見的 Cell 進行復用來達到的性能優化效果。

問：主動錯誤收集上報與業務邏輯混雜在一起是怎么解決的？

答：其實并沒有解決這個問題, 現在監控的內容相對少, 因而沒有侵入到業務當中,以后如果需要更加精確的監控, 未必能避免代碼混進業務當中的. 我覺得這也不是 Weex 的問題.

問：能詳細說下監控了哪些點嗎？跟普通html5、原生app的監控異同？

答：主要監控了兩個點：性能數據以及報錯數據。和 HTML 5 的不同就是需要 App 配合才能拿到性能、錯誤數據，而不是通過瀏覽器的 API 不同。比如 addEventListener "error" 我們在使用當中發現并不能像 web 那樣可靠地捕獲到所有 error。我們了解到的是 App 的監控通過 Hook 系統的 API 的方式去監控，Weex 的監控通過 Weex 本身提供的生命周期去監控。從 Weex 獲得 renderTime, networkTime, 以及 SDK 初始化消耗的時間等等, 這些和 Web 當中的 Performance API 提供的網絡時間信息有不小區別。（比較關注哪些指標？）Weex 這邊具體是網絡占用的時間, 示例啟動的時間, 渲染占用的時間.

問：關于說到的 list 組件，雖然有服用。但是首次渲染實際上是一個 cell 一個 cell 渲染的，并非一次渲染的，所以首次加載時性能很差，特別是 iOS，因為內核。這個有解決辦法么？

答：沒有感覺慢，相比 Scroller 渲染速度快許多。你可以確認下是否用的 List 組件而非 Scroller。

問：除了 list 組件 ，有對其他組件和RN做過性能比較嗎？

答：沒有做過。WebView 目前的痛點也只在于的長列表的渲染，所以我們之前對性能的關注點還是在長列表上。

問：使用v-if值顯示或隱藏組件，在app上出現卡頓，你們是怎么解決的？

答：我們確實也遇到過這個問題，我們目前使用的方法是：需要隱藏元素時，直接將 height 或者 width 置為0。比如：width: active ? '750px' : 0。

問：如果我要在項目 中使用Weex，前端和native端人員分配比是怎么樣的？核心是不是還在native上？

答：我們只有在前期接入監控以及實現部分 Scheme 的時候需要 Native 端配合，正式進入業務開發就不需要 Native 端配合了。還是看業務類型，如果需要使用 Native 端的組件，可能還是需要 Native 端配合了。

問：1）在工程化方面你們有什么最佳實踐；2）在對 tableView 或者其他方面有什么要注意的點來盡可能的使頁面渲染更快（除了盡可能用 cell）？

答：目前我們也仍舊在探索階段，并沒有特別的最佳實踐，只能是對著一些資料進行探索。tableView 并不清楚。

問：我的問題是現在Weex還在快速迭代，難免出現bug，但是Weex官方團隊處理這些問題上感覺有些慢。而且作為小團隊很難去咨詢到官方的人。 餓了么算是現在非官方最早接入Weex的大團隊，不知道有沒有興趣和可能作為非官方去維護一些Weex社群，群內維護接入者的一些詢問，或開展一些分享等，也可以將大家的聲音帶到Weex核心開發者。為Weex接入者謀些福利？

答：接觸到 Weex 官方還是非常容易的，如果你真正的已經接入到你的 App 里面，你可以去聯系下 vczero，他會加你到一個微信群里面。現在互助的還有 Weex.help 網站有很多愛好者, 也有社區自己的微信群, 可以加入.其實官方也說過了, Segmentfault 是他們會回答問題的地方, 其實在上面發問題已經有很多的回答了, 而且有 Weex 核心團隊的同學在解答問題.我們沒有維護非官方社區的打算. 其實 Weex 已經是中文社區的技術和平臺了,大家可以盡量參與到官方的活動或者分享當中。

問：沒用過Weex，那么Weex如果是基于webview，那么對于比如原生android的list view上容易出現的OOM的問題 Weex那邊是怎樣解決和優化的呢？

答：Weex 并不是基于 WebView, 準確說和瀏覽器共通的是 V8 引擎而已, 渲染引擎是通過 Native 代碼的實現的。對于說的具體的 list view 上的問題, 我們沒有深入過, 抱歉。

Chat文章：《Weex 技術在餓了么前端的實戰經驗》

在此感謝人民郵電出版社，為本場Chat的獲獎讀者提供了《Vue.js前端開發》一書。

本文轉載自異步社區。

移動APP Android

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。