java软件 java软件制作在线教程 收藏 0

程序员必知的8个Java开源IDE工具！你最钟意哪个？

出色的Java工具有助于提高工作效率。Java IDE 工具提供了多种用户独特需求和个人偏好来创建编程环境的方法。

今天，给大家分享8个程序员最爱的Java开源IDE工具，

没有用过的小伙伴，快快收藏哦！

01 BlueJ

BlueJJava环境下的一个内置编辑器、编译器、虚拟机、调试器的多应用软件，是专为教学设计的，很适合在小规模的软件开发中使用。它易于使用和测试的交互式界面，不仅适合用于在学校教授Java编程课程，而且允许程序员调用功能，即对象、方法、参数等，而无需编译源代码。

02 Eclipse

Eclipse是一款主要用Java编写的免费IDE，允许创建各种跨平台的可用于手机、网络、桌面和企业领域的Java应用程序。

它的主要功能包括Windows生成器、集成Maven、Mylyn、XML编辑器、Git客户端、CVS客户端、PyDev，并且还有一个基本工作区，有可扩展插件系统可满足自定义IDE的需求。通过插件，也可以用C、C ++、JavaScript、Perl、PHP、Prolog、Python、R、Ruby（包括Ruby on Rails框架）等语言开发程序。

03 IntelliJ IDEA

IntelliJ IDEA CE(社区版)是IntelliJ IDEA的开源版本，为Java、Groovy、Kotlin、Rust和Scala等提供IDE。可用于现有的源重构，代码检查，使用JUnit或TestNG构建测试用例，以及使用Maven或Ant构建代码。IntelliJ IDEA CE的优秀功能有API测试仪，允许通过Swing GUI设计器测试API的功能，很多经验丰富的程序员尤其喜欢IntelliJ IDEA CE。

04 Netbeans IDE

NetBeans IDE是一个集成的Java开发环境，它能为独立的、移动的和web架构设计模块化的应用程序，并支持web技术。NetBeans IDE能建立关于如何有效管理项目、工具和数据的多个视图，并可以在新开发人员加入项目时进行软件开发协作。

05 VSCodium

VSCodium是一个免费的源代码编辑器，它在Windows、macOS、Linux上皆可用。它是一个基于Visual Studio代码的开源替代品，支持多种编程语言，如Java、c++、c#、PHP、Go、Python、.net等。

06 jEdit

jEdit是一个具有广泛插件架构的文本编辑器，具备编辑搜索，查找，替换和源代码编辑等功能，支持超过两百种语言，包括Unicode。

07 jGRASP

jGRASP是运行在Java平台上的IDE，提供可视化自动生成，能在运行时产生静态可视化的源代码结构和直观化的数据结构，且jGRASP能产生支持Java、C、C ++、Objective-C、Python、Ada和VHDL的控制结构图；支持Java和Ada的复杂文件图表；支持Java的UML类图；还有动态对象查看器和结合了集成调试器和Java工作台的画布查看器。

08 JSource

JSource是免费的Java IDE，尤其在创建跨平台的Java应用程序中非常有用。JSource能运行、编译、编辑和创建Java文件，主要特点是支持多种语言的语法高亮显示和Java Swing组件。

程序员最爱的8个Java开源IDE工具你收藏了吗？如果还有什么想要了解的，或者你有其他更好用的IDE，欢迎大家在下方留言探讨！

11款常用Java编程软件推荐(建议收藏)

大家好，我是mikechen。

优秀的Java编程软件可以极大的提升我们的开发效率，所以今天给大家推荐一波必备Java编程软件@mikechen

本篇已经收纳于mikechen创作的《阿里架构师进阶专题合集》里面。

Eclipse 是一个开放源代码的基于Java的可扩展开发平台，Eclipse是IDE领域的瑞士军刀，有着大量定制的接口和无数的插件。

Java开发环境，最早使用比较多的就是：Eclipse ，有调查表明，Eclipse仍然是几乎半数Java开发人员在使用的开发环境。

eclipse官方网站https://www.eclipse.org/downloads

IDEA 全称 IntelliJ IDEA，是JetBrains公司的产品，IntelliJ在业界被公认为最好的java开发工具之一。

IntelliJ尤其在智能代码助手、代码自动提示、重构、J2EE支持、各类版本工具(git、svn、github等)、JUnit、CVS整合、代码分析、 创新的GUI设计等方面的功能可以说是超常的。

现在主流的 Java IDE 开发工具非 IntelliJ IDEA 莫属，前几年，可能 Eclipse 还能和 IDEA 一争高下，到了现在已经基本是 IDEA 的天下了。

IntelliJ IDEA官方下载地址：

https://www.jetbrains.com/zh-cn/idea/download

