子產品化與解耦簡述

本文主要講述了在ios開發過程中，子產品化工程架構的一種組織方式，本文主要講述基于<code>cocoapods</code>來做子產品化的方案，詳細講述了ios開發怎麼進行子產品劃分的内容，主要會在以下方面做闡述：

為什麼要做子產品化

子產品設計原則

子產品化開發有哪些優點和缺點

解耦與通信

我們都知道最基本的代碼設計原則：“don’t repeat yourself!”，每一個工程都會有自己的架構，即使你是剛入門的開發者，寫幾天代碼也會發現要把一些常用到的重複代碼單獨拿出來放在一個叫<code>common</code>的地方，實作代碼複用。這樣看來每個開發者其實都或多或少的做過架構方面的事情，每個團隊至少有1~2個人在做這樣的事情。

說道app代碼架構，記得<code>samurai</code>的開發者郭虹宇在群裡說過這段精辟的話，引用一下:

一派是說app開發并不需要什麼狗p架構，第二派說我們有自己nb的架構，第三派說隻要子產品化夠好，每個子產品應該有自己的架構。

這三個觀點的出發點，我覺得也比較好了解，第一種應該是一些個人開發者，個人能力很強，經常一個人很快搞出來一個app，他的映像中不需要弄太多的框框框住自己，但是其實他也是有一套自己的架構的。第二派應該是一些公司或者大公司，有一套nb的架構對于團隊的意義就比較大了，可以保證穩定疊代，保證規範和持久可維護性。第三派應該是bat這樣的有很多bu的超級公司，或者一些先進的開源開發者們，子產品化能夠更好的實作跨app的代碼和功能的複用, 能夠更好的共享資源，避免重複造輪子。

那麼為什麼要做子產品化？已經很明顯了，子產品化的代碼架構最屌，不信，看看蘋果的架構怎麼做的，你就明白了。

既然子產品化最屌，那怎麼才能做好project的子產品化拆分呢，哪些代碼應該被放到一個子產品？這裡分享一些我的經驗。

越底層的子產品，應該越穩定，越抽象，越具有高複用度。

這一點，目測大家應該比較認同，越是底層的sdk，就應該越穩定，穩定的最直覺表現就是api很久都不用變化，所有的變化因子不要暴露出來，避免傳遞給依賴它的子產品。但是要做到設計一套api很久都不用改變，那麼就需要設計的時候能越抽象, 即需要我們抽象總結的能力。

穩定性 還有一個特點就是會傳遞，比如 b 子產品依賴了 a 子產品，如果 b 子產品很穩定，但是 a 子產品不穩定，那麼b子產品也會變的不穩定了，是以下一個原則：

不要讓穩定的子產品依賴不穩定的子產品， 減少依賴

既然上面說最好不要依賴，但是我發現我的 b 子產品的确依賴了 a 子產品裡面不可或缺的代碼怎麼辦？ 假設依賴的代碼段為 x , 現在來看x的特性, 如果x是一個可能高複用的代碼段，那麼無妨把x從 a 子產品裡面拿出來，單做成一個子產品 x, 那麼 b 子產品依賴 x 子產品就好了；靈一種情況，x是一個方法或函數，而且不太适合單做成一個子產品，是以那就在b子產品裡面拷貝一份 x 代碼就ok了，因為這樣可以保證子產品的 穩定性 和 自完備性.

如果上面兩種方法都不太合适，我們會在後面解耦裡面講到如何解耦

提升子產品的複用度，自完備性有時候要優于代碼複用

什麼是自完備性，就是盡可能的依賴少的子產品來達到代碼可複用。

舉個例子，我有個子產品 <code>utils</code> 裡面放了大量的<code>category</code>工具方法等，在日常ui産品開發中，依賴這個<code>utils</code>會很友善，但是我現在要寫一個比較基礎的子產品，應該就要求複用度更高一些，這個時候需要用到<code>utils</code>裡面的幾個方法，那這個時候還适合直接依賴<code>utils</code>嗎，當然不合适了，這與我們上面的設計原則相悖了啊，是以我們這時候為了這個子產品的自完備性，就可以重新實作下這幾個方法，而不是依賴<code>utils</code>子產品

每個子產品隻做好一件事情，不要讓common出現

