『由于原生組件脫離在 WebView 渲染流程外，因此在操作時有以下束縛：

原生組件的層級是最高的，所以頁面中的其他組件無論設置 z-index 為多少，都無法蓋在原生組件上。 
后插入的原生組件可以覆蓋之前的原生組件。 
原生組件還無法在 scroll-view、swiper、picker-view、movable-view 中操作。 
部分CSS樣式無法應用于原生組件，例如： 
無法對原生組件設置 CSS 動畫 
無法定義原生組件為 position: fixed 
不能在父級節點操作 overflow: hidden 來裁剪原生組件的顯示區域 
原生組件的事件監聽不能操作 bind:eventname 的寫法，只支持 bindeventname。原生組件也不支持 catch 和 capture 的事件綁定方式 
在iOS下，原生組件暫時不支持觸摸相關事件。 
在工具上，原生組件是用web組件模擬的，因此很多情況并不能很好的還原真機的表現，意見搭建者在操作到原生組件時盡量在真機上進行調試。』

所謂的原生組件，即非Web組件軟件擴展Native組件。因為微信小程序在視圖渲染層面操作了WebView，而在Video，Map這類組件，操作WebView的WebCore渲染之后體驗不佳的詬病一直存在，而且標準不一。微信小程序上因操作原生的WebView進行渲染，而不是用修改的WebView內核（至少在iOS上沒有這么干），而無法對web原生標簽擴展。基于用戶體驗，和坑爹的技術束縛，微信小程序提出了原生組件的概念，也就是在WebView上面操作原生組件填充占位元素的方式修補這類組件用戶體驗問題。因為WebView和原生組件在應用層本身就不是一個渲染層級，于是出現Web上面的標簽無法浮于Video之上(直播應用的惡夢)，在不修改技術思路的前提下，position: fixed， overflow: hidden這樣的屬性是不可能用于原生組件的樣式的。不過偽同層渲染也不是說不可能，即在渲染原生組件時候根據層級鏤空面積。

特別在Map上操作WebView作為渲染之后體驗不佳的詬病一直存在，特別是地圖上marker標記過多的重度場景下，筆者所在的企業的在操作高德地圖Web端提供出來的C端具備反人類的體驗，地圖拖拉龜速，點擊響應緩慢，加載loading地圖區域等待時間過長。而Video則支持的格式局限，列出部分瀏覽器的支持的如下：

1. Firefox：支持 Ogg Vorbis和WAV
2. Opera ：支持Ogg Vorbis和WAV
3. Safari ：支持MP3，AAC格式 ，和MP4
4. Chrome ：支持Ogg Vorbis，MP3，WAV，AAC和MP4
5. Internet Explorer 9+ ：支持MP3，AAC格式 ，和MP4
6. IOS ：支持MP3，AAC格式 ，和MP4
7. Android ：支持AAC和MP3

上述，可以知道視頻支持局限（限于版權）。而就咱們關注的無線端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并沒有影響。