再读Handler机制

一、引言

距离上一次阅读Handler源码已经半年多过去了，当时读源码的目的更多的是忙于毕业找工作，为面试做准备，现在则是想更多地了解Android相关机制。半年多过去了，回头看当时的源码解读笔记（当时不写博客），发现有很多地方并没有很好地解释清楚，于是想趁着这2018结束之际再次根据自己的想法整理一遍，感兴趣的童鞋可以看看。

所谓Handler机制，实际是线程切换机制。在我们日常开发中用的最多的是通过Handler来更新UI视图，而Handler除了用于线程切换外，Handler、Looper、ThreadLocal、MessageQueue、Message如何融合、构成一个成熟框架的思想更值得我们学习，这也是写本文的目的：比较深入全面地理解Handler机制。

二、预热知识

通常，我们使用Handler是这样的：

private Handler mHandler1;

 mHandler1 = new Handler(new Handler.Callback() {
        @Override
        public boolean handleMessage(Message msg) {
            // 操作 UI
            textView.setText(String.valueOf(msg.obj));
            return false;
        }
    });

又如这样手动建立一个消息循环：

Handler mHandler;
Looper mLooper;
private void createHandlerLoop() {
   Thread looperThread =  new Thread(new Runnable() {
        @Override
        public void run() {
            Looper.prepare();
            mLooper = Looper.myLooper();
            mHandler = new Handler(new Handler.Callback() {
                @Override
                public boolean handleMessage(Message msg) {
                    // 操作UI时异常
                    // Looper不执行于UI线程，不能直接操作View控件
                    // textView.setText(String.valueOf(msg.obj));
                    Toast.makeText(MainActivity.this, String.valueOf(msg.obj), Toast.LENGTH_SHORT).show();
                    return true;
                }
            });
            Looper.loop();
        }
    });
    looperThread.start();
}

然后我们给两个Handler发送消息，这里我们从非主线程发送消息：

private ExecutorService mExecutorService = Executors.newCachedThreadPool();
public void sendMessage(View view) {
    mExecutorService.submit(new Runnable() {
        @Override
        public void run() {
            if (mHandler != null) 
                mHandler.obtainMessage(1, "" + Math.random()).sendToTarget(); 
            if (mHandler1 != null) 
                mHandler1.obtainMessage(1, "`from mHandler1::" + Math.random()).sendToTarget();
        }
    }); 
}

我们知道Handler运行于Looper，而Looper运行于创建它的线程中，因此可以说Handler运行于创建它的线程，这里刚好验证一下，我们给mHandler1和mHandler发消息，然后在其中更新UI，此时mHandler1正常更新，而mHandler则报非主线程更新UI的异常，可见 mHandler1的Looper运行于主线程，而mHander则运行于looperThread。

当然，这些只是表象上，我们来看看为啥它运行在创建它的线程。

首先来看看Handler的构造方法

public Handler(Callback callback, boolean async) {
    // ...
    mLooper = Looper.myLooper();
    // ...
}

这里主要关注到Looper.myLooper()，它是从ThreadLocal中获取到的，而之所以能得到，是因为在执行Looper.prepare()方法时会创建一个Looper实例存入其中，这也就是为什么我们在手动建立消息循环时必须要执行Looper.prepare()的原因了。

// 
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

注意到上面sThreadLocal被static final所修饰，也就是说它以常量的形式存在于进程中，所以我们应用进程中的所有Looper实例都会独立存储在其中，无论运行在主线程还是其他线程。ThreadLocal#get()源码如下：

public T get() {
    // 1.  拿到当前线程
    Thread t = Thread.currentThread();
    // 2.  取出当前线程的独立数据
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            // 3. 取出运行在当前线程的 Looper 实例
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}

可以看出，从ThreadLocal取出Looper实例时会根据当前运行的线程去取，也就是说在Handler执行于的线程决定于Looper所执行于的线程，也就是创建它的，并执行了Looper#prepare()的线程。

