LocationManager内存泄露

最近在做一个项目的内存优化时,偶然发现一个以前没有注意到的问题,LocationManager引起内存泄露,于是就想探究下泄露的Root Cause并整理出来,希望其他开发人员使用时也能够注意。

问题

我们先看下面的示例代码(Android 7.0):

// MainActivity.java
@Override
protected void onStart() {
    super.onStart();
    registerNmeaListener();
}

@Override
protected void onStop() {
    super.onStop();
    unregisterNmeaListener();
}

private void registerNmeaListener() {
    if (mOnNmeaMessageListener == null) {
        mOnNmeaMessageListener = new OnNmeaMessageListener() {
            @Override
            public void onNmeaMessage(String message, long timestamp) {

            }
        };
        mLocationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE);
        mLocationManager.addNmeaListener(mOnNmeaMessageListener);
    }
}

private void unregisterNmeaListener() {
    if (mOnNmeaMessageListener != null) {
        mLocationManager.removeNmeaListener(mOnNmeaMessageListener);
        mOnNmeaMessageListener = null;
    }
}

这是一段很常规的Android代码,我们在项目中通常都会这么实现。但如果使用Memory Monitor来查看堆内存,就发现会有内存泄露。

使用Memory Monitor分析步骤如下:

  1. 启动应用,然后按返回键退出应用。
  2. Android MonitorMemory Monitor界面点击Initate GC
  3. 点击Dump Java Heap生成hprof文件。生成完毕Android Studio会自动打开。
  4. 选择Package Tree View视图,并点击Class Name按升序排序,这样可以迅速找到要分析的程序的包名。
  5. 发现MainActivity的实例个数为1,即没有被GC回收,发生内存泄露。

分析

为什么会出现内存泄露?从HPROF ViewerReference Tree来看,
GC Root(Depth为0)是LocationManager的内部类GnssStatusListenerTransport成员mGnssHandlermGnssHandlerGnssStatusListenerTransport的内部类GnssHandler的实例,所以mGnssHandler隐式持有外部类GnssStatusListenerTransport实例的引用,而GnssStatusListenerTransport的成员mGnssNmeaListener又指向了MainActivityOnNmeaMessageListener匿名内部类实例,从而导致MainActivity泄露。简单概括就是:mGnssHandler->GnssStatusListenerTransport->mGnssNmeaListener->MainActivity

我们可以来看一下LocationManager的源码,位于$SOURCEROOT/frameworks/base/location/java/android/location/LocationManager.java:

private final HashMap<OnNmeaMessageListener, GnssStatusListenerTransport> mGnssNmeaListeners =
            new HashMap<>();

/**
 * Adds an NMEA listener.
 *
 * @param listener a {@link OnNmeaMessageListener} object to register
 *
 * @return true if the listener was successfully added
 *
 * @throws SecurityException if the ACCESS_FINE_LOCATION permission is not present
 */
@RequiresPermission(ACCESS_FINE_LOCATION)
public boolean addNmeaListener(OnNmeaMessageListener listener) {
    return addNmeaListener(listener, null);
}

/**
 * Adds an NMEA listener.
 *
 * @param listener a {@link OnNmeaMessageListener} object to register
 * @param handler the handler that the listener runs on.
 *
 * @return true if the listener was successfully added
 *
 * @throws SecurityException if the ACCESS_FINE_LOCATION permission is not present
 */
@RequiresPermission(ACCESS_FINE_LOCATION)
public boolean addNmeaListener(OnNmeaMessageListener listener, Handler handler) {
    boolean result;

    if (mGpsNmeaListeners.get(listener) != null) {
        // listener is already registered
        return true;
    }
    try {
        GnssStatusListenerTransport transport =
                new GnssStatusListenerTransport(listener, handler);
        result = mService.registerGnssStatusCallback(transport, mContext.getPackageName());
        if (result) {
            mGnssNmeaListeners.put(listener, transport);
        }
    } catch (RemoteException e) {
        throw e.rethrowFromSystemServer();
    }

    return result;
}

/**
 * Removes an NMEA listener.
 *
 * @param listener a {@link OnNmeaMessageListener} object to remove
 */
public void removeNmeaListener(OnNmeaMessageListener listener) {
    try {
        GnssStatusListenerTransport transport = mGnssNmeaListeners.remove(listener);
        if (transport != null) {
            mService.unregisterGnssStatusCallback(transport);
        }
    } catch (RemoteException e) {
        throw e.rethrowFromSystemServer();
    }
}

