目前cocos依旧是众多语言中,遇到4.3a的概率最高的,而且是最难解决的
无数客户的自述:
我的代码是新开发的 !
我的代码都是加密的!
我的客户端根本没有代码,我们都是热更新的!!!
请注意,所有的任何一个被拒案例 都是掌握苹果审核规律的重要依据
我尝试对cocos开发的App的ipa 进行了拆解, 有了重大发现(其实早都发现了, 剧情需要)
我们发现cocos的代码最终其实被编译成jsc文件, 集成到ipa内部
这个文件类似一个ts代码编译后的二进制文件, 我对这个jsc文件进行了多种尝试打开此文件, 经过了九九八十一翻操作, 我发现以我的水平很难打开此文件,这似乎
这是一件好事
为什么说这事一件好事, 因为如果我无法轻易打开这个文件 虽然不代表苹果也打不开, 但是我猜测苹果大概率不会打开这个文件查看里面的源代码
为什么这么说?
1: 苹果其实明确说明了: 出于对开发者知识产权的保护,不会逆向破解开发者源代码, 但是为了审核代码的相似度会提取重要特征
2: 根据大多客户的提审被拒案例来看, 无论是加密的代码, 新写的代码, 空代码都被苹果判断了4.3,说明这个jsc文件对苹果来说没有区分性, 也就是说 不在审查范围
这是一个非常重要的猜测, 让你在处理4.3的问题上直接大范围的排除疑点
那么4.3是什么导致的?
我通过研究cocos的项目结构 , 又发现了一个重大线索
我发现cocos的结构设计并不干净, 尤其是cocos 2.x 版本, 自动构建的xcode项目结构如此混乱.但是最重要的还是 cocos2d引擎库, 是以静态库的方式集成的
这个cocos2d子工程其实是一个静态库工程, 在cocos3.x版本中不以子工程的这种形式出现在主工程中,但是仍然是静态库的形式存在, 只是存在的方式有所区别, 最终的编译产物都是相同的, 那么了解静态库的开发者可能知道, 静态库最终被编译到可执行文件中.
这也是cocos的项目 , 可执行文件偏大的最重要的原因, 上图是一个空工程, 可执行文件高达12.4M,里面应该大部分由cocos2d静态库构成
这个静态库会不会是导致4.3的根本原因?
我虽然不敢肯定, 但是从近期大量客户的4.3案例中来看 ,有重大嫌疑, 我们在处理4.3的原则就是, 不确定的因素就要处理掉
那么问题来了,如何处理这个静态库
通过查看cocos2d 的静态库工程源码发现, 这个工层其实是由c++编写, 而且代码量非常大.
目前我们列举几个处理方式:
1: 修改源代码 , (pass, 修改源码之后cocos端调用会出现混乱)
2: 将静态库包装成动态库, 从可执行文件中抽离 (pass, 我亲自尝试将cocos2d静态库,抽离成pod形式集成,但是有大量报错, 搞的我头昏脑涨)
3: 编译过程中将cocos2d符号混淆 (✅被采取, 此方案不仅无需改动源码,而且操作简便)
例如我们 将CCFontAtlas.cpp 这个类文件的符号CCFontAtlas 在xocd编译过程中混淆成ILoveYou
但仍然是一个庞大的研发量,我们团队由5个人共同开发 , 耗时三个月研发完成
提取过程: 我们先提取所有c++符号
混淆过程:将提取的符号进行混淆