好了，接下来将结合源码分析Handler、Looper、ThreadLocal、MessageQueue、Message的具体运作原理。

三、 Looper 源码分析

在Looper对象创建时会创建一个消息队列，并记录当前线程信息

private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread();
}

而实际上调用Looper.prepare()时才会真正意义上的创建Looper对象，Looper对象会记录在ThreadLocal中，而ThreadLocal在这里是个static final常量，意味着会在运行时以常量形式记录在常量池，从而保证使用到Looper的线程都只对应这唯一的ThreadLocal常量，也就保证不同使用到Looper消息循环的线程中都对应着唯一的Looper，且相互之间是独立的。

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

loop()方法则是个死循环，所以执行之后，会使得创建它的线程就处于阻塞状态，此时会一直处于从MessageQueue中提取Message的状态，直到调用Looper.quit()方法退出消息队列。Looper.quit()执行后使得queue.next()返回Message为null,Looper也随即退出，线程最终执行结束。

在消息循环正常执行过程中，会将每个从消息队列中提取到的消息分发给handler#dispatchMessage(msg)处理，这里的msg.target就是Message记录下来的发送它的那个Handler。

public static void loop() {
    final Looper me = myLooper();
    final MessageQueue queue = me.mQueue; 
    // . . .
    for (;;) {
        Message msg = queue.next(); // might block
        if (msg == null) {  // 拿到的消息为null了，说明消息队列已经退出了，因而退出消息循环
            return;
        }

        try { // 分发消息给handler处理
            msg.target.dispatchMessage(msg); 
        } finally { 
            // ...
        } 
    }
}

执行mQueue.quit(false)后消息队列会删除队列内的所有消息，并把根节点Message设置为null（MessageQueue是个单向链表结构，后面会讲到）,所以上面如果queue.next()拿到的消息为null了，就说明消息队列已经退出，因而就会退出Looper#loop()，也就是退出消息循环。

public void quit() {
    mQueue.quit(false);
}
void quit(boolean safe) {
    // ...
    synchronized (this) {
        // ... 
        if (safe) {
            removeAllFutureMessagesLocked();
        } else {
            removeAllMessagesLocked();
        } 
        // We can assume mPtr != 0 because mQuitting was previously false.
        nativeWake(mPtr);
    }
}
private void removeAllMessagesLocked() {
    Message p = mMessages;
    while (p != null) {
        Message n = p.next;
        p.recycleUnchecked();
        p = n;
    }
    mMessages = null;
}

至于Handler.dispatchMessage()，源码如下，可见它首先会看看是否给Message设置了回调，如果有，那执行Message的回调方法，如果没有，则看看自己的回调，如果没有再就执行自己的方法；所以Message自身的回调是优先级最高的，其次是自身回调，最后才是自身的方法。

