Framework 源码解析知识梳理(5) - startService 源码分析

一、前言

最近在看关于插件化的知识，遇到了如何实现Service插件化的问题，因此，先学习一下Service内部的实现原理，这里面会涉及到应用进程和ActivityManagerService的通信，建议大家先阅读一下之前的这篇文章 Framework 源码解析知识梳理(1) - 应用进程与 AMS 的通信实现，整个Service的启动过程离不开和AMS的通信，从整个宏观上来看，它的模型如下，是不是和我们之前分析的通信过程一模一样：

二、源码分析

当我们在Activity/Service/Application中，通过下面这个方法启动Service时：

public ComponentName startService(Intent service)

与之前分析过的很多源码类似，最终会调用到ContextImpl的同名方法当中，而该方法又会调用内部的startServiceCommon(Intent, UserHandle)：


在该方法中，主要做了两件事：

  • 校验Intent的合法性，对于Android 5.0以后，我们要求Intent中需要制定Package和Component中至少一个，否则会抛出异常。
  • 通过Binder通信调用到ActivityManagerService的对应方法，关于调用的详细过程可以参考 Framework 源码解析知识梳理(1) - 应用进程与 AMS 的通信实现 中对于应用进程到ActivityManagerService的通信部分分析。

ActivityManagerService中的实现为：


这里面，通过mServices变量来去实现Service的启动，而mServices的类型为ActiveServices，它是ActivityManagerService中负责处理Service相关业务的类，无论我们是通过start还是bind方式启动的Service，都是通过它来实现的，它也被称为“应用服务”的管理类。

从通过ActiveServices调用startServiceLocked，到Service真正被启动的过程如下图所示，下面，我们就来一一分析每一个阶段究竟做了什么：

我们首先来看入口函数startServiceLocked的内部实现：

    ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
            int callingPid, int callingUid, String callingPackage, final int userId)
            throws TransactionTooLargeException {

        final boolean callerFg;
        //caller是调用者进程在AMS的远程代理对象，类型为ApplicationThreadProxy。
        if (caller != null) {
            //获得调用者的进程信息。
            final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller);
            if (callerApp == null) {
                throw new SecurityException(
                        "Unable to find app for caller " + caller
                        + " (pid=" + Binder.getCallingPid()
                        + ") when starting service " + service);
            }
            callerFg = callerApp.setSchedGroup != ProcessList.SCHED_GROUP_BACKGROUND;
        } else {
            callerFg = true;
        }

        //通过传递的信息，解析出要启动的Service，封装在ServiceLookupResult中。
        ServiceLookupResult res =
            retrieveServiceLocked(service, resolvedType, callingPackage,
                    callingPid, callingUid, userId, true, callerFg, false);
        if (res == null) {
            return null;
        }
        if (res.record == null) {
            return new ComponentName("!", res.permission != null
                    ? res.permission : "private to package");
        }
        //对于每个被启动的Service，它们在AMS端的数据结构为ServiceRecord。
        ServiceRecord r = res.record;

        if (!mAm.mUserController.exists(r.userId)) {
            Slog.w(TAG, "Trying to start service with non-existent user! " + r.userId);
            return null;
        }
        //判断是否允许启动该服务。
        if (!r.startRequested) {
            final long token = Binder.clearCallingIdentity();
            try {
                final int allowed = mAm.checkAllowBackgroundLocked(
                        r.appInfo.uid, r.packageName, callingPid, true);
                if (allowed != ActivityManager.APP_START_MODE_NORMAL) {
                    Slog.w(TAG, "Background start not allowed: service "
                            + service + " to " + r.name.flattenToShortString()
                            + " from pid=" + callingPid + " uid=" + callingUid
                            + " pkg=" + callingPackage);
                    return null;
                }
            } finally {
                Binder.restoreCallingIdentity(token);
            }
        }
        //是否需要配置相应的权限。
        NeededUriGrants neededGrants = mAm.checkGrantUriPermissionFromIntentLocked(
                callingUid, r.packageName, service, service.getFlags(), null, r.userId);

        if (Build.PERMISSIONS_REVIEW_REQUIRED) {
            if (!requestStartTargetPermissionsReviewIfNeededLocked(r, callingPackage,
                    callingUid, service, callerFg, userId)) {
                return null;
            }
        }
        //如果该Service正在等待被重新启动，那么移除它。
        if (unscheduleServiceRestartLocked(r, callingUid, false)) {
            if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "START SERVICE WHILE RESTART PENDING: " + r);
        }
        //给ServiceRecord添加必要的信息。
        r.lastActivity = SystemClock.uptimeMillis();
        r.startRequested = true;
        r.delayedStop = false;
        r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                service, neededGrants));
        //其它的一些逻辑，与第一次启动无关，就先不分析了。
        return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
    }

