提示：英文原文寫於2009年，當時的Firefox和最新版的Firefox，介面也有很大改動。以下是正文。

花了數小時閱讀了如潮的好評，Bob最終迫不及待為他購買的托斯卡納全脂牛奶點選了“進行結算”，然後……

哇！剛剛發生了什麼?

在點選按鈕過後的220毫秒時間內，發生了一系列有趣的事情，火狐瀏覽器（Firefox）不僅改變了位址列顏色，而且在瀏覽器的右下角出現了一個小鎖頭的標誌。在我最喜歡的網際網路工具Wireshark的幫助下，我們可以通過一個經過略微調整的用於debug的火狐瀏覽器來探究這一過程。

根據RFC 2818標準（譯者注：RFC 2818為HTTP Over TLS-網路協議），火狐瀏覽器自動通過連線Amazon.com的443埠來響應HTTPS請求。

很多人會把HTTPS和網景公司（Netscape）於上世紀九十年代中期建立的SSL（安全套接層）聯絡起來。事實上，隨著時間的推移，這兩者之間的關係也慢慢淡化。隨著網景公司漸漸的失去市場份額，SSL的維護工作移交給了Internet工程任務組（IETF）。由網景公司釋出的第一個版本被重新命名為TLS 1.0（安全傳輸層協議 1.0），並於1999年1月正式釋出。考慮到TLS已經發布了將近10年，如今已經很難再見到真正的SSL通訊了。

客戶端問候（Client Hello）

TLS將全部的通訊以不同方式包裹為“記錄”（Records）。我們可以看到，從瀏覽器發出的第一個位元組為0x16（十進位制的22），它表示了這是一個“握手”記錄。

接下來的兩個位元組是0x0301，它表示了這是一條版本為3.1的記錄，同時也向我們表明了TLS1.0實際上是基於SSL3.1構建而來的。

整個握手記錄被拆分為數條資訊，其中第一條就是我們的客戶端問候（Client Hello），即0x01。在客戶端問候中，有幾個需要著重注意的地方：

•  隨機數：

在客戶端問候中，有四個位元組以Unix時間格式記錄了客戶端的協調世界時間（UTC）。協調世界時間是從1970年1月1日開始到當前時刻所經歷的秒數。在這個例子中，0x4a2f07ca就是協調世界時間。在他後面有28位元組的隨機數，在後面的過程中我們會用到這個隨機數。

• SID（Session ID）：

在這裡，SID是一個空值（Null）。如果我們在幾秒鐘之前就登陸過了Amazon.com，我們有可能會恢復之前的會話，從而避免一個完整的握手過程。

• 密文族（Cipher Suites）：

密文族是瀏覽器所支援的加密演算法的清單。整個密文族是由推薦的加密演算法“TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA”和33種其他加密演算法所組成。別擔心其他的加密演算法會出現問題，我們一會兒就會發現Amazon也沒有使用推薦的加密演算法。

•  Server_name擴充套件：

通過這種方式，我們能夠告訴Amazon.com：瀏覽器正在試圖訪問https://www.amazon.com。這確實方便了很多，因為我們的TLS握手時間發生在HTTP通訊之前，而HTTP請求會包含一個“Host頭”，從而使那些為了節約成本而將數百個網站域名解析到一個IP地址上的網路託管商能夠分辨出一個網路請求對應的是哪個網站。傳統意義上的SSL同樣要求一個網站請求對應一個IP地址，但是Server_name擴充套件則允許伺服器對瀏覽器的請求授予相對應的證書。如果沒有其他的請求，Server_name擴充套件應該允許瀏覽器訪問這個IPV4地址一週左右的時間。

伺服器問候（Server Hello）

Amazon.com回覆的握手記錄由兩個比較大的包組成（2551位元組）。記錄中包含了0x0301的版本資訊，意味著Amazon同意我們使用TLS1.0訪問的請求。這條記錄包含了三條有趣的子資訊：

1.伺服器問候資訊（Server Hello）(2):

