有限狀態機編程

① 有限狀態機的編程

有限狀態機體現了兩點：首先是離散的，然後是有限的。
State：
狀態這個詞有些難塵鉛以定義，狀態存儲關於過去的信息，就是說它反映從系統開始到現在時刻的輸入變化。
Actions & Transitions：
轉換指示狀態變更，並且用必須滿足來確使轉移發生的條件來描述它。動作是在給定時刻要進行的活動的描述。
Guards:
檢測器出現的原因是為了檢測是否滿足從一個狀態切換到另外一個狀態的條件。
Event：
事件，又見事件，籠統說來，對系統重要的並州某件事情被稱為事件。
恩，就這些了，有些迷惑么:),恩，我們來理清一下思路：先從事件說起，事件是有生命
的，它經歷:
1).被產生(被接受，等待被處理，一般放入事件隊列)
2).被分發(從事件隊列取出，分發到響應的狀態機處理)
3).死亡(當狀態機處理了該事件，它隨之死亡)
從一個狀態切換到另外一個狀態被稱為派蔽好狀態轉換，而引起它的事件稱為觸發事件.(可以看到，不是所有的事件都會引起狀態的轉換).
提到狀態轉換，不能不提及檢測器(Guards)，只有當檢測器的值為TRUE時候，才能啟動轉換

② 軟體工程裡面系統分析和系統需求分析有區別嗎

