前言

    上篇文章我們演示了為Configuration添加Etcd數據源，並且了解到為Configuration擴展自定義數據源還是非常簡單的，核心就是把數據源的數據按照一定的規則讀取到指定的字典里，這些都得益於微軟設計的合理性和便捷性。本篇文章我們將一起探究Configuration源碼，去了解Configuration到底是如何工作的。

ConfigurationBuilder

    相信使用了.Net Core或者看過.Net Core源碼的同學都非常清楚,.Net Core使用了大量的Builder模式許多核心操作都是是用來了Builder模式，微軟在.Net Core使用了許多在傳統.Net框架上並未使用的設計模式，這也使得.Net Core使用更方便，代碼更合理。Configuration作為.Net Core的核心功能當然也不例外。
    其實並沒有Configuration這個類，這隻是我們對配置模塊的代名詞。其核心是IConfiguration接口，IConfiguration又是由IConfigurationBuilder構建出來的，我們找到IConfigurationBuilder源碼大致定義如下

public interface IConfigurationBuilder
{
    IDictionary<string, object> Properties { get; }

    IList<IConfigurationSource> Sources { get; }

    IConfigurationBuilder Add(IConfigurationSource source);

    IConfigurationRoot Build();
}

Add方法我們上篇文章曾使用過，就是為ConfigurationBuilder添加ConfigurationSource數據源，添加的數據源被存放在Sources這個屬性里。當我們要使用IConfiguration的時候通過Build的方法得到IConfiguration實例，IConfigurationRoot接口是繼承自IConfiguration接口的，待會我們會探究這個接口。
我們找到IConfigurationBuilder的默認實現類ConfigurationBuilder大致代碼實現如下

public class ConfigurationBuilder : IConfigurationBuilder
{
    /// <summary>
    /// 添加的數據源被存放到了這裏
    /// </summary>
    public IList<IConfigurationSource> Sources { get; } = new List<IConfigurationSource>();

    public IDictionary<string, object> Properties { get; } = new Dictionary<string, object>();

    /// <summary>
    /// 添加IConfigurationSource數據源
    /// </summary>
    /// <returns></returns>
    public IConfigurationBuilder Add(IConfigurationSource source)
    {
        if (source == null)
        {
            throw new ArgumentNullException(nameof(source));
        }
        Sources.Add(source);
        return this;
    }

    public IConfigurationRoot Build()
    {
        //獲取所有添加的IConfigurationSource里的IConfigurationProvider
        var providers = new List<IConfigurationProvider>();
        foreach (var source in Sources)
        {
            var provider = source.Build(this);
            providers.Add(provider);
        }
        //用providers去實例化ConfigurationRoot
        return new ConfigurationRoot(providers);
    }
}

這個類的定義非常的簡單，相信大家都能看明白。其實整個IConfigurationBuilder的工作流程都非常簡單就是將IConfigurationSource添加到Sources中，然後通過Sources里的Provider去構建IConfigurationRoot。

Configuration

通過上面我們了解到通過ConfigurationBuilder構建出來的並非是直接實現IConfiguration的實現類而是另一個接口IConfigurationRoot

ConfigurationRoot

通過源代碼我們可以知道IConfigurationRoot是繼承自IConfiguration，具體定義關係如下

public interface IConfigurationRoot : IConfiguration
{
    /// <summary>
    /// 強制刷新數據
    /// </summary>
    /// <returns></returns>
    void Reload();

    IEnumerable<IConfigurationProvider> Providers { get; }
}

public interface IConfiguration
{
    string this[string key] { get; set; }

    /// <summary>
    /// 獲取指定名稱子數據節點
    /// </summary>
    /// <returns></returns>
    IConfigurationSection GetSection(string key);

    /// <summary>
    /// 獲取所有子數據節點
    /// </summary>
    /// <returns></returns>
    IEnumerable<IConfigurationSection> GetChildren();
    
    /// <summary>
    /// 獲取IChangeToken用於當數據源有數據變化時，通知外部使用者
    /// </summary>
    /// <returns></returns>
    IChangeToken GetReloadToken();
}

接下來我們查看IConfigurationRoot實現類ConfigurationRoot的大致實現，代碼有刪減

public class ConfigurationRoot : IConfigurationRoot, IDisposable
{
    private readonly IList<IIConfigurationProvider> _providers;
    private readonly IList<IDisposable> _changeTokenRegistrations;
    private ConfigurationReloadToken _changeToken = new ConfigurationReloadToken();

    public ConfigurationRoot(IList<IConfigurationProvider> providers)
    {
        _providers = providers;
        _changeTokenRegistrations = new List<IDisposable>(providers.Count);
        //通過便利的方式調用ConfigurationProvider的Load方法，將數據加載到每個ConfigurationProvider的字典里
        foreach (var p in providers)
        {
            p.Load();
            //監聽每個ConfigurationProvider的ReloadToken實現如果數據源發生變化去刷新Token通知外部發生變化
            _changeTokenRegistrations.Add(ChangeToken.OnChange(() => p.GetReloadToken(), () => RaiseChanged()));
        }
    }

    //// <summary>
    /// 讀取或設置配置相關信息
    /// </summary>
    public string this[string key]
    {
        get
        {
            //通過這個我們可以了解到讀取的順序取決於註冊Source的順序，採用的是後來者居上的方式
            //后註冊的會先被讀取到，如果讀取到直接return
            for (var i = _providers.Count - 1; i >= 0; i--)
            {
                var provider = _providers[i];
                if (provider.TryGet(key, out var value))
                {
                    return value;
                }
            }
            return null;
        }
        set
        {
            //這裏的設置只是把值放到內存中去，並不會持久化到相關數據源
            foreach (var provider in _providers)
            {
                provider.Set(key, value);
            }
        }
    }

    public IEnumerable<IConfigurationSection> GetChildren() => this.GetChildrenImplementation(null);

    public IChangeToken GetReloadToken() => _changeToken;

    public IConfigurationSection GetSection(string key)
        => new ConfigurationSection(this, key);

    //// <summary>
    /// 手動調用該方法也可以實現強制刷新的效果
    /// </summary>
    public void Reload()
    {
        foreach (var provider in _providers)
        {
            provider.Load();
        }
        RaiseChanged();
    }

    //// <summary>
    /// 強烈推薦不熟悉Interlocked的同學研究一下Interlocked具體用法
    /// </summary>
    private void RaiseChanged()
    {
        var previousToken = Interlocked.Exchange(ref _changeToken, new ConfigurationReloadToken());
        previousToken.OnReload();
    }
}

上面展示了ConfigurationRoot的核心實現其實主要就是兩點

• 讀取的方式其實是循環匹配註冊進來的每個provider里的數據，是後來者居上的模式，同名key后註冊進來的會先被讀取到，然後直接返回
• 構造ConfigurationRoot的時候才把數據加載到內存中，而且為註冊進來的每個provider設置監聽回調

ConfigurationSection

其實通過上面的代碼我們會產生一個疑問，獲取子節點數據返回的是另一個接口類型IConfigurationSection，我們來看下具體的定義

public interface IConfigurationSection : IConfiguration
{
    string Key { get; }

    string Path { get; }

    string Value { get; set; }
}

這個接口也是繼承了IConfiguration，這就奇怪了分明只有一套配置IConfiguration，為什麼還要區分IConfigurationRoot和IConfigurationSection呢？其實不難理解因為Configuration可以同時承載許多不同的配置源，而IConfigurationRoot正是表示承載所有配置信息的根節點，而配置又是可以表示層級化的一種結構，在根配置里獲取下來的子節點是可以表示承載一套相關配置的另一套系統，所以單獨使用IConfigurationSection去表示，會顯得結構更清晰，比如我們有如下的json數據格式

{
  "OrderId":"202005202220",
  "Address":"銀河系太陽系火星",
  "Total":666.66,
  "Products":[
    {
      "Id":1,
      "Name":"果子狸",
      "Price":66.6,
      "Detail":{
          "Color":"棕色",
          "Weight":"1000g"
      }
    },
    {
      "Id":2,
      "Name":"蝙蝠",
      "Price":55.5,
      "Detail":{
          "Color":"黑色",
          "Weight":"200g"
      }
    }
  ]
}

我們知道json是一個結構化的存儲結構，其存儲元素分為三種一是簡單類型，二是對象類型，三是集合類型。但是字典是KV結構，並不存在結構化關係，在.Net Corez中配置系統是這麼解決的，比如以上信息存儲到字典中的結構就是這種

Key	Value
OrderId	202005202220
Address	銀河系太陽系火星
Products:0:Id	1
Products:0:Name	果子狸
Products:0:Detail:Color	棕色
Products:1:Id	2
Products:1:Name	蝙蝠
Products:1:Detail:Weight	200g

如果我想獲取Products節點下的第一條商品數據直接

IConfigurationSection productSection = configuration.GetSection("Products:0")

類比到這裏的話根配置IConfigurationRoot里存儲了訂單的所有數據，獲取下來的子節點IConfigurationSection表示了訂單里第一個商品的信息，而這個商品也是一個完整的描述商品信息的數據系統，所以這樣可以更清晰的區分Configuration的結構，我們來看一下ConfigurationSection的大致實現

public class ConfigurationSection : IConfigurationSection
{
    private readonly IConfigurationRoot _root;
    private readonly string _path;
    private string _key;

    public ConfigurationSection(IConfigurationRoot root, string path)
    {
        _root = root;
        _path = path;
    }

    public string Path => _path;

    public string Key
    {
        get
        {
            return _key;
        }
    }

    public string Value
    {
        get
        {
            return _root[Path];
        }
        set
        {
            _root[Path] = value;
        }
    }

    public string this[string key]
    {
        get
        {
            //獲取當前Section下的數據其實就是組合了Path和Key
            return _root[ConfigurationPath.Combine(Path, key)];
        }
        set
        {
            _root[ConfigurationPath.Combine(Path, key)] = value;
        }
    }
    
    //獲取當前節點下的某個子節點也是組合當前的Path和子節點的標識Key
    public IConfigurationSection GetSection(string key) => _root.GetSection(ConfigurationPath.Combine(Path, key));
    //獲取當前節點下的所有子節點其實就是在字典里獲取包含當前Path字符串的所有Key
    public IEnumerable<IConfigurationSection> GetChildren() => _root.GetChildrenImplementation(Path);
    public IChangeToken GetReloadToken() => _root.GetReloadToken();
}

這裏我們可以看到既然有Key可以獲取字典里對應的Value了，為何還需要Path？通過ConfigurationRoot里的代碼我們可以知道Path的初始值其實就是獲取ConfigurationSection的Key,說白了其實就是如何獲取到當前IConfigurationSection的路徑。比如

