在生产型Android客户端软件(企业级应用)开发中，界面可能存在多个输入(EditText)和多个操作(MotionEvent和KeyEvent)，且操作依赖于输入的状态。如下图所示的场景：
 
设定图中
 
确认操作依赖于商品编码和储位的状态
 
跳过操作不依赖于输入状态
 
登记差异操作依赖于储位和数量的状态
 
输入框有三种状态：
 
待输入；
 
待校验；
 
校验成功。
 
操作需要当其依赖的输入数据校验成功，才能执行。
 
如果在Activity中去判断输入框状态，那么实际需要调用(3个输入框)*(3种状态)*(3个按钮) = 27个 if 判断，对于状态的维护将使得整个程序可维护性极差，并随着输入和操作的增加，维护的状态呈指数增长。
 
通过对这种场景的抽象，实现了Android控件状态依赖框架，其使用方法如下：
 
使用方法：
 
1、布局文件引用WatchEditText和WatchButton
 

 
android:id="@+id/edit_query_1"
 
android:layout_width="match_parent"
 
android:layout_height="wrap_content"
 
android:tag="editQuery1"
 
android:imeOptions="actionNext"
 
android:hint="商品编码"
 
android:inputType="number"/>
 

 
android:id="@+id/search_button_1"
 
android:layout_width="wrap_content"
 
android:layout_height="wrap_content"
 
android:tag="buttonSearch1"
 
android:text="确认" />
 
由于Library Module中的控件id不是常量(可参考ButterKnife对Library Module的支持采用R2的原因)，这里采用了tag的方式。
 
2、在Activity中通过注解申明依赖
 
@ViewName("商品编码")
 
private WatchEditText editQuery1;
 
@ViewName("储位")
 
private WatchEditText editQuery2;
 
@ViewName("数量")
 
private WatchEditText editQuery3;
 
@ViewDependency(name = @ViewName("确认"), dependency = {"editQuery1", "editQuery2"})
 
private WatchButton buttonSearch1;
 
@ViewDependency(name = @ViewName("跳过")/*不依赖输入*/)
 
private WatchButton buttonSearch2;
 
@ViewDependency(name = @ViewName("登记缺货"), dependency = {"editQuery2", "editQuery3"})
 
private WatchButton buttonSearch3;
 
ViewName定义控件名称，ViewDependency中dependency指定其依赖的控件tag。
 
3、直接执行onClick和onEditorAction(修改状态)
 
@Override
 
public void onClick(View v) {
 
if (v == buttonSearch1) {
 
Toast.makeText(this, "调接口", Toast.LENGTH_SHORT).show();
 
} else if (v == buttonSearch2) {
 
Toast.makeText(this, "跳下一页", Toast.LENGTH_SHORT).show();
 
} else if (v == buttonSearch3) {
 
Toast.makeText(this, "登记缺货", Toast.LENGTH_SHORT).show();
 
}
 
}
 
可以看出，这里并没有通过if判断各个输入控件的状态。
 
@Override
 
public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
 
if (actionId == EditorInfo.IME_ACTION_NEXT && v == editQuery1
 
&& (query1Str = editQuery1.getText().toString()).isEmpty()) {
 
if (query1Str.equals("12345")) {
 
editQuery1.complete();
 
return true;
 
}
 
}
 
// 省略代码
 
return false;
 
}
 
onEditorAction模拟调用软件的Enter进行校验，这里需要注意通过editQuery1.complete()修改该EidtText的状态。
 
实现原理
 
整个框架分为三个package：annotation、state和view。
 
1、在annotation中定义ViewName和ViewDependency注解，分别用于WatchEditText和WatchButton。ViewName指定WatchEditText控件在业务中的名称，ViewDependency指定WatchButton依赖的WatchEditText控件；
 
@Target(ElementType.FIELD)
 
@Retention(RetentionPolicy.RUNTIME)
 
@Documented
 
public @interface ViewDependency {
 
ViewName name() default @ViewName;
 
String[] dependency() default {};
 
}
 
2、在state中通过状态模式定义Enter、Verify、Complete，其基类为抽象类Operator，定义方法operator；
 
public abstract class Operator {
 
// 操作对应的上下文
 
protected Context context;
 
// 操作
 
public abstract boolean operator(String operatorName, String viewName);
 
}
 
