扣丁书屋

Alibaba.com瘦包40MB——业界最全的iOS包大小技术总结

前言

包大小是衡量APP性能的一项重要指标,它直接影响用户的下载点击率(包太大不想下)、下载安装成功率(下载慢不用了)、APP卸载率(太占空间先删掉)。包大小的计算逻辑很简单,它是各种类型的文件占用磁盘大小相加。APP瘦身的技术却很复杂,代码文件的复杂度和编译器策略决定了可执行文件的大小,业务功能和工程架构决定了代码文件的复杂度。iOS APP瘦身,需要掌握的技能有XCode构建技术、LLVM编译器技术、CocoaPods构建技术、图片压缩技术、持续集成技术。本文总结提炼了Alibaba.com App的瘦身的技术和策略,系统化地介绍APP瘦身的业务价值、分析技术、瘦身技术、防劣化机制,让读者可以系统化地了解APP瘦身的技术体系。本文还基于实践经验,介绍各种瘦身技术的ROI,让读者可以避免踩雷,将资源浪费在效果不佳的技术上。希望对你有所帮助。

业务价值

包体大小每上升6MB,应用下载转化率就会下降1%

在2019谷歌开发者大会上,谷歌给出了一个很详细的数据,包体大小每上升6MB,应用下载转化率就会下降1%。不同地区转化率略有差异,APK包体大小每减少10MB ,全球平均下载转化率会提升1.75%,新兴国家代表印度和巴西下载转化率提升2.0%以上,高端市场代表美国和德国下载转化率提升1.5%。

上图标题:APK减少10MB,在不同国家转化率增长

数据来源:google play 内部数据

详细材料:白鲸出海:2019谷歌开发者大会首日看点

上述数据调研分析报告是2019年以前,已经有所滞后,仅供参考

包大小影响下载转化率可能有3个原因:

1.蜂窝网络环境下,用户不愿意支付流量费用。包大小超过200MB时,App Store会弹框提醒用户下载可能会产生流量费用。

2.下载时间太长,用户不愿意等就取消了

3.下载过程中出现网络连接问题虽然Google Play没有给出不同APP类目的数据,但是从以上三个原因推断,不同类目包大小对下载转化率的影响估计差不多。App Store的用户人群比较高端,可以参考美国和德国的数据。

20%的人因为存储空间有限而卸载应用程序

clevertap在2021年做了一项调查,他们调查了2000多个移动应用程序用户,询问了他们卸载移动应用程序的主要原因,其中有20%的人因为存储空间有限而卸载应用程序。

最主要的3个原因是:

1.他们不再使用该应用程序

2.有限的存储空间

3.太多的广告。

详细材料:clevertap:Why Users Uninstall Apps

App Store 发布和下载限制

兼容iOS8的App,主二进制文件的Text段不能超过60MB, 否则将无法提交App Store。App Store下载包超过200MB,无法使用蜂窝流量下载和更新。

分析技术

APP瘦身最终目标是减少App Store的安装包大小和下载包大小,但研发阶段对比XCode构建包大小会更方便,需要理清楚他们之间的口径差异。

结果指标:App Store安装包大小和下载包大小

查看路径是App Store Connect->TestFlight->交付版本->构建版本元数据->App Store文件大小

过程指标:XCode构建包大小

XCode构建产物ipa包的大小和App Store的安装大小口径差异很大,通过模拟Apple处理的流程可以得到它们的关系。开发者上传的ipa包里有多个架构的产物,多套尺寸的图片资源,苹果会进行裁剪和二次分发,转化为App Store下载的ipa包。

构建产物ipad包大小:静态库二进制文件(arm64、armv7)、动态库(arm64、armv7)、asset.car(@2x、@3x)、其他资源文件App Store的安装大小:静态库二进制文件(单架构)、动态库(单架构)、asset.car(单尺寸)、其他资源文件

使用lipo工具拆分单架构

lipo "originalExecutable" -thin arm64 -output "arm64Executable"

使用assetutil工具拆分asset

xcrun --sdk iphoneos assetutil --scale 3 --output "$targetFolder/Assets3.car" "$sourceFolder/Assets.car"

构建包组成

学习如何治病前,得先了解人体的构成。同样的道理,我们首现要了解iOS工程结构和IPA包结构。