子產品化結構是讓工程結構更清晰，每個子產品都隻做一件事情，都有自己的一個命名，這樣這個子產品才能良性發展， 但是這個名字千萬不要再叫common了，試想下你有沒有做過這樣的事情：“哎呀，這塊代碼放哪都不太合适，放common吧”， 日久以後，這個common就變成了毒瘤，大家都依賴它，還一堆不相關的代碼，這個<code>common</code>子產品就是我們設計原則第一點的反面教材： “非常不穩定，大量依賴，全是耦合，整個子產品無法複用到其他app”, 是以删掉工程裡面的common吧，再遇到不知道放哪的代碼，就要好好思考子產品的設計，再不行如果具有可複用性就單建一個子產品吧，為什麼不可以呢？

按照你架構的層數從上到下依賴，不要出現下層子產品依賴上層子產品的現象 業務子產品之間也盡量不要耦合

優點： 1、不隻提高了代碼的複用度，還可以實作真正的功能複用，比如同樣的功能子產品如果實作了自完備性，可以在多個app中複用 2、業務隔離，跨團隊開發代碼控制和版本風險控制的實作 3、子產品化對代碼的封裝性、合理性都有一定的要求，提升開發同學的設計能力。

缺點,子產品化當然也有它的缺點： 1、入門門檻較高，新手入門需要的成本也更高 2、工具的使用成本，團隊間和子產品間的配合成本升高，開發效率短期會降低。

但是從長期的影響來說，帶來的好處遠大于壞處的，是以子產品化仍然是最佳的架構選擇。

我先說說為什麼要解耦吧，子產品化并不是說你把工程的代碼拆分成 50 個 pod 或者framework就算完事了，要實作子產品之間真正的解耦才算真正的子產品化，否則如果子產品之間還都是互相調用代碼，循環依賴，那麼和原本放檔案夾裡面沒啥兩樣。那麼什麼是子產品間的解耦呢？

子產品解耦的目标就是, 在基于子產品設計原則上, 讓子產品之間沒有循環依賴, 讓業務子產品之間解除依賴。

這塊其實還是講的子產品設計，一個工程的架構可能會分為很多層，然而在開發的過程中，很容易有人不注意讓應該處于較底層的子產品依賴了上層的子產品，這種情況下應該對子產品的設計進行改造實作單向依賴。

比如一個常見的普遍的例子： 一個公共的webview子產品，裡面可能有webviewcontroller的基類，然後還有jsbridge的服務，如果設計的時候沒有注意，很容易在開發過程中，這個子產品被塞入大量的其他業務代碼，依賴了一大堆業務子產品，因為經常注冊jsbridge服務需要跟業務耦合。

這個時候怎麼做呢，首先我們要思考webview子產品的定位，從更全局的角度思考，每個app的架構應該都需要這樣一個子產品，那麼我們完全可以把這個子產品單獨拎出來下沉為基礎子產品，這個時候的解耦就需要你對webview子產品做出一些設計，添加一些注冊型api，修改jsbridge的服務為可以通過注冊的方式添加邏輯，這樣來實作與業務解耦，業務完全可以把與自己業務相關的代碼放在自己的子產品裡面，然後通過你設計的api注冊到webview子產品中。

雖然說公共子產品可以通過架構設計來避免耦合業務，但是業務子產品之間還是會有耦合的啊，而且這種情況是最多的，比如頁面跳轉啊，資料傳遞啊，這些情況前面的方法已經不夠用了。那如何解耦不同業務子產品之間的代碼調用呢？

那就是面向接口調用，我們知道隻要直接引用代碼，就會有依賴，比如：

那麼我們可以實作一個 <code>getsomedatafromb</code> 的接口，讓 a 隻依賴這個接口，而 b 來實作這個接口，這樣就實作了 a 與 b 的解耦。

這樣就可以實作了即滿足了子產品之間調用，也實作了解耦

優點：

缺點：

面向接口調用的缺點導緻并不能滿足所有的需求，也解耦的不夠徹底，那麼終極手段就是通過定義一套協定來實作子產品間的通信，協定現成的，那就是<code>url</code>跳轉協定，基本滿足需要，簡單易上手，基本上現在很多的app架構裡面都會有“統一跳轉” 這一套東西的，這個不光是對子產品解耦有幫助，對于統一化營運都是有極好的幫助的，比如app裡面的任何頁面，或者任何操作都是通過一個<code>url</code>來喚起的話，這樣是不是就把各個複雜的業務之間解耦了呢，通信都使用url.

說了這麼多，也要放點幹貨吧，下面給出2個庫的介紹，對你子產品化的程序希望有幫助。