NSCache和NSURLCache、網路緩存優化

来源:http://www.cnblogs.com/Mike-zh/archive/2016/02/24/5210169.html
-Advertisement-
Play Games

本文目錄 一種緩存優化方案 響應頭'Last Modified'和請求頭'If Modified Since' 'Keep Alive'響應頭和不離線的URLSession 'Expires'響應頭 這篇文章的意義 正文開始 首先要說一件重要的事： NSCache和NSURLCache一點關係也沒有


本文目錄
正文開始

首先要說一件重要的事：
NSCache和NSURLCache一點關係也沒有
NSCache和NSURLCache一點關係也沒有
NSCache和NSURLCache一點關係也沒有

然後我推薦大家閱讀一下這兩篇文章：
南峰子Foundation:NSCache
matttNSURLCache

需要註意的一點是：
設置NSURLCache的大小時，大多使用下麵的代碼

- (BOOL)application:(UIApplication *)application
    didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024
                                                       diskCapacity:20 * 1024 * 1024
                                                           diskPath:nil];
  [NSURLCache setSharedURLCache:URLCache];
}

但是即使沒有這兩句代碼，iOS也會自動參與緩存的，只不過使用的是系統創建的NSURLCache類，同樣是可以通過NSURLCache的sharedURLCache方法獲取。

在某些情況下，應用中的系統組件會將緩存的記憶體容量設為0MB，這就禁用了緩存。解決這個行為的一種方式就是通過自己的實現子類化NSURLCache，拒絕將記憶體緩存大小設為0。如可以使用如下代碼進行設置：

@interface MKNonZeroingURLCache : NSURLCache

@end

@implementation MKNonZeroingURLCache

- (void)setMemoryCapacity:(NSUInteger)memoryCapacity {
    if (memoryCapacity == 0) {
        return;
    }
    [super setMemoryCapacity:memoryCapacity];
}

@end

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    
    MKNonZeroingURLCache *urlCache = [[MKNonZeroingURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024 diskCapacity:20 * 1024 * 1024 diskPath:nil];
    [NSURLCache setSharedURLCache:urlCache];
    
    return YES;
}
// ...
@end

另外，在應用沒有運行的狀態下，如系統遇到磁碟空間太小的情況，系統也會主動清除一些磁碟緩存的。

說點題外話：setSharedURLCache:這個方法的命名和編程行為也是可以學習的。它告訴我們，單例的創建並不都是一成不變的使用sharedXXX方法，也可以使用一個setSharedXXX:傳遞一個自定義的本類對象，雖然單例對象是外部創建而不是預設的，但是這樣創建之後sharedXXX方法依然是獲取單例的方法。

本篇文章主要介紹一種網路緩存優化的策略，實際上這個優化方案是提升網路性能的一個小方案。提升網路性能是一個大的課題，它主要包括以下幾個方面的改善：

網路請求性能優化的策略
一.減少請求帶寬
1.請求壓縮
2.響應壓縮
二.降低請求延遲
如：為NSURLReqeust開啟管道支持
三.避免網路請求
主要是使用緩存優化

回到頂部

一種緩存優化方案

HTTP協議規格說明定義ETag為“被請求變數的實體值”。另一種說法是，ETag是一個可以與Web資源關聯的記號（token）。Web資源可以是一個web頁面、json或xml數據、文件等。Etag有點類似於文件hash或者說是信息摘要。

在瀏覽器預設的行為中，當進行一次URL請求，服務端會返回'Etag'響應頭，下次瀏覽器請求相同的URL時，瀏覽器會自動將它設置為請求頭'If-None-Match'的值。伺服器收到這個請求之後，就開始做信息校驗工作將自己本次產生的Etag與請求傳遞過來的'If-None-Match'對比，如果相同，則返回HTTP狀態碼304，並且response數據體中沒有數據。

進一步剖析這個過程：第二次請求的時候從哪裡獲取到'Etag'的值並賦給請求頭'If-None-Match'的？自然是瀏覽器的緩存中取出的。那麼瀏覽器收到304狀態碼之後又幹了什麼？剛纔說到response數據體中沒有數據，但是瀏覽器仍需載入頁面，它會從緩存中讀取上次緩存的頁面。

上面的瀏覽器和伺服器的配合完成了這樣一系列的工作：

