谷歌發布ViewPager2正式版，Android開發如何用它實現懶加載？

作者：快樂丸
鏈接：https://blog.csdn.net/qq_36486247/article/details/103959356

前言
ViewPager2是官方推出的新控件，從名稱上也能看出是用于替代ViewPager的，它是基于RecyclerView實現的，因此可以實現一些ViewPager沒有的功能，最實用的一點就是支持豎直方向滾動了。
雖然很早就聽說過，但是從一些文章中也多少了解到ViewPager2使用的一些坑，也就一直沒有正式使用過。前不久ViewPager2發布了1.0.0正式版，心想是時候嘗試一下了。哈哈，可能是因為此前寫過兩篇懶加載相關的文章吧，我第一時間想到的不是ViewPager新功能的使用，而是在配合Fragment時如何實現懶加載。本文就來具體探究一下ViewPager2中的懶加載問題，關于ViewPager2的使用已經有很多詳細的文章了，不是本文的研究重點，因此就不會具體介紹了。

在進入正文之前要強調一下，本文的分析基于ViewPager2的1.0.0版本，是在androidx包下的，因此在使用ViewPager2之前需要做好androidx的適配工作。

利用ViewPager2加載多個Fragment

第一步、首先需要在build.gradle文件中添加ViewPager2的依賴

implementation 'androidx.viewpager2:viewpager2:1.0.0'

第二步、在布局文件中添加ViewPager2

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <androidx.viewpager2.widget.ViewPager2
        android:id="@+id/view_pager2"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />

</LinearLayout>

第三步、編寫Adapter
需要注意，ViewPager2中加載Fragment時的Adapter類需要繼承自FragmentStateAdapter，而不是ViewPager中的FragmentStatePagerAdapter。

public class MyFragmentPagerAdapter extends FragmentStateAdapter {

    private List<Fragment> mFragments;

    public MyFragmentPagerAdapter(@NonNull FragmentActivity fragmentActivity, List<Fragment> fragments) {
        super(fragmentActivity);
        this.mFragments = fragments;
    }

    @NonNull
    @Override
    public Fragment createFragment(int position) {
        return mFragments.get(position);
    }

    @Override
    public int getItemCount() {
        return mFragments.size();
    }
}

第四步、為ViewPager2設置Adapter

ViewPager2 mViewPager2 = findViewById(R.id.view_pager2);
List<Fragment> mFragments = new ArrayList<>();
mFragments .add(new FirstFragment());
mFragments .add(new SecondFragment());
mFragments .add(new ThirdFragment());
MyFragmentPagerAdapter mAdapter = new MyFragmentPagerAdapter(this, mFragments);
mViewPager2.setAdapter(mAdapter);

經過以上幾步我們就實現了利用ViewPager2加載多個Fragment，當然我這里是為了簡單演示，具體的Fragment類我就不展示了。

Fragment切換時的生命周期方法執行情況

接下來我們具體來看一下Fragment切換時生命周期方法的執行情況。我在測試用例中添加了6個Fragment，在Fragment的生命周期回調方法中打印執行情況，具體執行結果如下：

  • 初始情況顯示第一個Fragment

可以看出此時只創建出了第一個Fragment，生命周期方法執行到了onResume()，其他的幾個Fragment并沒有創建。

  • 切換到第二個Fragment

此時創建出了第二個Fragment，生命周期方法同樣執行到onResume()，同時，第一個Fragment執行onPause()方法。

  • 切換到第三個Fragment

和上一種情況相同，創建出第三個Fragment，執行到onResume()方法，同時第二個Fragment執行onPause()方法。

  • 切換到第四個Fragment

和前兩種情況相同，同樣是創建出當前Fragment，生命周期方法執行到onResume()，并且上一個Fragment執行onPause()方法。不同的是，此時會銷毀第一個Fragment，依次執行onStop()、onDestroyView()、onDestroy()和onDetach()方法。

  • 切換到第五個Fragment

和上一種情況相同，創建出第五個Fragment，生命周期方法執行到onResume()，第四個Fragment執行onPause()方法，同時銷毀第二個Fragment。

  • 切換到第六個（最后一個）Fragment

可以看出此時創建出了第六個Fragment，生命周期方法執行到onResume()，第五個Fragment執行onPause()方法，如果按照上面兩種情況的執行結果來看，此時應該會銷毀第三個Fragment，但實際上并沒有。

