在公司的項目架構里，根控制器之后是4個一級功能頁面，一級頁面下再鏈接到各個其他功能頁面上。
其中一級頁面和其他功能頁面的關系并不是固定的上下級關系，實際上它們之間的耦合度極低，甚至可以看做是完全平級、完全分割開的。
它們之間的鏈接關系其實是這樣的：當在某一個功能頁中要打開另一個功能頁時，只需調用一個功能管理類（FunctionCodeManager）的跳轉方法，將要跳往的功能頁的功能標識和其他參數（如果有需要的話）傳給這個跳轉方法，功能管理類便會創建功能標識對應的功能頁面的對象，然后將它push進來。以此實現了從一個功能鏈接到另一個功能的操作。
這個功能管理類就是我此次要優化的對象。它是整個項目的中樞，所有的功能跳轉都由它來調度，實現方法并不復雜：
1、首先要規定好各個功能對應的功能標識（FunctionCode），將它們枚舉出來：
功能標識是前后臺共同約定的，不只是客戶端在使用，當后臺想要在客戶端某個位置動態地展示其他功能的入口時，接口數據中便是用功能標識來標識“其他功能”的。
2、然后在功能管理類的跳轉方法中，對應每個功能標識做出響應：
3、那么當其他地方需要跳轉到某個功能頁面時，只需要這么調用：
功能管理類便會打開對應的功能頁面。
這種模式的好處是顯而易見的，但是缺點也很明顯：用if-else來判斷功能標識效率太低。尤其是公司項目的真實數據中總共有80多個功能，那么當要使用功能管理類跳轉去最后一個功能的時候，就意味著代碼要跑80多次if-else判斷，看起來是很低效的。
于是我就產生了要優化的它的想法。
我們都知道switch-case的效率遠遠高于if-else，于是我便決定用switch-case來優化功能管理類。大致的思路如下：
1、功能標識里都是包含數字的，那么可以將功能標識里的數字提取出來，用提取出來的數字作為條件來供switch-case判斷；
2、那就需要先枚舉出所有功能標識轉換成數字后的數值，功能管理類的跳轉方法就使用這些枚舉的數值來做判斷；
3、同時需要提供一個方法，用來做功能標識和數值的轉換，為了提高效率，還要將已提取過數字的功能標識和對應的數字保存起來；
4、那么整個流程就可以定為這樣：在本地跳轉或者是接口數據要求跳轉的情況下，可以仍然傳字符串類型的功能標識給功能管理類的跳轉方法，跳轉方法內部將字符串類型的功能標識轉換為數值，然后使用數值去switch-case，再在對應的case里對各個跳轉請求作出響應。
優化的操作過程如下：
1、首先新建了一個優化后的功能管理類（FunctionCodeManagerOptimized），枚舉出所有功能標識轉換成數字后的數值：
為了樣式整齊，在將功能標識轉換成數字后在前面加多一個1，那么0位就可以保留著了。在這種轉換思路下，比如APP_001就將被轉換成1001；
2、接下來就可以編寫新的功能跳轉方法了：
3、對于其中字符串功能標識轉換成數值的方法transformFuncCode:，代碼如下：
它使用了一個靜態數組funcCodeCache來做緩存，將已經轉換過的功能標識保存起來，下次可以直接使用，這樣就大大加快了轉換的效率。
4、以上這些優化使得功能管理類的時間復雜度從O(N)降低到了O(1)。
完成了這個新的功能管理類后，將它和舊的功能管理類進行對比，測試了在最極端的情況下（要跳轉第80個功能），兩者的耗時情況，編寫代碼如下：
在10000次執行下，雙方的耗時情況如下：
可以發現，舊的功能管理類要花0.037秒，優化后的功能管理類只要0.007秒，性能約提升了5倍。
看起來，這似乎是一次成功的優化了。
在完成了這些測試后，我又重新思考了一下這次優化，最后的結論還是決定放棄這次優化操作。雖然優化確實可以提升5倍的效率，但是事實上并沒有看起來的那么完美，有這么兩個問題：
1、舊的功能管理類中只需要管理一份字符串類型的功能標識，并且在宏定義和跳轉方法中都是使用這一份功能標識，各個位置都是一致的，很方便管理；優化后的功能管理類需要管理兩份功能標識：一份字符串類型的和一份數值類型的，并且在宏定義和跳轉方法中各自使用了一份功能標識，兩者并不一致，加大了代碼管理的難度；
2、雖然表面看起來優化似乎是使性能提升了5倍，但是實際提升并不大。在項目中調用功能跳轉方法跳轉的時候，通常都只需要執行一次即可，絕對不可能出現測試代碼那樣執行10000次的情況。也即是說，所謂的5倍性能提升實際上只是將功能管理類代碼的執行時間從0.0000037提升到0.0000007，我不認為兩者有什么區別。
基于這些思考，最終放棄了這次優化。