对于项目中的代码版本管理工具，Git 已经处于垄断地位了，新项目的话不需要再考虑 SVN、CVS了。

之所以 Git 现在处于垄断地位，主要胜在 2 点：

Git 是分布式的，不会因为版本管理服务器崩溃导致完整的代码历史版本丢失。

Git 创建分支是非常廉价的操作，可以随意创建分支，从而使并行开发很容易落地，而 SVN、CVS 这些版本管理工具创建分支则非常笨拙，并行开发非常麻烦。

上述第 1 点大大提升了代码资产的安全可靠程度，第 2 点则完美适应当代的敏捷开发需求，因此，Git 大行其道就不足为怪了。

Git官方下载地址：

https://www.git-scm.com/download/

Java 项目的构建工具现在是龙争虎斗，业内一般有两个选择：Maven 和 Gradle。

如果是后端的 Java 项目，那绝大部分用的还是 Maven 去构建项目，如果是前端的 Android 项目，则选择 Gradle。

maven官方下载地址：

https://maven.apache.org/download.cgi

Gradle官方下载地址：

https://gradle.org

在学习数据库的时候，经常接触到Navicat这个管理数据库的工具，Navicat是Java程序员必备的工作伙伴。

Navicat是以直觉化的图形用户界面而建的，可以让使用者安全并简单的方式创建、组织、访问并共用信息，它可以用来对本机或远程的MySQL、SQL server、SQLite、Oracle及PostgreSQL数据库进行管理及开发。

Navicat官方下载地址:http://www.navicat.com.cn/download/navicat-premium

FindBugs 是一个静态分析工具，它检查类或者 JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具，就可以在不实际运行程序的情况对软件进行分析。

FindBugs下载地址

http://findbugs.sourceforge.net/downloads.html

很多开发者并不使用人工仓库管理JARs，WARs，库和应用，但是如果想这么做的话，Nexus是最好的选择。

Sonatype Nexus官方下载地址：

https://www.sonatype.com/products/repository-oss-download

JMeter是Apache组织开发的开源项目，设计之初是用于做性能测试的，同时它在实现对各种接口的调用方面做的比较成熟，因此，常被用做接口功能测试和性能测试。

JMeter是现在比较热门的 web 性能测试工具，由于具有开源、免费、轻巧等特点，现在较多的测试人员选择用 jmeter 来替代 loadrunner 做自动化测试。

JMeter除了能做 web 性能测试，还能做 web 接口测试。

Jmeter官方下载地址：

https://jmeter.apache.org/download_jmeter.cgi

JAD 是一款老牌的、经典的、使用起来简单的 Java 反编译工具,和eclipse的插件JadClipse,二者结合可以方便的在eclipse中查看class文件的源代码。

1. 从官网 https://sourceforge.net/projects/jadclipse/ 下载 jadClipse 的 jar 包到 eclipse 根目录下的 dropins 目录中（没有这个目录则新建）
2. 重启 eclipse 导航到 Windows -> Preferences -> Java -> jadClipse （如果没有出现这一项，删除 eclipse 根目录下的 configuration/org.eclipse.update 文件夹后重启 eclipse）
3. 在 Path to decompiler 中输入下载的 jad 的路径，如 D:\\dev\\jad158g.win\\jad.exe
4. 导航到 Windows -> Perference -> General -> Editors -> File Associations 将 *.class 和 *.class without source 默认编辑器都设置为 JadClipse Class File Viewer
5. 然后就可以直接打开 .class 文件进行查看了

除此之外，Java反编译工具还有多款，比如：JD-GUI Lutyten CFR Arthas，详情请查看这篇文章Java反编译工具详解(4款主流反编译工具)

VisualVM 是一款免费的，集成了多个 JDK 命令行工具的可视化工具，它能为您提供强大的分析能力，对 Java 应用程序做性能分析和调优。

VisualVM 功能包括生成和分析海量数据、跟踪内存泄漏、监控垃圾回收器、执行内存和 CPU 分析，同时它还支持在 MBeans 上进行浏览和操作。

VisualVM 提供在 Java 虚拟机 (Java Virutal Machine, JVM) 上运行的Java 应用程序的详细信息，在 VisualVM 的图形用户界面中，您可以方便、快捷地查看多个 Java 应用程序的信息。

VisualVM下载地址

http://visualvm.github.io/

Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，主要用于持续、自动的构建/测试软件项目、监控外部任务的运行。

Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT，构建工具有Maven、Ant、Gradle。

Jenkins 官方下载地址：

https://www.jenkins.io/download/

本篇已经收纳于mikechen创作的《阿里架构师进阶专题合集》里面。

Kotlin 风险高、RxJava 已过时，Android 原生开发现状分析

当你好不容易学会了某个框架或者工具，觉得它很好用的时候，它或许就要过时了。