if (本地沒有緩存) {
    進行第一次請求
} else {本地有緩存
    取出上次response的Etag，作為這次請求的'If-None-Match'值
    進行網路請求
    if (伺服器給的HTTP狀態碼 == 304) {
        // response的數據體為空，減少了一次數據傳輸
        // 緩存存在的先決條件滿足，從緩存中取數據
    } else {
        // 不是304,說明請求的內容改變了，伺服器給了新的數據,數據體不空
        // 使用最新的數據
    }
}

然而上面說的一大通都只是瀏覽器的行為，並不是iOS請求的預設行為，對於iOS開發而言，雖然不需要手動地管理緩存，但緩存策略會對上面的行為有影響。
iOS中定以的URLRequest緩存策略有以下幾種：

typedef NS_ENUM(NSUInteger, NSURLRequestCachePolicy)
{
    NSURLRequestUseProtocolCachePolicy = 0,

    NSURLRequestReloadIgnoringLocalCacheData = 1, // 從不讀取緩存，但請求後將response緩存起來
    NSURLRequestReloadIgnoringLocalAndRemoteCacheData = 4, // Unimplemented
    NSURLRequestReloadIgnoringCacheData = NSURLRequestReloadIgnoringLocalCacheData,

    // 以下兩種在取緩存時，可能取到的是過期數據
    NSURLRequestReturnCacheDataElseLoad = 2, // 緩存中沒有才去發起請求載入，有就不進行網路請求了
    NSURLRequestReturnCacheDataDontLoad = 3, // 緩存中沒有不載入，絕不發起網路請求,緩存中沒有則返回錯誤

    NSURLRequestReloadRevalidatingCacheData = 5, // Unimplemented
};

我們著重看一下預設緩存策略UseProtocolCachePolicy和忽略緩存的策略ReloadIgnoringLocalCacheData,

當使用預設的緩存策略時：

第一次請求一個URL時，會將response和數據緩存起來，
再次請求相同的URL時，會使用緩存中的Etag作為這次請求的request的'If-None-Match'值，這樣服務端會返回304並且response的數據體為空，此時iOS會幫助讀取緩存中的數據體，修改次請求的response，將HTTP狀態碼改為200，使用修改後的response和緩存中取到的data作為參數執行完成回調。

以上過程看起來似乎很完美，除了狀態碼不是304，其他的過程和瀏覽器幾乎一致。但是他有一個缺陷，在研究這個缺陷之前我們先弄清一個這麼一個事實：請求內容可以分為三種 1.腳本2.用數據渲染的頁面3.靜態文件。

對於腳本請求的處理，服務端是會忽略Etag，而每次都會處理，這樣返回的數據都是新的，返回HTTP狀態碼為200.
對於用數據渲染的頁面，伺服器會按照一定的計算規則，計算渲染之後的Etag，然後對比，再決定返回的是304或者200.
對於靜態文件，有些伺服器具有檢測靜態文件改變的能力，一旦文件發生改變，伺服器會立刻檢測到，從而返回200給客戶端，而有些伺服器檢測文件改變的功能是有延遲的，或者根本沒有這種功能，這樣即使文件的內容改變了，伺服器仍然認為沒有改變，於是對比Etag依然相等，結果返回304.（這次測試使用了apache和Express，預設配置下的apache對文件改變的檢測是有延遲的，Express則是實時檢測的）

根據以上的描述就會暴露出使用預設緩存策略的一點劣勢，如果伺服器不能實時檢測文件改變狀態，那麼文件是否改變的比對結果是不准確的。最糟糕的情況就是：當文件改變了，伺服器認為仍然沒有改變，從而返回了304，而沒有攜帶最新的數據。

ReloadIgnoringLocalCacheData策略時：

每次請求前都會忽略緩存，request的header從來不會附帶'If-None-Match'值, 伺服器每次處理成功後都是返回200,這樣每次都會拿到伺服器的數據(每次response的Date頭都是新的值)，伺服器返回的response帶有完整的數據體。iOS接收到數據之後，將response和數據緩存，並作為參數執行完成回調。

這裡我們也能夠看到使用ReloadIgnoringLocalCacheData策略暴漏出來的缺點：儘管伺服器端的文件確實沒有改變，但iOS依然不使用本地已有的緩存，而每次服務端還要將數據發給客戶端，這樣是多麼浪費帶寬！

用這個不好，用這個也不好，到底該如何

我們期望的狀態是這樣的：
無論伺服器怎麼做的配置，都希望文件是否改變的檢查結果是最準確的，返回200自然不要多做什麼處理，如果返回304，則從緩存中取到數據。

於是進行瞭如下的緩存優化方案：

