在大约两年前，我为入坑播客制作的新人们写下了 《播客制作入门指南》一文，希望可以帮助新人主播快速跨过上手播客必要的技术门槛，更轻松地录制自己的节目。在过去的两年中，中文播客进入了快速增长期，大量新节目和新人主播如雨后春笋般出现在播客圈，这份指南在主播群体里广泛传阅，时常被一些播客群和播客活动提及。

不过，指南中的一些内容不够完善，还有部分内容随着环境的变化而显得不合时宜。因此，我决定调整和升级指南中的内容，保留基础框架的同时引入更适合当下播客创作的技巧和心得。这份指南依旧以「降低播客入门门槛」为初衷，希望它能让你的「第〇期」录起来更简单。

• 关联收听：《 一派·Podcast｜「鞋底播客」突围指南》

一、选题和准备

如果你希望自己的播客能够长期、稳定地获得听众，并形成良性传播，选择一个相对明确的播客主题非常重要。直白的主题能让听众对你的节目内容有一个大致的预期，也便于听众之间相互推荐时可以一句话说清楚你的节目在讲什么。相反，如果你的节目什么都聊，其他人也很难迅速判断你的节目是否值得订阅。

如果你不太确定节目想聊什么，可以想想到底是什么东西激发了你的表达欲，然后从这个灵感开始。我建议你选择自己了解或有兴趣长期钻研的话题。当你谈论自己熟悉的领域时，肯定更容易形成有价值的观点，对某个领域的长期兴趣也能支持你把节目持续做下去，避免「更了三期就开始放鸽子」的情况出现。

• 关联收听：《 一派·Podcast｜给新手主播的三个问题》

有了选题，你需要确定播客名称，并准备一句节目介绍，还需要确定节目 logo 并制作封面图。封面图的尺寸以大于 2000 x 2000 为佳，3000 x 3000 更好。

二、录音

设备的选择

在正式购买录音设备之前，我建议你先使用手机或电脑试录你的第〇期内容。你可以借助这个过程先行了解做播客的流程，顺带测试你的录音环境是否达标。较新款的旗舰和手机都配备了不错的麦克风，即使未来你购买了更专业的录音设备，手机或电脑自带麦克风的录音质量依然可以拿来应急。

在熟悉基本流程后，你就可以考虑购入自己的录音设备了。市面上的相关产品很多，产品推荐类的影片、文章也有不少。总体来说，做播客需要用到麦克风、录音机和监听耳机。

常见的消费级麦克风分为动圈和电容两类。抛开原理不谈，两类麦克风的主要区别在于收音特点不同——动圈麦克风相对不敏感，多以定向麦为主，非常适合多人录制时每位主播各拿一个收声，或者在有底噪的环境里录音；电容麦克风比较灵敏，能收录很多声音细节，适合单人录音或录制乐器等。

目前，多数多人节目都使用动圈麦克风录制，得益于动圈麦不敏感的特点，每个主播都可以把自己的声音单独录成一轨，便于后期剪辑。

有些带有 USB 接口的麦克风可以直连电脑，使用电脑上的录音软体就能录音。还有一些则使用 XLR 接口，它们不能直接插在电脑上，有两种方案可以完成转接：一是使用音频介面（Audio Interface），二是使用 XLR to USB 转接线。

两者本质上都是转接器，只是功能复杂度略有不同。音频介面在国内电商平台常被称为「声卡」，除了能让你的电脑连上 XLR 设备，它们通常还可以调节音量、外接监听耳机等。XLR to USB 转接线则和你用过的其它转接线没什么大区别——一头是 XLR 接口，另一头是 USB 接口。

录音也不一定要用电脑，市面上还有大量的专业录音机，它们可以直连 XLR 麦克风，还能插入存储卡以保存录音。Zoom 的经典产品 Zoom H6 就是其中代表，它也是被播客主播使用最多的录音机。录音机功能单一，稳定性高，不会出现电脑常见的「节目录到一半，录音应用闪退了」等情况，而且外出录音会比带着电脑方便很多，如果有预算的话完全应该购买。

除了收音设备，我还建议你准备一个监听耳机。这个耳机既可以是你日常在用的普通耳机，也可以购买专用的监听耳机（如 SONY 经典型号 7506）。但请注意，一定要用有线耳机来做监听，无线耳机都有延迟，对监听效果影响很大。

监听耳机的作用有二，其一是帮你实时确认话筒运作是否正常，避免录音事故；其二是把你说的内容实时反馈到耳内，让你的思路更清晰。你一定要经历过一次录音，才能深切体会到「我靠我当时都他妈在说什么啊」是一种怎样的体验，这也是返听很重要的原因所在。

录音环境

无论后期处理能力如何强大，都不如前期录音环境的小小改善。请确保录音环境安静且尽可能没有回音。对于家里比较空旷而回音较大的主播而言，「用被子把自己裹起来，躲在被子里录音」是一个成本很低却效果很好的录音方式，许多职业主播甚至也在采用这种方法录音。当然，如果你有条件改造录音环境，也可以在家里贴上吸音棉，或为自己专门设置一块封闭、独立的录音区域。

租借场地是另外一个提升录音环境的好办法。租借场地有两种方案，其一是专门租用为播客主播提供的录音间，在国内的部分地区已经有相关从业者（譬如老袁的播客公社、小宇宙等）为主播们提供场地支持，这些场地通常都准备好了录音设备，你只要去到现场张嘴说话即可；其二是租用自习室，自习室是近几年在国内流行起来的公共空间，部分自习室提供会议室（或洽谈室）甚至直播室，其室内经过消音改造，同样适合播客录制。《一派·Podcast》的这期节目就是在深圳的一个洽谈室内录制的。

当前市面上有很多通过机器学习和算法来改善录音质量的工具，这些工具在某些场景下确实可以做得不错，但终究不能从本质上改变声音档案的质量。它们可以作为你在录音或剪辑中的辅助工具，但录音环境的重要性无可替代。

录音的流程

播客录音通常分为线下录音和线上录音，两种录音方式各有一套截然不同的工作流，需要面对的问题也不尽相同。

最简单的是单人录音，只需要找个安静的地方直接对着麦克风说话就行。单口节目考验得更多的是主播本人的表达能力和观点输出，如果哪些段落聊得不够好还可以反复录制和剪辑，后期空间很大。

比较麻烦的是需要多人参与且采用线下录音的节目，推荐使用动圈麦克风进行录音。动圈麦克风的特点是收音集中且对环境音的敏感度较低，所以当多人一起聊天时，每个人的麦克风都不会收录其他人的声音。你需要将每个人说的话单独录成一轨，这样做的好处是后期剪辑时如果遇到抢话、说错话等情况，可以分轨处理，让剪辑更容易。

线上录音更为复杂，主要难点在于你要确保参与节目的其他人也处在安静的环境中，并且他们的录音设备没有问题。线上录音通常采用「multi-ender」的方式，即每个人都准备两部设备，一部用于语音通话（譬如使用 Zoom、Skype 或微信语音），另外一部则用来录制自己的声音。当在线谈话结束后，大家都将自己的录音统一汇总给负责剪辑的人，由他合并和后期处理。

《 博物志》主播于婉莹曾手绘过一幅录音过程示意图，你也可以参考其中要点——准备两部设备，一部用于通话，另一部用于录音；两部设备都要开启静音或飞行模式，避免打扰；如果用手机录音，记得垫高手机，让麦克风尽量靠近你的嘴。

录音中记得关闭手机或开启勿扰模式，尤其在线录音，很有可能突然被电话打断。如果录音真的被打断了也不要紧，所有人都不要停止录音，处理好问题后继续开录就行。

录音结束后，所有参与者要通过网盘等工具把各自的录音文件汇总至剪辑者手中，便于对方后期剪辑。

录音时的注意事项

对于新人主播而言，在录音的过程中逐渐学会「完整保留一句话」非常重要，即当某个地方说错的时候，立即将这句话的正确版本完整地重复一遍。没有经验的主播常常会在说错某个词之后直接从正确的地方说下去，这样会导致后期剪辑不便——如果出错的地方恰好是某个词中间，就有可能出现「说错的地方需要剪掉，说对的内容又不完整」的情况。因此，重复一整句话是更稳妥的办法。

婉莹还推荐过一个治口癖的好方法：在便利贴把自己常说的口癖贴在看得见的地方，用来提醒自己。每当自己录音时说到词汇，就把立刻把这句话去掉口癖重说一遍。

如果你的节目有嘉宾，记得在录音时提醒对方不要乱动。许多人在讲话时会不自觉地离麦克风越来越远，或者搓腿、跺脚、挠头等，这些动作都会影响录音质量且完全无法修复。如果嘉宾说话时出现以上状况，可以及时提醒对方，并让他把话重复一遍。

总而言之，你可以把播客视为综艺节目，节目的效果由前期素材和后期剪辑共同决定。不要害怕在录音时犯错或重复，因为听众最终听到的都会是剪辑后的版本。

• 关于录音流程的细节，这期《 播客这门手艺，想学好还是得上点儿心》中有更详细的分享

三、剪辑

剪辑通常分为两个部分，分别是内容剪辑和音效调整。

内容剪辑指通过各种技术手段修改和调整音档内容的过程，最常见的就是去除录音中的「嗯」、「啊」、空白、口误等部分，让表达更加流畅。这个步骤相对比较机械，基本就是在重复「切断——删除——拼合」的过程。

音效调整指对声音的质量和效果进行修改，最常见的是降噪、去回声、调整 EQ、压限等、音量均衡等。

通常来说，剪辑的第一步都是降噪。无论你的录音环境如何，降噪都可以让人声更清晰。最常用的免费降噪工具是 Audacity，它同时支援 Windows 和 Mac 平台。Audacity 同时还能完成去回声的工作，如果你录音的环境比较空旷，可以一试。

Adobe Audition 用户可以使用自带的降噪功能。其原理和 Audacity 一样，都需要先截取一段背景噪音，然后软体会自动生成一个反向声波，贯穿整条音轨，把噪声抵消掉。Bose、SONY 等厂牌旗下的主动降噪耳机采用的也是这个原理。

进阶方案是购买 iZotope 出品的 RX 8 系列插件，插件内包含了降噪、去回声、去破音等常用功能，并使用机器学习算法来处理声音。从效果上来说，iZotope RX 8 的降噪远超其它方案。此外，类似 RX 8 等第三方插件可以与 Garageband、Logic Pro X、Adobe Audion 等任何音频处理软件配合使用，不受平台及工具的限制。

在输出音频前，记得做一次音量均衡，这个过程可以让节目中每一轨的音量都保持同样大小，避免出现「主持人声音好大，但嘉宾声音听不见」的情况。 音量平衡通常使用 LUFS 作为音量单位，它衡量的是一段声音的平均响度（而你更熟悉的音量单位分贝（dB）衡量的则是瞬间响度）。因此，LUFS 更能代表一条音轨的整体音量大小。

不同的剪辑工具内调整 LUFS 的方式也各有不同，无法一概而论（其中一些还需要加载第三方插件才能实现）。如果你想了解更多信息，可以将自己在用的工具加上 LUFS 作为关键字，搜索相关教程（譬如「Logic Pro X + LUFS」）。在诸多剪辑工具中，Reaper 调整 LUFS 的方式最简单，挂载 SWS Extension 后就能在应用内直接修改，我就设置了「Command + Shift + L」一键将所选音轨调整至 -16 LUFS 的快捷键。

• 影视飓风的 Tim 在这期影片里也提及了 LUFS 的使用

所有调整完毕后，输出声音文件（Render）即可。一般来说，128 Kbps 的 mp3 格式文件就能满足谈话类节目的音质要求，但你也可以根据各托管平台对文件体积的限制来调整输出文件的解析度。只要平台不限，音质当然越高越好。

四、放送

有了制作好的声音文件，接下来就要把它发布出去了。在这个环节，你要先选择一家托管服务商上传你的音档，然后再把它发布到 Apple、Google、Spotify 等平台。这个过程类似你把某个文件上传至百度网盘，然后给其他人网盘链接，对方点击链接就能获得你要分享的内容。