作者 | Vasiliy Zukanov，已获翻译授权

译者 | 罗昭成，Android 开发者；责编 | 唐小引

封图 | CSDN 付费自东方 IC

出品 | CSDN（CSDNnews）

许多 Android 开发者经常会问我，要学会哪些东西才能成为一个优秀的 Android 工程师？对于这个问题，他们的描述或多或少都有些差异。但是，总体来说，我们都需要学习一系列的技能，才能成为一个优秀的 Android 工程师。

Android 原生开发的生态系统变化得非常快。至少在过去的五年时间里，我经历过很多 Android 的变化，并且花费大量的时间参与其中。这几年里，Google 每两到三年，就会推出一组新的库和框架作为官方 Android 原生开发的指导方针。我花了大量的时间，回顾了这几年的变化，希望从中找出好坏。我相信，有很多的 Android 开发者，也和我一样。

过去的一年，大量的内容被添加、被废弃或被删除，文档被更改，新的官方指导方针被引入等等。即使我以 Android 原生开发生态系统的的标准来看待这些问题，所发生的这些事情，都是非常疯狂的。当我开始思考这些内容的时候，我已经无法在我的脑海中描绘出一个完整的、详细的 Android 开发环境。

因此，我决定要花一些时间去整理这些内容，然后再来写这篇文章。本文中，我会试图去总结 Android 原生开发的生态系统中发的事情，并且对原生开发未来的走向做一些预测。我会将我的想法分成不同的章节去叙述，这些内容没有特定的顺序，但我会把最有争议的内容放在文章最后。

我希望我的这篇文章可以给你带来一些启发和帮助，但是你需要记住，本文不可能包含所有的内容，有可能会漏掉许多重要的观点，并且本文中的内容可能会包含我个人的一些偏见。

AndroidX

这个事情说起来有点儿疯狂，Google 官方在一年半前就发布了 AndroidX 的预览版本。并且在一年前， AndroidX 库就已经很稳定了，与此同时，Google 官方也宣布不再对遗留的库进行支持与开发。（在我写这句话的时候，我想起我之前在 StackOverflow 上提的一个问题：为什么要将新的 API 放在 Support 库中，而不是 SDK 中？[1]）

用“稳定”来描述 AndroidX 这个库有点讽刺，现在关于 AndroidX 的任何东西都是不稳定的。Google 不断地在 AndroidX 下添加新的库和框架，使用 androidx 作为命名空间。许多“老”的 API（目前还不到一年）以非常快的速度发展。

到目前为止，我已经将两个应用程序迁移到了 AndroidX 上了。一切都很顺利，我已经不记得在这个过程中，带给了我多少的“惊喜“。Google 也提供了一个工具，Jetifier 可将依赖于支持库的库迁移为依赖于等效的 AndroidX 软件包，一个非常好用的工具。然而，即使是一个很小的工程，也不能实现“一键迁移”。

我也参与了没有迁移 AndroidX 的项目（项目并不计划迁移到 AndroidX）， 现在也没有任何问题，所以，不迁移 AndroidX， 在有些情况下，也是一种可行的方案。

总而言之，在新的 Android 项目中，直接使用 AndroidX。并且，针对老项目，我也推荐你们将迁移到 AndroidX 列到计划中，虽然现在你看不到迁移 AndroidX 过后，带来的任何收益。无论如何，你都有可能在某个时间点进行 AndroidX 的迁移，所以最好能够按照自己的进度进行迁移，而不是在 6 个月后，你需要使用某个新的 AndroidX 库时，再进行紧急迁移。

Jetpack

在讨论 AndroidX 过后，还必须要提到 Jetpack。在我的印象中，Jetpack 开始是作为“架构组件”的一把保护伞推出的。但是到后面，引入了几乎所有关于 AndroidX 的 API。因此，现在来看，我们看不到它与 AndroidX 之间的任何区别，除了 Marketing 和 PR（即市场和公关）。

当你查看 Jetpack 主页[2]时，会发现，这个页面并不是一个技术文档页面。这个更像是一个早期的 SaaS 页面。

看看例子，开发者“赞誉”：

开发者赞誉

或者“信赖应用”列表：

信赖应用

这些在市场公关层面更受，如果 Jetpack 在 2020 年申请独立 IPO，我都不会感到惊讶。

不过，说真的，尝试向自己生态系统内的开发者“销售”API 的想法，我觉得存在一些问题，比如说，谁会想看出来第一个就是 ViewModel 广告呢？

Android ViewModel

总而言之，Jetpack 只是 AndroidX 库的一个聚合，所以在前面写到的 AndroidX 的内容，在很大的程度上也适用于 Jetpack。在后面的内容中，我将单独讨论其中一些 API。

