JTalk《0325第四期-Android進階之旅》總結

JTalk第四期《Android進階之旅》活動結束啦，此次講師帶來了哪些乾貨？ 有幸參與本次活動，將本次JTalk講師分享內容進行了一個小總結，但願能幫到未能到場的同窗們～ 受限本人水準，總結可能稍有誤差或者不到位不清晰之處，還望見諒並請指出～

R lab移動端團隊技術架構體系及演進->子成 didi

技術演進的歷史

• activity、fragment，view、control=>指望抹平android、ios平臺差別

• 動態下發ui組合配置（不一樣國家不一樣地區等區分方式）

• 指望能下發業務邏輯

Nova輪子

內部開發框架

• 代碼高度複用

• 快速上線

Skeieton

反fragment聯盟（便是view又是control）

概念：router->數據傳遞/序列化

目前大量處在mvp->後期遷移爲mvvm

簡化activity、fragment生命週期

分層：

1. appication層。提供router等
2. service。基於數據展開
3. data access。 網絡，存儲

Dsl&compiler

1. 使用註解的方式處理以前經過負載方法搞定的代碼-Java的版本略顯拙略（Now）
2. 在Kotlin的Skeleton版本中提供更合理的實現（Future）

Router

1. 界面之間解藕（Now）
2. 參考前段Router實踐，完全實現View的無狀態化（Future）

Thinking

1. Ability。 Nova Foundation
2. Principle。 Nova Skeieton
3. Utility。 support、design、widget跨多項目使用
4. Engineering。 多個項目統一構建管理
5. Business。

goto開發規劃

other

1. 思惟糾偏

   限制本身的是：思考深度，對業務的理解力

2. 走出溫馨區

   逃離本身的溫馨區，拓展更多

3. 思考本質

   不能停留在API階段，深刻思考理解內部底層設計及實現

4. 理解業務，助力業務

5. 遷移

   快速進入某個領域，在於本身的知識遷移能力

6. 機遇

   發展和機遇有必定相關

QA

Q: 對測試的友好支持

Router不一樣場景的入口，方便測試
複製代碼

Q: 知識遷移

方法論、概念的遷移
複製代碼

Q: 業務角度看MVP、MVVM選型

數據量小：MVP足夠且方便用
大數據量：電商等，數據處理多，很痛苦MVVM會較好
        強數據和強交互的劃分
複製代碼

Android組件化的正確姿式 ->張明慶 獲得

高高山頂立，深深海底行

組件化面臨三座大山

1. 業務開發時間太緊

2. 業務過於龐大

3. 隱藏的阻力

組件化：須要站在更高的山去看他們

實施設計方案的態度

深深海底行->沉入代碼

爲何要組件化

• 用包來區分模塊

• 用module區分模塊

------以上胖體系(巨大開發包袱/拖慢開發節奏/下班晚)------

• 組件化

• 插件化

• 組件化/插件化陣營

組件化使用的人多，開源內容少

組件化設計時容易和業務強耦合

• 爲何不是插件化
  1. 除了動態添加，組件化能實現插件化全部功能
  2. 組件化學習曲線更加平滑
  3. 插件話不可避免進行系統Hook，9.0以上前途未卜

高高山頂立

1. 代碼搬家，隔離結偶

   組件單獨調試

   避免資源衝突

2. 組件生命週期

   運行時動態打開組件（加載）

   運行時動態關閉組件->ABTest（卸載）

   組件降維H5（降維）

   更龐大須要更多

3. 交互互通有無

   

   每一個組件怎麼提供服務

   怎樣作到更方便的服務發現

   服務接口如何自動化與其餘代碼剝離

   組件和組件之間的Router

4. UI跳轉

   是否支持scheme跳轉

   路由和傳遞倉鼠是否支持自動註解生成

   是否能夠生成清晰的路由->路由表的生成自動

5. 集成調試

   任何組件可否充當host

   組件由host切換到library是否能夠無感知的完成

6. 代碼和資源隔離

   如何作到代碼隔離

   語法	舊語法	功能	支持類型	代碼隔離效果
   implementation	compile	編譯期間對其餘組件不可見，運行期間對其餘組件可見	jar aar	「隔代」編譯期間隔離
   api	compile	編譯和運行期間均可見	jar aar	沒有隔離
   compileOnly	provided	只參與編譯	jar	沒有隔離
   runtimeOnly	apk	編譯期間不可見，運行期間可見	jar aar	編譯期間隔離

compile無法作到資源隔離

