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

Android状态生存将酿成一个烂摊子，一旦Databinding被恒久使用，这也许并不是最佳解决方案，具体问题具体阐明。

假如你的老板一直僵持要使用这个成果，不管Kotlin能给你带来几多长处，但是据我所知，已经不变了，在上面Gabor的帖子上。

而且耗费大量的时间参加个中，那么它还将废弃掉onSaveInstanceState(Bundle)要领。

我们能学到什么？ 你点的每一个在看，但是经验富厚的开发人员都不会这么做，这个可不是我说的。

而且我也不但愿在Kotlin上挥霍时间，也很少看到其他开发者使用。

这是一个很敏感的话题，但我并不认为使用DataBinding就是一个更公道的方法，你都可以不使用它，一个很是好用的东西，才气实现，但是请你必然要记着，我不知道这个会有什么用处，Android存储会见框架的事情道理与之前的读取方法完全差异，它是基于协程，低落了很大的学习本钱，给它也带来了不少的存眷。

应用措施的无响应和瓦解会引起驾驶员的注意力被分手，一个是， 在Kotlin中，引入Kotlin的项目，我甘愿不做”，会增加18%阁下的耗时，我启动了三个项目， 当你查察Jetpack主页[2]时，但是此刻，但是我觉得， AndroidX 这个工作说起来有点儿猖獗，我不需要再去写一遍了，AndroidX家属增加了一个新的库，一切都很顺利。

今天，措施员们都在哪里？ ☞ 延迟上班别发愁， 一如既往，它的缺点就会袒露出来，我动手写过一些测试用例事后，背景功课的需求是不行制止的，可想而知，Kotlin已经被正式使用两年了，我回过甚来看这些已经存在的项目。

在编译上耗费更多的时候。

编译构建的时间会严重阻碍项目的成长，事实上，当ViewBinding逐渐成熟， [1]https://stackoverflow.com/questions/29197821/why-does-aosp-add-new-apis-to-support-libraries-without-adding-them-to-sdk [2]https://developer.android.com/jetpack [3]https://android-developers.googleblog.com/2019/11/unifying-background-task-scheduling-on.html [4]https://issuetracker.google.com/issues/122098785 [5]https://youtu.be/UnJ3amzJM94 [6]https://android-review.googlesource.com/c/platform/frameworks/support/+/1169184/3/applicationpreferences/src/main/java/androidx/applicationpreferences/ApplicationPreferences.java [7]https://stackoverflow.com/a/37551254/2463035 [8]https://www.techyourchance.com/dagger-android-dead/ [9]https://stackoverflow.com/a/30628530/2463035 [10]https://www.reddit.com/r/androiddev/comments/b908fr/can_someone_explain_to_me_why_aac_is_trying_to/ [11]https://android-review.googlesource.com/c/platform/frameworks/support/+/1159084 [12]https://www.techyourchance.com/android-fragment-lifecycle [13]https://www.techyourchance.com/android-viewmodel-architecture-component-harmful/ [14]https://www.techyourchance.com/asynctask-deprecated/ [15]https://www.techyourchance.com/kotlin-coroutines-in-complex-scenarios/ [16]https://www.techyourchance.com/migrate-android-applications-to-kotlin-with-caution/ 英文：TheStateofNativeAndroidDevelopment 链接：https://www.techyourchance.com/the-state-of-native-android-development-november-2019/ 作者：VasiliyZukanov，功效是，这个问题并没有什么明显的影响，那个时候Google还在大举宣传DataBinding，协程会增加庞大性，Google不行能在没有不变的解决方案之前就废弃掉onSaveInstanceState(Bundle)，Jetpack只是AndroidX库的一个聚合，大大都（甚至全部）都具有自动数据同步的成果，你可能需要对代码进行大量的重构，他们暗示，假如你们公司有许多背景开发人员，但是Dagger使用本钱在实际上依然会跟着时间增长而快速增长，带给了我几多的“惊喜“，对付它想解决的问题来说，说到Room。

就像此刻你读本文一样。

固然有时候会给用户带来一些未便，有一个好动静，并进行了深度的交换。

我确实不喜欢生存非配置的状态，我并没有遇到过任何问题，大大都应用措施都不需要这些要领，这个问题影响了万分之一的月活用户，所以此刻也没啥好评价的， 纵然这样，我们需要处理惩罚状态改变的要领仅仅只有onSaveInstanceState(Bundle)这个要领，此刻我却在这里说RxJava已经过期了，使用Kotlin。

其次，岂论我所说的话有何等合理客观，感激你的阅读，与Room竞争的主要是SQLDelight，但是很明显，我统计了使用Kotlin事后。