iOS工程结构:iOS工程由壳工程和Pod模块组成,模块有静态库和动态库两种类型。壳工程的构成有主Target、Apple插件Target。模块内部的构成有源代码文件(OC、C、C++的.h和.m)、nib、bunlde、xcassets、多语言文件、各种配置文件(plist、json)。IPA包结构:iOS上传到App Store是IPA包,IPA包解压后是一个文件夹,内部由各种类型的文件构成,主要包括MachO可执行文件、.framework(动态库)、Assets.car、.appex(Apple插件)、.strings(多语言)、.bundle、nib、json、png...。从iOS工程到IPA包:iOS工程构建为IPA包,核心的变化是编译和文件拷贝,静态库里的源代码会被编译为MachO可执行文件,xcassets文件夹会被转化为Assets.car,其他都可以简单理解为文件拷贝。

通过分析构建包的组成,可以判断有哪些优化空间。如果动态库占比太高,就可能有大量可裁剪代码。建议根据资源大小敏感程度划分,比如:MachO executeable(包含所有静态库)、动态库、Apple Extension、assets.car、bundle、nib、音频、视频。

Pod模块大小

APP瘦身会涉及大量业务模块,离不开业务团队的参与。因此,我们需要分析出每个Pod模块的大小,从而可以横向比较各个业务团队的包大小占比。静态库和动态库计算的原理不同。对于静态库,先解析linkmap数据,计算出Pod模块代码大小,在解析Pods-targetName-resource.sh的资源拷贝代码,计算出拷贝到Pod模块的资源大小。对于动态库,先使用lipo拆分动态库的二进制文件,计算出单架构的代码大小,然后再计算动态库framework内的资源文件,得到动态库的资源文件大小。

运行时Objc类覆盖率

如果能知道App运行时有哪些类被使用过,就可以下线掉无用的模块或代码文件,Objc类覆盖率指标可以帮到我们。APP运行时,某1个Pod模块被加载的类数量除以所有类数量,可以称为这个模块的Objc类覆盖率。核心技术是判断一个类是否被加载过,下面介绍一个经过线上验证的轻量级方案。ObjC的类第一次被使用时会调用+initialize方法,类被加载过后cls->isInitialized会返回True。isInitialized方法读取了metaClass的data变量里的flags,如果flags里的第29位为1,则返回True。

// objc-class.mm
Class class_initialize(Class cls, id inst) {
    if (!cls->isInitialized()) {
        initializeNonMetaClass (_class_getNonMetaClass(cls, inst));
    }
    return cls;
}


// objc-runtime.h
#define RW_INITIALIZED        (1<<29)
bool isInitialized() {
    return getMeta()->data()->flags & RW_INITIALIZED;
}

未被使用的图片资源

技术原理是先解析出所有拷贝到构建产物的资源文件,再解析出代码中实际引用到的资源文件,两者的差集就是无用资源。

第一步获取全量资源文件。在Cocoapos工程中,“Pods-targetName-resource.sh”脚本负责拷贝Pod里的文件资源到构建产物,包括所有文件类型bundle、xcassets、json、png。解析该脚本可以得到每个Pod模块都拷贝了哪些图片资源。

// Pods-targetName-resource.sh
install_resource "${PODS_ROOT}/APodName/APodName.framework/APodName.bundle"
install_resource "${PODS_ROOT}/BPodName/BPodName.framework/BPodName.xcassets"
install_resource "${PODS_ROOT}/BPodName/BPodName.framework/xxx.png"

第二步,获取代码中实际引用到的资源文件。OC代码中引用资源文件都是以字符串字面量的形式声明,构建后存放在Mach-O文件"__cstring" section。利用strings解析framework的二进制文件就可以得到代码中所有的字符串声明,然后基于代码的各种引用方式匹配“xxx”,"xxx@2x.png","xxx.png","xxx.bundle/xxx.png"-

strings executable | grep 'xxx' > cstrings.txt

编译时未被引用的类

iOS编译的产物是Mach-o格式的,文件里 __DATA __objc_classrefs 段记录了所有引用过的类的地址,__DATA __objc_classlist段记录了所有类的地址,两者Differ可以得到未被引用类的地址。然后将地址符号化,就可以得到未被引用类信息。因为Objc是动态语言,如果使用runtime动态调用某个class,这种情况扫描不出来。(比如Target Action和 JS Core)