- (void)refreshedRequest:(NSString *)urlString success:(void (^)(NSHTTPURLResponse *httpResponse, id responseData))successs failure:(void (^)(NSError *error))failure {
    NSMutableURLRequest *urlRequest = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:urlString]];
    
    NSURLCache *urlCache = [NSURLCache sharedURLCache];
    NSCachedURLResponse *cacheURLResponse = [urlCache cachedResponseForRequest:urlRequest];
    if (cacheURLResponse) {
        NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *)cacheURLResponse.response;
        NSString *cachedResponseEtag = [httpResponse.allHeaderFields objectForKey:@"Etag"];
        if (cachedResponseEtag) {
            [urlRequest setValue:cachedResponseEtag forHTTPHeaderField:@"If-None-Match"];
        }
    }

    [urlRequest setCachePolicy:NSURLRequestReloadIgnoringCacheData];
    [[[NSURLSession sharedSession] dataTaskWithRequest:urlRequest completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
        if (!error && successs) {
            NSHTTPURLResponse *newHttpResponse = (NSHTTPURLResponse *)response;
            if (newHttpResponse.statusCode == 304) {
                // cached in local
                successs(newHttpResponse, cacheURLResponse.data);
            } else {
                // refreshed from server
                successs(newHttpResponse, data);
            }
        } else {
            if (failure) {
                failure(error);
            }
        }
    }] resume];
}

這樣每次請求都使用忽略緩存的策略，但是要附帶著"If-None-Match"頭，它的值是上次請求的響應頭"Etag"的值，於是伺服器會每次都實時檢查文件的修改狀態，得到一個準確的狀態值，最後決定返回304還是200。若是200，iOS則直接使用新的response和新的數據;如果是304，則使用新的response和緩存中的data。
這樣既能夠獲取到最新的數據有能夠節約帶寬。兩全其美。
回到頂部

不可忽視的響應頭'Last-Modified'和請求頭'If-Modified-Since'

在上面說的服務端對文件的驗證只涉及到ETag，而實際上服務端的驗證過程比這個複雜，還需要使用'Last-Modified'值。'Last-Modified'值在伺服器處理階段代表著文件的上次修改時間，在處理結束後作為一個響應頭放到response中。如果在請求中添加了'If-Modified-Since'頭，並將這個值設置為上次請求時得到的響應頭'Last-Modified'的值，那麼這次請求，伺服器的處理過程如下：

if 計算出的'ETag' != 請求頭中的'If-Non-Match' || 查詢到的'Last-Modified'(上次修改的時間) != 請求頭中的'If-Modified-Since'
    返回的response狀態碼200 和 數據
else
   返回的reponse狀態碼304

'Etag'與'Last-Modified'不同的是：
'Etag'更強調的是實體內容，它代表著文件的信息摘要，它是由伺服器計算出來的類似於md5的值，使用'Etag'的驗證是基於內容的。
'Last-Modified'實際上就是文件上次修改的時間，僅僅是一個時間戳，是從文件屬性讀取出來的，使用'Last-Modified'的驗證是基於時間的。

瞭解了這些我們就可以改造上面的代碼，使用雙重驗證：

- (void)refreshedRequest:(NSString *)urlString success:(void (^)(NSHTTPURLResponse *httpResponse, id responseData))successs failure:(void (^)(NSError *error))failure {
    NSMutableURLRequest *urlRequest = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:urlString]];
    
    NSURLCache *urlCache = [NSURLCache sharedURLCache];
    NSCachedURLResponse *cacheURLResponse = [urlCache cachedResponseForRequest:urlRequest];
    if (cacheURLResponse) {
        NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *)cacheURLResponse.response;
        NSString *cachedResponseEtag = [httpResponse.allHeaderFields objectForKey:@"Etag"];
        if (cachedResponseEtag) {
            [urlRequest setValue:cachedResponseEtag forHTTPHeaderField:@"If-None-Match"];
        }
        // 增加對上次修改時間的驗證
        NSString *cachedResponseModified = [httpResponse.allHeaderFields objectForKey:@"Last-Modified"];
        if (cachedResponseModified) {
            [urlRequest setValue:cachedResponseModified forHTTPHeaderField:@"If-Modified-Since"];
        }
    }

    // ....
}

不過現在比較悲劇的是，各個web容器已經將Etag值的計算方法玩壞了，在計算Etag是依賴的參數不僅僅有文件的內容信息，還有文件的修改時間，這樣一來，Etag的功能就相當於最初設計的Etag的功能+Last-Modified的功能。所以說上面的改造代碼沒有什麼實在意義，只使用Etag就可以。

