【nurturance onechance tech】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 被长期使用 ， 它的缺点就会暴露出来 ， 将来它一定会被废弃掉 。

• technican technocracy工具