從以上幾種情況下Fragment生命周期方法的執行情況來看，不難看出ViewPager2默認情況下不會預先創建出下一個Fragment。

但與此同時，Fragment的銷毀情況就令我有些不解了，如果不看切換到最后一個Fragment的情況，我們可以猜測是由于ViewPager2內部RecyclerView的緩存機制導致最多可以存在三個Fragment，但是切換到最后一個Fragment的情況就違背了我們的猜測，很明顯此時并沒有銷毀前面的Fragment。

接下來我們就根據上述結果來分析一下ViewPager2加載Fragment的幾個問題。

ViewPager2中的setOffscreenPageLimit()方法

通過示例中的執行結果我們可以發現ViewPager2默認情況下不會像ViewPager那樣預先加載出兩側的Fragment，這是為什么呢，我們可能會想到ViewPager中預加載相關的一個方法：setOffscreenPageLimit()，ViewPager2中也定義了該方法，我們來看一下它們的區別。

首先來看ViewPager中的setOffscreenPageLimit()方法：

private static final int DEFAULT_OFFSCREEN_PAGES = 1;
private int mOffscreenPageLimit = DEFAULT_OFFSCREEN_PAGES;

public void setOffscreenPageLimit(int limit) {
    if (limit < DEFAULT_OFFSCREEN_PAGES) {
        Log.w(TAG, "Requested offscreen page limit " + limit + " too small; defaulting to "
                + DEFAULT_OFFSCREEN_PAGES);
        limit = DEFAULT_OFFSCREEN_PAGES;
    }
    if (limit != mOffscreenPageLimit) {
        mOffscreenPageLimit = limit;
        populate();
    }
}

方法傳入一個整型數值，表示當前Fragment兩側的預加載數量，很多人可能都知道，ViewPager默認的預加載數量為1，也就是會預先創建出當前Fragment左右兩側的一個Fragment。

從代碼中我們可以看出，如果我們傳入的數值小于1，依然會將預加載數量設置為1，這也導致了ViewPager無法取消預加載，也因此才會需要Fragment的懶加載方案。

接下來我們來看ViewPager2中的setOffscreenPageLimit()方法：

public static final int OFFSCREEN_PAGE_LIMIT_DEFAULT = -1;
private int mOffscreenPageLimit = OFFSCREEN_PAGE_LIMIT_DEFAULT;

public void setOffscreenPageLimit(@OffscreenPageLimit int limit) {
    if (limit < 1 && limit != OFFSCREEN_PAGE_LIMIT_DEFAULT) {
        throw new IllegalArgumentException(
                "Offscreen page limit must be OFFSCREEN_PAGE_LIMIT_DEFAULT or a number > 0");
    }
    mOffscreenPageLimit = limit;
    // Trigger layout so prefetch happens through getExtraLayoutSize()
    mRecyclerView.requestLayout();
}

我們可以看出ViewPager2中默認的預加載數量mOffscreenPageLimit為OFFSCREEN_PAGE_LIMIT_DEFAULT也就是-1，我們可以通過傳入該默認值或者大于1的整數來設置預加載數量。

接下我們來看一下哪里用到了mOffscreenPageLimit，通過全局搜索，我們可以發現在ViewPager2的內部類LinearLayoutManagerImpl中的calculateExtraLayoutSpace()方法中通過getOffscreenPageLimit()方法獲取了mOffscreenPageLimit。

@Override
protected void calculateExtraLayoutSpace(@NonNull RecyclerView.State state,
                                         @NonNull int[] extraLayoutSpace) {
    int pageLimit = getOffscreenPageLimit();
    if (pageLimit == OFFSCREEN_PAGE_LIMIT_DEFAULT) {
        // Only do custom prefetching of offscreen pages if requested
        super.calculateExtraLayoutSpace(state, extraLayoutSpace);
        return;
    }
    final int offscreenSpace = getPageSize() * pageLimit;
    extraLayoutSpace[0] = offscreenSpace;
    extraLayoutSpace[1] = offscreenSpace;
}

calculateExtraLayoutSpace()方法定義在LinearLayoutManager中，用于計算LinearLayoutManager布局的額外空間，也就是RecyclerView顯示范圍之外的空間，計算結果在保存參數extraLayoutSpace中，它是一個長度為2的整型數組，extraLayoutSpace[0]表示頂部/左側的額外空間，extraLayoutSpace[1]表示底部/右側的額外空間（取決于方向）。

