1.先看下苹果关于 .ipa上传的大小规定:
解压 XXX.ipa
size Payload/xxx.app/xxx
上图为, 32位ipa
上图为, 32位 + 64位
有些2dx、u3d游戏 或是 超级app __TEXT部分会超过60MB(比如淘宝 等)。
这时候可以把部门代码或是第三方做成动态库,作为资源(类似bundle 或是图片资源)打包到xxx.ipa里面。
然后在程序启动时候,不论是+load()时候 还是+load()后、main之前,还是main之后用到该库之前,可以动态去加载动态库。
__attribute__((constructor))
void load_dyld_framework() {
NSString *frameworkPath = [NSString stringWithFormat:@"%@/MyFramework",[[NSBundle mainBundle] pathForResource:@"MyFramework" ofType:@"framework"]];
void* libHandler = dlopen([frameworkPath cStringUsingEncoding:NSUTF8StringEncoding], RTLD_LAZY);
if (libHandler == NULL) {
char *error = dlerror();
NSLog(@"dlopen error: %s", error);
} else {
NSLog(@"dlopen load framework success.");
}
}
以上方法为+load()后、main之前加载自己的动态库,另外一定要给自己的动态库 签名!签名!签名! 不然在读取的时候会报错。
查看framework 签名信息:
codesign -d -vv xxx.framework
查看本机证书:
/usr/bin/security find-identity -v -p codesigning
签名:
codesign -fs "iPhone Developer: ... (...)" xxx.framework
2.Android 引用函数数量超过65535限制
那么让我们看一下为什么会引起这种错误?
在Android系统中,一个APP的所有代码都在一个Dex文件里面。Dex是一个类似Jar的存储了多个Java编译字节码的归档文件。因为Android系统使用Dalvik虚拟机,所以需要把使用Java Compiler编译之后的class文件转换成Dalvik能够执行的class文件。这里需要强调的是,Dex和Jar一样是一个归档文件,里面仍然是Java代码对应的字节码文件。当Android系统启动一个应用的时候,有一步是对Dex进行优化,这个过程有一个专门的工具来处理,叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件,即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。但是在早期的Android系统中,DexOpt有一个问题,也就是这篇文章想要说明并解决的问题。DexOpt会把每一个类的方法id检索起来,存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的,导致了方法id的数目不能够超过65536个。当一个项目足够大的时候,显然这个方法数的上限是不够的。尽管在新版本的Android系统中,DexOpt修复了这个问题,但是我们仍然需要对低版本的Android系统做兼容。
解决方案:(1)应用插件化 (2)分割Dex
第二种方法比较简单粗暴,第一种方式需要有前瞻性或是有一个合理的架构模式。