后台作业

在 Android 应用程序不在前台执行逻辑时，你可以有很多种方式来实现后台运行，这也是 Android 动态化的用例之一。如果你不引入 doze , SyncAdapter , CGMNetworkManager , FirebaseJobDispatcher , JobScheuler 和最近的 WorkManager，可以使用常规的启动服务（非绑定服务）来实现。这些都是 Google 提供的 API ， 我可以说出所有的使用方式。当然，还有一些第三方库可以使用， 例如：Android-Job。

不过，Google 最近宣布，他们将围绕 WorkManager 来统一后台任务调度[3]。这听起来非常棒，我再也不用学习那么多后台调度的知识了，只是，不知道为什么，我好像以前在哪儿听到过这句话……

我们不管将来是否会统一使用 WorkManager，WorkManager 都还存在一些问题，比如可靠性。我不想在本文中解释为什么，但是请你一定要记住，如果你想在应用程序中使用 WorkManager，实现后台作业，一定要去读一下 dontkillmy 上的所有内容，并且要一下与 WorkManager 相关的 Google 问题列表[4]。

Android 的后台作业由于碎片化等原因，导致它们一团糟，而且还很不可靠。

在过去，我一直主张尽可能对数据和其它类型的后台处理进行同步。我或许是 SyncAdapter 最后的粉丝。今天，考虑到可靠性的问题，我，尽可能避免后台作业。如果你的老板一直坚持要使用这个功能，请将上面的链接发给他们，告诉他们，后台作业可能会需要数百小时的工作，才能实现，并且它带来的问题也会比它带来的好处多很多。

很多情况下，后台作业的需求是不可避免的。但是在大多数情况下，你都可以不使用它。虽然有时候会给用户带来一些不便，但是这可能是到目前为止的最佳方案。

数据库

在有关 SQLite ORMs 的内容里面，没有什么令人吃惊的内容—— Room 主宰着一切。Room 从 2.2.0 开始，添加增量注解解析支持。不过，请你一定要记住，你应用程序的架构不应该关心你使用的是什么样的 ORM 框架。说到 Room，“架构组件”也只是一个营销术语，并不是一个技术角色。

在 Android ORM 框架中，与 Room 竞争的主要是 SQLDelight。这是一个比 Room 老很多的库。但是据我所知，在过去的一年里，它几乎被全部重写。但新版本的 SQLDelight 只针对 Kotlin。另一方面，SQLDelight 也支持 Kotlin Multiplatform，所以，随着 Kotlin 使用的增多，我预计， SQLDelight 的采用率也会随之增加。

顺便说一下，在 AndroidX 的命名空间下，也有 SQLite 的镜像。我不知道这个会有什么用处，但是如果你在应用程序中直接使用 SQLite，也可以对这个进行深入的研究。

此外，我们也不要忘记非关系型数据库，比如 Realm、Parse、Firebase、ObjectBox 等等 （其中一些，核心还是使用的 SQLite 来实现的），如果我没有记错的话，这些非关系型数据库中，大多数（甚至全部）都具有自动数据同步的功能。在之前有段时间里，它们非常地流行。但是现在，据我所知，已经不再流行了。也就是说，在短期内，我会持续非关系型数据库。

去年，我写了一个非常复杂的应用程序，对接了一个 Parse 的服务。这个 具有完全的离线支持，服务端本地化，用户指定的系统和语言设定，复杂的多媒体系统等功能。我在 Android 端上使用了 Parse 的 SDK。除了一些小的 WTF 以外，其他体验都非常棒。如果你们公司有很多后台开发人员，或者说你需要实现大量的服务端逻辑，这也许并不是最佳解决方案。但是对于仅仅只需要执行简单的 CRUD 操作的初创公司，这或许是一个不错的选择。

一个警告：如果你打算采用数据库即服务解决方案（如 Firebase），请你一定要长期使用的成本和影响。

外部存储

Android 外部存储发生了一个“很有意思”的变动。

如果，你在开发 的时候，把 Target API 调整为 29 及以上，之前获取 SD 卡文件的方法，现在都不能使用了，并且不会提示任何异常[5]。现在，你需要使用 Android 存储访问框架来进行更细粒度的文件访问。不幸的是，Android 存储访问框架的工作原理与之前的读取方式完全不同，你可能需要对代码进行大量的重构，来实现新的文件访问和读取。

Google 原本希望在 Android 10 上，对所有的应用程序进行文件访问的限制，推广使用 Android 存储访问框架的方式进行文件访问。但是这个改动引起了社区内的强烈抗议，所以 Google 决定推迟推出这个功能。因此，现在即使你的应用程序在 Target API 29 及以上，也可以设置为在“Legacy”模式下可读取文件。不过，有可能在 Android 的下一个版本，不管你设置的 Target API 为多少，都会限制应用程序使用新的作用域访问模式。