public class Enter extends Operator {
 
private static Enter enter;
 
private Enter(Context context) {
 
this.context = context;
 
}
 
public static Enter getInstance(Context context) {
 
if (enter == null) {
 
enter = new Enter(context);
 
}
 
return enter;
 
}
 
@Override
 
public boolean operator(String operatorName, String viewName) {
 
Toast.makeText(context, String.format("[%s]为空，不允许执行[%s]", viewName, operatorName),
 
Toast.LENGTH_SHORT).show();
 
return false;
 
}
 
}
 
3、WatchEditText和WatchButton定义控件的依赖关系。WatchEditText实现ViewState接口，其包含三种状态的转换方法。
 
public interface ViewState {
 
void enter();
 
void verify();
 
void complete();
 
}
 
以上，博客园对markdown支持的不太好，无法添加注释(/* */)，如需查看源码，请移步Github地址：https://github.com/yhthu/AndroidViewDependency.git
 
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。

 
依赖注入
 
指程序运行过程中,调用者需要被调用者的辅助,但是创建被调用者对象的工作不再由调用者来完成(因此称为控制反转(IOC:Inversion of Control)),而是由相关的容器控制程序将被调用者的对象在外部创建出来并注入到调用者的引用中.(以HRSystem 和person为例)
 
public class HRSystem {
 
@Inject
 
Person person;
 
public staticvoid main(String[] args) {
 
}
 
}
 
为什么要使用依赖注入
 
依赖注入是实现控制反转的方式之一(另一方式是依赖查找),目的就是为了让调用者和被调用者之间解耦
 
可以注入依赖的模拟实现,使得测试变得更加简单.
 
(一)ButterKnife
 
https://github.com/JakeWharton/butterknife
 
用途:主要用来简化各种初始化控件的操作
 
配置:(高版本需要添加仓库)
 
在build.gradle文件中dependencies节点添加如下代码Add this to you project-level build.gradle:
 
buildscript{
 
repositories {mavenCentral()}
 
dependencies {classpath'com.neenbedankt.gradle.plugins:android-apt:1.8'}
 
}
 
Add this to your module-levelbuild.gradle:
 
apply plugin: 'android-apt'android {
 
...
 
}
 
dependencies {compile'com.jakewharton:butterknife:8.1.0'
 
apt'com.jakewharton:butterknife-compiler:8.1.0'}
 
在Android Studio中点击File-->Settings-->Plugins-->Browse repositories,搜索Android ButterKnife Zelezny插件,安装成功以后重启Android Studio.
 
在布局文件中添加控件的时候,所有需要在Activity/Fragment代码中进行控制的控件都要添加id属性
 
在Activity/Fragment代码中,将鼠标放在布局文件的引用上(即R.layout.activitymain中的activitymain上面),此时按快捷键Alt + Insert或鼠标右键选择Generate
 
在弹出的菜单中选择Generate ButterKnife Injections,此时会再次弹出一个对话框
 
新的对话框中点击confirm后直接生成控件的引用,代替findViewById
 
如果需要处理控件的点击事件,可以选择对应控件的OnClick复选框.
 
如果是ListView的Item视图,还可以选择左下角的Create ViewHolder复选框,生成ViewHolder静态类.
 
使用技巧：
 
在AndroidStudio\plugins\android\lib\templates\gradle-projects\NewAndroidModule\recipe.xml.ftl中添加如下代码,以后新创建的工程默认会添加Butterknife依赖:
 
(二)AndroidAnnotations
 
主页:http://androidannotations.org/
 
用途:1.使用依赖注入Views,extras,System Service,resources
 
2.简化线程模型
 
3.事件绑定
 
4.REST Client
 
配置:
 
1.在project/build.gradle文件中按下图所示添加代码:
 
mavenCentral()
 
classpath'com.neenbedankt.gradle.plugins:android-apt:1.8'
 
mavenCentral()
 
mavenLocal()
 

 
2.在app/build.gradle文件中按下图所示添加代码:
 
apply plugin: 'android-apt'
 
apt {
 
arguments {
 
androidManifestFilevariant.outputs[0]?.processResources?.manifestFile
 
}
 
}
 
apt"org.androidannotations:androidannotations:4.0.0"
 
