编程知识 cdmana.com

Chrome 是新的 Safari,Edge 和 Firefox 也是

原文鏈接:nielsleenheer.com/articles/20…

在的蘋果手機的應用商店,有很多瀏覽器可供選擇。在最新的 iOS 系統甚至可以把這些瀏覽器設置為默認瀏覽器。那麼為什麼一些抱怨iOS 上的瀏覽器選擇呢?

你可能沒有意識到 iOS 上的所有瀏覽器都需要使用與 Safari 相同的渲染引擎。在其他平臺上,情况並非如此。

在安卓系統、視窗系統甚至 macOS 上,他們都在使用 Chromium 渲染引擎。但在 iOS,它使用的是 WebKit。或者看看火狐,它在所有平臺上都使用 Gecko 渲染引擎。除了 iOS,它使用 WebKit。

###為什麼每個人都使用 WebKit?

並不是因為這些渲染引擎不能在 iOS 上運行。把渲染引擎移植到 iOS 可能需要一些工作,但是據我所知,一些瀏覽器希望投入這項工作,但是很遺憾他們不被允許這麼做。

事實上,App Store 中的應用需要經過蘋果的審核和批准,滿足應用商店審查指南:

2.5.6 瀏覽網頁的應用程序必須使用適當的 WebKit 框架和 WebKit Javascript 引擎。

這是最後的决定。蘋果要求瀏覽器使用 WebKit。事實上, 應用必須使用系統提供的 WebKit 框架。即使 WebKit 是開源的,也不能在應用程序中使用修改或者改進的任一版本。决不允許

@mtomweb創建的說明圖片

偉大的均衡器:系統WebView

但是你如何使用授權版本的 WebKit呢?有一個框架可以解决這個問題。蘋果提供了一個WebView,允許在你的應用程序中做少量工作就可以嵌入WebKit。需要為框架提供一個配置對象,並處理它發送的一些事件。 WebKit 處理所有實際的加載、解析和渲染。你的應用根本不需要關系任何細節。你需要做的僅僅是提供一個友好的用戶界面,也許還要與你的生態系統集成。例如:與桌面版本的瀏覽器共享書簽。

這正是其他瀏覽器廠商為這個爛攤子煩惱的首要原因。他們不關心在iOS上完成一個偉大的瀏覽器,而是更關心讓他們現有的用戶在iOS上進入他們當前的生態系統。

你在Windows上使用Edge嗎?沒問題,你可以在iOS上下載Edge,你所有的密碼、書簽和標簽都在那裏。生態系統集成,完美!

雖然這聽起來很棒,但它也將瀏覽器簡化為不同的用戶界面。

為什麼這很重要?

瀏覽器最重要的是渲染引擎。用戶界面需要在瀏覽器裏才能展示,但瀏覽器不能從中礙事。

即使蘋果也認為用戶界面渲染應該盡可能的快。蘋果在 iOS 15 測試版中對 Safari 進行的早期實驗並符合這個理念,導致一些蘋果專家例如Marco Arment, Frederico ViticciJohn Gruber 提出了一些非常直言不諱的批評。盡管如此,蘋果是對的,因為用戶想瀏覽網頁,只能使用瀏覽器。

而這正是 iOS 上其他瀏覽器無法創新的地方,他們必須使用與平臺上其他瀏覽器相同的渲染引擎。

所以如果你想使用新的 WEB 標准?需要等到蘋果在WebKit中實現它。如果有 bug 引發了問題?等到蘋果修複它並發布新版本的iOS。

這就是問題所在。

標准支持和推動 WEB 平臺發展

即使我創建了一個HTML5test網站,我也不會拿出分數來說明Safari比其他瀏覽器得分更低。但願如此,因為事實不是這樣。這個網站已經 5 年沒有更新了,Safari 支持幾乎所有5年前的 WEB 標准。

問題要複雜得多。蘋果對 WEB 的看法和其他瀏覽器存在根本區別。

很容易回想到類似的之前穀歌不認真對待隱私的問題,因為他們也是一家廣告公司。 蘋果只賣硬件。 不,不是這樣。

這同樣適用於蘋果希望從 App Store 中獲得約 30% 至 15% 的收入,讓 WEB 變得更糟,迫使用戶改用APP,並從中獲得利益。 我一點也不相信。

Safari 和 Chrome 團隊都希望讓 WEB 更安全,並努力改進 WEB 但是他們對 WEB 應該是什麼樣的是有不同的看法的。

穀歌專注於通過 提高 WEB 的能力來改善 WEB 擴展 WEB 的能力,超越今天的可能性。 這也意味著允許它與本地應用程序競爭,安卓團隊肯定並不總是同意這一點。

