標籤: 網頁設計公司

最近的數據显示，Chrome在2020年4月的市場份額達到了70%左右，把微軟的Edge和Firefox遠遠甩在身後，毫無疑問，Chrome贏得了第二次遊覽器之戰，成為新一代王者。 

 

Chrome的第一版於2008年推出，當時微軟的IE瀏覽器幾乎佔到了60%的份額，Firefox緊隨其後，佔據了大概30%，Chrome在2008年僅占0.3%。 

十年以後Chrome就主導了瀏覽器的市場， 這一切是怎麼發生的？ 

我們先來回顧一下第一次瀏覽器之戰，交戰的雙方是Netscape的Navigator瀏覽器和微軟的IE， Netscape佔據着先發優勢，IE則背靠Windows這棵大樹，雙方你來我往，戰事極為精彩，競爭帶來了技術進步，像JavaScript、DHTML、CSS、XMLHttpRequest等各種技術層出不窮。 

IE4成為這場戰爭的轉折點，因為它被集成到了Windows當中， 開箱即用，免費，誰還會去額外下載安裝收費的Netscape呢？  

Netscape從此潰不成軍，IE贏得了最後的勝利，從這張圖中可以清楚地看出IE和Netscape之間此消彼長的勢頭。 

 

IE的勝利也結束了Web瀏覽器的快速創新，早期的IE是积極進取的，比如AJAX的基石XMLHttpRequest就是IE率先提出來，並且發揚光大的。 

可是一旦垄斷形成，微軟就不思進取，不想更新了，2001年微軟發布IE6以後，在長達5年的時間里，IE居然沒有新版本發布！ 

很多年輕的程序員沒有經歷過被IE支配的“恐懼”，那個時候開發網頁，必須要保證在IE6上能夠運行，否則你絕對活不了。巔峰時期IE6曾經達到過90%多的恐怖佔有率， 很多國企，內部系統都是基於IE6。 

雖然Netscape的瀏覽器戰敗，卻沒有因為死亡，Netscape把Navigator的代碼開源，捐給了非盈利的Mozilla基金會。在這裏Netscape幾經輾轉，終於在2004年涅槃重生，變身為著名的Firefox。 

 

我現在還記得第一次看到FireFox時的感受：非常輕薄！速度飛快！作為開發人員，我迅速就拋棄了老舊不堪的IE， 把Firefox作為主力的瀏覽器。 

Firefox也不負眾望，在此後的幾年中穩步上升，到2009年達到了30%多的佔有率，隱隱有成為下一個霸主的潛質。 

可是另外一個可怕的對手出現了，Google在2008年推出了一個叫做Chrome的瀏覽器，這個時候iPhone上市不到一年，Windows7剛剛面世，IE依然是最流行的瀏覽器。 

但是Google卻看到了不一樣的東西，它們認為現在的互聯網和10幾年前大不相同了，原來只是web pages，現在到處是applications，而瀏覽器的本質卻沒有變化。Google覺得自己有責任改變， 這幾幅漫畫講述了Google要推出Chrome的根本原因： 

 

 此時的Web已經進入Web2.0時代，像Google Map和GMail這樣的應用迫切需要瀏覽器能夠快速地裝載頁面，快速地執行JavaScript。 

Google下定決心，從零開始設計一個滿足現代Web應用的瀏覽器， 瀏覽器不僅僅是一個瀏覽網頁的工具，而是一個新的平台，在此之上可以在線完成各種事情，這種深刻的洞察力將給Google Chrome帶來極大的成功。 

Google給新瀏覽器定下的目標是：穩定，快速，安全，好用，開源。財大氣粗的它組建了一支豪華團隊來開發Chrome , 並且從Firefox挖走了好幾員幹將，如Ben Goodger，這可是Firefox的主力開發。 

與IE和Firefox相比，Chrome的一大優勢就是拋棄了遺留代碼的包袱，從頭開始設計，開發人員可以盡情地施展才華，他們帶來了兩個重要的創新： 

1. 在很早的時候就確定下了“沙箱”的機制：每個Tab頁都運行在自己的進程中，互不影響，充分利用多核。 