1. 我們得到了伺服器的以Unix時間格式記錄的UTC和28位元組的隨機數。
2. 32位元組的SID，在我們想要重新連線到Amazon.com的時候可以避免一整套握手過程。
3. 在我們所提供的34個加密族中，Amazon挑選了“TLS_RSA_WITH_RC4_128_MD5”（0x0004）。這就意味著Amazon會使用RSA公鑰加密演算法來區分證書籤名和交換金鑰，通過RC4加密演算法來加密資料，利用Md5來校驗資訊。我們之後會深入的研究這一部分內容。我個人認為，Amazon選擇這一密碼組是有其自身的原因的。在我們所提供的密碼族中，這一加密組的加密方式是CPU佔用最低的，這就允許Amazon的每臺伺服器接受更多的連線。當然了，也許還有一個原因是，Amazon是在向這三種加密演算法的發明者Ron Rivest（羅恩·李·維斯特）致敬。

2.證書資訊（11）：

這段巨大的資訊共有2464位元組，其證書允許客戶端在Amazon伺服器上進行認證。這個證書其實並沒有什麼奇特之處，你能通過瀏覽器瀏覽它的大部分內容。

3.伺服器問候結束資訊（14）：

這是一個零位元組資訊，用於告訴客戶端整個“問候”過程已經結束，並且表明伺服器不會再向客戶端詢問證書。

校驗證書

此時，瀏覽器已經知道是否應該信任Amazon.com。在這個例子中，瀏覽器通過證書確認網站是否受信，它會檢查 Amazon.com 的證書，並且確認當前的時間是在“最早時間”2008年8月26日之後，在“最晚時間”2009年8月27日之前。瀏覽器還會確認證書所攜帶的公共金鑰已被授權用於交換金鑰。

為什麼我們要信任這個證書？

證書中所包含的簽名是一串非常長的大端格式的數字：

任何人都可以向我們傳送這些位元組，但我們為什麼要信任這個簽名？為了解釋這個問題，我們首先要回顧一些重要的數學知識：

RSA加密演算法的基礎介紹

人人常常會問，程式設計和數學之間有什麼聯絡？證書就為數學在程式設計領域的應用提供了一個實際的例子。Amazon的伺服器告訴我們需要使用RSA演算法來校驗證書籤名。什麼又是RSA演算法呢？RSA演算法是由麻省理工（MIT）的Ron Rivest、Adi Shamirh和Len Adleman（RSA命名各取了三人名字中的首字母）三人於上世紀70年代建立的。三位天才的學者結合了2000多年數學史上的精華，發明了這種簡潔高效的演算法：

選取兩個較大的初值p和q，相乘得n；n = p*q  接下來選取一個較小的數作為加密指數e，d作為解密指數是e的倒數。在加密的過程中，n和e是公開資訊，解密金鑰d則是最高機密。至於p和q，你可以將他們公開，也可以作為機密保管。但是一定要記住，e和d是互為倒數的兩個數。

假設你現在有一段資訊M（轉換成數字），將其加密只需要進行運算：C ≡ Me (mod n)

這個公式表示M的e次冪，mod n表示除以n取餘數。當這段密文的接受者知道解密指數d的時候就可以將密文進行還原：Cd ≡ (Me)d ≡ Me*d ≡ M1 ≡ M (mod n)

有趣的是，解密指數d的持有者還可以將資訊M進行用解密指數d進行加密：Md ≡ S (mod n)

加密者將S、M、e、n公開之後，任何人都可以獲得這段資訊的原文：Se ≡ (Md)e ≡ Md*e ≡ Me*d ≡ M1 ≡ M (mod n)

如同RSA的公共金鑰加密演算法經常被稱之為非對稱演算法，因為加密金鑰（在我們的例子中為e）和解密金鑰（在我們的例子中是d）並不對稱。取餘運算的過程也不像我們平常接觸的運算（諸如對數運算）那樣簡單。RSA加密演算法的神奇之處在於你可以非常快速的進行資料的加密運算，即 ，但是如果沒有解密密碼d，你將很難破解出密碼，即運算 將不可能實現。正如我們所看到的，通過對n進行因式分解而得到p和q，再推斷出解密金鑰d的過程難於上青天。

簽名驗證

在使用RSA加密演算法的時候，最重要的一條就是要確保任何涉及到的數字都要足夠複雜才能保證不被現有的計算方法所破解。這些數字要多複雜呢？Amazon.com的伺服器是利用“VeriSign Class 3 Secure Server CA”來對證書進行簽名的。從證書中，我們可以看到這個VeriSign（電子簽名校驗器，也稱威瑞信公司）的係數n有2048位二進位制數構成，換算成十進位制足足有617位數字：

