今年的关键字：幸运、充（mang）实（lu）
回首 2023，忙碌，幸运。这两天吃火锅吃太饱，撑着了，故随意总结一番。
扫除历史债务（构建域）
年初，将 1688 的 AGP 插件进行了升级，让 1688 Android 客户端构建侧能支撑热修、插件化以及极小包等能力，构建侧能力基本追齐手淘（上一次升级是近4年前），移除不少构建历史包袱，同时也上线了我们的热修方案。
春：1688 极小包
3月中，经过评估后极小包项目立项，感谢组织的厚爱与信任，有幸成为了项目的PM。在完成项目技术攻坚的同时，也需要设法推动多团队协作，让项目按质按量落地。3月底正式投入，经过两个多月多团队协作·，极小包完成了灰度验证。最终，5月底完成第一次上线交付，6月在处理了厂商账号和登录率等问题后，6月底部分厂商渠道上线，投放至今，表现良好。
欢迎大家体验！！！
麻雀虽小，五脏俱全。小小的极小包包含了完整的主链路业务，所以要协同的业务或产品线同学也很多，在项目过程中会遇到各种资源协同、产品设计、项目节奏等等问题，项目上线前，俺都是如履薄冰。
同一时间公司有非常多的项目，而在这些项目当中，这个项目极可能微不足道。每个人手上都有不少的活儿，能投给这个项目的时间和精力可能没有或者不多，需要体谅、理解，但是更需要争取或者交换到资源，然后安排好协同节奏。极小包陆陆续续有50 ~ 60人直接参与或以帮助协同等方式间接参与，大部分同学是投入1~2天左右、少部分同学会是3 ~ 5天等等，所以如何安排协同节奏，避免空转或等待也异常重要，这些都是隐藏在关键节点后的重要工作。
当人员进入后，可能运营、产品、设计、开发、测试的想法都不一样，例如：运营想更多的新客下单转化及可用的归因方案、产品觉得保留的功能越全越好、设计考虑UI及体验上的提升会带来更多的升级转化、开发觉得历史负担重（要做好可能时间不够）、测试觉得人力不足（改动范围太广）。在这个过程中，每个人都从不同角度去看当前要做的事情，意图对现有的问题进行优化。在讨论和聆听的过程中也能学到很多不同的思考方式，这一点感触很深，很庆幸自己能在这样一个团队中。
面对这些意见或者建议，资源有限，不可能全部采纳，以始为终做抉择：拆解、采纳、妥协、放弃还是后续迭代完成，需要去做沟通，让大家知晓并接受最终的决定，也需要有说“不”得勇气，更要主动承担决策的后续结果以及直面可能遇到的问题。
当然还有其他很多需要注意的，例如：法务、成本、稳定性、体验、渠道、实验等等问题。对产品的最终形态以及交互要心里有数，心里越是清晰，需要的临时调整就越少，糟心事就会越少。当然，不可能事事都在规划之内，项目研发过程中见招拆招也是偶有发生。。。
庆幸能有这样一段试炼经验，感恩组织信任，也感谢来自自己团队内部的支持，少有的几次事情确实不好推动时，总能请到 TL 帮忙周旋协调，中间有很多次开发任务处理不过来的时候，也都能争取到团队内部的协助；感谢师兄的开导与鼓励，无论是技术、项目还是规划，总能给到不少有用的经验；还有几个之前合作过的同学，再次合作时给了很多帮助和建议（尤其是一直合作的测试搭档，以及上一个测试搭档），让我能有更多的精力放在首次合作的同学身上，再次深刻了这样一个道理——合作的过程也是信用积累的过程。
技术方案上就不细讲了，感兴趣的同学可以去看看 Virtual APK。其实，也非常感谢阿里这个大平台，很多方案其他团队或多或少都有类似的方案，所以想用想学就非常方便，会避免重复造轮子陷入太多太多的细节陷阱中。这也是我第一次讲将一个插件化项目送上线，以前对插件化的理解都是“纸上谈兵”，通过实际项目，我对插件化的知识和应用也有了一个比较大的提升。
完整走过了一个APP项目的完整流程，从一个想法到产品的最终交付上线，自己对自己认可也提高了，对技术与业务的关系也有了更多的理解。关于项目推进，这里也推荐一本《从点子到产品：产品经理的价值观与方法论》，关于技术与业务推荐一本《聊聊“架构”》。
夏：Gradle & AGP 升级
在极小包交付第一个版本后，又迎来一个"研发效能"命题。
7月，之前说年初对近4年没有动过的 Gradle & AGP 又做过一轮升级，构建侧在各项能力上追平手淘，构建工具属于是基于手淘的半自建。虽然各种功能啥的都差不多了，但是历史迭代遗留了不少问题，导致每次模块集成都需要花很长的时间，构建成功率也不太乐观，所以团队研发效能评级上，虽然从第三梯队上升到第二梯队，但是想进入第一梯队还是比较难，在经过仔细评估后，团队决定彻底放弃手淘方案，Gradle 从 5.5 升级到 6.1，AGP 从3.4.6 升级到 4.2.2。
Gradle & AGP 升级，不像极小包那样有直接的明显的业务价值，它只是个技术投入。对效能和后续的端技术方案的落地或升级有帮助，效能的帮助很直接，构建可以缩短到原来的50%甚至更低（后面为了快速适配Android 11，避免应用下架，又在构建里做了一堆适配，导致速度又变慢了，这个后续还是要优化一下），构建成功率也能明显。
9月份，完成了Gradle & AGP 的整体迁移达到了效能的明显提升的效果，同时也带来了包体上的收益，并且在此过程中也为一个比较有影响力的内源项目贡献了些代码。另外在调研TheRouter的时候，也贡献了几行代码，在与涛哥的交流及日常看TheRouter答疑群时，看得出来涛哥对TheRouter的莫大付出，说实话如果纯粹是为了开源，这种付出难以理解，只能敬佩。虽然最终由于各种原因暂时没有用上有些遗憾，但作为端架构的一员，必须考虑项目现状追求合脚——好的不一定是适合自己的。
技术上，关于 Gradle & AGP 的书籍还没有看到有一本特别好的书。大部分都是入门级的，教你怎么配置，最多教你怎么理解，网上东平西凑会有一些干货，但目前还没有遇到一本能像《Android开发艺术》《深入理解 Android 》《Android 内核剖析》类似的成体系的关于 Gradle & AGP 高级应用的书籍。这也是市场空，希望未来有机会我能写一本（幻想一下），没有这样的书籍也可能是Gradle & AGP 开发和应用开发不一样，除了需要掌握比较多的应用开发知识外，还需要其他的综合知识，而且都需要一些深度。例如：被讲烂了的ASM插桩，除了要有JVM知识，想做点东西出来还需要补充非常多的其他知识。如果只知道一个ASM，也写不出ARouter，想写ARouter又得去学注解处理器等等，更何况渠道包构建、签名、包体优化、调用堆栈分析、热修复、插件化等等，没有一个是仅仅靠熟悉Gradle & AGP 就能完成的，内容复杂繁多，思路五花八门，各有各的门槛。另外，Gradle 版本在疯狂迭代，AGP 更是如此，而且AGP在迭代过程中的改动还非常大。尽管如此，其实只要熟悉其中一个版本，其他版本也会很快得心应手，毕竟构建的总体流程没什么变化，所以未来市场了要是有那么一款介绍低版本 AGP 的进阶书籍，大家可以放心阅读，肯定能用上的，熟悉了以后 AGP 更像是一种思考方式。
通过这次升级，项目中之前所有的构建历史包袱基本都干掉了，个人对 AGP 各个版本的差异也有了更细致的了解，通过阅读其他内源或开源项目的 AGP 插件，也了解了更多关于 AGP 插件如何设计能更高性能更好兼容性的设计思路，推荐开源项目：Atlas、ByteX。
秋：android 11 适配
10月，刚做完Gradle & AGP 的升级，又接到了 Android 11 升级的任务，太忙了~~~。
马不停蹄地有去调研 Android 11 的升级事宜，时间紧任务重，升级慢了会影响版本发布。
还好对这个事情整个端研发都非常认可、积极参与。最终在项目推动过程中也没有什么大的阻力，只需要解决一些技术性问题即可。由于时间紧迫，并且一些二方库没法短时间内完成升级上线，所以我选择了在构建脚本中加了一些任务去完成这些二方库的适配，这也导致了构建任务时长又被拉长了不少。
在解决了几个高风险问题、确保升级进展无太大风险并在改造进入首次灰度时，我也从项目中主动脱离了出来，并去了更大的战场。
这个项目中感受比较深有如下两点：
- 有时不得不做一些“恶心”的技术选项，例如紧急情况下使用构建做适配，导致构建的耗时之痛又出现在团队中了。
- 确实有同时陷入优先级都很高的多个项目上，将一件事从头做到位确实是很“厉害”的事情，但有时也要学会割肉做些放弃。
冬：极致包体优化
更大的战场在这里。规划、推动、落地极致包体优化方案，包体目标设置在了一个几乎不太可能完成的指标（好在经过一个半月的日月星辰，看到了希望），没有一丝喘气机会~
这次项目对业务的帮助是非常巨大的，对1688端架构也是非常大的挑战，一起期待更快更小的 1688 吧。
总结
通过这两年的架构治理，1688 端架构的确实有了明显进步。启动任务的收拢、冗余渲染方案的下线、架构分层改造、稳定性治理、构建全面升级等等，抛弃了众多历史包袱。同时，在解决各类问题时也积累了不少技术，从手淘搬运工走向了师淘长技自主建设，点滴的积累走到现在发生质变。
今年工作上的事情，基本以项目为单位，一边负责技术攻坚一边推进项目落地，不累是骗自己。在技术攻坚和项目推进的路上，也收货颇多，也非常感恩在工作5年之际能有这样的机会成长和锻炼。
忙碌的，也是幸运的，亦知道“千里马常有，而伯乐不常有。”人才或者技能大多数情况下并非稀有不可替代，机会才是稀有的，保持谦卑，厚积薄发，机会不一定总会给有准备的人，但是有准备的人可以更好把握好来之不易的机会，所以年终总结如果一定要用一个词来总结，那应该是“幸运”。
规划。。。
随想随写，不喜勿喷。
我组招人，base 杭州，有意私我。
