# 手游发行平台SDK

**Repository Path**: swei/sdk

## Basic Information

- **Project Name**: 手游发行平台SDK
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2017-07-26
- **Last Updated**: 2023-05-08

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

#手游发行平台SDK

##1、背景，解决问题，优缺点
```
游戏发行公司，核心是负责游戏商业化运作，而上架渠道则成为获取流量的关键一步。
国内渠道方为把控用户、收入、游戏运营数据，会让游戏方接入SDK，通常这需要0.5-1.0工作日。
这使得一个游戏如果同时首发上架30个渠道，工作量是十分巨大的，因此市面出现了例如quick、棱镜等这样的融合SDK。

这种融合SDK做法的本质是做了一套标准接入流程，屏蔽各个渠道SDK之间的差异。
CP只需简单接入一套标准化接口，便可按需打包、生成相应安卓和IOS的游戏渠道包。

优点：前期技术投入很少，只需让CP接入诸如quick、棱镜即可出包上架。

缺点：
1、数据保密性。因为接入完全交由quick、棱镜这种三方平台，那么三方平台是完全得知游戏的核心数据。
2、发行渠道控制。因为母包交给了三方平台，因此无法较好的控制上架渠道（例如工会渠道）;
3、商业结算。因为有可能渠道参数申请也委托给了融合方，那么结算方式则为渠道和融合方结算，我方和融合方结算，导致结算周期问题。
4、安全性。因为是使用三方提供的打包工具进行打包，其技术本质是逆向改造，那么游戏内部具体植入了何种代码并不透明，这存在潜在风险。
5、技术响应能力。因为是委托关系，并不一定能第一时间响应调整的需求。

总而言之，发行公司是有必要有一套自己的发行SDK技术体系，应对渠道方的各种要求。
```

##2、产品落地

```
1、供游戏方标准化接入的SDK，文档响应，讨论组支持，示例代码支撑。
2、渠道方SDK资源接入，日常更新维护。
3、母包分发成具体渠道包后台或客户端软件。
```

##3、项目计划

```
第一阶段：团队组建。
Server资深工程师一名（PHP,JAVA均可）
工作内容：
1、对接渠道方SDK服务端接入；
2、渠道方用户体系的数据创建维护，订单系统的数据维护；
3、统计后台支持

iOS工程师一名
工作内容：
1、负责上架iOS版本SDK编写，主要控制用户体系以及订单支付体系；

android工程师一名
工作内容：
1、负责渠道SDK的对接；
2、负责具体渠道打包脚本规则的编写;

产品/美术设计一名
1、负责自有渠道界面UI交互，收银台界面的绘制（该包体主要走广告推广，和渠道不分账）
2、对接公司集团内支付（支付宝、微信、网银）或自建流水体系（申请微信支付，支付宝支付，网银支付等）
3、负责后台统计界面的落地和基础指标数据
```

```
第二阶段：工程实施。
1、标准化SDK接入编写；
2、渠道SDK资源对接（拉讨论组，要测试参数）;
3、打包工具内核编写；
4、打包工具平台化，作为内部系统使用，商务只需填写渠道申请参数，即可出具体渠道上线包；
```

```
第三阶段：内部测试，A/B测试。
1、客户端渠道SDK资源测试（工程师内测 + 测试黑盒测）
2、发行游戏包体的测试
3、通过工具打包后游戏包体测试
4、游戏具体渠道内测，线上监控平台监控，crash率低于千分之三
```

```
第四阶段：发行游戏接入公司内融合SDK
1、游戏方接入公司内融合SDK，打出母包
2、商务从渠道那边申请参数，并填写在后台，通过平台出渠道包
3、运营或商务提最终上线资源给渠道
4、数据统计后台支持
```