到目前为止，我也还没有更新我应用程序的文件访问方式。但是从互联网上的讨论来看，实现新的文件访问方式是一项很具挑战的任务，虽然你的应用程序在“Legacy”模式下，没有任何异常，但是我你最好从现在开始，着手对代码进行重构和测试，以防发生不可控的事情。

Shared Preferences

在几周前，AndroidX 家族增加了一个新的库，这条提交信息写道：

新的库用来替换 SharedPreferences，新库的名称还没有确定下来，这次提交只是为了评审和设计文档（请自行申请设计文档）。

现在还没有什么值得担心的。不过，从长远来看，SharedPreferences 会被废弃掉，取而代之，使用新的库来实现类似的功能。

与 SharedPreferences 不同的是，这个新的库默认情况下使用的是异步的方式[6]。换句话说，如果你需要取某个值，你需要实现回调，通过这个回调才能拿到值。

如果你对这种异步回调的原理感兴趣，你可以去看看 StackOverflow 上的这个回答[7]。Reddit 的一个用户 Tolriq 分享了他们的 遇到的一个 SharedPreferences 的 Bug，这个问题影响了万分之一的月活用户。对于一般的应用程序来说，这个问题并没有什么明显的影响。但在一些需要高可靠性的应用上，就显得很不可靠了。举个例子，如果在 Android 汽车上，应用程序的无响应和崩溃会引起驾驶员的注意力被分散，这将有可能导致出现交通意外。

依赖注入

在依赖注入领域，最大的新闻莫过于 Dagger-Android 被弃用，有两点需要强调一下，首先我所说的弃用，不是正式的弃用，因为官方并没有发布声明。其次，Dagger-Android 并不是指整个 Dagger 2 框架，只是指其中相对比较新的部分。详细细节可以看我的另一篇文章[8]。

在 Android 领域也存在其他的依赖注入框架，但是我不认为他们会比 Dagger 更好。值得一提的是，Koin 是一个不错的依赖注入框架，但是我依然觉得它也不会引起多大的潮流。它之所以会被采用，无非是这两个原因，一个是，它拥有比 Dagger 好很多的文档，降低了很大的学习成本。第二个是它基于 Kotlin 进行编写，因为 Kotlin 的热度，给它也带来了不少的。到目前为止，Kotlin 的热潮几乎已经全部过去了，所以，我预测，Koin 的也将会逐渐减少。

不管这些框架如何发展，手动依赖注入的发展都会很缓慢。

Google 声称：随着应用程序的增大，手动依赖注入的成本会出现指数级增长。但是我并不这么认为，我觉得 Google 既不了解 \”指数\” 的含义，也没有实际去“衡量”过任何东西。这个申明的内容是错误的，我希望 Google 不再使用这种方式误导社区。

事实上，这种手动依赖注入在后端比较常见（尤其是微服务中，你并不想在每个服务中都添加对注入框架的依赖），也可以正常的工作。在后端，反射被经常用到，所以后端的依赖注入框架并不需要解析编译时的代码。

在 Android 上，解决方案与后端有一些不同，我们几乎不会用反射方案的依赖注入框架，所以就只剩下 Dagger 可以用了。其实，反射虽然会影响性能，但是在大多数项目，都是可以用的。我的意思并不是你们使用反射方案的依赖注入框架，这个选择并非是非黑即白的，你需要按照你的要求来进行选择。

无论如何，Android 领域上， Dagger 作为依赖注入框架的现行标准，我们所有人都在使用它。尽管 Google 在宣传上，对 Dagger 的使用成本使用漂亮的绿色图形进行展示，但是 Dagger 使用成本在实际上依然会随着时间增长而快速增长。越来越多的代码，在编译构建的时候需要花费更多的时间；你的开发人员越多，代码编译的次数就越多。当然，所有的开发人员都需要学习如何使用 Dagger ， 这本身就是一项很大的成本。

换句话说，虽然 Dagger 可以减少项目中编写的代码，但是需要花更多的时间去培训新人，在编译上花费更多的时候。所以，对大型项目来说，使用 Dagger 会更耗时。

在一个大型项目中，编译耗时会逐渐成为生产力的瓶颈。当然， Dagger 也提供了很多优秀新的功能来帮助你优化编译时间，但前提是，你需要知道如何使用这些工具。读到这里，我相信你对手动依赖注入会很感兴趣。

数据绑定

作为一个 Android 开发者，都知道在写布局的时候，会经常调用 findViewById 这个方法。DataBinding 诞生就是为了取代掉这个模板方法。老实说，在使用 findViewById 的时候，我并没有遇到过任何问题，虽然希望摆脱掉它，但我并不认为使用 DataBinding 就是一个更合理的方式。有一个好消息，很快我们就可以使用 ViewBinding 来摆脱 findViewById 了，也不需要使用 DataBinding。