compile"org.androidannotations:androidannotations-api:4.0.0"
 

 

 
注意事项:*Manifest中注册的activity要在原类名后追加下划线”_”*使用注解的控件和方法不能使用private修饰符*大型项目并不适用
 
(三)Dagger2
 
主页:https://github.com/google/dagger
 
配置:
 
1.在project/build.gradle文件中按下图所示添加代码:classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
 

 
2.在app/build.gradle文件中按下图所示添加代码:* apply plugin: 'com.neenbedankt.android-apt'
 
* compile 'com.google.dagger:dagger:2.2'
 
* apt 'com.google.dagger:dagger-compiler:2.2'
 
* provided 'org.glassfish:javax.annotation:10.0-b28'
 
主要的注解:
 
@Provides:用来修饰方法，方法的返回类型就是所提供的依赖类型，可以简单的把方法的返回值理解为我们通常要new出来的对象.
 
@Provides方法都会用provide作为前缀
 
@Module:所有的@Provides方法都必须放到一个Moudle中,一个Moudle就是使用@Moudle修饰的类,可以简单的理解为一个持有各种对象的仓库.用来给@Component组件提供实例化的对象.
 
Android中有三种Module:ApplicationModule，ActivityModule，UserModule,分别提供整个应用级别的(只生成一个该组件的实例)，Activity级别的，用户级别的Module。
 
@Module类都用Module作为后缀
 
@Inject:通常在需要依赖的地方使用这个注解,简单的理解为声明一个对象
 
@Component它是@Inject和@Module的桥梁，它的主要作用就是连接这两个部分.
 
我们必须用@Component注解一个接口,为该注解传入Module类，或者添加其依赖的组件
 
@Component注解的接口或抽象类以Component为后缀
 
@Component的实现类
 
@Component注解的接口或抽象类，Dagger将会为该接口或者抽象类生成一个实现，这个实现的命名是在接口或抽象类前面加上Dagger，如MyComponent生成的实现是DaggerMyComponent
 
使用步骤:
 
1.创建Module,并在其中创建Provides.示例代码:@Module
 
public class MainActivityModuel {
 
@Provides
 
User provideUser(){
 
return  new User("zhangsan",12,"18612345678");
 
}
 
}
 
2.创建Component.示例代码:@Component(modules = MainActivityModuel.class)
 
public interface MainActivityComponent {
 
void inject(MainActivityactivity);
 
}
 
3.Rebuild工程,生成对应的以Dagger开始的工具类
 
4.利用对应的以Dagger工具类初始化,并注入对象.示例代码:public class MainActivity extends AppCompatActivity {
 
@Inject
 
Useruser;
 
@Override
 
protected void onCreate(BundlesavedInstanceState) {
 
super.onCreate(savedInstanceState);
 
setContentView(R.layout.activity_main);
 
MainActivityComponent component =DaggerMainActivityComponent.builder().mainActivityModuel(newMainActivityModuel()).build();
 
component.inject(this);
 
}
 
}

 
依赖注入(DI)技术在安卓开发领域已经非常流行了。DI可以减少重复代码的编写，更便于调试和测试，使得开发出优秀的APP更加简单。尽管各种DI框架看着都非常强大，但也需要非常注意它们对APP性能带来的开销。本文中我们对比了三个最流行的DI框架，来帮助开发者了解它们各自的优劣。
 
我们比较的是以下三个DI框架：
 
Roboguice和Dagger的工作原理有所差异，Roboguice在运行时利用反射进行依赖注入，而Dagger则利用编译期的注解处理来生成依赖注入的代码，尽可能的减少了反射的使用。当然这一差异在APP的性能上的提现非常明显，因为在安卓平台反射的开销非常大。尽管Roboguice的开销更大，由于它使用起来更加简单，很多开发者还是会倾向于Roboguice，他们认为APP性能的提升相比于开发过程中的付出要得不偿失，然而这种思想是最应该摈弃的。(注意我们这里并不讨论Butter Knife，因为它是进行View绑定的，并不是通常所说的依赖注入，当然如果你需要进行View绑定的话，Butter Knife是不错的选择。)
 
本文接下来的部分，会首先展示对依赖注入框架的性能测试结果，然后展示对市场上百万下载量的APP进行性能测试的结果，最后对比一下三个框架的方法数量。
 
微基准测试
 