Safari 似乎專注於 改進 WEB讓它更安全、更快、更漂亮。如果你想要更多,你可以使用一個應用程序。

我並不是說蘋果的做法是錯誤的。蘋果正在做的事情也很重要,我贊揚蘋果在改善 WEB 隱私方面所做的工作。

但這不可能是唯一的優先事項。想象一下,如果20年前每個瀏覽器都采取這種方法,WEB 會是什麼樣子。

事實上,不要想象這一切。回想一下Internet Explorer 6;這就是20年前的 WEB 。我不是說 Internet Explorer 6 是一個糟糕的瀏覽器。它在2001年是一個偉大的瀏覽器。但是就像Internet Explorer 6 一樣,如果你停止創新,你就落後了。這導致了Internet Explorer的衰落。其他瀏覽器確實通過創新變得更好,而Internet Explorer變得無關緊要。盡管微軟多年來一直試圖趕上甚至後面嘗試使用Edge來追趕,最終還是失敗了,Edge現在使用 Chromium 作為渲染引擎

在過去的20年裏,我們花了大量的努力和創新才變成今天的樣子:新的應用編程接口、新的標准、新的功能。具有諷刺意味的是,一個更强大的 WEB 的推動最初來自Safari和WebKit渲染引擎。WebKit 是新貴,它改變了一切,並為 WEB 增加了許多有用的新功能。

但時代變了。Safari 已經落後很難跟上 WEB 平臺的發展方向。我不是在說一些只有Chromium才實現的奇异功能。即使是其他瀏覽器中適當的標准和廣泛支持的功能也可能需要數年才能在Safari中出現。

Web 開發人員的口頭禪是“Safari 是新的 IE”。可悲的是,它已經有一段時間了

不幸的是,與 Internet Explorer 不同的是,在iOS上用戶不能簡單地選擇使用其他瀏覽器。嗯,他們可以,但正如我們剛剛看到的,他們只是偽裝的 Safari。

所以不僅僅是一個瀏覽器落後了。iOS上的所有瀏覽器都落後了。iOS上的整個 WEB 都落後了。iOS已經變得如此重要,以至於整個 WEB 平臺都被阻礙了

正如開發人員對因為對長期支持 Internet Explorer 6感到沮喪一樣,他們也因為必須支持Safari而感到沮喪。

更令人沮喪的是蘋果最近發錶的一些聲明。在訴訟和監管機構的壓力下,蘋果為 App Store 的封閉性質辯護,稱 WEB 是構建原生應用的合適替代品。你不必遵守應用商店的規則;你也可以創建 WEB 應用。

同時,他們對實現允許 Web 應用程序與原生應用程序競爭的功能不感興趣,讀到這有點傷人。

漫長的等待

不幸的是,對開發人員來說,讓事情複雜化的不僅僅是缺少功能。令人沮喪的一個主要原因是突然出現的小 Bug 和錯誤。

現在,我不是說 Safari 比其他瀏覽器有更多的錯誤。每個瀏覽器都有錯誤。然而,當錯誤出現時,最重要的是問題修複的速度有多快。我要說的是,與其他瀏覽器相比,向用戶推出錯誤修複需要更長的時間。

一個關於indexedDB的嚴重錯誤為例。錯誤的技術細節並不重要,但時間線很重要。這個錯誤是在5月24日發布的iOS 14.6中引入的。它在6月2日被報告並很快修複。到目前為止,一切都很好。然後直到7月19日iOS 14.7發布才向用戶推出此功能。在此期間,indexedDB 在Safari中實際上是不可用的,你的客戶抱怨你的 WEB 應用程序壞了,你應該修複它。

任何其他瀏覽器都會立即發布錯誤修複。他們可以在幾天內而不是幾周內開始推出修複程序,因為他們的瀏覽器是獨立於操作系統推出的。

但Safari或iOS上的任何其他瀏覽器不是這樣;相反,你必須等到 iOS 版本中包含該修複程序,並且根據該版本的發布時間,它甚至可能不會發布即將發布的版本。你甚至不知道它是否會被包含,因為“蘋果不對未來的版本發錶評論”。

大多數這些問題並非源於 Safari 團隊。我很確定他們會喜歡更快地發布修複程序。這是iOS平臺的問題。但話雖如此,對於 Safari 和 iOS 上的其他瀏覽器來說,這仍然是一個問題。

所有瀏覽器都是平等的,但有些更平等

在這篇文章的開頭,我提到Safari也使用WebKit。這是真的。但是Safari和其他瀏覽器的最大區別在於Safari可以自由地在用戶界面和渲染引擎上競爭。如果他們想實現一個新的標准或功能,他們可以自由地這樣做。其他瀏覽器必須等待蘋果是否以及何時實現一個特定的功能時,蘋果可以隨時添加他們想要的任何東西。這不是公平競爭。

