1.为什么要使用多线程
Cocos2d-x是一个单线程循环的引擎,引擎通过每一帧之间更新游戏中各元素的状态,以保证它们之间互不干扰,这个过程中尽管看起来成程序像是在并行运行,但实际上却是一个串行过程。单线程的好处就是我们无需去担心游戏对象更新的线程安全问题,但是当我们的程序遇到某些费时的I/O操作时,单线程的缺点也就显现出来了。
举例来说,在游戏进行场景跳转时,通常我们会释放当前场景的资源并加载下一个场景的资源,这样就需要将下一个界面需要用到的纹理加载到内存中,这一过程便需要对资源文件进行读写操作,而这种外部存储操作又十分耗时,如果需要加载的图片量很大并且分辨率很高,就很有可能会造成我们的主线程阻塞,因为处理器无法在如此短暂的时间间隔内(默认帧率1/60)完成这么大的计算量,而程序又因为只有一个线程不会中断当前执行内容去执行其它内容,所以这时候我们变会观察到界面上的帧率骤降甚至界面直接卡住。
为了规避此类问题的发生,Cocos2d-x在引擎中为开发者提供了异步加载的功能,我们可以向TextureCache发送一个异步加载文件的请求,TextureCache内部会帮助我们创建一个新的线程来完成耗时的加载纹理操作,而在我们的主线程中则可以继续执行其他的计算。
除了资源加载之外,网络读写也属于常见的费时操作之一,所以在客户/服务器系统使用线程也是比较常见的现象,例如HttpClient中的异步功能。
2.单核与多核
单核即只有一个处理器,多核即有多个处理器。我们现在的移动设备一般都是双核或四核,如iphone6、三星note4,较老的设备如iPhone4的cpu则只是单核。这里要说明的是单核多线程与多核多线程之间的差别。
单核设备中的多线程是并发的。
多核设备中的多线程是并行的或并发的。
下面来解释一下这两句话的含义,单核双线程是一种很常见的做法,例如我们编写一段具备多个线程的代码,让它在iphone4上面去运行,由于iphone4只有一个处理器,所以实际上我们所创建的新线程和主线程之间,是一种相互交错运行的状态,比如我们将时间片划分为100毫秒,那么当前的100毫秒内程序执行主线程,下一个100毫秒内程序可能就会去执行另一个线程,再过了100毫秒又回到了主线程,这样做的好处就是,不会让一个线程无期限的延迟,一旦时间片到了程序会强行中断当前的线程而去执行另一个线程。这样在宏观上看起来,它们就像是在同时执行,但事实上,它们仍然是分开执行的。
然而如果这段代码放到了三星note4上去执行,note4具有一个4核的cpu,在这种多处理器的设备上,我们的两个线程可以每个线程霸占一个处理器,并且独立的去执行,即同时运行而不需要去交错运行。这样的状态,我们称之为并行状态。所以,并发实际上是一种伪并行的状态,它只是一种假装在同时执行多个操作的状态。
3.线程安全问题
首先我们来了解一个概念,线程安全。
线程安全是指代码能被多个线程调用而不会产生灾难性的结果。这里我们举个简单的例子来说明(这里笔者使用的是POSIX线程的线程函数格式,理解大概意思就好)
如上述代码所示,假设我们现在启动了两个线程,两个线程的线程函数分别设为A和B(这里为了便于理解把线程函数分开写了,其实写一个线程函数让两个线程去执行就够了),运行程序后我们期望的控制台输出结果是,123456789.......(这段代码对于实现功能可能没有任意意义....这里只是举个例子说明)
但实际上运行的结果可能不是如此,我们期望的情况是在每个线程函数中,count值做一次加一的操作,然后输出这个count,但是由于不同线程的执行顺序是不可预知的,上述代码很可能出现这样的情况(假设设备是单核):count的初始值是0,现在轮到线程1运行,A中执行到了count +=1,此时count值便已等于1,本来之后应该输出1,但刚好时间片到这里结束了,现在被切换到了线程2,这时候线程2里面的count的值已经为1了,现在再做一次加1,变成了2,然后执行了print语句,输出一个2,然后时间片结束了,又回到了1,1则继续执行刚才没有执行的输出语句,但由于count值已经被线程2再次改变,这时候我们可能就会看到屏幕上的输出结果是 223456789.... 。
当然我说的这个情况未必一定会出现,原因是上文说的,不同线程的执行顺序是不可预知的,每次执行都会产生不同的结果,也许绝大多数情况下输出都是正常的。这个例子只是告诉大家,这样的情况线程就不安全了。
那么如何解决上述问题?
首先,count变量对于两个线程来说,它是一个共享的数据,那么两个线程同时访问这个共享数据就可能会出现问题,就比如之前的那段代码,线程1想要输出的count值是1,但是由于线程2在线程1还没有输出count的时候把这个值给改掉了,但是线程1并不知道这个count值被改掉了然后继续执行输出,结果线程1输出的值就是2。
解决这个问题,最常用的方法就是使线程"同步",注意,这里的同步指的可不是让线程步调一致的一起运行,我们所说的线程同步,指的是让线程有先后次序的去运行,你先运行完了,我再运行。
使用线程同步最常用的方法就是使相同数据的内存访问"互斥"的进行。用我们上述的例子来解释就是,当线程1里面进行count的加操作以及输出操作时,线程2就不允许访问count,这时候count2只能处于阻塞的状态,等线程1里面对count的操作完成后,线程2才可以访问,一次只允许一个线程去写数据,其它线程只能等待。
举个例子来说,假设我和你各代表一个线程,现在我想要去执行一个操作,上厕所,我在进入厕所之后为了防止你想占用测试,我就会把厕所的门锁上,如果你这个时候也想上厕所,那么就只能在门口等我上完解锁离开后在使用厕所。这里的锁,就好比我们所说的互斥量(互斥体)。我们可以通过对互斥量进行锁定和解除锁定的方式来确保在某一时间段内只有一个线程能够去操作这些数据。
在pthread中的互斥体类型用pthread_mutex_t表示,在C++ 11中可使用std::mutex。
例如刚才的代码可以写成:
pthread_mutex_t count_mutex = PTHREAD_MUTEX_INITIALIZER;@H_502_36@
/* 锁定保护count操作的互斥体。*/@H_502_36@
pthread_mutex_lock (&count_mutex);@H_502_36@
/* 已经完成了对count操作的处理,因此解除对互斥体的锁定。*/@H_502_36@
pthread_mutex_nlock (&count_mutex);@H_502_36@
除了互斥体之外,同步工具还有信号量以及条件变量,因为互斥量有时候尽管可以满足我们的需求,但是会浪费很多时间,使用这些工具可以帮助我们实现更复杂的控制模式。
4.Cocos2d-x中使用多线程的注意事项
Cocos2d-x所使用的内存管理机制以及OpenGL的接口函数都不是线程安全的,所以,不要试图在一个除主线程之外的其它线程内调用引擎所提供的内存管理的方法,例如在一个新线程中去创建一个精灵或是层之类的元素,这些元素在create()方法中均会调用autorelease,autorelease以及retain、release都不是线程安全的,OpenGL的上下文也不是线程安全的,所以也不要在新线程中去使用OpenGL的绘制功能。
5.pthread多线程
pthread是一个多线程库,全称是 POSIX 线程,因为它的API遵循国际正式标准POSIX。pthread线程库由C语言开发,可以运行在多个平台上,包括Andoird,iOS,以及Windows,pthread中的所有线程函数和数据类型都在<pthread.h>头文件中声明,也是Cocos2d-x之前推荐使用的多线程库。如今在3.x引入C++11的特性之后,取消了pthread库的引用,我们可以使用标准库thread进行多线程编程。
6.异步加载
笔者的开发环境是Xcode+Cocos2d-x 3.3beta0版本,下面我们来简单的了解一下异步加载的过程。
我们可以使用一个Loading界面很好的实现资源的预加载,只有将资源全部加载到内存后,我们在使用如Sprite,ImageView去创建对象的时候,才不会造成卡顿的现象。那么如何将图片异步加载到内存中,Cocos2d-x为我们提供了addImageAsync()方法,该方法位于TextureCache类中。下面我们来看一下这个方法中所作的工作
TextureCache::addImageAsync(@H_502_36@const@H_502_36@std::string &path,@H_502_36@std::function<@H_502_36@(Texture2D*)>& callback)@H_502_36@
{@H_502_36@
//创建一个纹理对象指针@H_502_36@
Texture2D *texture = nullptr;@H_502_36@
std::string fullpath = FileUtils::getInstance()->fullPathForFilename(path);@H_502_36@
//如果这个纹理已经加载 则返回@H_502_36@
auto it = _textures.find(fullpath);@H_502_36@
(texture != nullptr)@H_502_36@
{@H_502_36@
callback(texture);@H_502_36@
30.@H_502_36@
_loadingThread =@H_502_36@std::thread(&TextureCache::loadImage,宋体">this@H_502_36@);@H_502_36@
33.@H_502_36@
_needQuit =@H_502_36@false@H_502_36@34.@H_502_36@
35.@H_502_36@
36.@H_502_36@
== _asyncRefCount)@H_502_36@
39.@H_502_36@
43.@H_502_36@