Bill Chiles（Roslyn編譯器的程序經(jīng)理)寫了一篇文章《Essential Performance Facts and .NET Framework Tips》，知名博主寒江獨(dú)釣對(duì)該文進(jìn)行了摘譯，文中分享了性能優(yōu)化的一些建議和思考，比如不要過(guò)早優(yōu)化、好工具很重要、性能的關(guān)鍵，在于內(nèi)存分配等，并指出開發(fā)者不要盲目的沒(méi)有根據(jù)的優(yōu)化，首先定位和查找到造成產(chǎn)生性能問(wèn)題的原因點(diǎn)最重要。

　　全文如下：

　　本文提供了一些性能優(yōu)化的建議，這些經(jīng)驗(yàn)來(lái)自于使用托管代碼重寫C# 和 VB編譯器，并以編寫C# 編譯器中的一些真實(shí)場(chǎng)景作為例子來(lái)展示這些優(yōu)化經(jīng)驗(yàn)。.NET 平臺(tái)開發(fā)應(yīng)用程序具有極高的生產(chǎn)力。.NET 平臺(tái)上強(qiáng)大安全的編程語(yǔ)言以及豐富的類庫(kù)，使得開發(fā)應(yīng)用變得卓有成效。但是能力越大責(zé)任越大。我們應(yīng)該使用.NET框架的強(qiáng)大能力，但同時(shí)如果我們需要處理大量的數(shù)據(jù)比如文件或者數(shù)據(jù)庫(kù)也需要準(zhǔn)備對(duì)我們的代碼進(jìn)行調(diào)優(yōu)。

　　為什么來(lái)自新的編譯器的性能優(yōu)化經(jīng)驗(yàn)也適用于您的應(yīng)用程序

　　微軟使用托管代碼重寫了C#和Visual Basic的編譯器，并提供了一些列新的API來(lái)進(jìn)行代碼建模和分析、開發(fā)編譯工具，使得Visual Studio具有更加豐富的代碼感知的編程體驗(yàn)。重寫編譯器，并且在新的編譯器上開發(fā)Visual Studio的經(jīng)驗(yàn)使得我們獲得了非常有用的性能優(yōu)化經(jīng)驗(yàn)，這些經(jīng)驗(yàn)也能用于大型的.NET應(yīng)用，或者一些需要處理大量數(shù)據(jù)的APP上。你不需要了解編譯器，也能夠從C#編譯器的例子中得出這些見解。

　　Visual Studio使用了編譯器的API來(lái)實(shí)現(xiàn)了強(qiáng)大的智能感知(Intellisense)功能，如代碼關(guān)鍵字著色，語(yǔ)法填充列表，錯(cuò)誤波浪線提示，參數(shù)提示，代碼問(wèn)題及修改建議等，這些功能深受開發(fā)者歡迎。Visual Studio在開發(fā)者輸入或者修改代碼的時(shí)候，會(huì)動(dòng)態(tài)的編譯代碼來(lái)獲得對(duì)代碼的分析和提示。

　　當(dāng)用戶和App進(jìn)行交互的時(shí)候，通常希望軟件具有好的響應(yīng)性。輸入或者執(zhí)行命令的時(shí)候，應(yīng)用程序界面不應(yīng)該被阻塞。幫助或者提示能夠迅速顯示出來(lái)或者當(dāng)用戶繼續(xù)輸入的時(shí)候停止提示�，F(xiàn)在的App應(yīng)該避免在執(zhí)行長(zhǎng)時(shí)間計(jì)算的時(shí)候阻塞UI線程從而讓用戶感覺(jué)程序不夠流暢。

　　想了解更多關(guān)于新的編譯器的信息，可以訪問(wèn) .NET Compiler Platform ("Roslyn")

　基本要領(lǐng)

　　在對(duì).NET 進(jìn)行性能調(diào)優(yōu)以及開發(fā)具有良好響應(yīng)性的應(yīng)用程序的時(shí)候，請(qǐng)考慮以下這些基本要領(lǐng)：

　　要領(lǐng)一:不要過(guò)早優(yōu)化