public void dispatchMessage(Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

以上整个分析流程下来就可以得出如下草图，其中包含了线程切换的概念在内：

Handler机制.png

以上便是Handler机制的核心内容，也可以说是Looper的运行流程，当然这还没完，因为我们在分析过程中依然存在其他疑问，比如以单向链表结构为基础的Messagequque为啥这么设计、ThreadLocal为啥能够独立存储线程数据等。

三、MessageQueue 源码分析

消息队列顾名思义是用来存放Message的队列，但实际上它不是使用队列，而是以Message为节点的单链表结构；它提供enqueueMessage(Message msg, long when)方法用来插入消息，next()来提取消息，它是一个阻塞方法，只有当Looper.quit调用后它才会退出。

这里重点分析一下它的next()方法，它采用了线程安全设计，并且它也是阻塞式的，我们先来看看源码：

Message next() {
    final long ptr = mPtr; // 留意 mPtr
    if (ptr == 0) {
        return null;
    }
    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;
    for (;;) {
        if (nextPollTimeoutMillis != 0) {
            Binder.flushPendingCommands();
        }

        nativePollOnce(ptr, nextPollTimeoutMillis);
        
        synchronized (this) {
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
            if (msg != null && msg.target == null) {
                // 1. 遍历单向链表，也就是消息队列，查找尾部节点
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }

            if (msg != null) {
                // 2. 根据消息的执行时间判定是否要返回、处理这条消息
                if (now < msg.when) {
                    // 还没轮到它
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else { // 时间到，就是它了
                    mBlocked = false;
                    if (prevMsg != null) {  // 删除队尾节点
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    // 3. 这条消息可以处理了，则标记为正在使用并返回
                    msg.next = null;
                    msg.markInUse();
                    return msg;
                }
            } else {
                // No more messages.
                nextPollTimeoutMillis = -1;
            }

            // 检查消息循环是否退出
            if (mQuitting) {
                dispose();
                return null;
            }
            // 其他情况，则继续循环等待
        }
        // ...
    }
}

由于是基于单向链表的设计，因而每次如果想要得到队尾节点都需要遍历整个队列，直到定位到队尾。一旦定位到了队尾，且它不为null，那么就会根据消息的执行时间判定是否要返回、处理这条消息，如果还没到点，那么继续循环（也可看成是在等待，如果是异步isAsynchronous的,那么就直接使用这个消息，而不需要定位到队尾），直到达到了执行时间，而达到执行时间后，说明这条消息可以处理了，则标记为已用，并返回给Looper进行分发。

MessageQueue#next.png

update 2021-01-17： 上面关于阻塞等待的问题只是一笔带过，感觉解释的太浅显，漏掉了关键的nativePollOnce，当时没理解透吧，现在来补充一下。

为什么这里next是死循环，却不会导致ANR呢？或者说导致导致CPU满载呢？ 相信很多小伙伴面试的时候，面试官都喜欢问这个问题，当然我也一样被问过，大概在两年前吧。当时我的回答就比较模糊了，我说是因为当消息队列为空的时候，或者消息还没有到执行时间时，也就是我们postDelayed的消息的执行时间，Looper会处于等待状态，此时不会太消耗CPU，直到有消息执行可以执行；当然这回答感觉也没啥太大毛病，但是不够细节，我之所了最终呈现的现象或结果，但是并没有给出很好的解释或依据，能表明它确实是不会耗尽CPU资源或者卡死；

OK，下面我们就来补充补充细节，我们知道 nativePollOnce 是个 native 方法 , 直接上C++源码:

static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
        jlong ptr, jint timeoutMillis) {
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
    nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}

注意到ptr, 我们执行nativePollOnce(ptr, nextPollTimeoutMillis);的时候会传入一个mPtr，这个实际是NativeMessageQueue的一个指针，它是nativeInit()的返回值，创建过程如下：

    MessageQueue(boolean quitAllowed) { 
        mPtr = nativeInit(); // 
    }

static jlong android_os_MessageQueue_nativeInit(JNIEnv* env, jclass clazz) {
    NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
    // ...
    nativeMessageQueue->incStrong(env);
    return reinterpret_cast<jlong>(nativeMessageQueue);
}

所以理解android_os_MessageQueue_nativePollOnce就很简单了，就是通过mPtr指针重新找到对应的NativeMessageQueue对象，然后执行pollOnce方法，然后回到native的Looper；

void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
    // ...
    mLooper->pollOnce(timeoutMillis); 
}

重点看下 Looper::pollOnce，代码只保留我们所关心的：

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
    int result = 0;
    for (;;) {
        // ...
        if (result != 0) { 
            if (outFd != nullptr) *outFd = 0;
            if (outEvents != nullptr) *outEvents = 0;
            if (outData != nullptr) *outData = nullptr; 
            return result; // 返回状态，代表本次poll结束 
        } 
        // 产生结果状态
        result = pollInner(timeoutMillis);
    }
}

