自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

驚天秘密！從Thread開始，揭露Android線程通訊的詭計(jì)和主線程的陰謀

作者：佚名
移動(dòng)開發(fā) Android
我們?cè)贏ndroid開發(fā)過程中，幾乎都離不開線程。但是你對(duì)線程的了解有多少呢?它完美運(yùn)行的背后，究竟隱藏了多少不為人知的秘密呢?線程間互通暗語，傳遞信息究竟是如何做到的呢?Looper、Handler、MessageQueue究竟在這背后進(jìn)行了怎樣的運(yùn)作。本期，讓我們一起從Thread開始，逐步探尋這個(gè)完美的線程鏈背后的秘密。

背景介紹

我們?cè)贏ndroid開發(fā)過程中，幾乎都離不開線程。但是你對(duì)線程的了解有多少呢?它***運(yùn)行的背后，究竟隱藏了多少不為人知的秘密呢?線程間互通暗語，傳遞信息究竟是如何做到的呢?Looper、Handler、MessageQueue究竟在這背后進(jìn)行了怎樣的運(yùn)作。本期，讓我們一起從Thread開始，逐步探尋這個(gè)***的線程鏈背后的秘密。

注意，大部分分析在代碼中，所以請(qǐng)仔細(xì)關(guān)注代碼哦!

從Tread的創(chuàng)建流程開始

在這一個(gè)環(huán)節(jié)，我們將一起一步步的分析Thread的創(chuàng)建流程。

話不多說，直接代碼里看。

線程創(chuàng)建的起始點(diǎn)init()

  1. // 創(chuàng)建Thread的公有構(gòu)造函數(shù)，都調(diào)用的都是這個(gè)私有的init()方法。我們看看到底干什么了。 
  2.  
  3. /** 
  4.  
  5.      * 
  6.  
  7.      * @param 線程組 
  8.  
  9.      * @param 就是我們平時(shí)接觸最多的Runnable同學(xué) 
  10.  
  11.      * @param 指定線程的名稱 
  12.  
  13.      * @param 指定線程堆棧的大小 
  14.  
  15.      */ 
  16.  
  17. private void init(ThreadGroup g, Runnable target, String name, long stackSize) { 
  18.  
  19.         Thread parent = currentThread();            //先獲取當(dāng)前運(yùn)行中的線程。這一個(gè)Native函數(shù)，暫時(shí)不用理會(huì)它怎么做到的。黑盒思想，哈哈！ 
  20.  
  21.         if (g == null) { 
  22.  
  23.             g = parent.getThreadGroup();            //如果沒有指定ThreadGroup，將獲取父線程的TreadGroup 
  24.  
  25.         } 
  26.  
  27.         g.addUnstarted();                           //將ThreadGroup中的就緒線程計(jì)數(shù)器增加一。注意，此時(shí)線程還并沒有被真正加入到ThreadGroup中。 
  28.  
  29.         this.group = g;                             //將Thread實(shí)例的group賦值。從這里開始線程就擁有ThreadGroup了。 
  30.  
  31.         this.target = target;                       //給Thread實(shí)例設(shè)置Runnable。以后start()的時(shí)候執(zhí)行的就是它了。 
  32.  
  33.         this.priority = parent.getPriority();       //設(shè)置線程的優(yōu)先權(quán)重為父線程的權(quán)重 
  34.  
  35.         this.daemon = parent.isDaemon();            //根據(jù)父線程是否是守護(hù)線程來確定Thread實(shí)例是否是守護(hù)線程。 
  36.  
  37.         setName(name);                              //設(shè)置線程的名稱   
  38.  
  39.         init2(parent);                              //納尼？又一個(gè)初始化，參數(shù)還是父線程。不急，稍后在看。 
  40.  
  41.         /* Stash the specified stack size in case the VM cares */ 
  42.  
  43.         this.stackSize = stackSize;                 //設(shè)置線程的堆棧大小 
  44.  
  45.         tid = nextThreadID();                       //線程的id。這是個(gè)靜態(tài)變量，調(diào)用這個(gè)方法會(huì)自增，然后作為線程的id。 
  46.  
  47.     }  