目前，国内播客常用的播客托管服务商为 Fireside、Typlog、Anchor 和喜马拉雅等。Fireside 在大陆地区访问速度不佳，Anchor 据说有无法访问的问题，需要留意。少数派旗下的播客节目都在两个月前从 Fireside 迁移到了 Typlog。

• 关联阅读：《 功能全、价格低、操作简单，它是个人建站和播客创作的新选择》

注意，上传（托管）和发布其实是两件事，但国内的播客平台（如喜马拉雅等）将这两件事合并成了一件，即当你把音档传至喜马拉雅的同时，节目也就在喜马拉雅平台发布了。但对于 Apple 等通用平台，你需要另外找一个地方托管音档，并把它提交给 Apple，听众们才能看到你的节目。

所有泛用性播客平台——如 Pocket Casts、Overcast、Castro 等——都是通过抓取 Apple Podcast 的节目数据库来完成搜索和订阅的。关于 Apple Podcast 与泛用性播客客户端的关系，建议收听 这期节目了解其原理。

大陆地区上架播客还需要面对 Apple Podcast 中国区审核的问题，我派作者 甜食已经撰写了一篇非常详尽的 中国区播客上架指导，这是目前为止关于该主题结论最明确（甚至唯一给出准确解答）的文章，建议阅读。

将你的播客节目发布至 Apple Podcast、Google Podcast 和 Spotify 的地址分别是 这里、 这里和 这里。

五、运营

走到这一步，恭喜你的新节目开播啦。但一切到这里还没有结束，如果你希望节目能长久地做下去，就要为之后的用户运营做好准备。

微博、微信公众号、Twitter、Telegram 等是各播客栏目常用的社交平台，你可以在这些平台发布节目预告、更新通知等重要讯息，便于听众们及时了解节目动态。不过，对于前期听众较少的节目来说，着重经营一两个渠道是更高效的方案。运营社交媒体的核心目的是让你的听众有一个「落脚点」，让大家可以第一时间了解到你的节目动态。因此，你不需要在一开始就遍地开花，投入大量精力经营多个社交媒体。

或许你还需要准备一个听众群，吸纳更多的听众交流互动，至于选择微信、Telegram 还是 Slack，就完全取决于你的判断啦。和社交媒体一样，经营听众群也需要投入大量时间，在建群之前，你要考虑清楚自己的节目是不是真的需要让听众聚在一个群里闲聊，以及听众群对你的节目增长是否真的有意义。

别忘了准备一个邮箱，接收听众来信。

• 拓展阅读：《 做了播客却没听众？这些推广和运营心得值得你尝试》

六、总结

以上就是从零开始做播客的要点咯。这篇文章中没有涉及更深入的技术问题，当你已经渡过了入门期之后，一定会渐渐摸到播客制作的门道和更多技巧。祝你开播顺利，新节目开播也别忘了告诉少数派的读者们，让我们一起进步。

拓展阅读

• 《 全平台播客订阅及收听指南》
• 《 这些少数派的作者们，原来都在做播客》
• 《 新手如何从零开始一档播客》
• 《 轻芒做的这个微信小程序工具，想要帮你「看」见播客》
• 《 除了 Apple Podcast 渠道，你还能通过这些网站找到好听的中文播客》
• 《 听杨一聊播客》
• 《 无论做一档私人还是商业播客，这些数据和资讯都值得你了解》
• 《 做播客连续亏损 5 年，每聊一句话就赔 5 块钱》

> 下载 少数派 2.0 客户端、关注 少数派公众号，解锁全新阅读体验 📰

> 实用、好用的 正版软件，少数派为你呈现 🚀

当前移动端App的开发很多都需要内嵌WebView来方便业务的快速开展，特别是电商App中，业务变化快，活动多。仅仅依靠native的开发方式难以满足快速的业务发展，于是混合开发模式便出现。当前比较知名的有 Cordova, Ionic, 国内的有 Appcan, APICloud开发平台，这几种都是依赖于WebView的实现。而Facebook的 React Native和阿里的 Weex是混合开发的另一种实现， React Native和 Weex可以让原生开发者像H5开发一样写前端的代码，然后通过自己的SDK渲染成原生的组件，不依赖于 WebView。本文主要总结一下当前 WebView和native的交互方式。

Android中 WebView和 JavaScript的交互，其实就是Android native与网页中的 Javascript之间的交互, 所以搞清楚了它们之间数据是如何传递的就明白了。以下从两个方面进行介绍：

Native 向 Javascript 发送数据

Native 向 JavaScript发送数据有两种方式, 一种是 evaluateJavascript另一种是 loadUrl。区别在于 evaluateJavascript比 loadUrl更高效， evaluateJavascript在android 4.4之后才能用，该方法的执行不会使页面刷新, 而 loadUrl则会。所以通常我们如下使用：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    evaluateJavascript(jsCommand, null);
} else {
    loadUrl(jsCommand);
}
复制代码

当然，如果想要直接获得javascript代码的执行结果，我们可以这样写:

String command = "ABC";
webView.evaluateJavascript("(function() { return " + command + "; })();", new ValueCallback<String>() {
    @Override
    public void onReceiveValue(String result) {
        // 此处的result便是 ABC
    }
});
复制代码

Javascript 向 Native 发送数据

Javascript向Native发送数据有4种方式，第一种方式是借助 webChromClient中的 onJsAlert(), onJsPromot()的方法来获取Javascript相关数据。第二种方式是采用覆盖 shouldOverrideUrlLoading方法，拦截url协议。第三种是最方便的,也就是 @JavascriptInterface方案, 现在大多数App都会用到这种方式, 后面会详细介绍。最后一种是利用在 webView中嵌入 iframe的方式，通过更新 iframe的url。比较出名的混合框架 JsBridge之前就是采用这种方式，现已改成采用 @JavascriptInterface这种方式了。以下简单介绍一下各种方式的使用。

onJsPrompt

webChromeClient中提供了 onJsAlert, onJsPrompt方法，方便开发者重写Javascript中的 alert, prompt方法对应的行为。我们可以在这两个方法中任选一个做为native和js进行交互的桥梁。通常我们借助于 onJsPrompt方法来实现, 就是因为在js中，这个方法通常我们用得比较少。而对于 onJsAlert(), 当调用js中的 alert()时会触发，我们可以通过重写这个方法来实现自定义的提示View

但是这种方式对传入的数据量有限制，和手机的WebView版本有关，以我的测试机为例，在 oppo reno手机 android 10上面, 其传递数据最多只能是10k。 而用 @JavascriptInterface方案, 传递的数据最多可达20 - 30M

我们来看前端网页的写法, 直接调用 prompt函数

var data = prompt("native://getUserInfo?id=1");
console.log('data:' + data);
复制代码

在为WebView设置 WebChromeClient的时候重写 onJsPrompt方法，如下：

 @Override
public boolean onJsPrompt(WebView view, String url, String message, String defaultValue, JsPromptResult result) {
    Uri uri = Uri.parse(message);
    //如果是调nativeAPI.
    if (url.startsWith("native://")) {
        result.confirm("call natvie api success");
        return true;
    }
    return super.onJsPrompt(view, url, message, defaultValue, result);
}
复制代码

shouldOverrideUrlLoading

前端页面的Js代码：

document.location="native://getUserInfo?id=1";
复制代码

native层面在为WebView设置 WebViewClient对象时，我们需要重写 shouldOverrideUrlLoading方法。需要注意的是， WebViewClient中有两个 shouldOverrideUrlLoading方法的定义:

• public boolean shouldOverrideUrlLoading(WebView view, String url)
• public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request)

其中上面一个在sdk中已被标记 Deprecated, 下面一个是在android 7.0中才引入的，所以为了避免兼容性问题。在使用时，建议这两个方法都重写。

@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
    //如果是调nativeAPI.
    if (url.startsWith("native://")) {
        Log.i("CommonWebViewClient", "shouldOverrideUrlLoading execute------>")
        return true;
    }
    return super.shouldOverrideUrlLoading(view, url);
}
复制代码

@JavascriptInterface

在 Android 4.2以下有安全漏洞, 但目前我们的app大部份最小支持版本都已经升到5.0了，这个可以忽略，当然感兴趣可以自己搜索。

在native层面，我们需为要WebView注入一个对象，用来处理两边的数据交互。注入方式如下：

• 首先定义一个类来处理两边的交互:

public class HybridAPI {
    public static final String TAG = "HybridAPI";

    @JavascriptInterface
    public void sendToNative(final String message) {
        Log.i(TAG, "get data from js------------>" + message);

    }
}
复制代码

• 在 WebView中注入这个类的实例

HybridAPI hybridAPI = new HybridAPI();
webview.addJavascriptInterface(hybridAPI, "HybridAPI")
复制代码

在网页中直接用如下代码便可以将数据发送到native端

 HybridAPI.sendToNative('Hello');
复制代码

iframe

我们还可以利用 iframe进行请求伪造向native端发送数据的。思路是向网页中添加一个 iframe控件，通过修改其 src属性，触发native端的 shouldOverrideUrlLoading方法的执行, 同样，native端通过重写该方法，去拿到js端传过来的数据。具体操作方式如下：

var iframe = document.createElement('iframe');
iframe.style.display = 'none';
document.documentElement.appendChild(iframe);
iframe.src="native://getUserInfo?id=1";
复制代码

在操作完成后，我们再从当前的dom结构中移除这个组件。

setTimeout(function() {
    iframe && iframe.parentNode && iframe.parentNode.removeChild(iframe);
}, 100);
复制代码

具体实践

在前面总结了WebView和Native交互的几种方案。但距离实际项目使用还有一段距离，在实际项目开发中还有很多问题需要考虑。如：

• 交互的规则如何定义
• 数据如何传递
• 调用之后，如何拿到回调的结果
• 对于Javascript的请求，native端应该如何设计?
• ....

native端向JavaScript发送消息只有 loadUrl, evaluateJavascript这两种方式。Javascript向native端发送信息可以利用 onJsPrompt, @JavascriptInterface, shouldOverrideUrlLoading等几种方案，以下 我们通过采用 @JavascriptInterface这种方式(也就是大家通常说的注解方案)为例来看看如何解决实际项目开发中碰到的问题。

交互的规则

首先我们来定义两端的交互规则。

Javascript向native发数据：

我们约定在H5中采用 HybridAPI.sendToNative方法向native端发送数据，于是我们需要在native端做如下支持：

• 定义一个 HybridAPI类，并向WebView中注册

HybridAPI hybridAPI = new HybridAPI(this);
webview.addJavascriptInterface(hybridAPI, "HybridAPI");
复制代码

• 在 HybridAPI类中定义一个方法 sendToNative, 该方法暴露给Javascript用来给native发送数据

@JavascriptInterface
public void sendToNative(final String message) {
    Log.i(TAG, "get data from js------------>" + message);

}
复制代码

native层向Javascript发数据：

public final String TO_JAVASCRIPT_PREFIX = "javascript:HybridAPI.onReceiveData('%s')";

public void sendToJavaScript(Map message) {
    String str = new Gson().toJson(message);
    final String jsCommand = String.format(TO_JAVASCRIPT_PREFIX, escapeString(str));

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
        evaluateJavascript(jsCommand, null);
    } else {
        loadUrl(jsCommand);
    }
}
复制代码

在H5中，我们这样写, 当native向Javascript发送数据时，便会触发Javascript中的 Hybrid.onReceiveData方法, 该方法就能接收到native层传过来的数据

HybridAPI.onReceiveData = function(message) {
    console.log('[response from native]' + message);
}
复制代码

数据结构的定义

在上面我们已经基于 @JavascriptInterface方案完成了native与WebView间通信机制的实现，双方可以交换数据，但开发的时候需要考虑更多问题。比如，如果是Javascript向native发送数据，需要将数据转换成一个字符串，然后再将字符串发给native, native再去解析这个字符串，找到对应的处理方法，提取出相关的业务参数，再进行相应的处理。所以我们需要定义这个字符串的数据结构。

在上面我们已经约定了，H5端可以采用 HybridAPI.sendToNative向native发送数据，该方法只有一个字符串参数, 以 获取用户信息这个业务功能为例，我们的字符串参数是 native://getUserInfo?id=1，这个字符串中的 getUserInfo表示当前通信的目的或行为(为了拿用户信息)， ?后面的 id=1表示的是参数（用户id为1), 如果参数多了，这个字符串会更长，再如果上面涉及到中文的转码，其可读性会大大降低，所以这种交互方式不够直观和友好，我们期望用户采用下面这个方法去与native通信:

