2. 代碼架構和運行時架構（內涵段子）
代碼架構：與業務邏輯無關，基本上每個項目都要用的，比如訪問，網絡，圖片，Activity，Fragment 等等 (一般是不會變動，多下些功夫)
運行時架構：與業務邏輯有關，是這個項目特有的一些功能部分，比如，參數要加密（RSA）單點登錄，插件換膚等等（BaseSkinActivity）
xx公司 （股份，10k） 組織代碼 代碼架構，運行時架構 （7:3 or 6:4） 用視頻賣喫東西，直播，換了方向，小程序（2-3年）
3. 怎麼選擇架構層級
3.1 所有代碼，寫在一起也就是都在 app 裏面 （外包，一個人做）
3.2 按架構層級分層 Base , FrameWorker , App , 每個層次一個模塊 （內涵段子）
3.3 多模塊和多組件開發 （協同，多人開發，方便測試），注意的是不用用蜘蛛網，最好用路由的方式 （1個人）
什麼是模塊什麼是組件 ? 模塊更多的是你的項目的功能模塊，
組件一般都是一些小型的輔助（第三方的自定義View，第三方的一些基礎功能）（也可以單獨存在於moudle中）
處理不好還是會有一些問題的，資源問題，命名不能衝突，針對問題要不斷調整？分析經驗，我帶大家解決問題的方式，解決問題能力
4. 怎麼選擇第三方
1. 熟悉原理（比較重要）開發可控；
2. 選擇大多數人選擇（國外），問題都解決沒？是否停止更新 ，可以依賴多個第三方
3.要注意解耦（重構，版本迭代） HttpUtils RxLogin RxPay , 圖片（工廠設計模式），數據緩存（工廠設計模式） xUtils，AsncHttpClient ，OkHttp
4. 要站在成員的角度去選擇（培訓，倒逼）
5. 等等 （學習模仿）
5. 其他的補充
5.1 需求文檔（吃了很多虧，反思） 自己寫需求分析文檔（領頭人）
5.2 不要濫用繼承和接口，多用封裝 ， Retrofit 封裝好用，但是比較死，深度定製的問題（出錯率就會大，代碼的可讀性就會弱） 版本迭代功能擴展比較致命
5.3 不要嵌套（直接依賴） （內涵端子，每個功能部分都是分開的） （註解 AOP 等等） IOC(LogUtils 測試的時候去大打印日誌，檢測是否登錄)
5.4 問題的解決方式多種，找最簡單的 （《墨菲定律》）
微博分享 singleInstance Unity , 2.寫一個新的 Activity 一開啓就去分享，分享完畢把當前Activity關閉掉，3. 微博Activity主題採用的是透明的，去掉透明