App Thinning

App Thinning可以译成“应用瘦身”。指的是App store 和操作系统在安装iOS或者watchOS的 app 的时候通过一些列的优化,尽可能减少安装包的大小,使得 app 以最小的合适的大小被安装到你的设备上。而这个过程包括了三个过程:slicing, bitcode, and on-demand resources。

slicing

App Slicing在节省应用所需资源中发挥着最重要的作用。

很多应用需要在不同尺寸的设备上运行,针对这些不同的设备,它们内含不同的独立资源,而大部分是你的设备不需要的。所以App store会针对不同的设备制作不同的“简化版App”,当你下载app时候只需要下载不同的“简化版app”就可以了。

比如用户使用的是iPhone 5c,它运行的是32位CPU和GPU,并不支持Metal API。但如果用户下载的是一款最新的通用游戏应用,它的二进制中含有64位代码,iPad和“3x”iPhone 6 Plus 资源以及Metal API代码,这些都是你的设备用不上的。它只需要32位代码,“2x”iPhone尺寸资源以及OpenGL图形代码。

Slicing 的主要的工作流程如下:

1、在 Xcode中,选择好目标设备并且使用 asset catalog 提供多分辨率的图片资源

只有使用 asset catalog 才能正确使Slicing作用于资源文件

2、在模拟器或者设备上编译并运行app

3、Xcode 会自动构建针对你运行设备的“简化版app”,同时也是为了减少编译时间和进行本地的测试

4、打包app(为了及时发现不同目标设备的配置错误,可以在本地为目标设备导出“简化版app“,测试无误后再打包)

5、上传打包好的app到 iTunes connect。App store 将会为上传的app归档创建不同的“简化版app”。

6、在 iTunes Connect 中, 发布一个预览版给合格的测试者进行测试

7、测试者通过 TestFlight 下载预览版。TestFlight 会自动根据测试者的设备下载合适的“简化版app”。

Bitcode (iOS, watchOS)

Bitcode是一个编译好的程序的中间表示形式。上传到 iTunes Connect 中的包含Bitcode的app 将会在 App store 中进行链接和编译。苹果会对包含Bitcode的二进制app进行二次优化,而不需要提交一个新的app版本到app store中。

On-Demand Resources (iOS)

ODR(on-demand resources 随需应变资源)是iOS减少应用资源消耗的另外一种方法。比如多级游戏,用户需要的通常都是他们当前的级数以及下一级。ODR意味着用户可以下载他们需要的几级游戏。随着你的级数不断增加,应用再下载其他级数,并将用户成功过关的级数删掉。

当用户点击应用内容的时候,就会动态从App Store上进行下载,也就是说用户只会在需要的时候占用存储空间。这项功能有趣之处还在于当将这些内容在后台进行下载之后,当存储空间紧张的时候会自动进行删除。

On-Demand Resources可以是除了可执行代码外的任意类型。

在开发过程中,你可以通过分配一个或多个tag来识别On-Demand Resources。你可以使用tag的别名来确定什么时候将它加载到你的App中。

下图展示了一个在App中保持最小资源占用的例子

可以给资源设置优先级,比如当App从Appstore安装后就立即加载。

**On-Demand Resources的生命周期**

1、App向操作系统请求资源。操作系统将请求发送给包含所有所需资源的asset packs。

2、asset packs检查请求的资源本地是否存在。如果存在,则直接提供App使用。

3、如果请求的资源本地不存在,则它们被保存在App Store。

4、操作系统开始下载本地不存在的资源

5、远程资源下载完毕

6、当资源下载成功或监测到资源包已经被下载,资源包内存计数将会被+1,并通知App此资源可用。

7、当请求的资源可用,App使用资源标签对应的资源。

8、操作系统在本地释放资源标签

9、操作系统在本地清除资源缓存。当一个缓存资源不与任何请求相关联时,操作系统会在一定时间后将它释放掉。

完整的生命周期如下图所示

实际处理方法

1、iOS9以后Xcode默认开启On-Demand Resources功能,可以在下图所示位置进行设置。

2、在App中创建Tags

3、给文件设置tag

4、给图片设置tag

5、给tag设置加载的优先级

有三种加载优先级

* **Initial install tags.** 资源和App同时下载,在App Store中,App的大小计算已经包含了这部分资源。当没有NSBundleResourceRequest对象访问它们时,它们将会从设备上清除。

* **Prefetch tag order.** 在App安装后开始下载,按照预加载列表中的顺序依次下载。

* **Dowloaded only on demand.** 只有在App中发出请求时才会下载。

**资源大小限制**

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,222评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,455评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,720评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,568评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,696评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,879评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,028评论 3 409
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,773评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,220评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,550评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,697评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,360评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,002评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,782评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,010评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,433评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,587评论 2 350

推荐阅读更多精彩内容