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

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

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

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

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

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

上一篇:Spring Mvc 上传文件Demo 实例


下一篇:.net core 上传文件Demo