在开发一个模拟人工自动网银转账的软件的时候,大量使用了async+await,在项目成功上线并且迭代了若干版本后,对于await相关的代码进行了重构,目前的结构更清晰,可扩展性更强。同时对于await的使用也从很初级,变得有一些经验,现在把这些经验总结如下:
1 await和async配对使用。最典型的应用如下:
下面的代码是不用线程的情况,winform就会在5秒的无响应状态后才会在testbox中显示“test”,用户体验不好。
private string testString()
{
Thread.Sleep(5000);
return "test";
}
private async void btnGetAndTransfer_Click(object sender, EventArgs e)
{
tbTextBox.text=testString();
}
下面的代码使用传统的threading技术更新textbox的内容,非常复杂,代码难于维护
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
new Thread(SampleFunction).Start();
}
public void SetTextBox(string value)
{
if (InvokeRequired)
{
this.Invoke(new Action<string>(SetTextBox), new object[] {value});
return;
}
textBox1.Text = value;
}
void SampleFunction()
{
Thread.Sleep(5000);
SetTextBox("test");
}
}
下面的代码使用await+async实现了第一段代码的功能,并且解决了winform冻结的问题。从代码的结构来说,也是清晰易读。
private async Task<string> testString()
{
return await Task<string>.Run(() =>
{
Thread.Sleep(5000);
return "test";
});
}
private async void btnGetAndTransfer_Click(object sender, EventArgs e)
{
tbTextBox.text=await testString();
}
从以上的代码示例来看await+async虽然是语法糖,但是有明显的的优势。
2 虽然await+async有以上所说的优点,但是,如果大规模使用一定要慎重:
a 方法体中使用await,方法也必须声明为async,另一个方法调用声明了async的方法,也需要用await,如果不用await,就会立即从被调用方法返回,继续执行后面的代码,而不会等待被调用async方法实际执行完毕再继续执行后面的代码。但是大多数情况下,调用async 方法都需要等待对方执行完再继续执行后面的代码,结果就因为某个方法里面用了await,导致调用它的整个call stack上的method都需要await+async,搞得很多代码被await传染。
b 我在代码中用到了Action,就是为了可以把配置文件中的字符串对应执行相应的方法。但是,Action是个template class,不能同时兼容async和非async方法,结果导致用了await的方法只能另外处理。(Action应该也可以使用async方法,参考:https://stackoverflow.com/questions/20624667/how-do-you-implement-an-async-action-delegate-method)
3 从代码整体的架构设计来说,如果一个很深的call stack都用了await,那么就可以换个思路,不要让最里面的方法启动线程,而是把启动线程的代码放到最外面,这样一来绝大部分方法就都不再需要用async修饰了,方法就都可以用正常的方式开发了,也不会再把async传染到新的模块中。
换句话说,async和await应该在贴近UI的地方使用,不要在基础功能的代码中使用。
原文链接:https://blog.csdn.net/wingnet/article/details/99678840