Universal-Image-Loader解析（三）源代码解析

Universal-Image-Loader解析系列

Universal-Image-Loader解析（一）基本介绍与使用
Universal-Image-Loader解析（二）内部缓存原理
Universal-Image-Loader解析（三）源代码解析

前两篇文章主要跟大家介绍了UIL的基本使用以及它的缓存设计，本篇文章主要讲解它的源代码

当我们配置好ImageConfiguration和ImageLoader后，我们就会开始调用

ImageLoader.getInstance().loadImage(...);   
ImageLoader.getInstance().displayImage(...);

这两个方法其中一个来显示图片。
先看loadImage

public void loadImage(String uri, ImageSize targetImageSize, DisplayImageOptions options,
            ImageLoadingListener listener, ImageLoadingProgressListener progressListener) {
        checkConfiguration();
        if (targetImageSize == null) {
            targetImageSize = configuration.getMaxImageSize();
        }
        if (options == null) {
            options = configuration.defaultDisplayImageOptions;
        }

        NonViewAware imageAware = new NonViewAware(uri, targetImageSize, ViewScaleType.CROP);
        displayImage(uri, imageAware, options, listener, progressListener);
    }

首先调用了checkConfiguration用来判断是否有初始化ImageLoaderConfiguration
如果有设置ImageView的大小，则设置，没则默认Configuration的大小。
如果没有设置DisplayImageOptions，则设置上一个默认的options
之后创建了个NonViewAware，再调用displayImage。
也就是说，loadImage最终还是调用到了displayImage。

ImageAware

这里的NonViewAware实现了ImageAware接口。先来看个结构图

ImageAware

ImageAware是一个接口，内部提供了一系列操作图片的一些方法。
对于NonViewAware来说，它内部只是简单的保存图片一些必要的数据，比如图片大小尺寸，URI，ScaleType这些。主要封装成ImageAware来给displayImage调用。

看下displayImage的使用

public void displayImage(String uri, ImageView imageView) {
        displayImage(uri, new ImageViewAware(imageView), null, null, null);
    }

这里把ImageView封装成ImageViewAware再去调用displayImage这个就跟loadImage一样。
而这里ImageViewAware继承与ViewAware,ViewAware则实现了ImageAware接口。
与NonViewAware不同的是ViewAware内部持有一个Reference<View> viewRef的成员变量，它是用来保存当前ImageView的一个弱引用，以便之后来直接设置显示图片。
ViewAware很多方法都是依赖于这个View

@Override
    public boolean setImageDrawable(Drawable drawable) {
        if (Looper.myLooper() == Looper.getMainLooper()) {
            View view = viewRef.get();
            if (view != null) {
                setImageDrawableInto(drawable, view);
                return true;
            }
        } else {
            L.w(WARN_CANT_SET_DRAWABLE);
        }
        return false;
    }

之后就可以在ImageViewAware中设置显示。

好了回过头看他们最终调用的方法。
这个方法有点长，我们拆分成一部分一部分来看

public void displayImage(String uri, ImageAware imageAware, DisplayImageOptions options,
            ImageSize targetSize, ImageLoadingListener listener, ImageLoadingProgressListener progressListener) {
        checkConfiguration();
        if (imageAware == null) {
            throw new IllegalArgumentException(ERROR_WRONG_ARGUMENTS);
        }
        if (listener == null) {
            listener = defaultListener;
        }
        if (options == null) {
            options = configuration.defaultDisplayImageOptions;
        }

        if (TextUtils.isEmpty(uri)) {
            engine.cancelDisplayTaskFor(imageAware);
            listener.onLoadingStarted(uri, imageAware.getWrappedView());
            if (options.shouldShowImageForEmptyUri()) {
                imageAware.setImageDrawable(options.getImageForEmptyUri(configuration.resources));
            } else {
                imageAware.setImageDrawable(null);
            }
            listener.onLoadingComplete(uri, imageAware.getWrappedView(), null);
            return;
        }
        ...//下一部分看
    }

首先先检查是否有初始化设置ImageLoaderConfiguration没则抛出异常，没设置listener和DisplayImageOptions则设置一个默认值。

之后调用TextUtils.isEmpty(uri)判断是否当前的uri为空，则调用
engine.cancelDisplayTaskFor(imageAware);
之后则用listener通知开始和结束，也比较好理解，主要是这个engine。