说句实话，我不相信 DataBinding。对于它想解决的问题来说，这种方案在过于复杂。在使用 DataBinding 的时候，需要把代码逻辑放到 XML 布局中，这听起来很不错，但是经验丰富的开发人员都不会这么做，这个做法也是 Databinding 的另一个缺点。

早在 2016 年 11 月的时候，那个时候 Google 还在大肆宣传 DataBinding。我在 StackOverflow 的回答中作了如下预测[9]：

我可以非常自信地预测：DataBinding 不会成为行业标准。DataBinding 可以带来短期收益，但是从长远来看，它将会使代码变得不可维护。一旦 Databinding 被长期使用，它的缺点就会暴露出来，将来它一定会被废弃掉。

我没有统计过使用 DataBinding 的项目，但是很明显，它没有成为行业标准。我从来没有在自己的项目中使用过它，也很少看到其他开发者使用。据我猜测，当 ViewBinding 逐渐成熟，并且被广泛采用，DataBinding 将会作为一个“传统”框架，大量地被引用到。

状态保存

自从引入 ViewModel 架构组件以来，在 Android 应用程序中，当配置发生更改，保存与恢复状态的逻辑，就变成了一个烂摊子，没有人去管理。虽然这样子说有点过分，但是我觉得，这已经是我最温和的表达方式了。

Gabor Varadi（又叫 Zhuinden）在 Reddit 论坛中描述了 ViewModel 引入带来的问题[10]，我不需要再去写一遍了。再次强调，不推荐使用 onRetainCustomNonConfigurationInstance，推荐使用 ViewModel。

在帖子的末尾，Gabor 作了一些预测：

你知道吗？Fragment 状态保存的方法已经被弃用了[11]。

在我看来，废弃 Fragment 状态保存的方法是非常好的主意，， Fragment 的 onAttach 和 onDetach 方法就是为了支持状态保存的，现在废弃了状态保存的方法，那这两个方法也可以被废弃掉，并且这样子可以简化 Fragment 的生命周期。我长期以来都不保存 Fragments 的状态，忽略掉 onAttach 和 onDetach 方法，和我之前写的处理 Framgent 生命周期方法一致[12]。

尽管有很多理由表明，要废弃掉 Fragment 的状态保存，但是也不可能废弃掉 onRetainCustomNonConfigurationInstance，这个可不是我说的，是 Jake Wharton 说的。在上面 Gabor 的帖子上，他的回复获得了最多的点赞。虽然我不太赞成 Jake 所说的话，但是我找不到更好的理由去说服自己。这个方法和 ViewModel 后台使用的原理完全一致，完全没有理由废弃掉它。

那我们应该怎么对待这些废弃的方法呢？Google 不管这些方法使用的技术方案和优势，都强制所有的 Andorid 应用迁移到 ViewModel。即使这些方案有可能优于 ViewModel 本身，他们也愿意放弃。听起来有点像是阴谋论吧。

我确实不喜欢保存非配置的状态，并且废弃掉对我没有任何影响，因为我从来都没有使用过它。事实上，大多数应用程序都不需要这些方法，当然，ViewModel 也不需要。我们需要处理状态改变的方法仅仅只有 onSaveInstanceState(Bundle) 这个方法。这个方法非常简单明了，可以同时处理保存和恢复的逻辑。所以，只要能用这种方式保存状态就可以了，我相信，我不是唯一一个使用这个方法的人。虽然 Google 对 ViewModel 进行了大量的营销宣传，但是对于很多经验丰富的开发者来说， ViewModel 还是太复杂了，我们有更简单有效的方法来处理状态存储。

如果 Google 别有用心，想强制所有项目使用 ViewModel ， 那么它还将废弃掉 onSaveInstanceState(Bundle)方法。这听起来有点不可思议，如果将来真的这样发展，那说明我的基础理论是正确的。

考虑到 Android 的内存管理机制，Google 不可能在没有稳定的解决方案之前就废弃掉 onSaveInstanceState(Bundle) 。“幸运的是”，我们已经可以使用 ViewModel 来完成相关工作了。

我想，在一两年内，就能看到我的理论是否正确。

总而言之，如在本节开头所说，Android 状态保存将变成一个烂摊子。两年多前，我曾经写过 ViewModel 架构组件有害的文章[13]时，我就预测 ViewModel 会对保存与恢复状态的一点点造成影响。我所预测的都变成了现实，而且现在的情况比我曾经的预测更糟。

并发

在 Android 并发编程中，一个重要的 API 就是 AsyncTask， 不过它现在已经被弃用掉了。我之前已经写过很详细的文章分析过它了[14]，在这里，将不再赘述。

