一眨眼，2018年就剩下最后一天了的，明天即將邁入2019年。
今天在家躺著回顧一下2018年，試著去展望一下2019年。
2018年過(guò)的有點(diǎn)太快了的
這幾年朋友圈比較流行一個(gè)段子，一到年底就吐槽去年的plan，現(xiàn)在發(fā)現(xiàn)都只剩下一個(gè)“p”，因?yàn)楸容^“l(fā)an”。
自己看了一下之前寫(xiě)的 《回顧2017，展望2018》 ：
2018，希望可以和小伙伴們一起把項(xiàng)目理得更像一個(gè)正常的項(xiàng)目，把之前的坑給趟過(guò)去！同時(shí)希望自己能腳踏實(shí)地的學(xué)點(diǎn)東西，提高代碼質(zhì)量，拓展一下自己的思維！
target 23 升級(jí)到了 target 26
想了一想，和小伙伴們一起把項(xiàng)目理得更像一個(gè)正常的項(xiàng)目 ，我們真的努力了，年末的時(shí)候，把項(xiàng)目從之前的 target 23 升級(jí)到了 target 26，這對(duì)于我們項(xiàng)目而言算是一個(gè)很大的跨度，讓我們可以慢慢的擺脫掉由于之前留下來(lái)的坑導(dǎo)致項(xiàng)目無(wú)法同步升級(jí)相關(guān)依賴的尷尬局面，比如support包版本等。
2.14.1 升級(jí)到了 4.1
但在適配 target 26 之前，還是要表?yè)P(yáng)一下自己，年初的時(shí)候，把項(xiàng)目 gradle 從 2.14.1 升級(jí)到了 4.1，不僅為后續(xù)第三方庫(kù)同步升級(jí)提供了可能性，而且還給整個(gè)團(tuán)隊(duì)提高了開(kāi)發(fā)效率，因?yàn)榻鉀Q了gradle編譯問(wèn)題之后，項(xiàng)目終于支持了 Instant Run。以前只能每次十幾分鐘的全量編譯，到現(xiàn)在只需要點(diǎn)一下??，分分鐘立馬可以看到運(yùn)行效果。
dex 分包
項(xiàng)目架構(gòu)上，去年年底小組里面制定過(guò)一些任務(wù)，自己也在年初的時(shí)候?qū)崿F(xiàn)了一部分，比如統(tǒng)一了圖片加載框架，網(wǎng)絡(luò)請(qǐng)求框架等。
但是一年過(guò)去了的，現(xiàn)在想想離去年的目標(biāo) 和小伙伴們一起把項(xiàng)目理得更像一個(gè)正常的項(xiàng)目，還有很長(zhǎng)的路要走。當(dāng)然我可以找借口說(shuō): 項(xiàng)目過(guò)于老化，過(guò)于龐大了的，根本無(wú)法入手。 雖然這確實(shí)是個(gè)尷尬的不爭(zhēng)的事實(shí)，然而現(xiàn)實(shí)卻非常殘酷的，當(dāng)我們停下調(diào)整項(xiàng)目結(jié)構(gòu)的腳步，上半年的時(shí)候項(xiàng)目突然無(wú)法構(gòu)建了的：main dex 在開(kāi)啟了分包策略之后依舊有報(bào)編譯錯(cuò)誤 65535，整個(gè)團(tuán)隊(duì)成員都沒(méi)法工作了的，非常非常棘手。當(dāng)時(shí)調(diào)研了之后，采用了插件手動(dòng)分包，踢出一些我們認(rèn)為不應(yīng)該放在主dex的class，從而臨時(shí)性的解決了主dex分包失敗問(wèn)題。當(dāng)時(shí)還寫(xiě)了一篇文章去分析主dex的生成過(guò)程 :《Android multidex 主dex是怎么來(lái)的？》。然而這僅僅是臨時(shí)解決方案，并沒(méi)有從項(xiàng)目架構(gòu)上去解決問(wèn)題。。。這事情就暫時(shí)擱淺掉了的！！！
熱修復(fù)
說(shuō)到dex分包 ，想到了今年另外一個(gè)技術(shù)突破：熱修復(fù)。在調(diào)研技術(shù)方案的時(shí)候，優(yōu)先考慮的是《Tinker》，然而結(jié)局又是給了我狠狠一巴掌，剛才提到的主dex已經(jīng)爆掉的問(wèn)題，而Tinker又要求必須放在主dex，這就限制了后續(xù)“主dex的靈活性”。另一方面是因?yàn)轫?xiàng)目采用的是Dexguard 混淆，Tinker 不支持。所以也就放棄了這個(gè)方案。最終選擇了美團(tuán)的《Robust》，Robust又不像Tinker那樣提供下發(fā)patch包的平臺(tái)，所以第三季度末第四季度初又開(kāi)始著手實(shí)現(xiàn)整個(gè)熱修復(fù)前后臺(tái)。不過(guò)又面臨新的挑戰(zhàn)，大家都知道Robust 需要mapping文件，而多渠道打包，打出來(lái)的每個(gè)渠道都有自己的mapping文件，patch管理平臺(tái)又不想針對(duì)渠道來(lái)下發(fā)。那該怎么辦呢？
多渠道打包
于是乎，多渠道打包又是個(gè)棘手問(wèn)題，調(diào)研之后決定采用《walle》，這樣以來(lái)，多渠道打包最終只有一份mapping文件，不僅熱修復(fù) 方案得以推行，而且新的打包方案只需要十幾分鐘遠(yuǎn)超過(guò)之前耗時(shí)兩個(gè)多少小時(shí)的傳統(tǒng)打包方式效率，一箭雙雕啊。
團(tuán)隊(duì)所有成員使用kotlin
另一方面，帶領(lǐng)整個(gè)團(tuán)隊(duì)開(kāi)始全面使用 kotlin ，但是路還很長(zhǎng)，編程思維還在慢慢切換適應(yīng)過(guò)程中。
2019年 面臨更大挑戰(zhàn)
回顧2018年，會(huì)發(fā)現(xiàn)自己的工作重心主要是集中撲在了項(xiàng)目架構(gòu)上，技術(shù)挑戰(zhàn)比較大，業(yè)務(wù)上相對(duì)少一些，很多零碎時(shí)間也都是在幫組里同事分析bug，提供解決思路。整體也算是：收獲滿滿，給自己打一個(gè)80分吧。
展望2019年，不變的話題，還是如何提升自己的技術(shù)能力，讓自己的技術(shù)儲(chǔ)備能跟上技術(shù)革新。另一方面對(duì)于項(xiàng)目已有舊的代碼如果能調(diào)整到理想狀態(tài)，那么我想又是一大驚喜。