看看這個吧 希望能對你有幫助「普及計算」時代：嵌入式系統重新劃分計算機類別 由於事物的發展性，對事物的定義是很難放之四海而皆準的，尤其對於計算機領域而言，這種現象更加明顯。以前我們把計算機按其體系結構、運算速度和結構規模等因素分為大、中、小型機和微機，並以此來組織學科和產業分工，後來隨轎姿搜著微機處理速度的迅速提高，使得這種劃分界限大大模糊化。而嵌入式計算機系統在當前及未來的大量應用，無疑會使得這一幕重新上演。 計算技術在各行各業的廣泛滲透，使得嵌入式計算機在應用數量上將遠遠超過傳統意義上的計算機，它可以應用於製造業、通訊、儀表、汽車、軍事、航空航天和消費類電子產品等廣闊領域。許多學者主張以應用為中心把計算機劃分為兩類：通用計算機（典型的如PC）和嵌入式系統。因為科技發展的動力在某種程度上總是欲使人類自身更為舒適，所以未來必定是一個「普及計算」（Pervasive Computing）的時代，在諸如家庭網路（Home Network）、汽車網路（Automobile Network）、移動電子商務（Mobile e-business）以及Financial Service Everywhere等普及計算的重要內容中，嵌入式系統都將是核心的組成部分之一。 在嵌入式系統中，軟體與硬體是緊密集成在一起的。它和通用計算機有著本質的區別，由於它基於具體應用，所以在各種不同嵌入式系統之間，很難找到共通的特性。嵌入式系統的分析和設計無法延用傳統方法。本專題圍繞「嵌入式系統開發技術」這個核心，組織了以下四篇文章： 1. 實時系統軟體分析和設計方法綜述 2. 嵌入式系統軟體的面向對象開發技術 3. 實時操作系統任務間通信的設計與分析 4. 嵌入式計算機系統的設計技術 本專題分兩次刊出，本期刊出前兩篇文章. 實時系統簡介 實時系統在工業、商業和軍事等領域都有非常廣泛的用途，並且已經有很多實際的應用。一般來說，實時系統通常是比較復雜的，因為它必須處理很多並發事件的輸入數據流，這些事件的到來次序和幾率通常是不可預測的，而且還要求系統必須在事先設定好的時限內做出相應的響應。 那麼，是不是響應時間在多少毫秒或多少微秒以內的系統就是實時系統，而超出這個時限的就不算呢？事實上，實時系統並非是指「快速」的系統，實時系統有限定的響應時間，從而使系統具有可預測性。實時系統又可以分為「硬實時系統」和「軟實時系統」。二者的區別在於：前者如果在不滿足響應時限、響應不及時或反應過早的情況下都會導致災難性的後果；而後者則在不滿足響應時限時，系統性能退化，但並不會導致災難性的後果。 實時系統具有以下一些特點，從而區分於其他系統： 嵌入式系統 實時系統通常是嵌入式的系統，也就是由封裝好的軟體系統控制與其相關的硬體。 與外部環境交互 實時系統通常需要與外部環境進行交互，例如，可以控制機器及生產過程，或者監控化學反應並隨時匯報危急情況，這種情況通常需要從外部接收數據並提供輸出和控制外部環境。 時限 實時控制 實時系統經常包括實時控制，從接收到的輸入數據中做出控制決策。 「反應」系統 很多實時系統都是「反應」的系統，也就是說，由事件驅動並且必須對外界事件進行響應。 並發處理 絕大多數實時系統的一個重要特點是並發處理，通常，事件發生的順序是不可預測的。 一些重要概念與一般的系統設計一樣，實時系統軟體也包括一些和一般系統相同的分析和設計概念，在這里不再討論。下面列出幾點對於實時系統設計有特別重要意義的概念： 有限狀態機（FSM） 很多實時系統，特別是實時控制系統，其整個分析機制與系統的狀態有相當大的關系。有限狀態機由有限的狀態和相互之間的轉移構成，在任何時候只能處於給定數目的狀態中的一閉歷個。當接收到一個輸入事件時，狀態機產生一個輸出，同時也可能伴隨著狀態的轉移。主要有兩種方法來建立有限狀態機，一種是「狀態轉移圖」，另一種是「狀態轉移表」，分別用圖形方式和表格方式建立有限狀態機。實時系統經常會應用於比較大型的系統中，這時採用圖形或表格方式對理解復雜的系統具有很大的幫助。 並發任務 實時系統通常都會有很多事件同時產生。一個任務描述一個事件，整個系統的並發機制是通過讓很多任務並行運行而實現的。一個強調並發任務的系統設計通常都會顯得更加清楚並且易於理解。 信息隱藏 信息隱藏是一個與各種系冊兄統設計都有關的設計概念，原則是每個模塊應該隱藏可能會做改變的設計結果。採用信息隱藏的原因是使模塊可供修改，易於理解，因此也便於維護。 實時系統分析和設計的常用方法 首先要區分兩個不同的概念：系統分析和系統設計。系統分析指的是由用戶提供的，說明軟體系統應該做什麼以及需要在什麼環境下運行等情況的方案；系統設計則是指那些由系統分析員或設計者提供的描述軟體系統如何實現這些需求的方案。在實時系統的設計中，系統的瞬時表現是最難描述的，但同時也是最重要的因素。 以下具體地介紹實時系統設計的常用方法。 語言描述及數學分析 在系統分析和設計中，語言描述是不可缺少的，但其功能也只是對其他方法提供的分析和設計進行補充。在系統分析中，也可以採用數學分析來描述對系統功能的需求。數學分析是一種精確而有效的方法，對系統性能的優化可以通過優化相應的數學模型而獲得，但在大系統中，其作用相對受限。 流程圖 流程圖也許是最早出現的軟體系統模型，而且也有著很廣泛的應用，因此，簡單的系統可以採用流程圖來進行建模。流程圖適合指令不超過5000到10000條的系統。在多任務的系統中，流程圖可用來對各個任務進行分別描述，但是進程之間的交互就不太容易描述，同時也無法描述其瞬時的表現。 結構圖 結構圖是一種廣泛採用的、用以描述系統模塊結構的方法。結構圖從左到右代表了執行的順序，從上到下代表了程序模塊的細節化。結構圖可以在相當多的計算機科學的文獻以及其他描述系統的文章中見到。 偽代碼和編程設計語言(PDL) 編程設計語言與偽代碼只有細小的差別。編程設計語言是一種與系統運行的底層硬體環境相分離開來的抽象語言，它以一種類似於真正的編寫代碼的方式來說明系統。ADA就是一個成功應用編程設計語言的例子。 使用編程設計語言或偽代碼的好處是，它們比直接應用語言來描述系統需求更抽象，而同時比前述所有方法都更接近實際的編程語言。 有限狀態機 有限狀態機是實時系統設計中的一種數學模型，是一種重要的、易於建立的、應用比較廣泛的、以描述控制特性為主的建模方法，它可以應用於從系統分析到設計的所有階段。有限狀態機的組成如下： （1） 一個有限的狀態集合Q （2） 一個有限的輸入集合I （3） 一個變遷函數δ：Q×I→Q 變遷函數也是一個狀態函數，在某一狀態下，給定輸入後，FSM轉入該函數產生的新狀態。δ的定義域內的某些數值可以是未定義的。 有限狀態機通常用圖的方式來表示，其節點代表狀態。若在輸入ｉ下狀態由q1轉變為狀態q2，則有一條標有輸入ｉ的弧線從狀態q1指向q2。此時，其變遷函數δ(q1,i)=q2。圖１示意了一個簡單的有限狀態機。
圖1 簡單有限狀態機 圖1中的左圖表明該FSM有q0、q1、q2、q3四個狀態，輸入集中有a、b、c三個元素；右圖中各個狀態之間的轉換關系則更清晰。有限狀態機非常適合於描述這樣的系統：系統含有有限個狀態，不同事件的發生可以用不同狀態之間的轉換來模擬。 總的來說，有限狀態機的優點在於簡單易用，狀態間的關系能夠直觀看到。但應用在實時系統中時，其最大的缺點是：任何時刻系統只能有一個狀態，無法表示並發性，不能描述非同步並發的系統。另外，在系統部件較多時，狀態數隨之增加，導致復雜性顯著增長。為了消除這些缺點，一些新的方法應運而生。下面介紹的Petri網就是其中一種，與FSM相比，它具有更強的建模能力，並能描述系統的並發、非同步、同步等特性。 Petri網 Petri網是一種使用圖形方式對系統進行需求規格說明的技術，用來定義多進程、多任務系統的數學模型，易於描述系統的並發、競爭、同步等特徵，並可用於評價和改進系統。如今，Petri網已經大量應用於各種系統的模型化。與FSM相比，Petri網不僅能描述同步模型，更適合於相互獨立、協同操作的處理系統。 Petri網的組成成分包括： (1)一個有限的庫所（place）集合，表示系統的狀態。 (2)一個有限的變遷（transition）集合，表示系統中的事件。 (3)一個有限的連接庫所到變遷或者反向的有向箭頭的集合，又分輸入和輸出。 圖2為一Petri網示例，圖中的庫所用圓圈表示，變遷由矩形表示。 Petri網有如下特性： (1)狀態 通過標記Petri網的庫所來給出其狀態，標記Petri網的庫所在圖形中表現為對庫所插入數目不同的令牌。 (2)狀態變化規則 一個變遷可以有多個輸入或輸出庫所，如果一條有向箭頭是從庫所到變遷，則該庫所是該變遷的一個輸入庫所，反之則為輸出庫所。如果一個變遷中每一個輸入庫所都至少有一個令牌，則稱該變遷是一個使能變遷。 (3)點燃 一個使能變遷可以被點燃，即從該變遷的每一個輸入庫所中移走一個令牌，在該變遷的每一個輸出庫所中增加一個令牌。 圖2 Petri網示例� 圖2中，庫所中的星號代表令牌。由(a)中可以看出，變遷t1和t2都是使能的，(b)表示了點燃t1的過程，(c)表示了點燃t2的過程。從這個模型中可以看出，在給定初始令牌後，Petri網的發展過程可能是不同的。在Petri網中，經常利用變遷來模擬一個事件，而點燃則用來表示事件的發生。這樣，如果一個變遷所表示的事件的發生條件是滿足的，那麼這個變遷就是使能的，庫所中的星號標記則說明某個條件是滿足的。圖2中的Petri網可分為兩部分，一部分是由變遷t1、t3組成，另一部分由t2、t4組成，這相當於是兩個獨立的工作流，並且共享了資源p3。開始時，雙方可以互不幹涉地、非同步地進行，因為變遷t1和t2雙方互不妨礙。點燃t1後，t3處於使能狀態，點燃t2後，t4處於使能狀態。在兩個變遷都點燃後，兩個工作流都有新的變遷處於使能狀態，但是這兩個變遷的點燃處於競爭狀態，兩個工作流中只能有一個獲得p3的資源從而得以繼續變遷。如果資源滿足的情況可以解決這種沖突，就可以設p3的令牌有兩個，兩個工作流就互不幹擾，可以並發執行。 數據流圖 數據流圖主要是作為軟體系統建模中的結構化分析工具。建立數據流圖從分析系統的功能需求開始，分析系統中的數據流並且確定主要的函數。數據流圖需要細分系統和子系統，從而在圖中對數據流有清楚的表現。 表1方 法優點缺點語言描述廣泛應用，能起說明作用不夠明確，無法相應產生代碼。數學分析精確，是一種正式的分析方法，可在此基礎上進行代碼優化。難於應用，並非很多系統設計人員都能夠通過數學方式對系統分析。流程圖廣泛應用，對單任務系統非常適合。沒有並發處理，不能表現瞬時狀態，多採用GOTO語句。結構圖廣泛應用，適合於小系統，鼓勵自頂向下的設計方式。沒有條件轉移，沒有並發處理，不能表現瞬時狀態。偽代碼和PDL與編程語言接近，是正式應用的分析和設計方法。容易出錯且不易發現。有限狀態機廣泛應用，易於建立，方便於代碼產生和優化。沒有並發處理，隨著狀態的增加系統復雜性顯著增加。Petri網廣泛應用，適合於多進程處理，對並行性有很好的表示。應用於過小的系統時顯得不必要。數據流圖廣泛應用，並發處理，易於理解。不易於表示同步性控制流圖是一種在系統中實現控制信號流的數據流圖。這些控制信號能夠描述離散的從開關或感應器得到的信號數據，同時也能包含從離散時鍾得到的離散的定時信息。數據流圖和控制流圖結合使用，可以提供更具控制性的信息。 總體來說，數據流圖特點是：強調數據的流動，不太強調控制信號的流動，對於確定並發性很有用。實際上，如果缺少了並發性的特點，數據流圖就是有限狀態機。數據流圖最主要的缺點是描述同步很困難。 數據流圖容易理解，應用廣泛，通常是和一些其他方法結合使用來產生連貫的軟體需求文檔。實時系統分析和設計方法總結 本文對應用於實時系統的、常用的多種分析和設計方法進行了簡單的介紹。應該明確的一點是，沒有一種分析或設計方法是可以應用於任何場合的，事實上，很多情況都是幾種方法的混合使用。表１列出了文中所介紹的各種分析和設計方法，並簡單列出其優缺點。