HybridAPI.invoke(methodName, params, callbackFun)

• methodName: 当前通信的行为
• params: 传递的参数
• callbackFun: 接收native端的返回数据

于是，我们在js层面进行一层的封装

var callbackId = 0;
var callbackFunList = {}
HybridAPI.invoke = function(method, params, callbackFun) {
    var message = {
        method,
        params
    }
    if (callbackFun) {
        callbackId  = callbackId + 1;
        message.id = 'Hybrid_CB_' + callbackId;
        callbackFunList[callbackId] = callbackFun
    }
    HybridAPI.sendToNative(JSON.stringify(message));
}
复制代码

最终还是调用的是 sendToNative与native层进行通信，但是采用 HybridAPI.invoke方法对开发者更加友好。

由于需要在执行成功后调用回调函数。为此在发送消息的时候先把 callbackFun保存起来，在执行成功后再响应。 当Javascript请求发送到native层时，会触发 sendToNative方法，在该方法中, 我们来解析前端的数据：

@JavascriptInterface
public void sendToNative(final String message) {
    JSONObject object = DataUtil.str2JSONObject(message);
    if (object == null) {
        return;
    }
    final String callbackId = DataUtil.getStrInJSONObject(object, "id");
    final String method = DataUtil.getStrInJSONObject(object, "method");
    final String params = DataUtil.getStrInJSONObject(object, "params");

    handleAPI(method, params, callbackId);
}

private void handleAPI(String method, String params, String callbackId)  {
    if ("getDeviceInfo".equals(method)) {
        getDeviceInfo();
    } else if ("getUserInfo".equals(method)) {
        getUserInfo();
    } else if ('login'.equals(method)) {
        login();
    }
    ....
}
复制代码

native端在处理完成后，再调用 evaluateJavascript或 loadUrl方法，反馈给前端。操作流程示例：

//指定了js端的接收入口 
public final String TO_JAVASCRIPT_PREFIX = "javascript:HybridAPI.onReceiveData('%s')";


public void callJs() {
    Map responseData = new HashMap<>();
    responseData.put("error", error);
    responseData.put("data", result);
    //回调函数的id标识，返回给js,这样才能找到对应的回调函数
    responseData.put("id", callbackId);
    sendToJavaScript(responseData);
}

public void sendToJavaScript(Map message) {
    String str = new Gson().toJson(message);
    final String jsCommand = String.format(TO_JAVASCRIPT_PREFIX, escapeString(str));

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
        evaluateJavascript(jsCommand, null);
    } else {
        loadUrl(jsCommand);
    }
}

// 转义
private String escapeString(String javascript) {
    String result;
    result = javascript.replace("\\", "\\\\");
    result = result.replace("\"", "\\\"");
    result = result.replace("\'", "\\\'");
    result = result.replace("\n", "\\n");
    result = result.replace("\r", "\\r");
    result = result.replace("\f", "\\f");
    return result;
}
复制代码

在上面的 callJs方法中组织好相关的数据，然后利用 Gson进行序列化，再转进行字符串的转义，最终调用 evaluateJavascript或者 loadUrl来传递给js。于是js端便可以利用 HybridAPI.onReceiveData来接收到。

还记得这段代码中定义的 callbackFunList吗？在上面native给js返回数据的时候，会带上一个 id, 我们可以根据这个id找到本次通信的回调函数，然后将数据回调过去。

var callbackId = 0;
var callbackFunList = {} //看这里
HybridAPI.invoke = function(method, params, callbackFun) {
   var message = {
       method,
      params
   }
   if (callbackFun) {
       callbackId  = callbackId + 1;
       message.id = 'Hybrid_CB_' + callbackId;
       callbackFunList[callbackId] = callbackFun
   }
   HybridAPI.sendToNative(JSON.stringify(message));
}
复制代码

所以，我们js端接收数据，可能是这样子：

HybridAPI.onReceiveData = function(message) {
    var callbackFun = this.callbackFunList[message.id];
    if (callbackFun) {
      callbackFun(message.error || null, message.data);
    }
    delete this.callbackFunList[message.id];
}
复制代码

再回到我们上面的 获取用户信息这个业务功能，我们的写法就会是这样子了：

HybridAPI.invoke('getUserInfo', {"id": "1"}, function(error, data) {
    if (error) {
        console.log('获取用户信息失败');
    } else {
        console.log('username:' + data.username + ', age:' + data.age);
    }
});
复制代码

至此，我们就将一具完整的数据通信流程实现了，由js端用 HybridAPI.invoke(method, params, callbackFun)来向native端来发送数据，native处理完毕后，js端通过 callbackFun来接收数据。

改进

在上面的java代码中，我们可以看到，native层的入口是 sendToNative方法，该方法中解析传入的字符串，再交给 handleAPI方法来处理

@JavascriptInterface
public void sendToNative(final String message) {
    JSONObject object = DataUtil.str2JSONObject(message);
    if (object == null) {
        return;
    }
    final String callbackId = DataUtil.getStrInJSONObject(object, "id");
    final String method = DataUtil.getStrInJSONObject(object, "method");
    final String params = DataUtil.getStrInJSONObject(object, "params");

    handleAPI(method, params, callbackId);
}

private void handleAPI(String method, String params, String callbackId)  {
    if ("getDeviceInfo".equals(method)) {
        getDeviceInfo();
    } else if ("getUserInfo".equals(method)) {
        getUserInfo();
    } else if ('login'.equals(method)) {
        login();
    }
    ....
}
复制代码

我们会发现，随着业务的发展，项目的迭代，js端可能会需要native提供越来越多的能力，所以我们的 handleAPI方法中就会有越来越多的 if...else if...了。

于是，我们可以按业务来划分，新建一个 UserController类来处理 getUserInfo, login, logout这种与用户相关的native 接口。新建一个 DeviceController来处理类似于 getDeviceInfo, getDeviceXXX,... 等与设备信息相关的接口。然后我们再维护一个controller list, 每次调用js api的时候从这个list里面去找对应的 controller中的方法处理。

这样，就可以把具体的业务处理方法抽取出来。然而即便这样，还是避免不了在每个Controller中去写一段这个 if...else if ...这种代码。于是，其实我们可以很自然的想到用反射来做点事。

我们和H5开发约定好了，如果需要获取用户的信息，就调用 getUserInfo方法，这个方法名始终不变。同时，我们在Java端这样定义 UserController:

public class UserController implements IController{

    private volatile static UserController instance;
    private UserController() {}

    public static UserController getInstance() {
        if (instance == null) {
            synchronized(UserController.class) {
                if (instance == null) {
                    instance = new UserController();
                }
            }
        }
        return instance;
    }

    @APIMethod
    public UserInfo getUserInfo(Map params, String callbackId) {
        //TODO
    }

    @APIMethod
    public void login(Map params, INativeCallback callback) {
        //TODO
    }

    @APIMethod
    public boolean logout(Map params, INativeCallback callback) {
        //TODO
    }
}
复制代码

我们将该 UserController添加到上面提到的controller list中，然后我们在handleAPI方法中:

private void handleNativeAPI(String methodName,  String params, String callback) {
    for (IController controller : controllerList) {
        Method[] methods = controller.getClass().getDeclaredMethods();
        for (Method method : methods) {
            Annotation[] annotations = method.getAnnotations();
            for (Annotation annotation : annotations) {
                // 获取注解的具体类型
                Class annotationType = annotation.annotationType();
                if (method.getName().equals(methodName) &&  APIMethod.class == annotationType) {
                    try {
                        Map map = DataUtil.jsonStr2Map(params);
                        method.invoke(controller, map, callback);
                    } catch (IllegalAccessException e) {
                        e.printStackTrace();
                    } catch (InvocationTargetException e) {
                        e.printStackTrace();
                    }
                    return;
                }
            }
        }

    }
}
复制代码

后面，每当新增一个交互的方法时，我们只需要在对应的java类中写一个方法，并用 @APIMethod标识就可以。

以上我们总结了WebView与native通信的几种方式，并结合具体实践给出相应的实现思路，当然因为篇幅原因，这里并没有面面俱到。比如：

• 如何实现H5端监听native端的某个事件的功能？
• H5端监听native事件后，进行相应的操作，如何将操作的结果再返给native?
• 如果js端调了一个不存的native的方法，应该如何处理？
• ...

如果仔细理解了前面介绍的两端通信方式，实现上面的这些功能应该不是问题。但如果想把代码更好的封装，使开发者用起来更舒服，那就需要下一点功夫了。

  本文9100字，向内看，多听批判的话。

这是智远的第0150篇成长笔记的分享。

01

以偏概全的心智模式

02

基本归因处理法

基本归因分为正确，错误两个方面，科普中国百科定义为人们在考察某些行为或后果的原因时高估倾向性因素，低估情景因素，譬如谴责或赞美他人的双重倾向（Lee Ross, 1977）。

定义是不是有点复杂？那么我们简单理解：

我把它解释为 “你对事件原因”的判断，生活中多数用到的是对自己成功或失败的归因，但除这些外别人的行为也可能成为我们归因的目标。

为什么会有归因偏差？

先带你做看一个简单实验，请你想象下这种场景，你在马路上开车遇到红绿灯等待，刚好红灯转绿，正准备启动的同时突然从后方出来一辆摩托车，抢到你前面，吓得自己出一身冷汗。

这种情况你会有什么反应？大多数人肯定愤怒的内里说出了脏话，此时你对那位司机印象以及行为极度不满，并在内心给他贴上一系列标签，譬如“行事莽撞”“安全意识差”“不考虑别人”等。

虽然你可能还没有见过此人，但在内心已经做出基础判断，不过现实中，一辆车横冲而过必有其原因，可能司机的确鲁莽，但也可能是因为有急事处理，比如“要去医院”。

更多可能性却让我们忽略掉，最终把原因归属到对方这个“人”身上，这种倾向心理学就是 “基本归因错误”。

日常中各种现象你也会遇到，譬如工作中销售业绩不佳时，领导更倾向于将其原因归属于下属的懒惰而不是竞争对手的实力太强。

譬如我的眼睛天生有色弱缺陷，看红绿灯没问题，对浅红和浅绿分不清，但我家人从来都不让我开车，一是为了安全， 其次就有极大的“归因错误”，不能因为某件事的判定而直接决定整体。

归因错误的核心在于人是“认知经济学家”不是“朴素心理学家”，而这一切就好比经济学总是假设“民众都是最严格的经济动物”这个观念是错误的一样。

心理学以前也出现过假设大家都是“朴素心理学家”的观点，即普通人也会用心去观察并分析人们解释问题，分析成功原因时，着重分析出哪些因素，并研究其中的道理。

然而并不一定所有人都是认知经济学家，因为人的大脑本能总是懒惰的，谁愿意去思考那么多，挑就近原理， 容易的不好去决策不好吗？

譬如， 这种场景你上学时或许遇到过：

三长两短选最短，三短一长选最长，两长两短就选B，同长同短就选A，长短不一选择D，参差不齐就选C，以抄为主，以懵为辅，抄辅结合，定能及格。

现在想想这是不是一种荒谬的“归因偏差”，所以归根到底偏差的核心在于懒得思考，脑中逮住旧有认知就转移成为了语言，却不知道其原认知接受的信息是否有“依据”，是否正确，最后机会产生“晕轮效应”发生。

为什么第一信息很重要？

墨菲定律中有这样一则故事，1974年，希伯来大学心理学教授卡纳曼和特沃斯基做了一个实验。

实验要求志愿者对非洲国家在联合国所占席位的百分百进行评估，首先他们随机给出每组志愿者一个百分比数字，然后他们逐个暗示志愿者真实数字比这个大或小。

有趣的是， 志愿者最后预估出来的数字，都受到一开始随机数字的影响，比如实验中志愿者得到的实验数字分别是10%和60%，而他们最终估计出来的数字分别为25%和45%，非常接近这两组志愿者一开始得到的随机数字。

这个实验得到的结论为：

