手机游戏渠道SDK接入工具项目分享（三）拨开云雾是个坑

一直在纠结是先写框架设计还是先写掉过的坑，最后本这娱乐大众的态度先写掉过的坑让大家乐呵下。

项目开发过程中遇问题无数，回顾下8个大坑照成了项目一定程度上延期甚至返工。

1. 1.  项目一开始几个人把现有3家主流的产品（1接，棱镜，AnySDK）研究了一遍。没想先在这里就进坑了。在研究了几天后发现这3家虽推出有一定时间，但都是以第三方服务角度设计和开发的产品，与需求不符。
2. 2.  版本管理、和流程管理等内容因为运营人员更替一直在调整，直到我提出需要加价才做吧。需求上快把打包工具做成OA系统了，删除了于渠道、游戏、运营无关的需求后，也花了近2个月才完成。
3. 3.  服务端指望一个项目里面集成所有渠道解决问题，被证实是不可能完成的，将所有功能和渠道都才分为服务或模块并解除了耦合后才得以继续。
4. 4.  事实上要带领一群菜鸟完成开发工作，高大上的设计很蛋疼，要简单、简单、再简单。
5. 5.  最初设计出包需要经过反编译，然后插入渠道SDK内容，再编译成分包。因为市面上聚合SDK产品都是采用这个模式，所以我们理所当然的跟这走了，为了攻克反编译及整合资源花了好几周时间。最后发现被带沟里了。在调研typesdk这个开源项目时发现，里面直接使用Unity导出的项目工程进行原生编译出包，避免了反编译带来的问题和隐患，想想也对我们有项目源码和渠道接入源码，干嘛吃撑了去反编译。
6. 6.  最初设计框架封装很全面，所以灵活性很低。但自己开发的产品需要更高的灵活性。因为买来的东西遇到需求时你只要说没这功能就完了，自己开发的产品就需要和产品运营撕B。
7. 7.  因为时间就是金钱，框架设计一完成就急于接入渠道SDK，最后部分渠道SDK因为于设计的接口不兼容被放弃，应该先调查完成所有渠道是否兼容设计后才开始接入。
8. 8.  上线游戏开发组不愿意修改充值逻辑，认为会影响效率和稳定性，项目上线后就被刷充值，都说高手在民间，不能有任何侥幸心理。后来在所有充值和登录相关接口都加上了主动校验、被动校验和防刷机制。

其他小问题这里就不说了，都是google、百度可以解决的问题。其实最后typesdk这个开源项目对我们的启发很大。我这里不能提供我项目的代码，但有兴趣的猿类可以看看typesdk的项目（https://code.csdn.net/typesdk_code）

下期预告《手机游戏渠道SDK接入工具项目分享（四）设计简单才是美》