③ 編程所需要的數學知識

計數的能力： for循環中經常用， 小學生都會。
數字的加減乘除 ： 每種編程語言都會內置支持， 都不需要你自己算
余數和模： 偶爾會用得到
集合運算： 交集、並集、差集 ， 編程中用的不多。
布爾運算： AND , OR, 非
各種進制： 二進制、十進制、十六進制
還有哪些？ 我想不起來了， 歡迎補充。
當然這和我從事的編程領域有極大關系， 如果我做的不是Web開發， 而是搜索，游戲， 安全，演算法，人工智慧等， 那對數學的要求估計就開始飆升了。
其實計算機的基礎是數學， 只是我們一直在應用層編程， 體會不到罷了。
比如說我們日常使用的計算機，絕大部分都是所謂馮諾依曼結構(參見文章《馮·馮諾依曼計算機的誕生》) ，這個結構可以說是圖靈機這個概念機器的具體實現，而圖靈機就是一個純數學的東西啊 ，沒有圖靈機這么偉大的抽象作為數學基礎， 現代的計算機是製造不出來的。
再比如說密碼領域需要很多數論的知識，RSA演算法就涉及到大素數的分解；
我們常用的Mysql, Oracle 等關系資料庫的底層基礎是離散數學的笛卡爾乘積；
通信系統中很重要的一個原理就是傅里葉變換。
編譯器會用到有限狀態機；
數據的壓縮會用到各種數學的演算法；
項目管理中的進度管理，甘特圖數學基礎就是圖論。