这个engine就是ImageLoaderEngine，主要用来负责显示加载图片的一个类。
ImageLoaderEngine中存在一个HashMap,用来记录正在加载的任务，加载图片的时候会将ImageView的id和图片的url加上尺寸加入到HashMap中，加载完成之后会将其移除。

接着看下面

public void displayImage(String uri, ImageAware imageAware, DisplayImageOptions options,
            ImageSize targetSize, ImageLoadingListener listener, ImageLoadingProgressListener progressListener) {
        ...//前一部分
        if (targetSize == null) {
            targetSize = ImageSizeUtils.defineTargetSizeForView(imageAware, configuration.getMaxImageSize());
        }
        String memoryCacheKey = MemoryCacheUtils.generateKey(uri, targetSize);
        engine.prepareDisplayTaskFor(imageAware, memoryCacheKey);

        listener.onLoadingStarted(uri, imageAware.getWrappedView());

        Bitmap bmp = configuration.memoryCache.get(memoryCacheKey);
        if (bmp != null && !bmp.isRecycled()) {
            L.d(LOG_LOAD_IMAGE_FROM_MEMORY_CACHE, memoryCacheKey);

            if (options.shouldPostProcess()) {
                ImageLoadingInfo imageLoadingInfo = new ImageLoadingInfo(uri, imageAware, targetSize, memoryCacheKey,
                        options, listener, progressListener, engine.getLockForUri(uri));
                ProcessAndDisplayImageTask displayTask = new ProcessAndDisplayImageTask(engine, bmp, imageLoadingInfo,
                        defineHandler(options));
                if (options.isSyncLoading()) {
                    displayTask.run();
                } else {
                    engine.submit(displayTask);
                }
            } else {
                options.getDisplayer().display(bmp, imageAware, LoadedFrom.MEMORY_CACHE);
                listener.onLoadingComplete(uri, imageAware.getWrappedView(), bmp);
            }
        } 
        ...//下一部分
    }

当URI不为空的时候来加载显示。首先根据uri获取对应uri对应唯一的一个Key，之后调用engine.prepareDisplayTaskFor(imageAware, memoryCacheKey);来记录当前加载的任务，开启listener的start回调，接着调用Bitmap bmp = configuration.memoryCache.get(memoryCacheKey);来获取内存缓存中的图片，这里默认的内存缓存是LruMemoryCache，前篇文章有分析到。

如果缓存中存在相应的Bitmap的话，进入到if里面
我们如果在DisplayImageOptions中设置了postProcessor就进入true逻辑，不过默认postProcessor是为null的，BitmapProcessor接口主要是对Bitmap进行处理，这个框架并没有给出相对应的实现，如果我们有自己的需求的时候可以自己实现BitmapProcessor接口（比如将图片设置成圆形的）.

然后到了27行
将Bitmap设置到ImageView上面，这里我们可以在DisplayImageOptions中配置显示需求displayer，默认使用的是SimpleBitmapDisplayer，直接将Bitmap设置到ImageView上面，我们可以配置其他的显示逻辑， 他这里提供了FadeInBitmapDisplayer（透明度从0-1）RoundedBitmapDisplayer（4个角是圆弧）等， 然后回调到ImageLoadingListener接口。

我们知道loadImage和displayImage的区别在于loadImage依靠返回的Bitmap进行设置显示，而displayImage则是直接显示。而loadImage最终也是调用了displayImage，原因就在于这个display和imageAware

public final class SimpleBitmapDisplayer implements BitmapDisplayer {
    @Override
    public void display(Bitmap bitmap, ImageAware imageAware, LoadedFrom loadedFrom) {
        imageAware.setImageBitmap(bitmap);
    }
}

loadImage的ImageAware是NonImageAware并没有处理setImageBitmap的方法，而displayImage的ImageViewAware则有处理显示。

好，继续前面，当从内存缓存获取到的Bitmap为空的情况下

