相关问题：
最近很多讨论应用内支付（IAP）的问题，但是好像很少有人看了这个 App Store Review Guidelines
（）之后再来看这到底是个什么问题。 引起争议的是这几条：11.2Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected11.3Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected11.4Apps that use IAP to purchase credits or other currencies must consume those credits within the application11.2 说在 App 内使用非 IAP 的第三方支付购买内容或服务、解锁功能是不允许的；11.3 说用 IAP 购买实物或者应用外的货物或服务是不允许的；11.3 说通过 IAP 购买的货币必须只在 App 内使用。我们抠一下字眼就知道问题在哪儿，11.2 告诉你在 iOS App 内部不要使用第三方支付购买 App 内使用的内容，11.3 告诉你不要使用 IAP 购买在 App 外使用的货品，而这两种商品是可能重合的，即在 iOS 内和外都能使用的内容或服务，这两条审核规则却没有明确重合部分适用哪条规则。所以就我的理解，对于跨平台的电子阅读器应用，只要你在 iOS App 内是通过 IAP 而不是第三方支付来购买电子书，也不用 IAP 来购买不能在 iOS App 内使用却可以在 iOS 以外的平台使用的电子书，在 iOS App 内通过 IAP 、在其他平台上通过第三方支付购买电子书然后双向同步，那就是不违反审核规则的。实际上是个解释权的问题，如果不同的苹果员工对不同的 Apps 把这两条解释出不同的意思，审核的结果就可能不一样。我们之前就这个问题专门询问过 Apple 的客服，他的回答是需要使用跨平台支付和同步功能的应用可以向苹果提出申请，如果申请通过了就可以了，虽然我从来没在苹果网站上找到过这个申请的入口在哪儿。
这是一个好问题，我来随便说说自己的经验。&br&当初在盛大负责做移动支付产品的时候，我们也面临过一样的问题。理论上，在App Store体系里，所有应用的生死大权都归苹果掌控，所以上架不带苹果支付的应用而使用第三方支付是有很大风险的（对第三方支付本身应用也一样有被下架的风险）。&br&&br&之前我们认为，苹果想通过AppStore进行封闭管理，所有涉及支付环节都要抽成，后来发现也不尽然如是。否则淘宝、京东等电商企业将直接被逼得走投无路，要知道，30%的支付渠道成本，即便在国外都是不可想象的，更何况费率平均维持在千分之几万分之几的中国。&br&&br&另外，基于国内网银的现状，我们当时为非WIN非IE浏览器的平台感到担忧——ActiveX控件害人不浅，几乎所有网银都要IE支持……蛋疼。当然，后来支付宝快捷支付让人眼前一亮，这是题外话，暂且不提。&br&&br&随着快捷支付的兴起，我们发现：电商网站也可以开始在IOS平台上不通过苹果支付进行正常支付行为了（拍手）。&br&&br&在&a href=&/question/& class=&internal&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/question/2066&/span&&span class=&invisible&&5419&/span&&span class=&ellipsis&&&/span&&/a& 问题中，Arays提到苹果对使用第三方支付的应用是否违规的判断依据应该”是买的东西是不是需要安装在Apple的系统中使用“。我想大概逻辑如是，否则很多电商应用都要下架了。&br&&br&回到正题，像电子阅读器这种应用，正是卡在了这个限制范围内。&br&我给几个思路（合规不合规，有没有实践成功的都有）：&br&1.用目前比较流行的策略，其他平台购买的书可以同步到客户账户下，但是不在AppStore上开发支付功能。好处是不会有下架的风险（不要引导客户去其他平台付款，不然一样被干掉），但会流失一部分销售机会。&br&2.由1衍生的策略，建立虚拟货币体系，客户通过PC或者Android购买虚拟货币，在IOS平台上进行消费。类似的策略还有预付卡（点卡）等。好处是用户在IOS体系里内进行消费，消费的是你的虚拟货币，并不涉及人民币结算，苹果干预起来难度很大。坏处是，这玩意打的是擦边球，可能会被苹果干掉；同时你要有足够的内容和应用去支撑你的虚拟货币账户，例如腾讯Q币、盛大点券等，具有这样的能力。&br&3.放弃不越狱的伙计，收费只针对越狱版本的应用。风险和好处一目了然。&br&4.还没试过，请前辈指点。上传苹果应用审核的时候，付费功能模块用webkit做，显示“更多更新，尽请期待”之类的……一旦上线，服务器端改页面，放出收费页面。这样子是彻底违了苹果的规，不知道苹果会不会有事后检查。另外，应用下载量和热度上去后，难不保会被人盯上……所以一直就没敢干这个事情。&br&&br&感谢&a class=&member_mention& data-hash=&b6fb0b7b9c680& href=&///people/b6fb0b7b9c680& data-hovercard=&p$b$b6fb0b7b9c680&&@黄继新&/a&在评论中给出了唐茶的案例：&br&自己的账户系统和 Apple ID 绑定，比如唐茶，在网页版支付过了，在 App 里就显示已经购买完成了。如果在 App 里通过 IAP 购买了，在网页版也显示购买完成了。 &br&&br&&br&抛砖引玉，大家随便讨论。
这是一个好问题，我来随便说说自己的经验。 当初在盛大负责做移动支付产品的时候，我们也面临过一样的问题。理论上，在App Store体系里，所有应用的生死大权都归苹果掌控，所以上架不带苹果支付的应用而使用第三方支付是有很大风险的（对第三方支付本身应用…
App 内创造一种虚拟货币，各平台用各平台可行的支付方式购买虚拟货币，然后该虚拟货币在 App 内通用，可用于支付不同平台 App 内的书籍以及其他内购项目的费用。
App 内创造一种虚拟货币，各平台用各平台可行的支付方式购买虚拟货币，然后该虚拟货币在 App 内通用，可用于支付不同平台 App 内的书籍以及其他内购项目的费用。
已有帐号？
无法登录？
社交帐号登录
云计算 互联网 游戏 工程师在iOS开发中如果涉及到虚拟物品的购买，就需要使用IAP服务，我们今天来看看如何实现。
在实现代码之前我们先做一些准备工作，一步步来看。
1、IAP流程
IAP流程分为两种，一种是直接使用Apple的服务器进行购买和验证，另一种就是自己假设服务器进行验证。由于国内网络连接Apple服务器验证非常慢，而且也为了防止黑客伪造购买凭证，通用做法是自己架设服务器进行验证。
下面我们通过图来看看两种方式的差别：
1.1、使用Apple服务器
1.2、自己架设服务器
简单说下第二中情况的流程：
用户进入购买虚拟物品页面，App从后台服务器获取产品列表然后显示给用户
用户点击购买购买某一个虚拟物品，APP就发送该虚拟物品的productionIdentifier到Apple服务器
Apple服务器根据APP发送过来的productionIdentifier返回相应的物品的信息（描述，价格等）
用户点击确认键购买该物品，购买请求发送到Apple服务器
Apple服务器完成购买后，返回用户一个完成购买的凭证
APP发送这个凭证到后台服务器验证
后台服务器把这个凭证发送到Apple验证，Apple返回一个字段给后台服务器表明该凭证是否有效
后台服务器把验证结果在发送到APP，APP根据验证结果做相应的处理
2、iTunes Connet操作
搞清楚了自己架设服务器是如何完成IAP购买的流程了之后，我们下一步就是登录到创建应用和指定虚拟物品价格表
2.1、创建自己的App
如下图所示，我们需要创建一个自己的APP，要注意的是这里的Bundle ID一定要跟你的项目中的info.plist中的Bundle ID保证一致。也就是图中红框部分。
2.2、创建虚拟物品价格表
2.2.1、虚拟物品分为如下几种：
消耗品（Consumable products）：比如游戏内金币等。
不可消耗品（Non-consumable products）：简单来说就是一次购买，终身可用（用户可随时从App Store restore）。
自动更新订阅品（Auto-renewable subscriptions）：和不可消耗品的不同点是有失效时间。比如一整年的付费周刊。在这种模式下，开发者定期投递内容，用户在订阅期内随时可以访问这些内容。订阅快要过期时，系统将自动更新订阅（如果用户同意）。
非自动更新订阅品（Non-renewable subscriptions）：一般使用场景是从用户从IAP购买后，购买信息存放在自己的开发者服务器上。失效日期/可用是由开发者服务器自行控制的，而非由App Store控制，这一点与自动更新订阅品有差异。
免费订阅品（Free subscriptions）：在Newsstand中放置免费订阅的一种方式。免费订阅永不过期。只能用于Newsstand-enabled apps。
类型2、3、5都是以Apple ID为粒度的。比如小张有三个iPad，有一个Apple ID购买了不可消耗品，则三个iPad上都可以使用。
类型1、4一般来说则是现买现用。如果开发者自己想做更多控制，一般选4
2.2.2、创建成功后如下所示：
其中产品id是字母或者数字，或者两者的组合，用于唯一表示该虚拟物品，app也是通过请求产品id来从apple服务器获取虚拟物品信息的。
2.3、设置税务和银行卡信息
这一步必须设置，不然是无法从apple获取虚拟产品信息。
设置成功后如下所示：
更多关于iTunes Connet的操作请才看这篇博文
3、iOS端具体代码实现
完成了上面的准备工作，我们就可以开始着手IAP的代码实现了。
我们假设你已经完成了从后台服务器获取虚拟物品列表这一步操作了，这一步后台服务器还会返回每个虚拟物品所对应的productionIdentifier，假设你也获取到了，并保存在属性self.productIdent中。
需要在工程中引入 storekit.framework。
我们来看看后续如何实现IAP
3.1、确认用户是否允许IAP
//移除监听
-(void)dealloc
[[SKPaymentQueue defaultQueue] removeTransactionObserver:self];
//添加监听
- (void)viewDidLoad{
[super viewDidLoad];
[self.tableView.mj_header beginRefreshing];
[[SKPaymentQueue defaultQueue] addTransactionObserver:self];
- (void)buyProdution:(UIButton *)sender{
if ([SKPaymentQueue canMakePayments]) {
[self getProductInfo:self.productIdent];
[self showMessage:@&用户禁止应用内付费购买&];
3.2、发起购买操作
如果用户允许IAP，那么就可以发起购买操作了
//从Apple查询用户点击购买的产品的信息
- (void)getProductInfo:(NSString *)productIdentifier {
NSArray *product = [[NSArray alloc] initWithObjects:productIdentifier, nil];
NSSet *set = [NSSet setWithArray:product];
SKProductsRequest * request = [[SKProductsRequest alloc] initWithProductIdentifiers:set];
request.delegate =
[request start];
[self showMessageManualHide:@&正在购买，请稍后&];
// 查询成功后的回调
- (void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response {
[self hideHUD];
NSArray *myProduct = response.
if (myProduct.count == 0) {
[self showMessage:@&无法获取产品信息，请重试&];
SKPayment * payment = [SKPayment paymentWithProduct:myProduct[0]];
[[SKPaymentQueue defaultQueue] addPayment:payment];
//查询失败后的回调
- (void)request:(SKRequest *)request didFailWithError:(NSError *)error {
[self hideHUD];
[self showMessage:[error localizedDescription]];
3.3、购买操作后的回调
//购买操作后的回调
- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions {
[self hideHUD];
for (SKPaymentTransaction *transaction in transactions)
switch (transaction.transactionState)
case SKPaymentTransactionStatePurchased://交易完成
self.receipt = [GTMBase64 stringByEncodingData:[NSData dataWithContentsOfURL:[[NSBundle mainBundle] appStoreReceiptURL]]];
[self checkReceiptIsValid];//把self.receipt发送到服务器验证是否有效
[self completeTransaction:transaction];
case SKPaymentTransactionStateFailed://交易失败
[self failedTransaction:transaction];
case SKPaymentTransactionStateRestored://已经购买过该商品
[self showMessage:@&恢复购买成功&];
[self restoreTransaction:transaction];
case SKPaymentTransactionStatePurchasing://商品添加进列表
[self showMessage:@&正在请求付费信息，请稍后&];
- (void)completeTransaction:(SKPaymentTransaction *)transaction {
[[SKPaymentQueue defaultQueue] finishTransaction: transaction];
- (void)failedTransaction:(SKPaymentTransaction *)transaction {
if(transaction.error.code != SKErrorPaymentCancelled) {
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:nil message:@&购买失败，请重试&delegate:self cancelButtonTitle:@&取消& otherButtonTitles:@&重试&, nil];
[alertView show];
[self showMessage:@&用户取消交易&];
[[SKPaymentQueue defaultQueue] finishTransaction: transaction];
- (void)restoreTransaction:(SKPaymentTransaction *)transaction {
[[SKPaymentQueue defaultQueue] finishTransaction: transaction];
3.4、向服务器端验证购买凭证的有效性
在这一步我们需要向服务器验证Apple服务器返回的购买凭证的有效性，然后把验证结果通知用户
- (void)checkReceiptIsValid{
AFHTTPSessionManager manager]GET:@&后台服务器地址&
parameters::@&发送的参数（必须包括购买凭证）&
success:^(NSURLSessionDataTask * _Nonnull task, id
_Nonnull responseObject) {
if(凭证有效){
你要做的事
}else{//凭证无效
你要做的事
} failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:nil message:@&购买失败，请重试&delegate:self cancelButtonTitle:@&取消& otherButtonTitles:@&重试&, nil];
[alertView show];
3.5、发送凭证失败的处理
如果出现网络问题，导致无法验证。我们需要持久化保存购买凭证，在用户下次启动APP的时候在后台向服务器再一次发起验证，直到成功然后移除该凭证。
保证如下define可在全局访问：
#define AppStoreInfoLocalFilePath [NSString stringWithFormat:@&%@/%@/&, [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject],@&EACEF35FE363A75A&]
-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
if (buttonIndex == 0)
[self saveReceipt];
[self checkReceiptIsValid];
//持久化存储用户购买凭证(这里最好还要存储当前日期，用户id等信息，用于区分不同的凭证)
-(void)saveReceipt{
NSString *fileName = [AppUtils getUUIDString];
NSString *savedPath = [NSString stringWithFormat:@&%@%@.plist&, AppStoreInfoLocalFilePath, fileName];
NSDictionary *dic =[ NSDictionary dictionaryWithObjectsAndKeys:
self.receipt,
Request_transactionReceipt,
self.userId
[dic writeToFile:savedPath atomically:YES];
3.6、APP启动后再次发送持久化存储的购买凭证到后台服务器
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{
NSFileManager *fileManager = [NSFileManager defaultManager];
//从服务器验证receipt失败之后，在程序再次启动的时候，使用保存的receipt再次到服务器验证
if (![fileManager fileExistsAtPath:AppStoreInfoLocalFilePath]) {//如果在改路下不存在文件，说明就没有保存验证失败后的购买凭证，也就是说发送凭证成功。
[fileManager createDirectoryAtPath:AppStoreInfoLocalFilePath//创建目录
withIntermediateDirectories:YES
attributes:nil
error:nil];
else//存在购买凭证，说明发送凭证失败，再次发起验证
[self sendFailedIapFiles];
//验证receipt失败,App启动后再次验证
- (void)sendFailedIapFiles{
NSFileManager *fileManager = [NSFileManager defaultManager];
NSError *error =
//搜索该目录下的所有文件和目录
NSArray *cacheFileNameArray = [fileManager contentsOfDirectoryAtPath:AppStoreInfoLocalFilePath error:&error];
if (error == nil)
for (NSString *name in cacheFileNameArray)
if ([name hasSuffix:@&.plist&])//如果有plist后缀的文件，说明就是存储的购买凭证
NSString *filePath = [NSString stringWithFormat:@&%@/%@&, AppStoreInfoLocalFilePath, name];
[self sendAppStoreRequestBuyPlist:filePath];
DebugLog(@&AppStoreInfoLocalFilePath error:%@&, [error domain]);
-(void)sendAppStoreRequestBuyPlist:(NSString *)plistPath
NSString *path = [NSString stringWithFormat:@&%@%@&, AppStoreInfoLocalFilePath, plistPath];
NSDictionary *dic = [NSDictionary dictionaryWithContentsOfFile:path];
//这里的参数请根据自己公司后台服务器接口定制，但是必须发送的是持久化保存购买凭证
NSMutableDictionary *params = [NSMutableDictionary dictionaryWithObjectsAndKeys:
[dic objectForKey:USERID],
[dic objectForKey:DATE],
[dic objectForKey:Request_transactionReceipt],
Request_transactionReceipt,
AFHTTPSessionManager manager]GET:@&后台服务器地址&
parameters:params
success:^(NSURLSessionDataTask * _Nonnull task, id
_Nonnull responseObject) {
if(凭证有效){
[self removeReceipt]
}else{//凭证无效
你要做的事
} failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
//验证成功就从plist中移除凭证
-(void)removeReceipt{
[AppUtils removeIapFailedPath:AppStoreInfoLocalFilePath];
//AppUtils类方法，验证成功，移除存储的receipt
+ (void)removeIapFailedPath:(NSString *)plistPath{
NSString *path = [NSString stringWithFormat:@&%@/%@&, AppStoreInfoLocalFilePath, plistPath];
NSFileManager *fileManager = [NSFileManager defaultManager];
if ([fileManager fileExistsAtPath:AppStoreInfoLocalFilePath])
[fileManager removeItemAtPath:AppStoreInfoLocalFilePath error:nil];
if ([fileManager fileExistsAtPath:path])
[fileManager removeItemAtPath:path error:nil];
至此，整个流程结束，有任何疑问欢迎大家留言
更多技术文章，欢迎大家访问我的技术博客：
阅读(...) 评论()iOS（111）
我们在今年春节后上线了新的在线智能题库：猿题库。猿题库现在推出了公务员考试行测和申论2个产品，均包括web, iOS和Android三个平台。这次我们尝试做一个收费的产品，所以在iOS端集成了应用内支付（IAP）功能。在开发过程中和上线后，我们遇到了IAP中的一些坑，在此分享给各位。
IAP 审核相关的坑
IAP开发的详细步骤我写在中了。在此主要介绍审核时遇到的问题。
IAP类型错误
由于我们是按月付费的产品，所以在设置IAP类型时，我没有经验，只是简单设置成了可重复消费(Consumable)的IAP项目。但是我不知道，苹果对于这种按时间收费的产品，应该使用不可更新的定阅（Non-Renewing Subscription）类型。这个类型设置错误造成了我们app的一次审核被拒。
IAP验证逻辑
由于苹果在iOS5.0以下有IAP的bug，使得攻击者可以伪造支付成功的凭证。而iOS6.0的系统在越狱后同样可以伪造凭证，所以我们对于应用内支付，增加了服务器端的验证。 服务器端会将支付凭证发给苹果的服务器进行二次验证，以保证凭证是真实有效的。
在我们公司的测试服务器中，我们会连接苹果的测试服务器（https://sandbox./verifyReceipt）验证。
在我们部署在线上的正式服务器中，我们会连接苹果的正式服务器（https://buy./verifyReceipt ）验证。
我们提交给苹果审核的是正式版，我们以为苹果审核时，我们应该连接苹果的线上验证服务器来验证购买凭证。结果我理解错了，苹果在审核App时，只会在sandbox环境购买，其产生的购买凭证，也只能连接苹果的测试验证服务器。但是审核的app又是连接的我们的线上服务器。所以我们这边的服务器无法验证通过IAP购买，造成我们app的又一次审核被拒。
解决方法是判断苹果正式验证服务器的返回code，如果是21007，则再一次连接测试服务器进行验证即可。苹果的上有对返回的code的详细说明。
IAP上线后的遇到的情况
我们在服务器端增加了验证IAP是否有效的逻辑。在产品上线后，如我们所料，我们收到了大量的欺骗性购买，这些都被我们的服务器识别出来了，但是我们也遇到了以下这次没有想到的情况:
1、由于国内越狱用户的比例比较大(大概为50%),所以虽然我们服务器会验证购买凭证，但是每天有超过50%以上的凭证都是伪造的。同时由于苹果的验证服务器在美国，凭证验证请求响应的时间比较慢，大量的伪造凭证发给苹果服务器，不知道会不会被苹果认为我们是在恶意进行DDOS。至少我们发现有些时候，验证请求会超时。
2、由于国内有许多小白用户，他们的手机从购买时就被渠道商帮忙越狱过了并且安装了IAP free插件。所以对于这类用户，他们即使想付费购买，由于系统原有的IAP支付功能已经被破坏，所以他们是无法正常付费的。麻烦的是，他们会以为这是我们的app的问题，转而给我们的客服打电话投诉。这让我们非常郁闷。
3、苹果的验证服务器有时候会出问题，我们发现本来约定好返回的JSON数据在有几次返回的居然是一个XML格式的文件。造成我们将正常的付费IAP凭证验证失败。所以，在服务器记录下所有的验证凭证非常有必要，一来可以防止黑客多次提交同一个成功凭证的重放攻击，二来在需要时可以手工进行再验证。
越狱手机可能被黑客窃取购买凭证！！
我们发现有一部分用户反馈说已经收到苹果的扣费账单，但是我们从服务器的验证记录看，他上传的凭证却是虚假的。由于这些用户不太多，我们一开始以为是用户在恶意欺骗我们，后来我们让他将苹果的付费账单邮件转发给我们，以及将itunes的购买记录截图转发给我们，我们越来越怀疑这里面有一个黑色的产业链。越狱手机的正常购买凭证可能被黑客的恶意程序截获，具体的攻击方式我们讨论了一下，其实就是被，详细的过程如下:
越狱手机的在被破解后，可能从一些破解渠道安装了黑客的恶意程序。黑客将越狱手机所有https请求都经过他的中间服务器。当有支付请求时，黑客先将请求发给苹果服务器，待苹果将成功的凭证返回后，黑客将这个凭证替换成假的凭证，完全支付凭证的偷取。
或许有人会问，这个凭证拿来有什么用呢?很简单 ，因为苹果为了保护用户的隐私，支付凭证中并不包含任何用户的apple id信息，所以我们的app和服务器无法知道这个凭证是谁买的，而只能知道这个凭证是真的还是假的。于是黑客就可以用这个凭证，在另外的账号中通知我们完成了购买，而发来的验证凭证又是真实的，所以我们的服务器就会误认为是黑客的账号完成了购买，继而把会员期算在黑客的账号上。
再举一个简单的例子，你拿500块钱买了顺风优选的500元购物券，由于这个购物券是不记名的，所以顺风优选无法知道是谁买的。如果这个购物券在发放过程中被人掉包，那么偷购物券的人就可以拿这个偷来的真购物券来购物，而顺风优选的卡因为是不记名的，所以也无法查证这件事情。在这个例子中，购物券的不记名和苹果的支付凭证无账号信息是同一个道理。
鉴于以上情况，考虑到越狱手机不但不能成功支付，还会有安全问题，所以我们在新版中取消了越狱手机中的IAP支付功能。
所以，请大家还是不要越狱自己的手机，iphone手机越狱后风险相当大。实在不值得为了免费玩几个游戏就丢掉安全性。
中间人攻击的演示
iOS独立开发者在他的博客文章中演示了如何使用中间人攻击来修改Game Center游戏数据。王轲还把我的例子白话翻译了一下（可见我还是说得太绕了，囧）：
坏人在购买过程中插了一腿，换走了用户的无记名发票（购物小票形象些），然后手持无记名小票伪装成真实顾客或者转手出售获利。
关于越狱与盗版
不少细心的同学评论纠正我，指出越狱并不等同于使用盗版。确实，如果说严格的定义，越狱只是让iPhone获得root权限，进而可以做任何事情。如果越狱的同学在越狱后不安装IAP free插件，不使用app sync插件，不使用任何国内的和非bigboss的cydia源，不使用任何盗版软件，所有应用都是从app store官方网站上下载的话，被黑客攻击的可能性会降低一些。
即使这样，由于手机已经被root了，苹果的沙盒安全机制失效，所以风险还是很大的。
关于越狱用户的比例
有同学提出我文章中写的越狱手机比例太高了，想询问数据来源。这个比例主要来自我们自己的app的统计信息，以及结合国内的统计工具友盟的，去年底国内的越狱比例是42%。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：46142次
积分：1950
积分：1950
排名：第14582名
原创：144篇
转载：78篇
评论：14条[][][][][][][][][][][][]
最新文章热门文章
[][][][][][][][][][][][]
[][][][][][][][][][][][]
01-2101-2010-3010-29
09-0608-0508-0307-26
03-1201-2501-2001-12
今日推荐有奖活动
上海云螺研发、龙图游戏发行的手游《螺旋境界线》今日全平台公测开启
《阴阳师》在App Store免费榜和畅销排行榜上名次飙升，一周收获数万好评
爆笑手游扛鼎之作《大大大乱斗》邀你畅玩体验 iPad mini4等豪奖等你赢
《青云志》电视剧同名大型3DMMORPG手游，畅玩游戏晒截图拿京东卡
日期名称状态下载号
09-23内测09-23封测09-23公测09-23公测09-23公测09-26内测09-27公测09-27公测09-30停运10-15公测11-01公测
12345678910
日期名称号
09-2009-2009-2009-2009-2009-2009-2009-2009-20
京公网安备 86 京ICP证140355号 京网文【-109号