手機游戲渠道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接入工具項目分享（四）設計簡單才是美》