人们在决策之前，思维往往会被所得到的第一信息所影响，它就像沉入海底的锚一样，把你的思维固定在某处，从而产生先入为主的歪曲认知。

还要一个非常经典的故事，说有一家卖三明治的小店，店里有两名售货员，其中一名每个月的销售业绩都要比另外一名高，老板就觉得非常郁闷。

有一天他躲在门后观察两位销售的区别，才发现，每当顾客点餐时，一名销售员说，先生（小姐）您需要加一个鸡蛋还是两个？ 顾客经常在一和二中选择，只有不到30%的消费者选择不加。

而另一名销售员则是询问顾客，先生（小姐）你需要加鸡蛋吗？顾客的思考范围被锚定在“需要还是不需要加鸡蛋”上面，只有少数人想到加二个上面。

其实在现实生活中还有很多案例，譬如你去咖啡厅或奶茶店会被问统一问题，要大杯还是超大杯？

曾经我脱口而出要中杯，店员礼貌的告诉我：“不好意思，我们没有中杯”，他们真没有中杯吗？

其实我们熟悉的星巴克，部分门店确实只配备大杯，超大杯，但是他们为了销售额的增加，故意把“中杯给隐藏”作为锚定，从而推荐超大杯，引导你去决策。

这些种种情况告诉我们：

人的第一印象一旦形成，便会导致认知懒惰和惯性思维，那些善于利用这种心理的人，就会先发制人，所以如果是初次见面认识一位朋友，你给他提供的一手信息 （形象，颜值，穿着，谈吐）很重要。

03

大脑为什么会误判

即使我们用直尺测量这三条线，知道它们一样长，并且也了解这种环节背后的神经原理，但在我们眼中，A依然比其他两者要短些。

在比如上述这张图， 你第一直觉看到的是侧脸还是正脸的一半呢？

惯性思维肯定回答的只有“正脸或者侧脸”，而当你真正冷静下来时会发现其实是两者兼容的图片。

在经历视觉幻觉时，我们行动缓慢的但又善于分析的大脑，能够意识到缪氏错觉并说服大脑不要相信靠直观感受的结论，但现实生活中，当我们碰到活生生案例时，一切就不那么容易了， 这也就是所谓的认知偏差。

喜欢分歧与美丽困境

除视觉上的认知偏差，还有两条人际交往中的认知偏差也会让你产生“晕轮效应”，分别为 美丽困境（Beautiful mess effect）与喜欢分歧（Liking Gap）。

何为美丽困境（Beautiful mess effect）？

生活与工作中对于多数人来说，承认错误寻求帮助，甚至承认自己喜欢某个人，都是件很难开口的事情，为什么？因为暴露弱点或弱点会让人处境相对弱势，我们担心被拒绝，我们担心被拒绝后的“评判”而无颜面存在。

而现实中据资料记载研究者Anna Bruk与团队做了次试验，要求参与者想象别人和自己展示脆弱的场景，然后分别作出评价。

随后在另一项研究中，研究者设计特定场景引发参与者真实展示自己的脆弱或弱点，结果都发现，参与者对自身脆弱的评价都比别人的评价更消极，别人甚至会觉得展现自己的脆弱是一种勇敢的行为。

这就是看似矛盾的现象，虽然自己不想暴露脆弱，但我们对那些坦诚自己脆弱的人，却持有积极的态度，这也是所谓的“认知偏差”。

为什么会有这种情况呢？

“解释水平论”（construal level theory）解释了这个现象，原因是当我们思考自身脆弱时，因为对自身的了解，就会思考很多细节，使这件事暴露在外成为件格外丢脸的事情，就会使处境难看。

我们更关注细节和事情本身， 就会很少做进一步意义上的解释或本质的思考，但相反，对于别人的脆弱，我们的感性脑会更加抽象，不会停留在具体情境和行为上，还会更加抽象客观的理解事情的本质。

何为喜欢分歧（Liking Gap）？

你和别人第一次见面，如果别人特意打扮，自己并没有收拾匆匆忙忙而过去在加上不是太熟，很多人就会觉得焦虑，从而就会造成我们消极的判断，譬如：“他不会不太喜欢我把”“我刚才似乎不应该说那句话”等。

这种判断其实就出现了认知偏差，我们低估了对方对自己的判断，就会产生喜欢分歧（Liking Gap）。

研究者Erica Boothby（2018）在耶鲁大学进行试验，他们让两个同性别陌生人见面自然聊天，然后评估自己对彼此的喜爱程度，以及对方会多喜欢自己。

结果发现，他们都低估了对方对自己的喜爱，并觉得以后有机会，对方可能也不会跟我再次讲话。

其实这种现象很普遍，有人认为对方态度捉摸不定，才让我们判断错误。

但结果比较出人意料，并不是因为对方没有释放相关讯息，而是即使讯息存在，我们依然会关注那些自我批判的想法， 有偏差的关注点就会造成不准确的认知出现。

04

如何防止归因偏差

你看到一个经理在批评员工，你觉得经理有问题还是员工有问题？

如果不只是经理批评他，而是客户和其他员工也在批评他， 这就是高共识性，如果经理一般不批评员工，只批评了他， 这是特殊高共识性，若经理有事没事就批评他， 这是一致性共识性。

在上述中可得出结论，不是经理人品有问题，而确实是员工有问题。

那么情况反过来呢？

除了经理，其他人并没有批评过这个员工，这就是 共识性低，经理哪个员工都有事没事批评，这是 特殊性低，经理常常批评这个员工，也就是一致性高，那么人们会倾向于 “老板人品有问题”。

以上这种情况，若一致性低，不管共性和特殊性的高低，人们都很难做出准确归因，会产生一种不确定感，或者会选择其他外界归因，比如人们常听说的 “领导今天可能心情不好”，离他远点。

那么怎么办呢？也就有了 对应论的出现，一般思考基于三个假设：

其一：行为者预先知道一个行为的结果。

其二：行为者有能力做出此行为。

其三：行为者想要的就是这种结果。

譬如你去揭发一个人的心灵伤疤，对方恼羞成怒，这里你的行为就符合上述三个假设，我们也可以顺利归因，你就是想让他恼羞成怒。

那么如何提高自己归因的准确性呢？

其一：对应推理归因，如果一个观察者所拥有的信息越多，他对该行为所做的推论对应性就越高，也就是归因月准确。

第二：一个人行为越是异常，观察者对归因的准确性也就越大。

举个例子：你对爱人的行为判断往往比同事对他的判断要准，这是因为你对你爱人更加了解。

再比如当你老板骂你时，多数人都会做出虚心接受的样子，而这个 “虚心接受”到底是接受了还是委曲求全，其实很难从表达判断，因为你一般不会反驳老板。

但假如你马上朝老板身上泼了一杯水，这时就很明确你很生气，对他意见很大，也不在乎这个工作了。

05

360度认知事物

第三：社会期望（Expectancies）

主要分为社会阶层期望和个人期望，比如资本家与农民工，他们在任何一个人社会新闻中表现都是不同。

例如贫困家孩子被北大和一所职业专业录取了，那么他若去了北大，我们希望能改变命运便可理解，但若他去了本地专科，我们就会觉得他没钱，但如果一个中产家庭遇到这种场景，我们便无法解释了。

第四：选择自由（Choice）

行为处于自由选择，而非外力强迫，我们更倾向于认为某个行为与态度是相对应的，比如一个孩子上大学前很努力，我们很难判断他因为爱学习，还是因为家长外界释放压力。

但若他到了大学家长的外力消失了，他依然很努力，那么我们就可以归因 “他真的爱学习”。

第五：个人参与度（Personalism）

我们对被观望的对象的态度是什么？有时是因为喜欢或者讨厌，就会对他的行为有更积极或更消极的解读。

比如你和某个伙伴的关系不错，你夸她时更像赞美，但你如果和他关系不好，猛然一夸，会让人觉得你不怀好意。

基于这5个要素，我们就构建基础的“影响对推论”，你可能会觉得这样分析很有道理，不过太机械和静止看待问题。

美国心理学家伯纳德·韦纳（Bernard Weiner）也是这样认为，最后它基于上述提出 “动态三维模型”，来解释。

什么是动态三维模型？

一个人对于某些事物成败的归因，会反过来影响参与这项活动努力的程度，而一件事结果的好坏，也会加强或削弱对这件事的归因。

举个例子，我认为我能完成这个任务，是因为做过且有把握，于是我对未来完成此类任务充满信心，下次遇到你还会这样， 这就形成一个行动和想法的良性循环。

韦纳教授把这个成就归属分为三个维度，这三个维度也包含相反的一面，分别为：

第一维度：稳定性（稳定与不稳定）

第二维度：控制源（内部控制和外部控制）

第三维度：可控性（可控与不可控）

 《影响对论与动态三维》

理论总是比较抽象， 我们看一则故事：

小时候我们经常说孩子考试考的真好，有时却很差，到底什么因素会影响成绩呢？有很多，比如考试的难度，孩子努力的程度，运气等等。

现在我们进行分类归因， 有些因素是稳定的，比如考试难度和孩子智商，有些则是不稳定的，比如努力程度，考试运气等。

有些因素是内部控制源的，比如努力程度，有些是外部控制源，比如难度和运气，那么可控的是什么？依然是努力程度和考试难度， 不可控的呢？运气，智商。

所以对于一个成功者来说，理解什么是稳定，内部可控，可以帮助他接受自己的基础上增强信心，理性的进行归因。

若把不稳定外界因素，不可控因素都归因为稳定，内部及可控因素，当这些汇总结果成为正面时，会让人积极快乐，但可能会让人偏离现实，做错误的归因。

所以 “归因风格会影响一个人的动机”。

我们会发现成功者归因往往会认为能力优秀，他们觉得自己能控制进程。

若任务失败，成功者会归因于外界因素，比如团队不行，事出偶然等，你这么一听， 可能会觉得成功也不怎么样，不谦虚，不客观。

不过你要注意的是，他们不一定是正确的，但这些归因给了他们继续挑战的动机和信心，反之失败者，不论事前事后，都觉得自己能力不行，即使偶然成功，也是运气而已。

分享给你一段话：

这三句话来自于美国一位神学家尼布尔，他说： “神啊，求你赐给我一颗宁静的心，去接受不能改变的事。

求你赐给我信心和勇气，去改变能改变的事。神啊，赐给我智慧，去分辨两者的不同。

写在最后：

让我们回顾一下，容嬷嬷，纪晓岚， 和珅形象在人的心智中怎么来的？

大脑接受信息—内心“主客我心理定夺”——基本归因——思维沉抛——强化塑造——形成固化标签。

所以人的第一印象重要吗？ 非常重要。

了解晕轮效应后，从人物与事实角度，你会如何做归因呢？

大脑接受信息—内心“主客我心理定夺”——基本归因——思维沉抛——内部外部场景区分—匹配5要素— 再次归因— 强化塑造——形成标签。

你在别人眼中的每个场景，对方眼睛都会像卡尔蔡司镜头一样拍摄下来，回传至脑中形成记忆，不断打碎强化。

所以社交场合不管是见客户还是约会，稍微打扮一下， 衣着整洁，谈吐清晰，会让你的整体形象在对方的心智里加分。

当然从日常做事中，若遇到问题，也不要 以偏概全，归因于外界，从事实出发，向内求，别回头，向前看，多听批判的话加以思考， 祝你独具慧眼，明鉴万里。

1.新闻传播学：美国心理学家G.H.米德“主我与客我”理论