otool -v -s __DATA __objc_classrefs xxxMainClient  #读取__DATA Segment中section为__objc_classrefs的符号
otool -v -s __DATA __objc_classlist xxxMainClient #读取__DATA Segment中section为__objc_classlist的符号
nm -nm xxxMainClient

扫描未使用类的开源工具

瘦身技术

包大小瘦身可以从纯技术视角瘦身,也可以从逻辑视角瘦身。

从纯技术视角有两种思路,第一种思路是优化编译逻辑, 第二种思路是删减各种其他类型(非编译产物)的文件。编译优化对业务逻辑无侵入式,风险和成本比较低,但收益通常也不高。删减文件则比较复杂,删减资源文件收益高但成本不小,逐个删减源码文件风险高且收益小。

相比而言,从逻辑的视角瘦身效果会更明显。站在逻辑的视角,工程是由许多功能模块组成的,主要可以分为业务功能模块(首页、搜索、收银台、订单)、基础功能模块(网络库、图片库、中间件、各种三方库...)。大型工程通常几百甚至上千个模块组成,小模块的有几十KB,大的模块有1MB~10+MB。功能模块内聚性强,当某个功能模块可以废弃或被替代时,整体下线的风险和成本比较低,ROI很高。

瘦身技术大图

根据项目经验,我梳理出各种优化方法的ROI,下面依次介绍。

组件瘦身

组件瘦身的ROI:类加载率0%的组件 > 无用功能组件 > 重复功能组件“类加载率0%的组件”是一个完整的Pod模块,模块的代码和资源可以被整体删除,ROI最高。“无用功能组件”通常是模块内某个文件目录,需要处理一些耦合,梳理资源的归属,ROI其次。“重复功能组件”需要适当重构,迁移成本和风险最高,ROI相对较低。

类加载率0%的组件

“类加载率0%的组件”是指运行时没有任何一个类被加载过的组件,它在运行过程中完全没有用到,可以整体下线。统计类加载率时一般会进行采样,有些低频业务组件可能会误报,下线前需要和业务Owner二次确认。



无用功能组件

“无用功能组件”是逻辑上已经没用的组件,它可能代码还有耦合,但逻辑已经没用,通过重构就可以下线。比如AB实验没效果的业务代码、往年大促的业务代码、业务改版后遗留的老业务、已经过时的三方库。

重复功能组件

对于大规模团队,不同业务线可能会引入“重复功能组件”,比如图片选择器、缓存库、UI组件。重复的功能组件会带来不必要的包大小压力,同时也会带来维护成本。

资源瘦身

资源瘦身ROI:大资源>有损压缩>重复资源>iconfont>多语言文案瘦身>无用资源

大资源

对大资源进行单点优化收益很大,优先分析100KB以上的资源。比如音频文件,我们工程中音频铃声900KB,优化后去掉了700KB。

有损压缩

XCode构建时会做“compile asset catalog”,会重新对图片进行无损压缩。因此使用imageoptim等工具进行无损压缩效果不明显,其中压缩png图片没有效果,压缩jpg图片有一定效果。根据实践经验,icon做有损压缩并不影响视觉体验,压缩率可以达到70%~80%。比如使用tinypng算法压缩一张425.9 KB的png图片,压缩后79.8 KB,压缩率达到81%。业界有不少png压缩工具,我们使用到的有tinypng、pngquant、pngcrush、optipng(无损)、advpng。实测发现不同的图片,压缩效果最好的工具是不一样,所以压缩图片时可以用每个工具尝试,然后取效果最好的。需要注意的是,压缩APNG图片可能会变成非动图,尽量避免对APNG图片进行压缩,压缩前先识别是否APNG图片。

# 判断是否APNG格式,APNG格式不压缩
function isApng() {
    ret=`grep "acTL" "$1"`
    lastWord="${ret##* }"
    if [[ $lastWord == "matches" ]]; then
        echo "YES"
    else
        echo "NO"
    fi
}
# 使用各种工具压缩png图片
# pngquant
pngquant  256 -s5 --quality 70 --output "${tmpFileName}" -- "${tmpOrigName}" 
# pngcrush
pngcrush -brute -rem alla -nofilecheck -bail -blacken -reduce -cc -- "$tmpOrigName" "$tmpFileName"
# optipng
optipng -o6 -i0 -out "$tmpFileName" -- "$tmpOrigName"
# advpng
cp "$tmpOrigName" "$tmpFileName"
advpng -4 -z -- "$tmpFileName"

