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. 核心：學習能力
複製程式碼

面試

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

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

平常：注重提升個人核心競爭力

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