//當前productSection的Path是 Products:0
IConfigurationSection productSection = configuration.GetSection("Products:0");
//當前productDetailSection的Path是 Products:0:Detail
IConfigurationSection productDetailSection = productSection.GetSection("Detail");
//獲取到pColor的全路徑就是 Products:0:Detail:Color
string pColor = productDetailSection["Color"];

而獲取Section所有子節點
GetChildrenImplementation來自於IConfigurationRoot的擴展方法

internal static class InternalConfigurationRootExtensions
{
    //// <summary>
    /// 其實就是在數據源字典里獲取Key包含給定Path的所有值
    /// </summary>
    internal static IEnumerable<IConfigurationSection> GetChildrenImplementation(this IConfigurationRoot root, string path)
    {
        return root.Providers
            .Aggregate(Enumerable.Empty<string>(),
                (seed, source) => source.GetChildKeys(seed, path))
            .Distinct(StringComparer.OrdinalIgnoreCase)
            .Select(key => root.GetSection(path == null ? key : ConfigurationPath.Combine(path, key)));
    }
}

相信講到這裏，大家對ConfigurationSection或者是對Configuration整體的思路有一定的了解，細節上的設計確實不少。但是整體實現思路還是比較清晰的。關於Configuration還有一個比較重要的擴展方法就是將配置綁定到具體POCO的擴展方法，該方法承載在ConfigurationBinder擴展類了，由於實現比較複雜，也不是本篇文章的重點，有興趣的同學可以自行查閱，這裏就不做探究了。

總結

    通過以上部分的講解，其實我們可以大概的將Configuration配置相關總結為兩大核心抽象接口IConfigurationBuilder,IConfiguration，整體結構關係可大致表示成如下關係

    配置相關的整體實現思路就是IConfigurationSource作為一種特定類型的數據源，它提供了提供當前數據源的提供者ConfigurationProvider，Provider負責將數據源的數據按照一定的規則放入到字典里。IConfigurationSource添加到IConfigurationBuilder的容器中，後者使用Provide構建出整個程序的根配置容器IConfigurationRoot。通過獲取IConfigurationRoot子節點得到IConfigurationSection負責維護子節點容器相關。這二者都繼承自IConfiguration，然後通過他們就可以獲取到整個配置體系的數據數據操作了。

    以上講解都是本人通過實踐和閱讀源碼得出的結論，可能會存在一定的偏差或理解上的誤區，但是我還是想把我的理解分享給大家，希望大家能多多包涵。如果有大家有不同的見解或者更深的理解，可以在評論區多多留言。

歡迎掃碼關注我的公眾號 本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※新北清潔公司,居家、辦公、裝潢細清專業服務

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

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

※超省錢租車方案

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

摘要

      本文通過列舉歷史中出現的產品，梳理了模數轉換器在20世紀30年代~~20世紀80年代末的發展歷史。接下來，簡要介紹模數轉換器的原理、技術指標、分類和未來發展方向。最後，提供了一種自製3位FLASH型ADC的方法(該方法經過了作者的測試且價格在20元以下)。

 

參考文獻

    涉及到的數據手冊(eyg7)

    Flash ADC_Chapter 13 – Digital-Analog Conversion

    ZepToBars

    《Analog-Digital Conversion》 Chapter I Walt Kester

    《数字电子技術》第六版 康華光

    数字电子技術 西南石油大學課程中心

 

ADC的歷史

     世界上記載的第一個”純电子“的A/D轉換器於1939年被亞歷克·哈利·里夫斯(Alec Harley Reeves)發明，該設計的採樣率為6KSPS，分辨率為5位。

亞歷克·哈利·里夫斯設計的A/D轉換器原理圖，《Analog-Digital Conversion》 Chapter I Walt Kester

     1947年，鍺晶體管於貝爾實驗室誕生。

     1946年，ENIAC問世，現代数字計算機的鼻祖，為A/D的蓬勃發展做鋪墊。

     1948年，貝爾實驗室發明了5位、8KSPS的逐次逼近型A/D轉換器。

     得力於电子束編碼管技術，在1960年左右出現了12MSPS、9位的編碼器(A/D)。

 电子束編碼管原理圖，《Analog-Digital Conversion》 Chapter I Walt Kester

     1954年，硅晶體管於德州儀器誕生。

     1954年，伯納德·M·戈登(Bernard M. Gordon)發明了11位、50KSPS的基於真空管的A/D，這被認為是世界上第一個商業化的A/D轉換器。“Datrac”功率500W，售價8000~~9000美元。

伯納德·M·戈登發明的 “Datrac”，《Analog-Digital Conversion》 Chapter I Walt Kester

     1958/1959，集成電路問世，德州儀器(1958)，仙童半導體(1959)。

     1963~1965年，為了給美國軍方的雷達提供高速A/D，貝爾實驗室的John M. Eubanks和Robert C. Bedingfield研發了8位、10MSPS的A/D，其功率為150W、售價10000美元。

 John M. Eubanks和Robert C. Bedingfield研發的A/D，《Analog-Digital Conversion》 Chapter I Walt Kester

      1969年，Pastoriza公司利用分立元件製造了12位、10us、2.3W的逐次逼近型A/D樣機—-“ADC-12U”，售價800美元。

 “ADC-12U”原型機，《Analog-Digital Conversion》 Chapter I Walt Kester

     1978年，Paul Brokaw設計了第一個完整的單芯片ADC，型號為AD571，使用了雙極型工藝，參數為：10位、25us、SAR結構。同年，誕生了最具重要意義的SAR ADC–AD574。這時的A/D可以說開始走向現代。

AD571，源

AD571框圖，《Analog-Digital Conversion》 Chapter I Walt Kester

     1988年，Crystal Semiconductor推出了世界上第一個單芯片商業化的ε-Δ ADC–CSZ5316，參數：16位、20KSPS，可以用於語音處理。

     接下來的歷史中，各廠商不斷改進ADC的性能、推出更多不同用途的ADC。總而言之，就是讓ADC進入千家萬戶。

 

ADC的原理

     ADC(Analog to Digital Converter)是一類將模擬信號(連續信號)轉換為数字信號(離散信號)的器件，按原理可分為：并行比較型A/D轉換器(FLASH ADC)、逐次比較型A/D轉換器(SAR ADC)和雙積分式A/D轉換器(Double Integral ADC)。

     模擬信號，下圖中的ui(t)是一個輸入的模擬電壓信號，可以想象成從一個麥克風輸出的音頻信號。

     数字信號，現代計算機能夠處理的信號，表現為下圖中的“n位数字量輸出”。

     香農-奈奎斯特(Shannon & Nyquist)採樣定理規定，使恢復出的信號不失真的條件：採樣頻率大於原始信號頻率的兩倍，即 Fs >= 2Fi

      一個連續的電壓信號ui(t)通過一個由方波CPs控制的開關S之後施加到電容C上，由於電容兩端的電壓不會突變，可知在S斷開時C將維持ui(t)在開關斷開瞬間的電壓一段時間，直到開關S再次打開。這樣，一個模擬的電壓信號就轉換成了採樣展寬信號us(t)，其中CPs的頻率就是採樣頻率Fs。然後，由ADC的数字編碼電路將採樣展寬信號us(t)轉換成n位的数字量dn-1 : d0並輸出。

     通過上述步驟，一個連續的電壓信號就轉換成了n位的数字量，而實現該過程的器件叫做模擬-数字轉換器(ADC)。

AD轉換的一般原理，”数字电子技術”  SWPU

TLC5540I，8位、40MSPS、CMOS工藝的并行比較型A/D轉換器的版圖，https://zeptobars.com/,license: CC BY 3.0，未修改

 

 ADC的主要性能指標

     分辨率：ADC能分辨的最小電壓，通常用位數表示，例如：8位。一個n=8位的ADC，參考電壓為5V，則其能分辨的最小電壓為 5 / 2^n = 19.53mV

     轉換時間：ADC從控制信號到來開始，到輸出端得到穩定的数字信號所經歷的時間。

     轉換精度：ADC輸出的数字量所表示的模擬值與實際輸入的模擬量之間的偏差。

 

ADC的分類

     并行比較型A/D轉換器：這是本文嘗試構建的ADC，其由電阻分壓器、電壓比較器(運算放大器)、D觸發器和優先級編碼器構成。其原理簡單，將在後文介紹。

                            優點：1.轉換時間最短，其轉換周期為通過比較器、觸發器和優先級編碼器的時間總和(見下式)，這個數值通常很小。

T轉 = T比 + T寄 + T編

                            缺點：1.造價高昂，隨着分辨位數的提高，所需的元件幾乎按幾何級數增長，如：一個n位的并行比較型ADC，需要2^n – 1個比較器和2^n – 1個觸發器，假如n=12，那麼一共需要8190個比較器和觸發器！

                                    2.對集成電路的工藝要求很高。

                    常見的型號：AD9012，TTL工藝，分辨率為8位，採樣率為100MSPS，模擬輸入電壓範圍 -Vs~~+0.5V(Vs為芯片供電電壓)。

                                     AD9002，ECL工藝(射極耦合邏輯)，分辨率為8位，採樣率為150MSPS，模擬輸入電壓範圍 -Vs~~+0.5V(Vs為芯片供電電壓)。

                                     AD9020，TTL工藝，分辨率為10位，採樣率為60MSPS，雙極性模擬輸入(+-1.75V)。

3位并行比較型A/D轉換器原理圖，《数字电子技術》第六版 康華光

AD9012原理圖，Analog Devices 

AD9002原理圖，Analog Devices  

AD9020原理圖，Analog Devices 

1107PV2，蘇聯，8位、20MSPS，典型的并行比較型A/D轉換器的版圖，https://zeptobars.com/,license: CC BY 3.0，未修改

1107PV2，蘇聯，8位、20MSPS，典型的并行比較型A/D轉換器的比較器的版圖，https://zeptobars.com/,license: CC BY 3.0，未修改

 

     逐次比較型A/D轉換器：原理像天平，對輸入的模擬電壓信號與不同權值的電壓做多次比較，使得轉換所得的数字量在數值上不斷逼近輸入的模擬量。通常由控制邏輯電路、數據寄存器、移位寄存器、D/A轉換器(Digital Analog Converter)和電壓比較器構成。

                            優點：1.轉換速度快。其轉換周期等於 分辨率 * 時鐘周期(見下式)，如一個8位的逐次比較型A/D轉換器，時鐘周期為10us，則其轉換周期為80us。

T轉 = n * Tclk  (n為分辨率)

                   常見的型號：1.ADC0808/ADC0809，8位逐次比較型A/D轉換器，轉換時間100us，輸入電壓範圍0~~5V，可接入8個模擬量輸入。

                                    2.ADC0803/ADC0804，8位逐次比較型A/D轉換器，在1MHz的時鐘頻率下，轉換時間在66~~73us之間，支持一對差分模擬電壓輸入。

