在线程中使用Toast以及其他有关UI更新的API

背景与声明

博主在写这篇文章的时候,使用的环境是Xamarin.Form,Xamarin.Android也适用。不过考虑到Xamarin.Form/Android会运行在Android环境中,所以本文内容也适用于原生Android开发。

但是与原生Android开发的不同点在于,Xamarin.From/Android使用的是C#语言,而原生Android开发使用的是Java/Kotlin,所以在语法、库以及编程习惯等多方面会有不同,请读者悉知。

序言

在Android中,为了良好的用户体验,是不允许在UI进程(主进程)中进行一些可能运行比较长的时间的操作的(例如网络操作和文件操作)。其原因也简单,如果在主进程中进行了这样的操作(例如写文件),可能会导致UI长时间无响应,进而影响用户体验。所以这样的操作一般要放在单独的进程中。

正文

我们现在解决了在UI中执行长时间操作的问题(具体方法待补充),但是如果我们如果需要在“长时间操作”中执行UI更新怎么办?直接在里面写吗?在下面的代码中,写了一个方法,而这个方法将会以线程的形式来执行:

private void Run()
{
    // Do something below.
        // ...
        // Make a Toast
    Android.Widget.Toast.MakeText(Android.App.Application.Context, "这是一个Toast", ToastLength.Short).Show();
        // Do something else.
        // Blah Blah ...
}

但是如果这样写了代码,我们就会遇到一个异常

Can't toast on a thread that has not called Looper.prepare()

这是为什么呢?在报错中提到的Looper.prepare()又是什么呢?

关于Looper类

Looper是一个类,主要用来为一个线程开启一个消息循环。在默认情况下,Android没有为每一个线程开启消息循环(关键是Android也不能确定我们的线程到底需不需要这个消息循环,如果万一我们不需要,而Android又为我们开启了,那岂不是浪费资源?)。

为什么要用Looper

更新UI(Toast也算是更新UI的一种),是需要主线程来做的。如果真的要子线程(也就是我们自己开启的线程)来做,可能会引起一系列的问题,况且Android也不允许我们这样做。实际上不仅Android中,在之前编写C#图形界面的时候,也有这种不允许子线程更新UI的情况。

所以如果我们需要更新UI,需要使用消息队列来处理这个操作。也就是说,我们需要把更新UI的操作串行化。具体的方法是使用一个消息队列。如果我们需要在子线程中更新UI,就要将一个更新UI的操作以一个消息(可以理解为请求)的形式发布出去,由管理UI的线程(主线程)来处理,至于到底执行不执行,以及如何执行,就是主线程的事了。

在C#中,处理的方法是使用一个委托来异步地执行UI更新操作,而在Android中则是使用一个消息队列,在更新UI前,准备好一个消息队列,然后执行操作,这样,要执行的UI更新操作就进入到了消息队列中,再由主线程来执行具体的操作。具体使用的方法是,在执行UI更新之前,调用Looper.prepare()方法。例如我们Toast一下:

// 前面的代码省略
Looper.Prepare();
Android.Widget.Toast.MakeText(Android.App.Application.Context, "这是一个Toast", ToastLength.Short).Show();

这样就行了吗?答案是否定的,我们Prepare()了一个Looper那么下面的指令就会进入到队列里,但是我们还要说明,到哪里我们的代码就不进入队列了,方法是使用Looper.Loop()方法。完整的代码如下:

Looper.Prepare();
Android.Widget.Toast.MakeText(Android.App.Application.Context, "这是一个Toast", ToastLength.Short).Show();
Looper.Loop();

使用Looper的弊端

有一点要说明一下,在一个进程(或者是Handler)中,Looper.Loop()方法后面的代码是不会被执行到的,也就是说,如果有下面这样的代码:

Looper.Prepare();
Android.Widget.Toast.MakeText(Android.App.Application.Context, "这是一个Toast", ToastLength.Short).Show();
Looper.Loop();
// Some code below Looper.Loop()

那么// Some code below Looper.Loop()是不会执行的,所以这种方法的应用也比较有限。例如,我们在一个线程(或者Handler)中只需要在最后才需要更新UI,就可以使用这种方法。但是如果我们需要一直开一个进程(例如一直侦听一个端口),那么就不太合适了(实际上,如果我们如果真的有这种需求的话,会用Service来实现吧(* ̄︶ ̄))

