事情还得在两天前说起，部门经理拉我去单独聊天，跟我说公司现在需要做一个平台型的SDK。因为公司接的游戏都是租用着别人的SDK，要给租金不说，处理突发事情也不够及时。所以，希望我来开发一个属于公司自己的SDK。当时，我一听，这挺好啊，那就做吧。就问要需求文档，经理居然回我，需求的话就是按照我们现在租用的SDK来开发就可以了。当时我就懵逼了，没有需求文档怎么去开发。就因为这个问题，我们讨论了快半个小时，经理很坚定说，其实我就是需要和这个SDK一样功能的就可以了。你就去用一下这个SDK就知道了，为什么要我写文档。其实，对于我们开发来说，比起看得到的功能来说，我认为SDK里面的业务逻辑才是最重要的。我们能看见的功能，就只能模仿到表面，却了解不了真正的精髓。没办法啊，既然经理给不了具体的需求，那只能靠自己了。
既然靠自己，就得看看自己手上现在有什么资源，自己的目标是什么，下一步要做什么。有什么资源呢，有一个SDK的jar和一个SDK的lib。目标就是按照这个SDK去开发自己的SDK，现在我知道这个SDK的表面功能，下一步我要了解SDK里面的业务逻辑。左思右想，要怎么了解业务逻辑呢？叫开发商给源码是不可能，这辈子不可能给源码的。但是可以个接入文档，我这里可能了解个大概的流程啊！于是，我拿到了SDK的接入文档，与接入的demo。经过认真的跑demo，看文档后。我为自己画了个流程图
在这个流程图能看得见也就是 登录，注册，支付，登出。其他的都是SDK内部业务逻辑上的接口。所以我从不相信SDK能靠几个功能这么简单就可以撑起来一个SDK平台，能撑起来的是背后强大的业务逻辑。
画了流程，知道了一个SDK的大概框架。我的下一步就要看他们的源码，让他们给源码是不可能，还是得靠自己。看源码才是看出一个应用真身，才知道一个应用能稳定运行的真正原因是什么。看源码，那就用反编译吧，把SDK反编译，只能祈祷SDK没有做过混淆的操作。经过一系列猛如虎的操作，成功把SDK反编译了，谢天谢地，可以看源码。这就很满足了！真开心去看源码的时候，才发现一个看起来简单的SDK，源码居然这么多！而且让人不知从哪里看起，更不知道每个文件，每个方法的作用是什么！
到这里我才知道，我痛苦的开发SDK历程才刚刚开始。我告诉自己不能怂，直面源码，别人看书我看源码。想开发出一个稳定的SDK，就要学习前人的经验。看！不看不是人！
最后，致敬所有看过别人源码的同学。我也会记录下来，我看源码的思路，方法。我是一名Android工程师，我为自己加油！