逐次比較型A/D轉換器原理圖 ，《数字电子技術》第六版 康華光

 

 ADC0808/ADC0809原理圖，National Semiconductor

ADC0803/ADC0804原理圖，Philips Semiconductors

 

     雙積分式A/D轉換器：一種間接的A/D轉換器，其分別對輸入電壓和參考電壓進行兩次積分，將輸入電壓平均值變換成與之成正比的時間間隔，然後利用時鐘脈衝和計數器測出此時間間隔，進而在輸出端得到與模擬量相應的数字量。通常由積分器(運算放大器及相應的外部電路)、過零比較器(運算放大器)、時鐘脈衝控制門和計數器等構成。

                         優點：1.抗工頻干擾能力強。通過對輸入電壓的平均值進行變換來實現抗干擾。 

                         缺點：1.轉換速度最慢。

                常見的型號：TLC7135，4.5位雙積分式A/D轉換器，CMOS工藝，差分電壓輸入。

雙積分式A/D轉換器原理圖，《数字电子技術》第六版 康華光

TLC7135数字部分原理圖，Texas Instruments

 

ADC的未來發展方向

     ADC在未來會變得性能更強、價格更低、功耗更低、通用性和專業性更強。

     性能：從歷史上看，對ADC性能的改進主要集中在改進架構和改善製造工藝兩個方面。ADC有很多架構，典型的包括：FLASH、SAR和雙積分；其他的有：流水線等。在集成電路發展的過程中，出現了許多的工藝：雙極性、ECL、CMOS、CB、BiCMOS、GaAs……這些工藝可以幫助改進ADC的性能。

     價格：隨着集成電路工藝的不斷成熟，價格變低只是時間問題。

     功耗：得力於集成電路工藝的改善，如：使用更低線寬的IC的功耗會低於高線寬的IC。功耗同時也取決於ADC架構。

 

元件清單(” * “為可選)

————————————————————時鐘發生器部分——————————————————————–

  NE555           *1

  *DIP-8芯片座  *1

  8位撥碼開關    *1

  *3pin排針       *1

  3.9K電阻        *1

  68K電阻         *1

  10uF無極電容   *1

  1uF無極電容     *1

  100nF無極電容 *1

  10nF無極電容   *2

  1nF無極電容     *1

  100pF無極電容 *1

  10pF無極電容   *1

  1pF無極電容     *1

所有元件合照(時鐘發生器部分)

———————————————————————————————————————————————–

————————————————————數模轉換器部分——————————————————————–

  MCP6004        *1(可以使用LM324替換)

  *DIP-14芯片座 *1

  CD4042B *1

  CD4532B *1

  *DIP-16芯片座 *2

  2K可調電阻器   *1

  330R電阻   *3

  390R電阻   *1

  1K電阻       *5

  LED-G       *3

  *Pin-3排母 *1

  *Pin-2排針 *1

所有元件合照(數模轉換器部分，不含Pin-2排針)

———————————————————————————————————————————————–

 

電路原理

 

總原理圖(1)

 

總原理圖(2)

————————————————————時鐘發生器部分——————————————————————–

     555定時器工作在多諧振蕩器模式，通過撥碼開關選擇不同的電容來產生不同頻率的方波。

 

基於555定時器的時鐘發生器原理圖

————————————————————————————————————————————————

————————————————————數模轉換器部分——————————————————————–

     比較器：左側的電阻分壓網絡為右側的四個比較器的反相輸入端提供階梯狀的參考電壓(4V、3V、2V、1V)，可調電阻模擬輸入到四個比較器同相端的模擬電壓(0~~5V)。比較器通過比較同相輸入端與反相輸入端電壓的大小，輸出0V(Vp<Vn)或5V(Vp>Vn)給後面的D鎖存器。

 

運放的特性圖

     四路D鎖存器：在時鐘的每一個上升沿，將四個運放輸出的電壓(比較結果)存儲起來並交給後面的編碼器。

     優先級編碼器：對來自鎖存器的四個比較結果進行編碼，並輸出給計算機處理(如果有計算機的話)。

———————————————————————————————————————————————–

 

集成電路簡介

     MCP6004：微芯公司生產的低功耗1MHz帶寬的4路運算放大器，本項目的運算放大器均工作在飽和區。

 

MCP6004實物圖

MCP6004引腳定義

     CD4042B：CMOS四路D鎖存器，在本項目中使用上升沿觸發，時鐘由555定時器提供，用於保存MCP6004輸出的4位數據。

 

CD4042B實物圖

CD4042B引腳定義

CD4042B真值表

     CD4532B： CMOS的8位優先級編碼器，用於對CD4042B鎖存的數據進行編碼。

 

CD4532B實物圖

CD4532B引腳定義

CD4532B真值表

 

測試

 ————————————————————時鐘發生器部分——————————————————————–

     此555時鐘發生電路，實際測試可以產生1Hz、10Hz、100Hz、1KHz、10KHz、100KHz、0.4MHz、0.7MHz的方波信號。實測中，產生的0.4MHz和0.7MHz與設計的1MHz、10MHz存在較大的誤差，可能是電容的問題(這兩個頻率對應所使用的是貼片電容)。

時鐘發生器(正面)

時鐘發生器(反面)

實測產生的最大頻率的波形(Vcc=5V下，Vpp=4.7V)

————————————————————————————————————————————————

————————————————————數模轉換器部分——————————————————————–

     在時鐘為400KHz下，此并行比較型A/D可以正常工作；使用700KHz的時鐘會導致轉換故障。

     主要參數：A/D分辨率為3位(嚴格來說只有2位，可以在不改變架構的情況下通過增加4個比較器拓增至3位)

                   採樣率為400KSPS~~700KSPS。

     功耗：20mA@5V = 100mW (包含時鐘發生器部分)

 

當輸入電壓為2.5V時，輸出的情況(可以看出LED指示“101”，正好是對“1100”編碼的結果)

 

正面(1)

 

正面(2)

 

反面

———————————————————————————————————————————————–

 

聲明

     此教程未經DLHC允許，禁止轉載。所有引用均註明了出處。DLHC保留所有權利。

     由於本人學識有限且整理較為倉促，如有錯誤或不妥，請指正。

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

原作者：Nik Piepenbreier

翻譯&內容補充：費弗里

原文地址：https://towardsdatascience.com/advanced-python-list-techniques-c6195fa699a3

　　列表（List）是你使用Python過程中接觸最為頻繁的數據結構，也是功能最為強大的幾種數據結構之一。Python列表非常的萬能且蘊含着許多隱藏技巧，下面我們就來探索一些常用的列表技巧。

1 列表元素的過濾

1.1 filter()的使用

　　filter()函數接受2個參數：1個函數對象以及1個可迭代的對象，接下來我們定義1個函數然後對1個列表進行過濾。

　　首先我們創建1個列表，並且剔除掉小於等於3的元素：

圖1

　　回顧一下發生了什麼：

　　1. 我們定義了列表original_list
　　2. 接着我們定義了一個接受數值型參數number的函數filter_three，當傳入的參數值大於3時會返回True，反之則會返回False
　　3. 我們定義了filter對象filtered，其中filter()接受的第一個參數是函數對象，第二個參數是列表對象
　　4. 最終我們將filter對象轉化為列表，最終得到經filter_three過濾后original_list內留下的元素。

1.2 使用列表推導式

　　類似的，我們也可以利用列表推導式來過濾列表元素，作為一種生成和修改列表優雅的方式，列表推導式想必大家都比較熟悉了，下面是使用列表推導完成同樣任務的過程：

圖2

2 修改列表

2.1 map()的使用

　　Python中內置的map()函數使得我們可以將某個函數應用到可迭代對象內每一個元素之上。

　　比方說我們想獲取到一個列表對象中每一個元素的平方，就可以使用到map()函數，就像下面的例子一樣：

圖3

　　類似filter()的工作過程，下面我們來看看發生了什麼：

　　1. 首先我們定義了列表original_list，以及接受數值型參數並返回其平方值的函數square()
　　2. 接着我們定義了map對象squares，類似filter()，map()接受的第一個參數是函數對象，第二個參數是列表對象
　　3. 最終我們將map對象squares列表化，就得到了想要的結果

2.2 使用列表推導式

　　同樣的我們也可以使用列表推導式完成同樣的任務：

圖4

3 利用zip()來組合列表

　　有些情況下我們需要將兩個或以上數量的列表組合在一起，這類需求使用zip()來完成非常方便。

　　zip()函數接收多個列表作為參數傳入，進而得到每個位置上一一對應的元素組合，就像下面的例子一樣：

圖5

4 顛倒列表

　　Python中的列表是有序的數據結構，正因如此，列表中元素的順序很重要，有些時候我們需要翻轉列表中所有元素的順序，可以通過Python中的切片操作，用::-1來快捷地實現：

圖6

5 檢查列表中元素的存在情況

　　有些情況下我們想要檢查列表中是否存在某個元素，這種時候就可以使用到Python中的in運算符，譬如說我們有一個記錄了所有比賽獲勝隊伍名稱的列表，當我們想查詢某個隊名是否已獲勝時，可以像下面的例子一樣：

圖7

6 找出列表中出現次數最多的元素

　　有些情況下我們想要找出列表中出現次數最多的元素，譬如對記錄若干次拋硬幣結果的列表，找出哪一種結果出現次數最多，就可以參考下面的例子：

圖8

7 展平嵌套列表

　　有些情況下我們會遇到一些嵌套的列表，其每個元素又是各自不同的列表，這種時候我們就可以利用列表推導式來把這種嵌套列表展平，如下面2層嵌套的例子：

圖9

額外補充：

　　原作者這裏只考慮到兩層嵌套的列表，如果是更多層嵌套，就需要有多少層寫多少for循環，比較麻煩，其實還有一種更好的方法，我們可以使用pip install dm-tree來安裝tree這個專門用於展平嵌套結構的庫，可以展平任意層嵌套列表，使用例子如下：

圖10

8 檢查唯一性

　　如果你想要查看列表中的值是否都是唯一值，可以使用Python中的set數據結構的特點，譬如下面的例子：

圖11

　　以上就是本文的全部內容，如有疑問歡迎在評論區討論~

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

【其他文章推薦】

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

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

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案

本文介紹如何基於各種雲服務優雅且低成本地搭建個人網站，涉及的雲產品有雲服務器、SSL、企業郵箱、對象存儲、CDN、雲函數、API網關、雲監控等。

概述

如今雲服務提供商們提供了大量涵蓋計算、網絡、存儲等方面的雲服務，其中一些雲產品功能強大，如果能善加利用可以大幅降低開發和運維的成本。下面以基於騰訊雲搭建的個人網站為例，對網站整體的架構進行介紹。

