好久沒有寫博客了,這次準備寫寫我這幾天的研究成果――Android插件化開發框架CJFrameForAndroid。
好久沒有寫博客了,這次準備寫寫我這幾天的研究成果――Android插件化開發框架CJFrameForAndroid。
首先,你需要知道甚么是插件化開發。就拿最多見的QQ來講,在第3個界面動態那里有個管理,點開后可以選擇很多的增植功能,這里騰訊只放了1些網頁利用,那末如果未來想加入1個打飛機游戲,要怎樣做?讓用戶重新安裝嗎,這就是插件化開發所解決的問題。
用1句話來概括插件式開發:你基本上可以理解為讓1個apk不安裝也能夠被運行。只不過這個運行是有很多限制的運行,所以才叫插件否則就叫病毒了。其實在目前淘寶、百度、騰訊、等都有成熟的動態加載框架,包括apkplug,但是它們都是不開源的。
說1下我認為這項技術的難點:1、1個未被安裝的apk正常情況沒法被運行;2、這個apk的資源沒辦法被援用;3、這個apk的界面就算被加載,也沒辦法與用戶交互。
最初查遍了資料,第1點好解決,在Android中有1個dexClassLoad類加載器,大家應當明白了,就是通過反射加載1個類來運行。第2點,網上有兩種方法:可以將插件的資源放到sd卡上通過流的情勢讀取,不過也有人反對說用流讀取會有問題,通配性太差;1種比較好的解決辦法是將apk中的資源復制1份到當前app內,然后就能夠加載了。這類辦法是不錯,但是用戶每下載1次插件就復制1份,長此以往,對空間要求太高了,還有就是第3點也沒辦法解決。而第3點,在github上有1個叫AndroidDynamicLoader的項目,是通過用Fragment做為插件的表現情勢,由于Fragment特殊性(既可以處理邏輯交互又具有與Activity相同的生命周期)。可是Fragment限制性太大了,太過碎片化使得使用起來復雜性太高。直到我找到了1篇360的官方博客,博客給了1種思路:通過代理/拜托模式設計的Application類去動態的改變1個apk所在的環境,實現動態加載的目的。抱著這類思路,我曾想自己去設計1個application類,但是技術有限,太復雜了,因而結合AndroidDynamicLoader的思路與360的思路,我自己設計了1個Activity去代理插件的Activity,因而就有了CJFrameForAndroid.
首先解釋幾個名詞:
APP項目:指要調用插件apk的那個已安裝到用戶手機上的利用。
插件項目:指沒有被安裝且希望借助已安裝得手機上的項目運行的apk。
插件化:Activity繼承自CJActivity,且與APP項目jar包沖突已解決的插件項目稱為已被插件化。
Activity事務:在CJFrameForAndroid中,1個Activity的生命周期和交互事件統稱為Activity的事務。
托管所:指插件中的1個委派/代理Activity,通過這個Activity去處理插件中Activity的全部事務,從而表現為就像插件中的Activity在運行1樣。
CJFrameForAndroid的實現原理是通過類加載器,動態加載存在于SD卡上的apk包中的Activity。通過使用1個托管所,插件Activity全部事務(包括聲明周期與交互事件)將交由托管所來處理,間接實現插件的運行。
1句話描寫:CJFrameForAndroid中的托管所,復制了插件中的Activity,來替換插件中的Activity與用戶交互。
看到這里你應當就明白了,全部框架最核心的部份就是這個托管所。這里給出CJFrameForAndroid中這個托管所的細節代碼:
本框架目前僅僅是1個開發階段,僅僅是實現了插件Activity的運行(原理上來講,動態注冊的廣播也能夠運行),而Service、contentProvider都沒辦法使用,這些都仍在研究中。
在未來的某1天,或許會將這個CJFrameForAndroid插件框架與KJFrameForAndroid快捷開發框架合并,組成1個更完善利用開發框架,對自己說:加油!
●目前僅支持Activity和Fragment,Service,動態注冊的廣播,Activity LaunchMode,注解式開發。
●APP項目和插件項目中,都需要使用到CJFrameForAndroid的jar包。
●在項目中必須加入托管所聲明。
●在開發插件的時候,必須繼承CJActivity;
●在插件的Activity中,1切使用this的部份必須使用that來替換;
●在插件Activity跳轉時,推薦使用CJActivityUtils類來輔助跳轉;
●在插件和APP兩個工程中不能援用相同的jar包;
上一篇 Oracle動態SQL語句
下一篇 java程序員面試喜歡問到的問題