添加listener的时候会先判断下是否已经添加过,如果添加过了,就直接返回,如果没有,则使用传入的OnNmeaMessageListener对象和Handler对象构造一个对应的GnssStatusListenerTransport对象,并将其注册到LocationManagerService端,同时记录在本地mGnssNmeaListeners表示的HashMap中。

移除listener时,先将listener从本地HashMap中移除,同时将其从LocationManagerService注销掉。

注册到LocationManagerService和从LocationManagerService注销的过程与我们这里分析的问题关联不大,所以就不分析了。我们主要来看GnssStatusListenerTransport类。Android 7.0对LocationManager做了较大改动,主要是增加了对GPS以外的其他卫星定位系统的支持,统称为GNSS(Global Navigation Satellite System)。这里为了流程清晰,我们把7.0兼容之前老版本的代码删除了。

// This class is used to send Gnss status events to the client's specific thread.
private class GnssStatusListenerTransport extends IGnssStatusListener.Stub {

    private final GnssStatus.Callback mGnssCallback;
    private final OnNmeaMessageListener mGnssNmeaListener;

    private class GnssHandler extends Handler {
        public GnssHandler(Handler handler) {
            super(handler != null ? handler.getLooper() : Looper.myLooper());
        }

        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
                case NMEA_RECEIVED:
                    synchronized (mNmeaBuffer) {
                        int length = mNmeaBuffer.size();
                        for (int i = 0; i < length; i++) {
                            Nmea nmea = mNmeaBuffer.get(i);
                            mGnssNmeaListener.onNmeaMessage(nmea.mNmea, nmea.mTimestamp);
                        }
                        mNmeaBuffer.clear();
                    }
                    break;
                case GpsStatus.GPS_EVENT_STARTED:
                    mGnssCallback.onStarted();
                    break;
                case GpsStatus.GPS_EVENT_STOPPED:
                    mGnssCallback.onStopped();
                    break;
                case GpsStatus.GPS_EVENT_FIRST_FIX:
                    mGnssCallback.onFirstFix(mTimeToFirstFix);
                    break;
                case GpsStatus.GPS_EVENT_SATELLITE_STATUS:
                    mGnssCallback.onSatelliteStatusChanged(mGnssStatus);
                    break;
                default:
                    break;
            }
        }
    }

    private final Handler mGnssHandler;

    // This must not equal any of the GpsStatus event IDs
    private static final int NMEA_RECEIVED = 1000;

    private class Nmea {
        long mTimestamp;
        String mNmea;

        Nmea(long timestamp, String nmea) {
            mTimestamp = timestamp;
            mNmea = nmea;
        }
    }
    private final ArrayList<Nmea> mNmeaBuffer;

    GnssStatusListenerTransport(GnssStatus.Callback callback) {
        this(callback, null);
    }

    GnssStatusListenerTransport(GnssStatus.Callback callback, Handler handler) {
        mOldGnssCallback = null;
        mGnssCallback = callback;
        mGnssHandler = new GnssHandler(handler);
        mOldGnssNmeaListener = null;
        mGnssNmeaListener = null;
        mNmeaBuffer = null;
        mGpsListener = null;
        mGpsNmeaListener = null;
    }


    GnssStatusListenerTransport(OnNmeaMessageListener listener) {
        this(listener, null);
    }

    GnssStatusListenerTransport(OnNmeaMessageListener listener, Handler handler) {
        mOldGnssCallback = null;
        mGnssCallback = null;
        mGnssHandler = new GnssHandler(handler);
        mOldGnssNmeaListener = null;
        mGnssNmeaListener = listener;
        mGpsListener = null;
        mGpsNmeaListener = null;
        mNmeaBuffer = new ArrayList<Nmea>();
    }

    @Override
    public void onGnssStarted() {
        if (mGpsListener != null) {
            Message msg = Message.obtain();
            msg.what = GpsStatus.GPS_EVENT_STARTED;
            mGnssHandler.sendMessage(msg);
        }
    }

    @Override
    public void onGnssStopped() {
        if (mGpsListener != null) {
            Message msg = Message.obtain();
            msg.what = GpsStatus.GPS_EVENT_STOPPED;
            mGnssHandler.sendMessage(msg);
        }
    }

    @Override
    public void onFirstFix(int ttff) {
        if (mGpsListener != null) {
            mTimeToFirstFix = ttff;
            Message msg = Message.obtain();
            msg.what = GpsStatus.GPS_EVENT_FIRST_FIX;
            mGnssHandler.sendMessage(msg);
        }
    }

    @Override
    public void onSvStatusChanged(int svCount, int[] prnWithFlags,
            float[] cn0s, float[] elevations, float[] azimuths) {
        if (mGnssCallback != null) {
            mGnssStatus = new GnssStatus(svCount, prnWithFlags, cn0s, elevations, azimuths);

            Message msg = Message.obtain();
            msg.what = GpsStatus.GPS_EVENT_SATELLITE_STATUS;
            // remove any SV status messages already in the queue
            mGnssHandler.removeMessages(GpsStatus.GPS_EVENT_SATELLITE_STATUS);
            mGnssHandler.sendMessage(msg);
        }
    }

    @Override
    public void onNmeaReceived(long timestamp, String nmea) {
        if (mGnssNmeaListener != null) {
            synchronized (mNmeaBuffer) {
                mNmeaBuffer.add(new Nmea(timestamp, nmea));
            }
            Message msg = Message.obtain();
            msg.what = NMEA_RECEIVED;
            // remove any NMEA_RECEIVED messages already in the queue
            mGnssHandler.removeMessages(NMEA_RECEIVED);
            mGnssHandler.sendMessage(msg);
        }
    }
}