第二個(gè)init2() 

 

 

 

至此，我們的Thread就初始化完成了，Thread的幾個(gè)重要成員變量都賦值了。

啟動(dòng)線程，開車?yán)?

通常，我們這樣了啟動(dòng)一條線程。

  1. Thread threadDemo = new Thread(() -> { 
  2.  
  3.     }); 
  4.  
  5. threadDemo.start();  

那么start()背后究竟隱藏著什么樣不可告人的秘密呢?是人性的扭曲?還是道德的淪喪?讓我們一起點(diǎn)進(jìn)start()。探尋start()背后的秘密。

  1. //如我們所見，這個(gè)方法是加了鎖的。原因是避免開發(fā)者在其它線程調(diào)用同一個(gè)Thread實(shí)例的這個(gè)方法，從而盡量避免拋出異常。 
  2.  
  3. //這個(gè)方法之所以能夠執(zhí)行我們傳入的Runnable里的run()方法，是應(yīng)為JVM調(diào)用了Thread實(shí)例的run()方法。 
  4.  
  5. public synchronized void start() { 
  6.  
  7.         //檢查線程狀態(tài)是否為0，為0表示是一個(gè)新狀態(tài)，即還沒被start()過。不為0就拋出異常。 
  8.  
  9.         //就是說，我們一個(gè)Thread實(shí)例，我們只能調(diào)用一次start()方法。 
  10.  
  11.         if (threadStatus != 0) 
  12.  
  13.             throw new IllegalThreadStateException(); 
  14.  
  15.         //從這里開始才真正的線程加入到ThreadGroup組里。再重復(fù)一次，前面只是把nUnstartedThreads這個(gè)計(jì)數(shù)器進(jìn)行了增量，并沒有添加線程。 
  16.  
  17.         //同時(shí)，當(dāng)線程啟動(dòng)了之后，nUnstartedThreads計(jì)數(shù)器會(huì)-1。因?yàn)榫途w狀態(tài)的線程少了一條??！ 
  18.  
  19.         group.add(this); 
  20.  
  21.         started = false; 
  22.  
  23.         try { 
  24.  
  25.             nativeCreate(this, stackSize, daemon);  //又是個(gè)Native方法。這里交由JVM處理，會(huì)調(diào)用Thread實(shí)例的run()方法。 
  26.  
  27.             started = true; 
  28.  
  29.         } finally { 
  30.  
  31.             try { 
  32.  
  33.                 if (!started) { 
  34.  
  35.                     group.threadStartFailed(this);  //如果沒有被啟動(dòng)成功，Thread將會(huì)被移除ThreadGroup，同時(shí)，nUnstartedThreads計(jì)數(shù)器又增量1了。 
  36.  
  37.                 } 
  38.  
  39.             } catch (Throwable ignore) { 
  40.  
  41.                 
  42.  
  43.             } 
  44.  
  45.         } 
  46.  
  47.     }  

好吧，最精華的函數(shù)是native的，先當(dāng)黑盒處理吧。只要知道它能夠調(diào)用到Thread實(shí)例的run()方法就行了。那我們?cè)倏纯磖un()方法到底干了什么神奇的事呢? 

 

 

 

黑實(shí)驗(yàn) 

 

 

 

上面的實(shí)驗(yàn)表明了，我們完全可以用Thread來作為Runnable。

幾個(gè)常見的線程手段(操作)

Thread.sleep()那不可告人的秘密

我們平時(shí)使用Thread.sleep()的頻率也比較高，所以我們?cè)谝黄鹧芯垦芯縏hread.sleep()被調(diào)用的時(shí)候發(fā)生了什么。