不过既然提到了,就继续说吧~

使用Handler来实现

这个方法说到底还是使用消息队列,不过好处在于,我们不需要使用Looper,也就意味着,在更新UI的代码后面,我们还可以放其他的代码~

我们可以使用Handler来处理消息:

private Handler msgHandler = new Handler((Message msg) =>
{
        Android.Widget.Toast.MakeText(Android.App.Application.Context, "这是一个Toast", ToastLength.Short).Show();
});

上面的代码实际上是一个Action(这是C#里面的概念!)

而使用它的方法也很简单,假设下面的代码将要在一个进程中执行:

Message m = msgHandler.ObtainMessage();    // 注意,这里的msgHandler就是我们在上面声明的Handler,所以一定要注意其作用域。
m.Arg1 = Resource.String.string_SomeString_1;    // Arg1 和 Arg2 只能是int类型,所以一般用来传递Resource里面的东西。
m.Arg2 = Resource.String.string_SomeString_2;
m.Obj = "Message类的Obj成员,可以指定任何类型的数据,这个比较自由"。
msgHandler.SendMessage(m);

在使用Message的时候,一定要注意,Arg1Arg2只能赋值为int,所以只能使用Resource里面的物件(string、图片甚至Layout等等),而Obj就比较自由了,可以配置各种类型(因为Obj就是Object嘛~(* ̄︶ ̄))。

结束

EOF

编写无警告的代码

本文内容版权归原作者(作者e5Max)所有,我不对本文内容的真实性做任何保证。
原文地址:编写无警告的代码

今天把项目的Qt版本从Qt4.6.3升级到Qt4.8.4,重新编译项目代码的时候,特别关注了一下编译器的警告。于是找到《C++编程规范——101条规则、准则与最佳实践》翻了翻,重温了一下第1条 在高级别警告干净利落地进行编译。
如果编译器对某个构造发出警告,一般表明代码中存有潜在的问题。警告就好比代码的“肿瘤”,可能是良性的也可能恶性的——作为代码医生的我们不能对其视而不见。必须“把它弄清楚”,然后通过“改写代码以排除警告”!
典型的编译器警告示例:
1.”Unused function parameter”(未使用的函数参数):
编译器会对没有使用到的函数参数报告警告。如果确实不需要,那直接删除函数参数名就行了。
2. “Variable defined but never used”(定义了从未使用过的变量):
如果确实不需要,可以直接将之删除。 如果该变量的实例化是为了启动某项服务,则经常可以通过插入一个变量本身的求值表达式,使编译器不再报警。(这种求值不会影响运行时的速度)
3. “Variable may be used without being initialized”(变量使用前可能未经初始化):
这种警告通常意味着你的代码存在问题,请慎重处理之。
4. “Missing return”(遗漏了return语句)。:
这可能是一种好现象。即使你认为控制永远都不会运行到结尾或某个分支,则应该加上执行assert(false ) 的语句。
像下面这样(兼有注释作用的断言):

  default:  
     assert( !"should never get here!" );  // !“string” 的求值结果为false  
  
  1. “signed/unsigned mismatch”(有符号数/无符号数不匹配):
    通常需要插入一个显式的强制转换。
  2. “warning: type qualifiers ignored on function return type”(忽略了函数返回类型的类型限定符):
    通常是因为在函数前面的返回值面前添加了多余的 const 限定符。
    例如,const int getAge() const { return m_age; } ,最前面的const 是多余的,编译器会报告警告。
  3. “warning: deprecated conversion from string constant to ‘char*'”(不推荐的转化用法):
    函数原型:void setName(char *name);

    函数调用:setName(“personName”); // 编译器报告警告

释义:这是因为 char * 是一个指针,其背后的含义是:给我一个字符串,我可以修改它。

而如果我们传给函数一个“字符串常量”,这应该是没法被修改的。所以说,比较合理的办法是把参数类型修改为const char * ,而这个类型背后的含义是:给我一个字符串,我只要读取它(const意味着只读)。
8. “warning: “MAX_PATH” redefined” (重复定义) :

  #ifndef MAX_PATH
  #define MAX_PATH(260)
  #endif
  
  1. 第三方头文件。

  2. “auto-importing has been activated without –enable-auto-import specified on the command line”