public void displayImage(String uri, ImageAware imageAware, DisplayImageOptions options,
            ImageSize targetSize, ImageLoadingListener listener, ImageLoadingProgressListener progressListener) {
            ...//前两部分
        //如果Bitmap为空
        } else {
            if (options.shouldShowImageOnLoading()) {
                imageAware.setImageDrawable(options.getImageOnLoading(configuration.resources));
            } else if (options.isResetViewBeforeLoading()) {
                imageAware.setImageDrawable(null);
            }

            ImageLoadingInfo imageLoadingInfo = new ImageLoadingInfo(uri, imageAware, targetSize, memoryCacheKey,
                    options, listener, progressListener, engine.getLockForUri(uri));
            LoadAndDisplayImageTask displayTask = new LoadAndDisplayImageTask(engine, imageLoadingInfo,
                    defineHandler(options));
            if (options.isSyncLoading()) {
                displayTask.run();
            } else {
                engine.submit(displayTask);
            }
        }
    }

如果需要设置显示加载中的图片，则进行设置显示。
ImageLoadingInfo则是一个加载显示图片任务信息的一个类。
之后根据它创建了一个LoadAndDisplayImageTask类，它实现了Runnable。
如果配置了isSyncLoading为true, 直接执行LoadAndDisplayImageTask的run方法，表示同步，默认是false,将LoadAndDisplayImageTask提交给线程池对象

接下来我们就看LoadAndDisplayImageTask的run(), 这个类还是蛮复杂的，我们还是一段一段的分析。

@Override
    public void run() {
        if (waitIfPaused()) return;
        if (delayIfNeed()) return;

        ...
    }

如果waitIfPaused(), delayIfNeed()返回true的话，直接从run()方法中返回了，不执行下面的逻辑, 接下来我们先看看waitIfPaused（）

private boolean waitIfPaused() {
        AtomicBoolean pause = engine.getPause();
        if (pause.get()) {
            synchronized (engine.getPauseLock()) {
                if (pause.get()) {
                    L.d(LOG_WAITING_FOR_RESUME, memoryCacheKey);
                    try {
                        engine.getPauseLock().wait();
                    } catch (InterruptedException e) {
                        L.e(LOG_TASK_INTERRUPTED, memoryCacheKey);
                        return true;
                    }
                    L.d(LOG_RESUME_AFTER_PAUSE, memoryCacheKey);
                }
            }
        }
        return isTaskNotActual();
    }

这个方法是干嘛用呢，主要是我们在使用ListView，GridView去加载图片的时候，有时候为了滑动更加的流畅，我们会选择手指在滑动或者猛地一滑动的时候不去加载图片，所以才提出了这么一个方法，那么要怎么用呢？ 这里用到了PauseOnScrollListener这个类，使用很简单ListView.setOnScrollListener(new PauseOnScrollListener(pauseOnScroll, pauseOnFling ))， pauseOnScroll控制我们缓慢滑动ListView，GridView是否停止加载图片，pauseOnFling 控制猛的滑动ListView，GridView是否停止加载图片。

我们可以看下这个PauseOnScrollListener的处理

@Override
    public void onScrollStateChanged(AbsListView view, int scrollState) {
        switch (scrollState) {
            case OnScrollListener.SCROLL_STATE_IDLE:
                imageLoader.resume();
                break;
            case OnScrollListener.SCROLL_STATE_TOUCH_SCROLL:
                if (pauseOnScroll) {
                    imageLoader.pause();
                }
                break;
            case OnScrollListener.SCROLL_STATE_FLING:
                if (pauseOnFling) {
                    imageLoader.pause();
                }
                break;
        }
        if (externalListener != null) {
            externalListener.onScrollStateChanged(view, scrollState);
        }
    }

滑动停止的话会调用到imageLoader.pause

public void pause() {
        engine.pause();
    }
...
void pause() {
        paused.set(true);
    }
这里的pause是
private final AtomicBoolean paused = new AtomicBoolean(false);

所以调用pause.get则会返回true。

除此之外，这个方法的返回值由isTaskNotActual()决定，我们接着看看isTaskNotActual()的源码

private boolean isTaskNotActual() {
        return isViewCollected() || isViewReused();
    }

isViewCollected()是判断我们ImageView是否被垃圾回收器回收了，如果回收了，LoadAndDisplayImageTask方法的run()就直接返回了，isViewReused()判断该ImageView是否被重用，被重用run()方法也直接返回，为什么要用isViewReused()方法呢？主要是ListView，GridView我们会复用item对象，假如我们先去加载ListView，GridView第一页的图片的时候，第一页图片还没有全部加载完我们就快速的滚动，isViewReused()方法就会避免这些不可见的item去加载图片，而直接加载当前界面的图片。

