一直在糾結是先寫框架設計還是先寫掉過的坑，最後本這娛樂大衆的態度先寫掉過的坑讓大家樂呵下。
項目開發過程中遇問題無數，回顧下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.csdn.net/typesdk_code）
下期預告《手機遊戲渠道SDK接入工具項目分享（四）設計簡單纔是美》