一个渠道号获取方法的优化

March 22, 2016

我将要说的这个问题可能跟渠道号没有关系,但是确实因为这个引起的。

在我目前的项目里,在发布的时候,会为每个渠道单独打一个特殊的包,为了统计各个渠道的下载量,我们需要收集应用的渠道号。并且不知道什么原因,在请求我们的服务器的时候,渠道号也被当成了一个公共参数被提交到服务端。

那么问题来了,在我的项目里,渠道号的被写在了一个 INFO 文件里,然后在需要获取的时候,需要根据当前 app 的位置,使用 zip 解压的方式,去读取这个文件,然后从文件里找到这个渠道号。

这本是一个非常耗时的操作,因为它需要 IO ,读文件,而且不是简单的读文件,是读 zip 文件。然后这个操作被一个同事封装为一个方法,返回值就是这个渠道号,方法体就是读文件,分析文件。

这是一个公开的方法,在任何需要渠道号的代码都调用了这个方法。基本上,调用这个方法的方法都在主线程里。比如每次 http 请求的时候,都需要获取公共参数,然后把请求放到一个请求队列里,这些都是在主线程里完成的。这样的结果就是,这个获取渠道号的方法在主线程里被调用了 N 多次。特别是在 App 启动的时候,发起了很多 http 请求。结果就是很卡。不过现在想想,还好他们都是在主线程里操作,要是在 N 多个线程里做这个事情,那么画面也许会很好看。

对于这个问题,其实很简单,读取文件只需要做一次,不需要每次都去读文件,只要增加一个静态变量保存就行了。

其实最终的问题不是这个同事这样写有多么的错,而是他的 leader 没有能发现这样的问题,才是最大的问题。在我现在的项目里,确实存在这样的情况,有太多的人同时在维护一套代码,每个人的水平是不一样的,怎么才能确保一个项目能够可持续下去,对代码质量的把控是很关键的,但是就我目前看到的,各个小 leader 貌似不是很在意这个,经常能看见各种奇葩的代码。如果作为一个 leader ,对公司,这算不负责任。可能你会说,我才拿多少钱,干嘛操那份心。OK,咱们现在不谈这么崇高的事情,咱就说作为一个 leader,你对你的小伙伴负责了吗?你的小伙伴可能刚毕业,是一个新手,菜鸟,现在在你负责的项目里,你是怎么帮助他成长的?送人玫瑰,手留余香。

--- EOF ---

添加新评论