　　編寫代碼比想象中的要復(fù)雜的多，代碼需要維護(hù)，調(diào)試及優(yōu)化性能。 一個(gè)有經(jīng)驗(yàn)的程序員，通常會(huì)對(duì)自然而然的提出解決問(wèn)題的方法并編寫高效的代碼。 但是有時(shí)候也可能會(huì)陷入過(guò)早優(yōu)化代碼的問(wèn)題中。比如，有時(shí)候使用一個(gè)簡(jiǎn)單的數(shù)組就夠了，非要優(yōu)化成使用哈希表，有時(shí)候簡(jiǎn)單的重新計(jì)算一下可以，非要使用復(fù)雜的可能導(dǎo)致內(nèi)存泄漏的緩存。發(fā)現(xiàn)問(wèn)題時(shí)，應(yīng)該首先測(cè)試性能問(wèn)題然后再分析代碼。

　　要領(lǐng)二:沒(méi)有評(píng)測(cè)，便是猜測(cè)

　　剖析和測(cè)量不會(huì)撒謊。測(cè)評(píng)可以顯示CPU是否滿負(fù)荷運(yùn)轉(zhuǎn)或者是存在磁盤I/O阻塞。測(cè)評(píng)會(huì)告訴你應(yīng)用程序分配了什么樣的以及多大的內(nèi)存，以及是否CPU花費(fèi)了很多時(shí)間在 垃圾回收上。

　　應(yīng)該為關(guān)鍵的用戶體驗(yàn)或者場(chǎng)景設(shè)置性能目標(biāo)，并且編寫測(cè)試來(lái)測(cè)量性能。通過(guò)使用科學(xué)的方法來(lái)分析性能不達(dá)標(biāo)的原因的步驟如下：使用測(cè)評(píng)報(bào)告來(lái)指導(dǎo)，假設(shè)可能出現(xiàn)的情況，并且編寫實(shí)驗(yàn)代碼或者修改代碼來(lái)驗(yàn)證我們的假設(shè)或者修正。如果我們?cè)O(shè)置了基本的性能指標(biāo)并且經(jīng)常測(cè)試，就能夠避免一些改變導(dǎo)致性能的回退(regression)，這樣就能夠避免我們浪費(fèi)時(shí)間在一些不必要的改動(dòng)中。

　　要領(lǐng)三:好工具很重要

　　好的工具能夠讓我們能夠快速的定位到影響性能的最大因素(CPU，內(nèi)存，磁盤)并且能夠幫助我們定位產(chǎn)生這些瓶頸的代碼。微軟已經(jīng)發(fā)布了很多性能測(cè)試工具比如： Visual Studio Profiler, Windows Phone Analysis Tool, 以及 PerfView.

　　PerfView是一款免費(fèi)且性能強(qiáng)大的工具，他主要關(guān)注影響性能的一些深層次的問(wèn)題(磁盤 I/O，GC 事件，內(nèi)存)，后面會(huì)展示這方面的例子。我們能夠抓取性能相關(guān)的 Event Tracing for Windows(ETW)事件并能以應(yīng)用程序，進(jìn)程，堆棧，線程的尺度查看這些信息。PerfView能夠展示應(yīng)用程序分配了多少，以及分配了何種內(nèi)存以及應(yīng)用程序中的函數(shù)以及調(diào)用堆棧對(duì)內(nèi)存分配的貢獻(xiàn)。這些方面的細(xì)節(jié)，您可以查看隨工具下載發(fā)布的關(guān)于PerfView的非常詳細(xì)的幫助，Demo以及視頻教程（比如 Channel9上的視頻教程）

　　要領(lǐng)四：所有的都與內(nèi)存分配相關(guān)

　　你可能會(huì)想，編寫響應(yīng)及時(shí)的基于.NET的應(yīng)用程序關(guān)鍵在于采用好的算法，比如使用快速排序替代冒泡排序，但是實(shí)際情況并不是這樣。編寫一個(gè)響應(yīng)良好的app的最大因素在于內(nèi)存分配，特別是當(dāng)app非常大或者處理大量數(shù)據(jù)的時(shí)候。