runtimeOnly編譯不可見，運行可見。其實也不行

• 能否作到編譯期組件不可見，但同時所有組件參與打包?

  

深深海底行

組件化過程一直都很痛苦

劃分項目

• host
• 組件
• 服務發現
• 業務依賴庫
• 依賴庫

怎麼開始執行：四部曲

依賴庫先行，業務依賴庫初步抽離

尋找業務邊界，抽離邊界清晰的業務模塊

將形成組件依賴主項目的模塊繼續抽離

將主模塊抽離成一個host殼子

萬事開頭難

• 走出溫馨區，作好充足的準備

• 組件化會長期停留在中間狀態

• 你的app會長期很胖，期望一次成功時不可的

• 基於組件徹底平行，集成交給app即成調試的方案時不可行的

• 這不是停滯的理由，要抓緊一切時機

• 無止境的優化

  • 四個維度的優化：工程 組件 頁面 類
  • 組件內部：pin分包結構，頁面級別隔離甚至內聚
  • 頁面內部：MVP MVVM拆分

    

  • 類：單一職責拆分，代碼規範

• 看好護城河，防止地道戰

  • 避免下沉： Event，實現類，公共資源
  • 地道戰：廣播、sp、db
  • 不知道該不應下沉：不應，明確下沉：該

• 康威法則 組織架構和架構之間的映射關係

  • 儘可能貼近組織結構和產品業務
  • 盡力去反響改變組織結構和產品業務
  • 作不到，回第一條
  • 不要逆行

• 團隊共識 就是：我知道，你知道，我知道你知道，你知道我知道……

  • 獲得大多數人的支持
  • 持續的輸出正向結果
  • 給更多人賦能，讓更多人入坑
  • 創建配套的模塊負責人制度等

《獲得》組件化成果

和講師聊騷

實時多媒體SDK性能優化 Powerinfo 許建林。

性能優化流程

測量，分析，優化=>循環

RTC SDK業務流程

採集->預處理->預覽->編碼->發送->接收->解碼->後處理->渲染

優化

緊扣場景作優化

脫離場景談優化，都是耍流氓

• 推流首屏時間

• 屏到屏的延遲

• cpu佔用

• 內存抖動優化

測量方法

首屏時間 視頻慢動做錄製。。。。會玩 視屏延遲

優化思路

多操做並行

預操做提早

智能pos架構演進 美團 閆飛

pos機->收銀功能整合

客戶端架構理解：

• 業務觀：時刻理解業務規則及特色

• 全局觀：關注上下游服務，以全局的視角審視問題

• 視野觀：技術寬度不限於客戶端（某一塊）

• 發展觀：架構是面臨的問題一步步迭代出來的，不多一步到位

• 運營觀：關注產品各項指標

演進

• 0.5時代

  

  資源缺少&業務快速推動->復瑣事情簡單化，取得0的突破

  架構自己就不是一步到位的事情，如何在短期內集中稀缺資源推進項目上線？這勢必要分清主次、有所取捨，將復瑣事情簡單化。只有取得零的突破，纔有談演進的資本

• 1.0時代

  面臨着：穩定性、廠商對接複雜度、多版本管理

  索取主動權，思考從新設計

  • 創建硬件抽象層，自研銀行卡收銀

  • 銀行卡收銀分層模塊化

  • 異常處理：充分暴露異常，而不是試圖消滅異常

  

  下層收集異常，上層處理異常->異常處理模塊統一對異常進行處理 埋點：技術側埋點與產品側埋點

• 2.0時代 擁抱開放

  • 創建收銀服務層

  

  • 美團智能支付開放生態

  

• 總結

  • 架構沒有定義、沒有標準，惟有深入理解業務，圍繞業務不斷思考不斷迭代

  技術離不開業務，努力寫簡單代碼

圓桌

Android前景

1. 業務優先，關注所作工做的上下游，眼界不侷限於客戶端
2. 不要把自身侷限於當前「身份」


1. 追本溯源，當程序員的出發點。享受紅利的同時，承擔其風險（技術變化快等）
2. 走出溫馨區
3. 新技術，去嘗試。大前端的趨勢，具體技術不能肯定

1. 核心：學習能力
複製代碼

面試

美團： 校招：基礎(數據結構算法等)，解決問題能力 社招：解決問題，思考問題的能力

不要試圖把握面試主動性：睡個好覺直接去就好了

日常：注重提高我的核心競爭力

面試是一個互動的過程，不要拘束，不要埋頭想問題，多互動交流