為了Etag確實不僅僅是基於內容的驗證值，我做了一下測試：
先進行訪問一次對http://127.0.0.1/blog文件(裡面只有幾個字元的文本文件)的訪問，得到如下的response：

<NSHTTPURLResponse: 0x7fe143d170d0> { URL: http://127.0.0.1/blog } { status code: 304, headers {
    Connection = "Keep-Alive";
    Date = "Tue, 23 Feb 2016 04:16:36 GMT";
    Etag = "\"14-52c66cf22bd40\"";
    "Keep-Alive" = "timeout=5, max=100";
    Server = "Apache/2.4.16 (Unix) PHP/5.5.29";
} }
<7b0a0922 74657374 223a2268 656c6c6f 222c0a7d>

此時文件的MD5為：

MD5 (blog) = 35466082cffbc8fe4529a18a55f0260e

然後修改服務端文件的修改時間，但並沒有修改文件的內容

# 將修改時間更改為2016年1月1日0點0分
touch -mt 201601010000 blog

這時文件的MD5值為：

MD5 (blog) = 35466082cffbc8fe4529a18a55f0260e # 沒有改變

再次進行訪問，這次訪問使用忽略緩存的協議，並且帶上Etag值，而不帶修改時間值，得到的response是：

<NSHTTPURLResponse: 0x7fe143c0c870> { URL: http://127.0.0.1/blog } { status code: 200, headers {
    "Accept-Ranges" = bytes;
    Connection = "Keep-Alive";
    "Content-Length" = 20;
    Date = "Tue, 23 Feb 2016 04:20:42 GMT";
    Etag = "\"14-52833bf364000\"";
    "Keep-Alive" = "timeout=5, max=100";
    "Last-Modified" = "Thu, 31 Dec 2015 16:00:00 GMT";
    Server = "Apache/2.4.16 (Unix) PHP/5.5.29";
} }<7b0a0922 74657374 223a2268 656c6c6f 222c0a7d>

數據沒有變，但是Etag仍然改變了。(以上是在apache+PHP的測試結果,使用Express也是這樣)
回到頂部

'Keep-Alive'響應頭和不離線的URLSession

"Keep-Alive"響應頭會控制客戶端進行發起請求的間隔。例如：

"Keep-Alive" = "timeout=5, max=100"

其中timeout值代表著最小間隔，也就是說如果這次發送請求之後，要在5秒之後發起的請求才會進行網路訪問。
max值代表著最大的嘗試次數，在timeout時間內發起請求會使這個值-1直到變為0再變為設定值。
以上兩個值就控制著這樣一個過程：剛剛訪問的一個請求，獲取到了數據併進行了緩存，如果還沒有過去5秒再次發起同樣的請求，則不進行網路訪問，直接讀取緩存並且將響應頭修改為"Keep-Alive" = "timeout=5, max=99"，如果這次請求還沒過去5秒又進行請求，同樣不進行網路訪問，直接讀取緩存，修改響應頭為"Keep-Alive" = "timeout=5, max=98".....直到max變為0，再來一次又變回100.

看到這裡我們又能體會到緩存優化的必要性，服務端當設定了這個響應頭時，也可以不受影響地拿到實時數據。

這裡還要說的一個問題是Session的線上狀態，例如上面的訪問中，每次訪問需要使用相同的session才能做到max值不斷-1，如果session值改變了，相當於一次新的請求，獲得的始終是"Keep-Alive" = "timeout=5, max=100",也就是說，下麵的兩種狀況是不同的。

- (void)onlyUseOneSession {
    NSMutableURLRequest *urlRequest = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:kURLString]];
    
    [[[NSURLSession sharedSession] dataTaskWithRequest:urlRequest completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
        // ...
    }] resume];
}

- (void)useDifferentSession {
    NSMutableURLRequest *urlRequest = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:kURLString]];
    
    NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration]];
    
    [[session dataTaskWithRequest:urlRequest completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
        // ...
    }] resume];
    
    session = nil;
}

iOS的URLSession相當於一個瀏覽器視窗，它們雖然能夠共用cookie和NSURLCache，但是每個session因配置不同和狀態不同，會對相同url的訪問有差別的。如果訪問使用相同Session，那麼就能公用一套配置和訪問歷史等信息，管理起來也是非常方便的，而如果使用的Session都是一些局部變數，那麼使用之後就會離線，而且再也無法獲取到這些session。因此在開發中建議使用[NSURLSession sharedSession];
回到頂部

