[译] 为什么每个 Android 开发者都应该尝试 Flutter

我相信你已经听过一系列关于为什么 Android 开发者应该关注 Flutter 的若干论据（如果你还没有看过，请让我谦逊地建议你瞧瞧这个），但是我想指出一个我还没有真正解决的大问题，那就是 Flutter 可以让你对 App 开发有完全不同的看法。首先，你的应用本身将采用不同的方式构建 —— 但更重要的是，实际的 UI 开发通过将其合并到你的 Dart 代码（而不是 XML）中而被推到前台，因此使它成为了“一等公民”。一旦你的 UI 代码突然出现在一种非标记语言中，你就会意识到你突然有了构建应用的可能性。说实话，在使用 Flutter 之后，我开始讨厌在 Android 上编写 UI 代码；因为在 Android 中步骤更加繁琐，虽然你仍然可以使用数据绑定等工具构建响应式应用，但它实际上比 Flutter 中要花费更多的时间。

当你考虑在 Android 中整合动画和其他动态数据时，使用 Flutter 的论点变得更加有力。整合动画可能会不太方便，有时你可能不得不拒绝设计师的要求，因为要实现他们的需求太难了。谢天谢地，Flutter 改变了这一切。如果你一直在关注 Flutter，你可能已经从 Fluttery 听说过 Flutter 挑战。这些挑战展示了构建具有大量自定义组件和精美设计（包括动画）的复杂 UI 的快速和直观性。在 Android 上实现这样的东西会变得非常困难 —— 特别是因为与 Flutter 不同，Android 的视图基于继承而非组合，这使得构建视图变得更加复杂。

下面，让我们切入正题：使用 Flutter 构建声明性 UI，这改变了 UI 开发的一切。现在也许你在想，Android 布局不也是以声明方式构建的吗？ 答案是肯定的，但事实不是。使用 XML 来定义布局让我们有了以声明方式定义布局的感觉，但如果你的视图是完全静态的，并且所有数据都是以 XML 格式设置的，那么这种感觉才真正成立。不幸的是，这种情况几乎从未发生过；一旦添加动态数据和类似列表之类的东西，你自然必须使用一些 Java / Kotlin 代码将数据绑定到视图。然后我们最终得到某种 ViewModel，它将数据设置为视图。想象一下，这就像在 Android 上调用 textView.text =“Hello Medium！” 一样。在 Flutter 上，这是完全不同的：你创建了一个包含某个状态的窗口组件类，然后根据该状态以声明方式定义你的布局。每当状态改变时，我们调用 setState（） 来重新渲染我们改变的组件树的部分。让我们看一下如何在 Flutter 中使用 API，并使用结果渲染一个 List：

@override
Widget build(BuildContext context) {
return new FutureBuilder(
future: apiClient.getUserRepositoriesFuture(username),
builder: (BuildContext context,
AsyncSnapshot snapshot) {
if (snapshot.hasError)
return new Center(child: new Text(“Network error”));
if (!snapshot.hasData)
return new Center(
child: new CircularProgressIndicator(),
);
return new ListView.builder(
itemCount: snapshot.data.nodes.length,
itemBuilder: (BuildContext context, int index) =>
new RepoPreviewTile(
repository: snapshot.data.nodes[index],
),
);
},
);
}
在这里，我们使用了 FutureBuilder 来等待网络调用（Future）的完成。一旦网络调用完成，出现结果或错误，FutureBuilder 组件会在内部调用 setState 来调用所提供的 builder 方法来重新渲染。正如你在这个例子中看到的，一切都是声明式的。在 Android 上做同样的事情通常需要一个被动的 XML 布局，然后需要一些其他类来手动设置状态，比如 Adapter 和视图模型。这种方法的问题在于，状态可能与屏幕上渲染的状态不同。这就是为什么我们希望拥有像 Flutter 为我们提供的那样的声明性布局。我们最终编写的代码要少得多，同时将状态绑定到要在屏幕上显示的内容。
有了这些声明性布局，我们也开始对架构进行了不同的思考。突然间，reactive 这个词出现了，我们谈论了更多的是关于状态管理的内容，而不是架构。有了 Flutter，像 MVP 和 MVVM 这样的架构已经没有多大有意义了；我们不再使用它们了，而是考虑状态如何流经我们的应用。状态突然成为讨论的一个重要部分，我们将投入越来越多精力去思考构建应用的新方法上。这对我们所有人来说都是一次新的旅程，有许多事情可以解决，但最重要的是，这是我们开阔视野的机会。
坦白地说，Flutter 也不只有阳光和彩虹。我目前正在与 Flutter 合作开展一个更大的项目来了解它的弱点，迄今为止我遇到的最大缺陷是缺乏基础设施。当我尝试使用 Graphql-API 时，这个问题就非常明显；虽然有库确实会这样做，但它们并没有接近 Android 与 Apollo 的关系。不过，好消息是，Flutter 迎头赶上只是时间的问题，在此期间扩展现有的库，甚至建立自己的库并不困难。请注意，你可能需要花一些时间投入在应用程序的基础设施中，而对于 Android 和 iOS 来说，情况通常并非如此 —— 毕竟，天下没有免费的午餐。
最后，我最近从使用 Flutter 中得到的最大启示之一就是，体验这种构建 UI 的声明方式以及它对状态管理的影响是非常有用的。我觉得 Flutter 太棒了；不过，我告诫你不要把它当作解决你所有问题的银弹，而应该是作为一种创新的工具，它可以比在 Android 上更快地构建漂亮的自定义 UI。更重要的是，它展示了强大的声明性布局功能，并让你将应用视为渲染状态，而不是非连贯性 Activity，视图和视图模型 —— 仅此而言，我强烈建议你尝试一下 Flutter。

如果发现译文存在错误或其他需要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

最后

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【算法合集】

【延伸Android必备知识点】

【Android部分高级架构视频学习资源】

**Android精讲视频领取学习后更加是如虎添翼！**进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

实战项目源码讲义》点击传送门即可获取！**