網站目前的主要功能是個人博客，後續可以擴展如個人網盤等其他應用。當前架構圖如下：

一、基礎設施

1.雲服務器CVM

雲服務器使用的是CVM，1核2G，下行帶寬1Mbps，這個配置用來搭建起步階段的個人博客是完全夠用了，購買學生機或者在活動時購買價格也比較便宜。

有了服務器資源就可以開始博客搭建，我選的博客系統是極簡主義的Typecho，安裝過程可以參考這篇博文，主要是在服務器上安裝nginx、mysql、php以及typecho的源碼。

2.域名

註冊 – 備案 – 解析

服務器創建后同時會分配一個公網ip，但是為了便於分享和傳播，建議進行域名註冊。註冊后需要進行備案，現在的備案流程也已經簡化為在小程序上操作，省去了原有的幕布拍照環節，前後大概1-2周時間就可以完成備案。之後在控制台進行域名解析，即綁定域名和服務器ip，注意對帶或不帶www前綴的域名都要進行解析，完成解析后就可以在瀏覽器通過域名來訪問網頁了。

主域名的確定

為了便於SEO，建議根據個人喜好確定一個主域名，因為搜索引擎對於帶www和不帶www前綴的地址是當成兩個網站分開計算權重的。國內網站一般帶www，而國外網站(如github、stackoverflow、leetcode)等是不帶www的。我這裡是選擇不帶www的地址（zhayujie.com），並在nginx中配置對帶www的訪問301重定向到不帶www上，以集中權重。

企業郵箱

擁有域名后，還可以註冊以自己域名為後綴的企業郵箱，基礎版免費使用且賬號數量無上限，再也不用擔心郵箱號不夠用了（如微信公眾平台註冊），郵箱格式類似於 zyj@zhayujie.com。

3.全站HTTPS

為了網站安全以及利於SEO，建議支持https協議訪問網站。可以申請免費的SSL證書，將證書和私鑰放置到服務器，並在nginx中開啟並配置SSL。同樣為了避免分散權重，可以把http訪問的請求301重定向到https上。以我的網站為例，帶不帶www以及是否使用https都會統一訪問https://zhayujie.com/。

二、基於COS和CDN的圖床

1.對象存儲COS

由於服務器下行帶寬有限，如果圖片存儲於我們自己的服務器，出現併發訪問時可能導致帶寬超限，訪問速度下降。所以可以把圖片存儲到 COS（Cloud Object Storage）中，搭建自己的圖床，這樣當博客同步到其他博客平台時，也便於對圖片資源進行統一管理。

COS的使用比較簡單，類似於網盤，在存儲桶中可以建立樹狀目錄結構，每個存儲桶（bucket）會分配一個公網域名，其下的文件通過https://{bucket}/{dir}/{filename}的形式進行訪問。但在博客中直接使用該鏈接是不妥的，因為一旦我們遷移到其他雲服務商或者切換其他的存儲方式了，原有的鏈接就失效了，一一修改成本太高。好在cos支持配置自定義域名，可以通過類似http://{domain}/{dir}/{filename}的地址進行訪問。

2.內容分髮網絡CDN

COS的自定義源站域名不支持https訪問，為了不影響我們的全站https，並且同時提升訪問速度和減少流量成本，可以配合CDN服務，開啟自定義CDN加速域名，具體步驟見文檔。

可以選取一個子域名作為cdn自定義域名，添加CNAME解析，這樣通過自定義域名會首先訪問cdn邊緣服務器，如果未命中則回源到cos。例如上面的圖片我配置的地址是https://blog.cos.zhayujie.com/web/blog-cloud-arch.jpg。

三、基於Serverless的消息服務

1.雲函數SCF

在博客開發過程中會遇到一些發送消息的功能，比如讀者回復文章時給筆者發送通知，筆者回複評論時給讀者發送通知，博文發布時給訂閱的讀者發送通知等等。這種消息通知的功能是很適合單獨拆分出來形成一個消息服務的，如果寫在博客源碼中則復用性差（網站下其他應用要發送消息時需要重寫），而單獨部署服務又會增加運維的成本（如果服務掛掉怎麼辦），這時候可以考慮serverless（無服務器）的架構，僅將我們的核心代碼片段託管給雲服務商。

騰訊雲提供了雲函數SCF（Serverless Cloud Function），是一種FaaS技術。對於消息通知這種異步、無狀態的功能，很適合使用雲函數編寫，比如接收到請求後向指定接收人發送一封郵件。

2.API網關

雲函數的觸發方式有多種，最常用的有定時任務和API網關。由於消息通知是通過事件觸發而不是定時觸發，所以選擇API網關，創建了觸發器后便可從公網直接訪問該函數，與Nginx反向代理的作用類似。

API網關的域名是隨機生成的，不利於對未來變化的擴展，故同樣綁定自定義域名，使用https://{domain}/{function}形式的地址觸發函數。例如我的郵件發送函數地址配置為https://apigw.zhayujie.com/commentNotice，在業務代碼中只需向該地址發送POST請求即可觸發郵件投遞。

四、監控、快照和統計

1.監控告警

服務器的監控和告警同樣很重要，有助於我們及時發現並排查問題。監控部分一般直接在控制台的 雲服務器 – 實例 – 監控 中進行查看，有對不同時間周期和時間粒度下的CPU、內存、帶寬、磁盤等的詳細數據。

告警部分則在雲監控中配置，可以配置多種報警策略如對cpu、內存、帶寬等指標超出閾值後進行告警，以及一些機器故障事件（如ping不可達、機器重啟等）。對COS的報警同樣可以在此配置。告警渠道可以是微信、郵件和短信。

2.快照

為了防止服務器硬盤中的數據遭到攻擊或被誤刪，可以在 雲服務器 – 快照 控制台中設置進行快照備份，並且支持定期快照策略，設置每隔一段時間自動創建新的快照。

3.訪問統計

對網站的訪問情況進行統計分析有利於我們優化網站內容和體驗。對於訪問數據統計使用的是百度統計，使用埋點方式接入，可以查看每一個訪客的地域，來源，搜索詞，轉化等信息，統計訪問量趨勢。

對於搜索引擎工具使用的是百度站長工具，用於提交頁面收錄，查看索引量、抓取頻次等數據。

總結

以上就是一個功能齊全的個人博客的搭建過程，大致計算一下成本，雲服務器活動期購買一百一年，域名一般幾十塊一個，而COS、CDN、SCF等產品都有大量的免費額度，且在建站初期流量費用同樣是微乎其微，所以總體算下來成本是極低的。個人開發者可以把個人網站當做一個產品來做，思考如何利用好公有雲的各種雲產品資源來提升用戶體驗，提高開發效率，降低運維成本。

原文鏈接：https://zhayujie.com/blog-cloud-arch.html

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

【其他文章推薦】

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

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

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

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

※新北清潔公司,居家、辦公、裝潢細清專業服務

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

HTTPS協議詳解

從事移動互聯網軟件開發的小夥伴肯定了解：自Android 9.0開始，應用程序的網絡請求默認使用https；基本是同期蘋果IOS在應用網絡請求方面，也強制使用https禁止http。
這一期間如果你去面試，不了解Https的握手過程，都不好意思講工資。
本人一個普通程序員，項目期間工期緊張，並未抽出時間詳細了解Https網絡請求過程中TLS握手過程，因此這件事一直在我的待辦記錄中…
這篇文章以Wireshark抓包，詳細了解Https請求中TLS的握手過程 與 客戶端證書校驗過程。

• HTTPS簡介
• SSL/TLS握手過程
• 客戶端 證書校驗

一、HTTPS簡介

HTTPS （Secure Hypertext Transfer Protocol）安全超文本傳輸協議，是一種通過計算機網絡進行安全通信的傳輸協議。
HTTPS 利用 SSL/TLS 來加密數據包，經由 HTTP 進行通信。
其設計的主要目的是，提供對網站服務器的身份認證、保護交換數據的隱私與完整性。

TLS/SSL

• SSL（Secure Socket Layer） 1994年由 瀏覽器開發商Netscape公司 率先倡導研發，為數據通訊提供安全支持，開發了最初的幾個版本SSL 1.0、SSL 2.0、SSL 3.0。
• TLS（Transport LayerSecurity）前身為SSL，1999年從 3.1 開始被 IETF（Internet Engineering Task Force，Internet 工程任務組）標準化並改名，發展至今已經有 TLS 1.0、TLS 1.1、TLS 1.2 三個版本。
  SSL3.0和TLS1.0由於存在安全漏洞，已經很少被使用到；
  TLS 1.3 改動會比較大，目前還在草案階段，目前使用最廣泛的是TLS 1.1、TLS 1.2；

TLS/SSL是介於TCP和HTTP之間的一層安全協議。

Http

HTTP（HyperText Transfer Protocol）超文本傳輸協議。
HTTP是一個客戶端（用戶）和服務端之間請求和應答的標準，其最初的設計目的是為了提供一種發布和接收HTML頁面的方法。

Http協議不是本文重點，感興趣的同學可參考文章：
HTTP 協議詳解
https://blog.csdn.net/xiaxl/article/details/104541274

二、SSL/TLS握手過程

SSL/TLS握手過程用一句話總結就是：用非對稱加密的手段傳遞密鑰，然後用密鑰進行對稱加密傳遞數據。
以下為SSL/TLS握手過程的時序圖：

這裏以客戶端向百度主頁發起Https請求為例，用Wireshark抓包對SSL/TLS握手的各個環節進行介紹，Wireshark抓包示意圖如下圖所示：

2.1、Client Hello （ Client——>Server ）

握手第一步是客戶端向服務端發送 Client Hello 消息，消息中包含客戶端的 TSL版本信息、秘鑰隨機數、加密套件候選列表、壓縮算法候選列表、擴展字段等信息，相關信息通過Wireshark抓包如下：

• Version : 支持的最高TSL協議版本，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2；
• Random：隨機數 random_C 用於後續的密鑰協商;
• Session ID：有或者無，有則客戶端傳上一次session的id可以恢復session；
• Cipher Suite：客戶端支持的密碼算法列表，供服務器選擇；
• Compression Methods：客戶端支持的壓縮算法列表，用於後續的信息壓縮傳輸；
• extensions：擴展字段；

2.2、Server Hello （ Server——>Client ）

服務端向客戶端發送 Server Hello 消息：包括服務端選擇使用的TSL協議版本、選擇的加密套件、選擇的壓縮算法、服務端生成的隨機數等，相關信息通過Wireshark抓包如下：

• Version：服務器選擇的版本；
• Random：隨機數 random_S 用於後續的密鑰協商;
• Session ID：有或者無，有則客戶端傳上一次session的id可以恢復session；
• Cipher Suite：服務端選擇的密鑰算法；
• Compression Methods：服務端選擇的壓縮算法；

