在公司的项目架构里，根控制器之后是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，我不认为两者有什么区别。
基于这些思考，最终放弃了这次优化。
网友评论