　　在使用新的編譯器API開發(fā)響應(yīng)良好的IDE的實(shí)踐中，大部分工作都花在了如何避免開辟內(nèi)存以及管理緩存策略。PerfView追蹤顯示新的C# 和VB編譯器的性能基本上和CPU的性能瓶頸沒(méi)有關(guān)系。編譯器在讀入成百上千甚至上萬(wàn)行代碼，讀入元數(shù)據(jù)活著產(chǎn)生編譯好的代碼，這些操作其實(shí)都是I/O bound 密集型。UI線程的延遲幾乎全部都是由于垃圾回收導(dǎo)致的。.NET框架對(duì)垃圾回收的性能已經(jīng)進(jìn)行過(guò)高度優(yōu)化，他能夠在應(yīng)用程序代碼執(zhí)行的時(shí)候并行的執(zhí)行垃圾回收的大部分操作。但是，單個(gè)內(nèi)存分配操作有可能會(huì)觸發(fā)一次昂貴的垃圾回收操作，這樣GC會(huì)暫時(shí)掛起所有線程來(lái)進(jìn)行垃圾回收(比如 Generation 2型的垃圾回收)

　常見的內(nèi)存分配以及例子

　　這部分的例子雖然背后關(guān)于內(nèi)存分配的地方很少。但是，如果一個(gè)大的應(yīng)用程序執(zhí)行足夠多的這些小的會(huì)導(dǎo)致內(nèi)存分配的表達(dá)式，那么這些表達(dá)式會(huì)導(dǎo)致幾百M(fèi)，甚至幾G的內(nèi)存分配。比如，在性能測(cè)試團(tuán)隊(duì)把問(wèn)題定位到輸入場(chǎng)景之前，一分鐘的測(cè)試模擬開發(fā)者在編譯器里面編寫代碼會(huì)分配幾G的內(nèi)存。

　　裝箱

　　裝箱發(fā)生在當(dāng)通常分配在線程棧上或者數(shù)據(jù)結(jié)構(gòu)中的值類型，或者臨時(shí)的值需要被包裝到對(duì)象中的時(shí)候（比如分配一個(gè)對(duì)象來(lái)存放數(shù)據(jù)，活著返回一個(gè)指針給一個(gè)Object對(duì)象）。.NET框架由于方法的簽名或者類型的分配位置，有些時(shí)候會(huì)自動(dòng)對(duì)值類型進(jìn)行裝箱。將值類型包裝為引用類型會(huì)產(chǎn)生內(nèi)存分配。.NET框架及語(yǔ)言會(huì)盡量避免不必要的裝箱，但是有時(shí)候在我們沒(méi)有注意到的時(shí)候會(huì)產(chǎn)生裝箱操作。過(guò)多的裝箱操作會(huì)在應(yīng)用程序中分配成M上G的內(nèi)存，這就意味著垃圾回收的更加頻繁，也會(huì)花更長(zhǎng)時(shí)間。

　　在PerfView中查看裝箱操作，只需要開啟一個(gè)追蹤（trace），然后查看應(yīng)用程序名字下面的GC Heap Alloc 項(xiàng)（記住，PerfView會(huì)報(bào)告所有的進(jìn)程的資源分配情況），如果在分配相中看到了一些諸如System.Int32和System.Char的值類型，那么就發(fā)生了裝箱。選擇一個(gè)類型，就會(huì)顯示調(diào)用棧以及發(fā)生裝箱的操作的函數(shù)。

　　例1 string方法和其值類型參數(shù)

　　下面的示例代碼演示了潛在的不必要的裝箱以及在大的系統(tǒng)中的頻繁的裝箱操作。

public class Logger
{
    public static void WriteLine(string s)
    {
        /*...*/
    }
}
public class BoxingExample
{
    public void Log(int id, int size)
    {
        var s = string.Format("{0}:{1}", id, size);
        Logger.WriteLine(s);
    }
}

　　這是一個(gè)日志基礎(chǔ)類，因此app會(huì)很頻繁的調(diào)用Log函數(shù)來(lái)記日志，可能該方法會(huì)被調(diào)用millons次。問(wèn)題在于，調(diào)用string.Format方法會(huì)調(diào)用其 重載的接受一個(gè)string類型和兩個(gè)Object類型的方法：

String.Format Method (String, Object, Object)

　　該重載方法要求.NET Framework 把int型裝箱為object類型然后將它傳到方法調(diào)用中去。為了解決這一問(wèn)題，方法就是調(diào)用id.ToString()和size.ToString()方法，然后傳入到string.Format 方法中去，調(diào)用ToString()方法的確會(huì)導(dǎo)致一個(gè)string的分配，但是在string.Format方法內(nèi)部不論怎樣都會(huì)產(chǎn)生string類型的分配。

