简介：面向Unity开发者的微信与支付宝SDK接入资源包，完整覆盖微信登录、微信分享、微信支付及支付宝支付四大场景，适合需要在Android/iOS游戏中快速集成社交与支付能力的团队使用。资源包共7322个文件，压缩后约464.91MB，以C#脚本、DLL动态库、Bin数据文件为主体，同时包含Java/AAR原生适配文件、编辑器配置与Meta标记，能够支撑IL2CPP及多平台构建环境下的工程整合。已有2236人学习下载，参考热度良好。从内容构成看，内含大量可直接复用的SDK接入脚本、平台配置文件和回调处理示例，可帮助开发者减少重复造轮子，理解支付结果验证、分享场景调起、登录凭证交换等关键流程，并规避常见平台兼容与签名校验问题，从而更快完成联调上线。
1. 为什么Unity接微信和支付宝SDK这么折腾
做Unity游戏和应用的开发者，迟早都要面对第三方SDK接入这关。微信登录、微信分享、微信支付、支付宝SDK这四个能力，是国内安卓和iOS应用绕不开的基础设施，尤其是做社交、工具、电商类产品，缺一个都难受。我最早在项目里接这些的时候，光是把微信SDK跑通就花了两三天，不是因为文档多难读，而是官方文档对Unity的适配说得含糊其辞，很多坑都是自己踩出来的。
这套东西本质上是原生SDK通过Unity的AndroidJavaObject / AndroidJavaClass 或者 iOS 的 Objective-C 桥接层去调用。也就是说，Unity项目里不能直接引用微信的Android SDK类，而是要通过反射机制或者封装好的C#插件去访问Java层。iOS端则是在Xcode工程里通过UnityFramework的桥接头文件暴露方法给C#调用。理解了这一点，后面所有配置才有意义。
这篇内容适合谁看？凡是Unity项目需要在国内安卓和iOS渠道上线，并且要接微信生态和支付宝能力的开发者，都能直接用上。阅读过程中我会把每个环节的配置项、代码要点、常见坑都拆开讲，尽量做到你照着操作就能跑通。
2. 接入前的准备工作：AppID、密钥与平台配置
2.1 微信开放平台和支付宝开放平台的账号申请
微信登录、分享、支付这三个能力，都需要在微信开放平台（不是微信公众平台）创建移动应用，审核通过后拿到AppID和AppSecret。iOS和安卓要分别填Bundle ID和包名，注意签名一定要拿正式签名的MD5值去填，测试签名和正式签名不一致的话，登录和支付会直接回调失败，这种问题排查起来特别折磨人。
支付宝相对简单，在支付宝开放平台创建应用，签约支付产品，拿到支付宝公钥、应用私钥、APPID这三件套。支付宝的密钥用RSA2算法生成，工具在开放平台后台可以直接下载，在线生成后要把公钥上传到平台，私钥保存在本地用于请求签名。这里有个常见误区：SDK验签用的支付宝公钥和后台上传的应用公钥不是同一个，别搞混。
2.2 Unity工程的安卓导出配置
Unity接安卓SDK，推荐的方式是直接导出Gradle工程而不是导出AAR。原因很简单，微信和支付宝的SDK都依赖AndroidX库，如果Unity版本较老，默认的Android Support Library会和新SDK冲突。用Gradle工程，你可以在build.gradle里手动调整依赖版本，避免一堆莫名其妙的构建错误。
Unity版本建议用2019.4 LTS以上，安卓导出模块勾选SDK和NDK。微信SDK推荐用官方最新的版本，Android Studio里新建的模块把wechat-sdk-android-xxx.aar复制到libs目录下。支付宝SDK同样也是一股脑丢进libs。然后在settings.gradle和build.gradle里配置好仓库地址：
allprojects { repositories { google() mavenCentral() flatDir { dirs 'libs' } } }这一步的目的是让Gradle能把libs目录下的AAR包当依赖解析，不配置的话就算你把文件放进去也一样报找不到包。
2.3 iOS端的初始配置
iOS端微信SDK是通过CocoaPods安装，或者手动拖入。如果是手动拖入，必须把SDK的静态库文件和Resource bundle都加进Unity导出的Xcode工程里，然后在Build Settings中设置Other Linker Flags为-ObjC。这一步不设置的话，调用微信方法时会直接崩溃，报unrecognized selector错误。
支付宝iOS SDK也是类似流程，把AlipaySDK.framework拖进去，然后在Build Phases里确保Embed Frameworks。iOS端的URL Scheme配置同样重要，微信和支付宝的回调都靠它唤醒App。
3. 微信登录接入实操：C#层到底写了什么
3.1 安卓端Java桥接类编写与AndroidManifest配置
微信登录在安卓端需要注册一个WXEntryActivity作为回调入口。这个Activity必须放在应用包名下的wxapi目录里，也就是说如果你的包名是com.example.game，那么WXEntryActivity的路径必须是com.example.game.wxapi.WXEntryActivity。这个包名路径是硬性的，改动任何一部分都收不到微信的回调。
用Android Studio建一个Module作为Unity插件，写一个Java类，里面封装微信SDK的核心方法。比如初始化：
public class WeChatBridge { private static IWXAPI wxApi; public static void init(Context context, String appId) { wxApi = WXAPIFactory.createWXAPI(context, appId, true); wxApi.registerApp(appId); } public static void login() { SendAuth.Req req = new SendAuth.Req(); req.scope = "snsapi_userinfo"; req.state = "unity_login"; wxApi.sendReq(req); } }Unity C#端就通过AndroidJavaClass去调用这些静态方法：
using UnityEngine; public class WeChatBridge : MonoBehaviour { private static readonly AndroidJavaClass wechatBridgeClass = new AndroidJavaClass("com.example.game.WeChatBridge"); public static void Init(string appId) { AndroidJavaClass unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"); AndroidJavaObject activity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity"); wechatBridgeClass.CallStatic("init", activity, appId); } public static void Login() { wechatBridgeClass.CallStatic("login"); } }这里要特别注意，微信SDK的初始化必须在主线程中执行，如果Unity的Start方法里调用没问题，但如果在非主线程的异步回调里初始化，会直接抛异常。
3.2 iOS端桥接：从GameObject到UnitySendMessage
iOS端的微信登录，需要把SDK的回调事件传递回Unity。在Unity的AppController或UnityAppController子类中，注册微信SDK后，当SDK回调登录结果时，用UnitySendMessage方法传给场景里的某个GameObject：
- (void)onResp:(BaseResp *)resp { if ([resp isKindOfClass:[SendAuthResp class]]) { SendAuthResp *authResp = (SendAuthResp *)resp; NSString *code = authResp.code; NSString *message = [NSString stringWithFormat:@"%@|%d", code, authResp.errCode]; UnitySendMessage("WeChatManager", "OnLoginCallback", [message UTF8String]); } }C#端只需要定义一个带字符串参数的公共方法即可：
public void OnLoginCallback(string result) { string[] parts = result.Split('|'); string code = parts[0]; int errCode = int.Parse(parts[1]); if (errCode == 0) { // 拿code去后端换取access_token和用户信息 StartCoroutine(ExchangeAccessToken(code)); } }这里的关键点在于，微信登录返回给客户端的是临时授权code，真正获取用户信息（openid、昵称、头像）必须在服务端调用接口完成。客户端拿code去请求资源，就等于把AppSecret暴露给了所有能抓包的人，这是极其不安全的做法。我在前一个项目里见过把AppSecret写在客户端拿去换token的，上线没几天账号就被别人盗刷了。
3.3 登录状态回调与生命周期管理
登录完成后，微信SDK会通过WXEntryActivity的onResp方法回调。Unity端的GameObject必须在场景加载时保持常驻，并且方法名要和原生层SendMessage的目标完全一致。C#方法签名需要注意大小写敏感，Unreal里因为大小写匹配不上导致回调丢失的情况很常见，Unity的坑其实是一样的。
另一个细节是，安卓的Activity在微信跳转回来时可能被系统杀掉重建。所以Unity场景中负责接受消息的GameObject，建议用DontDestroyOnLoad挂载，否则微信授权页面跳转回来后，游戏场景重新加载，GameObject被销毁，回调就没人接了。
4. 微信分享：从分享文本到分享图片+链接
4.1 原生层分享接口封装
微信分享在Unity端比登录好接得多，因为不涉及Activity跳转的回调注册，只是发送一个请求就够了。安卓端的Java类里封装一个分享方法：
public static void shareWebPage(String title, String description, String url, String thumbPath) { WXWebpageObject webpage = new WXWebpageObject(); webpage.webpageUrl = url; WXMediaMessage message = new WXMediaMessage(); message.title = title; message.description = description; message.mediaObject = webpage; message.thumbData = getThumbData(thumbPath); // 压缩到32KB以内的缩略图 SendMessageToWX.Req req = new SendMessageToWX.Req(); req.transaction = "webpage" + System.currentTimeMillis(); req.message = message; req.scene = SendMessageToWX.Req.WXSceneSession; // 好友会话 wxApi.sendReq(req); }缩略图这个点特别值得注意，微信要求thumbData在32KB以内，超过这个值就直接分享失败。很多人在Unity端传原图路径进去，结果一分享就报错。解决办法是在Java层用BitmapFactory解码后压缩，或者干脆在Unity端就先把图片缩成一个256x256的Texture2D，再转成byte[]传过去。
4.2 iOS分享与SceneType
iOS端微信分享的逻辑相似，但参数类型和设置方式有些不同。用WXMediaMessage创建消息对象，webpageObject设置网页地址，然后构建SendMessageToWXReq请求，scene字段选择WXSceneSession、WXSceneTimeline或WXSceneFavorite。
iOS分享还有一个坑：如果要分享缩略图，需要通过UIImage的SDK方法将图片缩略到合适尺寸，再把图片转成NSData，最后设置到message.thumbData。这里图片必须是JPEG或PNG格式，否则微信识别不了。
4.3 UI层与业务层解耦
Unity端建议把分享逻辑封装到一个独立的类中，UI按钮只负责调接口，不关心具体平台。用#if UNITY_ANDROID和#if UNITY_IOS进行平台分支判断，这样代码结构清晰，后续想加分享到朋友圈、收藏等场景也只是在多传一个Int参数的问题。
分享回调处理的方式和登录有差异：登录和支付需要Activity接收回调，分享如果只是发请求，可以不关心结果。但如果你需要知道用户是否成功分享（比如做邀请奖励活动），那也必须注册回调Activity，在onResp里返回errCode为0即成功，-2表示用户取消。
5. 微信支付接入：服务端下单与客户端拉起收银台
5.1 Unity端应该如何与后端配合
微信支付的正确流程是：客户端发起下单请求 -> 服务端调用微信统一下单接口 -> 拿到prepay_id -> 服务端生成二次签名 -> 返回给客户端 -> 客户端调起微信收银台。客户端绝对不能自己拿着AppID和商户号去请求统一下单，原因和登录一样，密钥在客户端就是透明的。
服务端返回给Unity的数据一般包括appId、partnerId、prepayId、nonceStr、timeStamp、sign这六个字段。Unity端把这六个字段传给原生SDK，再由原生的pay方法调起收银台。
5.2 安卓端支付代码
public static void pay(String appId, String partnerId, String prepayId, String nonceStr, String timeStamp, String sign) { PayReq request = new PayReq(); request.appId = appId; request.partnerId = partnerId; request.prepayId = prepayId; request.packageValue = "Sign=WXPay"; request.nonceStr = nonceStr; request.timeStamp = timeStamp; request.sign = sign; wxApi.sendReq(request); }注意packageValue这个字段不能动，必须是那个字符串。timeStamp在微信支付SDK中就是字符串类型，不需要转成long再拼回String，直接传就好。
5.3 支付回调处理与状态校验
支付结果通过WXEntryActivity的onResp回调到Unity层。errCode为0表示支付成功，-2表示用户取消，其他值为失败。但这里有一个重要的原则：客户端收到成功回调后，只能用来刷新UI，真正的订单判定必须依赖服务端回调通知和查询接口。因为客户端回调是可以被篡改和模拟的。
实现上，推荐在支付成功后除了UI提示，立即调服务端的订单查询接口，以服务端返回的状态为准。如果服务端显示未支付，客户端要给出对应提示而不是直接发奖。
6. 支付宝SDK接入：更简单的流程与更隐蔽的坑
6.1 安卓端接入与Unity转调
支付宝SDK比微信清爽不少，客户端不需要注册回调Activity，只要在点击支付时把服务端拼装好的orderString传给支付宝SDK即可。安卓端的桥接代码：
public class AlipayBridge { public static void pay(final Activity activity, final String orderInfo, final String callbackObjectName) { final Runnable payRunnable = new Runnable() { @Override public void run() { PayTask alipay = new PayTask(activity); Map<String, String> result = alipay.payV2(orderInfo, true); final String resultStatus = result.get("resultStatus"); activity.runOnUiThread(new Runnable() { @Override public void run() { // 通过UnitySendMessage回调给C# } }); } }; Thread payThread = new Thread(payRunnable); payThread.start(); } }支付宝的PayTask调用必须在子线程中执行，这是很多Unity开发者第一次接的时候踩得最狠的坑——在主线程直接调，界面会卡死，严重时直接ANR。
6.2 iOS端接入与URL Scheme
iOS端支付宝SDK的接入主要是在AppDelegate的openURL回调里处理支付结果，通过[AlipaySDK defaultService] processOrderWithPaymentResult:standbyCallback:方法解析结果。Unity层需要把回调结果传给C#侧。
支付宝iOS的URL Scheme建议配置为alipay加上你的AppID前缀，比如alipay2024000000000000，确保唯一，避免与其他App冲突。
6.3 服务端签名与客户端验签的边界
支付宝支付流程里，orderString是服务端用支付宝私钥对业务参数签名后生成的字符串。客户端不参与签名，但可以在收到支付宝回调结果后，用支付宝公钥对结果做验签。这样做可以防止结果被第三方篡改。不过在Unity端，验签逻辑一般不写在客户端，因为公钥虽然在客户端不至于太敏感，但防篡改的核心还是依赖服务端二次确认。
7. 常见问题与排查技巧实录
7.1 问题速查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 微信登录无响应 | 未在开放平台配置正确签名 | 检查签名MD5是否与正式签名一致，用微信官方签名获取工具验证 |
| 登录回调收不到 | WXEntryActivity路径错误 | 确保Activity位于包名.wxapi目录下，且在AndroidManifest中声明 |
| 微信分享图片失败 | 缩略图超过32KB | 对缩略图做压缩处理，控制在32KB以内 |
| 支付返回-1 | 签名错误或参数不完整 | 核对服务端返回的签名字段与prepayId是否一致 |
| 支付宝ANR | PayTask在主线程执行 | 放到子线程中调用payV2 |
| iOS编译报错找不到微信类 | 缺少-ObjC标志 | Build Settings > Other Linker Flags 添加-ObjC |
| Unity场景切换后回调丢失 | 接收消息的GameObject被销毁 | 用DontDestroyOnLoad保留常驻节点 |
7.2 调试经验分享
调试微信SDK最痛苦的地方在于看不到底层日志。我的做法是写一个DebugLog工具类，在Java层的onResp回调里把返回的errCode和errStr通过UnitySendMessage传给C#，再在Unity的Console中打出来。这样一次联调就能看到完整链路，省去反复查日志的烦恼。
支付宝那边相对友好，PayTask返回的resultStatus字段含义很清晰：9000表示成功，8000表示支付宝正在处理中，6001表示用户取消，4000表示订单支付失败。出现非9000的状态码时，先别急着改代码，去服务端查一下订单详情，很多时候是签名参数被篡改或者订单已过期。
7.3 一些比SDK接入本身更重要的事
我在多个项目里做过一个相似的优化：把第三方SDK的初始化全部延迟到首帧渲染之后再执行。原因很简单，微信SDK初始化可能需要几毫秒到几十毫秒不等，如果放在启动流程的前几步，在低端安卓机上会明显拖慢首屏打开速度。而支付宝SDK初始化更重，反而建议尽早初始化，因为它的首次支付调用有个额外的网络握手流程。
另外一个容易被忽视的点是：在安卓上切换应用回来后，Unity的OnApplicationPause会被调用。很多开发者在这个回调里只处理游戏暂停逻辑，忘记把微信/支付宝的跳转返回状态同步给SDK。虽然现代SDK一般自带了Activity生命周期监听，但如果你用的版本较老，最好在OnApplicationPause参数为false时主动调用SDK的onResume接口，避免支付完成后状态不同步。
8. 我的最终实践体会
走了这么一大圈，我的感受是：Unity接微信和支付宝SDK这件事，本身难度不高，高的是对原生生态的理解。如果你之前只写过纯C#逻辑，第一次看到AndroidJavaObject和UnitySendMessage会非常不适应，但这两个机制就是Unity和原生世界对话的全部桥梁。
接入过程中最重要的习惯是：把原生层的每个入口封装得足够小、足够单一。不要写一个巨大的Java类把所有API都塞进去，也不要让Unity层直接依赖iOS的实现细节。把登录、分享、支付拆成三个独立的模块文件，每个模块的C#接口保持一致，这样将来无论是换SDK版本还是加新渠道，都不至于动到游戏逻辑层的代码。
还有一点：SDK升级要极其谨慎。微信SDK和支付宝SDK的版本更新频率虽然不高，但每次更新都可能改变回调的线程模型或回调参数的格式。升级前一定要看官方更新日志，升级后在真机上完整跑一遍登录、分享、支付全流程，不要只看编译能不能通过。我吃过一次亏，微信SDK从5.x升到6.x后，旧的WXEntryActivity回调线程变了，原来的UI操作直接崩溃，排查了很久才发现是SDK行为变化导致的。
最后再分享一个实用技巧：在Unity工程的Assets目录下建一个Editor文件夹，写一个简单的菜单脚本，一键打开微信和支付宝的开放平台配置页面、一键生成签名MD5等，这些日常重复操作自动化之后，效率能提升不少。看起来是小事，但真正在联调阶段不断切换配置、重打签名、查看AppID的时候，这种微小的效率提升会带来非常大的体验差异。
本文还有配套的精品资源，点击获取