# 逐个比较压缩效果,保留效果最好的压缩图片
sizeBefore=`stat -f%z "${tmpOrigName}"`
sizeBefore=`expr $sizeBefore`
sizeNow=`stat -f%z "${tmpFileName}"`
sizeNow=`expr $sizeNow`

if [ "$sizeNow" -lt "$sizeBefore" ]; then
  # 大小变小了
  echo "[advpng] $tmpOrigName"
  retImg="$tmpFileName"
fi
# 记录hash值
img_sum=`/usr/bin/shasum -a 256 "$retImg" | cut -d " " -f1`
cache_file="$cacheFolder/$img_sum.png"

无用资源

业务长期迭代会积累许多无用的资源。通过代码静态扫描,可以分析出没有被引用的图片资源。我们有工程无用资源有12MB,其中有20个模块无用资源超过100KB。

重复图标

不同业务需求会引入重复资源,长期积累也会造成很大浪费。解决方案是在构建时计算资源的哈希值,去重相同哈希资源,并保留源文件名和哈希值的映射表。运行时Hook 资源加载的”imageNamed“方法,根据映射表替换资源名称。

ODR

iOS不能像Android一样,运行时更新Framework。iOS的ODR技术(On Demand Resource)提供了运行时动态下载的能力。如果启动用不到的资源文件,可以通过ODR处理。

iconfont

iconfont支持缩放、修改颜色,它size小,适合用于箭头、占位图等图标场景,使用iconfont可以减少包大小也能提高开发视觉体验的统一性。首先,基于设计规范出一套完整的iconfont,封装iconfont组件,提供易用的API。然后禁止新业务场景增加图片资源,团队形成开发习惯后再逐步替换存量的图片。

多语言文案

对于国际化App,多语言文案也是大头。我们App支持20个语种,每个语种4000多条文案,文案总大小6MB,瘦身后减少了2MB。

编译优化

编译优化ROI:Optimization Level > 动态库复用主二进制静态库> 链接器产物压缩

XCode编译优化选项中,Optimization Level效果最明显,建议所有模块构建都开启Oz选项。如果APP有动态库,并且依赖了openssl等基础静态库,建议和APP工程共享,并通过EXPORTED_SYMBOLS_FILE的选型,确保动态库中需要用到的符号都在编译过程保留。如果团队技术储备强,可以自研链接器产物压缩技术,效果也很大。具体效果如下。

主工程 OC模块 62880行代码 C++模块
LTO <10KB 开启前 modulesize:2020KB, MainProjectSize:6463KB 开启后 modulesize:1582KB MainProjectSize:6888KB 收益:13KB /
剥离符号表:Strip Linked Product <10KB / /
精简编译产物Oz:Optimization Level 100-200KB Os:2261KB Oz:2020KB 收益:241KB /
Symbols Hidden by Default <10KB 优化前:2020KB 优化后:2020KB 收益:0KB /
剔除未引用的C/C++/Swift代码:Dead Code Strippin <10KB / /
Asset Catalog Compiler <10KB
动态库共享APP基础静态库 / / 动态库A依赖了公共的静态库库B,通过设置只导出必要符号 收益:1367KB
C++全局静态数组改成动态分配内存 / 收益:200KB
C++去掉RTTI支持 / 收益:1MB

精简编译产物Oz:Optimization Level

Optimization Level多个级别,-Oz比-O3的编译产物体积小10%左右。设置-Oz以后,XCode会优化连续的汇编指令,从而减少二进制大小,但副作用是执行速度会变慢。C++工程建议都开启。


主工程Release
Optimization Level :-Oz

Framework工程
Optimization Level :-Oz

LTO(OC/C++)

LTO 是在LLVM链接时,优化跨模块调用代码。根据大家分享的经验,它不同APP包大小优化效果差异较大,需要具体测试。另外它也有一些副作用,建议只在Release包开启。LTO介绍

优点:

●将一些函数內联化

●去除了一些无用代码

●对程序有全局的优化作用

缺点:

●降低编译链接速度,只建议在打正式包时开启

●降低 link map 可读性(出现XX-lto.thin的类)

主工程设置


主工程Release
Link-Time Optimization 设置为Incremental

framework工程Release
Link-Time Optimization 设置为Incremental

动态库复用主二进制静态库

