筆者從 2016 年初就因為公司業(yè)務(wù)需求轉(zhuǎn)戰(zhàn) android sdk 開發(fā)， 應(yīng)用插件化技術(shù)將公司 android sdk 重新翻版。先來說說需求。
由于筆者所在一家創(chuàng)業(yè)公司， android sdk 實際運營時間并不長， 處于業(yè)務(wù)成長階段， 經(jīng)常會面對各種需求更改以及運營通道穩(wěn)定性等個方面的問題。由于種種的不穩(wěn)定性， 會導(dǎo)致 sdk 可能會經(jīng)常出現(xiàn)小規(guī)模修改的問題， 用戶對這種行為當(dāng)然是非常不滿意的了?？梢韵胂?，每一次 sdk 更新商務(wù)部門的同學(xué)要扛著多少用戶口水去和用戶商談，而技術(shù)部門又要承受到少商務(wù)部門同學(xué)的白眼。
為了徹底解決這種現(xiàn)狀， 從 16 年初我就開始正式介入 android sdk 重新開發(fā)這邊的工作。 需求 (1) 很明確， 就是要能夠做到 一次對接。介紹一下這個需求， 一次對接， 對于正常的 sdk 開發(fā)來說是最基本的需求， 因為 sdk 就應(yīng)該處于長期穩(wěn)定的狀態(tài)， 要不然用戶不太愿意使用。 可是這對我們公司的現(xiàn)狀來說是致命的， 恰恰是最基本的我們保障不了。為了能夠留下為數(shù)可憐的那些用戶們，一定要做些事情。需求 (2) 能夠做到及時 升級。 當(dāng)然這個 升級 的需求就是針對我們自己的現(xiàn)實狀況， 產(chǎn)品處于成長期迭代的功能多少都會有。
主要的需求就是這兩個。 從技術(shù)的角度仔細去分析這兩個需求， 其實就是一個需求。 就是做 sdk 的 熱更。筆者之前從事的是 cocos2d-x 游戲開發(fā)， 對 熱更 不可謂不熟。對于移動領(lǐng)域的 app 開發(fā)熱更技術(shù)也都是了解的， 不過都是建立在腳本語言基礎(chǔ)上的。 如大家經(jīng)常提及的 cocos2d-x/u3d lua/js, android/iOS h5等， 這些都有成熟的方案做參考， 而當(dāng)時擺在我面前的卻是翻閱了所有搜索引擎都沒找到先例的問題。經(jīng)過一番苦思冥想之后， 從自己的記憶中提取到了一個片段 - 插件化。
15 年年底的時候， 快放假那段時間翻閱 github, 看到了一個很簡明的 android 插件化框架 PluginMgr。果斷翻閱了當(dāng)時能找到的關(guān)于 插件化 的所有技術(shù)文章， 看懂看不懂的都閱讀一邊。 最終還是選擇了 PluginMgr。 我需要一個只需要支持 android activity 的插件化框架就可以了，另外，在 sdk 中使用也不能體積太大。它能滿足我目前的所有需求。 但是缺點卻也很明顯， 作者當(dāng)時已經(jīng)在開發(fā)新的插件化框架了， 并沒有太多的時間去做維護和更新， 這意味著我自己需要能夠把控這個框架，這讓我一度很遲疑。 經(jīng)過一段時間后， 發(fā)現(xiàn)自己能夠完全掌握所需要的技術(shù)棧。于是開始動手， 新版 sdk 框架部分開發(fā)大概一周左右，然后另一位同事加入， 幫我開發(fā)我們 sdk 業(yè)務(wù) apk。
業(yè)務(wù) apk 的開發(fā)是一個正常的 android 項目， 插件化框架對他開始就是個黑匣子， 他不需要關(guān)心。 在后來實際上線的時候， 我提供了一些 宿主 和 插件 交互的 api 給他替換掉以前的一些 api 調(diào)用就可以了。 最后索性將這部分封裝做的徹底了點， 讓他自己去調(diào)試自己的 業(yè)務(wù) apk, 成功了就可以直接發(fā)布。
而我這邊需要做的前期工作就是把 PluginMgr 做一些定制化的修改， 并修復(fù)一些原本的 bug。 然后就是做動態(tài)更新部分的， 這很好做， 完全可以把以前做過的 熱更 部分拿過來做相應(yīng)的改動就好了。 只不過我需要面向的是 更新 apk, 而不是原來的一個加密后的 腳本壓縮包。