GnssStatusListenerTransport继承自IGnssStatusListener.Stub,熟悉Binder机制的同学都知道,Stub类展开之后的形式是Stub extends Binder(implements IBinder) implements IGnssStatusListener(implements IInterface),它是Binder通信的本地对象,将一个Binder本地对象传给另一个进程,另一个进程会拿到一个Binder通信的Proxy对象,这样另一个进程就可以通过Proxy对象调用本地对象的方法了,而LocationManager中又持有LocationManagerServiceProxy对象,这样LocationManagerLocationManagerService就可以双向通信。

这里IGnssStatusListener主要提供了5个方法供LocationManagerService回调以便通知相应的GNSS事件,其源码位于$SOURCEROOT/frameworks/base/location/java/android/location/IGnssStatusListener.aidl:

/*
 * Copyright (C) 2008, The Android Open Source Project
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package android.location;

import android.location.Location;

/**
 * {@hide}
 */
oneway interface IGnssStatusListener
{
    void onGnssStarted();
    void onGnssStopped();
    void onFirstFix(int ttff);
    void onSvStatusChanged(int svCount, in int[] svidWithFlags, in float[] cn0s,
            in float[] elevations, in float[] azimuths);
    void onNmeaReceived(long timestamp, String nmea);
}

可以看到在GnssStatusListenerTransportIGnssStatusListener的接口实现里,主要是将LocationManagerService回传的事件通过mGnssHandler进行异步转发。mGnssHandlerGnssStatusListenerTransport的内部类GnssHandler的实例,它在GnssStatusListenerTransport的构造函数中被创建。这里我们注意到,mGnssHandler的构造与外部传入的Handler对象有关。如果外部传入了Handler对象,则mGnssHandler绑定到外部传入的Handler对象所绑定的消息队列,如果外部传入的Handler对象为null,则mGnssHandler绑定到调用addNmeaListener方法所在的线程的消息队列。接下来,我们看GnssHandlerhandleMessage实现,这里的实现比较简单,就直接将事件通知给对应的listener。

看到这里,估计大家也发现了,这里的mGnssHandler可能会引发内存泄露,因为在调用LocationManager.removeNmeaListener时并没有任何清除与mGnssHandler关联的Message的操作。Handler可能引起内存泄露请参考http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html

对应到我们当前的场景,发生泄露的一个可能情况是LocationManagerService不断给GnssStatusListenerTransport对象发送信息,这些信息被mGnssHandler封装成Message投递到mGnssHandler绑定的消息队列里,这里就是主线程消息队列,当我们在主线程调用LocationManager.removeNmeaListener方法时,mGnssHandler可能已经往主线程的消息队列里投递了N多个消息。也就是说在主线程的消息队列里面,Activity.onDestroy的消息后面有很多mGnssHandler投递的消息。这些mGnssHandler投递的位于Activity.onDestroy之后的消息如果在Activity退出时没有被清除的话,就会发生Activity退出了,但是引用链Message->mGnssHandler->GnssStatusListenerTransport->mGnssNmeaListener->MainActivity还在,导致MainActivity泄露。

思考