LinearLayoutManagerImpl重寫了該方法，方法內部首先判斷了mOffscreenPageLimit的值，如果等于默認值OFFSCREEN_PAGE_LIMIT_DEFAULT，則直接調用父類方法，不設置額外的布局空間；

如果mOffscreenPageLimit的值大于1，則設置左右（或上下）兩邊的額外空間為getPageSize() * pageLimit，相當于預加載出了兩邊的Fragment。

看到這里我們就清楚了為什么默認情況下ViewPager2不會預加載出兩側的Fragment，就是因為默認的預加載數量為-1。和ViewPager一樣，我們可以通過調用setOffscreenPageLimit()方法，傳入大于1的值來設置預加載數量。

在此前的示例中，我們添加下面的代碼：

mViewPager2.setOffscreenPageLimit(1);

首次顯示第一個Fragment時打印的結果如下：


可以看出此時ViewPager2就會預先創建出下一個Fragment，和ViewPager默認的情況相同。

RecyclerView中的緩存和預取機制

接下來我們來看一下Fragment的銷毀情況，探究一下為什么在上面的示例中ViewPager2切換到最后一個Fragment時沒有銷毀前面的Fragment。

在此之前，我們先要了解一下RecyclerView的緩存機制和預取機制。

RecyclerView的緩存機制算是老生常談的問題了，核心在它的一個內部類Recycler中，Item的回收和復用相關工作都是Recycler來進行的，RecyclerView的緩存可以分為多級，由于我了解得非常淺顯，這里就不詳細介紹了，大家可以自行查看相關文章。

我們直接來看和ViewPager2中Fragment回收相關的緩存——mCachedViews，它的類型是ArrayList，移出屏幕的Item對應的ViewHolder都會被優先緩存到該容器中。

Recycler類中有一個成員變量mViewCacheMax，表示mCachedViews最大的緩存數量，默認值為2，我們可以通過調用RecyclerView的setItemViewCacheSize()方法來設置緩存大小。

回到我們的具體場景中，通過查看FragmentStateAdapter類的源碼，我們可以看到，此時mCachedViews中保存的ViewHolder類型為FragmentViewHolder，它的視圖根布局是一個FrameLayout，Fragment會被添加到對應的FrameLayout中，因此緩存ViewHolder其實就相當于緩存了Fragment，為了簡明，我后面就都說成緩存Fragment了，大家清楚這樣說是不準確的就好了。

在上面的示例中，我們使用ViewPager2加載了6個Fragment，當切換到第四個Fragment時，由于最多只能緩存兩個Fragment，此時mCachedViews中緩存的是第二個Fragment和第三個Fragment，因此第一個Fragment就要被銷毀，之后切換到第五個Fragment的情況同理，此時會緩存第三個和第四個Fragment，因此第二個Fragment被銷毀。

接下來問題就來了，如果按照這樣的解釋，當切換到第六個Fragment時應該銷毀第三個Fragment，上面的示例中很明顯沒有啊，這又是為什么呢？

這就涉及到RecyclerView的預取（Prefetch）機制了，它是官方在support v25版本包中引入的功能，具體表現為在RecyclerView滑動時會預先加載出下一個Item，準確地說是預先創建出下一個Item對應的ViewHolder。默認情況下預取功能是開啟的，我們可以調用下面的代碼來關閉：

mRecyclerView.getLayoutManager().setItemPrefetchEnabled(false);

那么預取機制會對ViewPager2中Fragment的銷毀產生什么影響呢，我們從源碼角度來簡單分析一下。首先來看RecyclerView的onTouchEvent()方法：

RecyclerView的onTouchEvent()方法

@Override
public boolean onTouchEvent(MotionEvent e) {
    // ...
    switch (action) {
        // ...
        case MotionEvent.ACTION_MOVE: {
            // ...
            if (mGapWorker != null && (dx != 0 || dy != 0)) {
                mGapWorker.postFromTraversal(this, dx, dy);
            }
        }
        break;
        // ...
    }
    // ...
    return true;
}

可以看到在RecyclerView滑動時會調用到mGapWorker的postFromTraversal()方法，將水平和豎直方向上的位移通過參數傳入，用于后面計算預取的Item位置。mGapWorker類型為GapWorker，我們來看它的postFromTraversal()方法：
GapWorker的postFromTraversal()方法