2. 開發了強勁的JavaScript執行引擎 V8，讓Web應用迅速地執行JavaScript代碼。 

2008年9月，Chrome推出Beta版，9個月後，即獲得3000萬用戶 

2009年12月，推出擴展程序庫，讓用戶安裝第三方插件，生態迅速繁榮。 

2010年，推出Web 應用商店。 

2012年2月，Chrome發布了Android版本， 6月推出iOS版本，此時市場份額達到30%以上 

2013年，為了對第三方的惡意擴展程序進行控制，Google要求所有的擴展必須託管在應用商店中 

……

 

一系列措施讓Chrome迅速蠶食了Firefox和IE的市場，從這幅圖可以清晰地看出IE（藍色線條）的沒落和Chrome(綠色線條）的崛起。

 

 

微軟豈會就此認輸？在這段時間內相繼推出IE7, IE8, IE9，IE10 , IE 11, 但是遺留的包袱讓它步履維艱，它那緩慢的速度經常成為大家調侃的對象： 

 

到了Windows 10 ，微軟另起爐灶，推出新的瀏覽器Edge，但也難挽敗局。 

微軟新CEO納德拉上台以後，一反原來封閉的形象，擁抱開源。2018年底，微軟宣布將會採用Google開源的Chromium為核心來構建Edge瀏覽器，從此Microsoft Edge和Google Chrome算是同源了，以後發展如何，我們拭目以待。 

Chome登上王位以後，對Google帶來了巨大的好處，因為Google本身提供了很多極為Web的服務：GMail, Google Map , Youtube, Google Gocs, Google Earth….  現在Google把瀏覽器端和服務器端都掌握了，那修改一下中間的協議也不算什麼了，對用戶來說，反正背後的協議也看不到，只要能變快就行。 

Google可以用Chrome試驗各種新協議，於是我們看到它對HTTP1.1動手，做了一個叫做SPDY協議的實驗，非常成功，成為了HTTP 2的基礎。然後又對傳輸層協議開刀，搞出了一個新的傳輸層協議QUIC，解決了TCP了諸多問題，有望把TCP給替換掉。基於QUIC，新的HTTP協議，即HTTP/3正在制定當中。 

尾聲

 Chrome的成功主要是因為Google深刻的洞察力，他們看到了Web未來的趨勢，迅速推出產品擁抱了這種趨勢。 

Chrome如今佔據了和當年的IE6一樣的主導地位， 一些批評聲音出現了，The verge有一篇報道說Google的很多Web應用都提倡“使用Chrome瀏覽效果最佳”， “Google Meet、Allo、YouTube TV、Google Earth 和 YouTube Studio Beta 都會阻止 Windows 10 系統的默認瀏覽器 Microsoft Edge 訪問它們，並指引用戶下載 Chrome 瀏覽器” ，“使用非Chrome瀏覽器訪問google.com會被提醒三次下載Chrome。”

 

 

Chrome最終會走向何方？你覺得Chrome會像IE那樣停滯不前嗎？ 

參考資料：

https://en.wikipedia.org/wiki/Browser_wars

https://usefyi.com/chrome-history/

https://www.theverge.com/2018/1/4/16805216/google-chrome-only-sites-internet-explorer-6-web-standards

https://www.google.com/googlebooks/chrome/big_00.html

 

更多精彩文章，盡在碼農翻身

微服務把我坑了

如何降低程序員的工資？

程序員，你得選准跑路的時間！

兩年，我學會了所有的編程語言！

一直CRUD，一直996，我煩透了，我要轉型

字節碼萬歲！

上帝託夢給我說：一切皆文件

Javascript: 一個屌絲的逆襲

Node.js :我只需要一個店小二

我是一個線程

TCP/IP之大明郵差

一個故事講完Https

CPU 阿甘

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※教你寫出一流的銷售文案?

說明：設計模式系列文章是讀劉偉所著《設計模式的藝術之道(軟件開發人員內功修鍊之道)》一書的閱讀筆記。個人感覺這本書講的不錯，有興趣推薦讀一讀。詳細內容也可以看看此書作者的博客https://blog.csdn.net/LoveLion/article/details/17517213

工廠模式是最常用的一類創建型設計模式，通常我們所說的工廠模式是指工廠方法模式，它也是使用頻率最高的工廠模式。簡單工廠模式是工廠方法模式的“小弟”，它不屬於GoF23種設計模式，但在軟件開發中應用也較為頻繁，通常將它作為學習其他工廠模式的入門。此外，工廠方法模式還有一位“大哥”——抽象工廠模式。這三種工廠模式各具特色，難度也逐個加大，在軟件開發中它們都得到了廣泛的應用，成為面向對象軟件中常用的創建對象的工具。

簡單工廠模式

簡單工廠模式並不屬於GoF 23個經典設計模式，但通常將它作為學習其他工廠模式的基礎，它的設計思想很簡單。

模式定義

簡單工廠模式(Simple Factory Pattern)：定義一個工廠類，它可以根據參數的不同返回不同類的實例，被創建的實例通常都具有共同的父類。因為在簡單工廠模式中用於創建實例的方法是靜態(static)方法，因此簡單工廠模式又被稱為靜態工廠方法(Static Factory Method)模式，它屬於類創建型模式。

簡單工廠模式的要點在於：當你需要什麼，只需要傳入一個正確的參數，就可以獲取你所需要的對象，而無須知道其創建細節。

模式結構圖

簡單工廠模式結構圖如下所示：

模式偽代碼

在使用簡單工廠模式時，首先需要對產品類進行重構，不能設計一個包羅萬象的產品類，而需根據實際情況設計一個產品層次結構，將所有產品類公共的代碼移至抽象產品類，並在抽象產品類中聲明一些抽象方法，以供不同的具體產品類來實現，典型的抽象產品類代碼如下所示：

public abstract class Product {
    // 所有產品的公共屬性

    // 所有產品類的公共業務方法
    public void methodSame() {
        //公共方法的實現
    }

    // 聲明抽象業務方法
    public abstract void methodDiff();
}

在具體產品類中實現了抽象產品類中聲明的抽象業務方法。

public class ConcreteProduct extends Product {
    @Override
    public void methodDiff() {
        // 具體產品業務方法的實現
    }
}

簡單工廠模式的核心是工廠類，在沒有工廠類之前，客戶端一般會使用new關鍵字來直接創建產品對象，而在引入工廠類之後，客戶端可以通過工廠類來創建產品，在簡單工廠模式中，工廠類提供了一個靜態工廠方法供客戶端使用，根據所傳入的參數不同可以創建不同的產品對象，典型的工廠類代碼如下所示:

public class Factory {
    //靜態工廠方法
    public static Product getProduct(String arg) {
        Product product = null;
        if (arg.equalsIgnoreCase("A")) {
            product = new ConcreteProductA();
            //初始化設置product
        } else if (arg.equalsIgnoreCase("B")) {
            product = new ConcreteProductB();
            //初始化設置product
        }
        return product;
    }
}

在客戶端代碼中，我們通過調用工廠類的工廠方法即可得到產品對象，典型代碼如下所示：

public class Client {
    public static void main(String[] args) {
        Product product;
        product = Factory.getProduct("A"); //通過工廠類創建產品對象
        product.methodSame();
        product.methodDiff();
    }
}

模式簡化

有時候，為了簡化簡單工廠模式，我們可以將抽象產品類和工廠類合併，將靜態工廠方法移至抽象產品類中，如下圖所示。

客戶端可以通過產品父類的靜態工廠方法，根據參數的不同創建不同類型的產品子類對象，這種做法在JDK等類庫和框架中也廣泛存在。
比如：java.nio.charset.Charset

public abstract class Charset {

    /**
     * Returns a charset object for the named charset.
     */
    public static Charset forName(String charsetName) {
        java.nio.charset.Charset cs = lookup(charsetName);
        if (cs != null)
            return cs;
        throw new UnsupportedCharsetException(charsetName);
    }
}

模式小結

簡單工廠模式提供了專門的工廠類用於創建對象，將對象的創建和對象的使用分離開，它作為一種最簡單的工廠模式在軟件開發中得到了較為廣泛的應用。

使用場景：

1. 工廠類負責創建的對象比較少，由於創建的對象較少，不會造成工廠方法中的業務邏輯太過複雜。
2. 客戶端只知道傳入工廠類的參數，對於如何創建對象並不關心。

工廠方法模式

簡單工廠模式雖然簡單，但存在一個很嚴重的問題。當系統中需要引入新產品時，由於靜態工廠方法通過所傳入參數的不同來創建不同的產品，這必定要修改工廠類的源代碼，將違背“開閉原則”，如何實現增加新產品而不影響已有代碼？工廠方法模式應運而生。

模式定義

在工廠方法模式中，我們不再提供一個統一的工廠類來創建所有的產品對象，而是針對不同的產品提供不同的工廠，系統提供一個與產品等級結構對應的工廠等級結構。工廠方法模式定義如下：

工廠方法模式(Factory Method Pattern)：定義一個用於創建對象的接口，讓子類決定將哪一個類實例化。工廠方法模式讓一個類的實例化延遲到其子類。工廠方法模式又簡稱為工廠模式(Factory Pattern)，又可稱作虛擬構造器模式(Virtual Constructor Pattern)或多態工廠模式(Polymorphic Factory Pattern)。工廠方法模式是一種類創建型模式。

模式結構圖

工廠方法模式提供一個抽象工廠接口來聲明抽象工廠方法，而由其子類來具體實現工廠方法，創建具體的產品對象。工廠方法模式結構如圖所示:

在工廠方法模式結構圖中包含如下幾個角色：

• Product（抽象產品）：它是定義產品的接口，是工廠方法模式所創建對象的超類型，也就是產品對象的公共父類。
• ConcreteProduct（具體產品）：它實現了抽象產品接口，某種類型的具體產品由專門的具體工廠創建，具體工廠和具體產品之間一一對應。
• Factory（抽象工廠）：在抽象工廠類中，聲明了工廠方法(Factory Method)，用於返回一個產品。抽象工廠是工廠方法模式的核心，所有創建對象的工廠類都必須實現該接口。
• ConcreteFactory（具體工廠）：它是抽象工廠類的子類，實現了抽象工廠中定義的工廠方法，並可由客戶端調用，返回一個具體產品類的實例。

模式偽代碼

與簡單工廠模式相比，工廠方法模式最重要的區別是引入了抽象工廠角色，抽象工廠可以是接口，也可以是抽象類或者具體類，其典型代碼如下所示：

public interface Factory {
    Product factoryMethod();
}

在抽象工廠中聲明了工廠方法但並未實現工廠方法，具體產品對象的創建由其子類負責，客戶端針對抽象工廠編程，可在運行時再指定具體工廠類，具體工廠類實現了工廠方法，不同的具體工廠可以創建不同的具體產品，其典型代碼如下所示：

public class ConcreteFactory implements Factory {
    @Override
    public Product factoryMethod() {
        return new ConcreteProduct();
    }
}

在客戶端代碼中，只需關心工廠類即可，不同的具體工廠可以創建不同的產品，典型的客戶端類代碼片段如下所示:

public class Client {
    public static void main(String[] args) {
        // 確定是哪個工廠可得到產品
        Factory factory = new ConcreteFactory();
        // 獲取產品
        Product product = factory.factoryMethod();
    }
}

模式簡化

有時候，為了進一步簡化客戶端的使用，還可以對客戶端隱藏工廠方法，此時，在工廠類中將直接調用產品類的業務方法，客戶端無須調用工廠方法創建產品，直接通過工廠即可使用所創建的對象中的業務方法。

// 改為抽象類
public class AbstractFactory {
    // 在工廠類中直接調用產品類的業務方法
    public void productMethod() {
        Product product = this.createProduct();
        product.method();
    }

    public abstract Product createProduct();
}

通過將業務方法的調用移入工廠類，可以直接使用工廠對象來調用產品對象的業務方法，客戶端無須直接調用工廠方法，在客戶端並不關心Product細節的情況下使用這種設計方案會更加方便。

模式小結

工廠方法模式能夠讓工廠可以自主確定創建何種產品對象，而如何創建這個對象的細節則完全封裝在具體工廠內部，用戶只需要關心所需產品對應的工廠，無須關心創建細節，甚至無須知道具體產品類的類名。基於工廠角色和產品角色的多態性設計是工廠方法模式的關鍵。

抽象工廠模式

工廠方法模式通過引入工廠等級結構，解決了簡單工廠模式中工廠類職責太重的問題，但由於工廠方法模式中的每個工廠只生產一類產品，可能會導致系統中存在大量的工廠類，勢必會增加系統的開銷。此時，我們可以考慮將一些相關的產品組成一個產品族，由同一個工廠來統一生產，這就是我們本文將要學習的抽象工廠模式的基本思想。

這裏我斗膽舉個例子來說明一下吧，如果不恰當歡迎指出。

眾所周知，國內知名的電器廠有海爾、海信(姑且就認為是2個)，電器廠會生產電視機、電冰箱、空調(姑且就認為是3種產品)。

• 使用工廠方法模式：工廠方法模式中每個工廠只生產一類產品，那麼就必須要有海爾電視機廠、海爾電冰箱廠、海爾空調廠、海信電視機廠、海信電冰箱廠、海信空調廠
• 使用抽象工廠模式：抽象工廠中每個工廠生產由多種產品組成的”產品族”，那麼就只需要有海爾工廠、海信工廠就夠了，每個工廠可生產自家的電視機、電冰箱、空調。

由此看出使用抽象工廠模式極大地減少了系統中類的個數。

模式定義

抽象工廠模式為創建一組對象提供了一種解決方案。與工廠方法模式相比，抽象工廠模式中的具體工廠不只是創建一種產品，它負責創建一族產品。抽象工廠模式定義如下：

抽象工廠模式(Abstract Factory Pattern)：提供一個創建一系列相關或相互依賴對象的接口，而無須指定它們具體的類。抽象工廠模式又稱為Kit模式，它是一種對象創建型模式。

模式結構圖

在抽象工廠模式中，每一個具體工廠都提供了多個工廠方法用於產生多種不同類型的產品，這些產品構成了一個產品族，抽象工廠模式結構如圖所示：

在抽象工廠模式結構圖中包含如下幾個角色：

• AbstractFactory（抽象工廠）：它聲明了一組用於創建一族產品的方法，每一個方法對應一種產品。
• ConcreteFactory（具體工廠）：它實現了在抽象工廠中聲明的創建產品的方法，生成一組具體產品，這些產品構成了一個產品族，每一個產品都位於某個產品等級結構中。
• AbstractProduct（抽象產品）：它為每種產品聲明接口，在抽象產品中聲明了產品所具有的業務方法。
• ConcreteProduct（具體產品）：它定義具體工廠生產的具體產品對象，實現抽象產品接口中聲明的業務方法。

模式偽代碼

在抽象工廠中聲明了多個工廠方法，用於創建不同類型的產品，抽象工廠可以是接口，也可以是抽象類或者具體類，其典型代碼如下所示：

public abstract class AbstractFactory {

    public abstract AbstractProductA createProductA();

    public abstract AbstractProductB createProductB();

    public abstract AbstractProductC createProductC();
}

具體工廠實現了抽象工廠，每一個具體的工廠方法可以返回一個特定的產品對象，而同一個具體工廠所創建的產品對象構成了一個產品族。對於每一個具體工廠類，其典型代碼如下所示：

public class ConcreteFactory1 extends AbstractFactory {
    @Override
    public AbstractProductA createProductA() {
        return new ConcreteProductA1();
    }

    @Override
    public AbstractProductB createProductB() {
        return new ConcreteProductB1();
    }

    @Override
    public AbstractProductC createProductC() {
        return new ConcreteProductC1();
    }
}

模式小結

如果一開始就學習抽象工廠模式估計很難理解為什麼這樣設計，按次序學習分析簡單工廠模式、工廠方法模式、抽象工廠模式基本就順理成章了。實際開發中，可能並不是照搬照套工廠模式三兄弟的偽代碼，大多會簡化其中的部分實現。本來學習設計模式就是重思想，學習如何用抽象類、接口、拆分、組合等將軟件解耦合，並增強系統可擴展性，這才是最關鍵的。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!