　　你可能會(huì)認(rèn)為這個(gè)基本的調(diào)用string.Format 僅僅是字符串的拼接，所以你可能會(huì)寫出這樣的代碼：

var s = id.ToString() + ':' + size.ToString();

　　實(shí)際上，上面這行代碼也會(huì)導(dǎo)致裝箱，因?yàn)樯厦娴恼Z(yǔ)句在編譯的時(shí)候會(huì)調(diào)用：

string.Concat(Object, Object, Object);

　　這個(gè)方法，.NET Framework 必須對(duì)字符常量進(jìn)行裝箱來(lái)調(diào)用Concat方法。

　　解決方法：

　　完全修復(fù)這個(gè)問(wèn)題很簡(jiǎn)單，將上面的單引號(hào)替換為雙引號(hào)即將字符常量換為字符串常量就可以避免裝箱，因?yàn)閟tring類型的已經(jīng)是引用類型了。

var s = id.ToString() + ":" + size.ToString();

　　例2 枚舉類型的裝箱

　　下面的這個(gè)例子是導(dǎo)致新的C# 和VB編譯器由于頻繁的使用枚舉類型，特別是在Dictionary中做查找操作時(shí)分配了大量?jī)?nèi)存的原因。

public enum Color { Red, Green, Blue }
public class BoxingExample
{
    private string name;
    private Color color;
    public override int GetHashCode()
    {
        return name.GetHashCode() ^ color.GetHashCode();
    }
}

　　問(wèn)題非常隱蔽，PerfView會(huì)告訴你enmu.GetHashCode()由于內(nèi)部實(shí)現(xiàn)的原因產(chǎn)生了裝箱操作，該方法會(huì)在底層枚舉類型的表現(xiàn)形式上進(jìn)行裝箱，如果仔細(xì)看PerfView，會(huì)看到每次調(diào)用GetHashCode會(huì)產(chǎn)生兩次裝箱操作。編譯器插入一次，.NET Framework插入另外一次。

　　解決方法：

　　通過(guò)在調(diào)用GetHashCode的時(shí)候?qū)⒚杜e的底層表現(xiàn)形式進(jìn)行強(qiáng)制類型轉(zhuǎn)換就可以避免這一裝箱操作。

((int)color).GetHashCode()

　　另一個(gè)使用枚舉類型經(jīng)常產(chǎn)生裝箱的操作時(shí)enum.HasFlag。傳給HasFlag的參數(shù)必須進(jìn)行裝箱，在大多數(shù)情況下，反復(fù)調(diào)用HasFlag通過(guò)位運(yùn)算測(cè)試非常簡(jiǎn)單和不需要分配內(nèi)存。

　　要牢記基本要領(lǐng)第一條，不要過(guò)早優(yōu)化。并且不要過(guò)早的開始重寫所有代碼。 需要注意到這些裝箱的耗費(fèi)，只有在通過(guò)工具找到并且定位到最主要問(wèn)題所在再開始修改代碼。

　　字符串

　　字符串操作是引起內(nèi)存分配的最大元兇之一，通常在PerfView中占到前五導(dǎo)致內(nèi)存分配的原因。應(yīng)用程序使用字符串來(lái)進(jìn)行序列化，表示JSON和REST。在不支持枚舉類型的情況下，字符串可以用來(lái)與其他系統(tǒng)進(jìn)行交互。當(dāng)我們定位到是由于string操作導(dǎo)致對(duì)性能產(chǎn)生嚴(yán)重影響的時(shí)候，需要留意string類的Format(),Concat(),Split(),Join(),Substring()等這些方法。使用StringBuilder能夠避免在拼接多個(gè)字符串時(shí)創(chuàng)建多個(gè)新字符串的開銷，但是StringBuilder的創(chuàng)建也需要進(jìn)行良好的控制以避免可能會(huì)產(chǎn)生的性能瓶頸。

　　例3 字符串操作

　　在C#編譯器中有如下方法來(lái)輸出方法前面的xml格式的注釋。