④ 狀態機到底是什麼

狀態機是有限狀態自動機的簡稱，是現實事物運行規則抽象而成的一個數學模型。

先來解釋什麼是「狀態」（State）。現實事物是有不同狀態的，例如一個LED等，就有亮和滅兩種狀態。我們通常所說的狀態機是有限狀態機，也就是被描述的事物的狀態的數量是有限個，例如LED燈的狀態就是兩個亮和滅。

狀態機，也就是StateMachine，不是指一台實際機器，而是指一個數學模型。說白了，一般就是指一張狀態轉換圖。

狀態機由狀態寄存器和組合邏輯電路構成，能夠根據控制信號按照預先設定的狀態進行狀態轉移，是協調相關信號動作、完成特定操作的控制中心。有限狀態機簡寫為FSM（Finite State Machine），主要分為2大類：

第一類，若輸出只和狀態有關而與輸入無關，則稱為Moore狀態機；

第二類，輸出不僅和狀態有關而且和輸入有關系，則稱為Mealy狀態機。

有限狀態機是一種概念性機器，它能採取某種操作來響應一個外部事件。具體採取的操作不僅能取決於接收到的事件，還能取決於各個事件的相對發生順序。之所以能 做到這一點，是因為機器能跟蹤一個內部狀態，它會在收到事件後進行更新。為一個事件而響應的行動不僅取決於事件本身，還取決於機器的內部狀態。另外，採取 的行動還會決定並更新機器的狀態。這樣一來，任何邏輯都可建模成一系列事件/狀態組合。