分析到这里就完了吗?显然不是。我们可以进一步思考:

  1. mGnssHandler投递的那些可能造成内存泄露的Message也没有使用delay的方式投递,也就是说,Activity退出过不了多久,这些Message就会被处理完,即 内存泄露一段时间后就会恢复正常,MainActivity又可以给被回收了。但事实确实如此吗?通过测试我们可以发现,即使过了很长时间,MainActivity依然回收不了。

  2. Memory Monitor显示GC Root是mGnssHandler,所以很可能不是Message->mGnssHandler导致泄露。Android中的GC Root主要包括如下几类,可以参考mGssHandler属于哪一类?如果有人知道,也请告诉我一下(参考2017/07/02更新)。

  • references on the stack
  • Java Native Interface (JNI) native objects and memory
  • static variables and functions
  • threads and objects that can be referenced
  • classes loaded by the bootstrap loader
  • finalizers and unfinalized objects
  • busy monitor objects
  1. Handler内存泄露的问题早在2009年就被提出来了,为什么现在Android发展到了7.0,还会出现这种问题。我们查看Android源代码中LocationManager的提交历史,发现GnssHandler的机制(或者类似机制)在LocationManager内部已历经几个Android版本,难道就一直没人发现这个问题吗?我们在Google Issue Tracker中搜索LocationManager leak,发现确实有一些相关的issue,但这些issue不知道为何最后要么不了了之,要么被Google没有任何解释就直接关闭了。
  2. 我们在Android的源码里搜索Handler,看Android内置程序如何使用Handler时会发现,在Android源码内部有些地方处理了泄露,如TV内部使用WeakHandler,有些地方没有处理泄露,即在Android源码内部对Handler的处理并未统一。
  3. 另外我们在StackOverflow上发现这篇帖子,于是尝试将程序改为:
// MainActivity
@Override
  protected void onResume() {
      super.onResume();
      registerNmeaListener();
  }

  @Override
  protected void onPause() {
      super.onPause();
      unregisterNmeaListener();
  }

竟然意外的发现内存泄露消失了。但是我们知道按返回建退出应用时,onPauseonStoponDestroy是在同一个Message里处理的。具体可以参见ActivityThread.performDestroyActivity,源码位于$SOURCEROOT/frameworks/base/core/java/android/app/ActivityThread.java:

private ActivityClientRecord performDestroyActivity(IBinder token, boolean finishing,
        int configChanges, boolean getNonConfigInstance) {
    ActivityClientRecord r = mActivities.get(token);
    Class<? extends Activity> activityClass = null;
    if (localLOGV) Slog.v(TAG, "Performing finish of " + r);
    if (r != null) {
        activityClass = r.activity.getClass();
        r.activity.mConfigChangeFlags |= configChanges;
        if (finishing) {
            r.activity.mFinished = true;
        }

        performPauseActivityIfNeeded(r, "destroy");

        if (!r.stopped) {
            try {
                r.activity.performStop(r.mPreserveWindow);
            } catch (SuperNotCalledException e) {
                throw e;
            } catch (Exception e) {
                if (!mInstrumentation.onException(r.activity, e)) {
                    throw new RuntimeException(
                            "Unable to stop activity "
                            + safeToComponentShortString(r.intent)
                            + ": " + e.toString(), e);
                }
            }
            r.stopped = true;
            EventLog.writeEvent(LOG_AM_ON_STOP_CALLED, UserHandle.myUserId(),
                    r.activity.getComponentName().getClassName(), "destroy");
        }
        if (getNonConfigInstance) {
            try {
                r.lastNonConfigurationInstances
                        = r.activity.retainNonConfigurationInstances();
            } catch (Exception e) {
                if (!mInstrumentation.onException(r.activity, e)) {
                    throw new RuntimeException(
                            "Unable to retain activity "
                            + r.intent.getComponent().toShortString()
                            + ": " + e.toString(), e);
                }
            }
        }
        try {
            r.activity.mCalled = false;
            mInstrumentation.callActivityOnDestroy(r.activity);
            if (!r.activity.mCalled) {
                throw new SuperNotCalledException(
                    "Activity " + safeToComponentShortString(r.intent) +
                    " did not call through to super.onDestroy()");
            }
            if (r.window != null) {
                r.window.closeAllPanels();
            }
        } catch (SuperNotCalledException e) {
            throw e;
        } catch (Exception e) {
            if (!mInstrumentation.onException(r.activity, e)) {
                throw new RuntimeException(
                        "Unable to destroy activity " + safeToComponentShortString(r.intent)
                        + ": " + e.toString(), e);
            }
        }
    }
    mActivities.remove(token);
    StrictMode.decrementExpectedActivityCount(activityClass);
    return r;
}