/**
 * Schedule a prefetch immediately after the current traversal.
 */
void postFromTraversal(RecyclerView recyclerView, int prefetchDx, int prefetchDy) {
    // ...
    recyclerView.post(this);
    // ...
}

從方法的注釋上我們也能看出它和RecyclerView的預取有關，方法內部會調用RecyclerView的post()方法，參數傳入了this，也就是當前GapWorker對象，通過查看GapWorker類的定義可以看到它實現了Runnable，因此這里就是提交一個任務到主線程的消息隊列中。接下來我們來看GapWorker實現的run()方法：

@Override
public void run() {
    // ...
    long nextFrameNs = TimeUnit.MILLISECONDS.toNanos(latestFrameVsyncMs) + mFrameIntervalNs;
    prefetch(nextFrameNs);
    // ...
}

方法內部會調用prefetch()方法，看到方法名大概可以推測出接下來就要進行預取相關邏輯了，我們接著來看。

void prefetch(long deadlineNs) {
    // 構建預取任務
    buildTaskList();
    // 開始執行預取任務
    flushTasksWithDeadline(deadlineNs);
}

prefetch()方法中首先會調用buildTaskList()方法來構建預取任務，主要是通過此前傳過來的水平和豎直方向位移確定出預取的位置，接下來會調用flushTasksWithDeadline()方法來執行預取任務，我們這里只看buildTaskList()方法就好。

private void buildTaskList() {
    final int viewCount = mRecyclerViews.size();
    int totalTaskCount = 0;
    for (int i = 0; i < viewCount; i++) {
        RecyclerView view = mRecyclerViews.get(i);
        if (view.getWindowVisibility() == View.VISIBLE) {
            // 關鍵代碼
            view.mPrefetchRegistry.collectPrefetchPositionsFromView(view, false);
            totalTaskCount += view.mPrefetchRegistry.mCount;
        }
    }
    // ...
}

接下來又會調用RecyclerView中mPrefetchRegistry的collectPrefetchPositionsFromView()方法，mPrefetchRegistry的類型為LayoutPrefetchRegistryImpl，它是GapWorker中的一個內部類，我們接著來看它的collectPrefetchPositionsFromView()方法。

void collectPrefetchPositionsFromView(RecyclerView view, boolean nested) {
    mCount = 0;
    // ...
    final RecyclerView.LayoutManager layout = view.mLayout;
    if (view.mAdapter != null
            && layout != null
            && layout.isItemPrefetchEnabled()) {
        // ...
        // momentum based prefetch, only if we trust current child/adapter state
        if (!view.hasPendingAdapterUpdates()) {
            layout.collectAdjacentPrefetchPositions(mPrefetchDx, mPrefetchDy,
                    view.mState, this);
        }

        if (mCount > layout.mPrefetchMaxCountObserved) {
            layout.mPrefetchMaxCountObserved = mCount;
            layout.mPrefetchMaxObservedInInitialPrefetch = nested;
            view.mRecycler.updateViewCacheSize();
        }
    }
}

方法內部首先會將LayoutPrefetchRegistryImpl中的成員變量mCount置為0，接著通過isItemPrefetchEnabled()方法判斷RecyclerView是否開啟了預取，默認是開啟的，接下來會執行layout的collectAdjacentPrefetchPositions()方法，這里的layout是RecyclerView設置的LayoutManager，我們以LinearLayoutManager為例，看一下它的collectAdjacentPrefetchPositions()方法。

LinearLayoutManager的collectAdjacentPrefetchPositions()方法

@Override
public void collectAdjacentPrefetchPositions(int dx, int dy, RecyclerView.State state,
                                             LayoutPrefetchRegistry layoutPrefetchRegistry) {
    // ...
    collectPrefetchPositionsForLayoutState(state, mLayoutState, layoutPrefetchRegistry);
}

void collectPrefetchPositionsForLayoutState(RecyclerView.State state, LayoutState layoutState,
                                            LayoutPrefetchRegistry layoutPrefetchRegistry) {
    // ...
    layoutPrefetchRegistry.addPosition(pos, Math.max(0, layoutState.mScrollingOffset));
}