到此客戶端和服務端都擁有了兩個隨機數（random_C+ random_S），這兩個隨機數會在後續生成對稱秘鑰時用到。

2.3、Certificate （ Server——>Client ）

服務端下發服務端的公鑰證書給客戶端，相關信息通過Wireshark抓包如下：

• Certificate 服務端的公鑰證書；

2.4、Server Key Exchange （ Server——>Client ）

該消息的目的是攜帶密鑰交換的額外數據，該消息內容對於不同的協商算法套件會存在差異：

• 對於使用DHE/ECDHE非對稱密鑰協商算法的SSL握手，服務器發送其使用的DH參數；
• RSA算法不會繼續該握手流程（DH、ECDH也不會發送server key exchange）。

2.5、Server Hello Done （ Server——>Client ）

通知客戶端，服務端已經將所有預計的握手消息發送完畢。

2.5、證書校驗 （客戶端進行證書校驗）

客戶端拿到服務端的公鑰證書后，需對該證書的合法性進行校驗，校驗內容如下：

• 證書鏈的可信性；
• 證書是否吊銷；
• 證書有效期；
• 證書域名校驗，核查證書域名是否與當前的訪問域名匹配;

注：
證書的詳細校驗過程將在下文進行詳細介紹

2.6、Client Key Exchange，Change Cipher Spec Protocol，Encrypted Handshake Message （ Client——>Server ）

• Client Key Exchange
  證書合法性驗證通過之後，客戶端產生隨機数字Pre-master，計算生成秘鑰enc_key（enc_key=Fuc(random_C, random_S, Pre-Master)，將Pre-master與enc_key用證書公鑰加密（非對稱加密算法）發送給服務端;
• Change Cipher Spec Protocol
  客戶端通知服務端後續的通信都採用協商的通信密鑰和加密算法進行加密通信;
• Encrypted Handshake Message
  客戶端將之前所有的握手數據（包括接受、發送）生成摘要，然後用協商好的秘鑰enc_key加密（對稱加密算法），發送給對應的服務端；
  服務端收到消息后，會用秘鑰enc_key解密客戶端的摘要信息，然後用與客戶端相同的算法生成服務端摘要信息，最後對比兩個摘要信息相同，則驗證通過；

2.7、Change Cipher Spec Protocol （ Server——>Client ）

服務器同樣發送 Change Cipher Spec Protocol 以告知客戶端後續的通信都採用協商的密鑰與算法進行加密通信;

2.8、Encrypted Handshake Message （ Server——>Client ）

服務端也會將握手過程的消息生成摘要再用秘鑰加密，這是服務端發出的第一條加密消息;
客戶端接收後會用秘鑰解密，能解出來說明協商的秘鑰是一致的。

2.9、Application Data （ Client——>Server ）

到這裏，雙方已安全地協商出了同一份秘鑰enc_key，所有的應用層數據都會用這個秘鑰加密后再通過 TCP 進行可靠傳輸。

2.10 總結

SSL/TLS握手過程：用非對稱加密的手段傳遞密鑰，然後用密鑰進行對稱加密傳遞數據。

三、證書校驗

客戶端驗證服務端下發的證書，主要包括以下幾個方面：

• 第一，校驗證書是否是受信任的CA根證書頒發機構頒發；
• 第二，校驗證書是否在上級證書的吊銷列表；
• 第三，校驗證書是否過期；
• 第四，校驗證書域名是否一致。

3.1、校驗證書是否是由受信任的CA根證書頒發機構頒發

為了確保客戶端獲取到的服務端公鑰不被篡改，需引入權威的第三方CA機構。
CA機構負責核實公鑰擁有者信息、頒發“證書(對服務端公鑰進行簽名)”，同時為使用者提供證書驗證服務。

CA機構頒發證書的基本原理為：

• 服務端生成一對服務端公鑰、服務端私鑰；
• 服務端將自己的服務端公鑰提供給CA機構；
• CA機構核實服務端公鑰擁有者信息（核實申請者提供信息的真實性，如組織是否存在、企業是否合法、是否擁有域名的所有權等）；
• CA機構計算服務端公鑰的摘要信息，利用CA機構的私鑰（CA機構有一對公鑰、私鑰）進行加密，加密后的服務端公鑰即CA機構頒發的“證書”；

客戶端驗證服務端公鑰的基本原理為：

• Https網絡請求過程中，客戶端獲取到服務端的公鑰；
• 客戶端用存儲在本地的CA機構的公鑰，對 服務端公鑰進行解密，獲取到服務端公鑰的摘要信息A；
• 客戶端計算服務端公鑰的摘要信息B；
• 對比摘要信息A與B，相同則證書驗證通過；

3.2、校驗證書是否在上級證書的吊銷列表

CA機構能夠簽發證書，同樣也存在機制宣布以往簽發的證書無效。使用者私鑰丟失，使用者申請讓證書無效等情況，CA機構需要廢棄該證書。
主要存在兩類機制：CRL 與 OCSP。

• CRL（Certificate Revocation List）
  證書吊銷列表是一個單獨的文件，該文件包含了 CA機構 已經吊銷的證書序列號與吊銷日期；
  證書中一般會包含一個 URL 地址 CRL Distribution Point，通知使用者去哪裡下載對應的 CRL 以校驗證書是否吊銷。
  該吊銷方式的優點是不需要頻繁更新，但是不能及時吊銷證書，因為 CRL 更新時間一般是幾天，這期間可能已經造成了極大損失。
• OCSP（Online Certificate Status Protocol）
  證書狀態在線查詢協議，一個實時查詢證書是否吊銷的方式。
  請求者發送證書的信息並請求查詢，服務器返回正常、吊銷或未知中的任何一個狀態。
  證書中一般也會包含一個 OCSP 的 URL 地址，要求查詢服務器具有良好的性能。
  部分 CA 或大部分的自簽 CA (根證書)都是未提供 CRL 或 OCSP 地址的，對於吊銷證書會是一件非常麻煩的事情。

3.3、校驗證書是否過期

校驗證書的有效期是否已經過期

3.4、校驗證書域名是否一致

校驗證書域名是否一致：核查證書域名是否與當前的訪問域名匹配。
這裏核驗的是我們請求的域名 www.baidu.com 是否與證書文件中DNS標籤下所列的域名相匹配；

注：
具體的證書文件舉例，請查看第四節 “四、證書舉例” 。

一種錯誤的寫法：

Android 軟件開發中，我們經常會遇到以下代碼，用來忽略證書的域名驗證，其實這是一種不安全的寫法：

// 對於自簽名證書，用以下代碼來忽略證書的域名驗證
HostnameVerifier hostnameVerifier = new HostnameVerifier() {
    @Override
    public boolean verify(String urlHostName, SSLSession session) {
		// 忽略證書的域名驗證
        return true;
    }
};

四、證書舉例

這裏以百度的Https證書舉例：

Certificate:
	Data:
	    Version: 3 (0x2)
	    Serial Number:
	        72:58:78:36:6e:9f:56:e8:1d:41:88:48
	Signature Algorithm: sha256WithRSAEncryption
	    Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
	    Validity
	        Not Before: Apr  2 07:04:58 2020 GMT
	        Not After : Jul 26 05:31:02 2021 GMT
	    Subject: C=CN, ST=beijing, L=beijing, OU=service operation department, O=Beijing Baidu Netcom Science Technology Co., Ltd, CN=baidu.com
	    Subject Public Key Info:
	        Public Key Algorithm: rsaEncryption
	            Public-Key: (2048 bit)
	            Modulus:
	                00:c1:a9:b0:ae:47:1a:d2:57:eb:1d:15:1f:6e:5c:
	                b2:e4:f8:0b:20:db:ea:00:df:29:ff:a4:6b:89:26:
	                4b:9f:23:2f:ec:57:b0:8a:b8:46:40:2a:7e:bc:dc:
	                5a:45:97:4f:ad:41:0e:bc:20:86:4b:0c:5d:55:21:
	                47:e2:31:3c:57:a7:ec:99:47:eb:47:0d:72:d7:c8:
	                16:54:75:ef:d3:45:11:0f:4b:ce:60:7a:46:5c:28:
	                74:ae:8e:1b:be:d8:70:66:7b:a8:93:49:28:d2:a3:
	                76:94:55:de:7c:27:f2:0f:f7:98:0c:ad:86:da:c6:
	                ae:fd:9f:f0:d9:81:32:9a:97:e3:21:ee:04:92:96:
	                e4:78:11:e5:c4:10:0e:10:31:7a:4a:97:a0:eb:c7:
	                9b:c4:da:89:37:a9:c3:37:d7:56:b1:7f:52:c7:d9:
	                26:0a:d6:af:38:16:b1:6d:fb:73:79:b1:68:79:03:
	                90:eb:88:7b:8c:48:91:98:51:a5:07:94:86:a5:78:
	                46:79:8f:58:9b:e9:35:59:a7:f1:7b:57:31:0a:90:
	                cf:24:ce:0d:24:e7:92:b2:6a:e9:e6:96:37:0a:b8:
	                7c:87:2f:74:d2:5c:e8:4b:0a:5f:66:18:a7:41:86:
	                cf:26:a6:08:8e:a5:49:17:92:53:b3:91:a5:cf:53:
	                b0:31
	            Exponent: 65537 (0x10001)
	    X509v3 extensions:
	        X509v3 Key Usage: critical
	            Digital Signature, Key Encipherment
	        Authority Information Access: 
	            CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
	            OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2

	        X509v3 Certificate Policies: 
	            Policy: 1.3.6.1.4.1.4146.1.20
	              CPS: https://www.globalsign.com/repository/
	            Policy: 2.23.140.1.2.2

	        X509v3 Basic Constraints: 
	            CA:FALSE
	        X509v3 CRL Distribution Points: 

	            Full Name:
	              URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl

	        X509v3 Subject Alternative Name: 
	            DNS:baidu.com, DNS:baifubao.com, DNS:www.baidu.cn, DNS:www.baidu.com.cn, DNS:mct.y.nuomi.com, DNS:apollo.auto, DNS:dwz.cn, DNS:*.baidu.com, DNS:*.baifubao.com, DNS:*.baidustatic.com, DNS:*.bdstatic.com, DNS:*.bdimg.com, DNS:*.hao123.com, DNS:*.nuomi.com, DNS:*.chuanke.com, DNS:*.trustgo.com, DNS:*.bce.baidu.com, DNS:*.eyun.baidu.com, DNS:*.map.baidu.com, DNS:*.mbd.baidu.com, DNS:*.fanyi.baidu.com, DNS:*.baidubce.com, DNS:*.mipcdn.com, DNS:*.news.baidu.com, DNS:*.baidupcs.com, DNS:*.aipage.com, DNS:*.aipage.cn, DNS:*.bcehost.com, DNS:*.safe.baidu.com, DNS:*.im.baidu.com, DNS:*.baiducontent.com, DNS:*.dlnel.com, DNS:*.dlnel.org, DNS:*.dueros.baidu.com, DNS:*.su.baidu.com, DNS:*.91.com, DNS:*.hao123.baidu.com, DNS:*.apollo.auto, DNS:*.xueshu.baidu.com, DNS:*.bj.baidubce.com, DNS:*.gz.baidubce.com, DNS:*.smartapps.cn, DNS:*.bdtjrcv.com, DNS:*.hao222.com, DNS:*.haokan.com, DNS:*.pae.baidu.com, DNS:*.vd.bdstatic.com, DNS:click.hm.baidu.com, DNS:log.hm.baidu.com, DNS:cm.pos.baidu.com, DNS:wn.pos.baidu.com, DNS:update.pan.baidu.com
	        X509v3 Extended Key Usage: 
	            TLS Web Server Authentication, TLS Web Client Authentication
	        X509v3 Authority Key Identifier: 
	            keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

	        X509v3 Subject Key Identifier: 
	            ......