下面我要说的内容，有可能会伤害很多读者，但是，请不要“恨”我。

RxJava，是一个 Andorid 中常见的多线程框架。但是它现在将逐渐退出历史的舞台。从 StackOverflow 的趋势图可以看出：

RxJava 使用趋势

很多开发者对这个说法提出了质疑，他们反驳说这个数据不具有代表性，并且我们可以找到其它的理由来解释图上所发生的事情。他们所说可能是正确的，我个人本身也不是数据科学家。但是从图中我们可以看到，RxJava 与 AsnycTask 有相同的斜率。

如果你没有时间去学习 RxJava 如何使用，并且你的项目中也没有使用过 RxJava，我你不要在你的项目中使用 RxJava。事实上，我也一直不推荐使用 RxJava ，现在已经有数据支持我的这个观点了。

如果你的项目中使用了 RxJava，你也不用慌张，不需要紧急去重构你的项目。如果你的项目只有你一个人，或者整个项目组成员基本不会变动，保持项目现状就好了。但是你需要记住，以后要招具有 RxJava 开发经验的人会越来越困难，新招开发人员可能需要学习使用 RxJava。广泛使用 RxJava 的项目，在以后也会被认为\”不酷\”，就像今天还在使用 AsyncTask 和 Loader 的项目一样。

我知道，很多 RxJava 的开发者都是 RxJava 骨灰级的粉丝，他们花了数周的时间去学习 RxJava，付出巨大的努力才说服队友在项目中使用 RxJava。现在我却在这里说 RxJava 已经过时了。我只能说，这不是我的个人意见，我只是对现有的情况进行分析，并根据我所看到的内容做出预测。我也有可能是错的。两军交战，不斩来使，请大家不要“攻击”我。

在 Kotlin 中，使用协程来实现多并发。最近使用协程实现了一些简单的用例[15]，我发现它复杂、不稳定，甚至还有一些 Bug。

所有的人都在说，协程可以降低并发的复杂度，使用并发变得简单。我从来都不相信这句话，因为我知道并发从根本上来说就是很复杂的。我动手写过一些测试用例过后，据我的经验，我可以很自信的告诉你，协程不能使并变得简单。我认为，协程会增加复杂性，我你们谨慎使用他们。

在 Kotlin 中，协程将作为处理多线程的默认方式，如果你已经开始使用 Kotlin 进行开发，那么你应该花点时间，去学习一下，协程的使用。

据我所知，还有一个 Flow 框架，它是基于协程，添加了流运算符。在几个月之前，已经稳定了。所以现在也没啥好评价的。

Kotlin

现在，让我们来讨论一下 Kotlin 在 Android 领域的现状。根据我个人的经验来看，这是一个很的话题，不论我所说的话有多么公正客观，都会有一些粉丝评价我所说的话是“Shit”。但从专业的角度来说，Kotlin 的话题是跳不过去的，所以，我要强调的是，这些内容只是我的个人观点，仅供参考。

在 Android 开发中，使用 Kotlin，会地增加你的编译时间。

在我的另一篇文章中[16]，我统计了使用 Kotlin 过后，编译时间的增长情况。结果是，全量编译的情况下，会增加 18%左右的耗时，如果是增量编译，则会增加 8% 左右的耗时。

Uber 和 JetBrains 联合发表了他们有关 Kotlin 对项目编译时间的影响， 在文章中，显示的结果非常的悲观。他们表示，如果你不开启 IDE 中的 annotation processors ，引入 Kotlin 的项目，编译构建的时间大约会增加四倍，如果开启了 annotation processors，编译构建的时间也会增加 50% ~ 100%。

Uber 的结果与 OkHttp 迁移到 Kotlin 后得到的结果是一致的，都是编译时长都增加了 4 倍。

别担心，虽然这个结果让人吃惊，这个也不是你的错，很多人都和你一样，正在使用 Kotlin。这个问题，虽然很重要，但是它并没有引起广泛的。我觉得，Google 也在试图解决这个问题。我曾问过 Google 相关的开发者，并进行了深度的交流，他们在这个问题给我的回答是：“这是一个很棘手的问题，我宁愿不做”。

Kotlin 除了会增加编译时间，直到上周，才支持增量注解处理，而 Java ，在 10 个月以前就支持了。

在两年前，我就写了篇文章用于告诫大家，过早使用 Kotlin 会存在很大的风险。你可以从评论中可以看出，我在很长的一段时间里面，都是“Kotlin 的黑粉”。