在開始之前，先介紹一個(gè)概念——納秒。1納秒=十億分之一秒。可見用它計(jì)時(shí)將會(huì)非常的精準(zhǔn)。但是由于設(shè)備限制，這個(gè)值有時(shí)候并不是那么準(zhǔn)確，但還是比毫秒的控制粒度小很多。

  1. //平時(shí)我們調(diào)用的Thread.sleep(long)***調(diào)用到這個(gè)方法來，后一個(gè)陌生一點(diǎn)的參數(shù)就是納秒。 
  2.  
  3. //你可以在納秒級(jí)控制線程。 
  4.  
  5. public static void sleep(long millis, int nanos) 
  6.  
  7.     throws InterruptedException { 
  8.  
  9.         //下面三個(gè)檢測(cè)毫秒和納秒的設(shè)置是否合法。 
  10.  
  11.         if (millis < 0) { 
  12.  
  13.             throw new IllegalArgumentException("millis < 0: " + millis); 
  14.  
  15.         } 
  16.  
  17.         if (nanos < 0) { 
  18.  
  19.             throw new IllegalArgumentException("nanos < 0: " + nanos); 
  20.  
  21.         } 
  22.  
  23.         if (nanos > 999999) { 
  24.  
  25.             throw new IllegalArgumentException("nanos > 999999: " + nanos); 
  26.  
  27.         } 
  28.  
  29.      
  30.  
  31.         if (millis == 0 && nanos == 0) { 
  32.  
  33.             if (Thread.interrupted()) {   //當(dāng)睡眠時(shí)間為0時(shí)，檢測(cè)線程是否中斷，并清除線程的中斷狀態(tài)標(biāo)記。這是個(gè)Native的方法。 
  34.  
  35.               throw new InterruptedException();  //如果線程被設(shè)置了中斷狀態(tài)為true了(調(diào)用Thread.interrupt())。那么他將拋出異常。如果在catch住這個(gè)異常之后return線程，那么線程就停止了。   
  36.  
  37.               //需要注意，在調(diào)用了Thread.sleep()之后，再調(diào)用isInterrupted()得到的結(jié)果永遠(yuǎn)是False。別忘了Thread.interrupted()在檢測(cè)的同時(shí)還會(huì)清除標(biāo)記位置哦！ 
  38.  
  39.             } 
  40.  
  41.             return; 
  42.  
  43.         } 
  44.  
  45.         long start = System.nanoTime();  //類似System.currentTimeMillis()。但是獲取的是納秒，可能不準(zhǔn)。 
  46.  
  47.         long duration = (millis * NANOS_PER_MILLI) + nanos;   
  48.  
  49.         Object lock = currentThread().lock;  //獲得當(dāng)前線程的鎖。 
  50.  
  51.         synchronized (lock) {   //對(duì)當(dāng)前線程的鎖對(duì)象進(jìn)行同步操作 
  52.  
  53.             while (true) { 
  54.  
  55.                 sleep(lock, millis, nanos);  //這里又是一個(gè)Native的方法，并且也會(huì)拋出InterruptedException異常。 
  56.  
  57.                 //據(jù)我估計(jì)，調(diào)用這個(gè)函數(shù)睡眠的時(shí)長是不確定的。 
  58.  
  59.                 long now = System.nanoTime(); 
  60.  
  61.                 long elapsed = now - start;  //計(jì)算線程睡了多久了 
  62.  
  63.                 if (elapsed >= duration) {   //如果當(dāng)前睡眠時(shí)長，已經(jīng)滿足我們的需求，就退出循環(huán)，睡眠結(jié)束。 
  64.  
  65.                     break; 
  66.  
  67.                 } 
  68.  
  69.                 duration -= elapsed;   //減去已經(jīng)睡眠的時(shí)間，重新計(jì)算需要睡眠的時(shí)長。 
  70.  
  71.                 start = now; 
  72.  
  73.                 millis = duration / NANOS_PER_MILLI;  //重新計(jì)算毫秒部分 
  74.  
  75.                 nanos = (int) (duration % NANOS_PER_MILLI); //重新計(jì)算微秒部分 
  76.  
  77.             } 
  78.  
  79.         } 
  80.  
  81.     }  

通過上面的分析可以知道，使線程休眠的核心方法就是一個(gè)Native函數(shù)sleep(lock, millis, nanos)，并且它休眠的時(shí)常是不確定的。因此，Thread.sleep()方法使用了一個(gè)循環(huán)，每次檢查休眠時(shí)長是否滿足需求。

同時(shí)，需要注意一點(diǎn)，如果線程的interruted狀態(tài)在調(diào)用sleep()方法時(shí)被設(shè)置為true，那么在開始休眠循環(huán)前會(huì)拋出InterruptedException異常。