回头继续看run方法

@Override
    public void run() {
        ...
        ReentrantLock loadFromUriLock = imageLoadingInfo.loadFromUriLock;
        L.d(LOG_START_DISPLAY_IMAGE_TASK, memoryCacheKey);
        if (loadFromUriLock.isLocked()) {
            L.d(LOG_WAITING_FOR_IMAGE_LOADED, memoryCacheKey);
        }

        loadFromUriLock.lock();
        Bitmap bmp;
        try {
            checkTaskNotActual();

            bmp = configuration.memoryCache.get(memoryCacheKey);
            if (bmp == null || bmp.isRecycled()) {
                bmp = tryLoadBitmap();
                if (bmp == null) return; // listener callback already was fired

                checkTaskNotActual();
                checkTaskInterrupted();

                if (options.shouldPreProcess()) {
                    L.d(LOG_PREPROCESS_IMAGE, memoryCacheKey);
                    bmp = options.getPreProcessor().process(bmp);
                    if (bmp == null) {
                        L.e(ERROR_PRE_PROCESSOR_NULL, memoryCacheKey);
                    }
                }

                if (bmp != null && options.isCacheInMemory()) {
                    L.d(LOG_CACHE_IMAGE_IN_MEMORY, memoryCacheKey);
                    configuration.memoryCache.put(memoryCacheKey, bmp);
                }
            } else {
                loadedFrom = LoadedFrom.MEMORY_CACHE;
                L.d(LOG_GET_IMAGE_FROM_MEMORY_CACHE_AFTER_WAITING, memoryCacheKey);
            }

            if (bmp != null && options.shouldPostProcess()) {
                L.d(LOG_POSTPROCESS_IMAGE, memoryCacheKey);
                bmp = options.getPostProcessor().process(bmp);
                if (bmp == null) {
                    L.e(ERROR_POST_PROCESSOR_NULL, memoryCacheKey);
                }
            }
            checkTaskNotActual();
            checkTaskInterrupted();
        } catch (TaskCancelledException e) {
            fireCancelEvent();
            return;
        } finally {
            loadFromUriLock.unlock();
        }

        DisplayBitmapTask displayBitmapTask = new DisplayBitmapTask(bmp, imageLoadingInfo, engine, loadedFrom);
        runTask(displayBitmapTask, syncLoading, handler, engine);
    }

第4行代码有一个loadFromUriLock，这个是一个锁，获取锁的方法在ImageLoaderEngine类的getLockForUri()方法中

ReentrantLock getLockForUri(String uri) {  
        ReentrantLock lock = uriLocks.get(uri);  
        if (lock == null) {  
            lock = new ReentrantLock();  
            uriLocks.put(uri, lock);  
        }  
        return lock;  
    }

从上面可以看出，这个锁对象与图片的url是相互对应的，为什么要这么做？也行你还有点不理解，不知道大家有没有考虑过一个场景，假如在一个ListView中，某个item正在获取图片的过程中，而此时我们将这个item滚出界面之后又将其滚进来，滚进来之后如果没有加锁，该item又会去加载一次图片，假设在很短的时间内滚动很频繁，那么就会出现多次去网络上面请求图片，所以这里根据图片的Url去对应一个ReentrantLock对象，让具有相同Url的请求就会在第10行等待，等到这次图片加载完成之后，ReentrantLock就被释放，刚刚那些相同Url的请求就会继续执行第10行下面的代码。

之后来到第13行，先调用checkTaskNotActual判断当前View是否被GC回收使用，是则抛出异常。
接着15行，它们会先从内存缓存中获取一遍，如果内存缓存中没有在去执行下面的逻辑，所以ReentrantLock的作用就是避免这种情况下重复的去从网络上面请求图片。

17行的方法tryLoadBitmap(),这个方法确实也有点长，我先告诉大家，这里面的逻辑是先从文件缓存中获取有没有Bitmap对象，如果没有在去从网络中获取，然后将bitmap保存在文件系统中，我们还是具体分析下

