App Store规定了安装包大小超过200MB的App不能使用OTA【over-the-air】环境下载，也就是只能在WiFi环境下下载。所以200MB就成了App的生死线，一旦超过这条线就很可能会失去大量用户。【如果你的App要兼容iOS7和iOS8的话，苹果官方主二进制text段的大小不能超过60MB。如果没有达到这个标准，你甚至都没法提交App Store】 另外，App包体积过大，对用户更新升级率也会有很大影响。
综上所述，App 包过大既损害用户体验，影响升级率，还会导致无法提交 App Store 的情况和非 WiFi 环境无法下载这样可能影响到 App 生死的问题。那么，怎样对包大小进行瘦身和控制包大小的不合理增长就成了重中之重。
对于一个App 从0-1 以及后续团队不断的迭代，研发人员的不断增多，伴随着也有能力的参差不齐，代码质量的高低不同。如果一味的增加需求，一味的写冗余重复的代码，势必很难维护以及打出的ipa包体积越来愈大。经历过一些版本的迭代，会发现ipa包体积变大了很多，想到了这些，我们应该可以做些什么，或者苹果官方为我们做些什么呢？
下面就按照上面一步一步跟着，给自己的App包瘦身。
App Thinning可以译成“应用瘦身”。指的是App store 和操作系统在安装iOS或者watchOS的 app 的时候通过一些列的优化，尽可能减少安装包的大小，使得 app 以最小的合适的大小被安装到你的设备上。
App Thinning 是由苹果公司推出的一项可以改善 App 下载进程的新技术，主要是为了解决用户下载 App 耗费过高流量的问题，同时还可以节省用户 iOS 设备的存储空间。现在的 iOS 设备屏幕尺寸、分辨率越来越多样化，这样也就需要更多资源来匹配不同的尺寸和分辨率。同时，App 也会有 32 位、64 位不同芯片架构的优化版本。如果这些都在一个包里，那么用户下载包的大小势必就会变大。
官方App Thinning包括了三个过程：slicing，bitcode，和 on-demand resources
App Slicing在节省应用所需资源中发挥着最重要的作用。
App Thinning 会专门针对不同的设备来选择只适用于当前设备的内容以供下载。比如，iPhone 6 只会下载 2x 分辨率的图片资源，iPhone 6plus 则只会下载 3x 分辨率的图片资源。
Slicing 的主要的工作流程图和过程如下：
Bitcode是一个编译好的程序的中间表示形式。上传到 iTunes Connect 中的包含Bitcode的app 将会在 App store 中进行链接和编译。苹果会对包含Bitcode的二进制app进行二次优化，而不需要提交一个新的app版本到app store中
ODR（on-demand resources 随需应变资源)是iOS减少应用资源消耗的另外一种方法。比如多级游戏，用户需要的通常都是他们当前的级数以及下一级。ODR意味着用户可以下载他们需要的几级游戏。随着你的级数不断增加，应用再下载其他级数，并将用户成功过关的级数删掉。
当用户点击应用内容的时候，就会动态从App Store上进行下载，也就是说用户只会在需要的时候占用存储空间。这项功能有趣之处还在于当将这些内容在后台进行下载之后，当存储空间紧张的时候会自动进行删除。
如果要进一步减小 App 包体积的话，还需要在图片和代码上继续做优化。为了减小 App 安装包的体积，我们还能在图片上做些什么？
删除无用图片应该是图片资源的优化空间最先想到的。那么，我们是如何找到并删除这些无用图片资源的呢？
对于删除图片，本人在项目中的实践采取的是下面的第二种第三种方法，大家跟着操作：
下面我们按照这个步骤开始着手去做~
删除无用图片的过程可以分为总共6个步骤和图解【思路如下】
<span style="font-size: 14px;">find /Users/zhang**/Project/ -name<span style="font-size: 14px;">pattern = @"@"(.+?)""。可以找到Assets.xcassets，对照着里面的一张张图片，然后在工程目录搜索，如果工程没有使用到的话，那就删除吧，此方法很土但费时，有没有好的操作方法呢？
FengNiao–一个删除Xcode工程中无用图片资源的神器！FengNiao一个命令行工具，由iOS界的大神onevcat喵神使用swift开发并开源。
下载FengNiao
git clone https://github.com/onevcat/FengNiao.git
进入到FengNiao目录下
执行./install.sh
fengniao会自动编译安装到/usr/local/bin目录下，然后成功结果如下：
cd到项目工程中，直接使用fengniao命令就可以【提供list（列表查看）、delete（直接删除）、ignore（忽略这些文件）三个命令】
通过输入l，就可以列举未使用的图片，大家对着看就好了，嘿嘿嘿，体验还不错！！！
本人建议这个是最好用的。大家可以查看LSUnusedResources源码
如果你不想自己重新写一个工具的话，可以选择开源的工具直接使用。本人觉得目前最好用的是 LSUnusedResources【运行此代码，最好的是还有人在维护，给作者一个赞】特别是对于使用编号规则的图片来说，可以通过直接添加规则来处理。
使用方式也很简单，可以参看下面的动画演示：【运行代码之后的界面】
4.4.2 将根目录输入进去，选择匹配法则，就可以可视化无用的图片
经过上面的三个方法，可以将无用图片彻底删除了，嘿嘿，完成优化了3-5MB的大小。不错不错~
无用图片资源处理完了，那么有用的图片还有瘦身的空间吗？答案是有的。
对于本人项目，安装App时，会有几个引导介绍视频，原本每一个视频大约都是2-3MB，但是对于包的减少，本人又让UI和视频组对4个引导视频压缩，最后大约每个引导都是1.3MB以内
此时引导视频优化了4-5MB优化空间，下面进行图片压缩方案探究。
对于 App 来说，图片资源总会在安装包里占个大头儿。对它们最好的处理，就是在不损失图片质量的前提下尽可能地做压缩。
目前比较好的压缩方案是，将图片转成 WebP。WebP 是 Google 公司的一个开源项目。
怎么把图片转成WebP？
Google 公司在开源 WebP 的同时，还提供了一个图片压缩工具 cwebp来将其他图片转成 WebP。cwebp 使用起来也很简单，只要根据图片情况设置好参数就行。
cwebp 语法如下：
cwebp [options] input_file -o output_file.webp
比如，你要选择无损压缩模式的话，可以使用如下所示的命令：
cwebp -lossless original.png -o new.webp
其中，-lossless 表示的是，要对输入的 png 图像进行无损编码，转成 WebP 图片。不使用 -lossless ，则表示有损压缩。
iSpart 是一个 GUI 工具，操作方便快捷，可以实现 PNG 格式转 WebP，同时提供批量处理和记录操作配置的功能。如果是其他格式的图片要转成 WebP 格式的话，需要先将其转成 PNG 格式，再转成 WebP 格式。它的GUI界面如下：
不过，WebP 在 CPU 消耗和解码时间上会比 PNG 高两倍。所以，我们有时候还需要在性能和体积上做取舍。
本人建议如果图片大小超过了 100KB，你可以考虑使用 WebP；而小于 100KB 时，你可以使用网页工具 TinyPng或者 GUI 工具ImageOptim进行图片压缩。这两个工具的压缩率没有 WebP 那么高，不会改变图片压缩方式，所以解析时对性能损耗也不会增加。
经过对部分图片的压缩，少了大约2-4MB的优化空间，到目前为止差不多有10-12MB的优化空间。嘿嘿~
App 的安装包主要是由资源和可执行文件组成的，所以在掌握了对图片资源的处理方式后，需要再一起来看看对可执行文件的瘦身方法
如果工程量不是很大的话，我还是建议你直接使用 AppCode 来做分析【本人项目就是使用它】当代码量过百万行时 AppCode 的静态分析会“歇菜”。毕竟代码量达到百万行的工程并不多。而，那些代码量达到百万行的团队，则会自己通过 Clang 静态分析来开发工具，去检查无用的方法和类。
用 AppCode 做分析的方法很简单，直接在 AppCode 里选择 Code->Inspect Code 就可以进行静态分析。
静态分析完以后，我们可以在 Unused code 里看到所有的无用代码，如下：【感觉棒棒哒】
接下来，说一下这些无用代码的主要类型。
看似 AppCode 已经把所有工作都完成了，其实不然。下面，列举下 AppCode 静态检查的问题：
self performSelector:@selector(arrivalRefreshTime)；layerClass = NSClassFromString(@“SMFloatLayer”)。还有以[[self class] accessToken] 这样不指定类名的方式使用的类，会被认为该类没有被使用。像 UITableView 的自定义的 Cell 使用 registerClass，这样的情况也会认为这个 Cell 没有被使用。基于以上种种原因，使用 AppCode 检查出来的无用代码，还需要人工二次确认才能够安全删除掉。
经过Appcode工具，大约找出优化了2-4MB的无用的类和代码。
除了这种方式，还有没有其他方法了呢？答案是有的，但是下面方法本人没有用到项目中尝试，但是还是要和大家说下，大家可以去尝试。
可执行文件的瘦身方法。可执行文件就是 Mach-O 文件，其大小是由代码量决定的。通常情况下，对可执行文件进行瘦身，就是找到并删除无用代码的过程。
查找无用代码，按照找无用图片的思路，即：
接下来，我们就看看具体的代码瘦身方法吧。
点击工程，选择 Build Setting 选项，搜索 map ，可以看到如下界面。将 Write Link Map File 设置为 Yes 后，Build结束后，会在默认路径下生成一个 Link Map File 文件，该文件是 txt 格式的。点击 Path to Link Map File ，可以设置 Debug 或 Release 模式下的生成路径。设置选项如下图所示：
查到Path to Map File路径【本人采用的模拟器】
打开txt文件
LinkMap 文件分为三部分：Object File、Section 和 Symbols
其中：
得到了代码的全集信息以后，我们还需要找到已使用的方法和类，这样才能获取到差集，找出无用代码。所以接下来，说说怎么通过 Mach-O 取到使用过的方法和类。
objc_selrefs 里的方法一定是被调用了的。objc_classrefs 里是被调用过的类，__objc_superrefs 是调用过 super 的类。通过 __objc_classrefs 和 __objc_superrefs，我们就可以找出使用过的类和子类。
如图上所示，可以看到 __objc_selrefs、__objc_classrefs和、__objc_superrefs 等这三个 section。
注意：
但是，这种查看方法并不是完美的，还会有些问题。原因在于， Objective-C 是门动态语言，方法调用可以写成在运行时动态调用，这样就无法收集全所有调用的方法和类。所以，通过这种方法找出的无用方法和类就只能作为参考，还需要二次确认。
都知道 Xcode 是使用 Clang 来编译 Objective-C 语言的，Clang 的优化选项在其文档 clang - Code Generation Options 中可以查阅得到。DE-Xcode 只提供给我们 6 个等级的编译选项，在 Xcode -> Build Setting -> Apple LLVM 9.0 - Code Generation -> Optimization Level 中进行设置
None[-O0]: 编译器不会优化代码，意味着更快的编译速度和更多的调试信息，默认在 Debug 模式下开启。Fast[-O,O1]: 编译器会优化代码性能并且最小限度影响编译时间，此选项在编译时会占用更多的内存。Faster[-O2]：编译器会开启不依赖空间/时间折衷所有优化选项。在此，编译器不会展开循环或者函数内联。此选项会增加编译时间并且提高代码执行效率。Fastest[-O3]：编译器会开启所有的优化选项来提升代码执行效率。此模式编译器会执行函数内联使得生成的可执行文件会变得更大。一般不推荐使用此模式。Fastest Smallest[-Os]：编译器会开启除了会明显增加包大小以外的所有优化选项。默认在 Release 模式下开启。Fastest, Aggressive Optimization[-Ofast]：启动 -O3 中的所有优化，可能会开启一些违反语言标准的一些优化选项。一般不推荐使用此模式。Fastest Smallest[-Os] 极小限度会影响到包大小，而且也保证了代码的执行效率，是最佳的发布选项，一般 Xcode 会在 Release 下默认选择 Fastest Smallest[-Os] 选项，较老的项目可能没有自动勾选。
Swift 语言的编译器是 swiftlang，同时也是基于 LLVM 后端的。Xcode 9.3 版本之后 Swift 编译器会提供新的选项来帮助减少 Swift 可执行文件的大小：
当然还有一个终极大招砍需求，哈哈哈【此种方法可能不太容易实现】
今天这篇文章，主要分享的是 App 安装包的一些瘦身方案。可以把包瘦身方案根据 App 的代码量等因素，划分为两种。
对于上线时间不长的新 App 和那些代码量不大的 App 来说，做些资源上的优化，再结合使用 AppCode 就能够有很好的收益。而且把这些流程加入工作流后，日常工作量也不会太大。
但是，对于代码量大，而且业务需求迭代时间很长的 App 来说，包大小的瘦身之路依然任道重远，这个领域的研究还有待继续完善。LinkMap 加 Mach-O 取差集的结果也只能作为参考，每次人工确认的成本是非常大的，只适合突击和应急清理时使用。最后日常采用的方案，可能还是用运行时检查类的方式，这种大粒度检查的方式精度虽然不高，但是人工工作量会小很多。
大致情况就是这样，动手吧！
本文由哈喽比特于3年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/mfm-Cg_uK1w24g3VcxK5Mw
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而，京东官方通过微博发言人发布的消息澄清了这些传言，称这些言论纯属虚假信息和蓄意捏造。
日前，据博主“@超能数码君老周”爆料，国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道，荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦（ASML）CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候，抖音悄然上线了一款名为“青桃”的 App，Slogan 为“看见你的热爱”，根据应用介绍可知，“青桃”是一个属于年轻人的兴趣知识视频平台，由抖音官方出品的中长视频关联版本，整体风格有些类似B站。
日前，威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”，同时，他发文表示：中国汽车普及率低于非洲国家尼日利亚，每百户家庭仅17户有车。意大利世界排名第一，每十户中九户有车。
近日，一项新的研究发现，维生素 C 和 E 等抗氧化剂会激活一种机制，刺激癌症肿瘤中新血管的生长，帮助它们生长和扩散。
据媒体援引消息人士报道，苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后，3D系统一度大涨超10%，不过截至周三收盘，该股涨幅回落至2%以内。
9月2日，坐拥千万粉丝的网红主播“秀才”账号被封禁，在社交媒体平台上引发热议。平台相关负责人表示，“秀才”账号违反平台相关规定，已封禁。据知情人士透露，秀才近期被举报存在违法行为，这可能是他被封禁的部分原因。据悉，“秀才”年龄39岁，是安徽省亳州市蒙城县人，抖音网红，粉丝数量超1200万。他曾被称为“中老年...
9月3日消息，亚马逊的一些股东，包括持有该公司股票的一家养老基金，日前对亚马逊、其创始人贝索斯和其董事会提起诉讼，指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息，为推广自家应用，苹果现推出了一个名为“Apps by Apple”的网站，展示了苹果为旗下产品（如 iPhone、iPad、Apple Watch、Mac 和 Apple TV）开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价，引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金（Future Fund）管理合伙人加里·布莱克发帖称，降价是一种“短期麻醉剂”，会让潜在客户等待进一步降价。
据外媒9月2日报道，荷兰半导体设备制造商阿斯麦称，尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效，但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日，根据美国证券交易委员会的文件显示，苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元（约 4.65 亿元人民币）。用于在 2023-2025 年期间，发射卫星，进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道，马斯克旗下社交平台𝕏（推特）日前调整了隐私政策，允许 𝕏 使用用户发布的信息来训练其人工智能（AI）模型。新的隐私政策将于 9 月 29 日生效。新政策规定，𝕏可能会使用所收集到的平台信息和公开可用的信息，来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日，荣耀CEO赵明在采访中谈及华为手机回归时表示，替老同事们高兴，觉得手机行业，由于华为的回归，让竞争充满了更多的可能性和更多的魅力，对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能（AI）系统，该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日，非营利组织纽约真菌学会（NYMS）发出警告，表示亚马逊为代表的电商平台上，充斥着各种AI生成的蘑菇觅食科普书籍，其中存在诸多错误。
社交媒体平台𝕏（原推特）新隐私政策提到：“在您同意的情况下，我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上，各大企业都带来了最新的理念和产品，而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品，具体内容为：“以我对我‘子公司’的了解，我认为 iPhone 15 跟 iPhone 14 不会有什么区别的，除了序（列）号变了，这个‘不要脸’的东西，这个‘臭厨子’。