2.社会心理学家罗斯(LeeRoss）归因偏差

3.丹尼尔·卡尼曼（Kahneman ）思考快与慢缪氏错觉

4.解释水平理论，社会心理学理论(Dhar & Kim ,2007)

近期推荐

 个人号 

语言是这么不靠谱

我们却由着“语言”来决定一切。

觉得有价值，欢迎点个在看，每个人都应该拥有独立思考的能力，欢迎分享给更多人。

你不知道的 babel

提到 babel，你会想到什么？

• 可以把项目中的 es6、es7 等代码转成目标环境支持的代码
• 可以自动 polyfill 目标环境不支持的 api
• taro （小程序转译工具）是基于 babel 实现的
• babel 的插件很丰富
• 我们公司现在用 babel 来编译 typescript，不用 tsc 了
• 我基于 babel 做过自动埋点的功能，得到了领导的夸奖
• ...

其实 babel 能做的不只是这些，它能做 3 类事情：

转译 esnext、typescript、flow 等到目标环境支持的 js

这个是最常用的功能，用来把代码中的 esnext 的新的语法、typescript 和 flow 的语法转成基于目标环境支持的语法的实现。并且还可以把目标环境不支持的 api 进行 polyfill。

babel7 支持了 preset-env，可以指定 targets 来进行按需转换，转换更加的精准，产物更小。

一些特定用途的代码转换

babel 是一个转译器，暴露了很多 api，用这些 api 可以完成代码到 AST 的 parse，AST 的转换，以及目标代码的生成。

开发者可以用它来来完成一些特定用途的转换，比如函数插桩（函数中自动插入一些代码，例如埋点代码）、自动国际化、default import 转 named import 等。

现在比较流行的小程序转译工具 taro，就是基于 babel 的 api 来实现的。

代码的静态分析

对代码进行 parse 之后，能够进行转换，是因为通过 AST 的结构能够理解代码。理解了代码之后，除了进行转换然后生成目标代码之外，也同样可以用于分析代码的信息，进行一些检查。

babel 还能做什么？

babel 是前端业务开发和工具链开发中必不可少的工具，我们每天都在用，可是你有想过这些问题么：

• 怎么写一个 babel 插件来做自定义的代码转换？
• 业务开发中有哪些地方可以用 babel 来做自动化？
• babel 是怎么实现的？

还有

• linter 是怎么实现的？
• typescript 类型检查是怎么实现的？
• 压缩混淆工具的原理是什么？
• 打包工具是如何分析代码依赖关系的？
• api 文档如何自动生成？

上面这些都可以用 babel 来实现，或许你并没有想过 babel 有这么大的能量， 学会了 babel，绝对能让你提升一个段位。

基于 babel 实现完整工具链

我们来理一下这些工具的实现思路（所有下面列的工具都有 实现代码放在 github）

自动国际化

国际化是把写死的字符串字面量换成从资源包取值的方式，babel 可以分析出代码中的字符串字面量，把它替换成一个函数调用语句，然后自动引入资源包。基于 babel，我们完全可以做到自动国际化。

自动生成 api 文档

我们在写 api 的时候，会在上方添加注释，那么是不是能把这些注释内容还有关联的函数、class 的信息提取出来，用一定的模版来生成 api 文档呢？ 没错，babel 可以做到。

linter

我们整天用 eslint、stylelint 来做代码规范的检查，其实他们不过就是对 AST 做了校验，这些我们用 babel 完全可以做到。可以基于 babel 实现 eslint。

type checker

typescript 是给代码添加了静态的类型信息，可以在编译期间进行类型检查，也可以辅助做代码的智能提示，现在基本是前端必备技能了。可是你有想过 typescript 怎么实现的么？在小册中 我们会手写一个 ts type checker，让你真正理解 typescript！

压缩混淆

前端代码上生产肯定要做压缩，做混淆，这个我们整天都在用，可是你知道他的实现原理么，我们能不能用 babel 来实现一下。答案是肯定的，在 小册中 我们会实现压缩混淆的功能。

js 解释器

v8 引擎的实现原理是什么，解释型语言都是怎么解释代码的。我们能不能实现一个 js 解释器，是可以的， 《babel 插件通关秘籍》小册中我们会基于 babel parser 实现一个 js 解释器。

手写 babel

可能你会问，上面的这些都是基于 babel，那如果没有 babel 呢？

没有 babel 我们就实现一个 babel， 小册最后 我们会实现一个简易但可用的 babel，让你真正理解 babel 的原理，真正掌握 babel。

上面的解释器和类型检查的内容， 王垠卖 12000，见下图，所以这本小册绝对超值。

大纲

上面说了很多小册的内容，下面是小册的完整目录：

不只是 babel

虽然上面的实战都是基于 babel 的，可是你学到的只是 babel 么？

不是的，上面的实战案例涉及到完整的工具链，从文档生成、lint、type check、压缩混淆到 js 解释器等等，这几乎是前端开发的闭环了。 以此为抓手，学到的是整条工具链的实现思路。

上面的工具还是集中在前端领域，但其中转译器、解释器的实现思路确是通用的，编译原理主要就是学编译器、转译器、解释器三部分， 学完整本小册，相信也能帮助你入门编译原理。

总结

babel 是前端领域几乎是必备的工具，基于它可以完成很多功能，甚至是打造整条工具链，我们在 小册中会实现 linter、type cheker、压缩混淆、api 文档自动生成、js 解释器等等一系列功能。其中解释器和类型检查的功能在王垠那里能卖 12000，对比之下，这本小册内容和价格绝对很良心了。

如果说 babel api 是术，那么基于 babel 学到的编译原理、工具链实现思路就是道了。掌握了 babel、掌握了工具链，入门编译原理，绝对能让你提升一个段位。

--  商业智能平台研究：ETL之metadata

    让我们解释的更加通俗易懂一些吧，在javaSE中也有metadata的概念，最早的就算是JavaDoc了，在5.0之后，Annotation就是大量的使用metadata了，这是关于源代码的数据，具体来说就是关于Java的类、方法、字段等关联的附加数据。这些数据可以被Java的编译器或者其它工具（比如Java IDE 象eclipse+junit一样）来发现和使用。junit在4.0后也使用了Annotation也算是metadata的一种应用。可见metadata并不是什么高不可攀的技术，我们时刻都在使用。

    再来看看metadata在BI系统上的定义吧，元数据（Metadata）是关于数据、操纵数据的进程，以及应用程序的结构、意义的描述信息，其主要目标是提供数据资源的全面指南。元数据是描述数据仓库内数据结构和建立方法的数据，可将其按用途分为两类：技术元数据（Technical Metadata）、业务元数据（Business Metadata）和内联映射元数据（Inter-Mapping Metadata）。

    技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库的数据，主要包括数据仓库结构的描述（各个主题的定义，星型模式或雪花型模式的描述定义等）、ODS层（操作数据存储ODS .Operation Data Storage)的企业数据模型描述（以描述关系表及其关联关系为形式）、对数据稽核规则的定义、数据集市定义描述与装载描述（包括Cube的维度、层次、度量以及相应事实表、概要表的抽取规则）。另外，安全认证数据也作为元数据的一个重要部分进行管理。

业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够理解数据仓库中的数据。业务元数据包括以下信息:使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据来源;系统所提供的分析方法及公式、报表信息。

    内联映射元数据（Inter-Mapping Metadata）实现技术元数据与业务元数据的层间映射，使得信息系统的概念模型与物理模型相互独立，使企业的概念、业务模型重组，以及物理模型的变化相互透明。

    内联映射元数据从技术上为业务需求驱动、企业数据驱动的双驱动建设模型提供了重要保证,使信息系统的建设具有更高的灵活性与适应性。

    元数据是跟特定的数据对象有关的，换句话说，talend和kettle的元数据就是不一样的。ETL的元数据就和pentaho report 的元数据不一样，因为他们要描述的东西不一样。这些元数据的存储格式可以有多种，可以储存成XML格式的也可以是放在数据库里面的。事实上这两种最通用的，也是可以互补的两种，没有谁比谁重要之说。

    metadata储存在repository的地方,我不知道是不是所有的ETL工具都喜欢这么叫.每个repository都会选用数据库来储存,他们都是按照一定的格式,这些格式最后也是可以变成XML形式的.这是看每个工具的支持程度,kettle 就支持导出到XML格式,其他的工具我就不知道了.

    具体解释到kettle来说，metadata就是你定义的每一个动作.kettle的repository里面有如下一些表,我没有列出全部,从表的结构看一下kettle的metadata有哪些

1. R_DATABASE R_DATABASE_ATIRIBUTE R_DATABASE_CONTYPE R_DATABASE_TYPE

2. R_JOB R_JOB_HOP R_JOBENTRY R_JOBENTRY_ATIRIBUTE R_JOBENTRY_TYPE

3. R_LOG R_LOGLEVEL

4. R_STEP R_STEP_DATABASE

5. R_TRANS_ATIRIBUTE R_TRANS_HOP R_TRANS_CONDITION

6. R_USER R_VALUE R_PERMISSION

7. R_CLUSTER R_CLUSTER_SLAVE R_SLAVE

8. R_PARTITION R_PARTITION_SCHEMA

1 . database的链接信息.在R_DATABASE_TYPE 表里面包含了所有支持的数据库链接信息,一共是25种,算是支持非常的多了.

2. 任务设计部分的表,R_JOB_HOP 是指两个数据之间的链接部分, R_JOBENTRY_TYPE 是目前支持的操作种类,一共有27种,包括Transformation , Job , Shell , Mail , SQL ,FTP ,Table exists ,File Exists , JavaScript , Secure FTP , HTTP , Create File , Delete File , Wait for File , Put a file with SFTP , File Compare , BulkLoad into Mysql , Display Msgbox Info , Wait for , Zip file , XSL Transformatio, BulkLoad from Mysql into File , Abort Job , Get mails from POP , Ping a host , Dummy Job Entry .

其中BulkLoad 只跟Mysql有关,我感觉很奇怪,BulkLoad 是数据库批量处理的方式,大型数据库都是支持的,比如oracle就有sqlloader来支持批量处理,其他的大型数据库应该也有吧,而且在transform里面kettle也有oracle的支持，在任务设计的时候就只有mysql的支持，不知道什么原因.

最后一个Dummy Job Entry 就是什么都不做.

3. Log记录,loglevel 一共有6种,Nothing at all , Minimal loggin , Basic loggin , Detailed loggin , Debugging , RowLevel(very detailed).根据你自己的需要来选择log的级别.

4. 每一步操作的表格与你使用的数据库

5. 转换的定义.一共有70种不同的转化,你不会想看到全部列出来的,其中有几种很有用的,比如DimensionLookup , 它的解释就是"在一个数据仓库里更新一个渐变维,或者在这个维里查询信息.

还有基于关键字删除记录,

cuebOutput, 把数据写入一个cube,

从一个excel文件读数据,执行一个sql脚本,调用数据库的储存过程,

OraBulkLoader ,调用oracle 的bulk loader to load data ,(应该是指Oracle的SQLLOADER吧).

ProSAPCONN, 从一个SAP系统取数据.

MergeRows,合并两个数据流, 并根据某个关键字排序. 这两个数据流被比较，以标识相等的、变更的、删除的和新建的记录.

    插一句关于merge的概念，从网上copy下来的：

MERGE语句是Oracle9i新增的语法，用来合并UPDATE和INSERT语句。通过MERGE语句，根据一张表或子查询的连接条件对另外一张表进行查询，连接条件匹配上的进行UPDATE，无法匹配的执行INSERT。这个语法仅需要一次全表扫描就完成了全部工作，执行效率要高于INSERT＋UPDATE。

6. 用户与权限.一开始建立的用户有两种,admin和guest ,权限有5种,Read only access , Administrator , Use transformations , Use Jobs , Use schemas .

7. pentaho官方网站上面有一个新闻是关于在mysql的Kettle集群新记录：

    最近Kettle集群基于 Amazon Elastic Computing Cloud做了一次测试，单台服务器输出4000 rows/sec ，数据库为MySQL. 如果你发送数据通过sockets从一个master到5个slave servers, 你将获得 5x4000 row inserts/sec。集群的效果非常好.

    我个人也做过测试。数据库是oracle 10.2.0.1,内网连接，从一台机器的oracle到本地机器，没有集群，速度也大概是4000 多一点 ，数据量大概是16万。