private Bitmap tryLoadBitmap() throws TaskCancelledException {
        Bitmap bitmap = null;
        try {
            File imageFile = configuration.diskCache.get(uri);
            if (imageFile != null && imageFile.exists() && imageFile.length() > 0) {
                L.d(LOG_LOAD_IMAGE_FROM_DISK_CACHE, memoryCacheKey);
                loadedFrom = LoadedFrom.DISC_CACHE;

                checkTaskNotActual();
                bitmap = decodeImage(Scheme.FILE.wrap(imageFile.getAbsolutePath()));
            }
            if (bitmap == null || bitmap.getWidth() <= 0 || bitmap.getHeight() <= 0) {
                L.d(LOG_LOAD_IMAGE_FROM_NETWORK, memoryCacheKey);
                loadedFrom = LoadedFrom.NETWORK;

                String imageUriForDecoding = uri;
                if (options.isCacheOnDisk() && tryCacheImageOnDisk()) {
                    imageFile = configuration.diskCache.get(uri);
                    if (imageFile != null) {
                        imageUriForDecoding = Scheme.FILE.wrap(imageFile.getAbsolutePath());
                    }
                }

                checkTaskNotActual();
                bitmap = decodeImage(imageUriForDecoding);

                if (bitmap == null || bitmap.getWidth() <= 0 || bitmap.getHeight() <= 0) {
                    fireFailEvent(FailType.DECODING_ERROR, null);
                }
            }
        }
        ...
        return bitmap;
    }

首先在第4行会去磁盘缓存中去获取图片，如果图片已经保存在磁盘了，则直接获取对应的File路径，调用bitmap = decodeImage(Scheme.FILE.wrap(imageFile.getAbsolutePath()));进行解析。

如果在磁盘中没有的话，则到了12行，开始进行网络下载获取。
在17行会去调用isCacheOnDisk判断是否要保持在磁盘中，如果默认false，如果是则调用tryCacheImageOnDisk来下载图片并且保持在磁盘

private boolean tryCacheImageOnDisk() throws TaskCancelledException {
        L.d(LOG_CACHE_IMAGE_ON_DISK, memoryCacheKey);

        boolean loaded;
        try {
            loaded = downloadImage();
            ...
        } ...
        return loaded;
    }

调用了downloadImage进行下载图片

private boolean downloadImage() throws IOException {
        InputStream is = getDownloader().getStream(uri, options.getExtraForDownloader());
        if (is == null) {
            L.e(ERROR_NO_IMAGE_STREAM, memoryCacheKey);
            return false;
        } else {
            try {
                return configuration.diskCache.save(uri, is, this);
            } finally {
                IoUtils.closeSilently(is);
            }
        }
    }

可以看到这里调用了getDownloader().getStream来下载，这里先不扩展，在后面会说到
下载之后则保存在磁盘中。
回来前面

String imageUriForDecoding = uri;
                if (options.isCacheOnDisk() && tryCacheImageOnDisk()) {
                    imageFile = configuration.diskCache.get(uri);
                    if (imageFile != null) {
                        imageUriForDecoding = Scheme.FILE.wrap(imageFile.getAbsolutePath());
                    }
                }
                checkTaskNotActual();
                bitmap = decodeImage(imageUriForDecoding);

这里有个String变量imageUriForDecoding，初始值是uri，如果有设置磁盘缓存的话，则会调用tryCacheImageOnDisk来下载并且保持图片，此时的imageUriForDecoding则是文件File的路径。

如果没有设置磁盘缓存的话，则imageUriForDecoding还是uri。
关键则是在decodeImage，它能根据对应的uri来加载图片。

    private Bitmap decodeImage(String imageUri) throws IOException {
        ViewScaleType viewScaleType = imageAware.getScaleType();
        ImageDecodingInfo decodingInfo = new ImageDecodingInfo(memoryCacheKey, imageUri, uri, targetSize, viewScaleType,
                getDownloader(), options);
        return decoder.decode(decodingInfo);
    }

把传递进来的imageUri（可能是文件的uri，也可能是图片的uri）封装到ImageDecodingInfo进行解析。
这里的decoder是ImageDecode，它的默认实现类是BaseImageDecode

