由于去年有几周接触过游戏发行的流程，简单记录下游戏打包时的流程。
一般游戏的最终上线都是放在各应用商店中的，游戏每走一个应用商品，一般都会接相对应应用商店的渠道SDK，也就是所谓的联运。游戏打包也主要是处理各渠道SDK的接入问题。
一个游戏最终是会对应多个渠道的，也就是需要一个工具，将一个游戏母包只要修改相对应的渠道参数，渠道相对应的文件，打包成具体的相对应的渠道包，之后测试通过后再放到各应用商店进行审核。
这里会分三部分：游戏母包、渠道资源包、自动化打包系统。
游戏母包：接入已封装测试渠道的SDK，对接统一化接口，一般主要走通SDK的登录、支付、数据上报交互逻辑的游戏包体；
渠道资源包：聚合SDK对接渠道SDK接口后，封装给打包系统的整合资源包，通常资源的结构形式会跟自动化打包系统对应；
自动化打包系统：输入游戏母包和渠道资源包后，自动化解包、合并资源、封包，最终输出游戏_渠道包。
打包流程简图
这里比较核心的部分分两部分，游戏母包和渠道资源包、自动化打包系统。在自动化打包系统中输入相对应的渠道资源包及渠道参数，最后生成各个渠道游戏包。
接入各个渠道SDK一般主要修改的逻辑是，登录逻辑，数据上报逻辑，支付逻辑，以及发货逻辑。
正常来说，一般除了打包工具外，还有打包后台管理系统和一个支付管理后台三部分组成：
打包工具：也可以叫聚合SDK，负责将游戏母包，反编译后并替换成各个渠道的相对应资源文件，最终打包成各个渠道包。
打包后台管理系统：管理各个渠道的资源包，参数等(如key、秘钥、发货路径等等)，并可以管理各渠道SDK的版本，配置完后，打包工具会根据后台系统设置的参数，进行打包替换工作。
支付管理后台：可查看和统计各个渠道的游戏订单情况，也可以查看发货情况，并可进行补发。
最后打包成各个渠道包后，最主要的还是测试，主要是否能拉取各渠道的登陆页面，是否能数据上报，是否能拉取各渠道的支付页面，并是否能正常到账等，一切测试正常后就可以上传到相对应应用商店审核了。
