經歷了頭兩年的爆發以後,手遊也和端遊、頁遊同樣,進入了一個利潤變薄、產業整合的過渡期。除了那些自有渠道的大廠商,如何找到新的用戶來源始終是中小CP面臨的最大問題,解決辦法目前看來只有不斷新接入渠道這一條。這就催生了一條新問題,接渠道也是一件很是耗時耗力的工做,裏面各類危機暗藏。這就是爲何作了4年手遊CP的星渠,轉型去作統一渠道SDK接入框架——TypeSDK,實在是由於過去4年裏接渠道吃過太多苦頭了。
git
爲何第一個問題就是時間?由於時間對於中小CP來講過重要了,全國登記註冊的手遊CP在2014年時就有20萬家,天天新上架的遊戲有50+款之多,衆多中小手遊CP在渠道導量能力拼不過大廠商的狀況下,只能與時間賽跑,早上線一天多一家渠道就多一線存活的但願。那麼一位有3年左右經驗的程序員接一個渠道SDK要花多少時間呢?據統計這個時間至少是3個小時。而目前國內比較主流的安卓渠道大約有80-100家,CP須要花300個小時來接入這些渠道,這還不包括調試、修改的時間。中小CP有沒有這我的力去作事情不說,光時間成本就是一個手遊新產品所不能接受的。花一個月的時間去接渠道?這一個月的時間都夠折騰死好十幾個小CP的了。當年TypeSDK成員所在的CP,就有趕不及上線,最終無力承擔開支最終倒閉的。程序員
TypeSDK的製做初衷就是讓中小CP完全擺脫時間的困擾,全部的渠道包都能一鍵快速出包,且可視圖形化操做。這樣在節省時間成本之餘,由於不須要太專業的人員來負責渠道這一技術含量簡單但枯燥的工做,還能省下很多人力成本,這樣CP就能夠把專業的人才投入到更須要他們的工做中去。github
若是TypeSDK能解決時間這一問題,接踵而至的就是安全問題。沒有CP願意把本身的產品參數、運營數據暴露在外,這就是以前有不少第三方接入工具能解決相關的問題,但中小CP不敢使用的緣由。做爲中小CP原本自身籌碼就很少,若是本身的產品參數、運營數據、流水營收都捏在第三方平臺手裏的話,那安全性根本無從談起。安全
而TypeSDK在研發之初就作出了TypeSDK代碼永久開源的承諾,代碼開源意味着什麼?它意味着,CP能夠在內網環境搭建SDK打包服務器,出包後全部的數據也徹底不會經TypeSDK之手流到第三方手裏去。一言蔽之,TypeSDK等因而CP本身開發出來的運營工具,CP徹底不用擔憂本身的遊戲代碼泄露、產品數據外流、營收流水被劫持這些問題。服務器
最後咱們來講一說渠道,這就要從TypeSDK爲何要叫統一渠道SDK接入框架提及,有作過渠道接入的朋友可能知道很多大渠道是拒絕CP使用第三方聚合SDK接入的,就是咱們常說的聚合SDK。渠道爲何拒絕聚合SDK?仍是由於上文所說的安全性,做爲渠道他們但願本身與CP的合做更爲單純,減小第三方的介入。CP做爲一個產品提供者,經由渠道將產品發佈至玩家,自己這是符合互聯網經濟「減小中間層、下降渠道成本」理念的。若是再加入一個聚合SDK,這自己並不是產業鏈關鍵,且只是手遊運營工做中的細分項目還來分一杯羹的話,CP和渠道對它如此排斥也就不難理解了。這就是爲何TypeSDK要叫統一渠道SDK接入框架,而不是聚合SDK的緣由。框架
使用TypeSDK的話,就不須要擔憂被渠道拒包了,TypeSDK的開源屬性就決定了渠道不會認爲這是由聚合SDK打出來的渠道包。另外TypeSDK的研發人員,都是在CP工做多年長期與渠道接觸的一羣人,他們一早就把各個渠道的細節要求都融合到TypeSDK中去了,CP不再須要在一些好比角標大小、圖片尺寸等小問題上反覆修改延誤工期了。
分佈式
若是一個第三方SDK接入工具,它免費、開源、安全,出一個渠道包只須要5分鐘,TypeSDK還整合了更多的功能,好比設計簡潔便於二次開發、能夠構建自有接入框架、分權限管理功能、分佈式批量打包出包等等
工具