Thread.yield()究竟隱藏了什么?

這個(gè)方法是Native的。調(diào)用這個(gè)方法可以提示cpu，當(dāng)前線程將放棄目前cpu的使用權(quán)，和其它線程重新一起爭奪新的cpu使用權(quán)限。當(dāng)前線程可能再次獲得執(zhí)行，也可能沒獲得。就醬。

無處不在的wait()究竟是什么?

大家一定經(jīng)常見到，不論是哪一個(gè)對(duì)象的實(shí)例，都會(huì)在最下面出現(xiàn)幾個(gè)名為wait()的方法。等待?它們究竟是怎樣的一種存在，讓我們一起點(diǎn)擊去看看。

哎喲我去，都是Native函數(shù)啊。 

 

 

[[186444]] 

那就看看文檔它到底是什么吧。

根據(jù)文檔的描述，wait()配合notify()和notifyAll()能夠?qū)崿F(xiàn)線程間通訊，即同步。在線程中調(diào)用wait()必須在同步代碼塊中調(diào)用，否則會(huì)拋出IllegalMonitorStateException異常。因?yàn)閣ait()函數(shù)需要釋放相應(yīng)對(duì)象的鎖。當(dāng)線程執(zhí)行到wait()時(shí)，對(duì)象會(huì)把當(dāng)前線程放入自己的線程池中，并且釋放鎖，然后阻塞在這個(gè)地方。直到該對(duì)象調(diào)用了notify()或者notifyAll()后，該線程才能重新獲得，或者有可能獲得對(duì)象的鎖，然后繼續(xù)執(zhí)行后面的語句。

呃。。。好吧，在說明一下notify()和notifyAll()的區(qū)別。

  • notify()

調(diào)用notify()后，對(duì)象會(huì)從自己的線程池中(也就是對(duì)該對(duì)象調(diào)用了wait()函數(shù)的線程)隨機(jī)挑選一條線程去喚醒它。也就是一次只能喚醒一條線程。如果在多線程情況下，只調(diào)用一次notify()，那么只有一條線程能被喚醒，其它線程會(huì)一直在

  • notifyAll()

調(diào)用notifyAll()后，對(duì)象會(huì)喚醒自己的線程池中的所有線程，然后這些線程就會(huì)一起搶奪對(duì)象的鎖。

扒一扒Looper、Handler、MessageQueue之間的愛恨情仇

我們可能過去都寫過形如這樣的代碼： 

 

 

 

很多同學(xué)知道，在線程中使用Handler時(shí)(除了Android主線程)必須把它放在Looper.prepare()和Looper.loop()之間。否則會(huì)拋出RuntimeException異常。但是為什么要這么做呢?下面我們一起來扒一扒這其中的內(nèi)幕。 

 

 

[[186445]] 

從Looper.prepare()開始

當(dāng)Looper.prepare()被調(diào)用時(shí)，發(fā)生了什么? 

 

 

 

經(jīng)過上面的分析，我們已經(jīng)知道Looper.prepare()調(diào)用之后發(fā)生了什么。

但是問題來了!sThreadLocal是個(gè)靜態(tài)的ThreadLocal 實(shí)例(在Android中ThreadLocal的范型固定為Looper)。就是說，當(dāng)前進(jìn)程中的所有線程都共享這一個(gè)ThreadLocal。那么，Looper.prepare()既然是個(gè)靜態(tài)方法，Looper是如何確定現(xiàn)在應(yīng)該和哪一個(gè)線程建立綁定關(guān)系的呢?我們接著往里扒。

來看看ThreadLocal的get()、set()方法。 

 

 

 

創(chuàng)建Handler

