我将要说的这个问题可能跟渠道号没有关系，但是确实因为这个引起的。
在我目前的项目里，在发布的时候，会为每个渠道单独打一个特殊的包，为了统计各个渠道的下载量，我们需要收集应用的渠道号。并且不知道什么原因，在请求我们的服务器的时候，渠道号也被当成了一个公共参数被提交到服务端。
那么问题来了，在我的项目里，渠道号的被写在了一个 INFO 文件里，然后在需要获取的时候，需要根据当前 app 的位置，使用 zip 解压的方式，去读取这个文件，然后从文件里找到这个渠道号。
这本是一个非常耗时的操作，因为它需要 IO ，读文件，而且不是简单的读文件，是读 zip 文件。然后这个操作被一个同事封装为一个方法，返回值就是这个渠道号，方法体就是读文件，分析文件。
这是一个公开的方法，在任何需要渠道号的代码都调用了这个方法。基本上，调用这个方法的方法都在主线程里。比如每次 http 请求的时候，都需要获取公共参数，然后把请求放到一个请求队列里，这些都是在主线程里完成的。这样的结果就是，这个获取渠道号的方法在主线程里被调用了 N 多次。特别是在 App 启动的时候，发起了很多 http 请求。结果就是很卡。不过现在想想，还好他们都是在主线程里操作，要是在 N 多个线程里做这个事情，那么画面也许会很好看。
对于这个问题，其实很简单，读取文件只需要做一次，不需要每次都去读文件，只要增加一个静态变量保存就行了。
其实最终的问题不是这个同事这样写有多么的错，而是他的 leader 没有能发现这样的问题，才是最大的问题。在我现在的项目里，确实存在这样的情况，有太多的人同时在维护一套代码，每个人的水平是不一样的，怎么才能确保一个项目能够可持续下去，对代码质量的把控是很关键的，但是就我目前看到的，各个小 leader 貌似不是很在意这个，经常能看见各种奇葩的代码。如果作为一个 leader ，对公司，这算不负责任。可能你会说，我才拿多少钱，干嘛操那份心。OK，咱们现在不谈这么崇高的事情，咱就说作为一个 leader，你对你的小伙伴负责了吗？你的小伙伴可能刚毕业，是一个新手，菜鸟，现在在你负责的项目里，你是怎么帮助他成长的？送人玫瑰，手留余香。
- EOF -
本站文章除注明转载外，均为本站原创或编译。欢迎任何形式的转载，但请务必注明出处，尊重他人劳动。
转载请注明：文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题： 一个渠道号获取方法的优化
本文地址： https://binkery.com/archives/533.html