8 . 数据库分区是数据库的高级特性之一，oracle的XE版和Enterprise版本的有一个差别就是XE版不支持分区。

    kettle还支持metadata搜索，可搜索的选项包括步骤，数据库连接和注释 ，可见metadata对于ETL的重要性就是它能够更好的管理你的数据，而不只是让你的数据呆在数据库里面。kettle对与数据库的元数据管理并不是很好，所谓数据库的元数据就比如数据库中表的名字，每一个column的信息，column的长度，每一个表的constrain，index等，而只有提供这些信息的管理才能够将ETL过程做的更好。下一篇介绍ETL质量控制的时候会看到oracle warehouse builder 对于这些数据管理是多么的强大，目前kettle的能力还不能算是非常的强大的。

    pentaho平台本身还有一种metadata , 在官方主页上是这么写的：

    pentaho metadata的能力是让管理员定义一个抽象层来显示数据库信息和商业流程，管理员用关系型数据库的表来表现相互之间的关系，为了复杂和含义模糊的数据库表和列而创建商用术语，为特性用户而设定权限参数，指定默认的数据格式，为多种语言部署提供翻译，商业用户可以使用pentaho新的ad hoc query能力查询他们想要的报表，比如订单的数量和按地区排序的客户开销，SQL可以自动取得这些信息。

    数据仓库的建模也需要用到metadata, oracle的数据仓库建模就是用的一种叫 Common Warehouse Metamodel 的metadata , CWM提供一个数据仓库的标准让不同的厂商集成和管理他们的数据，CWM建立在开发的标准XMI(XML for Metadata interchange) XML 和 UML2 作为建模语言。CWM 用UML2 定义一组核心类，这些类分作package（或者叫做子模型submodels)，每一个提供一个特定的数据仓库的domain , 比如 Relational , OLAP ,Transformation , CWM 提供一个强大的数据模型来实现数据仓库的Extraction , transformation , loading , integration and analysis ，没有一个单独的模型能够满足各种应用程序和开发工具的需求，但是CWM 为这些工具提供特定的扩展，它被设计用来支持关于metadata的快速开发，使用户能够通过扩展来满足他们的需求。

The table below summarizes resources that describe the Derby engine.

The table below summarizes white papers that describe the Derby Network Client.

The online  Apache Derby Tutorial provides a quick hands-on overview. Pointers to even more tutorials and other instructional materials are on the  Derby Wiki.

If you have figured out how something works in Derby or how to do something cool and have produced a white paper you would like to contribute to the Derby web site, please  open a Jira issue with the component set to "Web Site". Upload your contribution to that issue with the "Attach file to this issue" option. It will prompt you to click on "Grant license to ASF for inclusion in ASF works", and this is the permission we need in place to host your contribution on the Derby web site.

As time permits, somebody will take the document from the Jira issue and put it on the Derby web site. You can speed the posting process up by  testing your white paper in Forrest to verify it works well before you post it.

If you want the paper integrated with the Derby web site, with the forrest-generated navigation, it is easiest to incorporate these types of files:

• HTML (an example is  Derby JDBC Implementation Notes).
• XML, using the  Forrest DTD (an example is  Derby Engine Architecture Overview).
• ASCII text embedded in XML (an example is in the  derby_web.html page).

That much said, even though your favorite word processing program can produce an HTML file, that doesn't necessarily mean that forrest can read it and do something visually pleasing with it. If forrest can't consume your document, or you don't like what forrest did with it, or you want to provide your document in a binary format it can be included in its native format on the site -- it just won't have the forrest-generated left hand navigation and top banner. Examples are:

• Running DOTS (Database open Source Test Suite) with Derby.
• The C-JDBC  PDF and  Open Office files.

You can also link directly to a file in the Derby code tree; for example, to the  Building Derby file. Don't link with a viewcvs URL like the one below because it turns out to put a heavier burden on the server than is needed:

   https://svn.apache.org/viewcvs.cgi/*checkout*/db/derby/code/trunk/BUILDING.txt

ViewCVS is good for when you need to browse the history. But if all you need to do is display the file, link to it like this instead:

   http://svn.apache.org/repos/asf/db/derby/code/trunk/BUILDING.txt

相关文章:

1. SQL 日期/时间处理函数
2. 时间序列预测之ARIMA
3. 数据分析人员应该掌握的SQL技能

近些年来，前端领域的跨端技术越来越多了：react native、weex、flutter、electron、kraken 等等。

那么多跨端方案，他们有没有通用的思路？我们能不能从这么多方案中找出本质的原理？

本文会尝试探究探究以下问题：

• 什么是跨平台
• 有哪些方案是跨平台的
• 跨端和跨平台的区别是什么
• 前端领域有哪些跨端方案
• 跨平台、跨端的通用原理是什么

什么是跨平台

我们知道，cpu 有不同的架构和指令集，上层也有不同的操作系统，一个系统的可执行文件在另一个系统上就是不可执行的，比如 windows 的 exe 文件在 mac 上就不能直接执行。不同的系统就是不同的运行平台。可执行文件是不跨平台的。

不同平台提供的 api 不同，所以代码逻辑可能也不同，需要不同平台单独维护代码。这样就带来了几个问题：

• 多平台各自开发，怎么保证功能是一致的
• 多平台各自开发，那是不是得各自测试，开发和测试的人力都是多份的

所以出现了跨平台的一些技术，目标是一份代码跑在任意平台。

我们先来看一些各领域的跨平台方案：

浏览器

操作系统不同，浏览器上跑的网页的代码确实同一份。浏览器就是一种历史悠久的跨平台方案。

网页跨平台不意味着浏览器也是跨平台的，浏览器的可执行文件还是每个平台单独开发和编译的，但是他们支持的网页解析逻辑一样，这样上面跑的网页就是跨平台的。

浏览器提供了一个容器，屏蔽了底层差异，提供了统一的 api（dom api），这样就可以实现同一份代码跑在不同平台的统一的容器里。这个容器叫做浏览器引擎，由 js 引擎、渲染引擎等构成。

docker

docker 是一种虚拟化技术，可以在操作系统之上加一个虚拟层，在这层之上划分一到多个容器，容器里再去跑系统、app，这样可以实现硬件和软件的分离，动态分配硬件资源给容器，并且方便 app 运行环境的整体迁移（保存成镜像）。

docker 很明显也是一种跨平台技术，同一个镜像可以跑在任何操作系统的 docker 上。只要不同操作系统实现同样的容器即可。

jvm

java 是一门编译 + 解释的语言，java 源码编译成字节码，然后字节码直接在 vm 上解释执行。

java 为什么这么火呢？主要是因为跨平台。

c、c++ 这种语言写的代码需要编译成不同操作系统上的可执行文件来跑，而且每个平台的代码可能还不一样，需要写多份。

java 因为提供了 jvm 容器，只要把源码编译成 jvm 能解释的字节码就行了，而且 jdk 提供了统一的 api，分别由不同操作系统的底层 api 来实现，这样对于 java 代码来说，不同操作系统的代码是一致的。

jvm 也是通过容器的技术实现了一份代码跑在多个平台，而且 jre 提供了统一的 api，屏蔽掉了底层的差异。

node、deno

node 和 deno 也是跨平台的技术，通过提供一套一致的 api，让其上的 js 代码可以跨平台。这些 api 也是不同平台各自实现的。

electron

electron 内置了 chromium，并为其注入了 node 的 api 和一些 GUI 相关的 api，是基于两大跨平台技术综合而成的跨平台方案。基于这些方案的组合使得 electron 支持用前端技术开发桌面端。

跨平台方案的优缺点

跨平台方案的优点很明显，就是一份代码跑在不同平台的同样的容器内，不用不同平台单独开发，节省成本。

但是跨平台方案也有缺点：

• 因为多了一层容器，所以性能相比直接调用系统 api 会有所下降

• 为了实现多平台的一致，需要提供一套统一的 api，这套 api 有两个难题：

  • api 怎么设计。要综合不同平台的能力，取一个合适的集合来实现。设计上有一定难度。node、deno、java 都抽象了操作系统的能力，提供了各自的跨平台 api

  • 部分 api 很难做到多平台的一致性

  • 当容器没有提供的能力需要扩展的时候比较麻烦，比如 js 引擎的 bridge、 jvm 的 jni、node 的 c++ addon 等都是为这个容器扩展能力的方式

前端领域的跨端方案

跨平台指的是跨操作系统，而跨端是指客户端。

客户端的特点就是有界面、有逻辑，所以包含逻辑跨端和渲染跨端。主要的客户端有 web、安卓、ios、iot 设备等。

现在主流的跨端方案有 react native、weex、flutter、kraken 以及各家自研的跨端引擎等。

react native

跨端包括逻辑跨端和渲染跨端，rn 的逻辑跨端是基于 js 引擎，通过 bridge 注入一些设备能力的 api，而渲染跨端则是使用安卓、ios 实现 react 的 virtual dom 的渲染。

其中 native api 和组件（灰色画出的部分）并没有做到双端一致，而且有的时候扩展图中灰色部分需要原生配合，混杂 rn 代码和自己扩展的代码导致代码比较难管理。最著名的事件就是 airbnb 从最大的 react native 支持者到弃用 react native。

weex

weex 也是类似的思路来实现跨端的，不过他对接的上层 ui 框架是 vue，而且努力做到了双端的组件 和 api 的一致性（虽然后续维护跟不上了）。架构和上图类似。

flutter

flutter 是近些年流行的跨端方案，跨的端包括安卓、ios、web 等。它最大的特点是渲染不是基于操作系统的组件，而是直接基于绘图库（skia）来绘制的，这样做到了渲染的跨端。逻辑的跨端也不是基于 js 引擎，而是自研的 dart vm 来跨端，通过 dart 语言来写逻辑，

kraken

跨端包括两部分，渲染跨端和逻辑跨端。有时候只需要渲染跨端、有时候只需要逻辑跨端，有的时候需要完整的跨端引擎，这 3 种情况都有各自的适用场景。

kraken 就是一个跨端渲染引擎，基于 flutter 的绘图能力实现了 css 的渲染，实现了渲染的跨端。

自研渲染引擎

跨端引擎很依赖底层实现的组件和 api，用开源方案也一样得扩展这部分，所以有一定规模的团队都会选择自研。

自研跨端引擎会和 rn、weex 不同：

• 渲染部分不需要实现 virtual dom 的渲染，而是直接对接 dom api，上层应用基于这些 dom api 实现跨端渲染。这样理论上可以对接任意前端框架。

• 逻辑部分也是基于 js 引擎，通过 binding 直接注入一些 c++ 实现的 api，或者运行时通过 bridge 来注入一些安卓、ios 实现的 api。

自研跨端引擎的好处是组件和 api 可以自己扩展，更快的响应业务的需求。其中组件和 api 的双端一致性，以及统一的 api 的设计都是难点。

跨端的通用原理是什么

其实跨端和跨平台的思路类似，都是实现一个容器，给它提供统一的 api，这套 api 由不同的平台各自实现，保证一致的功能。

具体一些的话，跨端分为渲染和逻辑跨端，有的时候只需要单独的渲染跨端方案（比如 karen）和逻辑跨端方案，有的时候需要完整的跨端引擎。

weex、react native 的渲染部分都是通过实现了 virtual dom 的渲染，用安卓、ios 各自的渲染方式实现，逻辑部分使用 js 引擎，通过 bridge 注入一些安卓、ios 的 api。

flutter 则是直接使用 skia 绘图库绘制，并且逻辑跨端使用 dart vm。

但是不管具体实现怎样，思路都大同小异： 跨端引擎需要实现一个渲染引擎、实现一个 vm，基于这套架构实现各种组件和 api，跨端容器上层对接一个 ui 框架，再上层的业务代码可以基于容器的 api 实现跨端的渲染和逻辑

web container

这两天 web container 比较火，其实也是一种跨平台技术，它是在浏览器里面实现的容器，通过 wasm 实现了 node 的 api，这样在这个容器里面可以跑 node 代码。其实思路比较常见，但是是一个新场景。

浏览器容器之上又跑了个容器，容器套娃。

总结

我们聊了跨平台和跨端的区别，跨平台是指跨操作系统，而跨端则是指跨客户端。

跨平台技术聊了 docker、浏览器、jvm、node、deno、electron、web container 等，他们都是跨平台（操作系统）的方案，跨平台有优点也有缺点，缺点就在于 api 的设计比较难，node、deno、java 等都有自己的一层 api 设计；api 一致性的保障也比较困难；其次就是扩展方式复杂一些（jvm 的 jni、node 的 c++ addon 等）。

