說一說Facebook開源的Litho

Facebook總是能給業界帶來一些驚喜，最近開源的Litho是一個高效構建Android UI的聲名式框架（declarative framework for building efficient UIs on Android）。Litho的出現可以追溯到Facebook去年的一篇博文Components for Android: A declarative framework for efficient UIs，中文譯文：Components for Android: 一個高效的聲明式UI框架。

Litho最初的目的是為了解決複雜列表的高效渲染和內存使用問題。之前我也寫過相關的文章Android ListView中複雜數據流的高效渲染，Android複雜數據流的「高效」渲染。之前的思路是把列表中的邏輯Item拆分為可復用的更小單元，然後利用ListView或者RecyclerView自帶的緩存策略達到節約內存的目的。Litho採用了更激進的方式，放棄使用原生的View，使用了自定義的View和布局，通過極高的View復用率節約了內存使用，同時採用了非常高效的布局策略，使得繪製更加迅速，滑動更加流暢。Litho的使用對於複雜數據流展示優化可以說是顛覆式的，非常佩服他們的思路和實現。當然個人認為Litho的目的不僅僅是解決上述問題，作為一個UI渲染框架完全可以代替目前Android中的渲染實現。但是就目前Litho的情況來看，離完全替代還有很長的距離，之後我會說明自己的想法。

Litho 概述

先來看下官方上對於Litho高效渲染的介紹，主要介紹了4個特徵：

聲名式組件

Litho採用聲名式的Api來定義UI組件，我們只需要基於一組不可變輸入（ immutable inputs）描述UI的布局，剩下的事情就可以交給Litho了。

聲名式布局讓我們用一種描述式的方式構建組件：

看代碼非常簡單易懂，而且Litho使用Flexbox對組件進行布局，有前端經驗的同學知道Flexbox布局非常的方便。Litho提供的Image使用了fresco，也非常棒。

非同步布局

Litho可以非同步進行measure和layout，不需要在UI線程中。

扁平化的View

Litho 使用了Yoga來進行布局，可以減少UI中繪製ViewGroup的數量。

在Android中，為了避免界面錯亂，所有的UI繪製和操作都是在UI線程中，對於比較複雜的界面，繪製過程過長就會引起界面卡頓，掉幀，之前的優化基本都是通過減少布局層級、避免過度繪製等手段進行優化。Litho使用非同步布局就避免了在UI線程中執行繁重的measure和layout過程。Litho使用Yoga可以進一步優化布局，我們在生命式的UI布局中只是指定了布局的樣子，並不是實際的布局，Litho可以進一步優化，我們知道展示UI可以使用View或者更加輕量級的Drawable，Litho可以根據需要裝載View或者Drawable，相比Android原生的布局，Litho使用了更多的drawable，這會讓試圖渲染更快速。如圖：

當我們使用開發者工具中的顯示布局時，可以看到圖中的所有元素是渲染在一個View上的。

細粒度的復用

所有組件包括text和image等可以被回收並在UI的所有位置進行復用。

Litho組件的全局復用，可以極大地提高內存使用率，在展示複雜列表時，內存使用會有明顯的區別。

看完Litho的四個特徵，相信每個Android開發者都是非常驚喜的。

Litho的思路

本文不會深入到Litho的代碼細節，主要介紹自己對於Litho的分析與想法。

1. 組件化

這裡所說的組件化不是工程上的組件化，而是布局上的組件化。Litho的靈感應該是來源於React，以組件的方式組織布局。

傳統的Android使用xml進行布局，名義上是mvc中的view，但是在功能上非常弱，幾乎沒有邏輯處理，之後推出的data binding使得功能上稍有加強，但是功能依然比較弱。當然不可否認這種界面布局與邏輯代碼分離的設計思路也是非常棒的。在傳統開發中，把界面布局和邏輯分離是最合理的方案，但是有些時候也稍顯笨重。litho的設計思路是放棄了xml布局，而是使用java代碼來構建界面組件並進行布局，使用組件的方式連接了邏輯和界面布局，與React在前端上的設計有相同的思路。Litho包含兩種組件：

Mount spec: 可以獨立渲染一個view或者drawable，擁有自己的生命周期

Layout spec：可以組織其他組件構成一個布局，類似於Android中的ViewGroup。

使用litho後每一個界面都是組件化的，合理設計組件，可以增加組件的復用性，同時組件本身props、state的設計是的自身功能比較完整，比傳統意義上的xml中定義布局要強大很多。

2. 扁平化與事件處理

關於Litho的一些想法

1. 關於界面調試

Android開發中我們在xml中定義布局，Android studio有強大的預覽功能，所見即所得的體驗很棒。Litho提供了對於Stetho對支持，可以利用chrome的開發者工具對界面進行調試：

其實相比xml，這種方式並不方便，在chrome只是輔助調試，最終還是根據調試情況手動在代碼中更新。

2. 開發體驗

在寫界面時，我們要合理地對界面進行拆分，使用多個組件組合成為一個完整對界面。一個組件定義如下：

例子中我們定義了一個組件，但是我們在邏輯代碼中並不會引用到這段代碼。Litho會根據componentSpec生的生成真正的component代碼：

所以有個弊端是我們每次修改一個component文件都需要build一次生成可用的代碼。對於開發來說體驗並不友好。

另外我們可以看下Litho提供的可用組件：

所以如果完全使用Litho來開發一款應用，需要自己實現的控制項會非常多。個人認為雖然Litho有諸多好處，對於一般的應用來講，常規的優化手段已經完全可以滿足需求。Litho還是更適用於對性能優化有強烈需求的應用。

3. Litho組件化的思考

Litho使用了類似React的設計思路，而React社區非常的活躍。如果Litho的未來發展的比較良好，可以支撐常規應用開發時，React社區的很多經驗就可以借鑒過來，如Redux等工具的實現等。

最後

對於Litho的使用還是一個比較初級的體驗，文中如有錯誤的地方，煩請指出，非常感謝。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！