greatzelda 寫:
如果以extension來個性化是fx的優點,那chrome也有這個啦,但速度差很多
試想想,大家也有基本常用的extension,但速度上是天壤之別,相信用家會選擇吧
的確，能用 extension 來自訂是 fx 一個無可取代的優點，
你要說 chrome 也有 extension，沒錯，但事實上，到目前為止 chrome 的 extension 架構還在發展中...
chrome 的 extension 架構目前看來，要對應的話，它其實跟 fx 開發中的 Jetpack 專案比較相似:
也就是官方預先提供一組 API 來供 extension 使用，所以 extension 能做的就被限制在這些 API 提供操控的範圍。
重點是: 這些 API 還在開發中...所以目前開放出來的部分所能做到的事，跟 fx 完全不能比。
可能要先了解一下 fx 的 extension 架構，fx 這邊 extension 的狀況是這樣:
簡單來講 fx 的"整個使用者介面"，都是透過一個叫 XUL 的程式語言架構來實作，
這個 XUL 其實本身是"未經編譯過的程式原始碼"檔案，也就是每當 fx 執行時，才去編譯然後執行並展現出來。
打從一開始 fx 被創造出來的時候，它就是用 XUL 來打造"整個" fx 的使用者介面...
所以有這點概念的話，就知道 fx 的整體速度要贏過 chrome 這種原生介面就是編譯過的程式，其實不太可能。
然而，卻也因此 fx 擁有了 "功能與介面自訂性高" 這個極大的特點。
因為... fx 的整個使用者介面，就...全部"直接是原始碼"啊，所以怎麼運作全都看的到...
加上 fx 允許 extension 執行時期動態修改程式碼的機制，這樣 extension 就能完全操控 fx 的使用者介面。
"想的到的功能，都可以透過 extension 來實現" 這個特點，就是目前 chrome 的 extension 遠遠不及的部分。
當然，這並不是說 fx 的 extension 架構就比較好，目前 fx 的 extension 架構也有它自己的問題...
舉個例子:
1.
由於 fx 的整個使用者介面，都開放給 extension 操控，所以每當 fx 大改的時候，
某個 extension 所操控的介面上的東西，有可能因為被 fx 改掉，而造成 fx 升級後 extension 運作不正常。
這個就是每當 fx 大改升級時，十分讓使用者頭疼的問題... "升級後一堆 extension 不能用了"
而 extension 作者也因此必須一直追著 fx 版本的更新跑。
2.
由於所有的 extension 都有操控同一個介面的能力，要實現這個，
目前的方式就是所有 extension 的程式碼，在 fx 啟動後，全都混在一個大缸裡...
而 fx 的核心，其實並沒有好的辦法可以控管各個 extension，所以 extension 彼此間會衝突一直是個常見的問題。
那...這問題難道無解嗎??
嗯，是有一個辦法:
那就是，用一道牆隔開 extension 跟 fx 的使用者介面...
這樣對 extension 來說，只要窗口沒變，就不用去管 fx 自己在裡面更新什麼東西，
在外頭的 extension 也就不再需要一直追著 fx 版本更新跑。
換句話說...就是跟 chrome 的 extension 架構一樣，提供一套 API 讓 extension 來用...
只要你的 extension 是用這套 API 來開發，那麼往後就不用一直追著 fx 的版本做修改，
而且因為 fx 對於用這個 API 的 extension 終於有辦法主動控管了，所以也有了一些額外的好處。
例如: 安裝、反安裝 extension 不用重開 fx。
是的...這就是 Jetpack 這個專案正在努力的目標...
Jetpack 面臨的問題跟現在的 chrome 一樣: 開放的 API 決定了 extension 能做的事情有多少。
雖然目前"能做的事太少"，但隨著 API 逐漸豐富起來，此缺點是可以逐漸改善的，但這得花時間...
現階段 chrome 的 extension 開發者，得先看 API 可否支援，來實現其創意...
而 fx 的 extension 開發者，則可以有更自由的選擇:
如果想做的事，可以用 Jetpack API 來達成，那就再好不過，不行的話，那還是可以用舊有的方法來達成...
登入
註冊
問答集
搜尋