跨端方案聊了 react native、weex、flutter、kraken 等，有的是绑定了 react、vue 等前端框架，直接从 virtual dom 渲染，有的是实现了 dom api，可以对接任意前端框架。当然可以单独做渲染或逻辑跨端。渲染跨端或者用安卓、ios 提供的方式，或者自己绘制，逻辑跨端或者用 js 引擎（可以对接前端框架）或者用 dart vm。

希望这篇文章可以让你理解跨端和跨平台的容器的思路和优缺点，遇到一些新技术（比如 web container）也能快速的理解。

刘晓蕾与新作《作为欲望号的金瓶梅》

记者 | 潘文捷

编辑 | 黄月

年轻时看《金瓶梅》，刘晓蕾觉得不论是人物还是文字都“太粗粝”，到了三十多岁再次捧起《金瓶梅》时，她却感受到了“满篇锦绣”。

兰陵笑笑生所著的《金瓶梅词话》到如今已经拥有超过四百年的历史。它一直是世人眼中的“奇书”，展现了上至朝廷内擅权专政的太师，下至地方官僚恶霸、市井地痞、帮闲的世界，市井的丰富、人性的善恶和明代社会的黑暗尽逐显露。此书虽因恣肆铺陈的性描写而一直被视作“淫书”，却受到不少学者和作家的喜爱。此前，著有《秋水堂论金瓶梅》的哈佛大学东亚系中国文学教授田晓菲、著有《雪隐鹭鸶 : <金瓶梅>的声色与虚无》的清华大学中文系教授格非等人，都认为《金瓶梅》要胜过《红楼梦》。

那么，我们究竟该怎么进入《金瓶梅》？刘晓蕾是南京大学中国现当代文学博士，任教于北京理工大学，在学校开设了“《红楼梦》导读”公选课，曾被评为“最受欢迎的公选课教师”。2019年曾出版《醉里挑灯看红楼》，今年，她又推出了《作为欲望号的金瓶梅》一书。在这本书里，她不仅围绕“欲望”这一核心讲解了《金瓶梅》的独特之处，也邀请读者一道将《水浒传》和《红楼梦》对照阅读，她认为，从《水浒传》到《金瓶梅》再到《红楼梦》，背后反映的是文明发展的不同阶段。

01 把《金瓶梅》看作小黄书和“老婆舌头”，是一种“呆看”

界面文化：你的这本新书名为《作为欲望号的金瓶梅》，为什么给书起这个名字?

刘晓蕾：《金瓶梅》有多重的主题，比如欲望、商业、城市、死亡等，但如果只能用一个词来概括的话，那就是欲望。欲望本身是在城市和商业的条件下展开的，死亡也是在欲望的背景下展开的。

界面文化：《金瓶梅》分成词话本和绣像本，美国汉学家和翻译家芮效卫（David Tod Roy）花了40年时间翻译成外文的是词话本，很多海外学者也觉得词话本是比较有艺术价值的。在你看来，为什么他们会更偏爱词话本？你自己是怎样的态度？

刘晓蕾：国外情况我不是很了解，国内好多人喜欢词话本可能是因为它保留了很多民俗资料，比如说一些美食和曲词（当时的流行歌曲）等等，读者能从词话本里看到当时的娱乐、饮食方方面面，看到民间活泼的文化，具有研究价值。绣像本把这些内容删掉了大部分，也是有自己的文学考量的。喜好哪个版本跟个人的阅读经历有关系。《红楼梦》也有不同的版本，大家各有所好，比如白先勇特别喜欢程乙本，因为那是他人生中接触《红楼梦》的第一个版本，有额外的感情。我第一次读《金瓶梅》就是绣像本。

我看《金瓶梅》不是从史料、民俗风情角度去观察，而是从人性、从文学的角度去观察，显然在这方面绣像本更有文学的自觉性。再把《红楼梦》拿来比较，曹雪芹对文学的主题、作品的结构、人物的设定是有自觉意识的，他知道自己要写的是一部不朽名著。《金瓶梅》词话本的作者似乎就不太在意这些，就是凭着自己的泼天才气，甚至有点偷懒。比如第一回，词话本一开头就把《水浒传》里武松的故事直接移植过来，而绣像本的修改者显然清楚《金瓶梅》的男主角是西门庆，而不是武松，于是改成了“西门庆热结十兄弟 武二郎冷遇亲哥嫂”。

界面文化：这是不是说明其实兰陵笑笑生写得没有那么好，修改过的更好？

刘晓蕾：不能这么说。词话本就像一个不太懂得打扮自己的绝世美女，出场不穿礼服，穿个衬衣牛仔裤就跳出来了。但是绣像本懂得修饰一下，知道画一画眉毛，点一点口红，马上就仪态万方。话又说回来，如果没有词话本这个美女的底子，绣像本再修饰也不行嘛。

绣像本第一就是把那些重复性的曲词、美食删掉，把一些偏口语化有点啰嗦的东西修整好；第二删掉了一些说教性的套话以及民间说书的术语，这样就比较文雅；第三有主题上的升华，尤其是第一回改得特别厉害。比如卷首诗，原来是“丈夫只手把吴钩，欲斩万人头。如何铁石打成心性，却为花柔”，绣像本是“豪华去后行人绝，萧筝不响歌喉咽”，表达的是更深邃的“空”与“悲”，直接抵达生命的本质，这比词话本的道德说教显然境界更高。当然，这不是绣像本修改者凭空添上去的，修改者深刻地体会到了词话本要表达的深层主题，凝练出来放在卷首。

界面文化：你在书里引用了清代文学评论家张竹坡的话，“读《金瓶梅》，不可呆看，一呆看便错了”，什么叫“呆看《金瓶梅》”？你遇到过这种情况吗？

刘晓蕾：“呆看”就是人云亦云。比如说一想到《金瓶梅》，就认为它是一本“小黄书”，脑子里只有那几回著名的不太节制的文字，这是一种“呆看”。还有一种就认为写的是西门庆和他的女人们，如何吃饭如何上床如何吵架，满篇的“老婆舌头”，也就是八卦。还有人把《金瓶梅》看成西门庆家的账簿，关注今天花了多少钱，明天又花多少钱，米多少钱，猪肉多少钱，这些都是“呆看”。其实在表层日常生活的背后，有最严肃最深邃的主题。

02 大手笔兼细心思：《金瓶梅》关乎人性、道德、商业与宗教

界面文化：张竹坡说《金瓶梅》是“大手笔”但却是“极细的心思做出来”的。在你看来，“大手笔”和“极细的心思”体现在哪里？

刘晓蕾：首先说“大手笔”。大手笔是包罗万象，有广度，此外对人性的理解也有深度，作者站位也有高度。

《金瓶梅》是有头有尾的100回，里面人物有几百位，不光有西门庆和他的家里人，还以清河县为枢纽，细致地写出了商业社会的结构、城市生活的面貌，牵扯的面非常广。书中有从南方来的客人，西门庆的伙计也会到南京、杭州、苏州采买货物。清河县还有太监、大户以及各路官僚，甚至笔触还伸到了东京朝廷……除了市井生活，商业官场多有涉猎，让我们看到整个时代的氛围。

除了群像，对每个个体的具象摹写也是大手笔。我认为，西门庆、潘金莲、应伯爵等等这些人都是前所未有的真实和深刻。如何理解这些人，就是如何理解欲望、人性、道德和商业。

从西门庆身上你可以看到，一个男性是如何在金钱和权力的加持下把欲望挥洒到极致的，还能看到他怎么做生意，他的生活和他的信仰，这样一个人身上有很多值得我们考量和深思的。我们也可以从潘金莲这个人物看女性的欲望，看到一个女人在欲望的驱使下是怎样“黑化”的，但这个狠辣的女性身上也有人性的一方面，甚至她相当聪明、性感——中国作家中很少有人把女性的恶与美写得如此酣畅，如此复杂。好多人讨厌应伯爵，一般都说他是个帮闲，骂他丑恶。田晓菲为他说过一句公道话，说“虽然他是个寄生虫，但我还是挺喜欢他的”（大意如此），但她也没多说。我在书里就为应伯爵专门写了一篇万字长文，从商业和城市的角度来看，你就会发现，应伯爵哪里丑恶？他就是一个中介，为西门庆做了很多服务，一个成熟的商业社会应该承认中介的作用。而且他特别会说话，情商特别高，在现代社会绝对是一把好手。

再说“极细的心思”。我读《金瓶梅》时常常对书里的细节流连忘返。作者是一个对生活、对人性充满好奇心的人，把握细节的能力非同凡响。

界面文化：可以举例说说吗？

刘晓蕾：第23回，潘金莲、孟玉楼和李瓶儿下棋，李瓶儿输了五钱银子，潘金莲就让人拿钱去买了猪头，再让宋蕙莲去烧。宋蕙莲一开始不愿意，因为她那时候是西门庆的情人了，以为自己也有身份了，能跟西门庆的小妾说得上话了。但旁边有人让她赶紧去，五娘那个脾气你是知道的，她只好去下厨。作者写她把猪头弄干净，抹了酱料，然后放上锡古子（类似于现在的高压锅），用一根柴火，把猪头烧到皮脱肉化，香喷喷的，用冰盘盛上来。还是李瓶儿让人盛了一碟给宋蕙莲，她就在一旁站着吃了。这个小细节充满心思，这是后院里的“宫心计”，有潘金莲和宋蕙莲的较劲，有李瓶儿的厚道，还有美食的味道，以及市面上一个猪头多少钱。多有意思。

再比如第25回，吴月娘带妻妾们打秋千。吴月娘是以处女之身嫁给西门庆的，其他全都是再嫁的寡妇或妓女。吴月娘的姿色、智商都不如别人，但她为自己的清白之身自豪，这是她隐形的道德优越感。虽然她不说，但伟大的作家用细节帮她说。潘金莲她们玩嗨了，笑得厉害，吴月娘就讲了一个故事：打秋千时不要笑，我在家里做女儿的时候，隔壁邻居家的周小姐就是打秋千时笑得厉害了，没坐稳掉下来，抓了喜。后来嫁人，人家发现她不是处女，把她休了。这只能是吴月娘讲的故事，有她的心思。打秋千不仅仅是打秋千，吴月娘把西门庆的女婿陈敬济请来，帮忙推秋千。张竹坡就说，吴月娘居然让一个男人来推秋千，这家风不行，祸事由此而起啊。陈敬济把李瓶儿裙子掀起来，露出她的大红底衣，推她的秋千……你看，陈敬济对小妾们的垂涎之心一下就出来了。在这里埋下一个伏笔，西门庆死后，陈敬济就成了后二十回的主角，把西门家搅得乱七八糟。

刚才说的是细节体现人性和性格，还有一种“细”是结构上的“细”。《金瓶梅》里有一个永福寺，在第一回就出现了，其实没什么作用，只不过是西门庆要结拜十兄弟，有人建议去永福寺，西门庆说寺庙不管这些事，去玉皇庙吧。而正是在永福寺，西门庆遇到了胡僧，得到了胡僧药（春药），这是他走向死亡的重要节点。此外，潘金莲死后被春梅葬在了永福寺后的白杨林里。在第100回末尾，正是在永福寺，吴月娘遇见了普静禅师，普静禅师把吴月娘和西门庆的儿子孝哥渡化出了家。也是在永福寺里，普静禅师为死去的人念了转生咒，让他们一一转世。这个结构是很精妙的。

还有害死官哥的那只猫，也不是突然就出现的，而是一再做了铺垫，一切都水到渠成。我们都说《红楼梦》手法高明，“草蛇灰线，伏脉千里”，其实是跟《金瓶梅》学的。

界面文化：你在书中提到，《金瓶梅》是暗黑系的、无神的世界，亲情、爱情、友情都指望不了，遍地都是金钱、权力和性。这一点要如何理解？另一方面，好像不少评论人士认为《金瓶梅》是有佛教思想贯穿其中的。

刘晓蕾：这两个问题是有关联的。这一句话看上去很绝望，其实“暗黑系，无神的世界，亲情、爱情、友情都指望不了”不是指向“绝望”，而是想呈现一个事实。

第一，作者穿透世相，拒绝抒情，直接看到了人心、道德和世情的“空”，这跟作者的佛教思想有关，待会儿再说。