(4)有限狀態機編程擴展閱讀：

狀態機的四大概念：

State，狀態。一個狀態機至少要包含兩個狀態。例如上面燈泡的例子，有燈泡亮和燈泡滅兩個狀態。

Event，事件。事件就是執行某個操作的觸發條件或者口令。對於燈泡，「打開開關」就是一個事件。

AcTIon，動作。事件發生以後要執行動作。例如事件是「打開開關」，動作是「開燈」。編程的時候，一個AcTIon一般就對應一個函數。

TransiTIon，變換。也就是從一個狀態變化為另一個狀態。例如「開燈過程」就是一個變換。

狀態機的應用：

狀態機是一個對真實世界的抽象，而且是邏輯嚴謹的數學抽象，所以明顯非常適合用在數字領域。可以應用到各個層面上，例如硬體設計，編譯器設計，以及編程實現各種具體業務邏輯的時候。

進程5狀態模型：

進程管理是Linux五大子系統之一，非常重要，實際實現起來非常復雜，我們來看下進程是如何切換狀態的。

⑤ 有限狀態機系統在嵌入式軟體中是個什麼地位

有限狀態機是嵌入式軟體的一種結構。

有限狀態機是實時系統設計中一種重要的，容易建立的，應用比較廣泛的，以描述控制特性為主的建模方法，它可以應用於從系統分析到設計的所有階段。
有限狀態機系統優點：簡單易用，狀態間關系直觀看到，便於編程；可以快速執行；只是通過改變輸出功能來改變機器的響應。悄埋缺點：任何時刻系統敗運凳只能有一個狀態，無法表示並發性，不能描述非同步並發系統；在系統部件多時，狀態數察旅隨之增加，導致復雜性顯著增長；對於大的應用系統，難於調試。 —— 轉自 http://blog.csdn.net/chinaunixj/article/details/737