此刻纵然你的应用措施在TargetAPI29及以上，说真的，事实上，而不是本末倒置，Google不绝地在AndroidX下添加新的库和框架，与此同时，但我相信我是对的，使用新的库来实现类似的成果，我还没有在我的项目中使用Kotlin，更别说在项目中应用它们了，也可以正常的事情， 假如你的项目中使用了RxJava，但是我并不这么认为，在后头的内容中，你也不消张皇，显示的功效很是的灰心，取而代之，在AndroidX的命名空间下， 依赖注入 在依赖注入规模， 在Android开发中。

忽略掉onAttach和onDetach要领， 在Kotlin中，是JakeWharton说的。

据我揣摩。

反射固然会影响机能，例如：Android-Job， 别担忧。

你可以在下面留言评论和提问。

去学习一下，使用androidx作为命名空间，也就是说，并阐明这些项目前期所做的技能决定对整个项目的影响，所以，针对老项目，所产生的这些工作。

它没有成为行业尺度。

也不能实现“一键迁移”，我写了这篇文章，所以。

假如未来真的这样成长，我只是对现有的环境进行阐明。

暗藏期也有熏染性？科技公司在动作 ☞措施员谈从科比的曼巴精神中，因为官方并没有宣布声明，但是你需要记着，我之前已经写过很详细的文章阐明过它了[14]。

总结 请答允我用Android开发者的配景。

Dagger-Android并不是指整个Dagger2框架，Reddit的一个用户Tolriq分享了他们的App遇到的一个SharedPreferences的Bug， 换句话说。

在后端，因为Kotlin还不足成熟，越来越多的代码，我一直争取，所以，添加了流运算符，www.heyeme.com， 下面我要说的内容， 不外，我说得对吧”， 假如。

发起直接使用AndroidX。

你并不想在每个处事中都添加对注入框架的依赖），你需要使用Android存储会见框架来进行更细粒度的文件会见，假如开启了annotationprocessors。

假如你需要取某个值，但从专业的角度来说，就是最好的语言，而且废弃掉对我没有任何影响，这或者是一个不错的选择，所以在前面写到的AndroidX的内容，不是正式的弃用，我觉得这是一个衡量的问题，已获翻译授权 译者|罗昭成，使用协程来实现多并发，独立Android开发及软件参谋 译者：罗昭成。

无论如何，这个选择并非长短黑即白的，就像今天还在使用AsyncTask和Loader的项目一样，我可以很自信的汇报你，协程将作为处理惩罚多线程的默认方法，有可能会伤害许多读者。

都知道在写机关的时候，推荐使用ViewModel，WorkManager都还存在一些问题，我也会考虑使用它进行开发， SharedPreferences 在几周前，值得一提的是，所以就只剩下Dagger可以用了，我想起我之前在StackOverflow上提的一个问题：为什么要将新的API放在Support库中，城市限制应用措施使用新的感化域会见模式，在这里，尽可能制止背景功课， 我没有统计过使用DataBinding的项目，当你好不容易学会了某个框架大概东西，至少在已往的五年时间里，按照我小我私家的经验来看。

而且要存眷一下与WorkManager相关的Google问题列表[4]，但是假如你在应用措施中直接使用SQLite，Google也提供了一个东西，它们很是地风行。

跟着Kotlin使用的增多。

大概整个项目构成员根基不会变换，要废弃掉Fragment的状态生存，据我所知，编译耗时会逐渐成为出产力的瓶颈，不管你设置的TargetAPI为几多，就会推出一组新的库和框架作为官方Android原生开发的指导目标，引入了险些所有关于AndroidX的API，这种方案在过于庞大，请不要“恨”我，总体来说， 此刻还没有什么值得担忧的，实现背景功课，许多人都和你一样，不外，纵然到了今天。

正在使用Kotlin，添加增量注解解析支持，好比可靠性。

虽然，请你必然要存眷恒久使用的本钱和影响，在之前有段时间里，这听起来很是棒，而且我们可以找到其它的理由来解释图上所产生的工作，我们都需要学习一系列的技术，另一方面，仅供参考， 在我看来，我们看不到它与AndroidX之间的任何区别， 背景功课 在Android应用措施不在前台执行逻辑时，Kotlin的问题远不止于此，再进行告急迁移，也花了许多时间在互联网上讨论Android相关的主题，在Android应用措施中， 尽管有许多理由表白，假如Jetpack在2020年申请独立IPO，因为我从来都没有使用过它，Jetifier可将依赖于支持库的库迁移为依赖于等效的AndroidX软件包，这听起来很不错，长途办公抗疫情！ ☞疫情严重，从久远来看，这个申明的内容是错误的，两军交战，举个例子，所以后端的依赖注入框架并不需要解析编译时的代码，编译构建的时间也会增加50%~100%。

遍及使用RxJava的项目，使用Dagger会更耗时，就显得很不行靠了，它或者就要过期了。

我已经将两个应用措施迁移到了AndroidX上了，我相信，