第二，“无神的世界”正是现代社会的一个写照，这是《作为欲望号的金瓶梅》这本书跟其他很多研究不一样的地方。很多人谈到《金瓶梅》会说这本书很深刻，但由于过于颠覆传统，过于黑暗冷酷，有点让人绝望。《金瓶梅》写的是商业社会和城市空间，而商业和城市是现代社会的特征，虽然在明代中后期只是阶段性的“现代”。《金瓶梅》里没有一个是种地的，连《红楼梦》写贵族还要有一个刘姥姥，有乌进孝，但《金瓶梅》全民皆商。商业和城市给了作者跟传统断裂的机会和勇气。城市是“陌生人社会”，把我们连根拔起，这也是现代社会的写照。现代社会本身就是“祛魅”的社会，尼采说上帝被杀死了，有一句话是“一切坚固的都烟消云散了”，这就是现代人和现代社会的“处境”，一切都变得不那么确定了，亲情、友情和爱情也很难指望。我们越现代，越会觉得都要靠自己。虽然让人感到很绝望，但人类对自己的处境会有更加全面的了解。长大肯定是要阵痛的，是很难过的。从这个角度来看《金瓶梅》里的人，比如应伯爵，你会有不一样的看法，你会对他们有更深的理解，而不是一味的批判。

接着说《金瓶梅》里的佛教思想。作者能够写出这样一个崭新的世界，毫不留情地颠覆传统的道德秩序和价值体系，有一个重要的根源在于他对佛教思想的借用。

《金瓶梅》里的佛教人士分两类，一类是王姑子薛姑子这种尼姑，是专门赚钱的，是世俗化的民间宗教。《红楼梦》的马道婆也是类似的人物，在明清小说里，民间宗教常常是被嘲笑挖苦的对象，那些尼姑、和尚、道士个个利欲熏心。但嘲笑归嘲笑，很多文人对佛教的义理还是尊重的。

《金瓶梅》的作者就是这样。黄道士给死去的李瓶儿念经，说的一长篇话，句句饱含深意，意指世人个个深陷欲望的深渊，贪生怕死，这其实就是佛教的义理。佛教对欲望的态度是“众生皆苦”，贪嗔痴这些欲望就是痛苦的根源等等。所以，作者一方面写他们的欲望，西门庆如何升官发财找女人，潘金莲和李瓶儿如何情欲满满，西门庆是“贪”，潘金莲是“嗔”，李瓶儿就是“痴”——贪嗔痴全了，这完全可以从佛教义理来解释。另一方面，《金瓶梅》又不是一部佛教书。作者把人间欲望写得热气腾腾，活色生香，如果体会不到“贪嗔痴”的佛教用意，很容易想歪，以为是在诲淫诲盗。

最后，在《金瓶梅》里，佛教思想不仅是结构上的需要，同时也有思想上的深度和厚度。作者在写热闹繁华的人间图景时，尤其是前面80回，西门庆一路爬坡，抵达人生顶峰，却总是在繁华背后透出“冰冷”的信息，所以张竹坡说作者善用“冷热金针”之法，繁华和凋败、生与死经常同时出现。比如第42-46回，作者描写元宵节的盛况，最后却来一句“总然费却万般心，只落得火灭烟消成煨烬”。冷冷一笔，真是透心凉。这种冷热交织的手法，后来《红楼梦》也学了去。这就是佛教的义理，即使现在繁华，但要知道这背后是一种空性，是不持久，大家都是因缘聚合的产物。

当然，作者知道自己笔下的这些人不会反思、不会觉悟，世间又有多少人能够反思和觉悟呢？但作者写这样一本书，写这么一群不觉悟的人，其实是想让我们觉悟的。至于我们觉悟不觉悟，就看我们自己了。

03 兰陵笑笑生和曹雪芹都是“超性别”的作家

界面文化：你怎么看待今天很多读者对文学作品的“三观审查”？

刘晓蕾：小说根本不能用道德或法律来约束，小说就是写人、写人性的，人性是一个非常辽阔的空间。“不道德的人”“不对劲的人”在文学里是有一席之地的，如果用三观来审查，那绝大多数世界文学名著都经受不了审查。比如陀思妥耶夫斯基的所有小说，托尔斯泰的《安娜·卡列尼娜》，福楼拜的《包法利夫人》，纳博科夫的《洛丽塔》，统统都得下架。

界面文化：《三国演义》《水浒传》里面女性都是集体失语的状态，但你看到《金瓶梅》却很懂女性。田晓菲和格非都提到过，西门庆结交十兄弟是对《三国演义》《水浒传》里“兄弟情义”、对男性同性欲望的反写和嘲讽，书里真正存在友谊的却是两个女性——潘金莲和春梅。从这个意义上，《金瓶梅》能不能说是女性主义的小说？

刘晓蕾：《金瓶梅》确实有这样的现象。但到底是不是女性主义小说，我持谨慎态度。从性别的角度读小说，自然有意义，但对《金瓶梅》这部小说来说，性别角度只是其中一个角度，而且是不太重要的一个角度。

讽刺兄弟情义，是因为兄弟情属于传统道德，这是对传统道德的态度，而不只是对男性的态度。男性的文化构成了传统社会的主流文化，所以反主流看起来像反男性。

兰陵笑笑生是一个男性作家，他对女性心理相当了解，写潘金莲和春梅的姐妹情谊，我们也能看见女性内心的纠结、痛苦和愤怒。但他写男人一样深刻又复杂，西门庆和应伯爵就被写得前无古人后无来者，我更愿意把他看成是“超性别”的作家。他和曹雪芹一样，都是伍尔夫说的那种“雌雄同体，具有伟大灵魂”的作家。

界面文化：你认为，从《水浒传》到《金瓶梅》再到《红楼梦》，人性是不断向上的。武松是丛林社会，西门庆代表欲望，贾宝玉带给我们的是爱和温柔。这样看来《水浒传》的文学水平应该是最低的吗？民间一直有“少不读《水浒》”的说法，你认为领悟作品有年龄的限制吗？

刘晓蕾：倒也不是这个意思。《水浒传》写的是人性的破坏力，这是人性原始的部分，是人性的一个方面。水浒社会是不正常的社会 ；《金瓶梅》里的人性更饱满更复杂，饮食男女这样的基本需求是被承认的。从这个角度来说，金瓶世界是比较正常的，当然精神的维度太弱了；而《红楼梦》里的人性更诗意、更高贵，活得更有尊严，更富有精神性，这其实是我们应该拥有的人生和生活。这三个方面加起来就是全部人性。

至于对《水浒传》的评价，我现在越来越谨慎了，不轻易言其好坏优劣。这本书写得很精彩，你看作者写林冲是怎样一步步被逼上梁山，把林冲的忍无可忍，只能再忍，再忍就得死，只好上梁山……这个过程写得多好。不过，《水浒传》只看见这些所谓英雄好汉，关注非凡人生，却看不见女性，也看不见平民百姓，所以我说它是“剑走偏锋”的小说，深刻但不博大。

“少不读水浒”还是有道理的。其实，《水浒传》比《金瓶梅》暗黑得多。一言不合拔刀相向，根本不会讲理，人就被杀了，在这样的社会里，普通人是很难活下去的。《水浒传》里劫法场的时候，李逵可是连围观群众也杀了不少。在《金瓶梅》里，这些普通老百姓能活下去，理发的、裁缝和货郎都活得好好的。

界面文化：你觉得《水浒传》比《金瓶梅》暗黑，但是很多人都觉得里面是兄弟义气。

刘晓蕾：如果《水浒传》里有兄弟义气，也是小圈子的利益，跟社会正义无关。你看，宋江倒是义薄云天，可他带着兄弟招安讨方腊，兄弟们最后几乎都死了。梁山上的108将有多少是被“赚上山”的？是被“传销”上来的？就因梁山需要他们，需要徐宁秦明卢俊义，就把人家弄得家破人亡。这是兄弟情深？利益联盟而已。

还有，武松为了施恩，醉打蒋门神，他的正义也经不起推敲，如果蒋门神给他好酒好肉，他也会为了蒋门神打施恩的。施恩和蒋门神只是黑吃黑，没有谁更正义。

04 《儒林外史》和张爱玲也深受《金瓶梅》影响

界面文化：在《秋水堂论金瓶梅》里，田晓菲认为《金瓶梅》更好，是因为《金瓶梅》看社会各阶层的各色人等更加全面而深刻，更严厉也更慈悲。比如说，《红楼梦》对赵姨娘、贾琏、贾芹这样的人物已经没有什么耐心与同情，就更无论等而下之的，《红楼梦》所最为用心的地方只是宝玉和他眼中的一班“头一等”女孩儿。你同意这个说法吗？

刘晓蕾：我个人很喜欢田晓菲解读《金瓶梅》，但唯独这一点我不太同意。《红楼梦》的灵魂是大观园，是贾宝玉和一群清净洁白的女儿们，是“人如何诗意地栖居”。它的主题变了，所关心的问题变了。像赵姨娘、贾琏、贾芹这些人，是 《金瓶梅》所关注的，但在《红楼梦》里，他们必然是配角。但对这些配角，也不是缺乏慈悲，我们依然可以从只言片语里，拼凑出他们的人生，看见他们的不得已。赵姨娘就和马道婆说，哪里有什么整块的绸缎到我的手里来？我们也可以从探春的痛苦，从贾环的处境，可以看出赵姨娘可恶之外的可怜。

贾琏也有可爱温情的一面。贾赦看上了石呆子的扇子，贾琏没买成，贾雨村把石呆子弄到狱里去，把扇子夺来送给贾赦。贾琏说，为把扇子把人家搞得坑家败业，不算什么能为。这句话是有良知的。

还有贾芹也有故事，有骑着大叫驴光擦的时候，也有被贾珍训得满脸通红的时候。

但这些人不是《红楼梦》的主角。《红楼梦》的主题跟《金瓶梅》不同。

界面文化：格非在 《雪隐鹭鸶：<金瓶梅>的声色与虚无》里认为，《红楼梦》是《金瓶梅》的“倒影”。  就是看到两者之间思想文化方面的关系，也看到《红楼梦》对《金瓶梅》的重要改造和超越。

刘晓蕾：这说得蛮精彩的。我再补充一句，在《金瓶梅》结束的地方，《红楼梦》才开始。《金瓶梅》的结尾有一段奇特的爱情故事，作者本来就看破人心世情，打碎传统道德和价值，却在最后两回写了韩爱姐很热烈地爱上一个人，一个浪子败家子陈敬济，这是人性废墟上开出的花，也是暗夜里的光。我认为，作者对人性还有期待，是绝处逢生，这是一种深刻的爱与慈悲。好在，在《红楼梦》里我们又看到了高贵纯粹深情的爱。

界面文化：曹雪芹之后，还有没有哪些重要作家受《金瓶梅》影响比较深？能否请你讲解一二？

刘晓蕾：《红楼梦》很受《金瓶梅》的影响。此外还有《醒世姻缘传》《儒林外史》等。说句夸张的话，《金瓶梅》影响了太多的小说。毕竟它是第一部写日常生活（鲁迅说的世情小说），第一部文人独立创作……《金瓶梅》对《红楼梦》的影响是全方位的，我在书中有详细说明。

对《儒林外史》的影响是白描式的“讽刺”。《金瓶梅》也很会揶揄文人的：第49回，蔡御史来西门庆家里，西门庆给他安排了两个妓女。蔡御史一看，“欲进不能，欲退不舍”。西门庆就说，当年谢安也曾经有过这样的雅兴，蔡御史说我比不了谢安，但是你有王右军（王羲之）的高致啊。这种场合，谢安和王羲之的棺材板都会压不住的。但这种讽刺也不是一味刻薄，讽刺是很难写好的，一不小心就流向“冷嘲”，但《金瓶梅》的作者能原谅他们。

还有张爱玲也深受《金瓶梅》的影响。我在网络上有一门课《刘晓蕾讲透金瓶梅》，有一节课专门讲张爱玲和《金瓶梅》的关系。张爱玲曾经说，《金瓶梅》和《红楼梦》是她“一切的源泉”，很多人都注意到《红楼梦》的影响，其实从她小说的内容和精神气质以及她的个人生活而言，她和《金瓶梅》关系更近。