C++动态库经常用到一些基础库比如openssl、libyuv、libcurl,他们一般是静态库。如果动态库引用了静态库,它编译时默认会内嵌静态库的所有符号。虽然我们可以在动态库中设置只导出需要用到的静态库符号,但是有可能多个动态库都用到了同一个基础库,这样还是会造成基础库的冗余。比如openssl大小1MB,如果A、B两个动态库依赖了openssl,APP也引用了openssl,最终ipa包实际有3个openssl,有2MB大小是冗余的。

这种场景下,最佳解决方案是共享符号表,让动态库可以调用主二进制的基础库符号,从而可以去掉内置的静态库。只要修改XCode的Link配置,无需额外的代码开发。

动态库工程:

1、设置当遇到未定义的函数时,动态查找APP主二进制符号表。

2、关闭bitcode


Other Linker Flags -> -undefined dynamic_lookup
Enable Bitcode -> No

3导出动态库需要调用的外部符号,写到一个文件exported_symbols内

nm -u  xxx.framework/xxx > exported_symbols.txt

APP工程:

1、配置需要导出exported_symbols文件内的所有符号,避免编译时动态库需要用到的符号被strip掉。

2、关闭bitcode。


// exported_symbols.txt是需要被导出的符号文件路径
EXPORTED_SYMBOLS_FILE -> exported_symbols.txt
Enable Bitcode -> No

如果C++动态库里依赖了外部静态库,该静态库的符号默认会被全部导出。实际上动态库只用了其中的部分符号,可以设置导出符号的白名单,从而减少导出没有用到的静态库符号。

注意事项:

1APP和framwork工程都要关闭bitcode,否则编译不过。2如果多个动态库都使用同一个基础库,导出的符号表需要取并集。3动态库升级要及时更新符号表,基础库升级要测试兼容性。

链接器产物压缩(黑科技)

iOS工程构建产物是MachO文件,MachO文件中的TEXT段存放了各种只读的数据段,__cstring段存放了普通的C String,__objc_methtype和__objc_methname存放了Objc的方法签名和方法名。比入Objc代码中声明的@"Hello world",底层会产生一个CFString,构建后存放在__cstring中。这些数据很占空间,一般工程至少会有10MB以上,压缩的收益很可观。我们上线后,App Store安装包大小从191MB优化到174MB,减少了16MB。

技术原理:

链接时将TEXT段数据移到__DATA段并压缩,运行时先执行解压代码,解压TEXT段数据存到自定义段中,将代码中对字符串的引用的地址修正为解压后的自定义段。

剥离符号表:Strip Linked Product

Strip Linked Product设置会剥离特定的符号,Debug环境不要设置YES,否则调试时看不到符号。

主工程Release
Deployment Postprocessing :YES
Strip Linked Product :YES
Strip Style :All Symbols(剥离所有符号表和重定向信息)

Framework工程
Deployment Postprocessing :YES
Strip Linked Product :YES
Strip Style :Non-Global Symbols(剥离包括调试信息等非全局的符号,保留外部符号)

说明:

1、静态库不能将Strip Style 设置为All Symbols,因为剥离了所有符号的静态库是无法被正常链接的

2、去除符号不影响 dSYM 文件中的符号信息,查看崩溃日志时,可以从 dSYM 文件中找对应符号

Symbols Hidden by Default

Symbols Hidden by Default用于设置符号默认可见性,如果设置为YES,XCode会把所有符号都定义为”private extern”,包大小会略有减少。动态库设置为NO,否则会有链接错误。


主工程Release
Symbols Hidden by Default :Yes

Framework工程 静态库/动态库
Symbols Hidden by Default :NO

剔除未引用的C/C++/Swift代码:Dead Code Stripping

Dead Code Stripping开启后会在链接时移除未使用的代码,它对静态语言C/C++/Swift有效,对动态语言OC无效。

主工程
Dead Code Stripping :Yes

Asset Catalog Compiler

Optimization有三个选项,空、time和Space,选择Space可以优化包大小

主工程
Asset Catalog Compiler->Optimization设置为space

C++只导出必要符号:Symbol Visibility

C++的静态库和动态库都只导出必须的符号,默认设置为隐藏所有符号,然后用Visibility Attributes单独控制需要导出的符号

默认隐藏所有C++符号

Other C++ Flags->添加-fvisibility=hidden

设置需要导出的符号


__attribute__((visibility("default"))) void MyFunction1() {} 
__attribute__((visibility("default"))) void MyFunction2() {} 
....

