苹果和国产软件杠上了，就连王者荣耀也难避免
苹果和国产软件杠上了，就连王者荣耀也难避免
西瓜谈谈一
或许是苹果已经对只有“iPhone爆料”才能登上科技话题榜这一事实感到了厌倦。因此今年，苹果拿出了全新的“杀手锏”，通过一系列对国产软件的新举措，吸引了大众的眼球，又一次成功登顶科技话题榜。但是，由于苹果这次操作很迷，加上各路人马的推波助澜，使得苹果的新政，不出意外遭遇了大量差评。然而在批评声音的背后，也有消费者跳出来为苹果喊冤。就这样，双方你来我往，斗得好不热闹。尽管小编也想和大家一样吃瓜看戏，但我们有必要为大家拨开迷雾，探索苹果新政的背后，究竟哪些是真实，哪些又是谎言。关注点一：强制抽成软件收入的30%如果你有关注科技新闻，就一定知道不久前苹果与微信之间的“相爱相杀”。事情源于微信官方关闭了iOS平台微信公众号的打赏功能。苹果的新规要求抽成微信打赏的30%作为“平台费”，但微信官方认为这并不符合规定，一番交涉后，微信官方无奈关闭了iOS平台的打赏功能。微信关闭iOS平台打赏功能的公告但事情并没有就此结束，微信关闭打赏功能后，如今日头条，知乎以及新浪微博等纷纷发出公告，表示根据苹果的要求，将更改原有的付费方式，统一通过苹果官方渠道收费（交30%的平台税）。一时间，苹果被推上了风口浪尖。事实上，作为平台提供商，苹果收取抽成并无不妥，毕竟平台的维护等都需要费用。但问题在于，苹果给出的开发者条款表述的较为模糊，并且掌握着最终解释权，这很难让软件厂商信服。根据苹果的开发者条款，用户在应用内购买虚拟物品时，将会收取30%的平台税。好比我们在应用内购买游戏，购买音乐，购买游戏金币，充值会员等等，这些都是虚拟物品，因此苹果收取30%的费用无可厚非。iOS平台应用内购但是，对于“打赏”这件事，显然是不一样的。打赏，应当看做是一种主观行为，是用户在消费了免费的内容后，愿意向内容提供者赠与一笔费用以表示感谢。这里，内容提供商提供的是免费内容，是无需付费的内容，同付费购买是搭不上任何关系。然而，苹果一刀切的将“打赏”也认为是内容购买，又拿不出明确的条款，显然是不对的。关于内购的开发者说明对普通用户来说，如果要付出更多的资金（用户分担30%的平台税），或要进行更多的无意义操作（打赏要识别二维码后转账才行），才能支持喜欢的内容提供商。这无疑会打击普通用户的积极性。对于内容提供商，由于在iOS平台获得的收益变少，一定会打击到创作的积极性。无论怎么看，苹果这一步，都是伤人又伤己。如果苹果能够认真审视条款，给出合理又清晰的规则，具体问题具体分析，才能避免争议，使平台健康的发展。关注点二：强制下架“热更新”应用或许苹果强制收取30%平台税这件事对普通用户的影响并没有那么大，但下架“热更新”应用这件事，将会直接影响很多用户的体验。小编先为大家解释一下什么是“热更新”。热更新就是指在服务器不关闭的情况下，用户打开应用就能安装更新。好比我们运行《王者荣耀》时，往往会在开始界面看到“正下载更新包”的情况。这种更新的优势在于，其更新包可以做的很小，有利于减少流量，使用者不必受限于网络环境。游戏热更新我们知道，iPhone中应用大多依靠在App Store进行完整更新。对于用户而言，通过App Store进行更新，意味着用户需要重新下载完整的软件应用包，费时费力。对于游戏玩家来说，由于游戏需要频繁进行数据更新，修复BUG，大型运营活动等。如果不依靠热更新，显然是极为麻烦的。但热更新的问题在于，其更新内容不会受到苹果的审核。我们知道，App Store之所以广受欢迎，就在于其内优秀的软件应用。由于苹果严格的审核机制，才保证了软件应用的质量。对于苹果来说，失去了软件的控制权，无异于是自杀行为。因此，苹果表示要封禁“热更新”应用。苹果禁止热更新后，更新修复一个bug都要重要下载完整数据包这一行为在近期得到了实施，据统计，自6月13日以来，苹果已经在中国区下架了4万个应用，当中游戏应用占35%。或许这就是为什么，用户对苹果不满的原因。但是这次，苹果是真的被冤枉了。实际上，苹果不是封杀热更新，而是要求开发者采取合理机制。更准确的说，苹果只是禁用了几种热更新框架和技术，如JSPatch（苹果在去年发现JSPatch引起的更新漏洞可以被黑客利用）。这些框架能够直接修改代码，可以修改到功能，绕过了苹果的审核。而诸如React Native等热更新架构，则完全没有问题。所以对于开发者而言，只要软件在更新后使用符合要求的热更新架构，是完全没有问题的。对于我们普通用户，就更没有什么值得担心的地方了。总结：如苹果这样的大公司，一举一动都会牵扯到广大消费者的利益。在大公司与普通消费者之间，消费者永远是劣势的一方。但我们知道，水能载舟亦能覆舟。即使是强大如苹果，假如不能倾听消费者的意见，不能给出清晰明了的开发条款，一定会失去消费者的喜爱。苹果的问题在于，它没有一个能让消费者与之沟通的渠道，由此导致双方的信息传递出现了诸多问题，大大增加了双方的不信任感。事实上，一旦这样的不信任感持续增加，那距离苹果帝国的倒塌，或许也不远了。
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
西瓜谈谈一
百家号 最近更新：
简介: 百度是好公司，了解时事，尽在百度
作者最新文章自己动手做一个上传JSPatch补丁代码的Mac应用
卷首语：自己动手做JSPatch补丁代码的上传下发，补丁代码采用RSA非对称，安全性有保障。操作简单，只需要将文件拖进来即可。并且无接入数限制，永久免费!
接上篇文章,我们讲述了如何混淆JSPatch框架，以绕过苹果的检测。那么不可避免的我们就要面对一个问题，那就是自己做补丁代码的上传与下发工作。
首先我们看一下JSPatchPlatform这个官方平台的大致样子，如下图。
JSPatchPlatform平台.png
从图中我们可以看到，其中有几个非常重要的点，一个是给你APP的哪个版本下发补丁，另一个是你下发的补丁代码是什么，最后一个就是出于安全性考虑对你的补丁代码进行RSA非对称加密，因此我们主要围绕这三个功能来开发自己的上传补丁代码的应用。(当然补丁描述与开发预览功能也很实用，只是在这里我们暂时不做这样的功能，以后可能会加上去。。)
其实一开始就有两条路摆在面前，那就是你是做一个网页版的补丁上传入口还是做一个Mac版的应用呢，最后我们选择了自己做Mac应用，一是在没有十足的把握下(因为一开始我们并不确定我们的混淆方案能否通过)不想给其他研发组的人员增加工作量，二是作为一个开发者，我们不应该仅仅局限于开发手机应用，基于苹果OSX这个统一的得天独厚的生态，我们可以很容易的去开发一个简单的Mac应用。比如在开发过程中有很多工具是直接从现有项目里拿过来的，并且完全兼容，没有错误。所以最终我们只需要后台提供给我们一个接口就可以了。。。
下面就是我们开发这个Mac应用的大致思路。我们知道JSPatch最终解析的是一个字符串，所以我们就想把我们写的补丁文件比如main.js最终也转变成一个字符串，并且这个字符串是经过RSA加密过的，最后在将这个加密后的字符串上传到自己的服务器就可以了，所以最终要做的事情其实很简单：读取文件内容，进行加密，得到一个加密后的字符串，设置版本号，上传服务器。
所以我们的Mac应用是这个样子的(请假想它其实长得并不丑。。)
JP-Mac应用窗口.png
怎么使用这个应用呢：将你写好的本地js补丁文件，拖进那个文件框，点击开始加密，然后就会在下方显示出加密后的结果和文件的原始内容。关于服务器地址的设置，你需要到代码中根据自己的情况进行设置，版本号也需要自己设置，只要你能够对应起来就可以了。
下面简单的介绍一下本文中用到的非对称加密，这是用来对补丁代码进行加密的，非对称加密讲究公钥与私钥，先来搞定这两个东西。这里，我们使用的是OpenSSL生成的。我们最终需要的是一个PKCS#12格式的文件，以及一个自签名证书。因为自己用的是Mac系统，所以就不用再麻烦着安装OpenSSL了。
首先，生成私钥与自签名证书，这里，我们将其合并，我们需要的就是这种效果。
打开终端输入以下的命令(注意执行下面命令后会让你输入密码及填写一些基本的信息比如国家城市等等，本demo中的所有密码都是作者的笔名：ccsundaychina，而这个密码在demo中的Security类中也需要用到，读者到时可以自行进行修改。)
openssl req -x509 -days 3650 -new -newkey rsa:2048 -keyout priv_key_self_signed_cert.pem -out priv_key_self_signed_cert.pem
接着，使用上面生成的文件，导出PKCS#12格式的文件(后缀通常为pfx或p12)及自签名证书(后缀通常为der、cer、crt)。
openssl pkcs12 -export -out pkcs.p12 -in priv_key_self_signed_cert.pem
openssl x509 -in priv_key_self_signed_cert.pem -inform PEM -out cert.der -outform DER
这样我们得到了以下三个文件
证书文件.png
将其中的p12文件与cert.der文件拖入项目即可。
在项目中的Security类中用到了这两个文件。这个类的作用就是对输入的NSData进行RSA加解密的，下面是它的头文件。
// Security.h
// testMacDemo
// Created by ccSunday on .
// Copyright ? 2017年 ccSunday. All rights reserved.
@interface Security : NSObject
+ (instancetype)sharedS
// RSA公钥加密，支持长数据加密
- (NSData *)encryptWithPublicKey:(NSData *)plainD
// RSA私钥解密，支持长数据解密
- (NSData *)decryptWithPrivateKey:(NSData *)cipherD
当点击开始加密按钮的时候，就会对文件路径下的文件进行加密操作了，下面是具体的代码。
- (IBAction)parseFiles:(NSButton *)sender {
NSLog(@&文件路径：%@&,_FilesPathTf.stringValue);
//获得原始数据
NSData *baseData = [NSData dataWithContentsOfFile:_FilesPathTf.stringValue];
NSData *encryptData = [[Security sharedSecurity]encryptWithPublicKey:baseData];
//获得RAS加密后的字符串,将此字符串上传服务器。服务器需要返回该字符串。
NSString * base64Encoded = [encryptData base64EncodedStringWithOptions:0];
_resultTextField.stringValue = base64E
// NSData from the Base64 encoded str
NSData *nsdataFromBase64String = [[NSData alloc]
initWithBase64EncodedString:base64Encoded options:0];
//私钥解密
// NSData *
NSData *decryptData = [[Security sharedSecurity]decryptWithPrivateKey:nsdataFromBase64String];
NSString *result = [[NSString alloc] initWithData:decryptData encoding:NSUTF8StringEncoding];
_originalContentTF.stringValue =
需要注意的一点是，由于加密后返回的是NSData类型的数据，而上传服务器的时候需要转为NSString,所以需要对它再进行一层转换，这里我们采用的是base64获得所对应的加密字符串,读者也可以根据自己的情况进行转换。只要做好前后端的统一即可，而这个base64Encoded就是我们需要上传到服务器的主要东西了。一般APP端都会有自己的加密方式，那么在上传这个base64Encoded的时候，要记得对其按照APP端统一的网络请求的加密方式再做一层加密。
本文demo可以到这里下载，下载下来后解压JSPatch后台.zip，就可以得到一个Mac桌面应用了，使用的时候记得添加信任。
另外运行demo时候，如果需要输入密码的话，输入ccsundaychina即可。 打包的方式跟手机app的打包方式是一样的。【进阶篇】iOS解决方案JSPatchJSPatch – 动态更新iOS APP
招聘信息：
JSPatch是最近业余做的项目，只需在项目中引入极小的引擎，就可以使用JavaScript调用任何Objective-C的原生接口，获得脚本语言的能力：动态更新APP，替换项目原生代码修复bug。用途是否有过这样的经历：新版本上线后发现有个严重的bug，可能会导致crash率激增，可能会使网络请求无法发出，这时能做的只是赶紧修复bug然后提交等待漫长的AppStore审核，再盼望用户快点升级，付出巨大的人力和时间成本，才能完成此次bug的修复。使用JSPatch可以解决这样的问题，只需在项目中引入JSPatch，就可以在发现bug时下发JS脚本补丁，替换原生方法，无需更新APP即时修复bug。例子@implementation&JPTableViewController
-&(void)tableView:(UITableView&*)tableView&didSelectRowAtIndexPath:(NSIndexPath&*)indexPath
&&NSString&*content&=&self.dataSource[[indexPath&row]];&&//可能会超出数组范围导致crash
&&JPViewController&*ctrl&=&[[JPViewController&alloc]&initWithContent:content];
&&[self.navigationController&pushViewController:ctrl];
@end上述代码中取数组元素处可能会超出数组范围导致crash。如果在项目里引用了JSPatch，就可以下发JS脚本修复这个bug：#import&“JPEngine.m"
@implementation&AppDelegate
-&(BOOL)application:(UIApplication&*)application&didFinishLaunchingWithOptions:(NSDictionary&*)launchOptions
&&&&[JPEngine&startEngine];
&&&&[NSURLConnection&sendAsynchronousRequest:[NSURLRequest&requestWithURL:[NSURL&URLWithString:@"http://cnbang.net/bugfix.JS"]]&queue:[NSOperationQueue&mainQueue]&completionHandler:^(NSURLResponse&*response,&NSData&*data,&NSError&*connectionError)&{
&&&&NSString&*script&=&[[NSString&alloc]&initWithData:data&encoding:NSUTF8StringEncoding];
&&&&if&(script)&{
&&&&&&[JPEngine&evaluateScript:script];
&&&&return&YES;
defineClass("JPTableViewController",&{
&&//instance&method&definitions
&&tableView_didSelectRowAtIndexPath:&function(tableView,&indexPath)&{
&&&&var&row&=&indexPath.row()
&&&&if&(self.dataSource().length&>&row)&{&&//加上判断越界的逻辑
&&&&&&var&content&=&self.dataArr()[row];
&&&&&&var&ctrl&=&JPViewController.alloc().initWithContent(content);
&&&&&&self.navigationController().pushViewController(ctrl);
},&{})这样 JPTableViewController 里的 -tableView:didSelectRowAtIndexPath: 就替换成了这个JS脚本里的实现，在用户无感知的情况下修复了这个bug。更多的使用文档和demo请参考。原理JSPatch用iOS内置的JavaScriptCore.framework作为JS引擎，但没有用它JSExport的特性进行JS-OC函数互调，而是通过Objective-C Runtime，从JS传递要调用的类名函数名到Objective-C，再使用NSInvocation动态调用对应的OC方法。详细的实现原理以及实现过程中遇到的各种坑和hack方法会另有文章介绍。方案对比目前已经有一些方案可以实现动态打补丁，例如，可以用Lua调用OC方法，相对于WaxPatch，JSPatch的优势是：1.JS语言JS比Lua在应用开发领域有更广泛的应用，目前前端开发和终端开发有融合的趋势，作为扩展的脚本语言，JS是不二之选。2.符合Apple规则JSPatch更符合Apple的规则。里3.3.2提到不可动态下发可执行代码，但通过苹果JavaScriptCore.framework或WebKit执行的代码除外，JS正是通过JavaScriptCore.framework执行的。3.小巧使用系统内置的JavaScriptCore.framework，无需内嵌脚本引擎，体积小巧。4.支持blockwax在几年前就停止了开发和维护，不支持Objective-C里block跟Lua程序的互传，虽然一些第三方已经实现block，但使用时参数上也有比较多的限制。相对于WaxPatch，JSPatch劣势在于不支持iOS6，因为需要引入JavaScriptCore.framework。另外目前内存的使用上会高于wax，持续改进中。风险JSPatch让脚本语言获得调用所有原生OC方法的能力，不像web前端把能力局限在浏览器，使用上会有一些安全风险：1.若在网络传输过程中下发明文JS，可能会被中间人篡改JS脚本，执行任意方法，盗取APP里的相关信息。可以对传输过程进行加密，或用直接使用https解决。2.若下载完后的JS保存在本地没有加密，在未越狱的机器上用户也可以手动替换或篡改脚本。这点危害没有第一点大，因为操作者是手机拥有者，不存在APP内相关信息被盗用的风险。若要避免用户修改代码影响APP运行，可以选择简单的加密存储。其他用途JSPatch可以动态打补丁，自由修改APP里的代码，理论上还可以完全用JSPatch实现一个业务模块，甚至整个APP，跟wax一样，但不推荐这么做，因为：JSPatch和wax一样都是通过Objective-C Runtime的接口通过字符串反射找到对应的类和方法进行调用，这中间的字符串处理会损耗一定的性能，另外两种语言间的类型转换也有性能损耗，若用来做一个完整的业务模块，大量的频繁来回互调，可能有性能问题。开发过程中需要用OC的思维写JS/Lua，丧失了脚本语言自己的特性。JSPatch和wax都没有IDE支持，开发效率低。若想动态为APP添加模块，目前React Native给出了很好的方案，解决了上述三个问题：JS/OC不会频繁通信，会在事件触发时批量传递，提高效率。（详见）开发过程无需考虑OC的感受，遵从React框架的思想进行纯JS开发就行，剩下的事情React Native帮你处理好了。React Native连都准备好了。所以动态添加业务模块目前还是推荐尝试React Native，但React Native并不会提供原生OC接口的反射调用和方法替换，无法做到修改原生代码，JSPatch以小巧的引擎补足这个缺口，配合React Native用统一的JS语言让一个原生APP时刻处于可扩展可修改的状态。目前JSPatch处于开发阶段，稳定性和功能还存在一些问题，欢迎大家提建议/bug/PR，一起来做这个项目。版权声明：本文章在微信公众平台的发表权，已「独家代理」给指定公众帐号：iOS开发(iOSDevTips)。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量9470点击量6606点击量6134点击量3802点击量3566点击量3552点击量2917点击量2621点击量2377
&2016 Chukong Technologies,Inc.
京公网安备89}