Handler可以用來實(shí)現(xiàn)線程間的通行。在Android中我們?cè)谧泳€程作完數(shù)據(jù)處理工作時(shí)，就常常需要通過Handler來通知主線程更新UI。平時(shí)我們都使用new Handler()來在一個(gè)線程中創(chuàng)建Handler實(shí)例，但是它是如何知道自己應(yīng)該處理那個(gè)線程的任務(wù)呢。下面就一起扒一扒Handler。

  1. public Handler() { 
  2.  
  3.         this(null, false);  
  4.  
  5. } 
  6.  
  7.      
  8.  
  9. public Handler(Callback callback, boolean async) {      //可以看到，最終調(diào)用了這個(gè)方法。 
  10.  
  11.         if (FIND_POTENTIAL_LEAKS) { 
  12.  
  13.             final Class<? extends Handler> klass = getClass(); 
  14.  
  15.             if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) && 
  16.  
  17.                     (klass.getModifiers() & Modifier.STATIC) == 0) { 
  18.  
  19.                 Log.w(TAG, "The following Handler class should be static or leaks might occur: " + 
  20.  
  21.                     klass.getCanonicalName()); 
  22.  
  23.             } 
  24.  
  25.         } 
  26.  
  27.         mLooper = Looper.myLooper();                    //重點(diǎn)?。≡谶@里Handler和當(dāng)前Thread的Looper綁定了。Looper.myLooper()就是從ThreadLocale中取出當(dāng)前線程的Looper。 
  28.  
  29.         if (mLooper == null) { 
  30.  
  31.             //如果子線程中new Handler()之前沒有調(diào)用Looper.prepare()，那么當(dāng)前線程的Looper就還沒創(chuàng)建。就會(huì)拋出這個(gè)異常。 
  32.  
  33.             throw new RuntimeException( 
  34.  
  35.                 "Can't create handler inside thread that has not called Looper.prepare()"); 
  36.  
  37.         } 
  38.  
  39.         mQueue = mLooper.mQueue;  //賦值Looper的MessageQueue給Handler。 
  40.  
  41.         mCallback = callback; 
  42.  
  43.         mAsynchronous = async; 
  44.  
  45.     }  

Looper.loop()

我們都知道，在Handler創(chuàng)建之后，還需要調(diào)用一下Looper.loop()，不然發(fā)送消息到Handler沒有用!接下來，扒一扒Looper究竟有什么樣的魔力，能夠把消息準(zhǔn)確的送到Handler中處理。

  1. public static void loop() { 
  2.  
  3.         final Looper me = myLooper();   //這個(gè)方法前面已經(jīng)提到過了，就是獲取到當(dāng)前線程中的Looper對(duì)象。 
  4.  
  5.         if (me == null) {  
  6.  
  7.             //沒有Looper.prepare()是要報(bào)錯(cuò)的！ 
  8.  
  9.             throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread."); 
  10.  
  11.         } 
  12.  
  13.         final MessageQueue queue = me.mQueue;       //獲取到Looper的MessageQueue成員變量，這是在Looper創(chuàng)建的時(shí)候new的。 
  14.  
  15.         //這是個(gè)Native方法，作用就是檢測(cè)一下當(dāng)前線程是否屬于當(dāng)前進(jìn)程。并且會(huì)持續(xù)跟蹤其真實(shí)的身份。 
  16.  
  17.         //在IPC機(jī)制中，這個(gè)方法用來清除IPCThreadState的pid和uid信息。并且返回一個(gè)身份，便于使用restoreCallingIdentity()來恢復(fù)。 
  18.  
  19.         Binder.clearCallingIdentity(); 
  20.  
  21.         final long ident = Binder.clearCallingIdentity(); 
  22.  
  23.         for (;;) {  //重點(diǎn)(敲黑板)！這里是個(gè)死循環(huán)，一直等待抽取消息、發(fā)送消息。 
  24.  
  25.             Message msg = queue.next(); //  從MessageQueue中抽取一條消息。至于怎么取的，我們稍后再看。 
  26.  
  27.             if (msg == null) { 
  28.  
  29.                 // No message indicates that the message queue is quitting. 
  30.  
  31.                 return; 
  32.  
  33.             } 
  34.  
  35.             // This must be in a local variable, in case a UI event sets the logger 
  36.  
  37.             final Printer logging = me.mLogging; 
  38.  
  39.             if (logging != null) { 
  40.  
  41.                 logging.println(">>>>> Dispatching to " + msg.target + " " + 
  42.  
  43.                         msg.callback + ": " + msg.what); 
  44.  
  45.             } 
  46.  
  47.             final long traceTag = me.mTraceTag;   //取得MessageQueue的跟蹤標(biāo)記 
  48.  
  49.             if (traceTag != 0) { 
  50.  
  51.                 Trace.traceBegin(traceTag, msg.target.getTraceName(msg));  //開始跟蹤本線程的MessageQueue中的當(dāng)前消息，是Native的方法。 
  52.  
  53.             } 
  54.  
  55.             try { 
  56.  
  57.                 msg.target.dispatchMessage(msg);   //嘗試分派消息到和Message綁定的Handler中 
  58.  
  59.             } finally { 
  60.  
  61.                 if (traceTag != 0) { 
  62.  
  63.                     Trace.traceEnd(traceTag);      //這個(gè)和Trace.traceBegin()配套使用。 
  64.  
  65.                 } 
  66.  
  67.             } 
  68.  
  69.             if (logging != null) { 
  70.  
  71.                 logging.println("<<<<< Finished to " + msg.target + " " + msg.callback); 
  72.  
  73.             } 
  74.  
  75.              
  76.  
  77.             final long newIdent = Binder.clearCallingIdentity();   //what？又調(diào)用這個(gè)Native方法了。這里主要是為了再次驗(yàn)證，線程所在的進(jìn)程是否發(fā)生改變。 
  78.  
  79.             if (ident != newIdent) { 
  80.  
  81.                 Log.wtf(TAG, "Thread identity changed from 0x" 
  82.  
  83.                         + Long.toHexString(ident) + " to 0x" 
  84.  
  85.                         + Long.toHexString(newIdent) + " while dispatching to " 
  86.  
  87.                         + msg.target.getClass().getName() + " " 
  88.  
  89.                         + msg.callback + " what=" + msg.what); 
  90.  
  91.             } 
  92.  
  93.             msg.recycleUnchecked();   //回收釋放消息。 
  94.  
  95.         } 
  96.  
  97.     }  

