1. 程式人生 > >App競品技術分析 (8)模組化拆分

App競品技術分析 (8)模組化拆分

1 iOS資源拆分與模組化

  對於iOS,很多App已經注意到圖片會散落在各個地方,於是會把圖片、配置檔案、xib按照模組進行歸類,放到各自的bundle包中。做得最好的,是一家電商App,會在App包中的一級目錄下面,看不到任何圖片,而只有若干bundle,如圖9-18所示:

  clip_image002

  圖9-18 某款App包中,對資源進行了模組化拆分

  只對資源進行模組化拆分是遠遠不夠的。一定要對程式碼進行模組化拆分。把不同模組的程式碼放到各自的GIT倉庫中,這樣各個部門只對各自GIT倉庫中的程式碼負責,而不會產生程式碼級別的依賴,如圖9-19所示:

  clip_image004

  圖9-19 iOS模組化架構

  在iOS,我們可以使用.a檔案進行模組化拆分。把每個模組都以.a檔案的形式嵌入到MainApp這個主模組中。

  但是.a檔案不能動態下載,所以也就不能使用類似於Android的外掛化思想。要想動態更新模組,還要另闢蹊徑。

2 Android模組化拆分

  家大業大,子女多了,以後就要考慮分家的事情,大家各過各的,出了問題儘量自己搞定。

  公司大了,也會面臨同樣的問題,我們會把App按照模組進行拆分,程式碼按照模組拆分到不同的GIT倉庫中,不同部門負責各自不同的模組,他們會對自己的模組負責。

  如果還按照之前的做法,把模組按照Package進行劃分,看起來也不錯,但是這樣做會有問題。比如說發版時間為1月14號,但是A部門負責的A模組卻延期了,難道我們要延期發版嗎?那不行。

  所以我們要把A模組從主專案中遷移出去,A模組會作為一個jar包,主專案會保持對該jar包的引用。這樣A模組如果延期了,那麼就主專案就仍然保持對A專案原有jar包的引用,這樣就不耽誤1月14號的正常發版了。

  另一方面,各部門如果繼續在一個版本庫下工作,經常會搞出互相干擾的情況。比如說A提交的程式碼會導致B編譯不過,A提交的程式碼會沖掉B的程式碼,A修改了公共方法會導致其他地方都報錯。當我們把程式碼按照模組都拆開了就不會有問題了,A隨便提交自己的程式碼,只會影響自己的GIT倉庫,不會禍及他人。

  然而問題接踵而至,如圖9-20所示:

  clip_image006

  圖9-20 Android模組化拆分示意圖

  我們看下面這個模組拆分圖,有以下幾個問題需要解決:

  1)ModuleA模組和ModuleB模組共用的類和方法,要怎麼處理?

  2)ModuleA模組和ModuleB模組共用的資源,要怎麼處理?

  3)如何能在不同模組間共享資料?比如說全域性變數,比如說模組之間頁面跳轉時傳值。

  對於問題1,我們要解決程式碼上的依賴。為此,需要從專案中剝離出一個業務無關的AndroidLib類庫。在此基礎上,我們可以輕鬆的把一個模組所涉及的那些Activity轉移到另一個模組去。

  對於問題2,我們要解決資源上的依賴。

  首先是要制定模組的命名規範,所有資源前面都要加上模組名稱,這樣才能確保資源名稱不衝突。

  對於公用資源,還是要放在AndroidLib目錄下,AndroidLib類庫會為每個公共資源生成一個R.id.xxx的對應屬性,我們要把這個R檔案連同資源、以及AndroidLib目錄下的程式碼一起打成jar包,放到要用到它的MainApp、ModuleA、ModuleB模組中,這樣手動打包時才不會出錯。

  對於問題3,我們有很多手段,來傳遞資料。

  比如說,從ModuleA模組的A1頁面,跳轉到ModuleB模組的B1頁面,傳遞一些簡單型別還好辦,如果要傳遞自定義的實體,就只能把這個實體定義在AndroidLib類庫中了。但是AndroidLib類庫畢竟是放業務無關的程式碼,所以不適合存放這樣的業務實體類,所以還是儘量不要改動AndroidLib類庫。

  比較靠譜的做法是,再新建一個存放實體的AndroidEntity類庫,這些實體專門用於傳遞模組間要傳遞的資料。所有模組都保持對這個類庫的引用。

  我還見過模組間通訊使用JSON文字的,這樣就不用在AndroidLib類庫中建實體類了。

  對於使用者身份資訊,也就是那個User單例類,也是這麼處理,把User類放到AndroidLib類庫中。

  如果一定要使用全域性變數,而且要在不同的模組間讀寫,也可以這麼處理。

  接下來說開發人員如何建立自己的工作區。

  1)最簡單無腦的辦法就是把所有的專案都開啟,專案之間是程式碼級依賴關係。ModuleA模組的開發人員只能修改ModuleA的程式碼,儘管能看到MainApp模組和ModuleB模組的程式碼,但是卻沒有許可權修改。

  專案之間是程式碼級的依賴關係,那麼自動打包指令碼就要相應修改,我們要同時編譯若干個專案,而且有先後順序。請參見部落格園“謙虛的天下”的文章《App自動化之使用Ant編譯專案多渠道打包》[1]

  2)比較高階的做法是jar包依賴的方式,只打開自己部門所屬模組的程式碼。

  比如說,對於MainApp模組的開發人員,他們只打開MainApp模組的程式碼,而把ModuleA模組和ModuleB模組對應的兩個jar包,引入專案中。這兩個jar包是由ModuleA和ModuleB這兩個模組的開發人員生成後上傳到MainApp模組的lib目錄的。

  而對於ModuleA模組的開發人員,則是要開啟MainApp模組和ModuleA模組的程式碼,而把ModuleB模組對應的jar包,引入專案中。因為MainApp模組是宿主(也就是一個殼),所以不得不開啟它的原始碼,才能編譯除錯程式碼。

  按照這種jar依賴的方式,自動打包指令碼就非常簡單了,仍然是單專案的打包機制,我們基於MainApp專案進行打包,其他所有模組都事先做成jar包放到MainApp專案的lib目錄下。

[1] 文章地址:http://www.cnblogs.com/qianxudetianxia/archive/2012/07/04/2573687.html