一眨眼，2018年就剩下最后一天了的，明天即将迈入2019年。
今天在家躺着回顾一下2018年，试着去展望一下2019年。
2018年过的有点太快了的
这几年朋友圈比较流行一个段子，一到年底就吐槽去年的plan，现在发现都只剩下一个“p”，因为比较“lan”。
自己看了一下之前写的 《回顾2017，展望2018》 ：
2018，希望可以和小伙伴们一起把项目理得更像一个正常的项目，把之前的坑给趟过去！同时希望自己能脚踏实地的学点东西，提高代码质量，拓展一下自己的思维！
target 23 升级到了 target 26
想了一想，和小伙伴们一起把项目理得更像一个正常的项目 ，我们真的努力了，年末的时候，把项目从之前的 target 23 升级到了 target 26，这对于我们项目而言算是一个很大的跨度，让我们可以慢慢的摆脱掉由于之前留下来的坑导致项目无法同步升级相关依赖的尴尬局面，比如support包版本等。
2.14.1 升级到了 4.1
但在适配 target 26 之前，还是要表扬一下自己，年初的时候，把项目 gradle 从 2.14.1 升级到了 4.1，不仅为后续第三方库同步升级提供了可能性，而且还给整个团队提高了开发效率，因为解决了gradle编译问题之后，项目终于支持了 Instant Run。以前只能每次十几分钟的全量编译，到现在只需要点一下⚡️，分分钟立马可以看到运行效果。
dex 分包
项目架构上，去年年底小组里面制定过一些任务，自己也在年初的时候实现了一部分，比如统一了图片加载框架，网络请求框架等。
但是一年过去了的，现在想想离去年的目标 和小伙伴们一起把项目理得更像一个正常的项目，还有很长的路要走。当然我可以找借口说: 项目过于老化，过于庞大了的，根本无法入手。 虽然这确实是个尴尬的不争的事实，然而现实却非常残酷的，当我们停下调整项目结构的脚步，上半年的时候项目突然无法构建了的：main dex 在开启了分包策略之后依旧有报编译错误 65535，整个团队成员都没法工作了的，非常非常棘手。当时调研了之后，采用了插件手动分包，踢出一些我们认为不应该放在主dex的class，从而临时性的解决了主dex分包失败问题。当时还写了一篇文章去分析主dex的生成过程 :《Android multidex 主dex是怎么来的？》。然而这仅仅是临时解决方案，并没有从项目架构上去解决问题。。。这事情就暂时搁浅掉了的！！！
热修复
说到dex分包 ，想到了今年另外一个技术突破：热修复。在调研技术方案的时候，优先考虑的是《Tinker》，然而结局又是给了我狠狠一巴掌，刚才提到的主dex已经爆掉的问题，而Tinker又要求必须放在主dex，这就限制了后续“主dex的灵活性”。另一方面是因为项目采用的是Dexguard 混淆，Tinker 不支持。所以也就放弃了这个方案。最终选择了美团的《Robust》，Robust又不像Tinker那样提供下发patch包的平台，所以第三季度末第四季度初又开始着手实现整个热修复前后台。不过又面临新的挑战，大家都知道Robust 需要mapping文件，而多渠道打包，打出来的每个渠道都有自己的mapping文件，patch管理平台又不想针对渠道来下发。那该怎么办呢？
多渠道打包
于是乎，多渠道打包又是个棘手问题，调研之后决定采用《walle》，这样以来，多渠道打包最终只有一份mapping文件，不仅热修复 方案得以推行，而且新的打包方案只需要十几分钟远超过之前耗时两个多少小时的传统打包方式效率，一箭双雕啊。
团队所有成员使用kotlin
另一方面，带领整个团队开始全面使用 kotlin ，但是路还很长，编程思维还在慢慢切换适应过程中。
2019年 面临更大挑战
回顾2018年，会发现自己的工作重心主要是集中扑在了项目架构上，技术挑战比较大，业务上相对少一些，很多零碎时间也都是在帮组里同事分析bug，提供解决思路。整体也算是：收获满满，给自己打一个80分吧。
展望2019年，不变的话题，还是如何提升自己的技术能力，让自己的技术储备能跟上技术革新。另一方面对于项目已有旧的代码如果能调整到理想状态，那么我想又是一大惊喜。