更糟糕的是,WebView和Safari系統在標准支持上存在差异,有時功能首先在Safari實現,但在一兩個版本後才會出現在WebView中。

最近,基於 WEB 的視頻通信出現了一個問題。一個允許瀏覽器訪問手機前置攝像頭的 WEB 標准在Safari中得到了一段時間的支持,但在 WEB 視圖中卻沒有。所以如果你想使用任何形式的基於 WEB 的視頻聊天,你必須使用Safari。截至iOS14.5,這個問題已經得到解决。

幾年前一個更著名的例子是,Apple 拒絕允許第三方瀏覽器使用他們更快的 Nitro 引擎運行 JavaScript。這涉及到一些真正的安全問題,因為當時 WebView 在與應用程序相同的進程中運行,允許 Nitro 意味著允許應用程序運行任意代碼。iOS 上的一大禁忌。但當然,Safari 沒有這些限制。最後,他們用一個全新的 WebView 替換了舊的 WebView,它在自己的進程中運行渲染引擎,完全避免了這個問題。

他們幸運地解决了這兩個問題。對他們和依賴這些功能的瀏覽器來說都很好。此外,Safari 團隊似乎有充分的理由不將這些特定功能推出到 WebView,直到他們能够正確地這樣做。

某些功能可能與 Safari 應用程序或 Apple 生態系統高度集成。因此,將該功能也推廣到 WebView 是沒有意義的。

但無論如何,蘋果不受自己規則的約束,可以自由創新,而其他人則不能。

iOS 上的所有瀏覽器都是平等的,但 Safari 更平等。

那麼其他瀏覽器能做什麼呢?

瀏覽器可以做兩件事來解决這個問題。不幸的是,兩者從一開始就注定了。

正如我所提到的,WebKit 是開源的,其他瀏覽器制造商可以投入時間和金錢來實現他們想要的功能。如果該功能被接受並符合 Apple 對網絡的願景,那麼它很有可能會被包含在 Safari 的下一個版本中——無論何時。

問題在於,這增加了使用其他瀏覽器改進 Safari 的負擔。這不是現實世界的運作方式。

即使有大筆資金的大型瀏覽器供應商選擇為團隊提供一個,也不能保證 Apple 會在 Safari 中提供該功能。即使在今天,WebKit 仍被多方使用和開發,因此,WebKit 支持許多 Safari 未包含的功能。

我並不是說他們會出於惡意或由於“非發明在這裏”綜合症而忽略這些貢獻。但是因為不同的願景,他們對於網絡平臺有著不同的看法。

假裝直到你打破它

可以工作的一件事是停止尋找解决方案的 WebKit,而是 WebView 本身。瀏覽器可以在 WebView 中插入 JavaScript,並且 JavaScript 可以向瀏覽器應用程序發送消息。這有點老套,但您可以創建一個在頁面加載時自動插入的 polyfill,假裝支持該功能。如果該功能需要,該 polyfill 甚至可以與瀏覽器應用程序對話並告訴它執行本機代碼。

這就是 Cordova 和 Capacitor 應用程序的工作方式。他們運行 WebView 並提供與應用程序本機端通信的 API,以支持瀏覽器通常永遠不會支持的功能。瀏覽器也可以使用這種技術。

這不僅僅是一個理論。在 Apple 在 Safari 中支持它之前,Chrome 使用它在 iOS 上提供 PaymentRequest 支持App Store 中甚至還有一些特定於功能的瀏覽器提供 WebBluetooth 或 WebMidi 支持。

但就像我說的。它很笨拙,隨時可能不工作。並且某些功能不能被 polyfill。

當然,作為用戶,如果瀏覽器能更多地使用這種技術為 iOS 帶來新的網絡平臺功能,我會很高興。但我理解為什麼瀏覽器會猶豫這樣做。

前景黯淡

那麼真正解决這些問題的方法是什麼?我們如何讓瀏覽器不僅在外觀上而且在網絡平臺功能上競爭?

只有一個合適的解决方案:Apple 需要向具有其他渲染引擎的瀏覽器開放他們的 App Store。廢弃規則 2.5.6 並允許 iOS 上的其他瀏覽器並讓它們真正參與競爭。盡管 Apple 被迫在某些 App Store 規則上妥協,但我對這種情况發生的希望不大。

這就是為什麼我認為市場監管機構需要對此進行調查。Apple 聲稱 Web 是 App Store 的合適替代品,因此監管機構應該接受他們的說法並確保它成為現實

版权声明
本文为[翟夢男]所创,转载请带上原文链接,感谢
https://cdmana.com/2021/11/20211125170645188L.html

Scroll to Top