雖然如此，個人認為，有限狀態機雖然不能用於表示並發和描述非同步這一點顯而易見，但是仍然還是可以用於實現非同步並發系統。

⑥ stateflow怎麼刪除輸入口介面

看了下上面的答歲陵案，呵呵了

不多吐槽，點開model explorer 位置在乎兆戚這里

選擇你想改名或者猜伍刪除的變數，鍵盤上按下Delete即可

⑦ 在實現一個任務時，為什麼要使用狀態機編程

大多數的應用程序如果在開發時考慮採用兩個以上線程，那麼一般情況下是為每個線程分配了獨立的功能，且這些功能能夠「並發地」執行。講一個二樓同學說到的網路I/O例子：點對點的聊天工具，需要在我們編寫信息的同時能夠接受並列印出來對方說的話。如果將信息的發送和接受放在一個線程里，線程的單一順序控制流程特性就使得發送和接受兩者不能兼顧。其實說到「並發地」，實際上，這兩個線程並不是同時在執行，而是相斥地，但是由於計算機的數據處理能力很強大，能夠把系統資源快速地在這兩者之間進行調配（切換），以至於我們人感覺不到這個切換的過程，好像它是在並發地執行，也就是說計算機通過多線程提供的所謂「並發性」滿足了程序使用者對於並發性的要求。
上面這個例子就說明了在單核計算機上，多線程程序還是有其存在的合理性滴。

⑧ 什麼叫提機狀態

提機狀態機是一種編程思路。一種對對自然界某種事物(或數據)狀態變化的抽象。 讓你的程序開發維護,思路更加返配清晰方便。它規定了一個實例(某種抽象),某一時刻只能有一種狀態(屬性)。一般用字元串表示。 規定了只能通過實例的方法,即執行某個動作(函數),之後才可以改變狀態(屬性)。

狀態機由狀態寄存器和組合邏輯電路構成，能夠根據控制信號按照預先設定的狀態進行狀態轉移，是協調相關信號動作、完成特定操作的控制中心。有限狀態機簡寫為FSM（Finite State Machine），主要分為2大類：

第一類，若輸出只和狀態有關而與輸入無關，則稱為Moore狀態機。

第二類，輸出不僅和狀態有關而且和輸入有關系，則稱為Mealy狀態機。

狀態機由狀態寄存器和組合邏輯電路構成，能夠根據控制信號按照預先設定的狀態進行狀態轉移，是協調相關信號動作,完成特定操作的控制中心漏豎指。

狀態機分為摩爾（Moore）型狀態機和米莉纖純（Mealy）型狀態機。

狀態機就是狀態轉移圖。

⑨ [因為我不懂啊]-什麼是狀態機編程（設計模式）（3）

上一篇文章寫完之後，我一直在想做一個游戲示例，想將之前學到的狀態機模式運用在其中。然而一直遇到各種奇怪的bug（之後寫出來），所以一直沒有完成這件事。而且加之自己又犯懶了，所以我決定做一件更簡單的事，以更容易接近的目標來引誘懶的不行的自己。

廢話說完，來說正經事了。前幾天認真看了一篇 博客-游戲狀態機 （侵立刪），覺得廳念碰挺不錯的，建議盆友們認真看一看。

讀完博客之後，之前計劃的示例貌似有了頭緒，（廢話型）總結出來，實現一個游戲狀態機結構需要進行如下幾步：