五、參考

TSL：
https://tools.ietf.org/html/rfc5246

SSL/TSL 原理：
https://www.cnblogs.com/chenjingquan/p/10531305.html

TLS/SSL握手過程
https://blog.csdn.net/hherima/article/details/52469674

========== THE END ==========

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

【其他文章推薦】

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

※新北清潔公司,居家、辦公、裝潢細清專業服務

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

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

※超省錢租車方案

熟悉React的朋友都知道，React支持jsx語法，我們可以直接將HTML代碼寫到JS中間，然後渲染到頁面上，我們寫的HTML如果有更新的話，React還有虛擬DOM的對比，只更新變化的部分，而不重新渲染整個頁面，大大提高渲染效率。到了16.x，React更是使用了一個被稱為Fiber的架構，提升了用戶體驗，同時還引入了hooks等特性。那隱藏在React背後的原理是怎樣的呢，Fiber和hooks又是怎麼實現的呢？本文會從jsx入手，手寫一個簡易版的React，從而深入理解React的原理。

本文主要實現了這些功能:

簡易版Fiber架構

簡易版DIFF算法

簡易版函數組件

簡易版Hook: useState

娛樂版Class組件

本文代碼地址：https://github.com/dennis-jiang/Front-End-Knowledges/tree/master/Examples/React/fiber-and-hooks

本文程序跑起來效果如下：

JSX和creatElement

以前我們寫React要支持JSX還需要一個庫叫JSXTransformer.js，後來JSX的轉換工作都集成到了babel裏面了，babel還提供了在線預覽的功能，可以看到轉換后的效果，比如下面這段簡單的代碼:

const App =
(
  <div>
    <h1 id="title">Title</h1>
    <a href="xxx">Jump</a>
    <section>
      <p>
        Article
      </p>
    </section>
  </div>
);

經過babel轉換后就變成了這樣：

上面的截圖可以看出我們寫的HTML被轉換成了React.createElement，我們將上面代碼稍微格式化來看下：

var App = React.createElement(
  'div',
  null,
  React.createElement(
    'h1',
    {
      id: 'title',
    },
    'Title',
  ),
  React.createElement(
    'a',
    {
      href: 'xxx',
    },
    'Jump',
  ),
  React.createElement(
    'section',
    null,
    React.createElement('p', null, 'Article'),
  ),
);

從轉換后的代碼我們可以看出React.createElement支持多個參數:

1. type，也就是節點類型
2. config, 這是節點上的屬性，比如id和href
3. children, 從第三個參數開始就全部是children也就是子元素了，子元素可以有多個，類型可以是簡單的文本，也可以還是React.createElement，如果是React.createElement，其實就是子節點了，子節點下面還可以有子節點。這樣就用React.createElement的嵌套關係實現了HTML節點的樹形結構。

讓我們來完整看下這個簡單的React頁面代碼：

渲染在頁面上是這樣：

這裏面用到了React的地方其實就兩個，一個是JSX，也就是React.createElement，另一個就是ReactDOM.render，所以我們手寫的第一個目標就有了，就是createElement和render這兩個方法。

手寫createElement

對於<h1 id="title">Title</h1>這樣一個簡單的節點，原生DOM也會附加一大堆屬性和方法在上面，所以我們在createElement的時候最好能將它轉換為一種比較簡單的數據結構，只包含我們需要的元素，比如這樣：

{
  type: 'h1',
  props: {
    id: 'title',
    children: 'Title'
  }
}

有了這個數據結構后，我們對於DOM的操作其實可以轉化為對這個數據結構的操作，新老DOM的對比其實也可以轉化為這個數據結構的對比，這樣我們就不需要每次操作都去渲染頁面，而是等到需要渲染的時候才將這個數據結構渲染到頁面上。這其實就是虛擬DOM！而我們createElement就是負責來構建這個虛擬DOM的方法，下面我們來實現下：

function createElement(type, props, ...children) {
  // 核心邏輯不複雜，將參數都塞到一個對象上返回就行
  // children也要放到props裏面去，這樣我們在組件裏面就能通過this.props.children拿到子元素
  return {
    type,
    props: {
      ...props,
      children
    }
  }
}

上述代碼是React的createElement簡化版，對源碼感興趣的朋友可以看這裏：https://github.com/facebook/react/blob/60016c448bb7d19fc989acd05dda5aca2e124381/packages/react/src/ReactElement.js#L348

手寫render

上述代碼我們用createElement將JSX代碼轉換成了虛擬DOM，那真正將它渲染到頁面的函數是render，所以我們還需要實現下這個方法，通過我們一般的用法ReactDOM.render( <App />,document.getElementById('root'));可以知道他接收兩個參數：

1. 根組件，其實是一個JSX組件，也就是一個createElement返回的虛擬DOM
2. 父節點，也就是我們要將這個虛擬DOM渲染的位置

有了這兩個參數，我們來實現下render方法：

function render(vDom, container) {
  let dom;
  // 檢查當前節點是文本還是對象
  if(typeof vDom !== 'object') {
    dom = document.createTextNode(vDom)
  } else {
    dom = document.createElement(vDom.type);
  }

  // 將vDom上除了children外的屬性都掛載到真正的DOM上去
  if(vDom.props) {
    Object.keys(vDom.props)
      .filter(key => key != 'children')
      .forEach(item => {
        dom[item] = vDom.props[item];
      })
  }
  
  // 如果還有子元素，遞歸調用
  if(vDom.props && vDom.props.children && vDom.props.children.length) {
    vDom.props.children.forEach(child => render(child, dom));
  }

  container.appendChild(dom);
}

上述代碼是簡化版的render方法，對源碼感興趣的朋友可以看這裏：https://github.com/facebook/react/blob/3e94bce765d355d74f6a60feb4addb6d196e3482/packages/react-dom/src/client/ReactDOMLegacy.js#L287

現在我們可以用自己寫的createElement和render來替換原生的方法了：

可以得到一樣的渲染結果：

為什麼需要Fiber

上面我們簡單的實現了虛擬DOM渲染到頁面上的代碼，這部分工作被React官方稱為renderer，renderer是第三方可以自己實現的一個模塊，還有個核心模塊叫做reconsiler，reconsiler的一大功能就是大家熟知的diff，他會計算出應該更新哪些頁面節點，然後將需要更新的節點虛擬DOM傳遞給renderer，renderer負責將這些節點渲染到頁面上。但是這個流程有個問題，雖然React的diff算法是經過優化的，但是他卻是同步的，renderer負責操作DOM的appendChild等API也是同步的，也就是說如果有大量節點需要更新，JS線程的運行時間可能會比較長，在這段時間瀏覽器是不會響應其他事件的，因為JS線程和GUI線程是互斥的，JS運行時頁面就不會響應，這個時間太長了，用戶就可能看到卡頓，特別是動畫的卡頓會很明顯。在React的官方演講中有個例子，可以很明顯的看到這種同步計算造成的卡頓：

而Fiber就是用來解決這個問題的，Fiber可以將長時間的同步任務拆分成多個小任務，從而讓瀏覽器能夠抽身去響應其他事件，等他空了再回來繼續計算，這樣整個計算流程就顯得平滑很多。下面是使用Fiber后的效果：

怎麼來拆分

上面我們自己實現的render方法直接遞歸遍歷了整個vDom樹，如果我們在中途某一步停下來，下次再調用時其實並不知道上次在哪裡停下來的，不知道從哪裡開始，即使你將上次的結束節點記下來了，你也不知道下一個該執行哪個，所以vDom的樹形結構並不滿足中途暫停，下次繼續的需求，需要改造數據結構。另一個需要解決的問題是，拆分下來的小任務什麼時候執行？我們的目的是讓用戶有更流暢的體驗，所以我們最好不要阻塞高優先級的任務，比如用戶輸入，動畫之類，等他們執行完了我們再計算。那我怎麼知道現在有沒有高優先級任務，瀏覽器是不是空閑呢？總結下來，Fiber要想達到目的，需要解決兩個問題：

1. 新的任務調度，有高優先級任務的時候將瀏覽器讓出來，等瀏覽器空了再繼續執行
2. 新的數據結構，可以隨時中斷，下次進來可以接着執行

requestIdleCallback

requestIdleCallback是一個實驗中的新API，這個API調用方式如下:

// 開啟調用
var handle = window.requestIdleCallback(callback[, options])

// 結束調用
Window.cancelIdleCallback(handle) 

requestIdleCallback接收一個回調，這個回調會在瀏覽器空閑時調用，每次調用會傳入一個IdleDeadline，可以拿到當前還空餘多久，options可以傳入參數最多等多久，等到了時間瀏覽器還不空就強制執行了。使用這個API可以解決任務調度的問題，讓瀏覽器在空閑時才計算diff並渲染。更多關於requestIdleCallback的使用可以查看MDN的文檔。但是這個API還在實驗中，兼容性不好，所以React官方自己實現了一套。本文會繼續使用requestIdleCallback來進行任務調度，我們進行任務調度的思想是將任務拆分成多個小任務，requestIdleCallback裏面不斷的把小任務拿出來執行，當所有任務都執行完或者超時了就結束本次執行，同時要註冊下次執行，代碼架子就是這樣：

function workLoop(deadline) {
  while(nextUnitOfWork && deadline.timeRemaining() > 1) {
    // 這個while循環會在任務執行完或者時間到了的時候結束
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
  }

  // 如果任務還沒完，但是時間到了，我們需要繼續註冊requestIdleCallback
  requestIdleCallback(workLoop);
}