1890572922 9464742433 9498401781 6528521078 8629616064 3051642608 4317020197 7241822595 6075980039 8371048211 4887504542 4200635317 0422636532 2091550579 0341204005 1169453804 7325464426 0479594122 4167270607 6731441028 3698615569 9947933786 3789783838 5829991518 1037601365 0218058341 7944190228 0926880299 3425241541 4300090021 1055372661 2125414429 9349272172 5333752665 6605550620 5558450610 3253786958 8361121949 2417723618 5199653627 5260212221 0847786057 9342235500 9443918198 9038906234 1550747726 8041766919 1500918876 1961879460 3091993360 6376719337 6644159792 1249204891 7079005527 7689341573 9395596650 5484628101 0469658502 1566385762 0175231997 6268718746 7514321

（如果你想要對這一大串數字進行分解因式獲得p和q，那就祝你好運！順便一提，如果你真的計算出了p和q，那你就破解了Amazon.com數字簽名證書了！）

這個VeriSign的加密金鑰e是 。當然，他們將解密金鑰d保管得十分嚴密，通常是在擁有視網膜掃描和荷槍實彈的警衛守護的機房當中。在簽名之前，VeriSign會根據相關約定的技術文件，對Amazon.com證書上所提供的資訊進行校驗。一旦證書資訊符合相關要求，VeriSign會利用SHA-1雜湊演算法獲取證書的雜湊值（hash），並對其進行宣告。在Wireshark中，完整的證書資訊會顯示在“signedCertificate”（已簽名證書）中：

這裡應該是軟體的用詞不當，因為這一段實際上是指那些即將被簽名的資訊，而不是指那些已經包含了簽名的資訊。

實際上經過簽名的資訊S，在Wireshark中被稱之為“encrypted”（密文）。我們將S的e次冪除以n取餘數（即公式： ）就能計算出被加密的原文，其十六進位制如下：

0001FFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFF00302130 0906052B0E03021A05000414C19F8786 871775C60EFE0542 E4C2167C830539DB

根據PKCS#1 v1.5標準（譯者注：The Public-Key Cryptography Standards (PKCS)是由美國RSA資料安全公司及其合作伙伴制定的一組公鑰密碼學標準）規定：“第一個位元組是00，這樣就可以保證加密塊在被轉換為整數的時候比其加密引數要小。”第二個位元組為01，表示了這是一個私有金鑰操作（數字簽名就是私有金鑰操作的一種）。後面緊接著的一連串的FF位元組是為了填充資料，使得這一串數字變得足夠大（加大黑客惡意破解的難度）。填充數字以一個00位元組結束。緊接著的30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14這些位元組是PKCS#1 v2.1標準中用於說明這段雜湊值是通過SHA-1演算法計算而出的。最後的20位元組是SHA-1演算法所計算出來的雜湊值，即對未加密資訊的摘要描述。（譯者注：原文中這裡使用了帶引號的signedCertificate，根據作者前文描述，這應該是Wireshark軟體的bug，實際上應指的是未被加密的資訊。）

因為這段資訊的格式正確，且最後的雜湊值與我們獨立計算出來的校驗一致，所以我們可以斷定，這一定是知道“VeriSign Class 3 Secure Server CA”的解密金鑰d的人對它進行了簽名。而世界上只有VeriSign公司才知道這串金鑰。

當然了，我們也可以重複驗證這個“VeriSign Class 3 Secure Server CA”的證書的確是通過VeriSign公司的“第三類公私證書認證（Class 3 Public Primary Certification Authority）”進行簽名的。

但是，即便是這樣，我們為什麼要信任VeriSign公司？整個的信任鏈條就此斷掉了。

由圖可以看到，“VeriSign Class 3 Secure Server CA”對Amazon.com進行了簽名，而“VeriSign Class 3 Public Primary Certification Authority”對“VeriSign Class 3 Secure Server CA”進行了簽名，但是最頂部的“VeriSign Class 3 Public Primary Certification Authority”則對自己進行了簽名。這是因為，這個證書自從NSS（網路安全服務）庫中的certdata.txt 升級到1.4版之後就作為“受信任的根證書頒發機構”（譯者注：參照微軟官方翻譯）被編譯到了Mozilla產品中（火狐瀏覽器）。這段資訊是由網景公司的Robert Relyea於2000年9月6日提交的，並隨附以下注釋：

“由僅存的NSS編譯了框架。包含一個線上的certdata.txt文件，其中包含了我們受信的跟證書頒發機構（一旦我們獲得了其他受信機構的許可會陸續將他們新增進去）”。