public void WriteFormattedDocComment(string text)
{
    string[] lines = text.Split(new[] {"\r\n", "\r", "\n"},
        StringSplitOptions.None);
    int numLines = lines.Length;
    bool skipSpace = true;
    if (lines[0].TrimStart().StartsWith("///"))
    {
        for (int i = 0; i < numLines; i++)
        {
            string trimmed = lines[i].TrimStart();
            if (trimmed.Length < 4 || !char.IsWhiteSpace(trimmed[3]))
            {
                skipSpace = false;
                break;
            }
        }
        int substringStart = skipSpace ? 4 : 3;
        for (int i = 0; i < numLines; i++)
            Console.WriteLine(lines[i].TrimStart().Substring(substringStart));
    }
    else
    {
        /* ... */
    }
}

　　可以看到，在這片代碼中包含有很多字符串操作。代碼中使用類庫(kù)方法來(lái)將行分割為字符串，來(lái)去除空格，來(lái)檢查參數(shù)text是否是XML文檔格式的注釋，然后從行中取出字符串處理。

　　在WriteFormattedDocComment方法每次被調(diào)用時(shí)，第一行代碼調(diào)用Split()就會(huì)分配三個(gè)元素的字符串?dāng)?shù)組。編譯器也需要產(chǎn)生代碼來(lái)分配這個(gè)數(shù)組。因?yàn)榫幾g器并不知道，如果Splite()存儲(chǔ)了這一數(shù)組，那么其他部分的代碼有可能會(huì)改變這個(gè)數(shù)組，這樣就會(huì)影響到后面對(duì)WriteFormattedDocComment方法的調(diào)用。每次調(diào)用Splite()方法也會(huì)為參數(shù)text分配一個(gè)string，然后在分配其他內(nèi)存來(lái)執(zhí)行splite操作。

　　WriteFormattedDocComment方法中調(diào)用了三次TrimStart()方法，在內(nèi)存環(huán)中調(diào)用了兩次，這些都是重復(fù)的工作和內(nèi)存分配。更糟糕的是，TrimStart()的無(wú)參重載方法的簽名如下：

namespace System
{ 
    public class String 
    { 
        public string TrimStart(params char[] trimChars);
    }
}

　　該方法簽名意味著，每次對(duì)TrimStart()的調(diào)用都回分配一個(gè)空的數(shù)組以及返回一個(gè)string類型的結(jié)果。

　　最后，調(diào)用了一次Substring()方法，這個(gè)方法通常會(huì)導(dǎo)致在內(nèi)存中分配新的字符串。

　　解決方法：

　　和前面的只需要小小的修改即可解決內(nèi)存分配的問(wèn)題不同。在這個(gè)例子中，我們需要從頭看，查看問(wèn)題然后采用不同的方法解決。比如，可以意識(shí)到WriteFormattedDocComment()方法的參數(shù)是一個(gè)字符串，它包含了方法中需要的所有信息，因此，代碼只需要做更多的index操作，而不是分配那么多小的string片段。

　　下面的方法并沒(méi)有完全解，但是可以看到如何使用類似的技巧來(lái)解決本例中存在的問(wèn)題。C#編譯器使用如下的方式來(lái)消除所有的額外內(nèi)存分配。

private int IndexOfFirstNonWhiteSpaceChar(string text, int start)
{
    while (start < text.Length && char.IsWhiteSpace(text[start])) 
        start++;
    return start;
}

private bool TrimmedStringStartsWith(string text, int start, string prefix)
{
    start = IndexOfFirstNonWhiteSpaceChar(text, start); 
    int len = text.Length - start; 
    if (len < prefix.Length) return false;
    for (int i = 0; i < len; i++)
    {
        if (prefix[i] != text[start + i]) 
            return false;
    }
    return true;
}

　　WriteFormattedDocComment() 方法的第一個(gè)版本分配了一個(gè)數(shù)組，幾個(gè)子字符串，一個(gè)trim后的子字符串，以及一個(gè)空的params數(shù)組。也檢查了”///”。修改后的代碼僅使用了index操作，沒(méi)有任何額外的內(nèi)存分配。它查找第一個(gè)非空格的字符串，然后逐個(gè)字符串比較來(lái)查看是否以”///”開頭。和使用TrimStart()不同，修改后的代碼使用IndexOfFirstNonWhiteSpaceChar方法來(lái)返回第一個(gè)非空格的開始位置，通過(guò)使用這種方法，可以移除WriteFormattedDocComment()方法中的所有額外內(nèi)存分配。

　　例4 StringBuilder

　　本例中使用StringBuilder。下面的函數(shù)用來(lái)產(chǎn)生泛型類型的全名：