// 上面的 result 有以下几种状态，都由 Looper#pollOnce() 或者 Looper#pollAll() 产生
enum {
    // 说明本次 poll 已经在超时之前被 wake() 唤醒，没有回调被执行且没有其他就绪的 fd 
    POLL_WAKE = -1,
    // 一个或多个回调被执行
    POLL_CALLBACK = -2,
    // 超时了
    POLL_TIMEOUT = -3,
    // 出错了
    POLL_ERROR = -4,
};

通过上面的注释我们知道结果状态由 pollInner 产生，如下，看看注释即可：

Vector<MessageEnvelope> mMessageEnvelopes; // guarded by mLock
int Looper::pollInner(int timeoutMillis) { 
    // ...  
    int result = POLL_WAKE; 
    // ...  
    struct epoll_event eventItems[EPOLL_MAX_EVENTS];
    // (1). 重点在 epoll_wait 这里，这里等待 Kernel IO 事件 
    int eventCount = epoll_wait(mEpollFd.get(), eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
    // ...  
    mLock.lock();
 
    for (int i = 0; i < eventCount; i++) {
        // 如果有epoll消息回调，这里会处理一波
        // ...
    }
    // ... 

    // 这里执行待处理的消息回调，也就是 handleMessage 
    mNextMessageUptime = LLONG_MAX;
    while (mMessageEnvelopes.size() != 0) {
        nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
        const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
        if (messageEnvelope.uptime <= now) { 
            // postDelay/postAtTime 设置消息时间到了，执行回调
            { // obtain handler
                sp<MessageHandler> handler = messageEnvelope.handler;
                Message message = messageEnvelope.message;
                mMessageEnvelopes.removeAt(0);
                mSendingMessage = true;
                mLock.unlock(); 
                handler->handleMessage(message); //（2）.接收到 epoll 事件消息可执行时执行handleMessage
            } // release handler

            mLock.lock();
            mSendingMessage = false;
            result = POLL_CALLBACK;
        } else {
            mNextMessageUptime = messageEnvelope.uptime;
            break;
        }
    }

    mLock.unlock();
    // ...
    return result;
}

OK，通过源码可以看出实际上不管是没消息时执行nativePollOnce，还是postDelay/postAtTime执行定时任务，都会在epoll_wait这里等待epoll事件，然后更新任务状态，执行定时任务的handlerMessage回调；也就是说，之所以不会ANR，其实是因为epoll_wait它本身不会太占CPU（PS：说不占CPU的话感觉不严谨），为啥嘞，我们下面继续聊聊；

关于 Epoll

epoll_wait源自Epoll，而Epoll是Linux中的一套多路复用I/O接口，能提高程序在并发场景下的CPU利用率，它基于事件驱动，因此等待I/O事件的过程中CPU占用会很低；暂且我们知道这个就可以了，如果有小伙伴想对进行深入研究或其源码感兴趣也可以多找点其他资料或pull一份源码康康，这里就不展开了；

这个可能很多人之前压根没听过，包括我自己（捂脸）；我们熟悉wait，因为Object也有wait方法，我们知道当我们执行Object#wait()方法时，当前线程会让出CPU资源，感觉有点像啊对吧，不过两者底层实现方式可是相差甚远，Object#wait() 底层是通过自旋锁来实现的，源码可以查找 ObjectMonitor::wait(jlong millis, bool interruptible, TRAPS) ，直戳这里一键直达

相关博客可看这里：

OK，补充完毕

再来看看插入消息，与取消息类似，线程安全设计，具体看看注释就行。

boolean enqueueMessage(Message msg, long when) {
    // . . . 
    synchronized (this) {
        if (mQuitting) {  // quit()方法调用后，消息循环已经退出
            msg.recycle();
            return false;
        }
        // 标记为正在使用
        msg.markInUse();
        msg.when = when;
        Message p = mMessages;
        boolean needWake;
        if (p == null || when == 0 || when < p.when) {
            // 如果没到执行时间，则直接插在队头
            msg.next = p;
            mMessages = msg;
            needWake = mBlocked;
        } else { // 其他则插入到队尾，比如已经到了执行时间了，那么直接插入到队头，这样就能在下次取消息时执行了
            needWake = mBlocked && p.target == null && msg.isAsynchronous();
            Message prev;
            //  插入消息到队尾
            for (;;) {
                prev = p;
                p = p.next;
                if (p == null || when < p.when) {
                    break;
                }
                if (needWake && p.isAsynchronous()) {
                    needWake = false;
                }
            }
            msg.next = p; // invariant: p == prev.next
            prev.next = msg;
        }
        // ...
    }
    return true;
}

四、ThreadLocal 源码分析

特点： 当多个线程使用同一个ThreadLocal时，它可以独立地记录各个线程的数据。

ThreadLocal#set(...)源码如下，可见每当执行ThreadLocal#set(...)保存线程数据时，会先查看当前线程是否已经绑定了ThreadLocalMap数据集合，如果不存在则创建一个绑定在这个线程。

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}

ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}

