视频先行
下面是视频内容的脚本整理稿。如果你看了视频，那下面的文稿就不用看了。
正文
「学 Compose 还是学自定义 View？」这个问题从去年初我发第一个 Compose 主题的视频到现在，一直有人问我。这个问题的背后表达了一种担忧：会不会等我学完自定义 View，它却过时了？
大家好，我是扔物线朱凯。
最近情况比较特殊，我被封在小区里了。虽然办公室就在马路对面，但是咫尺天涯，我还是拿不到我的摄像设备。所以今天就用手机来录一期。
今天来跟大家聊聊「学 Compose 还是学自定义 View」的问题。
首先我们确定一下前提：这是个个人职业发展角度的讨论，也就是所谓的利益导向。关于 Compose 和自定义 View 哪个更好或者我更喜欢哪个，在这个视频里不做讨论。
从原理看，Compose 似乎可以取代 View
大家更关心的是【**现在】**学哪个，如果让我简单直接地回答：自定义 View。但这个话题不是一句话这么简单，如果你打算做出最适合自己的决定，你最好把整个视频看完。
首先，我们来做一个对未来的展望：Compose 作为 Android 官方给出的新的 UI 方案，未来可以完全取代 View 的方案吗？
Compose 是基于 View 系统的，它的原理是通过一个自定义的 View，去对它的 onMeasure()、onLayout()、onDraw()、dispatchTouchEvent() 等等方法进行深度定制，来实现「在同一个 View 的内部完成整个 UI 组件树」这样的效果。也就是在 Compose 代码里面，你写的一个包含了多层复杂组件的完整界面，它实际上有可能全都被绘制在了同一个 View 上，并且触摸事件也都是由同一个 View 来进行实际承载和识别的。
由于这样的底层原理，Compose 是不会有能力上的天然限制的，也就是传统 View 方案能做的事 Compose 全都可以做，比如各种复杂的动画、手势、嵌套的多层级布局，Compose 都可以做到。这个我在读 Compose 的代码之前还有点打鼓，在读完它的代码之后我是非常确定的。
Compose 没有做出对等实现的只有 SurfaceView 和 TextureView 这两个类，它们是用于高速刷新的内容的，比如视频播放或者相机的取景器界面。你在写 Compose 代码的时候如果想用到它俩的效果，你找不到对应的 Compose 组件，而是需要老老实实去用原生的 SurfaceView 或者 TextureView。但是这是因为它俩的核心并不是 View，而是 Android 所提供的那一套跟 Surface 类相关的显示系统，所以不管你用 Compose 还是不用 Compose，这俩东西都是单独学的。换句话说，就算不用 Compose，有几个人知道怎么用 SurfaceView 的？——就是这个道理。
所以，从原理的角度来看，Compose 是有能力完全取代 View 的。
但短期内不会发生
那么下一个问题就是：这件事真的会发生吗？Compose 理论上有能力取代 View 是吧？但它未来真的会取代 View，成为写 UI 的主流做法吗？
首先我觉得是会的。Compose 发展到现在，虽然还没有达到完善的形态——比如传统 View 系统的某些官方组件或者开源组件，Compose 里还没有相应的实现，以及滑动组件的性能现在和传统的 RecyclerView 还有差距——但是到现在为止，Compose 和 View 系统的这些差距，已经没有不可弥合的了。只要给它几年时间，这些差距都能补齐。Compose 这个东西，最大的风险在于官方开发了几年之后，发现它的坑太大，怎么都填不平，最终弃坑，宣布砍掉 Compose 项目，让大家回到 View 去。官方弃坑，这是 Compose 最大的风险。但是我可以告诉大家，现在 Compose 已经迈过这个坎了，它现在遗留的都是一些靠时间来慢慢打磨就可以解决的小问题。再加上 Android 官方的态度也是非常坚决，要让 Compose 替代 View 成为新的 UI 方案，所以 Compose 取代 View，已经是必然会发生的事情了。
但是！有一个问题是，这种替代短期内并不会完成。
为什么？因为当下几乎所有公司的现有代码都是基于 View 系统的。你写新代码当然可以选择 Compose，但是老代码维护的时候不还是要和 View 打交道吗，是吧？——不过这个其实也和环境有关系，我们国内有一个情况是，巨型 App 比较多。一个软件的规模越庞大，它转身就越慢，那些巨型 App，它本身就非常复杂了，你往里面加任何一个新依赖都会进一步增加它的复杂度。更不用说 Compose 这种 UI 库，它的接入一定不是一个所谓的大规模重构就替换完成了，没人敢这么干，肯定会是一个渐进式的替换过程，今天替换这个界面，明天替换那个界面。那么对于大项目来说，就会在相当长的时间里，团队需要同时面对两种 UI 方案进行开发，这样一是增加了出问题的风险，二是会长时间降低团队的开发效率——Compose 是提升开发效率的对吧？但是在切换过程中，它是降效的。所以你会发现，大公司很多都已经在尝试 Compose 了，但没有一个是已经进入了全面替换的流程了的。这个国内和国外的公司都是这样，而我们的大公司往往 App 的规模要比国外的大很多，这个大家应该知道。
所以在接下来的几年，我们的大公司肯定会是在谨慎的探索中，慢慢地切换到 Compose。
学哪个？
那么，回到刚才开头的问题：学哪个？
我的观点是：对于当下这个时代，你如果有时间，双修——Compose 和自定义 View 两个都学——是对我们的职业发展最负责的选择。而如果你的时间不够，只能先学一个，那么去学自定义 View。虽然我现在有一门 Compose 的课程，但是我还是得说，这玩意是面向未来的，现在从找工作的角度考虑，最硬的还是自定义 View。其实我对我这门 Compose 课程的期待也是面向未来的，虽然它目前的销量已经大大超出我的设想。
不过有些人学 Compose 是为了吃时代红利，是想在早期成为一个 Compose 高手，然后出名啊或者在公司做 Compose 方向的顶梁柱啊什么的，这个我觉得没问题，那你现在就学 Compose 是可以的。但这就是另一个思维方向了。
总结
好，关于「学 Compose 还是学自定义 View」，今天就聊到这里。如果你喜欢我的视频，还请点赞关注收藏转发，你们的支持对我非常重要。我是扔物线，我不和你比高低，我只助你成长。
版权声明
本文首发于：https://rengwuxian.com/compose-vs-view/
微信公众号：扔物线
转载时请保留此声明