我们创建了一个Github仓库，包含了三个示例APP。建议先花费几分钟查看一下，如果你使用过这三个框架，工程的内容就会很好理解了。三个APP包含了相同的依赖图，我们使用不同的框架注入这些依赖，并计算性能开销。同时我们还输出了一些log，以确保依赖对象被成功注入。
 
我们总共进行了5455次注入：注入4800个模型对象(A* .. F*)到Test*
 
注入600个Test对象到TestManager
 
注入40个Test*到MainActivity
 
注入15个TestManager到MainActivity
 
(单个框架特有的功能，例如Roboguice的View注入，并没有被使用)
 
我们使用nimbledroid.com来测试执行时间，下面是我们在同一个测试APP中使用三个不同依赖注入框架的测试结果：
 
上面的数据可能有点迷惑性，接下来我们逐步分析。
 
NimbleDroid默认会显示APP的冷启动时间。你可以通过导航(Analysis Details -> Icicle Graph)查看具体每个方法的执行时间，就像下面这样：
 

 
调用 com.google.inject.internal.InjectorImpl.injectMembers 耗费3923毫秒
 
令人惊讶的是，Roboguice注入依赖耗费了3923毫秒！性能开销太大了！考虑到我们这里只是注入了简单地测试对象，实际场景中Roboguice的性能开销会更大，因为实际APP的依赖对象通常关系复杂，创建也会耗费更多的时间。如此漫长的注入时间使得依赖注入得不偿失了，意识到这一点非常重要，毕竟建议的APP启动时间是2秒以内，但我们花在依赖注入上的时间就已经将近4秒了。
 
现在，让我们看看Dagger 1和Dagger 2的测试结果。
 
Dagger 1:
 

 
调用 dagger.ObjectGraph$DaggerObjectGraph.inject 耗费154毫秒
 
Dagger 2:
 

 
调用 com.nimbledroid.demo.dagger2.DaggerD2EComponent.inject 耗费62毫秒
 
我们可以看到，Roboguice的耗时是Dagger 1的25倍，而Dagger 2速度更快。
 
实际APP例子
 
现在让我们测试一下市场上的APP。一个绝佳的例子就是Skype了。
 

 
调用 roboguice.RoboGuice.setBaseApplicationInjector 耗费2415毫秒
 
可以看到，他们使用Roboguice时耗费了2415毫秒。
 
一段时间后，他们切换到了Dagger，把依赖注入的时间减少到了170毫秒。
 

 
调用 com.skype.android.DaggerSkypeApplicationComponent.inject 耗费171毫秒
 
以下是存在类似问题的流行APP：Amex Mobile (~1,700ms 开销)，而最新的版本 (~274ms 开销) 切换到了Dagger
 
方法数
 
使用Roboguice还有另外一个缺点。通过查看我们使用Roboguice的测试APP的详细信息，我们发现：
 

 
方法数：33,189
 
在“Method Count”部分，NimbleDroid显示Roboguice测试APP有33,189个方法。
 
反观Dagger 1的数据：
 

 
方法数：23,997
 
和Dagger 2的数据：
 

 
方法数：23,930
 
33200个方法和24000个方法！安卓存在单个dex文件65K方法数限制，将近10000个方法数的差别还是非常巨大的。使用Roboguice也使得整个APK文件增大300KB左右。
 
注意：我们的测试中没有使用proguard，因为我们希望测试出这三个框架未优化时的开销。
 
建议：在安卓APP中使用Roboguice需要格外小心，因为相比于Dagger，它会带来更大的性能开销和方法数量。如果可以的话，请使用Dagger 2，因为它比Dagger 1更快。

 
今天继续Jetpack专题，相信很多的朋友都使用过Dagger，也放弃过Dagger，由于实在太难用了。因此官方也是为了让咱们更好使用依赖注入框架，为咱们封装了一个新的框架——Hilt，今天一块儿来看看：框架
 
依赖注入是啥？为何须要她？
 
Hilt是啥，怎么用？
 
Hilt支持哪些类的依赖注入。
 
依赖注入是啥？为何须要她？
 
简单的说，依赖注入就是内部的类在外部实例化了。也就是不须要本身去作实例化工做了，而是交给外部容器来完成，最后注入到调用者这边，造成依赖注入。ide
 
举个例子：
 
