本文引用至http://docs.anysdk.com/Introduce (mark一下)
1.常规方式手工接入SDK有什么弊端？开发者为什么需要使用AnySDK？
目前国内有大大小小一百多家手游分发市场渠道，其中拥有自己sdk的渠道也有六七十家。开发者在开发完游戏之后马上要面临的就是选择渠道上架。基于多一个渠道多一份收入的原则，大部分开发者都会选择去上线所有能找到的渠道。那么这时候就面临一个很严重的问题，那就是渠道要求开发者在游戏中接入相应渠道的登录及支付sdk，才能让玩家使用在渠道注册的账户来登录游戏，并发起支付在游戏内充值。也就是说只有接入了渠道sdk的游戏才能通过渠道审核并上架。
凡是曾经手工接入过各家渠道sdk的开发者都会知道，由于每一家渠道SDK的设计不同，SDK里自带的资源文件，代码jar包，功能接口数量等都是完全不一样的，而且并不能在同一份游戏代码中同时嵌入多家SDK的内容，因此开发者必须维护多套游戏代码项目来分别接入各家渠道SDK，或者配置繁多的参数然后使用ant等自动化打包工具来打包不同渠道的apk。前者会使游戏逻辑代码维护极为不便，任何一处代码逻辑的修改或者bug修复，都必须手工在所有渠道包项目中都找到相同的代码进行修改并测试。而后者并不能满足很多渠道特有的一些新增接口需求及ui界面改动，而这还只是客户端程序员的工作量。同样的，服务端的开发者也需要去研究每家渠道设计的不同加密算法及数据校验方式来开发订单数据校验和用户登录安全认证接口，然后跟客户端的技术一起一遍遍的测试联调接口是否运行正常。
如果仅仅是上面的问题，那接SDK这件事还可以简单的归结为重复体力劳动，只要愿意花时间去研究各家SDK文档并一一对应做实现就可以完成渠道SDK的接入。但是在真正的开发过程中很多开发者尤其是一些中小型开发团队，还会遇到另一个难题——那就是没有专门的开发人员来接入SDK。众所周知，目前手游开发引擎市场cocos2d-x，unity3d占一大半市场，其余部分是各种公司的自研引擎，到目前为止，还没有任何一款被大众所认可的成熟的市场化的游戏开发引擎是使用java语言的。因此，有很多团队里面的游戏研发人员都是单纯的c++，c#或者是lua开发者，对java并不熟悉而且也没有android应用的开发经验。但是偏偏目前市场上绝大部分的渠道sdk都是纯java版本，这就意味着要想从游戏逻辑代码中调用sdk的相关函数实现登录，支付，统计等功能，那么开发者就必须要手动去写jni函数进行java层代码与c++层代码的双向调用(其他语言同理)，这就需要开发者对java语法和jni规则比较熟悉。而且接入过程中也会涉及到很多android层的ui相关的配置及资源管理。因此一个团队如果没有熟悉java和android的开发人员，接入sdk的工作就会变得难以下手。
综上所述，接入渠道sdk这件听起来很简单的事，在实际生产开发中并不是那么想当然的小事一桩。根据AnySDK收集的数据显示，一个有经验的开发者平均接入一款渠道sdk需要耗费的时间(客户端接入+服务端对接)大概在两天到三天之间，而如果是之前没有接入sdk经验的开发者，这个时间会增加到两倍，因为有很多渠道的特殊需求及“潜规则”需要了解，而且可能需要面对渠道技术支持无限扯皮的情况。更严重的问题是，当游戏要接入上线的渠道非常多的时候，这个耗费的时间数量会成倍增长，也就是说你接入前一款sdk时候所做的工作并不能减少你接入下一款sdk需要的工作量。对于一款开发完成，即将上线的游戏来说，最珍贵的资源，莫过于时间了，早一天上线就能早一天赚钱，多上一个渠道就能多一份收入。相信这个时候任何一家公司的运营人员都会拿着一堆渠道sdk的参数整天追在技术同学后面碎碎念的:)
那么AnySDK的出现就是为了替广大开发者解决这些问题，AnySDK是一款为开发者加速接入第三方SDK的工具。他可以帮开发者实现只接入一次就可以批量打出所有渠道包，并且不再需要关心sdk的版本更新和处理因为渠道服务端接口变化造成的紧急重复更新工作。而且AnySDK提供了各个语言版本的框架，开发者只需要选择自己熟悉的开发语言，根据AnySDK的文档接入一次，花费的时间跟手工接入一个渠道sdk的时间相同，然后就可以通过anysdk提供的打包工具打出包含了不同的SDK的渠道包直接提交给渠道审核上线，减少了大量的开发工作量，在面对几十个渠道sdk时再也不用愁眉苦脸了。
2.AnySDK如何实现一次接入，批量打包？
简单的来说，就是四个字——”统一接口”。在客户端，AnySDK提供了五个不同语言游戏引擎版本的框架供开发者选择，开发者尽可以选择自己熟悉的语言版本来集成，再也不用关心c++/js/lua/c#如何去调用java层的一个函数。在AnySDKFramework中，总共有六大类接口——分别是用户，支付，统计，分享，广告和推送。开发者只需要根据自己的需求来调用相应的函数，比如想要打出的渠道包能登录，能支付，并能显示广告。那么就只需要根据AnySDK的文档调用login，payForProduct，showAds等函数，传入相应的参数就可以，不需要关心360的sdk需要在支付的时候传入什么参数，百度的sdk又需要在支付的时候传入哪些参数，同样的，虽然实际上显示广告的函数在admob的sdk和畅思广告的sdk中定义的并不是同一个函数名称，甚至参数也完全不同，但通过AnySDK，你完全不必去了解这些，只需要看一遍AnySdk的文档就可以，在实际打出的包含了真实sdk的渠道包中，真正调用相应sdk函数的工作由AnySDK来完成。
同样的，在服务端，开发者也不用关心某家渠道的文档规定了开发者需要以什么样的加密方式和校验算法来校验渠道服务器推送到游戏服务器的订单数据，开发者需要做的，只是根据AnySDK提供的文档来对接收到的数据做一次安全性校验就可以确认当前订单是来自哪个渠道，是否支付成功等。各渠道间不同的协议和规范由AnySDK去帮开发者完成统一。
3.接入AnySDK的流程是什么？如何理解母包及渠道包的概念？
接入AnySdk十分方便，开发者只需要去AnySDK管理后台http://dev.anysdk.com/去注册一个开发者帐号并新建一款游戏，然后就可以在http://www.anysdk.com/downloads去下载最新版本的AnySDK开发组件，其中包含了AnySDKframework，打包工具，以及Sample项目代码。
开发者首先要做的就是参照AnySDK的文档（http://docs.anysdk.com/CppTutorial此为c++版本，其他版本文档可在文档页面左侧列表查看）来将AnySDKframework集成到游戏项目当中。然后直接运行项目，观察是否成功调用了初始化，登录，支付等函数。如果接入正常的情况下调用除初始化以外的其他函数都会在游戏界面显示出相应的ui界面提示。
当开发者直接运行接入了AnySDKframework的项目测试调用相应函数没有问题之后，就意味着接入AnySDK Framework已经成功，这时候运行项目所编译出的apk包称之为”母包”。顾名思义，这个APK包用于生成包含渠道SDK的”渠道包”，”渠道包”就是用于提交给各渠道审核，审核通过之后分发给最终玩家的APK包。简单来说，”母包”就是游戏代码 +AnySDK Framework；”渠道包”就是游戏代码 + AnySDK Framework+ 渠道SDK(包括代码+资源)。
那么如何生成渠道包呢？AnySDK提供了一个功能强大的界面化打包工具，通过简单的四步就可以通过”母包”生成”渠道包”。首先，选择你要打包的APK所属的渠道(如百度91，360等)；然后，选择你希望在当前渠道的APK包中集成的SDK(比如91渠道，根据渠道要求，你要在APK中集成百度游戏的用户和支付sdk。你也可以额外集成一些其他的如推送，统计等SDK)；第三步就是为你选择的的每一个SDK配置相应的开发者参数(开发者想要使用任何一个SDK都必须先去SDK提供方的网站去申请相应的开发者参数，这是非常重要的一步)，以及选择是否需要添加渠道闪屏(根据渠道要求，目前所有要求添加闪屏的渠道AnySDK都已经提供了闪屏选项)，并可以根据渠道的规定来修改游戏icon，添加相应的渠道角标。最后一步，就是点击打包按钮，等待10-20s之后打包工具就会生成渠道包，开发者可以直接点击”安装”按钮将渠道包直接安装在手机上来测试生成的渠道包工作是否正常。
当开发者通过”母包”生成了相应渠道的”渠道包”并通过测试之后就可以将这些APK包上传到相应的渠道开发者后台来申请渠道审核并上架。如果打出的渠道包在测试过程中发现了某些接口运行结果异常，或者在提交渠道测试之后渠道的审核结果有反馈某些功能异常。则需要开发者再次修改母包中的代码，修复bug之后再次重复上面编译打包的过程来生成渠道包再次提交测试。
4.手工分别接入各家渠道SDK与通过AnySDK接入各家渠道SDK，代码有什么区别？
在这里我以渠道SDK最重要的功能—用户登录和支付功能为例，讲解一下手动接入渠道SDK和使用AnySDK接入渠道SDK之后代码的运行流程。
如果是开发者手工接入渠道用户系统sdk，首先要在代码里调用SDK提供的登录函数Login(举例，很多SDK提供的登录函数并不是命名为Login，而且不同SDK函数需要的参数类型与个数都不同)，登录成功后根据具体的文档说明解析登录返回结果，提取出用户信息，以及AuthCode。然后请求游戏服务器，将获取到的用户数据传给游戏服务器，游戏服务器再去请求渠道服务器，进行用户信息的安全性验证，获取Token。然后游戏服务器将token回传给客户端，然后客户端保存此token用于调用sdk其他函数，然后客户端再请求游戏服务器获取玩家角色相关信息显示。
在上面这个过程中，所有的代码都需要客户端开发者手动去解析sdk返回的数据，发起网络请求跟游戏服务器做交互，同样的，游戏服务器端的开发者也需要按照每一个SDK的文档要求去请求渠道服务器，传入合适的参数去做用户安全校验来得到token然后再返回给客户端。
而如果是使用AnySDK接入渠道用户系统SDK之后，开发者只需要在客户端调用Login函数，然后就什么都不用做了，AnySDKFramework会负责处理后续的登录验证与token请求的全过程，当完成登录流程之后会自动回调客户端设置的监听函数，开发者只需要在监听函数里处理登录完成后的游戏业务逻辑就可以了，也就是说使用了AnySDK之后开发者再不需要关心当前使用的是什么渠道的SDK了。
而对于接入渠道支付SDK来说，最复杂的莫过于跟每一家渠道服务端联调订单数据校验这一部分工作。因为每个SDK设计的订单信息字段都是不同的，采用的加密方式和数据组合格式也是各不相同，因此开发者需要对不同渠道推送过来的订单数据分别做判断然后进行校验，这个开发过程需要花费的时间随着接入渠道的增加而会成倍的增长。而采用AnySDK打包之后，开发者需要做的工作就简单多了，AnySDK 会帮开发者统一所有渠道推送过来的订单数据，用统一的数据格式和加密方式进行封装再推送给游戏服务器，开发者只需要按照AnySDK 的文档来进行订单数据的校验就可以确定支付结果，无论接入多少渠道SDK，都不需要任何额外的工作量增加。
5.如何理解AnySDK登录流程？什么是”登录验证地址”？
在上面有讲解过手工接入渠道SDK最基本的登录流程，那么使用AnySDK 进行登录实际上就是对这个流程做了大幅度的简化，这里分为客户端和服务端开发者需要实现的代码逻辑来讲解。
首先是客户端，在游戏代码中先初始化AnySDKFramework，当接收到框架初始化成功的回调函数之后直接调用Login函数即可显示出SDK的登录界面(在直接运行母包的情况下显示的是AnySDK 自带的用于测试的界面，打出渠道包之后显示的就是在打包工具中选择的相应用户系统SDK的登录界面)，当玩家输入了正确的用户名和密码之后AnySDK 就会自动处理后续的登录及用户验证流程，当完成用户登录验证之后就会自动回调到开发者在前一步设置的用户系统监听函数。开发者就可以在登录成功的回调函数中处理后续的游戏逻辑。整个登录过程客户端只需要调用一个接口就可以了。
那么服务端需要做什么呢，在客户端调用login接口之后AnySDKFramework会请求“登录验证接口地址”(此地址在打包工具中参数配置页面进行配置，而在未经过打包工具的“母包”中，则是请求代码中初始化AnySDKFramework时填入的第三个url参数)，这个接口负责负责将客户端请求过来的所有参数转发给AnySDK服务器(客户端请求过来的参数个数是不确定的，因为每个SDK登录验证需要的参数都是不同的，所以在这个接口中需要遍历解析所有的请求参数，然后全部转发给AnySDK 服务器。在AnySDK的文档中已经提供了现成的代码供开发者直接部署使用)去做登录验证，然后AnySDK服务器会返回登录验证结果，开发者将验证结果的完整数据再返回给客户端就可以了。注意，上面这个过程是一次HTTP连环请求，也就是说下面这个过程：
客户端 ——请求——> 游戏服务器(登录验证接口) ——请求——>AnySDK服务器(跟渠道服务器交互) ——返回——> 游戏服务器 ——返回——>游戏客户端
是在同一次HTTP请求中完成的。只要客户端AnySDKFramework 回调了登录成功的函数，就说明整个登录验证流程完全走通了，此时可以在AnySDK 管理后台查询到登录成功日志。当然，在此过程中游戏服务器还可以传递一些自定义的数据给游戏客户端以供后期的游戏逻辑使用，具体的文档说明请参见地址http://docs.anysdk.com/OauthLogin
6.如何理解AnySDK支付流程？什么是”支付通知地址”？
在正式使用AnySDK 发起支付之前，必须要先明确两点，首先，绝大部分的渠道SDK，其支付系统和用户系统是绑定在一起的，也就是说想要使用渠道SDK发起支付，那么首先要登录成功才可以。在打包工具中选择SDK的时候需要一起选择用户系统和支付系统SDK，在代码中也需要先调用登录函数，登录成功之后才能发起支付。如果在还没有登录的情况下直接调用支付函数，那么AnySDKFramework内部会自动先弹出登录框，登录成功后再自动发起支付流程。其次，目前AnySDK集成的支付SDK，除了少数几个明确标记为”单机版”和“弱联网”之外，其他所有的SDK发起支付后客户端支付监听函数里面回调得到的支付结果都不能作为真正的订单支付结果来使用。有很多SDK在设计中就是只要进入支付界面，生成订单号，或者发送支付信息成功后就会回调支付成功函数。因此一笔订单真正的支付结果必须要以游戏服务器“支付通知接口地址”接收到的AnySDK推送过来的订单信息为准，也就是说客户端在发起支付，接到支付成功回调之后必须要去游戏服务器确认订单支付结果，然后才可以进行发放道具等游戏逻辑。
在客户端代码中发起一笔订单支付非常简单，只需要调用payForProduct函数，传入玩家当前选择的道具信息，就可以调出SDK支付界面(在母包中则是弹出一个简单的确认支付的对话框)。当玩家在支付界面中完成支付之后即会回调执行开发者设置的支付监听函数。在支付成功的回调函数中，开发者需要跟游戏服务器做通讯确定当前订单是否支付成功。
在手工接入渠道SDK的支付流程中，当客户端SDK支付完成并关闭支付界面之后，渠道服务器在处理完支付扣款流程后会推送一条订单详情数据到游戏服务器提供的“支付回调接口地址”(这个地址需要开发者手动配置在渠道开发者后台的“支付回调地址”一栏中)，这条推送信息里面包含了这一笔支付订单的相关信息并以特定的形式组装并加密。游戏服务端开发者需要在接收到这条请求根据SDK文档的说明对数据进行安全性校验，然后读取相关订单数据并保存，等待客户端发送订单确认请求确认支付结果。
而使用AnySDK 接入支付系统SDK的话，AnySDK会帮助开发者统一各家渠道的订单推送数据，格式化成统一的数据再推送给开发者游戏服务器。因此开发者需要在渠道SDK管理后台的“支付回调地址”一栏填入AnySDK 提供的当前渠道统一支付回调地址(此地址可以在打包工具中渠道参数配置界面的“渠道通知地址”一栏看到，直接复制然后配在渠道后台就可以；也可以打开AnySDK管理后台网站，在“游戏管理”——“支付通知地址”页面中看到)，然后在打包工具参数配置界面“支付通知地址”一栏配置游戏服务器提供的”支付通知接口地址”。也就是说使用AnySDK 接入渠道支付SDK的流程跟手工接入大体一致，但是AnySDK 帮开发者做了不同渠道SDK的数据格式转换，开发者不用再去关心当前是什么渠道推送过来的支付订单数据，只需要按照AnySDK 的格式来统一进行验证就可以实现订单支付结果的获取。整个支付过程即是下面这个流程：
客户端：调用支付接口发起支付 ——> 接到SDK支付成功回调 ——> 去游戏服务器确认支付结果服务端：渠道服务器完成扣款流程 ——> 推送数据给AnySDK服务器 ——>AnySDK服务器做数据校验，并格式化为统一格式 ——> 推送数据给游戏服务器 ——> 游戏服务器校验订单数据
当游戏客户端带着订单号去游戏服务器确认当前订单支付结果是支付成功之后，此时一笔完整的订单支付流程就算走完了，此时就可以根据游戏的逻辑进行游戏内物品的发放。在支付过程中具体需要实现的代码请参照http://docs.anysdk.com/PaymentNotice文档页面。象订单校验等功能都提供了现成的实现代码供开发者使用。
7.签名文件、闪屏、角标、包名后缀如何配置?
在游戏apk提交渠道上架审核之前，还需要注意几个问题。首先，是打包用的签名文件，目前在国内的渠道中，对于签名文件有三种不同的要求：第一种是强制要求开发者使用渠道提供的签名文件来进行签名后才允许提交审核(如当乐)；第二种是不强制开发者使用特殊签名文件签名，但当开发者提交包给渠道之后渠道会为apk进行一次新的签名(如小米)；第三种就是对签名文件不做特殊处理的渠道，只需要按照开发者自己的需求选择相应的签名文件就可以。在AnySDK 打包工具中目前有两个地方可以配置打包使用的签名文件，分别是游戏管理和渠道参数两个界面上。在打包过程中如果检测到开发者有在渠道参数界面配置当前渠道包使用的签名文件，就使用此签名文件进行签名，如果没有配置当前渠道专用的签名文件，则会去检测是否在游戏管理界面配置此apk通用的签名文件，有配置则用其进行签名打包。如果两边都没有进行配置，那么会使用打包工具自带的一个默认签名文件进行签名，并会在打包界面上进行提示。
其次，就是关于闪屏和角标，有些渠道会要求开发者在游戏运行最开始的界面显示渠道自己的标志界面然后再跳转到游戏自己的界面，称之为”闪屏界面”。还有些渠道会要求开发者在游戏启动的图标上面添加渠道规定的标志图案，称之为”游戏角标”。在常规接入的流程中这些工作都需要开发者手动去每一个添加新的启动界面来显示闪屏图片，然后去让美术人员去做出若干个不同大小的附加了渠道角标的图标文件去手工替换项目内原有的图标文件再进行打包。那么使用AnySDK进行打包的话就不用这么麻烦了，打包工具内已经提供了渠道相关的快捷选项，当开发者选择打包某个要求添加闪屏和角标的渠道包的时候，在渠道参数配置界面可以选择是否添加渠道闪屏，添加横屏还是竖屏闪屏资源，有些渠道还可以选择闪屏底色是白色还是黑色等。然后在渠道参数配置界面点击下一步会跳转到icon管理界面，在这个界面，开发者可以为已选择的渠道包进行icon的修改，添加各渠道需要的角标图案，还可以进行位置自定义并微调。
最后，还有包名后缀，在Android开发中，包名是一个非常重要的参数，它是用来确认两个应用是否相同的唯一标志，在同一台Android设备上不能有两个包名一样的apk被安装。这个参数在Android项目中的配置位于AndroidManifest.xml文件中的packge属性。目前有很多渠道市场要求开发者上传的apk包的包名要以渠道规定的后缀结尾，以区分不同渠道下载的同一款游戏，比如91渠道包必须以nd91结尾，360渠道包要以qh360结尾等。在通常情况下这一步需要开发者手动修改包名参数然后重新打包，但是现在AnySDK 为开发者提供了方便的包名后缀自动添加功能，在打包参数界面开发者只需要配置好当前渠道包需要添加的包名后缀，在打包过程中工具就会自动帮开发者修改当前渠道包的package属性，一步到位生成符合渠道要求的包。
8.单机游戏能不能使用AnySDK？
最近一直有开发者在询问这样一个问题，就是说他们的游戏是单机游戏，想集成支付SDK让玩家进行游戏内购，能不能用AnySDK 进行打包呢。那么实际上这个问题里面其实包含了两个小问题：1，如果我们的游戏没有用户的概念，不需要用户登录SDK，只想使用渠道的支付SDK可不可以？2，我们的游戏是单机游戏，所有的数据都存在手机客户端，没有服务器，我能不能接入渠道SDK呢？这两个问题里面有些开发者遇到其中一个，也有些开发者两个问题都有。那么答案是什么呢，简单的来说，就是不可以，不可以的原因是渠道SDK的流程设计及规定导致了不接入用户系统是无法使用支付功能的，且没有服务器做用户登录验证和支付订单数据校验的话也是不可以接入渠道SDK的。但是针对这两种情况，AnySDK也都为广大开发者提供了解决方案。
对于第一种开发者不想接入渠道SDK，只想接入单独的支付SDK的情况，AnySDK为单机游戏开发者集成了支付宝单机版本SDK，以及三大运营商短信支付弱联网版本的SDK。这些SDK的共同点就是可以直接发起支付而不需要登录过程，并且在客户端完成支付过程之后SDK返回的支付回调函数中的结果即可作为订单支付的最终结果，也就是如果回调支付成功函数，那么开发者就可以认为这一笔交易已经支付成功，而不需要再去通过服务端异步验证来获取支付结果。那么看起来这么简单方便的SDK，有没有什么缺点呢？当然有，首先就是这些单机版SDK的接入资质比较难申请，比如支付宝就明确规定了只有法人资质，也就是公司才可以申请集成支付宝SDK，普通的个人开发者是无法申请的，而运营商短信支付SDK的集成资质也是非常难申请到。其次，就是短信支付类SDK在原理上是通过客户端手机发送短信到运营商服务器然后扣除相应话费的方式实现支付扣费，支付过程十分快捷，因此在早期有大量的病毒类软件使用了此类话费暗扣的方式实现窃取用户话费的目的，因此导致了现在大量的手机系统和安全类软件拥有屏蔽未知短信发送的功能，会导致用户支付不成功，或者是SDK返回成功回调，但实际上并未扣费的问题。而且运营商SDK接入后测试及发布都要通过运营商平台，调试起来比较麻烦，因此是不是要选择接入此类单机版SDK还要开发者考虑清楚。
而对于第二种情况，开发者没有服务端相关的逻辑，但是又想接入渠道SDK的话，AnySDK也有准备开发一套服务端的代码，用于处理渠道SDK的登录验证及订单支付校验功能。这套代码是免费提供给开发者并可以帮开发者部署在服务器上面，并且提供了一个后台管理系统，可以查看到所有的登录及支付数据，方便开发者管理游戏数据。开发者只需要将部署之后得到的登录验证接口地址和支付校验接口地址填入AnySDK打包工具中即可正常打出渠道包。需要具体咨询此服务请联系AnySDK的商务或技术支持。
9.公司出于数据安全考虑不想让支付信息被其他公司获取怎么办？
在指导开发者使用AnySDK接入渠道SDK的过程中，有遇到过一些开发者心存这样的疑虑：我们公司规定了游戏的充值数据是公司机密，绝对不能让其他公司获取。你们AnySDK用起来确实可以节省很多工作量，但是支付数据通过AnySDK服务器做统一转发的话就会经过你们的服务器，公司不愿意冒这个风险，可不可以只使用你们客户端打包工具来快速批量打包，但是支付订单信息由我们自己去跟每一个渠道服务器做对接进行校验，不经过AnySDK的服务器来统一转发？答案是可以！开发者完全可以只使用AnySDK 客户端框架及打包工具来快速批量生成渠道包，然后自己去处理渠道订单推送数据的校验及解析。只需要在渠道开发者管理后台的”支付通知地址”一栏填入游戏服务器自己的支付订单推送接口地址即可。另外，由于目前在发起支付的时候订单号是由AnySDK生成的，因此最后渠道推送给开发者的订单信息中订单号也是由AnySDK生成的(如果是使用AnySDK服务端做统一转发的话会帮开发者将游戏服务器生成的订单放在透传参数中传给游戏服务器)，因此，如果开发者需要使用游戏服务器生成的订单号的话需要开放一个接口用于AnySDKFramework来获取订单号并发起支付。相关具体的文档请联系AnySDK的商务或技术支持获取。
1.小米SDK登录不显示登录界面？
很多开发者在第一次打包小米渠道包并测试的时候会发现调用登录函数之后并没有显示小米的登录界面，而是直接回调了登录失败函数。但是其他的渠道包却又正常登录，说明母包代码写的没有问题，这是为什么呢？其实原因出在小米的特殊设计上面，很多渠道都要求开发者提交渠道包的时候要修改包名为固定渠道标志字符串结尾，小米也是一样，小米渠道规定要上传的apk包名必须以mi结尾。但是在小米后台的包名配置界面却没有提示，很多开发者在配置应用信息的时候在此处配置的是母包的原始包名，但是真正打渠道包的时候又添加了mi结尾，导致打出的渠道包包名与后台配置包名不匹配，而小米的SDK内部设计即是在登录前检测当前包名是否跟服务器后台配置一致，如果不一致则直接返回登录失败并且不显示登录界面，因此就有了这个问题。只要保证小米开发者后台配置的包名跟实际打出的渠道包报名一致就可解决。
2.悬浮窗没有显示是什么原因？
目前很多渠道SDK都增加了一个悬浮窗功能，即在游戏运行后界面商会显示一个半透明的悬浮窗按钮，点击之后可展开，里面容纳了若干sdk相关的功能选项。而渠道在审核包的时候也会检查开发者是否正确接入了SDK悬浮窗功能。但是各家渠道在悬浮窗功能设计上遵循的观念却又有区别，有些SDK是只要开发者初始化完成或者登录成功后SDK自动就会显示悬浮窗，而另一些SDK却需要开发者登录成功后手动调用相应的控制函数来显示和隐藏悬浮窗，如果开发者忘记调用控制函数的话虚浮窗是不会自动显示出来的。因此开发者在接入AnySDKFramework的时候要判断当前渠道SDK是否支持showToolBar和hideToolBar函数并在登录成功后调用相关函数。另外，目前有越来越多的渠道开始规定开发者必须在渠道后台配置应用包名，SDK只有在检测到当前包名跟管理后台配置的包名匹配的时候才能显示悬浮窗，否则即使登录成功或者调用了显示悬浮窗的函数也无法正确显示悬浮窗。典型的例子就是360渠道，目前360SDK内部已经需要检测包名匹配之后才能够显示悬浮窗，但是在360的开发者管理后台却没有任何地方可以配置这个应用包名，必须要开发者去联系360的技术支持或者运营人员才可以通过他们去360服务器配置正确的包名来显示悬浮窗。
3.支付界面没有显示支付方式？
有些开发者在打包渠道包成功后调用支付函数，显示出的SDK支付界面上却提示没有可用的支付方式，因此怀疑是不是有参数没有正确配置导致无法支付，常出现此问题的渠道有UC和安智等，其实这种情况出现的原因是这些渠道需要在开发者后台配置当前游戏需要启用的支付方式，开发者如果没有配置任何一种支付方式，那么SDK支付界面就不会显示正确的支付界面。此时需要开发者联系渠道商务或者运营去帮忙配置相关的支付方式即可正确开启支付功能。
4.微信分享失败？
很多开发者在集成了分享功能之后发现其他分享方式都能够正确分享，只有微信分享一直不成功。这是因为微信分享限制比较多，在微信开发者后台有两个比较重要的参数需要配置，第一个就是应用包名，第二个就是签名文件md5。微信的SDK进行分享的时候会检测当前的应用包名跟签名文件的md5值是不是跟后台配置的完全一致。如果有任何一项不匹配就会分享失败。因此如果开发者要测试微信分享功能，需要在打包工具里配置签名文件为微信后台注册的那个签名文件再打包。
5.支付提示参数缺失?
有一些开发者在测试支付功能的时候会遇到两种提示支付参数不完整的情况，第一就是在调用支付函数之后直接回调支付失败，log提示”paramincomplete”，这种情况是因为开发者在调用函数的时候传入的商品信息中缺失了某些参数，此时需要对照http://docs.anysdk.com/IAPSystem#.E6.94.AF.E4.BB.98此处文档中列出的商品信息参数来确定代码中有哪些参数尚未传入。第二种就是调用了支付函数后正确打开了SDK支付界面，但是SDK弹出toast提示商品信息不完整，这种情况是因为有些渠道需要开发者在渠道的开发者管理后台去配置当前游戏内的商品列表，并为每一个商品sh生成一个ID序号，开发者在调用支付的时候需要将此序号作为商品ID参数传入SDK才可以正确获取商品信息并支付。
6.OPPO显示商品名称不正确？
开发者在第一次打包OPPO渠道测试支付时会发现，在其他渠道支付界面上显示正常的商品名称信息在OPPO渠道SDK的支付界面却出现了问题。比如当前游戏内有一个商品叫10金币,价值10元，玩家购买后在游戏内会增加10个金币。那么在通常情况下此商品的信息参数里product_name为“10金币”，product_price为10,product_count为1 即可。但是OPPO的SDK设计比较特殊，它支付界面上显示的商品名称却是product_count + product_name，因此如此配置的话在界面上显示的就会是“110金币”这样。因此，开发者必须在代码中判断如果是OPPO渠道包，传入商品参数的时候应该将product_name设置为”金币”，product_count设置为“10”，product_price设置为”1”才可以正确的显示商品名称并计费。