在微信的文檔中有一個章節說明了『 原生組件的使用限制 』有這么一段話
『由于原生組件脫離在 WebView 渲染流程外,因此在使用時有以下限制:
原生組件的層級是最高的,所以頁面中的其他組件無論設置 z-index 為多少,都無法蓋在原生組件上。
后插入的原生組件可以覆蓋之前的原生組件。
原生組件還無法在 scroll-view、swiper、picker-view、movable-view 中使用。
部分CSS樣式無法應用于原生組件,例如:
無法對原生組件設置 CSS 動畫
無法定義原生組件為 position: fixed
不能在父級節點使用 overflow: hidden 來裁剪原生組件的顯示區域
原生組件的事件監聽不能使用 bind:eventname 的寫法,只支持 bindeventname。原生組件也不支持 catch 和 capture 的事件綁定方式
在iOS下,原生組件暫時不支持觸摸相關事件。
在工具上,原生組件是用web組件模擬的,因此很多情況并不能很好的還原真機的表現,建議開發者在使用到原生組件時盡量在真機上進行調試?!?/p>
所謂的原生組件,即非Web組件系統擴展Native組件。因為小程序在視圖渲染層面使用了WebView,而在Video,Map這類組件,使用WebView的WebCore渲染之后體驗不佳的詬病一直存在,而且標準不一。小程序上因使用原生的WebView進行渲染,而不是用修改的WebView內核(至少在iOS上沒有這么干),而無法對web原生標簽擴展?;谟脩趔w驗,和坑爹的技術限制,小程序提出了原生組件的概念,也就是在WebView上面使用原生組件填充占位元素的方式修補這類組件用戶體驗問題。因為WebView和原生組件在應用層本身就不是一個渲染層級,于是出現Web上面的標簽無法浮于Video之上(直播應用的惡夢),在不修改技術思路的前提下,position: fixed, overflow: hidden這樣的屬性是不可能用于原生組件的樣式的。不過偽同層渲染也不是說不可能,即在渲染原生組件時候根據層級鏤空面積。
特別在Map上使用WebView作為渲染之后體驗不佳的詬病一直存在,特別是地圖上marker標記過多的重度場景下,筆者所在的公司的在使用高德地圖Web端提供出來的C端具備反人類的體驗,地圖拖拉龜速,點擊響應緩慢,加載loading地圖區域等待時間過長。而Video則支持的格式有限,列出部分瀏覽器的支持的如下:
上述,可以知道視頻支持有限(限于版權)。而就我們關注的移動端iOS和Andoroid,實現一個視頻播放,我們可能都會有以下幾點的需求:
1、全屏處理; 2、覆蓋層效果; 3、自動播放; 4、播放控制; 5、隱藏播放控件;
在iOS上如果使用WebView,你無法修改全屏下的工具這一點體驗已經足夠讓所有的產品經理抓狂,更不用說Android的這么多的機型。覆蓋層效果在微信上不得不使用微信提供原生組件cover-view實現,而限于原生實現限制,cover-view的支持有限。
1、組件層于WebView層之上 這也應該是微信小程序團隊現階段使用的方案,通過特殊的占位標簽,使用getBoundingClientRect獲取組件位置,而原生組件跟隨Webview滾動。 Talking is cheap. Show me your code,那么用代碼實現的效果的如下。
now_lowest_gif.gif
從圖中可見,覆蓋層確實位于原生組件之下。
2、組件層于WebView層之下 此方式略微復雜。需要通過與Webview scroll聯動的置于Webview之下的Component Layer實現,而Webview背景設置為透明。至于事件,通過Webview的事件透傳,傳遞到Component Layer,需要通過緩存webview中元素再計算是否被點中通過重寫hitTest方法實現。通過此技術方案實現的好處也是明顯的,因為原生組件層很多時候都是置于最底層,而Web上的組件可以輕松覆蓋于Native之上,無需使用cover-view之類的hack方法。 效果如下所示
圖片發自簡書App Tips 在iOS上還特別需要注意一點UIWebview的坑。在使用-webkit-overflow-scrolling 使用,你會發現momentum scroll階段并不會觸發scroll事件,而且 scrollTop 屬性不會變化,當然getBoundingClientRect也同樣失效。如果考慮使用touchmove 這樣事件你也僅僅在手指還在屏幕上的時候觸發,檢測滾動區域內部元素的getBoundingClientRect 同樣無效。
當然幸運的是,這么大一個坑只是發生在UIWebview,對WKWebview并沒有影響。