方法內部又會調用collectPrefetchPositionsForLayoutState()方法，接著調用layoutPrefetchRegistry的addPosition()方法，這里的layoutPrefetchRegistry是從上面的collectPrefetchPositionsFromView()方法中傳過來的，可以看到參數傳的是this，也就是LayoutPrefetchRegistryImpl對象。我們接著來看LayoutPrefetchRegistryImpl的addPosition()方法：
LayoutPrefetchRegistryImpl的addPosition()方法

@Override
public void addPosition(int layoutPosition, int pixelDistance) {
    // ...
    mCount++;
}

可以看到方法最后會將mCount加1，此時mCount的值變為1。接下來我們回到collectPrefetchPositionsFromView()方法，來看方法最后執行的一個判斷。

if (mCount > layout.mPrefetchMaxCountObserved) {
    layout.mPrefetchMaxCountObserved = mCount;
    layout.mPrefetchMaxObservedInInitialPrefetch = nested;
    view.mRecycler.updateViewCacheSize();
}

這里判斷了mCount和mPrefetchMaxCountObserved的大小關系，mPrefetchMaxCountObserved是LayoutManager中定義的一個整型變量，初始值為0，因此這里會進入到if判斷中。

接著會將mCount賦值給mPrefetchMaxCountObserved，此時mPrefetchMaxCountObserved的值變為1，最后會調用Recycler的updateViewCacheSize()方法，我們來看一下這個方法。
Recycler的updateViewCacheSize()方法

void updateViewCacheSize() {
    int extraCache = mLayout != null ? mLayout.mPrefetchMaxCountObserved : 0;
    mViewCacheMax = mRequestedCacheMax + extraCache;

    // first, try the views that can be recycled
    for (int i = mCachedViews.size() - 1;
         i >= 0 && mCachedViews.size() > mViewCacheMax; i--) {
        recycleCachedViewAt(i);
    }
}

方法內部首先定義了一個整型變量extraCache，字面上看就是額外的緩存，它的值就是上一步中的mPrefetchMaxCountObserved，也就是1。

接下來這一步就重要了，將mRequestedCacheMax + extraCache賦值給mViewCacheMax，我們前面在介紹RecyclerView緩存的時候提到過mViewCacheMax表示mCachedViews的最大緩存數量，mRequestedCacheMax就是我們設置的mCachedViews緩存數量，默認值為2，因此此時mViewCacheMax的值被設置為3，也就是說mCachedViews最多可以保存3個ViewHolder（對于我們的場景來說就是Fragment）。

看到這里我們就大致清楚了示例中Fragment銷毀情況產生的原因，當從第一個Fragment切換到第二個Fragment時會執行我們上面分析的預取邏輯，將mCachedViews的最大緩存數量由默認的2置為3。

對于切換到第三、第四和第五個Fragment的情況，由于預取的Fragment占據了mCachedViews中的一個位置，因此還是表現為最多緩存2個Fragment。

當切換到第六個也就是最后一個Fragment時，不需要再預取下一個Fragment了，但是此時mCachedViews的最大緩存數量依然為3，所以第三個Fragment也可以被添加到緩存中，不會被銷毀。

為了驗證得出的結論，我們首先通過代碼取消ViewPager2內部RecyclerView的預取機制：

((RecyclerView) mViewPager2.getChildAt(0)).getLayoutManager().setItemPrefetchEnabled(false);

然后再來運行一下此前的示例程序，直接來看切換到最后一個Fragment的情況。


可以看出當切換到最后一個Fragment時會銷毀掉第三個Fragment，此時緩存的Fragment為第四和第五個，這是由于我們關閉了預取機制，在執行LayoutPrefetchRegistryImpl中的collectPrefetchPositionsFromView()方法時不滿足layout.isItemPrefetchEnabled()為true的條件，不會執行后面的邏輯，因此mCachedViews的最大緩存數量始終為2，這就驗證了我們的結論是沒錯的。

ViewPager2中的懶加載方案

由于ViewPager2默認情況下不會預加載出兩邊的Fragment，相當于默認就是懶加載的，因此如果我們如果沒有通過setOffscreenPageLimit()方法設置預加載數量，完全可以不做任何額外處理。但是對于Fragment很多的情況，由于ViewPager2中的RecyclerView可以緩存Fragment的數量是有限的，因此會造成Fragment的多次銷毀和創建，如何解決這個問題呢？下面就介紹一下我的解決方案。

首先設置ViewPager2的預加載數量，讓ViewPager2預先創建出所有的Fragment，防止切換造成的頻繁銷毀和創建。

