在學習模組化的過程中，也在不斷思考，同時和一些模組化方案的作者進行了一些交流，記錄下自己的一些心得體會。

為什麼要使用模組化，使用什麼樣的模組化？

我認為使用模組化的原因，從程式碼層面考慮精髓就是解耦合，從工程專案角度考慮，是為了分組協同，隔離，甚至動態釋出這些。所以重點來了，在考量是否需要使用模組化的時候，得首先考慮，程式碼是否耦合嚴重，或者是否需要規模分組開發，如果是個人開發者，或者超小團隊，引入模組化方案，可能帶來效率的降低，並且可能引入的bug，可能比帶來的收益都要低。其次，使用什麼樣的模組化。前段時間，阿里開源了Atlas，然後對於大部分中小型專案而言，Atlas並不是一種好的選擇，過於複雜和厚重，可能小型的路由方案，就可以實現全部需求。引入大型專案的解決方案，反而帶來效率的降低。

模組化框架該如何設計

在瞭解模組化的過程中，除了走讀各種方案程式碼，自己寫個簡單的路由框架以外，我也在思考模組化方案的設定思路。

• 當前兩種方案的優劣

在之前的文章中也提到，當前的模組化方案中，一種是靠編譯期的註解處理處理器生成路由表。一種是靠程式碼執行時的反射，在程式碼執行階段，通過處理註解，取得路由跳轉關係，比如LiteRouter。 相比前一種方案，個人覺得這種方案，還是存在一些問題。首先，反射存在效能開銷，這類方案基本都是仿照Retrofit的思路在設計，但是Retrofit畢竟是個網路請求方案，反射帶來的效能開銷造成的時間，和網路請求的時間相比，幾乎可以忽略不計，但是，對於元件跳轉的場景，這部分效能開銷，可能多少會有一些影響。不過這種設計思想的精妙的確值得肯定。

• 模組化設定時的細節

之前Arouter的作者，在演講中也說了，模組化方案，作為一個App的底層架構，應該需要足夠的穩定，我個人也很認同此觀點。這段時間看了幾種模組化方案的原始碼細節，其中的一些細節，印象深刻。

比如對 Activity 細節的處理。

 // Set flags.
                int flags = postcard.getFlags();
                if (-1 != flags) {
                    intent.setFlags(flags);
                } else if
 
 (!(currentContext instanceof Activity)) {    // Non activity, need less one flag.
                    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
                }

比如 對執行緒的處理

// Navigation in main looper.
                new Handler(Looper.getMainLooper()).post(new Runnable() {
                    @Override
                    public void run() {
                        if (requestCode > 0) {  // Need start for result
                            ActivityCompat.startActivityForResult((Activity) currentContext, intent, requestCode, postcard.getOptionsBundle());
                        } else {
                            ActivityCompat.startActivity(currentContext, intent, postcard.getOptionsBundle());
                        }

                        if ((0 != postcard.getEnterAnim() || 0 != postcard.getExitAnim()) && currentContext instanceof Activity) {    // Old version.
                            ((Activity) currentContext).overridePendingTransition(postcard.getEnterAnim(), postcard.getExitAnim());
                        }
                    }
                });

比如在註解編譯器中完備的日誌系統等。

這些設計，雖然都是細小的點，但是在對於增加程式碼穩定性和可維護性方面，均有很多提升。

通過這些點，我個人的體會是，一個框架的設計和功能設計還是有很大不同的。框架的設計，除了框架功能的完成，容錯，異常，錯誤收集這些點同樣應該在優先順序比較高的位置。

模組化的衍生

在思考模組化的過程中，也在想是否和其他方案結合。記錄下思路。當然都是個人見解和思路。

• 與配置中心（應用中心）結合

功能複雜的App，每個功能入口的順序可能會不斷變化，如果純用native實現功能的話，Activity的程式碼可以預埋在本地，同時生成路由關係，在合適的時機從伺服器拉取配置，配置中攜帶了功能模組的圖示等資訊和一個URL，然後根據URL完成功能跳轉。可以實現一個比較最簡易的動態化方案。

• 運用跳轉攔截進行降級

如果跳轉路徑Activity中發生了Crash，目標Activity中資料顯示異常時候，可以通過一些策略觸發降級，通過H5 App的方式來實現功能。之前看過一一些自動恢復的框架，可以通過這個框架和路由方案的集合設計一種思路，當通過URL跳轉出現Crash時，把自動恢復的流程替換為直接通過URL進行降級，開啟web容器，啟動H5 App或者web的錯誤頁面，增強App的容錯和體驗。

• 。。。

如今模組化方案，已經初步成熟，並且不斷演進之中，相信很多值得探索的地方，隨著一些新方案的出現和Android系統的升級，對於模組化方案，後續海需要不斷學習研究深入。