简单地来说，就是根据Intent查找需要启动的Service，封装成ServiceRecord对象，初始化其中的关键变量，在这一过程中，加入了一些必要的逻辑判断，最终调用了startServiceInnerLocked方法。

    ComponentName startServiceInnerLocked(ServiceMap smap, Intent service, ServiceRecord r,
            boolean callerFg, boolean addToStarting) throws TransactionTooLargeException {
        //...
        String error = bringUpServiceLocked(r, service.getFlags(), callerFg, false, false);
        //...
        return r.name;
    }

这里面的逻辑我们先忽略掉一部分，只需要知道在正常情况下它会去调用bringUpServiceLocked来启动Service：

    private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
            boolean whileRestarting) throws TransactionTooLargeException {
 
        //如果该Service已经启动。
        if (r.app != null && r.app.thread != null) {
            sendServiceArgsLocked(r, execInFg, false);
            return null;
        }
        //如果正在等待被重新启动，那么什么也不做。
        if (!whileRestarting && r.restartDelay > 0) {
            return null;
        }

        if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Bringing up " + r + " " + r.intent);

        //清除等待被重新启动的状态。
        if (mRestartingServices.remove(r)) {
            r.resetRestartCounter();
            clearRestartingIfNeededLocked(r);
        }

        //因为我们马上就要启动该Service，因此去掉它的延时属性。
        if (r.delayed) {
            if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (bring up): " + r);
            getServiceMap(r.userId).mDelayedStartList.remove(r);
            r.delayed = false;
        }

        //如果该Service所属的用户没有启动，那么调用 bringDownServiceLocked 方法。
        if (mAm.mStartedUsers.get(r.userId) == null) {
            String msg = "Unable to launch app "
                    + r.appInfo.packageName + "/"
                    + r.appInfo.uid + " for service "
                    + r.intent.getIntent() + ": user " + r.userId + " is stopped";
            Slog.w(TAG, msg);
            bringDownServiceLocked(r);
            return msg;
        }

        try {
            AppGlobals.getPackageManager().setPackageStoppedState(
                    r.packageName, false, r.userId);
        } catch (RemoteException e) {
        } catch (IllegalArgumentException e) {
            Slog.w(TAG, "Failed trying to unstop package "
                    + r.packageName + ": " + e);
        }

        final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
        final String procName = r.processName;
        ProcessRecord app;
        //如果不是运行在独立的进程。
        if (!isolated) {
            app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
            if (DEBUG_MU) Slog.v(TAG_MU, "bringUpServiceLocked: appInfo.uid=" + r.appInfo.uid
                        + " app=" + app);
            //如果该进程已经启动，那么调用realStartServiceLocked方法。
            if (app != null && app.thread != null) {
                try {
                    app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
                    //在Service所属进程已经启动的情况下调用的方法。
                    realStartServiceLocked(r, app, execInFg);
                    return null;
                } catch (TransactionTooLargeException e) {
                    throw e;
                } catch (RemoteException e) {
                    Slog.w(TAG, "Exception when starting service " + r.shortName, e);
                }
            }
        } else {
            app = r.isolatedProc;
        }

        //如果该Service所对应的进程没有启动，那么首先启动该进程。
        if (app == null) {
            if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
                    "service", r.name, false, isolated, false)) == null) {
                String msg = "Unable to launch app "
                        + r.appInfo.packageName + "/"
                        + r.appInfo.uid + " for service "
                        + r.intent.getIntent() + ": process is bad";
                Slog.w(TAG, msg);
                bringDownServiceLocked(r);
                return msg;
            }
            if (isolated) {
                r.isolatedProc = app;
            }
        }
        //将该ServiceRecord加入到等待的集合当中，等到新的进程启动之后，再去启动它。
        if (!mPendingServices.contains(r)) {
            mPendingServices.add(r);
        }

        if (r.delayedStop) {
            r.delayedStop = false;
            if (r.startRequested) {
                if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE,
                        "Applying delayed stop (in bring up): " + r);
                stopServiceLocked(r);
            }
        }

        return null;
    }

