最近在研究Android應用的外掛化開發，  外掛化都是在解決以下幾個問題：

本章我們來研究最後一個問題：資源共享與衝突。在《Android應用程式外掛化研究之AssertManager》中，我們實現了載入外掛apk中資源問題，實際上我們是單獨建立了用於訪問外掛資源的AssertManager和Resource物件，即，外掛獨立使用一個資源管理器，這樣外掛宿主之間無法共享資源。

資源共享

如果需要宿主、外掛之間使用同一套資源管理器，那麼我們需要將外掛的資源路徑新增到宿主的AssetManager中。
我們知道，apk包括程式碼和資源，在apk編譯過程中，dex工具將程式碼打包成.dex檔案，資原始檔會由aapt工具生成對應的ID，aapt在打包的時候組織成resources.arsc檔案（詳細參考： 

nt anim pop_dialog_in 0x7f040000
int anim pop_dialog_out 0x7f040001
int anim slide_left_in 0x7f040002
int anim slide_left_out 0x7f040003
int anim slide_right_in 0x7f040004
int anim slide_right_out 0x7f040005
int anim update_loading_progressbar_anim 0x7f040006
int array indicator_tab_icon 0x7f050001
int array indicator_tab_titlt 0x7f050000
 

現在問題來了，宿主apk和外掛apk是獨立編譯出來的兩個獨立的apk，那麼其中就有資源ID相同的情況出現，從而產生資源ID衝突。如何解決這個問題？看了一些開源框架，解決的辦法就是修改資源ID的PP段，大體有兩種做法：

修改aapt原始碼，定製aapt工具編譯期間修改PP段。

DynamicAPK的做法就是如此，定製aapt，替換google的原始aapt，在編譯的時候可以傳入引數修改PP段：例如傳入0x05編譯得到的資源的PP段就是0x05。個人覺得這個做法不是太靈活，入侵了原有的開發編譯流程，不好維護。

修改aapt的產物，即，編譯後期重新整理外掛Apk的資源，編排ID。

前面說過apk編譯之後會生成ID以及對應的索引表resorce.arsc，那麼我們能不能後期修改相關ID及索引表呢？答案是肯定的，個人比較贊同這種思路，不用入侵原有編譯流程。

結尾：外掛系列文章到此結束了，如果你從第一章開始看到此處，你應該明白外掛化要解決的問題、實現的思路、要掌握的技術，如果你理解完這5篇文章，你應該有能力寫出一個簡單的外掛方案了。文章重在點明思路，實踐才是最重要的，關於實踐我們要做的還有很多很多。