经验总结

  1. 首页 > 生活杂烩 > 美容减肥 > >

口红 5年磨一剑｜优酷Android包瘦身治理思路全解( 四 )

口红


常态化治理相对专项式治理 ， 更需要当作一个系统化工程来看待 ， 整体治理思路如下：

由专项式到常态化 ， 首先要做的转变是将关注点从“事”转移到“人”：每一个Byte都是由人（开发者）添加的 ， 对产生的原因（技术、流程、心理等）进行全面分析 ， 并给出有效解决方案 ， 才能够实现专项式到常态化的跃变 。 这个解决方案 ， 主要包括技术支撑、治理策略两方面 ， 二者相辅相成缺一不可 。
2.2 技术支撑
整个技术支撑体系的核心是包大小精准分析 ， 即对apk内任意实体元素（类、资源、so等）获取其在apk文件中实际占用值 。 因为编译过程会进行各种合并、裁剪、优化、格式转换等 ， 同时apk中不同类型元素的压缩率也不相同 ， 如果使用原始大小作为度量标准 ， 会在包大小治理的整个链路引入较大误差 ， 导致难以抓住瘦身重点 ， 也无法提前精准预判瘦身效果 ， 这对常态治理过程具有非常大的负面影响 。
第一点可瘦身项 ， 是指类、资源、so等元素中的“不合理”项 ， 对其进行改造或优化就可以降低包大小 。 这些可瘦身项细碎并且不易被人工发现 ， 但是累积起来却不容小觑 ， 通过工具化的分析能力可以快速找出这些可瘦身项 ， 一方面提供瘦身指导：为逐步降低包大小提供更多“方向”和“空间” ， 另一方面用来评判：一个功能/业务/团队 ， 在这段时间内减少/增加了哪些可瘦身项 ， 当前是否已经瘦无可瘦 。
第二点归属聚合 ， 是指将apk大小拆解到有效的责任实体 ， 根据app涉及到的研发团队和迭代模式不同 ， 责任实体可以是组织结构中具体的团队 ， 也可以是业务/功能/模块负责人 。 总之 ， 拆解的目的是明确责任 ， 即团队/业务/功能/模块对apk大小的“贡献”分别是多少 。
第三点研发流程 ， 是代码上线的“必经之路” ， 在这个过程中需要具备及时的增量感知 ， 以及超限后的拦截阻断能力 。 只有这样才能实现低（人力）成本持续管控 ， 另外这也是去中心化策略的重要技术支撑 ， 可以避免很多低效的增量定位排查、沟通、跟进等工作 。
第四点辅助工具 ， 是为研发同学对代码进行瘦身提供一系列切实有效的工具 ， 用来提高效率以及降低风险 。 目前在优酷已经沉淀了引用分析、代码归属/热度分析、模块下载/版本号同步查询对比、progaurd对比（mapping、usage）分析、apk信息查询/对比/反编译等共计十几项工具 。
上述技术支撑体系在具体实现上 ， 主要由“分析工具”和“包大小卡口能力“承载 ， 后面会做具体介绍 。
2.3 治理策略
常态化治理模式下 ， 治理策略的核心是去中心化 。 尤其是对于多团队参与研发的app ， 对每个功能最熟悉的人一定是日常直接负责的（团队）同学 ， 因此最高效的方式其实正是“各家自扫门前雪”的分布式治理模式 。 其中阈值划分 ， 是实现分布式治理的第一步 ， 即圈定“每家所负责的范围 ， 以及最多允许存在多少雪” 。 而灵活协作 ， 目的是打造合理、公开、透明、高效、低成本的可持续治理局面 ， 在为业务增长和创新提供更多包大小空间的同时 ， 将整包大小控制在预期范围内 。
分析技术 分析技术 ， 是秉承Byte级“较真儿”精神 ， 以包大小真实占用为指导原则 ， 公平公正童叟无欺 ， 实现对不同颗粒度（元素、功能、业务、团队）的包体积占用度量 ， 并在此之上提供切实有效的可瘦身项分析能力 ， 用于指导和评判瘦身情况 。 先来回答一个问题：分析工具为什么很重要 ， 很重要？
首先 ， 既然要进行包瘦身 ， 那么各种不同的“大小”就如影随形 ， 例如：“xxx模块多大？”、“xx功能/业务占多大”、“最新版本apk相对上个版本增加了1MB ， 不同功能的变更带来的大小变化分别是多少？”、“我今年的目标是将apk减少10MB ， 可以通过哪些瘦身Action来达成目标？” 。 工程领域有几句著名论断：“无度量不改进”、“无度量不管理” ， 包大小分析工具的核心价值之一就是提供这个度量：各种不同颗粒度的度量 ， 小到一个java类、资源、so ， 继而到一个模块（jar/aar）、再到一个独立功能、业务、甚至是团队 。 由此衍生开来 ， 既然有了度量 ， 那么就可以进行有效的责任归属、瘦身目标制定、效果预估等 ， 是不是豁然开朗？

经验总结扩展阅读


上一篇：减肥餐 最容易“翻车”的三种烫发，烫发前建议了解一下，免得烫完后悔

下一篇：油脂栖桐国际：保护好皮肤屏障，做好完美护肤