'Expires'響應頭

這個響應頭的值也是一個時間，代表著連接過期時間，它允許客戶端在這個時間之前不去髮網絡請求，與'Keep-Alive'功能相似，但是'Keep-Alive'指定的是時間長度，而'Expires'指定的是時刻。

當服務端返返迴響應頭有這個值，依然是使用優化過的緩存比較穩妥。

這篇文章的意義

有關針對'Etag'和HTTP304狀態碼進行優化緩存的文章不勝枚舉，那麼為什麼還要這樣一篇文章。我想原因主要有以下幾個：
1.大家都知道這個緩存的原理，可是沒有講得太明白，或者乾脆直接就不講直接上代碼。以至於有人存在這種想法：我每次都用預設緩存策略也好好的，你為什麼要讓我優化。我認為本篇文章對於預設緩存策略和忽略緩存策略二者的優缺點描述還是很有必要的。
2.很多人的代碼並沒有建立在使用系統的NSURLCache的基礎上，更有甚者，直接使用自定義的屬性存取'Etag'的值，apple看到這樣的代碼會哭的，那麼本地緩存中信息存在的意義是什麼。
3.我個人比較想讓大家讀一下NSCache和NSURLCache的那幾篇文章，對平常的工作確實相當有幫助的。
4.雖然我不是mattt，但我覺得mattt從未諷刺過SDWebImage。請不要將緩存和持久化存儲混為一談，也不要將文件緩存和URL緩存混為一談。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 關於在for迴圈中綁定事件列印變數i是最後一次。
    其實函數引用的外部變數都是最後一次的值。 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title> <style> #box{ width:100px; height:100px; b
  • 【AngularJS學習筆記】01 序
    AngularJS通過新的屬性與表達式來擴展HTML，有一種很形象的叫法，定義它為聲明式語言。 為剋服HTML在構建應用上的不足而設計! 這是它的目標。 它的官網進不去，應該是被牆了，這是goegle的團隊弄的。所以找了個應用AngularJS的網站，然後另存為下來的。 以一段簡單的代碼開頭 <di
  • 學習筆記 - 數據綁定之knockout
    參考： http://www.cnblogs.com/TomXu/archive/2011/11/21/2257154.html http://knockoutjs.com/documentation/introduction.html 複習：AngularJS的數據綁定 顯示文本 <p>{{gre
  • HTML5拖拽實現示例
    HTML5現在前端圈中，已然成為一個不那麼新的技術辭彙了，很多公司也把HTML5也當成了硬性的技能要求，但是很多前端恐怕都不瞭解HTML5的拖拽怎麼實現吧。 看了下極客學院的視頻，大概的瞭解了下思路。所以整理備份，便於以後查閱。先上示例： index.html 1 <!doctype html> 2
  • UICollectionView 簡單的使用和註意事項
    UICollectionView 在創建的時候，要給它一個UICollectionViewFlowLayout (不然會崩潰)，就像tableview一樣，也要為它註冊自定義的cell。 UICollectionViewFlowLayout *flowLayout = [[UICollectionV
  • ios 自動(手動)轉屏
    一、第一次做轉屏的時候走了不少彎路,過一段時間不寫,發現忘了差不多了,還好有度娘和google,讓我很快找到感覺，下麵來談談我對轉屏的瞭解（有不對的地方或更好的方法請留言，不勝感激！！！） iOS6前的轉屏比較簡單就一個方法 - (BOOL)shouldAutorotateToInterfaceOr
  • 手把手教你Android來去電通話自動錄音的方法
    我們在使用Android手機打電話時，有時可能會需要對來去電通話自動錄音，本文就詳細講解實現Android來去電通話自動錄音的方法，大家按照文中的方法編寫程式就可以完成此功能。 來去電自動錄音的關鍵在於如何監聽手機電話狀態的轉變： 1）來電的狀態的轉換如下（紅色標記是我們要用到的狀態） 空閑（IDE
  • iOS開發之AFN的基本使用
    本篇將從四個方面對iOS開發中經常使用到的AFNetworking框架進行講解： 一、什麼是 AFN 二、為什麼要使用 AFN 三、AFN 怎麼用 三、AFN和ASI的區別 一、什麼是 AFN AFN 全稱為 AFNetworking，是一個構建與在 NSURLConnection、NSOperat
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類