void createMap(Thread t, T firstValue) {
    t.threadLocals = new ThreadLocalMap(this, firstValue);
}

再来看看ThreadLocalMap的主要构成，看到这样的构成是不是可以联想到HashTable和HashMap呢？当然，不过不同之处在于，它并没有像HashTable那样采用数组+单向链表的设计，也没有像HashMap那样采用数组+单向链表+红黑树的设计，而仅仅是一个数组，不过原理都是类似的。

也就是说，实际上ThreadLocal本身并不存储数据，而ThreadLocal之所以能够实现单独记录每个使用到它的线程的数据，是因为它为每一个线程都建立了一个独立的ThreadLocalMap数据存储对象，并把这个数据存储对象绑定在对应的线程上，当我们需要设置或者获取某一个线程的数据时，那么只需要从这个线程中取出这个数据存储对象，然后写/读数据即可，你看这是不是既简便又能保证数据的独立性。

static class ThreadLocalMap { 
    // 真正线程存储数据的地方
    static class Entry extends WeakReference<ThreadLocal<?>> {
        /** The value associated with this ThreadLocal. */
        Object value; 
        Entry(ThreadLocal<?> k, Object v) {
            super(k);
            value = v;
        }
    } 
    private Entry[] table;  
    private int size = 0; 
    private int threshold; // Default to 0
    // ...
}

ThreadLocal#get()源码如下:

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t); //1. 取出当前线程所绑定的的ThreadLocalMap
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this); //2. 取出 ThreadLocalMap.Entry
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;   //3. 取出值
            return result;
        }
    }
    return setInitialValue();
}

五、设计思想

至此，我们已经结合源码分析了Handler机制中所有核心类，可能有的童鞋会有所怀疑，Handler机制的核心居然不是Handler？确实不是，Handler只是作为整个框架的入口和最终功能逻辑代码执行地，要说这套框架核心，那非Looper莫属啦。

纵观整个机制的执行过程及协作关系，不难发现它实际是基于生产者-消费者模型的设计：

生产者-消费者.png

为了方便对比，我把前面的Handler机制那张图粘过来这里：

Handler机制.png

然后对号入座一下，不难发现，这里的生产者指的是Thread 2，任务队列就是我们的MessageQueue，而消费者就是Looper也就是Thread 1，然后你会发现，Handler虽然起到承上启下的作用，但是Looper才是整套机制中最为核心的一环。

总结

本文从Handler的基本使用着手，结合源码分析了Handler机制中的几个核心类，并总结和下它的设计思想，水平有限，欢迎指正。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 161,601评论 4赞 369
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 68,367评论 1赞 305
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 111,249评论 0赞 254
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 44,539评论 0赞 217
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,967评论 3赞 295
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,929评论 1赞 224
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 32,098评论 2赞 317
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,825评论 0赞 207
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,609评论 1赞 249
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,796评论 2赞 253
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,282评论 1赞 265
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,603评论 3赞 261
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 33,277评论 3赞 242
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,159评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,959评论 0赞 201
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 36,079评论 2赞 285
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,874评论 2赞 277