我要做一個簡單的UI切換示例，所以簡述需求就是: 打開程序進入主界面，主界面中點擊開始游戲，進入游戲界面，游戲界面中點擊結束游戲，進入結算界面，結算界面可以點擊回到主界面，進入主界面，也可以點擊重新開始游戲，再次進入游扮談戲界面。

從需求描述來看，狀態有三個:

事件有四個:

然後（裝模作樣的）畫了一個狀態轉換表：

之前一篇文章中有提到過的，在Cocos2d-x游戲開發中，剛好使用Scene來作為控制器，由Scene來控制各層的出現和消失。

這里貼出Scene的源碼(完整的源文件，包括了後續步驟才會出現的狀態基類，以及派生的狀態類)：
QFLGameTwoScene.hpp

QFLGameTwoScene.cpp

上面可以看到，Scene中主要包含了:

包含了以上內容，本示例中的這個Scene就能起到控制器的作用了。

狀態基類是很有必要的，為了達到各個同級狀態都能通過同一個控制器來進行狀態轉換的目標，各個狀態類進行切換時必須有一套統一的流程。
這里貼出本示例中狀態基類的源碼:
QFLGameTwoStateBase.hpp

這個源文件中包含了:

所有的派生狀態類都會 include 這個文件，實現虛基類 GameTwoState 中的方法，所以所有的狀態類都有統一的切換流程:

而且在完成某個事件，需要進行狀態轉換時，可以通過發送自定義事件來完成消息的傳遞，自定義事件名放在這里也是為了方便起見。

這里直接貼出幾個State的源碼了，其高擾中包含注釋，廢話就不重復再寫了:

QFLGameTwoMainLayer.hpp

QFLGameTwoMainLayer.cpp

QFLGameTwoGameLayer.hpp

QFLGameTwoGameLayer.cpp

QFLGameTwoResultLayer.hpp

QFLGameTwoResultLayer.cpp

到這里，上面所提到的步驟全部進行完了。這個UI切換的狀態機示例也就完成了。

在AppDelegate.cpp中，直接進入Scene中:

進入主界面 :

此時的Log:

點擊Start，進入游戲界面 :

此時的Log:

<Exit> ->MainLayer
<Enter> ->GameLayer
<Execute> ->GameLayer

點擊Over，進入結算界面 :

此時的Log:

<Enter> ->GameLayer
<Execute> ->GameLayer
[Event]->Game_Over
<Exit> ->GameLayer

<Enter> ->ResultLayer
<Execute> ->ResultLayer

點擊Replay，重新進入游戲界面 :
此時的Log:

<Enter> ->GameLayer
<Execute> ->GameLayer
[Event]->Game_Over
<Exit> ->GameLayer

<Enter> ->ResultLayer
<Execute> ->ResultLayer
[Event]->Result_Replay
<Exit> ->ResultLayer

<Enter> ->GameLayer
<Execute> ->GameLayer

點擊Over，再次進入結算界面，然後在結算界面點擊Home，回到主界面
上面的兩次操作完成後，Log如下:

<Enter> ->GameLayer
<Execute> ->GameLayer
[Event]->Game_Over
<Exit> ->GameLayer

<Enter> ->ResultLayer
<Execute> ->ResultLayer
[Event]->Result_Replay
<Exit> ->ResultLayer

<Enter> ->GameLayer
<Execute> ->GameLayer
[Event]->Game_Over
<Exit> ->GameLayer

<Enter> ->ResultLayer
<Execute> ->ResultLayer
[Event]->Result_Home
<Exit> ->ResultLayer

<Enter> ->MainLayer
<Execute> ->MainLayer

這里用FSM實現UI切換示例只是眾多方法中的一種，暫時還沒有去比較它們的優劣。(使用markdown編輯器的經驗值+1)

可能性多種多樣，如果有小夥伴比較過這些方法。求留言告知，求分享經驗。