说一说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了。
    声名式布局让我们用一种描述式的方式构建组件:
@LayoutSpec
public class FeedItemComponentSpec {

  @OnCreateLayout
  static ComponentLayout onCreateLayout(
      ComponentContext c,
      @Prop final Artist artist,
      @Prop final RecyclerBinder binder) {
    return Column.create(c)
        .child(
            Column.create(c)
                .child(artist.images.length == 1 ?
                    SingleImageComponent.create(c)
                        .image(artist.images[0])
                        .aspectRatio(2)
                        .withLayout() :
                    Recycler.create(c)
                        .binder(binder)
                        .withLayout().flexShrink(0)
                        .aspectRatio(2))
                .child(
                    TitleComponent.create(c)
                        .title(artist.name))
                .child(
                    ActionsComponent.create(c)))
        .child(
            FooterComponent.create(c)
                .text(artist.biography))
        .build();
  }
}

看代码非常简单易懂,而且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. 扁平化与事件处理

我们知道,Android中的View不止可以展示,还可以与用户进行交互,如点击、滑动等等。Litho使用yoga布局,可以节约内存占用和绘制时间,但是这种情况下不能与用户进行交互了。Litho单独对Event进行处理,可以处理点击、长按、碰触(touch)事件,与View元素对事件处理略有不同,但可以满足基本的需求。

关于Litho的一些想法

1. 关于界面调试

Android开发中我们在xml中定义布局,Android studio有强大的预览功能,所见即所得的体验很棒。Litho提供了对于Stetho 对支持,可以利用chrome的开发者工具对界面进行调试:

其实相比xml,这种方式并不方便,在chrome只是辅助调试,最终还是根据调试情况手动在代码中更新。

2. 开发体验

在写界面时,我们要合理地对界面进行拆分,使用多个组件组合成为一个完整对界面。一个组件定义如下:

@LayoutSpec
public class FeedItemComponentSpec {

  @OnCreateLayout
  static ComponentLayout onCreateLayout(
      ComponentContext c,
      @Prop final Artist artist,
      @Prop final RecyclerBinder binder) {
    return Column.create(c)
        .child(
            Column.create(c)
                .child(artist.images.length == 1 ?
                    SingleImageComponent.create(c)
                        .image(artist.images[0])
                        .aspectRatio(2)
                        .withLayout() :
                    Recycler.create(c)
                        .binder(binder)
                        .withLayout().flexShrink(0)
                        .aspectRatio(2))
                .child(
                    TitleComponent.create(c)
                        .title(artist.name))
                .child(
                    ActionsComponent.create(c)))
        .child(
            FooterComponent.create(c)
                .text(artist.biography))
        .build();
  }
}

例子中我们定义了一个组件,但是我们在逻辑代码中并不会引用到这段代码。Litho会根据componentSpec生的生成真正的component代码:

public final class FeedItemComponent extends ComponentLifecycle {
  private static FeedItemComponent sInstance = null;

  private static final Pools.SynchronizedPool<Builder> mBuilderPool = new Pools.SynchronizedPool<Builder>(2);

  private FeedItemComponentSpec mSpec = new FeedItemComponentSpec();

  private FeedItemComponent() {
  }

  public static synchronized FeedItemComponent get() {
    if (sInstance == null) {
      sInstance = new FeedItemComponent();
    }
    return sInstance;
  }

  @Override
  protected ComponentLayout onCreateLayout(ComponentContext c, Component _abstractImpl) {
    FeedItemComponentImpl _impl = (FeedItemComponentImpl) _abstractImpl;
    ComponentLayout _result = (ComponentLayout) mSpec.onCreateLayout(
      (ComponentContext) c,
      (Artist) _impl.artist,
      (RecyclerBinder) _impl.binder);
    return _result;
  }

  private static Builder newBuilder(ComponentContext context, int defStyleAttr, int defStyleRes,
      FeedItemComponentImpl feedItemComponentImpl) {
    Builder builder = mBuilderPool.acquire();
    if (builder == null) {
      builder = new Builder();
    }
    builder.init(context, defStyleAttr, defStyleRes, feedItemComponentImpl);
    return builder;
  }

  public static Builder create(ComponentContext context, int defStyleAttr, int defStyleRes) {
    return newBuilder(context, defStyleAttr, defStyleRes, new FeedItemComponentImpl());
  }

  public static Builder create(ComponentContext context) {
    return create(context, 0, 0);
  }

  private static class FeedItemComponentImpl extends Component<FeedItemComponent> implements Cloneable {
    @Prop
    Artist artist;

    @Prop
    RecyclerBinder binder;

    private FeedItemComponentImpl() {
      super(get());
    }

    @Override
    public String getSimpleName() {
      return "FeedItemComponent";
    }

