话说最近真是流年不利，感觉各种BUG犹如天灾一样全部冒出来了，这不昨天又解了一个非常无语的问题，大概是关于换行和正则的臭虫，下面给大家吐槽一下。
昨天同事反馈某个页面的数据没有正常显示，最开始我还以为是接口没有返回数据，结果看了下请求发现接口有正常的数据呀。没办法就一路反查回去，最后查到居然代码里接口请求抛错了？！因为定义了 Promise 的 catch 流程，所以也没有把错误抛出来。因为之前这个页面都是正常的，很久都没有改动所以我第一反应是这个数据异常了，查了半天的数据格式问题。可是问题就在于明明看到数据是正常的呀，服务端没有报错，接口数据也是可以正常解析的。最后我突然想起来，我们的接口是 JSONP 的会不会是 JSONP 功能挂了？查了一下果然是这样。
前段时间我开源了一个叫 Animaris 的项目，这个项目是使用 ThinkJS + MongoDB + React + Antd 开发的移动端 WebView 接口文档系统。平常大家见到的接口文档无非就是 HTTP API 接口文档，要么就是框架/库提供的接口方法文档。对于这种 WebView 的接口提供文档基本上没有。借着业务的需求我做了这么一个项目，用来解决以下两个问题：
如果有相关需求的同学也欢迎使用，感兴趣的同学也欢迎 star。咳咳，回到本文的重点，项目开发的差不多的时候我就准备给它设计一款 LOGO 了，以下是成品效果图。虽然我没有学过绘画没有很好的设计功底，但是我相信简单的形状也能发挥不错的效果，那么我就给大家讲讲我是如何设计这款 LOGO 的。另外由于动画效果有兼容问题，最好使用 Chrome 等现代浏览器查看本文哦~
小程序以免安装用完即走的特性自发布初就很火，即使是现在也是热度不减。小程序虽然是一个 HTML5，但是通过限制开发者的写法，提供一套自定义的组件以及写法，并且将一部分耗费性能的组件使用客户端渲染来极大的提高网页的性能。
前段时间我们也进行了小程序的开发。由于是接手的项目，这个项目之前是没有使用框架，直接使用原生小程序开发的，开发过程中就发现有很多不方便的地方。例如 NPM, Promise 组件化等。最后我对 wepy, tinajs, labrador, mpvue 等多个框架进行了调研，最后决定使用 tinajs 对项目进行重构。选择 tinajs 的原因是它是基于小程序的语法，并没有多大的改造，学习成本非常低。同时它的渐进式概念让我能够循序渐进的接入框架，而不是一下子就要把它的所有概念都要学习下来，这对当时工期比较紧张的我来说是比较重要的。当然还有一个更重要的原因是，它的源码非常的简单，即使是出了问题我也能快速定位出来。
不过即使是选择了一套正确的框架，碰到坑的情况也是在所难免的，小程序更甚。下面我就我这段时间碰到的一些比较经典的问题来说一下我碰到的一些问题。
其实这个话题很简单，不是很想写这篇文章。不过的确还是有很多朋友在打包构建部署上存在一些问题，恰巧最近使用 Docker 部署了几个 ThinkJS 相关的项目，所以还是拿出来说说吧。需要提前说明的是本文并不是 Docker 的基础教程，默认大家都是了解 Docker 的。然后我会分享一下我觉得 ThinkJS 项目构建和部署过程中可能需要注意的点，我们先说说如何构建镜像，然后再说一下可能出现的问题。
一般说来 SPA 的项目我们只要启一个静态文件 Server 就可以了，但是针对传统项目就不一样了，一个项目会依赖很多服务端程序。之前我们的开发模式是在一台开发机上部署开发环境，所有人都在这台开发机上使用 Samba 连接开发。老式开发是没什么问题的，但是前端因为引入了编译流程，增加了 Webpack 打包构建的行为，当多人共同开发的时候经常会因为内存爆满进程被杀导致打包失败。痛定思痛后为了解决这个问题，我决定将 Docker 引入我们的开发环境，通过将开发环境本地化来解决这个问题，所以有了本文。
本文内容主要是我之前分享的文字版，若想看重点的话可以看之前的 Slide：
也可以查看分享视频：http://cloud.live.360vcloud.net/theater/play?roomid=2321
大家好，我是奇舞团，大家可以叫我小舞。第一届全宇宙 JavaScript 开发者大会三天后就要举行了，作为举办方的我简直忙极了。好在场地已经选好了，由我司生产的不写代码只写BUG牌人工智能机器人们已经在帮我布置会场了。本次大会场地定在了木星上，谁让地球上根本没办法容纳几亿来自五宇四宙观众的场地呢。作为第一届在外星球上举办的技术大会，我得把准备工作做足了才行，可千万不能丢了我们地球人的脸。这不，讲者的演讲稿都还没有发给我呢，我得赶紧去催催。
大家好，我是尼古拉斯·D·路飞，大家可以叫我路飞。对，隔壁海贼王片场的蒙奇·D·路飞和我并没有什么关系。（观众：没有关系对毛对！）作为名字带D致力成为JS王的男人，我很荣幸被邀请成为第一届全宇宙 JavaScript 开发者大会的演讲嘉宾。本次我要分享的内容是《去中心化的JS在地球上的运用》。这个内容其实之前我已经分享过，我只要用我之前的 PPT 更新下就好啦，so eas……等下，我的文档呢！！！此时天空中响起了一声系统提示：“尊敬的 VIP 用户您好，由于您的会员已到期，我们已任性地将您的资料全部都清空叻！”所以老天这是要我三天之内把 PPT 准备好的意思？我此时的心情只能如下图了。
Web开发过程中离不开调试，WebView 页面开发更是如此。本篇会和大家讲述在 iOS WebView 中一般是如何调试的。其实除去系统差异带来的区别之外，两者调试的原理上其实都差不多。
抓包即我们查看下 WebView 中的所有网络请求，在很多无法获取到机器的时候非常有用。通常页面行为不正常往往是接口请求的参数不正确，或者是接口返回的数据有异常。甚至于页面行为存在打点，根据打点请求来判断行为是否正常。通过这种“望闻问切”的方式，有些问题能够浮出水面。市面上抓包软件很多，Windows 上大家一般都是用 Fiddler, Mac 上则使用 Charles，还有其它的这里就不一一列举了。不过软件很多原理确实一样，简单的说来则是使用 HTTP 代理将所有的请求转发到软件记录本次 HTTP 请求的相关数据。
首先我们需要保证手机和电脑在同一个局域网中，软件中开启 Proxy 配置，这里以 Charles 为例，如图勾选"Enable transparent HTTP Proxying"即可。然后手机 WiFi 上配置 HTTP 代理 IP 为你的电脑 IP，端口为刚才软件中配置的端口（默认8888）。配置完后如无问题就可以在软件中看到请求流了。我们可以类似于 Chrome 开发者工具中的 Network 一样详细的查看请求的请求报文和响应报文。
WebView 是一个客户端浏览器控件，可以实现加载并渲染网页的逻辑。但是这个控件并不能完全同等于浏览器，而且我们页面的一些行为会依赖客户端的交互所以我们需要在 WebView 环境中进行调试。下面我就来说一说简单的 WebView 调试方法。
抓包即我们查看下 WebView 中的所有网络请求，在很多无法获取到机器的时候非常有用。通常页面行为不正常往往是接口请求的参数不正确，或者是接口返回的数据有异常。甚至于页面行为存在打点，根据打点请求来判断行为是否正常。通过这种“望闻问切”的方式，有些问题能够浮出水面。市面上抓包软件很多，Windows 上大家一般都是用 Fiddler, Mac 上则使用 Charles，还有其它的这里就不一一列举了。不过软件很多原理确实一样，简单的说来则是使用 HTTP 代理将所有的请求转发到软件记录本次 HTTP 请求的相关数据。
首先我们需要保证手机和电脑在同一个局域网中，软件中开启 Proxy 配置，这里以 Charles 为例，如图勾选"Enable transparent HTTP Proxying"即可。然后手机 WiFi 上配置 HTTP 代理 IP 为你的电脑 IP，端口为刚才软件中配置的端口（默认8888）。配置完后如无问题就可以在软件中看到请求流了。我们可以类似于 Chrome 开发者工具中的 Network 一样详细的查看请求的请求报文和响应报文。
前文我们介绍了 Android 的 WebView 交互方式，iOS 从原理上来说和 Android 还是非常类似的。在 iOS 中 WebView 需要分为UIWebView 和 iOS8 中新增的 WKWebView 两种类型。其中 WKWebView 相较于 UIWebView 优势在于能够直接使用系统 Safari 渲染引擎去渲染页面，支持更多的 HTML5 特性，渲染性能也会更好点。由于对 iOS 开发了解不太多，以下的代码大多是网络整理，没有 swift 的实现，如果有任何错误还请及时联系。
两个 WebView 类型提供了不同的调用方式，但是基本上可以归类成以下两种：
在 UIWebView 中，iOS7+ 提供了 JavascriptCore 让我们能够直接在 WebView 中获取到 JSContext，也就是当前执行环境的 JS 上下文。在这里我们就可以获取到对应的 JS 方法并执行，是非常高效的执行方式。同时这种方式的好处是能够拿到 JS 执行的结果，并转换成对应的 JS 类型。定义好 jsContext 之后就可以调用 evaluateScript 方法来执行 JS 了。
- (void)webViewDidFinishLoad:(UIWebView *)webView
{
JSContext *jsContext = [self.webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];
//设置JS执行报错捕获
[self.jsContext setExceptionHandler:^(JSContext *context, JSValue *exception){
NSLog(@"%@", exception);
}];
JSValue *value = [self.jsContext evaluateScript:@"document.title"];
self.navigationItem.title = value.toString;
}
| Objective-C 数据类型 | 对应 JavaScript 数据类型 |
|---|---|
| nil | undefined |
| NSNull | null |
| NSString | string |
| NSNumber | number, boolean |
| NSDictionary | Object object |
| NSArray | Array object |
| NSDate | Date object |
| NSBlock | Function object |
| id | Wrapper object |
| Class | Constructor object |
WebView 是移动端应用中的一个控件，提供了类似浏览器可以在 App 中加载网页的功能。现在市面上很多应用都会使用这种方式内嵌一些 h5 页面用来实现产品功能。使用这种方式带来的好处就是支持快速迭代更新，并且页面的功能是全网升级。当然目前 RN 和 Codorva 给我们带来的热更新方案也是可以的，只是目前 Apple 的态度很拒绝，这里我们略过不表。在 WebView 中的网页势必存在和客户端进行交互的动作，进行数据的共享。下面我们就来说说 Android WebView 中 JS 和 Native 的交互方式。
我们明白 WebView 其实就是在加载网页，所以客户端可以直接访问 javascript:console.log('hello') 这样的伪 URL 即可实现在页面注入需要执行的 JS 代码。调用方法如下：
WebView webview = (WebView) findViewById(R.id.webView);
webview.loadUrl("javascript:console.log('hello')");
这样我们就实现了调用 JS 的目的了。loadUrl() 的方案从另外一个角度来看可以算是 hack 方案了，对客户端来说，他们的 JS 交互本质上其实就是一个拼接 JS 字符串的过程。
刚才我们也说了 loadUrl() 不是 Android 的正经解决方法。好在官方也想到了这点，在 Android 4.4+ 之后，官方给提供了原生的方法支持调用，那就是 evaluateJavascript()。这个方法最大的好处就是能够直接在一次执行的时候获取到 JS 返回的结果。如果是使用 loadUrl() 的方式的话，执行完后对客户端来说这句话就结束了，如果想要拿到返回的结果的话另外需要 JS 调用客户端的方法返回。