代码下线

根据Objc类覆盖率统计的结果,可以逐步下线掉未被使用的类。代码文件的量级比较小,下线代码需要仔细确认,避免引起功能问题或crash,ROI比较低。

Flutter专项

Flutter是单独构建的,引入的内容包括Flutter引擎产物、Flutter业务代码产物。APP如果引入Flutter,需要对Flutter进行专项瘦身。

精简编译产物Oz:Optimization Level

-Oz选项相比Os,收益预估11%,但首屏性能1%~9%的损耗

Dart符号剔除和混淆

根据官方文档,可以通过--dwarf-stack-trace选项去除Dart标准的调试符号。通过--obfuscate 选项,可以将较长的符号替换为短符号,副作用是符号会被混淆。实践效果:Release环境下,--dwarf-stack-trace和--obfuscate选项开启后减少14%的大小

Flutter icon摇树优化

--tree-shake-icons实践效果:Alibaba.com App开启后减少了300KB左右大小

去除NOTICES文件

实践效果:压缩前700KB,压缩后80KB

防劣化机制

增量标准和集成卡口

包大小瘦身的技术就像各种减肥运动,跑步、跳舞、燃脂瑜伽。但想达到减肥的目标,只靠运动是不够的,还得控制卡路里的摄入,管住嘴的人最后才能减肥成功。因此,我们还需要”新增卡路里的规范”(包大小增量规范)和监工(集成卡口)。持续集成当中加入一个卡口插件,分析构建包的linkemap文件得到模块的大小可,然后对比基线数据,如果违反了包大小增量标准,则禁止集成。

包大小增量规范(参考):

1.基线数据:基于特定版本,通过上文提到的”计算模块大小“的方法,计算出每个模块的基线数据

2.存量模块:模块增量超过基准数据100KB时禁止集成。设置补偿机制,如果能对存量模块瘦身,可以抵消新增的模块大小。对于特殊情况可以走特殊审批,加入审批流程是启发大家反思。增加那么多是否有价值?有没有带入不必要的资源?

3.新模块:新业务功能需要走审批流程,评估新业务价值和包大小增量是否合理。

横向对比业务健康度

当包大小从技术层面已经优化到极致时,想要进一步瘦身,只能从业务价值的角度去挖掘。如果一个模块磁盘尺寸大,用户使用量却少,那可以认为它对业务的价值较小。因此我们可以定义一个技术指标来衡量模块单位大小的业务贡献度。基于容积率指标,我们就可以横向对比各个业务,要求容积率低的业务做包大小瘦身,或下线不太重要的业务功能。

容积率 = Business PV / Business size

总结

总结一下包大瘦身的实施路径。第一步,制定目标,跟踪APP下载转化率(App Store Connect Analytics)、APP安装包大小、XCode构建包大小等结果指标。第二步,建设分析体系,包括Pod模块大小分析、Objc类覆盖率分析、无用图片资源分析等。第三步,根据ROI使用各项瘦身技术,组件瘦身>资源瘦身>编译优化>代码下线.第四步,建设防劣化机制,包括增量标准、集成卡口能力、健康度分析。


https://mp.weixin.qq.com/s/I6DH5RvkMh_-bxGpkAKBPA

最多阅读

iOS 性能检测新方式​——AnimationHitches 11月以前  |  22200次阅读
快速配置 Sign In with Apple 3年以前  |  5761次阅读
APP适配iOS11 3年以前  |  4711次阅读
App Store 审核指南[2017年最新版本] 3年以前  |  4535次阅读
所有iPhone设备尺寸汇总 3年以前  |  4452次阅读
使用 GPUImage 实现一个简单相机 3年以前  |  4143次阅读
开篇 关于iOS越狱开发 3年以前  |  3976次阅读
在越狱的iPhone设置上使用lldb调试 3年以前  |  3891次阅读
给数组NSMutableArray排序 3年以前  |  3819次阅读
UITableViewCell高亮效果实现 3年以前  |  3510次阅读
使用ssh访问越狱iPhone的两种方式 3年以前  |  3497次阅读
关于Xcode不能打印崩溃日志 3年以前  |  3427次阅读
使用ssh 访问越狱iPhone的两种方式 3年以前  |  3242次阅读
为对象添加一个释放时触发的block 3年以前  |  3017次阅读

手机扫码阅读