@Override
    public Bitmap decode(ImageDecodingInfo decodingInfo) throws IOException {
        Bitmap decodedBitmap;
        ImageFileInfo imageInfo;

        InputStream imageStream = getImageStream(decodingInfo);
        ...
}

通过getImageStream来获取输入流

protected InputStream getImageStream(ImageDecodingInfo decodingInfo) throws IOException {
        return decodingInfo.getDownloader().getStream(decodingInfo.getImageUri(), decodingInfo.getExtraForDownloader());
    }

这里的Downloader默认实现类是BaseImageDownloader

    @Override
    public InputStream getStream(String imageUri, Object extra) throws IOException {
        switch (Scheme.ofUri(imageUri)) {
            case HTTP:
            case HTTPS:
                return getStreamFromNetwork(imageUri, extra);
            case FILE:
                return getStreamFromFile(imageUri, extra);
            case CONTENT:
                return getStreamFromContent(imageUri, extra);
            case ASSETS:
                return getStreamFromAssets(imageUri, extra);
            case DRAWABLE:
                return getStreamFromDrawable(imageUri, extra);
            case UNKNOWN:
            default:
                return getStreamFromOtherSource(imageUri, extra);
        }
    }

可以看到，在这里，已经做了多种情况的读取判断。第一篇文章就有介绍到UIL可以根据不同的uri来解析图片，其原理就是在这里。
而前面通过tryCacheImageOnDisk来下载图片也是根据这个。这里就不一一扩展开。
这里的网络下载图片内部则是使用HttpUrlConnection来下载的。

回到最前面LoadAndDisplayImageTask的run方法后面，当我们获取到Bitmap后，到了

    DisplayBitmapTask displayBitmapTask = new DisplayBitmapTask(bmp, imageLoadingInfo, engine, loadedFrom);
        runTask(displayBitmapTask, syncLoading, handler, engine);

这两个代码就是一个显示任务
直接看DisplayBitmapTask类的run（）方法

    @Override
    public void run() {
        if (imageAware.isCollected()) {
            L.d(LOG_TASK_CANCELLED_IMAGEAWARE_COLLECTED, memoryCacheKey);
            listener.onLoadingCancelled(imageUri, imageAware.getWrappedView());
        } else if (isViewWasReused()) {
            L.d(LOG_TASK_CANCELLED_IMAGEAWARE_REUSED, memoryCacheKey);
            listener.onLoadingCancelled(imageUri, imageAware.getWrappedView());
        } else {
            L.d(LOG_DISPLAY_IMAGE_IN_IMAGEAWARE, loadedFrom, memoryCacheKey);
            displayer.display(bitmap, imageAware, loadedFrom);
            engine.cancelDisplayTaskFor(imageAware);
            listener.onLoadingComplete(imageUri, imageAware.getWrappedView(), bitmap);
        }
    }

假如ImageView被回收了或者被重用了，回调给ImageLoadingListener接口，否则就调用BitmapDisplayer去显示Bitmap。到这里Bitmap已经显示加载完成，调用engine移除图片显示任务。

当然在最前面那里

public void displayImage(String uri, ImageAware imageAware, DisplayImageOptions options,
            ImageSize targetSize, ImageLoadingListener listener, ImageLoadingProgressListener progressListener) {
            ...
            ImageLoadingInfo imageLoadingInfo = new ImageLoadingInfo(uri, imageAware, targetSize, memoryCacheKey,
                    options, listener, progressListener, engine.getLockForUri(uri));
            LoadAndDisplayImageTask displayTask = new LoadAndDisplayImageTask(engine, imageLoadingInfo,
                    defineHandler(options));
            if (options.isSyncLoading()) {
                displayTask.run();
            } else {
                engine.submit(displayTask);
            }
        }
    }

如果此时的显示加载是异步的话，则交由engine的Executor线程池去处理，最终也是调用了LoadAndDisplayImageTask的run方法去加载显示。

到这里Universal-Image-Loader的分析也算完了，从基本使用到内存模型在加载显示，可以看到UIL这个开源框架十分的灵活，比如建造者模式，装饰模式，代理模式，策略模式等等，这样方便我们去扩展，实现我们想要的功能，当然，也带给我们更多的想象空间。

参考资料

Android 开源框架Universal-Image-Loader完全解析（三）---源代码解读

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

推荐阅读更多精彩内容