從上面的分析可以知道，當(dāng)調(diào)用了Looper.loop()之后，線程就就會(huì)被一個(gè)for(;;)死循環(huán)阻塞，每次等待MessageQueue的next()方法取出一條Message才開始往下繼續(xù)執(zhí)行。然后通過Message獲取到相應(yīng)的Handler (就是target成員變量)，Handler再通過dispatchMessage()方法，把Message派發(fā)到handleMessage()中處理。

這里需要注意，當(dāng)線程loop起來是時(shí)，線程就一直在循環(huán)中。就是說Looper.loop()后面的代碼就不能被執(zhí)行了。想要執(zhí)行，需要先退出loop。

  1. Looper myLooper = Looper.myLoop(); 
  2.  
  3. myLooper.quit();        //普通退出方式。 
  4.  
  5. myLooper.quitSafely();  //安全的退出方式。 

現(xiàn)在又產(chǎn)生一個(gè)疑問，MessageQueue的next()方法是如何阻塞住線程的呢?接下來，扒一扒這個(gè)幕后黑手MessageQueue。

幕后黑手MessageQueue

MessageQueue是一個(gè)用單鏈的數(shù)據(jù)結(jié)構(gòu)來維護(hù)消息列表。 

 

 

 

可以看到。MessageQueue在取消息(調(diào)用next())時(shí)，會(huì)進(jìn)入一個(gè)死循環(huán)，直到取出一條Message返回。這就是為什么Looper.loop()會(huì)在queue.next()處等待的原因。

那么，一條Message是如何添加到MessageQueue中呢?要弄明白***的真相，我們需要調(diào)查一下mHandler.post()這個(gè)方法。

Handler究竟對(duì)Message做了什么?

Handler的post()系列方法，最終調(diào)用的都是下面這個(gè)方法： 

 

 

 

接下來就看看MessageQueue的enqueueMessage()作了什么。 

 

 

 

至此，我們已經(jīng)揭露了Looper、Handler、MessageQueue隱藏的秘密。

另一個(gè)疑問?