public class Example 
{ 
    // Constructs a name like "SomeType<T1, T2, T3>" 
    public string GenerateFullTypeName(string name, int arity) 
    { 
        StringBuilder sb = new StringBuilder();
        sb.Append(name);
        if (arity != 0)
        { 
            sb.Append("<");
            for (int i = 1; i < arity; i++)
            {
                sb.Append("T"); sb.Append(i.ToString()); sb.Append(", ");
            } 
            sb.Append("T"); sb.Append(i.ToString()); sb.Append(">");
        }
        return sb.ToString(); 
    }
}

　　注意力集中到StringBuilder實(shí)例的創(chuàng)建上來(lái)。代碼中調(diào)用sb.ToString()會(huì)導(dǎo)致一次內(nèi)存分配。在StringBuilder中的內(nèi)部實(shí)現(xiàn)也會(huì)導(dǎo)致內(nèi)部?jī)?nèi)存分配，但是我們?nèi)绻�想要獲取到string類型的結(jié)果化，這些分配無(wú)法避免。

　　解決方法：

　　要解決StringBuilder對(duì)象的分配就使用緩存。即使緩存一個(gè)可能被隨時(shí)丟棄的單個(gè)實(shí)例對(duì)象也能夠顯著的提高程序性能。下面是該函數(shù)的新的實(shí)現(xiàn)。除了下面兩行代碼，其他代碼均相同

// Constructs a name like "Foo<T1, T2, T3>" 
public string GenerateFullTypeName(string name, int arity)
{
    StringBuilder sb = AcquireBuilder(); /* Use sb as before */ 
    return GetStringAndReleaseBuilder(sb);
}

　　關(guān)鍵部分在于新的 AcquireBuilder()和GetStringAndReleaseBuilder()方法：

[ThreadStatic]
private static StringBuilder cachedStringBuilder;

private static StringBuilder AcquireBuilder()
{
    StringBuilder result = cachedStringBuilder;
    if (result == null)
    {
        return new StringBuilder();
    } 
    result.Clear(); 
    cachedStringBuilder = null; 
    return result;
}

private static string GetStringAndReleaseBuilder(StringBuilder sb)
{
    string result = sb.ToString(); 
    cachedStringBuilder = sb; 
    return result;
}

　　上面方法實(shí)現(xiàn)中使用了 thread-static字段來(lái)緩存StringBuilder對(duì)象，這是由于新的編譯器使用了多線程的原因。很可能會(huì)忘掉這個(gè)ThreadStatic聲明。Thread-static字符為每個(gè)執(zhí)行這部分的代碼的線程保留一個(gè)唯一的實(shí)例。

　　如果已經(jīng)有了一個(gè)實(shí)例，那么AcquireBuilder()方法直接返回該緩存的實(shí)例，在清空后，將該字段或者緩存設(shè)置為null。否則AcquireBuilder()創(chuàng)建一個(gè)新的實(shí)例并返回，然后將字段和cache設(shè)置為null 。

　　當(dāng)我們對(duì)StringBuilder處理完成之后，調(diào)用GetStringAndReleaseBuilder()方法即可獲取string結(jié)果。然后將StringBuilder保存到字段中或者緩存起來(lái)，然后返回結(jié)果。這段代碼很可能重復(fù)執(zhí)行，從而創(chuàng)建多個(gè)StringBuilder對(duì)象，雖然很少會(huì)發(fā)生。代碼中僅保存最后被釋放的那個(gè)StringBuilder對(duì)象來(lái)留作后用。新的編譯器中，這種簡(jiǎn)單的的緩存策略極大地減少了不必要的內(nèi)存分配。.NET Framework 和 MSBuild中的部分模塊也使用了類似的技術(shù)來(lái)提升性能。

　　簡(jiǎn)單的緩存策略必須遵循良好的緩存設(shè)計(jì)，因?yàn)樗�有大小的限制cap。使用緩存可能比之前有更多的代碼，也需要更多的維護(hù)工作。我們只有在發(fā)現(xiàn)這是個(gè)問(wèn)題之后才應(yīng)該采緩存策略。PerfView已經(jīng)顯示出StringBuilder對(duì)內(nèi)存的分配貢獻(xiàn)相當(dāng)大。

標(biāo)簽： 安全 代碼 開發(fā)者 評(píng)測(cè) 數(shù)據(jù)庫(kù)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。