工程化移動開發

注意：本期節目很乾，專註移動開發領域。

回顧十來年的移動發展史，移動開發早就成三五個人的小打小鬧變成三五十人甚至三五百人的大規模集團化作戰了。在互聯網領域，量變引起質變是一條絕對的真理。因此，無論Android還是iOS，默認的那一套給個人或者小組使用的方式方法，都是不充分適配大團隊使用的。

在本期節目中，我們將基於周末參加的技術沙龍，分享一下我們的所見所想。

先從Android說起。

自從航母式的App層出不窮，為了下載的時候能夠體面一點，當然也為了省一筆推廣運營費，插件化技術就被廣泛的應用了。但插件化只是一個開始。如果沒有良好的組件化，那麼插件化就真的只是提供了一排插口而已。各個插件獨自開發，代碼的冗餘將直線上升。

組件化的目標與插件化是截然不同的，追求的是解耦徹底、依賴清晰、易讀高復用。從Java語言的角度，自然會聯想到服務端已經應用的一些技術。

組件化的再進一步，就是解決代碼量太大，一次全量編譯太慢的問題了。簡單的說，調整工程組織結構，從Module改為Project級別。以空的主Project結合大量服務或業務級別的Project，實現代碼隔離、按需打包、分離更新等效果，這樣即管理了代碼還管理了人。Atlas等框架都是類似的思想，這也是有點技術能力的公司在開發大型App時候的必然選擇。

完成上述那些，還差一點點，那就是整套的CI平台了。這樣不光能進行高效的工程管理界面，還能夠對於互聯網公司的產品矩陣形成提供快速試錯的平台級支持。

然後說說iOS。

iOS的最大問題在於封閉。蘋果相對於google是個不那麼geek，不那麼擅長搞工程的公司。xCode相對來說也更像個人使用的玩具。先來體驗下xCode的大平層結構帶來的噩夢般的體驗。

熟悉iOS的人會想到CoCoaPods。但pod本身也是夠可怕的，不更新pod還沒事，不然就是各種編不過，占磁碟，編譯慢。對了，還要手工清緩存，還有頭文件污染。。。所以，其實還是要自己做系統來管理的。

再來說說混合開發。

這一概念流行了很多年了，從最早的webview到各種webview容器再到最近一兩年的趨勢——RN或者類RN框架。核心的思路在於一套代碼多端執行，從而節省成本，缺點自然是效果不如原生。嘉賓的分享比較全面，不過並不深入。我可以說的比他更多一點，要不單獨開一期？

最後介紹一下我覺得很基礎也很重要的部分——基礎平台。在攜程這個系統被稱為MCD，是CI的一個全面增強。幾張ppt足以充分的解釋清楚這個東西了。

然後就是MTP平台了。這與之前在Android部分提到的管理平台很相似，只是更加直觀好用。這方面，攜程顯然比餓了么走的更遠一步。只要有了充分的組件化支持，開發維護管理一個龐大的產品矩陣並不困難。

最後，說說APM。聽雲之類的公司就是專門做移動應用實時監控的，可見此系統的價值之大。因此，對兩位從0到100實現整套系統的大佬致以最崇高的敬意。

移動開發十年來，任何覺得移動開發只是隨便找幾個人在一起寫寫頁面的想法，都顯得很幼稚了。我是說，如果不懂移動開發，可以虛心學。但想當然的覺得移動開發很簡單，很沒技術含量，那就是sb了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！