稳定性、性能、包大小，在移动端基础用户体验领域“三分天下”，是app承载业务获得稳定、高效、低成本、快速增长的重要基石。其中，包大小对下载转化率、拉新拉活成本等方面的影响至关重要，这在业界已经成为共识，近年来头部app针对下沉市场的极小包策略，更是将包大小的价值提升到了极致。优酷在Android包大小领域，有长达5年的持续投入、实践和积累，尤其是在近2年逐步进入低成本可持续治理的健康状态。现将这些思考、方案设计、技术建设、治理实践统一汇总整理成文并分享出来，希望能够帮助更多同学在所负责或参与的app中，更好的进行包大小治理。本文聚焦于整体治理思路，以治理实践为依托，讲述瘦身技术、治理模式、治理策略，以及背后的思考与取舍。
然后，我们需要给App设立路由跳转，所有的界面跳转都需要通过路由来分发，如果我们匹配到需要跳转到有bug的这样一个新功能时，那我们就不跳转了，或者是跳转到统一的异常正处理中的界面。如果这两种方式都不可以，那就可以考虑通过热修复的方式来动态修复，目前热修复的方案其实已经比较成熟了，我们完全可以低成本地在我们的项目中添加热修复的能力，当然，如果有些功能是由RN或WeeX来实现就更好了，那就可以通过更新资源包的方式来实现动态更新。而这些如果都不可以的话呢，那就可以考虑自己去给应用加上一个自主修复的能力，如果App启动多次的话，那就可以考虑清空所有的缓存数据，将App重置到安装的状态，到了最严重的等级呢，可以阻塞主线程，此时一定要等App热修复成功之后才允许用户进入。
App Crash对于用户来讲是一种最糟糕的体验，它会导致流程中断、app口碑变差、app卸载、用户流失、订单流失等。相关数据显示，当Android App的崩溃率超过0.4%的时候，活跃用户有明显下降态势。根据统计2021年初我们的Crash率为5%，大量的研发时间用于定位和解决用户反馈、用户投诉，crash治理刻不容缓。通过去年的大量实践治理，我们app的Crash率降低并且稳定在0.02%，在此做一些总结和分享，希望能为其他团队提供经验和启发
越来越多的业务需求都有统一的业务诉求，按照传统的方式，在开发、测试、维护上的成本都是乘以N的，体验也很难做到一致性，特别是复杂的业务，实现成本高，导致功能不能很快的上线，各端侧对齐存在成本，综合来看，这样或者类似的业务基于研发效率等考虑，选择用跨平台的实现方式是非常有必要的。
AIoT行业发展势头日益迅猛，各大云厂商也在构建各自的AIoT生态，设备接入量也将作为各大厂商实力衡量的重要指标。AIoT野蛮生长过程中，碎片化的现象已日益凸显，因此去"碎片化"的呼声日益高涨。如何建立一个行业认同度高、生态丰富的统一标准化AIoT平台，也成为行业朝万物互联方向迈进中急需解决的问题，这也将成为衡量AIot能力的领域重要指标。
技术思考本质还是结构化思考，所以常见的结构化思考方法也是适用的。这也是大家会看到很多技术架构师都会用一些方法论去分析问题的原因。但这里我不是重新去论述这些常见的技巧，而是分享从技术实战中得到的一些思考方法，为此我分为了技术架构设计的方法和技术Leader的思考方法两类。
技术Leader是一个对综合素质要求非常高的岗位，不仅要有解具体技术问题的架构能力，还要具备团队管理的能力，更需要引领方向带领团队/平台穿越迷茫进阶到下一个境界的能力。所以通常来说技术Leader的技能是虚实结合的居多，繁杂的工作偏多。为此我把自己在工作中经常用到的思考技巧也做了一个整理，算是对《关于技术能力的思考和总结》中提及第三阶段的补充。
从技术岗转型管理岗的开发者：首先，要明白人是最无法预知的因素，需要适当抛弃做开发者时的编码思维；其次，你要对整个团队的人和事负责，而不是只要自己走得快，不管他们有没有跟上，这个问题技术人很容易产生；最后，就是听别人的故事，走自己的路，时刻保持清醒
数字空间相当于对物理空间的复刻，需要尽可能多地将物理世界的信息挪到数字世界里。当然，它不止对物理事件进行复刻，更要将真实世界产生的行为和互动信息都在数字空间内进行重塑，包括人与人之间的交互行为。