// performUnitOfWork用來執行任務，參數是我們的當前fiber任務，返回值是下一個任務
function performUnitOfWork(fiber) {
  
}
requestIdleCallback(workLoop);

上述workLoop對應React源碼看這裏。

Fiber可中斷數據結構

上面我們的performUnitOfWork並沒有實現，但是從上面的結構可以看出來，他接收的參數是一個小任務，同時通過這個小任務還可以找到他的下一個小任務，Fiber構建的就是這樣一個數據結構。Fiber之前的數據結構是一棵樹，父節點的children指向了子節點，但是只有這一個指針是不能實現中斷繼續的。比如我現在有一個父節點A，A有三個子節點B,C,D，當我遍歷到C的時候中斷了，重新開始的時候，其實我是不知道C下面該執行哪個的，因為只知道C，並沒有指針指向他的父節點，也沒有指針指向他的兄弟。Fiber就是改造了這樣一個結構，加上了指向父節點和兄弟節點的指針：

上面的圖片還是來自於官方的演講，可以看到和之前父節點指向所有子節點不同，這裡有三個指針：

1. child: 父節點指向第一個子元素的指針。
2. sibling：從第一個子元素往後，指向下一個兄弟元素。
3. return：所有子元素都有的指向父元素的指針。

有了這幾個指針后，我們可以在任意一個元素中斷遍歷並恢復，比如在上圖List處中斷了，恢復的時候可以通過child找到他的子元素，也可以通過return找到他的父元素，如果他還有兄弟節點也可以用sibling找到。Fiber這個結構外形看着還是棵樹，但是沒有了指向所有子元素的指針，父節點只指向第一個子節點，然後子節點有指向其他子節點的指針，這其實是個鏈表。

實現Fiber

現在我們可以自己來實現一下Fiber了，我們需要將之前的vDom結構轉換為Fiber的數據結構，同時需要能夠通過其中任意一個節點返回下一個節點，其實就是遍歷這個鏈表。遍歷的時候從根節點出發，先找子元素，如果子元素存在，直接返回，如果沒有子元素了就找兄弟元素，找完所有的兄弟元素后再返回父元素，然後再找這個父元素的兄弟元素。整個遍歷過程其實是個深度優先遍歷，從上到下，然後最後一行開始從左到右遍歷。比如下圖從div1開始遍歷的話，遍歷的順序就應該是div1 -> div2 -> h1 -> a -> div2 -> p -> div1。可以看到這個序列中，當我們return父節點時，這些父節點會被第二次遍歷，所以我們寫代碼時，return的父節點不會作為下一個任務返回，只有sibling和child才會作為下一個任務返回。

// performUnitOfWork用來執行任務，參數是我們的當前fiber任務，返回值是下一個任務
function performUnitOfWork(fiber) {
  // 根節點的dom就是container，如果沒有這個屬性，說明當前fiber不是根節點
  if(!fiber.dom) {
    fiber.dom = createDom(fiber);   // 創建一個DOM掛載上去
  } 

  // 如果有父節點，將當前節點掛載到父節點上
  if(fiber.return) {
    fiber.return.dom.appendChild(fiber.dom);
  }

  // 將我們前面的vDom結構轉換為fiber結構
  const elements = fiber.children;
  let prevSibling = null;
  if(elements && elements.length) {
    for(let i = 0; i < elements.length; i++) {
      const element = elements[i];
      const newFiber = {
        type: element.type,
        props: element.props,
        return: fiber,
        dom: null
      }

      // 父級的child指向第一個子元素
      if(i === 0) {
        fiber.child = newFiber;
      } else {
        // 每個子元素擁有指向下一個子元素的指針
        prevSibling.sibling = newFiber;
      }

      prevSibling = newFiber;
    }
  }

  // 這個函數的返回值是下一個任務，這其實是一個深度優先遍歷
  // 先找子元素，沒有子元素了就找兄弟元素
  // 兄弟元素也沒有了就返回父元素
  // 然後再找這個父元素的兄弟元素
  // 最後到根節點結束
  // 這個遍歷的順序其實就是從上到下，從左到右
  if(fiber.child) {
    return fiber.child;
  }

  let nextFiber = fiber;
  while(nextFiber) {
    if(nextFiber.sibling) {
      return nextFiber.sibling;
    }

    nextFiber = nextFiber.return;
  }
}

React源碼中的performUnitOfWork看這裏，當然比我們這個複雜很多。

統一commit DOM操作

上面我們的performUnitOfWork一邊構建Fiber結構一邊操作DOMappendChild，這樣如果某次更新好幾個節點，操作了第一個節點之後就中斷了，那我們可能只看到第一個節點渲染到了頁面，後續幾個節點等瀏覽器空了才陸續渲染。為了避免這種情況，我們應該將DOM操作都搜集起來，最後統一執行，這就是commit。為了能夠記錄位置，我們還需要一個全局變量workInProgressRoot來記錄根節點，然後在workLoop檢測如果任務執行完了，就commit:

function workLoop(deadline) {
  while(nextUnitOfWork && deadline.timeRemaining() > 1) {
    // 這個while循環會在任務執行完或者時間到了的時候結束
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
  }

  // 任務做完后統一渲染
  if(!nextUnitOfWork && workInProgressRoot) {
    commitRoot();
  }

  // 如果任務還沒完，但是時間到了，我們需要繼續註冊requestIdleCallback
  requestIdleCallback(workLoop);
}

因為我們是在Fiber樹完全構建后再執行的commit，而且有一個變量workInProgressRoot指向了Fiber的根節點，所以我們可以直接把workInProgressRoot拿過來遞歸渲染就行了：

// 統一操作DOM
function commitRoot() {
  commitRootImpl(workInProgressRoot.child);    // 開啟遞歸
  workInProgressRoot = null;     // 操作完后將workInProgressRoot重置
}

function commitRootImpl(fiber) {
  if(!fiber) {
    return;
  }

  const parentDom = fiber.return.dom;
  parentDom.appendChild(fiber.dom);

  // 遞歸操作子元素和兄弟元素
  commitRootImpl(fiber.child);
  commitRootImpl(fiber.sibling);
}

reconcile調和

reconcile其實就是虛擬DOM樹的diff操作，需要刪除不需要的節點，更新修改過的節點，添加新的節點。為了在中斷後能回到工作位置，我們還需要一個變量currentRoot，然後在fiber節點裏面添加一個屬性alternate，這個屬性指向上一次運行的根節點，也就是currentRoot。currentRoot會在第一次render后的commit階段賦值，也就是每次計算完后都會把當次狀態記錄在alternate上，後面更新了就可以把alternate拿出來跟新的狀態做diff。然後performUnitOfWork裏面需要添加調和子元素的代碼，可以新增一個函數reconcileChildren。這個函數裏面不能簡單的創建新節點了，而是要將老節點跟新節點拿來對比，對比邏輯如下:

1. 如果新老節點類型一樣，復用老節點DOM，更新props
2. 如果類型不一樣，而且新的節點存在，創建新節點替換老節點
3. 如果類型不一樣，沒有新節點，有老節點，刪除老節點

注意刪除老節點的操作是直接將oldFiber加上一個刪除標記就行，同時用一個全局變量deletions記錄所有需要刪除的節點：

      // 對比oldFiber和當前element
      const sameType = oldFiber && element && oldFiber.type === element.type;  //檢測類型是不是一樣
      // 先比較元素類型
      if(sameType) {
        // 如果類型一樣，復用節點，更新props
        newFiber = {
          type: oldFiber.type,
          props: element.props,
          dom: oldFiber.dom,
          return: workInProgressFiber,
          alternate: oldFiber,          // 記錄下上次狀態
          effectTag: 'UPDATE'           // 添加一個操作標記
        }
      } else if(!sameType && element) {
        // 如果類型不一樣，有新的節點，創建新節點替換老節點
        newFiber = {
          type: element.type,
          props: element.props,
          dom: null,                    // 構建fiber時沒有dom，下次perform這個節點是才創建dom
          return: workInProgressFiber,
          alternate: null,              // 新增的沒有老狀態
          effectTag: 'REPLACEMENT'      // 添加一個操作標記
        }
      } else if(!sameType && oldFiber) {
        // 如果類型不一樣，沒有新節點，有老節點，刪除老節點
        oldFiber.effectTag = 'DELETION';   // 添加刪除標記
        deletions.push(oldFiber);          // 一個數組收集所有需要刪除的節點
      }

然後就是在commit階段處理真正的DOM操作，具體的操作是根據我們的effectTag來判斷的:

function commitRootImpl(fiber) {
  if(!fiber) {
    return;
  }

  const parentDom = fiber.return.dom;
  if(fiber.effectTag === 'REPLACEMENT' && fiber.dom) {
    parentDom.appendChild(fiber.dom);
  } else if(fiber.effectTag === 'DELETION') {
    parentDom.removeChild(fiber.dom);
  } else if(fiber.effectTag === 'UPDATE' && fiber.dom) {
    // 更新DOM屬性
    updateDom(fiber.dom, fiber.alternate.props, fiber.props);
  }

  // 遞歸操作子元素和兄弟元素
  commitRootImpl(fiber.child);
  commitRootImpl(fiber.sibling);
}

替換和刪除的DOM操作都比較簡單，更新屬性的會稍微麻煩點，需要再寫一個輔助函數updateDom來實現:

// 更新DOM的操作
function updateDom(dom, prevProps, nextProps) {
  // 1. 過濾children屬性
  // 2. 老的存在，新的沒了，取消
  // 3. 新的存在，老的沒有，新增
  Object.keys(prevProps)
    .filter(name => name !== 'children')
    .filter(name => !(name in nextProps))
    .forEach(name => {
      if(name.indexOf('on') === 0) {
        dom.removeEventListener(name.substr(2).toLowerCase(), prevProps[name], false);
      } else {
        dom[name] = '';
      }
    });

  Object.keys(nextProps)
    .filter(name => name !== 'children')
    .forEach(name => {
      if(name.indexOf('on') === 0) {
        dom.addEventListener(name.substr(2).toLowerCase(), nextProps[name], false);
      } else {
        dom[name] = nextProps[name];
      }
    });
}

updateDom的代碼寫的比較簡單，事件只處理了簡單的on開頭的，兼容性也有問題，prevProps和nextProps可能會遍歷到相同的屬性，有重複賦值，但是總體原理還是沒錯的。要想把這個處理寫全，代碼量還是不少的。

函數組件

函數組件是React裏面很常見的一種組件，我們前面的React架構其實已經寫好了，我們這裏來支持下函數組件。我們之前的fiber節點上的type都是DOM節點的類型，比如h1什麼的，但是函數組件的節點type其實就是一個函數了，我們需要對這種節點進行單獨處理。