bringUpServiceLocked的逻辑就比较复杂了，它会根据目标Service及其所属进程的状态，走向不同的分支：

  • 进程已经存在，并且目标Service已经启动：sendServiceArgsLocked
  • 进程已经存在，但是目标Service没有启动：realStartServiceLocked
  • 进程不存在：startProcessLocked，并且将ServiceRecord加入到mPendingServices中，等待进程启动之后再去启动该Service。

下面，我们就来一起分析一下这三种情况。

2.1 进程已经存在，并且目标 Service 已经启动

首先来当进程已经存在，且目标Service已经启动时所调用的sendServiceArgsLocked方法：

    private final void sendServiceArgsLocked(ServiceRecord r, boolean execInFg,
            boolean oomAdjusted) throws TransactionTooLargeException {
        final int N = r.pendingStarts.size();
        if (N == 0) {
            return;
        }

        while (r.pendingStarts.size() > 0) {
            Exception caughtException = null;
            ServiceRecord.StartItem si;
            try {
                si = r.pendingStarts.remove(0);
                if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Sending arguments to: "
                        + r + " " + r.intent + " args=" + si.intent);
                if (si.intent == null && N > 1) {
                    // If somehow we got a dummy null intent in the middle,
                    // then skip it.  DO NOT skip a null intent when it is
                    // the only one in the list -- this is to support the
                    // onStartCommand(null) case.
                    continue;
                }
                si.deliveredTime = SystemClock.uptimeMillis();
                r.deliveredStarts.add(si);
                si.deliveryCount++;
                if (si.neededGrants != null) {
                    mAm.grantUriPermissionUncheckedFromIntentLocked(si.neededGrants,
                            si.getUriPermissionsLocked());
                }
                bumpServiceExecutingLocked(r, execInFg, "start");
                if (!oomAdjusted) {
                    oomAdjusted = true;
                    mAm.updateOomAdjLocked(r.app);
                }
                int flags = 0;
                if (si.deliveryCount > 1) {
                    flags |= Service.START_FLAG_RETRY;
                }
                if (si.doneExecutingCount > 0) {
                    flags |= Service.START_FLAG_REDELIVERY;
                }
                r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);
            } catch (TransactionTooLargeException e) {
                if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Transaction too large: intent="
                        + si.intent);
                caughtException = e;
            } catch (RemoteException e) {
                // Remote process gone...  we'll let the normal cleanup take care of this.
                if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Crashed while sending args: " + r);
                caughtException = e;
            } catch (Exception e) {
                Slog.w(TAG, "Unexpected exception", e);
                caughtException = e;
            }

            if (caughtException != null) {
                // Keep nesting count correct
                final boolean inDestroying = mDestroyingServices.contains(r);
                serviceDoneExecutingLocked(r, inDestroying, inDestroying);
                if (caughtException instanceof TransactionTooLargeException) {
                    throw (TransactionTooLargeException)caughtException;
                }
                break;
            }
        }
    }

这里面最关键的就是调用了r.app.thread的scheduleServiceArgs方法，它其实就是Service所属进程的ApplicationThread对象在AMS端的一个远程代理对象，也就是ApplicationThreadProxy，通过binder通信，它最终会回调到Service所属进程的ApplicationThread的scheduleServiceArgs中：

    private class ApplicationThread extends ApplicationThreadNative {

        public final void scheduleServiceArgs(IBinder token, boolean taskRemoved, int startId,
            int flags ,Intent args) {
            ServiceArgsData s = new ServiceArgsData();
            s.token = token;
            s.taskRemoved = taskRemoved;
            s.startId = startId;
            s.flags = flags;
            s.args = args;
            sendMessage(H.SERVICE_ARGS, s);
        }
   }

sendMessage函数会通过ActivityThread内部的mH对象发送消息到主线程当中，mH实际上是一个Handler的子类，在它的handleMessage回调中，处理H.SERVICE_ARGS这条消息：