既然是在同一个Message里处理,那为何在onPause中移除listener不会造成泄露,而在onStop中移除listener就会造成内存泄露?

解决

虽然现在我们还有很多暂时无法解答的问题,但对出现的问题我们还是有要解决方案。

onPause移除listener

从之前分析来看,如果业务满足在onPause中移除listener的情况则可以使用此方法完美解决。若业务不满足在onPause中移除listener的情况(因为进入onPause时Activity可能没有被完全遮挡,所以底层视图还是需要更新,因此对于这种情况,我们不能移除listener),我们只能采用work around的方式。

反射

可以通过反射拿到mGnssHandler的引用,然后移除所有相关的消息,并将GnssStatusListenerTransport内部mGnssNmeaListener的引用置null

使用SoftReferenceApplication Context

我们可以实现一个足够小的静态的OnNmeaMessageListener内部类并持有外部MainActivity的软引用,然后将OnNmeaMessageListener接收到的所有事件转发给外部的MainActivity来处理,以保持内部类足够小。

使用SoftReference的方式很好理解,但为什么要同时使用Application Context呢?这是因为GnssStatusListenerTransport无法被回收会导致LocationManager无法回收,而LocationManager持有调用getSystemService的调用者的Context。在我们这个场景中就是MainActivity,因此还是会导致MainActivity泄露。使用Application Context使得整个应用只会构造一个LocationManager,这点可以从SystemServiceRegistry源码来看,源码位于$SOURCEROOT/frameworks/base/core/java/android/app/SystemServiceRegistry.java:

registerService(Context.LOCATION_SERVICE, LocationManager.class,
        new CachedServiceFetcher<LocationManager>() {
    @Override
    public LocationManager createService(ContextImpl ctx) {
        IBinder b = ServiceManager.getService(Context.LOCATION_SERVICE);
        return new LocationManager(ctx, ILocationManager.Stub.asInterface(b));
    }});

我们知道Context采用了设计模式里的装饰模式,ContextImplContextWrapper(Activity和Application的父类)真正做事情的类,同时ContextImpl内部持有Out Context,即ContextWrapper的引用。从SystemServiceRegistry可以看出,LocationManager与ContextWrapper是一一对应的关系,即使用LocationManager的每一个Activity都会创建一个LocationManager的实例。在我们这个场景中LocationManager持有ContextImpl的引用,ContextImpl持有Out Context,即MainActivityApplication的引用,从而导致MainActivity泄露,而统一使用Application Context则不会有这个问题。

好了,到此我们整个LocationManager泄露的问题就说完了。对于前面还无法的解答的问题,我会继续分析。如果有人知道答案,也请告诉我一声。

Updated 2017/07/02

当我们使用上述反射机制解决了MainActivity的内存泄露时,android.location包的内存泄露还是存在的。此时我们通过Memory Monitor来进一步分析android.location包的堆内存情况,如下图:


GC Root是GnssStatusListenerTransport,并且除了FinalizerReference,没有其他引用指向它。FinalizerReference是Android framework的一个隐藏类,主要用来实现Java的finalize机制。所有重写finalize()方法的类对象,最后都会被FinalizerReference类的静态变量引用,所以当它们没有强引用时不会被虚拟机立即回收,而是GC会将这些重写了finalize()方法的对象压入到ReferenceQueue中。同时会有一个守护线程Finalize Daemon来真正处理调用他们的finalize函数,实现垃圾回收。所以重写了finalize()方法的类对象需要至少经过两轮GC才有可能被释放,具体释放时机不确定。这与我们前面介绍Android GC Root有一类是finalizers and unfinalized objects不谋而合。

但是我们在GnssStatusListenerTransport并没有发现finalize()被重写,这到底是怎么回事呢?相信大家一定也猜到了:在父类里重写了。我们依次查看GnssStatusListenerTransport的父类,发现Binder类重写了finalize()方法:

protected void finalize() throws Throwable {
    try {
        destroy();
    } finally {
        super.finalize();
    }
}

到此,我们终于找到了LocationManager泄露的Root Cause。Android系统要解决这个问题,可以在GnssStatusListenerTransport类中添加一个cleanup的方法来清除所有的外部引用,然后在移除listener之后调用一下cleanup方法即可。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,772评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,458评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,610评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,640评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,657评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,590评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,962评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,631评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,870评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,611评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,704评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,386评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,969评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,944评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,179评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,742评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,440评论 2 342

推荐阅读更多精彩内容