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