顯然Microsoft開發(fā)人員和管理人員并沒有表達(dá)清楚，事實(shí)上ASP.NET Core 2.0將會(huì)得到整個(gè).NET Framework的支持。當(dāng)前的更改只實(shí)現(xiàn)了在ASP.NET上提供.NET Core，這是為了便于開發(fā)而采取的一個(gè)臨時(shí)步驟。對(duì)此，在ASP.NET Core預(yù)覽發(fā)行聲明中給出了如下的解釋：
在發(fā)布ASP.NET Core 2.0預(yù)覽版時(shí)，僅提供了對(duì).NET Core 2.0 SDK的支持。我們的目標(biāo)是在.NET Standard 2.0中發(fā)布ASP.NET Core 2.0，使應(yīng)用可運(yùn)行在.NET Core、Mono和.NET Framework上。團(tuán)隊(duì)正致力于在Build大會(huì)之前解決最后一些問題，最突出的問題是在ASP.NET Core 2.0預(yù)覽版中使用了.NET Standard 2.0之外的API，這妨礙了在.NET Framework上的運(yùn)行。由于這些問題，我們限制了Preview 1版本對(duì).NET Core的支持，以免對(duì)開發(fā)人員在.NET Framework上將ASP.NET Core 1.x應(yīng)用升級(jí)到ASP.NET Core 2預(yù)覽版時(shí)造成破壞。
在Register的一次采訪中，Miguel de Icaza確認(rèn)了Microsoft對(duì).NET Framework的承諾：
我要對(duì)此做出澄清。我感到十分遺憾的是，即將推出的.NET Core 2.0是我們專為Build大會(huì)準(zhǔn)備，它只是一個(gè)預(yù)覽版，因?yàn)槲覀儼l(fā)現(xiàn)其中存在一系列在.NET Framework上無法很快得到解決的問題。因此，我們推出的軟件包僅支持在.NET Core 2.0上運(yùn)行ASP.NET Core 2.0。我們將會(huì)修復(fù)這個(gè)問題，.NET Core 2.0終將運(yùn)行在.NET Framework上。
即便是臨時(shí)性更改，一個(gè)依然需要解決的問題是：要想進(jìn)一步改進(jìn)ASP.NET的性能，需要提供更好的字符串處理庫(kù)。
內(nèi)存分配上的考慮
在.NET中，幾乎所有的字符串處理方法都要做內(nèi)存分配，該問題長(zhǎng)期以來一直為人所詬病。在解析JSON、XML等格式時(shí)，substring方法常會(huì)產(chǎn)生成百上千的微小字符串分配。這不僅耗費(fèi)了大量時(shí)間生成拷貝，而且對(duì)垃圾回收造成了很大的壓力。這并非應(yīng)用開發(fā)人員所能掌控的。
這種做法有其合理性。與.NET一樣，在Java中字符串也是不可變的。而Java自帶的substring方法并不分配新的字符串，它創(chuàng)建一個(gè)指向原始字符串的指針。雖然Java的substring方法無需分配內(nèi)存，但是存在著內(nèi)存泄漏的風(fēng)險(xiǎn)。一個(gè)字符串substring方法可以保留5MB字符串不被垃圾回收（這個(gè)問題相當(dāng)惡劣，因此在Java 1.7u6版中做了更改，substring方法做內(nèi)存分配）。
在“Span
這一更改還需要重新實(shí)現(xiàn)更高效的基本類型解析方法，例如Int32.Parse和Inta32.TryParse等。理想情況下，這些方法將會(huì)加入到基類庫(kù)（BCL，Base Class Library）中，而不是以單獨(dú)庫(kù)的方式提供。這就回到了.NET Framework、Standard和Core的對(duì)比問題上。
毫無疑問，可以加快對(duì).NET Core的更改過程。除了操作系統(tǒng)特定的功能，新特性將做優(yōu)先更改。否則，只有得到所有.NET/Mono的各種實(shí)體（incarnation）支持的新特性，才會(huì)出現(xiàn)在.NET Standard中。雖然從理論上講，這些實(shí)體也歸屬于Microsoft的，但是新特性的添加依然會(huì)是一個(gè)冗長(zhǎng)的過程。
因此，在開發(fā)ASP.NET Core的過程中，基于ASP.NET進(jìn)行構(gòu)建是合乎情理的。這使得新的API在提交標(biāo)準(zhǔn)化前，得到真實(shí)用例的精煉。
默認(rèn)編碼上的考慮
并非所有開發(fā)人員都了解，在.NET內(nèi)部使用的是UTF16字符串。除了實(shí)現(xiàn)文件或網(wǎng)絡(luò)I/O處理之外，對(duì)于大部分用例，開發(fā)人員都無需考慮編碼問題。
Web應(yīng)用主要基于UTF8編碼。同樣，在處理大部分用例時(shí)，服務(wù)器端開發(fā)人員也無需考慮編碼問題。只需確保無論使用何種內(nèi)部格式，最終都會(huì)轉(zhuǎn)換為UTF8編碼。
當(dāng)需考慮性能時(shí)，這種做法就存在問題。所有的Web請(qǐng)求最初都是以UTF8編碼的，需要在被.NET理解前轉(zhuǎn)化為UTF16編碼。反之，所有來自.NET服務(wù)器的響應(yīng)，需要由UTF16編碼轉(zhuǎn)化為UTF8編碼。
現(xiàn)在已有一些建議方法，意在消除這種轉(zhuǎn)換的必要。一種做法創(chuàng)建了Utf8String類并匹配字符串處理庫(kù)，之后就可以新建直接操作類的解析庫(kù)。這一做法是完全“明確征得同意”（Opt In）的，因此風(fēng)險(xiǎn)很低。
更全面的建議是由Matt Warren提出的，稱為“緊湊字符串（Compact String）實(shí)現(xiàn)”。該建議受到了OpenJDK中類似建議的啟發(fā)，它會(huì)在字符串中添加一個(gè)類型字段，用于指示所使用的編碼。這是一種更大程度上的更改，對(duì)Span
查看英文原文：What ASP.NET Core May Bring to the .NET Framework’s String Handling
京公網(wǎng)安備 11010502049343號(hào)