Activity中有一个user类，正常状况下要使用这个user确定是须要实例化它，否则他是个空值，可是用了依赖注入后，就不须要在Activity内部再去实例化，就能够直接使用它了。函数
 
@AndroidEntryPoint
 
class MainActivity : BaseActivity() {
 
@Inject
 
lateinit var user: User
 
}
 
这个user就能够直接使用了，是否是有点神奇，都不须要手动依赖了，固然代码没写完，后面再去完善。只是表达了这么一个意思，也就是依赖注入的含义。post
 
那么这种由外部容器来实例化对象的方式到底有什么好处呢？最大的好处就是减小了手动依赖，对类进行了解耦。具体主要有如下几点：学习
 
依赖注入库会自动释放再也不使用的对象，减小资源的过分使用。
 
在配置 scopes范围内，可重用依赖项和建立的实例，提升代码的可重用性，减小了不少模板代码。
 
代码变得更具可读性。
 
易于构建对象。
 
编写低耦合代码，更容易测试。
 
Hilt是啥，怎么用？
 
很明显，Hilt就是一个依赖注入库，一个封装了Dagger，在Dagger的基础上进行构建的一个依赖注入库。Dagger咱们都知道是一个早期的依赖注入库，但确实很差用，须要配置不少东西，那么Hilt简单到哪了呢？咱们继续完善上面的例子：测试
 
@HiltAndroidApp
 
public class MainApplication extends Application {
 
}
 
@AndroidEntryPoint
 
class HiltActivitiy : AppCompatActivity() {
 
@Inject
 
lateinit var user: UserData
 
override fun onCreate(savedInstanceState: Bundle?) {
 
super.onCreate(savedInstanceState)
 
showToast(user.name)
 
}
 
}
 
data class UserData(var name: String) {
 
@Inject
 
constructor() : this("bob")
 
}
 
说下几个注释的含义：ui
 
@HiltAndroidApp。全部使用Hilt的App必须包含一个使用 @HiltAndroidApp 注解的 Application，至关于Hilt的初始化，会触发Hilt代码的生成。
 
@AndroidEntryPoint。用于提供类的依赖，也就是表明这个类会用到注入的实例。
 
@Inject。这个注解是用来告诉 Hilt 如何提供该类的实例，它经常使用于构造函数、非私有字段、方法中。
 
Hilt支持哪些类的依赖注入。
 
1) 若是是 Hilt 支持的 Android组件，直接使用 @AndroidEntryPoint注解便可。好比Activity，Fragment，Service等等。this
 
若是是ComponentActivity的子类Activity，那么直接使用@AndroidEntryPoint就能够了，好比上面的例子。
 
若是是其余的Android类，必须在它依赖的Android类添加一样的注解，例如在 Fragment 中添加@AndroidEntryPoint注解，必须在Fragment依赖的Activity上也添加@AndroidEntryPoint注解。
 
2)若是是须要注入第三方的依赖，可使用@Module注解，使用 @Module注解的普通类，在其中建立第三方依赖的对象。好比获取okhttp的实例code
 
@Module
 
@InstallIn(ApplicationComponent::class)
 
object NetworkModule {
 
/**
 
* @Provides
 
* @Singleton 提供单例
 
*/
 
@Provides
 
@Singleton
 
fun provideOkHttpClient(): OkHttpClient {
 
return OkHttpClient.Builder()
 
.build()
 
}
 
}
 
这里又有几个新的注解了：对象
 
@Module。用于建立依赖类的对象
 
@InstallIn。使用 @Module 注入的类，须要使用 @InstallIn 注解指定 module 的范围，例如使用 @InstallIn(ActivityComponent::class) 注解的 module 会绑定到 activity 的生命周期上。
 
@Provides。用于被 @Module注解标记类的内部的方法，并提供依赖项对象。
 
@Singleton。提供单例
 
3)为ViewModel提供的专门的注解
 
@ViewModelInject，在Viewmodel对象的构造函数中使用 @ViewModelInject 注解能够提供一个 ViewModel。
 
class HiltViewModel @ViewModelInject constructor() : ViewModel() {}
 
private val mHitViewModule: HiltViewModel by viewModels()
 
参考
 
拜拜
 
有一块儿学习的小伙伴能够关注下❤️个人公众号——码上积木，天天剖析一个知识点，咱们一块儿积累知识。