在handleServiceArgs方法，就会从mServices去查找对应的Service，调用我们熟悉的onStartCommand方法，至于Service对象是如何被加入到mServices中的，我们在2.2节中进行分析。

    private void handleServiceArgs(ServiceArgsData data) {
        Service s = mServices.get(data.token);
        if (s != null) {
            try {
                if (data.args != null) {
                    data.args.setExtrasClassLoader(s.getClassLoader());
                    data.args.prepareToEnterProcess();
                }
                int res;
                if (!data.taskRemoved) {
                    //调用 onStartCommand 方法。
                    res = s.onStartCommand(data.args, data.flags, data.startId);
                } else {
                    s.onTaskRemoved(data.args);
                    res = Service.START_TASK_REMOVED_COMPLETE;
                }

                QueuedWork.waitToFinish();

                try {
                    //通知AMS启动完成。
                    ActivityManagerNative.getDefault().serviceDoneExecuting(
                            data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
                } catch (RemoteException e) {
                    // nothing to do.
                }
                ensureJitEnabled();
            } catch (Exception e) {
                if (!mInstrumentation.onException(s, e)) {
                    throw new RuntimeException(
                            "Unable to start service " + s
                            + " with " + data.args + ": " + e.toString(), e);
                }
            }
        }
    }

这里面，我们会取得onStartCommand的返回值，再通过Binder将该返回值传回到AMS端，在AMS的mServices的serviceDoneExecutingLocked中，会根据该返回值来修改ServiceRecord的属性，这也就是我们常说的onStartCommand方法的返回值，会影响到该Services之后的一些行为的原因，关于这些返回值之间的差别，可以查看Service.java的注释，也可以查看网上的一些教程：

2.2 进程已经存在，但是 Service 没有启动

下面，我们来看Service没有启动的情况，这里会调用realStartServiceLocked方法：

    private final void realStartServiceLocked(ServiceRecord r,
            ProcessRecord app, boolean execInFg) throws RemoteException {
        if (app.thread == null) {
            throw new RemoteException();
        }
        if (DEBUG_MU)
            Slog.v(TAG_MU, "realStartServiceLocked, ServiceRecord.uid = " + r.appInfo.uid
                    + ", ProcessRecord.uid = " + app.uid);
        r.app = app;
        r.restartTime = r.lastActivity = SystemClock.uptimeMillis();

        final boolean newService = app.services.add(r);
        bumpServiceExecutingLocked(r, execInFg, "create");
        //更新Service所在进程的oom_adj值。
        mAm.updateLruProcessLocked(app, false, null);
        mAm.updateOomAdjLocked();

        boolean created = false;
        try {
            if (LOG_SERVICE_START_STOP) {
                String nameTerm;
                int lastPeriod = r.shortName.lastIndexOf('.');
                nameTerm = lastPeriod >= 0 ? r.shortName.substring(lastPeriod) : r.shortName;
                EventLogTags.writeAmCreateService(
                        r.userId, System.identityHashCode(r), nameTerm, r.app.uid, r.app.pid);
            }
            synchronized (r.stats.getBatteryStats()) {
                r.stats.startLaunchedLocked();
            }
            mAm.ensurePackageDexOpt(r.serviceInfo.packageName);
            app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
            //通知应用端创建Service对象。
            app.thread.scheduleCreateService(r, r.serviceInfo,
                    mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                    app.repProcState);
            r.postNotification();
            created = true;
        } catch (DeadObjectException e) {
            Slog.w(TAG, "Application dead when creating service " + r);
            mAm.appDiedLocked(app);
            throw e;
        } finally {
            if (!created) {
                final boolean inDestroying = mDestroyingServices.contains(r);
                serviceDoneExecutingLocked(r, inDestroying, inDestroying);
                if (newService) {
                    app.services.remove(r);
                    r.app = null;
                }
                if (!inDestroying) {
                    scheduleServiceRestartLocked(r, false);
                }
            }
        }
        //这里面会遍历 ServiceRecord.bindings 列表，因为我们这里是用startService方式启动的，因此该列表为空，什么也不会调用。
        requestServiceBindingsLocked(r, execInFg);

        updateServiceClientActivitiesLocked(app, null, true);

        if (r.startRequested && r.callStart && r.pendingStarts.size() == 0) {
            r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                    null, null));
        }
        //这个在第一种情况中分析过了，会调用 onStartCommand 方法。
        sendServiceArgsLocked(r, execInFg, true);

        if (r.delayed) {
            if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (new proc): " + r);
            getServiceMap(r.userId).mDelayedStartList.remove(r);
            r.delayed = false;
        }

        if (r.delayedStop) {
            // Oh and hey we've already been asked to stop!
            r.delayedStop = false;
            if (r.startRequested) {
                if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE,
                        "Applying delayed stop (from start): " + r);
                stopServiceLocked(r);
            }
        }
    }

这段逻辑，有三个地方需要注意：

  • app.thread.scheduleCreateService：通过这里会在应用进程创建Service对象
  • requestServiceBindingsLocked：如果是通过bindService方式启动的，那么会去调用它的onBind方法。
  • sendServiceArgsLocked：正如2.1节中所分析，这里最终会触发应用进程的Service的onStartCommand方法被调用。

