1.先看下蘋果關于 .ipa上傳的大小規定：
最大建構版本檔案大小
解壓 XXX.ipa
size Payload/xxx.app/xxx
32位
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
檢視moblieprovision：
security cms -D -i /Users/xxx/xxx.app/embedded.mobileprovision 更新：通過編譯指令，給部分__TEXT資料 重新命名規避。
今日頭條優化實踐： iOS 包大小二進制優化，一行代碼減少 60 MB 下載下傳大小
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
第二種方法比較簡單粗暴，第一種方式需要有前瞻性或是有一個合理的架構模式。
解決問題的能力很關鍵~（iOS開發交流群：219926126）