最近Jetpack Compose發佈了Beta版本，抽時間瞭解了一下Compose帶來的改變和其中的一些原理。本文不會講解具體API，只是比較隨意的分享自己的一些疑問以及在探尋答案過程中的一些收穫。 ...
最近Jetpack Compose發佈了Beta版本，抽時間瞭解了一下Compose帶來的改變和其中的一些原理。本文不會講解具體API，只是比較隨意的分享自己的一些疑問以及在探尋答案過程中的一些收穫。
為什麼要有Compose?
Android已經十年多了，傳統的Android UI ToolKit有很多歷史遺留問題，而有些官方也很難修改。比如View.java有三萬多行代碼，比如Combo box竟然叫Spinner，再比如Button繼承自Textview。同時官方的一些widget修複依賴系統升級，到達用戶周期過長。
通過在Jetpack中添加Compose，脫離了Android系統，代碼修複可以更快地到達用戶。
而對國內開發者來說，更統一的代碼，意味著沒有廠商定製。這幾天有位朋友和我抱怨『哪個大佬有時間重寫個editText嗎，廠商/系統的一堆問題』，我想他可能要夢想成真了。
同時，Compose通過引入聲明式編程，依賴Kotlin特性，可以讓代碼編寫更快更簡單。
想象寫一個搜索通訊錄的界面，傳統的Android開發寫這個界面需要多少代碼？activity一個xml，item一個xml，封裝一個recyclerview，再寫一個Adapter，寫了這麼多，可能還費力不討好，xml轉成view的過程中，IO和反射影響了性能，界面再複雜一些，走非同步layout還是x2c？而在compose中，可能只需要下麵這段簡短的代碼，並且沒有xml的性能問題。
如上圖，在Compose中，不斷的方法調方法，就完成了UI的組裝。
什麼是聲明式編程？
提到Compose，就不得不瞭解什麼是聲明式編程。
我們來看一下維基百科的解釋，聲明式編程是一種編程範式，表達邏輯但不描述具體控制流程。就是告訴電腦我想要什麼，而不是告訴它怎麼做。那對應到Android就是我想要一個什麼樣的UI，而不是這個UI應該如何改變，當然UI的自動改變需要框架的支持。
聲明式編程在React、Flutter等框架中已經有廣泛的應用，聲明狀態，狀態變化，UI自動重繪。
有意思的是，Compose的發起人Jim Sproch之前是React的核心開發人員，他在Slack上聊到VDOM的一些問題，比如vdom分配記憶體空間在複雜項目中成為性能瓶頸，compose採用調用composable方法的方式，減少記憶體分配。相比vdom，compose把node隱藏在背後以防濫用，同時可以更方便的使用if/for控制流程。
@Composable是什麼原理？
上面這個簡單的例子，當點擊button，button中的文字自動加1，remember用來記錄最新的count值。
@Composable是個註解，而要實現自動更新UI，肯定是修改了Class文件，讓我們看看class文件變成了什麼樣？Kotlin編譯後的class在build/tmp/kotlin-classes目錄中，但在Android Studio中是無法看到class反編譯後的內容，可以用Jadx。然後Text()這些Composable方法編譯成class後也有改動，為了方便閱讀，最好是編譯好APK後，再用Jadx閱讀反編譯源碼。
上面就是編譯後的CountInner方法，可以看到，方法參數都被改變了，方法塊中添加了很多start/end，調用Text()的Lambda變成了ComposableLamda，改動還是比較多的。
這些改動是怎麼實現的呢？如果我沒記錯的話，Kotlin的協程也做了有些改變方法參數的操作，兩個是不是差不多的實現？但協程是kotlin特性，應用層動態修改class文件，難道是在Gradle Transform里用ASM去操縱class的？
一番搜索，發現Compose應用了Kotlin compiler的新特性，通過IR extension，可以在中間代碼生成期間修改邏輯。IR又是什麼？intermediate representation的縮寫，翻譯為中間語言。Kotlin為了Compose開放了擴展能力，並且統一了JVM/JS/Native的IR流水線，為跨平臺提供支持。可以理解為Kotlin對協程做的那些事情，通過使用IR extension，你在應用層也可以去做了。
Talk is cheap, I will show you the code.
Compose Compiler的源碼。ComposePlugin.kt中註冊了ComposeIrGenerationextension。ComposeIrGenerationExtension中又有ComposableFunctionBodyTransformer實現上面描述的方法中添加start/end，ComposerLambdaMemoization實現上面描述的改變成ComposerLambda。具體邏輯可以看源碼，註釋描述的比較清楚。
重組是怎麼實現的?
看Compose的文檔，一直有重組(Recomposition)這個詞，就是狀態變化的時候，自動更新UI。那重組是怎麼實現的呢？
每次調用count.getValue()的時候，最終會回調到Composer，Composer中維持著一個Map，這時就把state和當前的scope進行了關聯，scope可以理解為一段可以重組的範圍。那當前的scope哪裡來呢？還記得編譯的class里多了很多start和end嗎，在調用start方法的時候，會生成一個scope，放在棧頂。所以調用count.getValue()的時候，直接拿棧頂scope就可以了。當調用end的時候，會調用updateScope更新scope的block屬性，而這個block是一個lambda，執行這個lambda會調用對應的composable方法重繪，這樣state和block就關聯起來了，後面state變化的時候，拿到block執行就可以了。在這個例子中，count state對應的block是一個調用Button方法的lambda。
再來看下更新state的流程。每次調用count.SetValue()的時候，最終會調到Composer中的recordModificationsOf方法，然後從上段說的Map中獲取state對應的scope, 並把它添加到invalidations中，通過編舞者監聽，下次vsync時，會調用invalidations中lambda的invoke方法，從而更新UI。
請註意，『在調用start方法的時候，會生成一個scope』，但其實只有第一次添加的時候生成就夠了，後面更新UI的時候直接用舊的就可以了，太多類似的東西需要存儲，Compose中有一個非常重要的數據結構叫插槽表SlotTable，剛說的這個scope復用以及例子中的remember都是利用了SlotTable，具體可以看深入詳解 Jetpack Compose | 實現原理。
Text對應的是TextView嗎？
Text對應的是TextView嗎？不是的。
debug看了一下，所有的composable UI最後被包在一個AndroidComposeView中，放在ContentView下麵，所以最上層的東西是沒有變化的。傳統的Android UI中的view樹，變成了node樹，view的那些功能被node替代了。
和舊有體系相容，可以直接把AndroidComposeView添加在xml中，這樣就可以混用了。
自定義Layout怎麼寫？
簡單的看了一下，measure/layout走的是measurePolicy，在一個方法中去寫measure和layout。measure中有個Constraints最大最小限制，類似MeasureSpec那一套，match_parent變成了Modifier.fillMaxWidth()，這個Modifier會在measure之前修改Constraints，measure的時候會把修改後的Constraints傳遞進去。
draw是通過Modifier實現的，還是走canvas那一套。
Touch事件怎麼處理？
自以為對Android的touch事件還算比較瞭解，之前在看Android源碼的時候也發現了一些有意思的地方，比如down事件在native底層處理，不是作為message在java層looper處理，所以setMessageLogging的方式檢測不到down里的耗時。那編舞者不是分發Input/animation/layout的callback嗎？那個主要是用來處理move事件。你以為move事件里只有一個坐標點嗎，看看MotionEvent.getHistorySize方法吧，那這個size和屏幕採樣率以及觸控採樣率又是什麼關係呢？
言歸正傳，看到Compose的出現，肯定也好奇對Touch事件處理方式的改變。
dispatchTouchEvent/onInterceptTouchEvent/onTouchEvent這些方法不見了，攔截事件需要實現PointerInputFilter，主要邏輯寫在onPointerEvent方法，這個方法甚至連boolean都沒返回，那怎麼判斷是否消費了呢？傳遞進來包裝好的event中有個是否消費的屬性，每個filter自己判斷是否有未消費的事件，去修改已經消費。感覺這一塊還有優化空間，好像沒有消費之前的事件，後續事件還會回調到。
現在定義了Initial、Main、Final三個階段，在你關心的階段中去處理，前兩個階段和以前差不多，Final階段類似用來處理之前的cancel事件。
結尾
Compose還在持續優化中，比如composable函數最近要支持併發執行了。
兩年磨一劍，谷歌推廣Compose的決心是毋庸置疑的。Compose為了方便開發者，也是考慮到了很多現實的東西，比如像kotlin支持和java互調一樣，支持Compose和傳統UI互調。雖然投入巨大，的確更快更簡單，但在社區中的普及還有待時間驗證，畢竟Jetpack中的庫很多大家都還沒有用過，而Compose的徵程也註定要比Kotlin艱難。
時間有限，本文只能紙上談兵、管中窺豹、拋磚引玉了，如有謬誤，還望不吝賜教。