這個舉動有著相當長遠的影響，因為這些證書的有效日期是從1996年1月28日到2028年1月1日。

肯·湯普遜（Ken Thompson）在他的《對深信不疑的信任》（譯者注：Reflections on Trusting Trust是肯湯普遜1983年獲得圖靈獎時的演說）的演說中解釋的很好：你最終還是要絕對信任某一人，在這個問題上沒有第二條路可走。在本文的例子中，我們就毫無保留的信任Robert Relyea做了一個正確的決定。我們同樣希望Mozilla在自己軟體中加入“受信任根證書頒發機構”這種行為也是合理的吧。

這裡需要注意的是：這一系列的證書和簽名只是用來形成一個信任鏈。在公共網際網路上，VeriSign的根證書被火狐瀏覽器完全信任的時間遠早於你接觸網際網路。在一個公司中，你可以建立自己的受信任的根證書頒發機構並把它安裝到任何人的計算機中。

相對的，你也可以購買VeriSign公司的業務，降低整個證書信任鏈的信任風險。通過第三方的認證機構（在這個例子裡是VeriSign公司）我們能利用證書建立起信任關係。如果你有類似於“悄悄話”的安全途徑來傳遞一個祕密的key，那你也可以使用一個預共享金鑰（PSK）來建立起信任關係。諸如TLS-PSK、或者帶有安全遠端密碼（SRP）的TLS擴充套件包都能讓我們使用預共享金鑰。不行的是，這些擴充套件包在應用和支援方面遠遠比不上TLS，所以他們有的時候並不實用。另外，這些替代選項需要額外德爾安全途徑進行保密資訊的傳輸，這一部分的開銷遠比我們現在正在應用的TLS龐大。換句話說，這也就是我們為什麼不應用那些其他途徑構建信任關係的原因。

言歸正傳，我們所需要的最後確認的資訊就是在證書上的主機名跟我們預想的是一樣的。Nelson Bolyard在SSL_AuthCertificate 函式中的註釋為我們解釋其中的原因：

“SSL連線的客戶端確認證書正確，並檢查證書中所對應的主機名是否正確，因為這是我們應對中間人攻擊的唯一方式！” （譯者注：中間人攻擊是一種“間接”的入侵攻擊，這種攻擊模式是通過各種技術手段將受入侵者控制的一臺計算機虛擬放置在網路連線中的兩臺通訊計算機之間，這臺計算機就稱為“中間人”。）

123	/* cert is OK. This is the client side of an SSL connection. * Now check the name field in the cert against the desired hostname. * NB: This is our only defense against Man-In-The-Middle (MITM) attacks! */

這樣的檢查是為了防止中間人攻擊：因為我們對整個信任鏈條上的人都採取了完全信任的態度，認為他們並不會進行黑客行為，就像我們的證書中所聲稱它是來自Amazon.com，但是假如他的真實來源並非Amazon.com，那我們可能就有被攻擊的危險。如果攻擊者使用域名汙染（DNS cache poisoning）等技術對你的DNS伺服器進行篡改，那麼你也許會把黑客的網站誤認為是一個安全的受信網站（諸如Amazon.com），因為位址列顯示的資訊一切正常。這最後一步對證書頒發機構的檢查就是為了防止這樣的事情發生。

隨機密碼串（Pre-Master Secret）

現在我們已經瞭解了Amazon.com的各項要求，並且知道了公共解密金鑰e和引數n。在通訊過程中的任何一方也都知道了這些資訊（佐證就是我們通過Wireshark獲得了這些資訊）。現在我們所需要做的事情就是生成一串竊密者/攻擊者都不能知道的隨機密碼。這並不像聽上去的那麼簡單。早在1996年，研究人員就發現了網景瀏覽器1.1的偽隨機數發生器僅僅利用了三個引數：當天的時間，程序ID和父程序ID。正如研究人員所指出的問題：這些用於生成隨機數的引數並不具有隨機性，而且他們相對來說比較容易被破解。

因為一切都是來源於這三個隨機數引數，所以在1996，利用當時的機器僅需要25秒鐘的時間就可以破解一個SSL通訊。找到一種生成真正隨機數的方法是非常困難的，如果你不相信這一點，那就去問問Debian OpenSSL的維護工程師吧。如果隨機數的生成方式遭到破解，那麼建立在這之上的一系列安全措施都是毫無意義的。