在你的实际工作中，你会发现，与上面的数据相比，Kotlin 的问题远不止于此。在大型的 Android 项目中，编译构建的时间会严重阻碍项目的发展。即使到了今天，Kotlin 已经被正式使用两年了，Kotlin 编译效率依然比 Java 差很多。不管 Kotlin 能给你带来多少优点，编译耗时的问题，都有可能导致你不在使用它。

不管如何，Google 向整个 Android 的开发生态推出 Kotlin 作为第一首选语言，现在 Kotlin 的使用量也越来越大，我们也不得不进行跟进。就我个人而言，我还没有在我的项目中使用 Kotlin。因为 Kotlin 还不够成熟，并且我的客户也不会为我的学习付费，并且我也不希望在 Kotlin 上浪费时间。但是从现在开始，Kotlin 已经逐渐稳定，我也在我拿手的项目上尝试过， 在新项目中，我也会考虑使用它进行开发。有一些开发者认为：“必须在新项目中使用 Kotlin 进行开发“，我不同意这个观点，我觉得这是一个权衡的问题，Kotlin 现在已经成为了一个重要的选项，只要适合当前的项目，就是最好的语言。

对于是否要将已有的项目迁移到 Kotlin 上， 我不能给你太好的。你需要根据你项目的情况，具体问题具体分析。如果你一旦决定要进行迁移，这篇文章中列举的一些可能存在的问题，可能对你有帮助。

总结

请允许我用 Android 开发者的背景，描述一下我这两年所经历的事情：

在过去的两年里，我启动了三个项目，我一直争取，至少参与其中一个项目的开发工作。我回过头来看这些已经存在的项目，并分析这些项目前期所做的技术决定对整个项目的影响。我写了这篇文章，也制作了很多 Android 开发的高级课程，也花了很多时间在互联网上讨论 Android 相关的主题。

即使这样，我今天依然感觉跟不上 Android 整个生态系统的变化。可想而知，对于那些经验不足，需要指导的 Android 开发者而言，是多么地绝望。我现在已经无法想像，现在从头开始学习 Android 的感觉。当你好不容易学会了某个框架或者工具，觉得它很好用的时候，它或许就要过时了。现在也许是加入 Android 开发大家庭最坏的时候。Google 正为他们的“包容性”沾沾自喜，但这一切，对初学者来说，都是极其痛苦的。

Google 在 Android 框架中所做的事情，会导致大量的时间浪费。我们需要花费数小时的时间才能读完所有更改的内容，更别说在项目中应用它们了。我宁愿花时间来创造价值，而不是舍本逐末。

在本文中，我试图总结 Android 开发的现状，并对未来作出了一些预测。文章中，可能包含错误和漏掉一些重要信息，请随时在下面的评论中告知我。文章中的内容都是客观内容，虽然我提出了一些有争议观点，但我相信我是对的。

还有，在文章中，我引用了很多之前写的帖子，我并不是为了炫耀。而是让你能够阅读之前的预测与现在的状况进行对比，虽然那些文章在那个时候读起来很疯狂，就像现在你读本文一样，但是我的这些预测都是很准确的。当然，我也想说：“看，我说得对吧”。鉴于我发布的内容具有争议，当得知没有误导读者，我也会感到很欣慰。有时候，我也宁愿我的预测是错的，Google 正在为开发者着想。但是到目前为止，情况并非如此。

一如既往，感谢你的阅读。你可以在下面评论和提问。

[1] https://stackoverflow/questions/29197821/why-does-aosp-add-new-apis-to-support-libraries-without-adding-them-to-sdk

[2] https://developer.android/jetpack

[3] https://android-developers.googleblog/2019/11/unifying-background-task-scheduling-on.html

[4] https://issuetracker.google/issues/122098785

[5] https://youtu.be/UnJ3amzJM94

[6] https://android-review.googlesource/c/platform/frameworks/support/+/1169184/3/licationpreferences/src/main/java/androidx/licationpreferences/ApplicationPreferences.java

[7] https://stackoverflow/a/37551254/24635

[8] https://techyourchance/dagger-android-dead/

[9] https://stackoverflow/a/6285/24635

[10] https://reddit/r/androiddev/comments/b908fr/can_someone_explain_to_me_why_aac_is_trying_to/

[11] https://android-review.googlesource/c/platform/frameworks/support/+/1159084

[12] https://techyourchance/android-fragment-lifecycle

[13] https://techyourchance/android-viewmodel-architecture-component-harmful/

[14] https://techyourchance/asynctask-deprecated/

[15] https://techyourchance/kotlin-coroutines-in-complex-scenarios/

[16] https://techyourchance/migrate-android-lications-to-kotlin-with-caution/

英文：The State of Native Android Development

链接：https://techyourchance/the-state-of-native-android-development-november-2019/

作者：Vasiliy Zukanov，独立 Android 开发及软件顾问

译者：罗昭成，Android 开发者

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com