① Unity-android集成微信支付出现返回-1问题
前段时间出去玩了一段时间，回公司得知一个惊天消息——微信支付出问题了！！！这个问题比较奇怪，说是部分机型可以支付成功，部分机型如小米、三星无法调起支付，返回-1。
众所周知返回-1的话代表了各种各样的错误（坑），所以只好从头开始排查，首先排查 WXPayEntryActivity.java 这个文件是否放在了 .wxapi包 下，及 manifest里的注册是否为.wxapi.WXPayEntryActivity ，确定无误后检查后台返回的参数是否有误
至此如果都正确，可以开始着手检查在后台里的参数设置是否正确
这里需要注意的是应用签名和应用包名，因为出问题的包不是由我打包的，我怀疑问题在于应用签名对不上，最后发现果然如此。打包的同事使用了另一个keystore文件进行打包，导致应用签名与后台填写的不一致，于是重新生成了签名更新后台设置，问题解决。
至于为什么部分机型可以正常支付，而部分机型无法调起，我参照有些coder遇到的问题“微信支付只能成功调起一次”
因为成功支付的机型为公司测试机，而不成功的机型是用户机，猜测因为公司测试机里曾经调试过微信支付，有正确的包名和签名的缓存，微信在调起时直接读取缓存值，验证正确后直接调起，而当缓存值出错时微信才会再次去读取新的包名和签名重新验证，因此出现了部分机型可支付的问题。也因为这个原因， 修改完签名后再次调试，第一次返回的还是-1，但再次点击就可以成功调起，此后也没有再返回-1。 个人猜测，如有错误欢迎指出讨论。
微信支付的坑实在是太多了，还有OC编写的iOS的IAP也有很多藏起来的坑，一直想把Unity内调用Java集成的微信、支付宝支付，使用OC集成的iOS内购详细过程写上来，但是一直犯懒。。这段时间一定要写好，给自己做个记录，也给大家作为一个参考。
② 单个APP接入多个微信支付宝支付的一种解决方案
背景
最近在对接微信支付宝支付的时候出现了一个需求，由于我们公司在不同的地区有分公司，为了实现财务对账方便，不同公司的客户需要打款到相应的公司的账户，也就是要实现接口分账，一听到这个需求，我一脸懵逼，之前做商城的时候，一个APP的收款不管是微信还是支付宝，都是只打到一个账户里面去，现在需要实现不管对于微信支付还是支付宝支付都需要有多个支付账户，实现接口分账，当时总经理提出这个需求，Android跟ios历史性地异口同声地说，这个做不到，并且从技术的角度在那儿跟总经理弹了一会儿琴，毕竟还是太年轻了，总经理说，这个肯定是可以实现的，因为在他眼里，没有什么是实现不了的，然后我们就回去搬砖了，然后思考这个问题的解决方案。
分析问题
需要实现的技术点
用户支付的时候，根据用户的uid，来把钱达到相应的账户里面去，判断身份很简单，问题主要在于如何使得一个APP接入多个微信或者支付宝账户，下面来逐个分析一下微信跟支付宝的接入方式
微信
对接过微信支付的应该很熟悉上面的这些东西，首先你得去微信开放平台注册一个账号，一年300块钱，然后再在这个账号里面开通微信支付功能，所以一开始我们尝试的就是不停地去骚扰微信客服，问问能不能通过一个微信支付账号进行接口分账，每次那边的回答都是不可以，然后又问一个APP能不能申请多个微信支付账号，那边回答也说是不可以，卧槽，基本上到这个份上，我们已经是放弃了，因为如果一个APP不能申请多个微信支付账号，那么微信基本上是做不了接口分账了，当时IOS了解到的微信支付情况是这个样子的，下面看看支付宝的过程。
支付宝
支付接入的时候其实也比较郁闷，苦逼之处在于支付宝以前是支持接口分账的，也就是只需要注册一个支付宝主账户，然后在注册几个子账户就可以进行接口分账，只是我们的APP生不逢时，支付宝关闭了这个服务，而且那边的客服也是说一个APP只能注册一个支付宝账户
发现希望
基本上到这里，我们已经打算放弃了，因为毕竟跟我们最初的设想是一样的，但是还是有点不甘心，因为在跟支付宝的技术客服，注意是技术客服，不是普通的人工客服，当时跟他说了一下我们的使用场景，他说可以通过注册多个支付宝账号，其实这一点跟我之前的设想是一样的，因为Android在介入支付宝的时候不需要应用的签名，可以通过服务端动态下发签名，从而调起支付宝支付，我突然间好像明白了什么，因为之前的思路走不通的原因在于总是想通过一个APP来注册多个支付宝账号，没有想到用多个支付宝账户来实线曲线救国。
支付宝实现接口分账
注册支付宝账户
支付宝应用名称
支付宝应用信息
支付宝支付跟微信支付最大的区别在于Android客户端的接入，需要应用的签名，所以如果用两个APP注册的话势必会导致签名不一致，支付宝的注册只需要填写一个应用名称就好了，注意应用名称不能一样，否则会失败。
基本上到这里，支付宝实现接口分账的链路打通了，测试也完全通过，吼吼
微信实现接口分账
对于微信来说,一个APP对应唯一的APPID,注册信息大致如下：
微信支付应用名称
微信支付应用信息
受到支付宝的启发，能不能注册在微信开放平台注册两个账号，然后申请两个微信支付账号，只不过这两个账号除了名称不一样以外，其余地全都一样，不过虽然这么想还是有点虚，因为IOS在跟客服沟通的时候客服只是说同一个APP只能申请一个微信支付账号，但是我们反问客服微信的判断规则是什么的时候，微信那边却说不知道，如果是名称，那么就能够通过审核，如果是应用的包名或者bundleid那基本上微信接入原生的APP支付彻底走不通了。
当时是分了两步走，总经理说微信支付必须得接入，万一不行只能接入微信H5支付，因为H5的话就可以实现动态下发了。所以当时H5支付跟原生支付的账号同时在申请，服务端那边也是在做两手的准备，比较苦逼。最后万幸的是，微信是通过应用名称来判断APP的唯一性，很幸运，可以完全放弃H5支付了，微信支付接口分账也打通了。
小结
这篇文章没有涉及到任何技术，但是这次实现一个APP实现多个接口分账，确实让我感触很多，很多时候，我们在做一件事情的时候，会调用我们以往的经验，有好也有坏，之前做的支付都是单个微信支付宝，按照之前的经验，在尝试之前就做出了错误的判断，很多时候还是需要敢于拆掉思维里的墙，去尝试一些新东西，包括在实现一些功能的时候，要勇于尝试一些新的思维，新的解决方式，尤其是在用已有的知识实现不了或者实现起来比较痛苦的时候，毕竟改变是痛苦的，不改变只会更加痛苦。
③ 汇聚，杉德，微信原生支付，支付宝成功/失败回调记录
1、清除微信缓存，清除微信存储空间，重新登录微信
2、如果有更换包名，有更换签名文件信息，清除编译器缓存clean Project 、Invalidate Caches/Restart，并确保包名，签名没错
额外补充说一句，无论是否支付成功、失败，最好都是轮训请求后端进行一个验证操作。所以对结果是怎么样的，我们都可以不用关心
杉德小程序支付，汇聚小程序支付，当你取消支付，点击小程序右边的关闭圆圈的时候，WXEntryActivity 界面会自动消失，但不会走finish，onDestroy。所以要做检测是否真的成功或者是否支付完成，需要自行在吊起微信支付页面或者待确认界面进行轮训请求后台，确定是否支付成功。
杉德小程序支付、汇聚小程序支付点击返回商户会走onResp，也会走finish，onDestroy
支付宝支付，不像微信一样，当你取消支付，支付成功，支付宝会帮你回调handleMessage，所以你需要在这里处理你自己的逻辑
1、原生微信APP支付，只能回调WXPayEntryActivity
2、汇聚、杉德小程序支付只能回调WXEntryActivity ，点击返回商户会走onResp，也会走正常的完整生命周期。如果点击的是小程序的圆圈关闭是不会走onResp，也就没有了WXEntryActivity 完结的生命周期，当你切回原来自己APP界面的时候，是直接在你发起小程序支付的界面了。
④ 支付宝支付和包名有关系吗
支付宝支付和和包支付是不同的两个支付平台，他们属于不同的两个公司的，完全是不一样的支付软件
⑤ 如何让一个应用程序一直在后台运行
1、保活手段
1 业界保活手段：黑色保活，灰色保活，白色保活
2 黑色保活：
1 不同的APP进程，用广播相互唤醒，包括利用系统广播进行唤醒
2 常见手段：
1 开机，网络切换，拍照，拍视频等利用系统广播唤醒APP
此场景Google已经意识到，在Android N 取消了 拍照，视频，网络切换的广播
2 接入第三方的SDK也会唤醒相应的APP进程
3 假如你手机里装了支付宝，淘宝，UC等阿里系的APP，那么你打开任何一个，都有可能唤醒其他的阿里系的APP
3 白色保活：
就是调用系统的API启动一个前台Service进程，这样会在通知栏生成一个Notification，用户知道哪些进程正在运行
4 灰色保活
1 保活领域应用最为广泛，利用系统的漏洞来启动一个前台的Service进程，与“白色保活”不同的是，它不会在通知栏生成一个Notification,用户无法察觉，但是优先级要高于普通的后台进程。
2 实现思路
思路一：当API<18，启动前台的Service直接传入new Notification()；
思路二：当API >= 18,同时启动两个id相同的前台Service，然后再将后启动的Service做stop处理
代码这样写：
[java]view plain
importandroid.app.Notification;
importandroid.app.Service;
importandroid.content.Intent;
importandroid.os.Build;
importandroid.os.IBinder;
/**
*APP灰色保活
*Createdbyfflinon2016/4/23.
*/
{
privatefinalstaticintGRAY_SERVICE_ID=1001;
@Override
publicIBinderonBind(Intentintent){
returnnull;
}
@Override
publicintonStartCommand(Intentintent,intflags,intstartId){
//API<18,此方法能有效地隐藏notification的图标
if(Build.VERSION.SDK_INT<18){
startForeground(GRAY_SERVICE_ID,newNotification());
}else{
Intentintent1=newIntent(this,GrayInnerService.class);
startService(intent1);
startForeground(GRAY_SERVICE_ID,newNotification());
}
returnsuper.onStartCommand(intent,flags,startId);
}
//给API>=18的平台上做灰色保护手段
{
@Override
publicIBinderonBind(Intentintent){
returnnull;
}
@Override
publicintonStartCommand(Intentintent,intflags,intstartId){
startForeground(GRAY_SERVICE_ID,newNotification());
stopForeground(true);
stopSelf();
returnsuper.onStartCommand(intent,flags,startId);
}
}
}
3 检验方法：
首先看系统通知栏有没有Notification，如果没有，就进入手机adb shell模式，输入命令mpsys activity services PackageName
打印出指定包名的所有进程中的service信息，看下有没有isForground=true的信息，如果有，就说明了该APP使用了灰色保活
4 使用灰色保活手段并不意味着你的应用就能永生不死，只能说提高了进程的优先级，如果应用占用了很大的内存，还是会被回收的
2、进一步理解保活
1 进程回收机制
系统出于体验和性能上的考虑，APP在退出后台时系统并不会真正的kill掉这个进程，而是将其缓存起来，打开的应用越多，后台缓存的进程也就越多。在系统内存不足的情况下，系统开始根据自身的一套进程回收机制来判断要回收掉哪些进程，这套杀死进程回收内存的机制叫 Low Memory Killer，它是基于Linux内核的OOM killer机制诞生的，该机制为每个系统分配了一个值，叫做oom_adj，代表了进程的优先级，oom_adj越大，代表优先级越低，越容易被回收，普通APP进程的oom_adj >=0,系统的可能会小于0.
2 查看oom_adj的值，需要用到两个shell命令
ps | grep 包名
$cat /proc/进程id/oom_adj
3 结果发现，APP推到后台，UI进程的值降低最为明显，因为它占用的内存资源最多，因此，为了避免后台UI进程被杀，需要尽可能的释放一些不用的图片，音频资源