mViewPager2.setOffscreenPageLimit(mFragments.size());

通過此前示例中Fragment切換時生命周期方法的執行情況我們不難發現不管Fragment是否會被預先創建，只有可見時才會執行到onResume()方法，我們正好可以利用這一規律來實現懶加載，具體實現方式和我此前介紹過的androidx中的Fragment懶加載方案相同，這里我再簡單說一下。

  • 將Fragment加載數據的邏輯放到onResume()方法中，這樣就保證了Fragment可見時才會加載數據。
  • 聲明一個變量標記是否是首次執行onResume()方法，因為每次Fragment由不可見變為可見都會執行onResume()方法，需要防止數據的重復加載。
    按照以上兩點就可以封裝我們的懶加載Fragment了，完整代碼如下：
public abstract class LazyFragment extends Fragment {

    private Context mContext;
    private boolean isFirstLoad = true; // 是否第一次加載

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mContext = getActivity();
    }

    @Nullable
    @Override
    public View onCreateView(@NonNull LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
        View view = LayoutInflater.from(mContext).inflate(getContentViewId(), null);
        initView(view);
        return view;
    }

    @Override
    public void onResume() {
        super.onResume();
        if (isFirstLoad) {
            // 將數據加載邏輯放到onResume()方法中
            initData();
            initEvent();
            isFirstLoad = false;
        }
    }

    /**
     * 設置布局資源id
     *
     * @return
     */
    protected abstract int getContentViewId();

    /**
     * 初始化視圖
     *
     * @param view
     */
    protected void initView(View view) {

    }

    /**
     * 初始化數據
     */
    protected void initData() {

    }

    /**
     * 初始化事件
     */
    protected void initEvent() {

    }
}

當然這只是我認為比較好的一種方案，如果有什么地方考慮得有問題或是大家有自己的見解都歡迎提出。

總結

本文探究了利用ViewPager2加載Fragment時生命周期方法的執行情況，進而得出ViewPager2懶加載的實現方式：

簡單來說完全可以不做任何處理，ViewPager2默認就實現了懶加載。但是如果想避免Fragment頻繁銷毀和創建造成的開銷，可以通過setOffscreenPageLimit()方法設置預加載數量，將數據加載邏輯放到Fragment的onResume()方法中。

雖說本文的研究對象是ViewPager2，但是文章大部分篇幅都是在分析RecyclerView，不得不感嘆RecyclerView確實是一個很重要的控件，如何使用大家基本都已經爛熟于心了，但是涉及到原理上的東西就不一樣了，我對RecyclerView的了解也是甚淺，有時間的話還是有必要深入學習一下的。

點關注，獲得更多Android開發技能~~

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
    沈念sama閱讀 227,967評論 6贊 531
  • 死咒
    序言：濱河連續發生了三起死亡事件，死亡現場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機，發現死者居然都...
    沈念sama閱讀 98,273評論 3贊 415
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事?！?“怎么了？”我有些...
    開封第一講書人閱讀 175,870評論 0贊 373
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長。 經常有香客問我，道長，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 62,742評論 1贊 309
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮，結果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當我...
    茶點故事閱讀 71,527評論 6贊 407
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著，像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上，一...
    開封第一講書人閱讀 55,010評論 1贊 322
  • 城市分裂傳說
    那天，我揣著相機與錄音，去河邊找鬼。 笑死，一個胖子當著我的面吹牛，可吹牛的內容都是我干的。 我是一名探鬼主播，決...
    沈念sama閱讀 43,108評論 3贊 440
  • 雙鴛鴦連環套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側響起，我...
    開封第一講書人閱讀 42,250評論 0贊 288
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當地人在樹林里發現了一具尸體，經...
    沈念sama閱讀 48,769評論 1贊 333
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,656評論 3贊 354
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,853評論 1贊 369
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
    沈念sama閱讀 38,371評論 5贊 358
  • ?日本核電站爆炸內幕
    正文 年R本政府宣布，位于F島的核電站，受9級特大地震影響，放射性物質發生泄漏。R本人自食惡果不足惜，卻給世界環境...
    茶點故事閱讀 44,103評論 3贊 347
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,472評論 0贊 26
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監牢的瞬間，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,717評論 1贊 281
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。 一個月前我還...
    沈念sama閱讀 51,487評論 3贊 390
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
    茶點故事閱讀 47,815評論 2贊 372