在Windows作業系統中，用於加密目的隨機數都是利用一個叫做CryptGenRandom的函式生成的。這個函式的雜湊表位對超過125個來源的資料進行抽樣！火狐瀏覽器利用CryptGenRandom函式和它自身的函式來構成它自己的偽隨機數發生器。（譯者注：之所以稱之為偽隨機數是因為真正意義上的隨機數演算法並不存在，這些函式還是利用大量的時變、量變引數來通過複雜的運算生成相對意義上的隨機數，但是這些數之間還是存在統計學規律的，只是想要找到生成隨機數的過程並不那麼容易）。

我們並不會直接利用生成的這48位元組的隨機密碼串，但是由於很多重要的資訊都是由他計算而來的，所以對隨機密碼串的保密就顯得格外重要。正如我之前所預料到的，火狐瀏覽器對隨機密碼串的保密十分嚴格，所以我不得不編譯了一個用於debug的版本。為了觀察隨機密碼串，我還特地設定了SSLDEBUGFILE和SSLTRACE兩個環境變數。

其中，SSLDEBUGFILE顯示的就是隨機密碼串的值：

1 2 3 4

4456:SSL[131491792]:Pre-MasterSecret[Len:48] 0301bb7b0898a749dee8e9b89152ec81...{...I.....R.. 4cc2397bf6ba1c0ab1955029be02ade6L.9{......P).... ad6e113f20c466f06422577ee1067a3b.n.?.f.d"W~..z 相關推薦 struct和class的區別 觀察者模式 https連線 點選button收到點選事件，中間發生了什麼 提示：英文原文寫於2009年，當時的Firefox和最新版的Firefox，介面也有很大改動。以下是正文。 花了數小時閱讀了如潮的好評，Bob最終迫不及待為他購買的托斯卡納全脂牛奶點選了“進行結算”，然後…… 哇！剛剛發生了什麼? 在點選按鈕過後的220毫秒時間內，發生了一系 使用util包裏自帶的接口和類實現觀察者模式 註意 簡化 響應 cat pan hang sys ext main 之前的關於觀察者模式的文章，是用自己寫的Observable接口和Observer接口，然後進行實現。其實官方的util包下自帶有實現觀察者模式對應的接口和類，可以簡化我們的代碼結構。 比如我們可 重學 Java 設計模式：實戰觀察者模式「模擬類似小客車指標搖號過程，監聽訊息通知使用者中籤場景」  作者：小傅哥 部落格：[https://bugstack.cn](https://bugstack.cn) - `原創系列專題文章` >沉澱、分享、成長，讓自己和他人都能有所收穫！ 觀察者模式和發布/訂閱模式的區別 observe nbsp 初步 有時 觀察 觀察者 發生 狀態 發現 在事件總線(EventBus)的架構設計中，用到了發布/訂閱模式，但發現和觀察者模式挺接近，有時容易發生混淆，現試圖分清一下他們的關系。 觀察者模式的角色為觀察者(observer) 中介者模式和觀察者模式區別? observer server serve 有一個 obs 交互 進行 強調 一個 中介者(mediator)強調的是同事(colleague)類之間的交互 而觀察者(observer)中的目標類(subject)強調是目標改變後對觀察者進行統一的通訊 兩者非常相同的一點就 觀察者模式和事件監聽模式的區別 監聽機制 其他 不包含 機制 監聽 多態 場景 觀察者模式 特定 事件監聽模式更像是觀察者模式的進階。 觀察者模式中，‘主題’會在特定邏輯下通知所有‘觀察者’。如果這個通知不包含任何信息，那麽這種實現就是通常的觀察者模式。 如果‘主題’通知‘觀察者’的過程帶有一些<其 觀察者模式（Observer）和釋出（Publish/訂閱模式（Subscribe）的區別 觀察者模式（Observer）和釋出（Publish/訂閱模式（Subscribe）的區別 在翻閱資料的時候，有人把觀察者（Observer）模式等同於釋出（Publish）/訂閱（Subscribe）模式，也有人認為這兩種模式還是存在差異，而我認為確實是存在差異的，本質上的區別是排程的地方不同。 Java的回撥函式和觀察者模式的區別     前一段時間研究了一下設計模式，突然想到觀察者模式和回撥函式之間的聯絡，網上也沒有什麼人說清楚，便自己又仔細想了想，便有了如下觀點，歡迎各位大神前來拍磚！     首先，先闡述一下網上說的，網上先說這是完全不同的兩種東西，介面回撥是觀察者模式的實現，後者是一種設計模式 觀察者模式（Observer）和發布（Publish/訂閱模式（Subscribe）的區別 enc can 處理 ted cas clas script prot add 源地址：https://blog.csdn.net/qq_39877296/article/details/79103206 觀察者模式（Observer）和發布（Publish/訂閱模式（S 觀察者模式和釋出訂閱模式的區別 之前一直對觀察者模式和釋出訂閱模式的區別理解不深，正好這段時間在看vue原始碼的分析，vue資料雙向繫結也用到了釋出訂閱模式，於是 值類型和引用類型的區別，struct和class的區別 tro 處理 數據結構和算法 ron ever ring net string 分配 C#值類型和引用類型 1、簡單比較 　　值類型的變量直接存儲數據，而引用類型的變量持有的是數據的引用，數據存儲在數據堆中。 　　值類型（value type）：byte，short，int 觀察者模式與發布訂閱模式的區別 發布訂閱 簡單的 veh highlight event 對象 instance post 相對 觀察者模式是軟件設計模式的一種。在此種模式中，一個目標對象管理所有相依於它的觀察者對象，並且在它本身的狀態改變時主動發出通知。這通常透過呼叫各觀察者所提供的方法來實現。此種模式 PHP 觀察者模式和php實現 Observer Pattern BE pattern 修改 private ray 擴展 UNC array type 觀察者模式：　　觀察者模式(Observer Pattern)：定義對象間的一種一對多依賴關系，使得每當一個對象狀態發生改變時，其相關依賴對象皆得到通知並被自動更新。觀察者模式又叫做發布 觀察者模式和發布訂閱模式（上） nts 針對 處理 nds script 分享圖片 .data cto 這樣的 觀察者模式 定義：觀察者模式(Observer Pattern)：定義對象間的一種一對多依賴關系，使得每當一個對象狀態發生改變時，其相關依賴對象皆得到通知並被自動更新。 其中有兩個定義需要明確， 微信訂閱號的關註和消息推送中的觀察者模式 obs 取消 account bstr ans 定義 bubuko ros 17. 　　　　觀察者模式定義了一種一對多的依賴關系，讓多個觀察者對象同時監聽某一個主題對象，主體對象的狀態變化會通知所有觀察者對象。觀察者模式又叫做發布-訂閱模式、模型-視圖模式、源-監聽器模式 手遊客戶端的效能篇（二）----Unity和C#版之字串拼接，Struct和Class的區別與應用 接著上篇文章： 2、字串拼接（簡單，直接結論）        使用“a” + “b”在幾次（10次以內吧）連線是不會產生gc的但是大量連線就會產生；         連線多的用StringBuilder，內部 java和c++觀察者模式實現 觀察者模式是一種比較常用的設計模式，，採用介面，封裝類中動態變化的方法，定義物件間的依賴關係，一邊但一個物件狀態發生改變時，所有以來他的物件都發生改變。 簡單的說，就是一管多，即關鍵就是觀察者和被觀察者，學習這一部分看其他部落格這樣解釋，就是多個屌絲追一個白富美的模式，多個屌絲就是所謂的觀察 Unity之C#——委託與事件，觀察者模式，貓和老鼠事例 委託與事件，觀察者模式，貓和老鼠事例     在Unity遊戲開發中，我們經常需要在一個類中，呼叫另一個類中的方法，比如，當玩家進入到某個地方，敵人就開始攻擊玩家。這時就需要利用委託與事件，設計觀察者模式。 此處我們利用貓和老鼠來簡單描述： 程式碼如下： Ca cocos中的觀察者模式 以及"點選事件"的註冊和分發（個人理解） 一、控制元件的點選事件註冊與完成 在學習cocos引擎時，感覺觸控事件用的比較頻繁。 於是對各種觸控事件做一些小小的總結： cocos中的控制元件（按鈕，精靈，各種容器等）。在實際開發中發現他們都是可以新增點選事件的，可以通過設定setTouchEnabled()來開啟點 【C++】struct和class的區別 最近在看一些關於C++的書，然後這個問題不懂就來百度了= =這個文章寫的很好所以來分享~ C++中的struct對C中的struct進行了擴充，它已經不再只是一個包含不同資料型別的資料結構了，它已經獲取了太多的功能。 struct能包含成員函式嗎？ 能！ struc