包体积优化，或者说包体积瘦身，相较于 crash 治理、卡顿优化、启动优化等比较硬性的指标来说，优先级可能没有那么高。特别是对于一些孵化期和成长期的 App 来说，用户量、DAU 没有上去之前，来进行包体积瘦身收益也不高。但是对于得物这种千万日活的 App 来说，进行包体积的瘦身还是具有蛮大意义的，为此，得物 App 也投入了不少资源来对包体积进行一系列的优化。
在介绍优化手段之前，我们先梳理下包体积瘦身的意义：
包体积瘦身最主要的好处是对应用 下载转化率 的影响，在不考虑外部因素影响下，如果你的 App 相较竞品 App 体积要更小的话，那么用户下载的欲望可能要高一些
包体积变小，运营增长投放的成本也能降低，对用户来说，获取安装包的流量成本也变小，下载等待时间也越短，心理上的下载欲望也会有所提升
包体积越小，代表安装时候所需要的文件拷贝、Library 解压、签名校验等花费的时间越短，也就可以获得更快的安装速度
包体积瘦身也能为 App 的启动和运行性能带来正收益
解压一个 APK 后，我们会发现 Android 安装包主要由 libs(就是so文件)、assets、res以及code(dex)组成。大部分应用中，这些内容都占了安装包99%的体积。毫无疑问，我们的优化也必然要从这几个方面着手切入。
RES 资源
资源相关的部分包括 res、assets、编译后的二进制资源文件 resources.arsc 和 清单文件 等，这一部分的优化效果是相对来说最容易、收益最高的。
其中， res 目录下的文件在打包的过程中会由 aapt2 自动生成对应的资源 ID，并且保存在 .R 文件中，但 .R 文件仅仅只是保证编译程序不会报错，实际上在应用运行时，系统会根据 ID 寻找对应的资源路径，而 resources.arsc 文件就是用来记录这些 ID 和 资源文件位置对应关系 的文件。
在绝大部分 App 中， res 目录下体积占比较高的当属图片和xml文件了。AAPT2 在打包 res 下的过程中，又可分为编译和链接两个部分：
在编译阶段，aapt2会解析输入的源文件并生成一个扩展名为 <span style="letter-spacing: 1px;">.flat 的中间二进制文件。默认情况下，此阶段会对所有 PNG 文件进行压缩，AAPT2 对于 PNG 图片的压缩可以分为三个方面：
RGB 是否可以转化成灰度
透明通道是否可以删除
是不是最多只有 256 色（Indexed_color 优化）
虽然 AAPT2 默认支持对PNG图片的优化，但是它采用是是相对保守的 Indexed_color 算法，这是一种无损的压缩算法，如果我们想要更高的压缩率，可以使用一些其他的压缩工具，来集成到我们的编译打包流程中。
在链接阶段，AAPT2 会合并在编译阶段生成的所有中间文件（如资源表、二进制 XML 文件和处理过的 PNG 文件），并将它们打包成一个 APK。此外，在此阶段还会生成其他辅助文件，如 <span style="letter-spacing: 1px;">R.java 和 ProGuard 规则文件。
了解了资源打包的相关流程，那么对应的优化方案也就有了头绪。我们主要从以下四个方向切入:
这一部分主要是针对一些图片，可以通过cdn下发的就没必要存放在apk里面了；cdn下发的方案必然会带来流量上的消耗，这一部分的优化是通过图片库接入cdn格式转换、图片裁剪等手段来处理的。
2 . 压缩res下的图片体积
开发同学在资源添加的时候会先通过 tinypng等手段来对图片进行压缩，同时在代码合入阶段通过CI检测避免非法大图资源的合入，最后在打包过程中，集成了Gradle 压缩插件 shrink，来进一步对资源进行优化处理。
3 . 剔除res下的无用资源
这一部分没有做额外的处理，只是开启了 shrinkResources 选项。
4 . 合并res下的相同资源
res 下存在不少命名不同但是内容一样的资源，这种情况在组件化工程中特别常见，这一部分也是通过 shrink 插件来统一处理掉的。
Assets 目录下的文件是通过 AssetManager 类的接口来获取，aapt2不会对它进行任何优化处理。同时，建立在Assets文件夹中的文件是只读的，自然也就无法通过下发资源的形式来进行处理。针对 Assets 下的资源，采取的方案也是裁剪与压缩两种模式。shrink 插件支持了对 Assets 目录下的图片进行压缩，裁剪则是通过代码调整的方式进行。
Assets 的裁剪主要从两个方面，一是检测出无用的Assets资源(通过ApkChecker,或者 gradle 插件均可做到)，然后删除掉；二是通过代码调整，将本来放在assets下的资源移到其他文件夹中，这样就可以通过资源下发的方式来进行处理。
这里总结下 shrink 插件目前提供了的功能：
libs下主要是一些 .so 文件，比较常规的是只保留一种abi架构，即通过 abiFilters 限定只让指定 abi 的 so 参与到最终的 mergeapk 流程。
得物 App 中使用到了大量的 so 来承载业务功能，其中大部分的 so 是通过动态下发的形式处理掉了，so 的动态下发功能主要由自研的 Yeezy动态资源管理平台 承载。除去下发的 so 外，APK 包内依然存在20M 左右的 so 库，这里的大部分是启动和首页就需要用到的；由于 App 体验的原因，这部分不适合进行下发；同时，我们目前存在 32 位和 64 位2套 ABI 架构，如何在兼顾体验与稳定性的同时，优化32位 so 的是我们接下来要处理的一个痛点。
Dex 是 Android 系统的可执行文件，包含 应用程序的全部操作指令以及运行时数据。当 Java 程序被编译成 class 文件之后，还需要使用 dx 工具将所有的 class 文件整合到一个 dex 文件中，这样 dex 文件就将原来每个 class 文件中都有的共有信息合成了一体，这样做的目的是 保证其中的每个类都能够共享数据，这在一定程度上 降低了信息冗余，同时也使得 文件结构更加紧凑。
目前，得物 App 中接近一半的体积被 .dex 文件占据，同时随着业务迭代，DEX 体积还有逐步增多的趋势。DEX的主要优化一般是通过 ProGuard 来处理的，包括 压缩（Shrinking）、优化（Optimization） 和 混淆（Obfuscation）；对于商业 App 来说，一般很难做到 ProGuard 火力全开，在得物 App 中，Shrinking 和 Optimization 都是处于关闭状态，只有混淆是开启的。
Q：为什么要关闭 Shrinking 和 Optimization 呢？
因为使用到了大量三方库，其中有些库的功能导致无法开启 Shrinking 和 Optimization，比如开启Optimization 将导致热修无法使用；Proguard 中所做的优化包括 内联、修饰符、**合并**类和方法等 30 多种优化项，在特定的情况下，它尽可能地做了相应的优化。在无法开启 Optimization 的情况下我们可以借助插件在编译过程中，通过ASM接入字节码，从字节码层次来针对性的做一些优化，也就是选择性的将 Proguard 功能迁移到transform中去执行。
这里我们主要参考了 ByteX 和 Redex 中的实现，实现了常量内联、access 内联、R内联、方法删除等功能。可以看出，这一部分的优化依然存在很大的优化空间。同时基于 DEX 文件格式的一些优化，比如移除 release 包不需要的一些信息，比如支付宝debugItem移除 也将在后续版本迭代陆续实验推进。同时，Optimization 的逐步开放性调研，.dex 文件的动态下发均是将来需要持续跟进的。
当我们把上面这些优化手段都做了之后，我们发现随着版本的迭代，包体积很快就涨回去了；是怎么膨胀的，哪里增加的，都是为什么增加的追溯起来都比较麻烦；同时我们也想知道还有哪些优化空间，哪里可以作为切入点，所以我们开发了包体积监控平台。
包体积平台主要完成以下几件事情： 1. 监控包体积变化的趋势，解析 APK 中各类型资源详情 2. 以业务线的维度监控 APK 中各种类型资源的变化 3. 资源文件的追溯 4. APK 中依赖关系的梳理 5. APK 对比，发现迭代过程中产生的问题
引入包体积监控平台后，整体的打包流程如下：
要实现对 Apk 变化趋势的监控，前提条件是实现对每个 apk 的解析，我们的做法是基于开源的ApkChecker重新定制（主要是对并行出包、解析的支持），布置到远端服务上，Jenkins 打包成功后通知后端解析APK，后端调用ApkChecker 实现解析，拿到解析数据后再将数据落库。
实现划分基于业务线维度的资源报表，除了拿到解析的 APK 资源数据外，还需要知道数据的来源和归属的业务线；数据的来源可以向前追溯到具体的 AAR，AAR 的依赖和 AAR 中资源详情的采集可以通过在打包的过程中使用一个自定义的 gradle插件-dependency-analysis 拿到的，由于gradle打包过程中会将aar和jar都解压放置在指定的目录中，所以插件只需要到具体路径下拿到解压后的资源数据就可以了；这里我们采取的是收集
RUNTIME_CLASSPATH 类型的原始数据。
收集到了aar的数据并落库后，只需要将aar中的资源与apk中的资源做一层映射，便可建立关联。剩下的便只需将aar与业务线建立关联关系，如此便可实现业务线维度资源报表。
如何建立aar与业务线的关联呢？正好我们在做编译优化的时候，有建立一个组件管理平台--airforce，其中我们引入了一个基线的概念，每个apk版本都将与一个基线版本对应，基线版本下管理着该版本全部aar以及插件classpath配置；如此，只需要后端与airforce建立一次通信便可以拿到组件与业务线的关系了。
当一个apk构建出来后，我们希望在开发阶段及时发现、及时修改，避免在灰度和上线的时候出现不可控的体积膨胀问题；报警服务正式为这一目的而存在的。
根据前面的介绍，当一个apk打包出来通知后端进行处理的时候，我们可以拿到apk解析后的数据、拿到资源与aar的关系、拿到aar与业务线的关系，以及aar相关负责人信息。接下来只需要指定报警规则，在解析apk之后进行报警校验，然后将报警数据打通飞书机器人通知到具体开发人员进行处理。
包体积监控平台的其中一个目的是为了方便开发人员发现APK中可以优化的点，为了实现这一目标，在前端页面中实现将APK最终产物数据与aar原生产物数据进行聚合展示就比较有意义。
apk的产物分布负责直观的展示apk中这种类型文件的体积占比
依赖关系以业务线的维度展示构建apk的原始aar依赖关系
原始aar列表按解压后的体积降序展示，点击可以直观展示aar中的各资源详情
aar的展示主要可以用于发现功能重复的依赖，比如项目中同时存在Glide和Fresco，则可以考虑移除一个；以及方便业务同学判断so是否可以下发等。
大资源详情对应apk中体积比较大的资源，是资源优化的最要指导
在资源优化阶段，针对大资源的专项优化可以获得非常不错的收益，这一部分优化实施起来相对容易，属于风险小、收益高。优化阶段告一段落之后，则是需要对大资源的膨胀敏感监控，开发阶段及时预警。
优化建议直接展示 ApkChecker 检测出的各项问题
项目的迭代过程中，体积是随着需求的增加而不断膨胀的，apk 的对比功能对于发现问题具有指导性的意义。目前 apk 对比功能实现了按照大文件类型的对比、aar依赖体积变更的对比以及 apk 中资源变更的对比。功能的实现难度不大，只需要从数据库中取出差异数据即可实现。
包体积监控平台上线后，版本迭代期间爆发性的体积膨胀得到了较好的控制。
目前的包体积监控平台对资源类型的监控比较完善，但是对代码体积的监控相对就弱了些。后续再对 DEX 进行专项优化的同时也将同步完善 Code 类型文件的监控。在经过一系列的优化尝试之后，目前得物 App 中体积占比最大的 .dex 文件和 .so 文件是亟需优化的重中之重。
优化 DEX 也将围绕裁剪和优化两点展开，裁剪则是找到项目中没有用的代码进行删除，无用代码可以分为两类：一类是在业务角度出发，将一些功能重复的类合并，比如承载图片加载的只需要引入 fresco 从而删除 glide 的依赖；一类是从技术角度出发，找出线上真实无用代码，将找到的无用类通知到具体开发人员评估是否可以删除；优化则是从 DEX 文件格式的角度和 Proguard 优化的角度，参考 redex 等优化功能的实现，以独立插件的形式逐条落地，这一部分的挑战相对更大、采取的策略也将更为谨慎。
包体积瘦身是一个持续性的挑战，一方面业务功能在不断增加、不可避免带来代码量和资源的增加；另一方面是随着优化的进行，可操作空间的逐步压缩，优化的难度也越来越高。同时，如果贸然采用一些黑科技也将为稳定性带来更大的挑战，如何在保障稳定的同时优化包体积是一个需要不断探索的过程。路漫漫其修远兮，吾将上下而求索。
本文由哈喽比特于2年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/1aAgY4OPnZl650Q8vD3LNA
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而，京东官方通过微博发言人发布的消息澄清了这些传言，称这些言论纯属虚假信息和蓄意捏造。
日前，据博主“@超能数码君老周”爆料，国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为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 不会有什么区别的，除了序（列）号变了，这个‘不要脸’的东西，这个‘臭厨子’。
