標籤：
控制器，是MVC中的一環，也是手機軟體開發中最需要注意的地方，對它的認識不清晰會導致業務層代碼的結構混亂，耦合性高。經常見一些進行了幾年的老項目代碼，如果不是經常的迭代重構，維護起來會非常痛苦。今天重點說一下怎麼化解這個問題。其實，每個平台都對Controller有很清晰的描述和定義，只不過我們在使用中容易自己亂了陣腳，而最終導致自己難受罷了。像Android中的Activity、Fragment，IOS中的ViewController，都定義了明確的生命週期自管理方法，供開發人員使用。我們只需要把這些生命週期方法當入口，驅動自己的代碼就好了。在使用過程中下面幾個注意事項多多注意，你的代碼會很純潔的。
1、Controller絕對不要對外暴露方法，不要讓其它C可以通過函數調用的方式操作自己。這個是嚴重破壞Controller生命週期自管理的行為，必須禁止。對一個C來說，接受外部C的啟動參數並啟動，加入到系統的C管理器之後，就不能接受任何其它C的驅動了。如果確實需要通訊，請使用訊息。
2、訊息通訊。這個應該必須被當作是C之間進行通訊的唯一手段，因為只有它是不干涉C的啟動並執行，由目標C自己決定是否接收訊息，接收了訊息之後如何處理。一個Ca啟動另一個Cb，或者在Cb運行期間，Ca向Cb發送訊息。Activity、Fragment中的Intent，ViewController中的Notification，這些都是多少天然的組合。
3、當Controller之間有共性的時候，我們腫麼辦？這其實是個Has-a，還是Is-a的問題。我用近10年的編碼經驗告訴大家，一定要選擇Has-a，這個基於幾點，一個是業務多變化，今天的共性明天可能就不存在了，今天有3個，明天就可能變成2個，選擇Is-a這種強關聯，會很痛苦的。另外，業務層的開發往往是幾個人幾杆槍，任務分開各幹各的，Has-a是最合適的，把關鍵的公用小模組做好，其它的自由發揮去吧。不要把眼睛緊盯在那幾行重複的代碼上面。
4、頁面太多，Controller之間跳轉混亂，怎麼破？這個其實是表象。首先，我們做好上面3點之後，C之間的耦合性問題已經不存在，接下來我們再規範一下C之間進行跳轉時的傳參規則，參數由目標C來定義自己需要接收的資料格式。想跳到哪個頁面時，找到它的源碼，看下它定義的參數規則，按它的要求傳過去，然後把產生的新C交給系統的C管理器就好了。在Android中是startActivity，commitFragment，IOS中是presentViewController。
5、關於頁面開放。是否使用PageLink？這個要避免走向極端。如果你的頁面需要開放給第三方應用，毫無疑問，PageLink是最好的選擇。因為這些頁面一般都是核心頁面，穩定性高，數量少，參數少，一個URI可以很清晰表達出來。像電端類的寶貝詳情，SNS類的個人首頁、日誌詳情等。那對於內部頁面之間的跳轉呢？這個要慎用。內部頁面數量多，參數多變，資料結構複雜多樣，隨著業務的變化還會不斷更新。每次跳轉前把資料結構壓成URI，通過分發中心傳遞給目標C之後再還原序列化，校正參數合法性。每次參數有變化再調整，你累不累？
好了，今天先聊這麼多，各位有什麼更好的想法或者不同意見歡迎交流，一起提高。
聊一下移動開發時MVC中的控制器