    @Override
    public boolean equals(Object other) {
      if (this == other) {
        return true;
      }
      if (other == null || getClass() != other.getClass()) {
        return false;
      }
      FeedItemComponentImpl feedItemComponentImpl = (FeedItemComponentImpl) other;
      if (this.getId() == feedItemComponentImpl.getId()) {
        return true;
      }
      if (artist != null ? !artist.equals(feedItemComponentImpl.artist) : feedItemComponentImpl.artist != null) {
        return false;
      }
      if (binder != null ? !binder.equals(feedItemComponentImpl.binder) : feedItemComponentImpl.binder != null) {
        return false;
      }
      return true;
    }
  }

  public static class Builder extends Component.Builder<FeedItemComponent> {
    private static final String[] REQUIRED_PROPS_NAMES = new String[] {"artist", "binder"};

    private static final int REQUIRED_PROPS_COUNT = 2;

    FeedItemComponentImpl mFeedItemComponentImpl;

    ComponentContext mContext;

    private BitSet mRequired = new BitSet(REQUIRED_PROPS_COUNT);

    private void init(ComponentContext context, int defStyleAttr, int defStyleRes,
        FeedItemComponentImpl feedItemComponentImpl) {
      super.init(context, defStyleAttr, defStyleRes, feedItemComponentImpl);
      mFeedItemComponentImpl = feedItemComponentImpl;
      mContext = context;
      mRequired.clear();
    }

    public Builder artist(Artist artist) {
      this.mFeedItemComponentImpl.artist = artist;
      mRequired.set(0);
      return this;
    }

    public Builder binder(RecyclerBinder binder) {
      this.mFeedItemComponentImpl.binder = binder;
      mRequired.set(1);
      return this;
    }

    public Builder key(String key) {
      super.setKey(key);
      return this;
    }

    @Override
    public Component<FeedItemComponent> build() {
      if (mRequired != null && mRequired.nextClearBit(0) < REQUIRED_PROPS_COUNT) {
        List<String> missingProps = new ArrayList<String>();
        for (int i = 0; i < REQUIRED_PROPS_COUNT; i++) {
          if (!mRequired.get(i)) {
            missingProps.add(REQUIRED_PROPS_NAMES[i]);
          }
        }
        throw new IllegalStateException("The following props are not marked as optional and were not supplied: " + Arrays.toString(missingProps.toArray()));
      }
      FeedItemComponentImpl feedItemComponentImpl = mFeedItemComponentImpl;
      release();
      return feedItemComponentImpl;
    }

    @Override
    protected void release() {
      super.release();
      mFeedItemComponentImpl = null;
      mContext = null;
      mBuilderPool.release(this);
    }
  }
}

所以有个弊端是我们每次修改一个component文件都需要build一次生成可用的代码。对于开发来说体验并不友好。

另外我们可以看下Litho提供的可用组件:

所以如果完全使用Litho来开发一款应用,需要自己实现的控件会非常多。个人认为虽然Litho有诸多好处,对于一般的应用来讲,常规的优化手段已经完全可以满足需求。Litho还是更适用于对性能优化有强烈需求的应用。

3. Litho组件化的思考

Litho使用了类似React的设计思路,而React社区非常的活跃。如果Litho的未来发展的比较良好,可以支撑常规应用开发时,React社区的很多经验就可以借鉴过来,如Redux等工具的实现等。

最后

对于Litho的使用还是一个比较初级的体验,文中如有错误的地方,烦请指出,非常感谢。

推荐阅读:

Android 组件化开发原理和配置

Android组件化开发实践

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 144,247评论 1 305
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 61,830评论 1 258
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 95,531评论 0 214
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 41,345评论 0 183
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 49,160评论 1 260
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 38,936评论 1 178
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,538评论 2 275
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,291评论 0 168
  • 想象着我的养父在大火中拼命挣扎,窒息,最后皮肤化为焦炭。我心中就已经是抑制不住地欢快,这就叫做以其人之道,还治其人...
    爱写小说的胖达阅读 29,162评论 6 237
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 32,654评论 0 214
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,401评论 2 217
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 30,747评论 1 232
  • 白月光回国,霸总把我这个替身辞退。还一脸阴沉的警告我。[不要出现在思思面前, 不然我有一百种方法让你生不如死。]我...
    爱写小说的胖达阅读 24,297评论 1 33
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,206评论 2 213
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 31,670评论 3 213
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,661评论 0 9
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,089评论 0 169
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 33,677评论 2 233
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 33,819评论 2 237

推荐阅读更多精彩内容

  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 170,394评论 25 707
  • 内容抽屉菜单ListViewWebViewSwitchButton按钮点赞按钮进度条TabLayout图标下拉刷新...
    皇小弟阅读 46,271评论 22 663
  • 从小到大发现进步最快的就是刚开始学某样东西的时候,因为这个时候我们对任何事情都保持着好奇心,每天都有十万个问什么等...
    环盈阅读 194评论 0 1
  • 一 从前有一只小兔子 名字叫兔酱 今天天气很晴朗 暖暖的阳光君透过叶片匀匀地洒在兔酱小屋前的草坪上 于是兔酱决定出...
    梵鹤阅读 337评论 0 0
  • Junit的所有测试方法都是以@Test修饰,以public void 开头。如下: @BeforeClass &...
    wangmin阅读 594评论 0 1