也許你已經(jīng)注意到在主線程中可以直接使用Handler，而不需要Looper.prepare()和Looper.loop()。為什么可以做到這樣呢?根據(jù)之前的分析可以知道，主線程中必然存在Looper.prepare()和Looper.loop()。既然如此，為什么主線程沒有被loop()阻塞呢?看一下ActivityThread來弄清楚到底是怎么回事。 

 

 

 

注意ActivityThread并沒有繼承Thread，它的Handler是繼承Handler的私有內(nèi)部類H.class。在H.class的handleMessage()中，它接受并執(zhí)行主線程中的各種生命周期狀態(tài)消息。UI的16ms的繪制也是通過Handler來實(shí)現(xiàn)的。也就是說，主線程中的所有操作都是在Looper.prepareMainLooper()和Looper.loop()之間進(jìn)行的。進(jìn)一步說是在主Handler中進(jìn)行的。

總結(jié)

  1. Android中Thread在創(chuàng)建時(shí)進(jìn)行初始化，會(huì)使用當(dāng)前線程作為父線程，并繼承它的一些配置。
  2. Thread初始化時(shí)會(huì)被添加到指定/父線程的ThreadGroup中進(jìn)行管理。
  3. Thread正真啟動(dòng)是一個(gè)native函數(shù)完成的。
  4. 在Android的線程間通信中，需要先創(chuàng)建Looper，就是調(diào)用Looper.prepare()。這個(gè)過程中會(huì)自動(dòng)依賴當(dāng)前Thread，并且創(chuàng)建MessageQueue。經(jīng)過上一步，就可以創(chuàng)建Handler了，默認(rèn)情況下，Handler會(huì)自動(dòng)依賴當(dāng)前線程的Looper，從而依賴相應(yīng)的MessageQueue，也就知道該把消息放在哪個(gè)地方了。MessageQueue通過Message.next實(shí)現(xiàn)了一個(gè)單鏈表結(jié)構(gòu)來緩存Message。消息需要送達(dá)Handler處理，還必須調(diào)用Looper.loop()啟動(dòng)線程的消息泵送循環(huán)。loop()內(nèi)部是***循環(huán)，阻塞在MessageQueue的next()方法上，因?yàn)閚ext()方法內(nèi)部也是一個(gè)***循環(huán)，直到成功從鏈表中抽取一條消息返回為止。然后，在loop()方法中繼續(xù)進(jìn)行處理，主要就是把消息派送到目標(biāo)Handler中。接著進(jìn)入下一次循環(huán)，等待下一條消息。由于這個(gè)機(jī)制，線程就相當(dāng)于阻塞在loop()這了。

經(jīng)過上面的揭露，我們已經(jīng)對(duì)線程及其相互之間通訊的秘密有所了解。掌握了這些以后，相信在以后的開發(fā)過程中我們可以思路清晰的進(jìn)行線程的使用，并且能夠吸收Android在設(shè)計(jì)過程中的精華思想。

責(zé)任編輯：龐桂玉 來源： 安卓巴士Android開發(fā)者門戶
Android線程Tread
相關(guān)推薦

2011-06-22 15:42:18

QT 信號(hào) 槽

2012-07-26 15:15:03

微軟Office2013蘋果

2015-03-16 14:02:35

GoogleAndroidCyanogen

2024-05-20 08:21:36

Activity內(nèi)部類接口

2025-04-28 08:20:40

ndroid主線程線程

2010-03-15 18:34:08

Java多線程

2014-04-08 14:19:06

Android開發(fā)UI線程

2010-02-24 11:19:00

Python主線程

2009-06-29 17:54:10

Java多線程Thread類創(chuàng)建線程

2021-06-16 14:18:37

NettyReactor線程模型

2012-05-14 17:09:05

iOS

2021-09-11 15:26:23

Java多線程線程池

2020-12-21 06:18:15

Android線程主線程

2017-06-23 15:45:09

AndroidThread

2022-08-29 10:52:37

線程函數(shù)操作系統(tǒng)

2022-07-27 13:44:51

數(shù)據(jù)泄露網(wǎng)絡(luò)安全

2010-03-01 13:28:44

Python子線程

2017-03-13 10:41:33

iOSUI操作主線程

2021-03-11 00:07:30

線程Thread程序

2010-02-02 16:47:12

Python主線程
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)