第二点由于我们今天分析的是startService的方式，所以不用在意，而第三点我们之前已经分析过了。所以我们主要关注app.thread.scheduleCreateService这一句，和2.1中的过程类似，它会回调到H中的下面这个消息处理分支当中：


具体的handleCreateService的处理逻辑如下图所示：

    private void handleCreateService(CreateServiceData data) {
        // If we are getting ready to gc after going to the background, well
        // we are back active so skip it.
        unscheduleGcIdler();

        LoadedApk packageInfo = getPackageInfoNoCheck(
                data.info.applicationInfo, data.compatInfo);
        Service service = null;
        try {
            //根据Service的名字，动态的加载该Service类。
            java.lang.ClassLoader cl = packageInfo.getClassLoader();
            service = (Service) cl.loadClass(data.info.name).newInstance();
        } catch (Exception e) {
            if (!mInstrumentation.onException(service, e)) {
                throw new RuntimeException(
                    "Unable to instantiate service " + data.info.name
                    + ": " + e.toString(), e);
            }
        }

        try {
            if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
            //1.创建ContextImpl对象。
            ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
            //2.将 Service 作为它的成员变量 mOuterContext 。
            context.setOuterContext(service);
            //3.创建Application对象，如果已经创建那么直接返回，否则先调用Application的onCreate方法。
            Application app = packageInfo.makeApplication(false, mInstrumentation);
            //4.调用attach方法，将ContextImpl作为它的成员变量mBase。
            service.attach(context, this, data.info.name, data.token, app,
                    ActivityManagerNative.getDefault());
            //5.调用Service的onCreate方法。
            service.onCreate();
            //6.将该Service对象缓存起来。
            mServices.put(data.token, service);
            try {
                ActivityManagerNative.getDefault().serviceDoneExecuting(
                        data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
            } catch (RemoteException e) {
                // nothing to do.
            }
        } catch (Exception e) {
            if (!mInstrumentation.onException(service, e)) {
                throw new RuntimeException(
                    "Unable to create service " + data.info.name
                    + ": " + e.toString(), e);
            }
        }
    }

以上的逻辑分为以下几个部分：

  • 根据Service的名字，通过ClassLoader加载该类，并生成一个Service实例。
  • 创建一个新的ContextImpl对象，并将第一步中创建的Service实例作为它的mOuterContext变量。
  • 创建Application对象，这里会先判断当前进程所对应的Application对象是否已经创建，如果已经创建，那么就直接返回，否则会先创建它，并依次调用它的attachBaseContext(Context context)和onCreate()方法。
  • 调用Service的attach方法，初始化成员变量。
  • 调用Service的onCreate()方法。
  • 将该Service通过token作为key，缓存在mServices列表当中，之后Service生命周期的回调，都依赖于该列表。

2.3 进程不存在的情况

在这种情况下，Service自然也不会存在，我们会走到mAm.startProcessLocked的逻辑，这里会去启动Service所在的进程，它究竟是怎么启动的我们先不去细看，只需要知道它是这个目的就可以了，此外，还需要注意的是它将该ServiceRecord加入到了mPendingServices中。

对于Service所在的进程，它的入口函数为ActivityThread的main()方法，在main方法中，会创建一个ApplicationThread对象，并调用它的attach方法：


而在attach方法中，会调用到AMS的attachApplication方法：

在attachApplication方法中，又会去调用内部的attachApplicationLocked：

这里面的逻辑比较长，我们只需要关注下面这句，我们又看到了熟悉的mServices对象：

在ActiveServices中的该方法中，就会去遍历前面谈到的mPendingServices列表，再依次调用realStartServiceLocked方法，至于这个方法做了什么，大家可以回到前面的2.2节去看，这里就不再重复分析了。

三、小结

以上就是startService的整个流程，bindService也是类似一个调用过程，其过程并不复杂，本质上还是 Framework 源码解析知识梳理(1) - 应用进程与 AMS 的通信实现 所谈到的通信过程，我们所需要学习的是AMS端和Service所在的应用进程对于Service是如何管理的。

系统当中的所有Service都是通过AMS的mServices变量，也就是ActiveServices类来进行管理的，并且每一个应用进程中的Service都会在AMS端会对应一个ServiceRecord对象，ServiceRecord中维护了应用进程中的Service对象所需要的状态信息。

并且，无论我们调用多少次startService方法，在应用进程侧都会只存在一个Service的实例，它被存储到ActivityThread的ArrayMap类型的mServices变量当中。

更多文章，欢迎访问我的 Android 知识梳理系列：

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

推荐阅读更多精彩内容