首先需要在更新的時候檢測當前節點是不是函數組件，如果是，children的處理邏輯會稍微不一樣:

// performUnitOfWork裏面
// 檢測函數組件
function performUnitOfWork(fiber) {
  const isFunctionComponent = fiber.type instanceof Function;
  if(isFunctionComponent) {
    updateFunctionComponent(fiber);
  } else {
    updateHostComponent(fiber);
  }
  
  // ...下面省略n行代碼...
}

function updateFunctionComponent(fiber) {
  // 函數組件的type就是個函數，直接拿來執行可以獲得DOM元素
  const children = [fiber.type(fiber.props)];

  reconcileChildren(fiber, children);
}

// updateHostComponent就是之前的操作，只是單獨抽取了一個方法
function updateHostComponent(fiber) {
  if(!fiber.dom) {
    fiber.dom = createDom(fiber);   // 創建一個DOM掛載上去
  } 

  // 將我們前面的vDom結構轉換為fiber結構
  const elements = fiber.props.children;

  // 調和子元素
  reconcileChildren(fiber, elements);
}

然後在我們提交DOM操作的時候因為函數組件沒有DOM元素，所以需要注意兩點：

1. 獲取父級DOM元素的時候需要遞歸網上找真正的DOM
2. 刪除節點的時候需要遞歸往下找真正的節點

我們來修改下commitRootImpl:

function commitRootImpl() {
  // const parentDom = fiber.return.dom;
  // 向上查找真正的DOM
  let parentFiber = fiber.return;
  while(!parentFiber.dom) {
    parentFiber = parentFiber.return;
  }
  const parentDom = parentFiber.dom;
  
  // ...這裏省略n行代碼...
  
  if{fiber.effectTag === 'DELETION'} {
    commitDeletion(fiber, parentDom);
  }
}

function commitDeletion(fiber, domParent) {
  if(fiber.dom) {
    // dom存在，是普通節點
    domParent.removeChild(fiber.dom);
  } else {
    // dom不存在，是函數組件,向下遞歸查找真實DOM
    commitDeletion(fiber.child, domParent);
  }
}

現在我們可以傳入函數組件了:

import React from './myReact';
const ReactDOM = React;

function App(props) {
  return (
    <div>
      <h1 id="title">{props.title}</h1>
      <a href="xxx">Jump</a>
      <section>
        <p>
          Article
        </p>
      </section>
    </div>
  );
}

ReactDOM.render(
  <App title="Fiber Demo"/>,
  document.getElementById('root')
);

實現useState

useState是React Hooks裏面的一個API，相當於之前Class Component裏面的state，用來管理組件內部狀態，現在我們已經有一個簡化版的React了，我們也可以嘗試下來實現這個API。

簡單版

我們還是從用法入手來實現最簡單的功能，我們一般使用useState是這樣的：

function App(props) {
  const [count, setCount] = React.useState(1);
  const onClickHandler = () => {
    setCount(count + 1);
  }
  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={onClickHandler}>Count+1</button>
    </div>
  );
}

ReactDOM.render(
  <App title="Fiber Demo"/>,
  document.getElementById('root')
);

上述代碼可以看出，我們的useState接收一個初始值，返回一個數組，裏面有這個state的當前值和改變state的方法，需要注意的是App作為一個函數組件，每次render的時候都會運行，也就是說裏面的局部變量每次render的時候都會重置，那我們的state就不能作為一個局部變量，而是應該作為一個全部變量存儲：

let state = null;
function useState(init) {

  state = state === null ? init : state;

  // 修改state的方法
  const setState = value => {
    state = value;

    // 只要修改了state，我們就需要重新處理節點
    workInProgressRoot = {
      dom: currentRoot.dom,
      props: currentRoot.props,
      alternate: currentRoot
    }

    // 修改nextUnitOfWork指向workInProgressRoot，這樣下次就會處理這個節點了
    nextUnitOfWork = workInProgressRoot;
    deletions = [];
  }

  return [state, setState]
}

這樣其實我們就可以使用了：

支持多個state

上面的代碼只有一個state變量，如果我們有多個useState怎麼辦呢？為了能支持多個useState，我們的state就不能是一個簡單的值了，我們可以考慮把他改成一個數組，多個useState按照調用順序放進這個數組裡面，訪問的時候通過下標來訪問:

let state = [];
let hookIndex = 0;
function useState(init) {
  const currentIndex = hookIndex;
  state[currentIndex] = state[currentIndex] === undefined ? init : state[currentIndex];

  // 修改state的方法
  const setState = value => {
    state[currentIndex] = value;

    // 只要修改了state，我們就需要重新處理這個節點
    workInProgressRoot = {
      dom: currentRoot.dom,
      props: currentRoot.props,
      alternate: currentRoot
    }

    // 修改nextUnitOfWork指向workInProgressRoot，這樣下次就會處理這個節點了
    nextUnitOfWork = workInProgressRoot;
    deletions = [];
  }

  hookIndex++;

  return [state[currentIndex], setState]
}

來看看多個useState的效果：

支持多個組件

上面的代碼雖然我們支持了多個useState，但是仍然只有一套全局變量，如果有多個函數組件，每個組件都來操作這個全局變量，那相互之間不就是污染了數據了嗎？所以我們數據還不能都存在全局變量上面，而是應該存在每個fiber節點上，處理這個節點的時候再將狀態放到全局變量用來通訊:

// 申明兩個全局變量，用來處理useState
// wipFiber是當前的函數組件fiber節點
// hookIndex是當前函數組件內部useState狀態計數
let wipFiber = null;
let hookIndex = null;

因為useState只在函數組件裏面可以用，所以我們之前的updateFunctionComponent裏面需要初始化處理useState變量:

function updateFunctionComponent(fiber) {
  // 支持useState，初始化變量
  wipFiber = fiber;
  hookIndex = 0;
  wipFiber.hooks = [];        // hooks用來存儲具體的state序列
  
  // ......下面代碼省略......
}

因為hooks隊列放到fiber節點上去了，所以我們在useState取之前的值時需要從fiber.alternate上取，完整代碼如下：

function useState(init) {
  // 取出上次的Hook
  const oldHook = wipFiber.alternate && wipFiber.alternate.hooks && wipFiber.alternate.hooks[hookIndex];

  // hook數據結構
  const hook = {
    state: oldHook ? oldHook.state : init      // state是每個具體的值
  }

  // 將所有useState調用按照順序存到fiber節點上
  wipFiber.hooks.push(hook);
  hookIndex++;

  // 修改state的方法
  const setState = value => {
    hook.state = value;

    // 只要修改了state，我們就需要重新處理這個節點
    workInProgressRoot = {
      dom: currentRoot.dom,
      props: currentRoot.props,
      alternate: currentRoot
    }

    // 修改nextUnitOfWork指向workInProgressRoot，這樣下次requestIdleCallback就會處理這個節點了
    nextUnitOfWork = workInProgressRoot;
    deletions = [];
  }

  return [hook.state, setState]
}

上面代碼可以看出我們在將useState和存儲的state進行匹配的時候是用的useState的調用順序匹配state的下標，如果這個下標匹配不上了，state就錯了，所以React裏面不能出現這樣的代碼:

if (something) {
    const [state, setState] = useState(1);
}

上述代碼不能保證每次something都滿足，可能導致useState這次render執行了，下次又沒執行，這樣新老節點的下標就匹配不上了，對於這種代碼，React會直接報錯：

用Hooks模擬Class組件

這個功能純粹是娛樂性功能，通過前面實現的Hooks來模擬實現Class組件，這個並不是React官方的實現方式哈~我們可以寫一個方法將Class組件轉化為前面的函數組件:

function transfer(Component) {
  return function(props) {
    const component = new Component(props);
    let [state, setState] = useState(component.state);
    component.props = props;
    component.state = state;
    component.setState = setState;

    return component.render();
  }
}

然後就可以寫Class了，這個Class長得很像我們在React裏面寫的Class，有state,setState和render：

import React from './myReact';

class Count4 {
  constructor(props) {
    this.props = props;
    this.state = {
      count: 1
    }
  }

  onClickHandler = () => {
    this.setState({
      count: this.state.count + 1
    })
  }

  render() {
    return (
      <div>
        <h3>Class component Count: {this.state.count}</h3>
        <button onClick={this.onClickHandler}>Count+1</button>
      </div>
    ); 
  }
}

// export的時候用transfer包裝下
export default React.transfer(Count4);

然後使用的時候直接:

<div>
  <Count4></Count4>
</div>

當然你也可以在React裏面建一個空的class Component，讓Count4繼承他，這樣就更像了。

好了，到這裏我們代碼就寫完了，完整代碼可以看我GitHub。

總結

1. 我們寫的JSX代碼被babel轉化成了React.createElement。
2. React.createElement返回的其實就是虛擬DOM結構。
3. ReactDOM.render方法是將虛擬DOM渲染到頁面的。
4. 虛擬DOM的調和和渲染可以簡單粗暴的遞歸，但是這個過程是同步的，如果需要處理的節點過多，可能會阻塞用戶輸入和動畫播放，造成卡頓。
5. Fiber是16.x引入的新特性，用處是將同步的調和變成異步的。
6. Fiber改造了虛擬DOM的結構，具有父 -> 第一個子，子 -> 兄，子 -> 父這幾個指針，有了這幾個指針，可以從任意一個Fiber節點找到其他節點。
7. Fiber將整棵樹的同步任務拆分成了每個節點可以單獨執行的異步執行結構。
8. Fiber可以從任意一個節點開始遍歷，遍歷是深度優先遍歷，順序是父 -> 子 -> 兄 -> 父，也就是從上往下，從左往右。
9. Fiber的調和階段可以是異步的小任務，但是提交階段(commit)必須是同步的。因為異步的commit可能讓用戶看到節點一個一個接連出現，體驗不好。
10. 函數組件其實就是這個節點的type是個函數，直接將type拿來運行就可以得到虛擬DOM。
11. useState是在Fiber節點上添加了一個數組，數組裡面的每個值對應了一個useState，useState調用順序必須和這個數組下標匹配，不然會報錯。

參考資料

A Cartoon Intro to Fiber

妙味課堂大聖老師：手寫react的fiber和hooks架構

React Fiber

這可能是最通俗的 React Fiber(時間分片) 打開方式

淺析 React Fiber

React Fiber架構

文章的最後，感謝你花費寶貴的時間閱讀本文，如果本文給了你一點點幫助或者啟發，請不要吝嗇你的贊和GitHub小星星，你的支持是作者持續創作的動力。

作者博文GitHub項目地址： https://github.com/dennis-jiang/Front-End-Knowledges

作者掘金文章匯總：https://juejin.im/post/5e3ffc85518825494e2772fd

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案