很多的元件化文章通常是教授技術上的經驗，但是在實際元件化中，尤其一個老專案進行元件化改造時，最為耗時的卻是業務程式碼的解耦合工作。這部分工作並不高階，由於很多的程式碼經過不斷的改動，並且改動人員水平參差不齊，解耦程式碼更多的時候是體力活。那麼怎麼高效的完成這部分無聊的工作，進入下一個高逼格的技術點呢？

一、基礎程式碼

這部分沒什麼好說的，前置工作，在前三講中應該已經做出了我們自己的基礎庫，之後在解耦過程中，若我們發現基礎共用的程式碼，隨時更新我們的庫，在前期我們改動頻繁的時候，我建議使用非正式版的方式引入基礎庫。

//podfile中
pod 'CSDNModuleExample', :git => 'git地址'
 
 , :branch =>'master'

這樣我們不必每次發版，git更新我們拉一下pod即可。
PS：此庫的原則上程式碼不應太多，而且複用性是非常高的，就算做一個新的完全不同的app，也可以直接拿來用的。

二、公共業務庫

這部分包含公共業務部分，根據業務解耦的難度，這部分可能會很多，一般來說，推送、埋點、登入、網路請求、業務工具等隨app變動的部分應放在此處。
這部分可以單獨分割為多個庫，比如網路請求一個庫，登陸一個庫，但是前期可以粗暴的都放在一起，後期再去優化，當然如果時間和業務需求都很配合，那麼一開始就乾淨的解耦獨立是的最理想的。

三、檔案結構分離各業務

• 做完上述兩個庫，那麼我們的工程中應該只剩下平臺功能（App的結構）和各個業務了，當然可能不乾淨，我們後面隨時拆即可，我們這時候就可以真正的開始解耦合業務了。
• 那麼我們這時候應該建立各業務的資料夾，將相關的程式碼進行粗暴的分類，畢竟我們元件化的目的就是要分離各業務線，先粗暴，再細緻（並不是獨立工程，只是在原有的工程用不同的資料夾分類）。
• 當我們分類完成後，我們可以通過刪除相關的業務，來處理編譯報出的耦合問題，根據錯誤，在進行更為精細的分類，最終我們剩下的問題應該絕大多數是耦合問題。

四、業務解耦幾點規範

接下來我們來處理業務耦合的問題，我們主要會碰上如下幾個方面的問題：

1、model

model分兩種情況：

• 共用=>放到業務庫
• 不共用=>業務線自己存放

下決心來判斷到底共不共用，如果model超出了自己model應有的功能，則需要將該功能分離出去，淨化model本身。對於巢狀的model，我們也遵循是否共用的原則來進行抉擇。這部分難度最小，改動複雜度也不太高。

2、view

同model，要給出是否共用的結論，然後做相應處理。
常見的問題情況：view中使用了某個業務獨有的model或view，則原則上分為業務部分，其他的業務方自己提供自己的相關view。若該view共用的太嚴重，裡面又有獨有的model等，等需要考慮將model等下沉，整串葡萄都要下沉。
通過優化程式碼進行解耦是最優解。

3、VC

同樣的，共用的下沉。
有問題的通常是無法下沉的公共VC，無法下沉的原因也多如裡面的view或model為業務線獨有，或者裡面業務連結多個業務。
這部分問題，只能硬著頭皮進行程式碼改造，重新設計，model部分去除資料汙染，view部分獨立view。

PS：VC的呼叫不算在解耦的內容中，這部分作為元件間相互呼叫的部分，我們後續會處理。

五、整理

上述工作，各個業務應該分配給各個業務的負責人，分別整理出自己業務部分的不好處理的部分，理論上，大部分都會指向相同的問題檔案，而這些部分通常來說都是要進行程式碼改動的，加油，解決完這些難啃的骨頭，我們元件化的路將變得非常光明。
這部分如果遇上很多問題，將會花費相當大的精力和時間。

六、元件呼叫和appDelegate改造

我們解決了上述問題後，我們將面對的是元件間的呼叫和appDelegate的改造，在之後我們就可以獨立各業務工程了。我將在之後的章節中介紹如何進行元件間呼叫。