一个人做一个项目，效率是最高的，各模块间的接口，前后端联调，产品策略，视觉还原，灰度部署方案，运营方案，都在一个人脑里，各块以毫秒级速度进行沟通，瞬间能完成，这里的沟通成本是没有的。

一旦涉及到团队合作做一个项目，沟通成本就上来了，随着项目越来越大，分工越来越细，项目的沟通也细分了很多个层级，同个小团队间的沟通最快，然后是跨团队，跨部门，跨事业群，跨公司。而这里的沟通往往除了项目本身确定性的方案对齐外，更多的是其他额外的不确定因素，像任务排期（优先级不统一）、权力和意愿（不配合，层层批准）、信息不对称（不知道谁负责，不知道为什么这样做）、意见不统一等，导致沟通成本不可控，一个中大型公司很大一部分工作就花在研究如何减少沟通成本上。

技术层面上，接口封装就是减少沟通成本，省去不同模块的的开发者之间沟通细节的成本。全栈也是种减少沟通成本的方式，一个前端页面，是跟其他页面需要沟通协调的内容多，还是跟后端联调接口的沟通多？大部分情况是后者，所以如果前后端一个人做，可以省去这里的沟通成本。产品PRD/运营方案文档/统一的视觉规范等自然也是为了减少沟通而产生的。

非技术层面上，很多组织架构的调整都是在寻找减少沟通成本以提高效率，像腾讯早期各产品的交互和视觉设计由一个部门负责，其他产品团队以提需求的方式跟设计团队合作，好处是专业度高和风格统一，结果每个产品跨部门沟通成本太高，现在都改成各个产品线配自己的设计团队。对于大公司，目前看到的比较好的常见做法是，大型固定的业务成立部门，备齐所有工种人员，包括技术产品设计运营等，需求在部门内完成，减少跨部门沟通成本。各工种仍是独立自己的团队，比如技术团队/产品团队，保持自己的专业度，而做一个个具体项目时，通常需要各团队人员协作完成，可以各团队抽人组成虚拟组，配一号位人员总体负责，减少因为跨团队跨组带来的沟通成本。不过这个虚拟组和一号位人员得有组织上/实际行动保证才能起作用，否则真的是纯虚拟了，变成仍然是跨团队沟通。

一些公司的精英招聘策略也是能有效减少沟通成本，若一个人能力强工作效率高，产出能顶两个人，那实际上加上减少的沟通成本，带来的收益远不止两倍，而若招平庸或差一些的人，跟团队间沟通效率不匹配，带来的沟通成本上升效率下降也不止一个人力的范围内。一个组织大了就一定会有各种人相关的问题需要解决，精英小团队各种好，不好的是招聘困难，以及在铺业务时还是会面临人力不足问题导致扩招，难以控制。

国内厂商联合起来推出快应用，说说看法。

与小程序相同点

1. 前端技术栈：毫无疑问所有类似方案都只能是前端技术栈，从社区成熟度，开发者接受程度，开发效率各方面没有对手。
2. native 能力：都提供了比 web 更多的 native 能力。
3. 即时/离线：跟 web 一样即点即用，跟 native 一样离线使用，前提是应用不复杂，体积限制在1M以内，当然以后复杂了也可以做分包。

与小程序的不同点

1. native 渲染：快应用使用前端技术栈开发，native 渲染，性能体验会比较好，看代码挺像是直接拿 RN 改改用了，不过发布会上没提到 RN，而小程序目前是webview渲染。
2. 自定义框架和规范：与小程序不同的开发框架和规范，快应用更像 vue 的写法，文件结构不一样，样式上因为使用native渲染，只支持 flexbox 布局，CSS 属性的支持程度上不如 webview 渲染的小程序，能力会弱一些。
3. 系统级能力：目前看起来小程序没有的只有deeplink和push，通过url唤起快应用的deeplink，以及跟原生一样的push能力。

优势

1. 流量：目前看起来，对开发者来说，使用快应用最大的理由就是厂商的流量扶持，而这是不是个优势还得看各厂商的扶持力度。
2. 反垄断：小程序腾讯有绝对控制权，开发者把身家性命都放在腾讯的平台里，可能会导致任人宰割，自身对应用的控制力也弱，多一个渠道多一份活路。
3. 其他：native渲染，deeplink入口，原生桌面入口，push能力这些目前相对小程序算是有一些优势。

劣势

1. iPhone：联合再多的厂商，也联合不到mg游戏网站，中国高端手机市场 iPhone 份额高达85%，做快应用要不就是放弃这部分用户，要不就是针对 iPhone 再做一套，这个成本划不划算只能看能从厂商流量扶持里拿到多少好处，否则为什么不开发小程序。
2. 跨公司合作：一个大公司内跨部门协作都困难，何况跨N个公司的合作，而且还没有一个站在上一层的领导者，要做成非常困难。
3. 社交：快应用缺乏微信的社交场景能力和传播手段，推广拉新成本仍不低。

看法

移动开发向前端技术栈倾斜，原因：

1. 超级APP，业务越来越多，为了减体积和动态发布能力，大部分业务使用前端技术栈开发。
2. 普通APP，拉新成本高，用户装APP的意愿低，开始尝试转向即开即用的H5/小程序和类似平台拉新。

普通业务开发，按目前趋势越来越倾向前端技术栈，即使是独立APP，展示型业务在 APP 里也会倾向用前端技术栈开发，从开发效率/跨平台/动态性都很有优势，劣势是性能体验稍差，这点长期可以靠机器硬件的提升，短期可以用类似RN方案。

小程序为这样的需求提供了个很好的平台，但缺陷是开发者对应用没有控制力，无法 push 触达唤起用户，入口也一般，生命线掌握在腾讯上，快应用可以弥补这些缺陷，提供了另一个选择，不过不支持 iPhone 仍是个几乎无法解决的致命缺陷，加上上述提到的劣势，总体上不看好。这种事可能得由 google 联合mg游戏网站一起做才有戏。

native VS web 这个话题从 08/09 年开始开始到现在都没有结束，因为各有不小优势，即使是现在 web 技术栈占上风，原生 APP 的性能体验，快捷入口，品牌认知这些优势仍是不小，而且技术的发展同时给 native 和 web 两种模式提供了利好，并没有倾向其中一方：对于 web，硬件提升使得体验越来越好。对于 native，运营商无限流量的时代和越来越大的存储空间使得用户装 APP 成本下降，这两个开发模式在很长时间内仍是融合的状态。

过年前去日本北海道浪，说了三四年要去日本，这次终于成行了，第一次去日本，写篇体验杂记水文。作为一个从小受日本动漫和游戏熏陶的人，本来想去东京秋叶原这些地方，季节原因还是先去北海道转转。

玩

北海道玩的就是雪和温泉，在登别玩白花花软绵绵厚厚的雪，走在洞爷湖边上纯白的湖畔小道，在札幌白色恋人公园体验大雪纷飞，确实都挺美的。北海道温泉特别多，连札幌市内的酒店都有温泉，不过还是登别的温泉最好，在室外天寒地冻边泡温泉边欣赏旁边雪景是挺不错的体验。不过温泉只能全裸不能穿泳衣导致必须男女分浴这点搞得挺没意思。
（更多…）

一般开发一个 APP，会直接调用系统提供的网络请求接口去服务端请求数据，再针对返回的数据进行一些处理，或者使用AFNetworking/OKHttp这样的网络库，管理好请求线程和队列，再自动做一些数据解析，就结束了。

但对于一些大型 APP，还会想针对网络的一些问题进行进一步优化，包括：

1. 速度：网络请求的速度怎样能进一步提升？
2. 弱网：移动端网络环境随时变化，经常出现网络连接很不稳定可用性差的情况，怎样在这种情况下最大限度最快地成功请求？
3. 安全：怎样防止被第三方窃听/篡改或冒充，防止运营商劫持，同时又不影响性能？

对基于浏览器的前端开发来说，网络这块能做的事情很少，但对于客户端 APP 来说，整个网络请求过程是自由控制的，可以做很多事情，很多大型 APP 都针对这三个问题做了很多网络层的优化，一些新的网络层协议像 HTTP2 / QUIC 也是在这些方面进行了不少优化，在这里边mg游戏平台官方网站边整理，大致列举一下常见的做法。

速度

正常一条网络请求需要经过的流程是这样：

1. DNS 解析，请求DNS服务器，获取域名对应的 IP 地址。
2. 与服务端建立连接，包括 tcp 三次握手，安全协议同步流程。
3. 连接建立完成，发送和接收数据，解码数据。

这里有明显的三个优化点：

1. 直接使用 IP 地址，去除 DNS 解析步骤。
2. 不要每次请求都重新建立连接，复用连接或一直使用同一条连接(长连接)。
3. 压缩数据，减小传输的数据大小。

逐条来看能做什么。

1.DNS

DNS 完整的解析流程很长，会先从本地系统缓存取，若没有就到最近的 DNS 服务器取，若没有再到主域名服务器取，每一层都有缓存，但为了域名解析的实时性，每一层缓存都有过期时间，这种 DNS 解析机制有几个缺点：

1. 缓存时间设置得长，域名更新不及时，设置得短，大量 DNS 解析请求影响请求速度。
2. 域名劫持，容易被中间人攻击，或被运营商劫持，把域名解析到第三方 IP 地址，据统计劫持率会达到7%。
3. DNS 解析过程不受控制，无法保证解析到最快的IP
4. 一次请求只能解析一个域名。

为了解决这些问题，就有了 HTTPDNS，原理很简单，就是自己做域名解析的工作，通过 HTTP 请求后台去拿到域名对应的 IP 地址，直接解决上述所有问题：

1. 域名解析与请求分离，所有请求都直接用IP地址，无需 DNS 解析，APP 定时请求 HTTPDNS 服务器更新IP地址即可。
2. 通过签名等方式，保证 HTTPDNS 请求的安全，避免被劫持。
3. DNS 解析由自己控制，可以确保根据用户所在地返回就近的 IP 地址，或根据客户端测速结果使用速度最快的 IP。
4. 一次请求可以解析多个域名。

其余细节就不多说了，HTTPDNS 优点这么多，几乎成为中大型 APP 的标配。至此解决了第一个问题 — DNS 解析耗时的问题，顺便把一部分安全问题 — DNS 劫持也解决了。

2.连接

第二个问题，连接建立耗时的问题，这里主要的优化思路是复用连接，不用每次请求都重新建立连接，如何更有效率地复用连接，可以说是网络请求速度优化里最主要的点了，并且这里的优化仍在演进过程中，值得了解下。

keep-alive

HTTP 协议里有个 keep-alive，HTTP1.1默认开启，一定程度上缓解了每次请求都要进行TCP三次握手建立连接的耗时。原理是请求完成后不立即释放连接，而是放入连接池中，若这时有另一个请求要发出，请求的域名和端口是一样的，就直接拿出连接池中的连接进行发送和接收数据，少了建立连接的耗时。

实际上现在无论是客户端还是浏览器都默认开启了keep-alive，对同个域名不会再有每发一个请求就进行一次建连的情况，纯短连接已经不存在了。但有个问题，就是这个 keep-alive 的连接一次只能发送接收一个请求，在上一个请求处理完成之前，无法接受新的请求。若同时发起多个请求，就有两种情况：

1. 若串行发送请求，可以一直复用一个连接，但速度很慢，每个请求都要等待上个请求完成再进行发送。
2. 若并行发送这些请求，那么首次每个请求都要进行tcp三次握手建立新的连接，虽然第二次可以复用连接池里这堆连接，但若连接池里保持的连接过多，对服务端资源产生较大浪费，若限制了保持的连接数，并行请求里超出的连接仍每次要建连。

对这个问题，新一代协议 HTTP2 提出了多路复用去解决。

多路复用

HTTP2 的多路复用机制一样是复用连接，但它复用的这条连接支持同时处理多条请求，所有请求都可以并发在这条连接上进行，也就解决了上面说的并发请求需要建立多条连接带来的问题，网络上有张图可以较形象地表现这个过程：



HTTP1.1的协议里，在一个连接里传送数据都是串行顺序传送的，必须等上一个请求全部处理完后，下一个请求才能进行处理，导致这些请求期间这条连接并不是满带宽传输的，即使是HTTP1.1的pipelining可以同时发送多个request，但response仍是按请求的顺序串行返回，只要其中一个请求的response稍微大一点或发生错误，就会阻塞住后面的请求。

HTTP2 这里的多路复用协议解决了这些问题，它把在连接里传输的数据都封装成一个个stream，每个stream都有标识，stream的发送和接收可以是乱序的，不依赖顺序，也就不会有阻塞的问题，接收端可以根据stream的标识去区分属于哪个请求，再进行数据拼接，得到最终数据。

解释下多路复用这个词，多路可以认为是多个连接，多个操作，复用就是字面上的意思，复用一条连接或一个线程。HTTP2这里是连接的多路复用，网络相关的还有一个I/O的多路复用(select/epoll)，指通过事件驱动的方式让多个网络请求返回的数据在同一条线程里完成读写。

客户端来说，iOS9 以上 NSURLSession 原生支持 HTTP2，只要服务端也支持就可以直接使用，Android 的 okhttp3 以上也支持了 HTTP2，国内一些大型 APP 会自建网络层，支持 HTTP2 的多路复用，避免系统的限制以及根据自身业务需要增加一些特性，例如微信的开源网络库 mars，做到一条长连接处理微信上的大部分请求，多路复用的特性上基本跟 HTTP2 一致。

TCP队头阻塞

HTTP2 的多路复用看起来是完美的解决方案，但还有个问题，就是队头阻塞，这是受限于 TCP 协议，TCP 协议为了保证数据的可靠性，若传输过程中一个 TCP 包丢失，会等待这个包重传后，才会处理后续的包。HTTP2的多路复用让所有请求都在同一条连接进行，中间有一个包丢失，就会阻塞等待重传，所有请求也就被阻塞了。

对于这个问题不改变 TCP 协议就无法优化，但 TCP 协议依赖操作系统实现以及部分硬件的定制，改进缓慢，于是 GOOGLE 提出 QUIC 协议，相当于在 UDP 协议之上再定义一套可靠传输协议，解决 TCP 的一些缺陷，包括队头阻塞。具体解决原理网上资料较多，可以看看。

QUIC 处于起步阶段，少有客户端接入，QUIC 协议相对于 HTTP2 最大的优势是对TCP队头阻塞的解决，其他的像安全握手 0RTT / 证书压缩等优化 TLS1.3 已跟进，可以用于 HTTP2，并不是独有特性。TCP 队头阻塞在 HTTP2 上对性能的影响有多大，在速度上 QUIC 能带来多大提升待研究。

3.数据

第三个问题，传输数据大小的问题。数据对请求速度的影响分两方面，一是压缩率，二是解压序列化反序列化的速度。目前最流行的两种数据格式是 json 和 protobuf，json 是字符串，protobuf 是二进制，即使用各种压缩算法压缩后，protobuf 仍会比 json 小，数据量上 protobuf 有优势，序列化速度 protobuf 也有一些优势，这两者的对比就不细说了。

压缩算法多种多样，也在不断演进，最新出的 Brotli 和Z-standard实现了更高的压缩率，Z-standard 可以根据业务数据样本训练出适合的字典，进一步提高压缩率，目前压缩率表现最好的算法。

除了传输的 body 数据，每个请求 HTTP 协议头的数据也是不可忽视，HTTP2 里对 HTTP 协议头也进行了压缩，HTTP 头大多是重复数据，固定的字段如 method 可以用静态字典，不固定但多个请求重复的字段例如 cookie 用动态字典，可以达到非常高的压缩率，这里有详细介绍。

通过 HTTPDNS，连接多路复用，更好的数据压缩算法，可以把网络请求的速度优化到较不错的程度了，接下来再看看弱网和安全上可以做的事情。

弱网

手机无线网络环境不稳定，针对弱网的优化，微信有较多实践和分享，包括：

1. 提升连接成功率
   复合连接，建立连接时，阶梯式并发连接，其中一条连通后其他连接都关闭。这个方案结合串行和并发的优势，提高弱网下的连接成功率，同时又不会增加服务器资源消耗：
   
   
2. 制定最合适的超时时间
   对总读写超时(从请求到响应的超时)、首包超时、包包超时(两个数据段之间的超时)时间制定不同的计算方案，加快对超时的判断，减少等待时间，尽早重试。这里的超时时间还可以根据网络状态动态设定。
3. 调优TCP参数，使用TCP优化算法。
   对服务端的TCP协议参数进行调优，以及开启各种优化算法，使得适合业务特性和移动端网络环境，包括RTO初始值，混合慢启动，TLP，F-RTO等。

针对弱网的这些细致优化未成为标准，系统网络库没有内置，不过前两个客户端优化微信的开源网络库 mars 有实现，若有需要可以使用。

安全

标准协议 TLS 保证了网络传输的安全，前身是 SSL，不断在演进，目前最新是 TLS1.3。常见的 http 就是 HTTP 协议加上 TLS 安全协议。

安全协议概括性地说解决两个问题：1.保证安全 2. 降低加密成本

在保证安全上：

1. 使用加密算法组合对传输数据加密，避免被窃听和篡改。
2. 认证对方身份，避免被第三方冒充。
3. 加密算法保持灵活可更新，防止定死算法被破解后无法更换，禁用已被破解的算法。

降低加密成本上：

1. 用对称加密算法加密传输数据，解决非对称加密算法的性能低以及长度限制问题。
2. 缓存安全协议握手后的密钥等数据，加快第二次建连的速度。
3. 加快握手过程：2RTT-> 0RTT。加快握手的思路，就是原本客户端和服务端需要协商使用什么算法后才能加密发送数据，变成通过内置的公钥和默认的算法，在握手的同时就把数据发出去，也就是不需要等待握手就开始发送数据，达到0RTT。

这些点涉及的细节非常多，对 TLS 的介绍有一篇雄文，说得很详细，在此推荐。

目前基本主流都支持 TLS1.2，iOS 网络库默认使用 TLS1.2，Android4.4 以上支持 1.2。TLS1.3 iOS 还处于测试阶段，Android 未查到消息。对于普通 APP，只要正确配置证书，TLS1.2 已经能保证传输安全，只是在建连速度上会有所损耗，有一些大型 APP 像微信就自行实现了 TLS1.3 的部分协议，早一步全平台支持。

最后

网络优化这个话题非常庞大，本文只是在mg游戏平台官方网站过程中从优化思路上列举了目前业界常见的优化点，还有很多细节很多更深入的优化没涉及到，网络层实践开发经验不足，若有错误欢迎指出。

工作

公司

今年最大的变化，自然是换工作了，回腾讯三年，度过了痛苦期，成长期和安逸期，腾讯给我足够的机会和支持，我给腾讯足够的输出，离开时只有感激没有遗憾。

来到蚂蚁，体验大阿里的工作方式，跟腾讯的差别非常大，或者说跟微信事业群的差别很大，很多是业务形态的差别导致，体验不同公司不同文化，不同的成事逻辑，挺有意思的。有几点较有体会：

1. 庞大，阿里和蚂蚁从人员到各种系统各种方案都很庞大，从外部看阿里商业布局的风格就能看出来，都会铺得很大，有很多可以mg游戏平台官方网站的地方。腾讯擅长快工出细活，靠产品取胜，阿里擅长组织力量办大事，靠战略取胜。
2. 变化，拥抱变化是阿里一大特点，组织架构/人员调整是分分钟的事，战略调整也不少，虽然成本很高，但可以跟上快速变化的时代。
3. 沟通，第一点庞大带来的副作用，庞大的人员配备和异地开发带来很大的沟通成本，可以说是大公司病，可能可以通过第二点变化去缓解，通过变化去寻找沟通成本最低的人员架构。
4. 自由，自由度上感觉比腾讯更像硅谷公司，移动办公能力很发达。
5. 全栈，技术栈的切换非常方便，也很鼓励全栈发展，技术转产品也没有问题。这也可能是所处团队的个例。
6. 江湖，江湖气息浓，有时会有山头林立的感觉。
7. 人才，有没有感觉很多认识的人都进了阿里？阿里的人才真心多，很能招揽和留住人才，庞大的体系，快速变化的职位，内部快速的流动，很有活力。在大公司的好处，跟很多聪明人一起工作，能学到他们做人做事方法和思维模式。
8. 反思，反思能力很强，一旦犯错误会有各种复盘，导致韧性很强，导致支付宝被微信打趴在地上后还能满血复活活奔乱跳。

进来经历996时期和业务调整重心转移时期，每个地方都有当下的局限困境和机会，努力去做力所能及的事。

JSPatch

JSPatch 在年初达到顶峰，随后遭遇mg游戏网站一纸文书直接禁用，很让人吃惊，自己想想其实也合理，JSPatch 脚本权限很大，只要接入过程没考虑好安全问题，就可能会被黑客利用，若大部分 APP 都接入，并且无法确保大家接入的方式是否安全，就会成为 iOS 系统级的一个安全隐患，必须控制，一刀切对mg游戏网站来说是最简单的方法，相关想法我也详细写过文章，就不再说了。对这种做法我是情绪稳定，只要是合理的都能接受。目前若要使用 JSPatch 还是可以接入 JSPatch 平台正常使用的，平台的接入方案可以解决这类安全隐患。

至今我做过的两个算是有点影响力的作品，推特中文圈和 JSPatch，都是理论上无法封锁的东西，都被用政策的手段打压，真是巧合，希望下一个作品可以不再这样。

生活

杭州

全家搬到杭州，付出的代价不小，如果只是两个人很好办，但有了小孩离家乡远就很不方便，老人也不适应杭州，很困难，明年还有小孩上幼儿园等问题接涌而来，还没想好怎么办。不过体验另一个城市的感觉还是很新鲜很好的，杭州一片生机勃勃，我也很喜欢跟来自全国各地多样化的同事们工作，时不时长长见识。

杭州目前还是个小城，能骑着电动车上下班，挺惬意，要是再租得近点，像同事那样中午回家吃饭都可以。不过骑电动车也只是天气好的时候惬意，不好的时候风吹日晒雨淋夏天被烤成炭冬天冻成翔，0度到42度，挺惨，这种天气还是坐在汽车里好，塞车都乐意。

抽空去了杭州各个景点，西湖，西溪湿地，小河直街，湘湖，千岛湖，乌镇，其实在杭州生活，也没多少个周末出去玩的，西湖那么大也就去了两次，可能是我们比较懒和宅。时隔7年再次去乌镇，感觉依然很好，跟其他古镇还是有差别的，特别是晚上和清晨寂静的时候，若今年杭州有下雪，还想再去一次。

上海

今年去了三次上海，两次出差一次游玩，感觉像乡下进城，来杭州时感叹超级商场真多，到上海发现杭州是小儿科，上海到处都是大商场，也不知道哪来那么大的消费力，感觉跟广州完全不一样，是江浙沪一带人民的消费水平特别高还是怎么着。

蚂蚁上海办公地点在上海中心大厦，感觉很了不得的地方，第一次进去还被叫住问我是干啥子的，尴尬。站在大厦楼下往上望有种很威严雄伟的感觉，像是个奇迹，远远望过去天上有这么个大柱子也是有种魔幻感，人在这种大建筑下面，会觉得自己很渺小，崇拜和信仰就来了，像金字塔教堂一类的建筑也是这个目的吧，我还挺喜欢看大型建筑的。

苏州

苏州离杭州只有一百多公里，随便开个车就到了，元旦假期跟家人在苏州度过，去寒山寺，苏州园林，同里古镇，感觉跟杭州上海的一些景点差不多，只是寒山寺有枫桥夜泊加持好点。游玩碰到今年江浙一代空气最差的时候，直接pm两百多重度污染，比较减分。

小孩

最近一个月小屁孩说话能力进步很快，各种发音都会学着说了，语言这种能力只要一开窍就学得特别快。看着她成长很幸福，经常被她萌到，带来很多快乐，这货特别喜欢出去玩，特别喜欢吃，很喜欢看书写字听故事，不过小小年纪就有不小的脾气，还提前n年进入叛逆期，怎样教育真是个难题。今年因为工作原因期间有两三个月时间小孩放在老家，错过小孩的成长期这个代价真是非常大，希望明年能减少不在身边的时间。

其他

今年只在江浙一带转转，没有旅游过的感觉，旅程倒是创新高，各种办事和出差游玩，在陆丰/广州/杭州/苏州/上海/合肥/北京多地来回跑。

离开微信读书，加上在杭州没有坐地铁时的阅读时间，直接就没看书了，断断续续看的几本也没看完。不过《禅与摩托车维修艺术》这本书倒是很合我胃口，是本可以看多几次的书。

做微信读书时多看书，在蚂蚁金服就多关注金融知识，确实每个人都无法避开金融，不关注金融的人口袋里的现金就会流向关注的人，置身其中无法逃避，有时觉得挺有趣，有时觉得挺烦，动不动房价涨一倍，腾讯阿里涨一倍，贪婪和恐惧算是小体验过了，理财观念还在逐渐形成。

去年年终总结提到自己的一些缺陷问题，今年回顾起来并没有多少进步，或者说有意识去纠正磨炼的次数不多，要改变确实是困难，不是一年半载的事，特别是在这个大家都在焦虑快跑的时代里。

根据过往经验年末立 flag 通常没什么用，希望2018年保持进步。

在杭州打车实在是困难，前两天打滴滴，排队二十几分钟，打到车后司机距离也就两公里，说不来，我说我等太久了还是过来吧，他说不行，还让我取消，我不取消，司机就开始破口大骂，挂了电话还继续在滴滴上发语音骂，嚣张至极。

虽然当时很生气，但过后想想觉得又挺合理，在资源匮乏的时候，拥有资源方就是大爷，如果这时候没有任何东西可以约束这位大爷，自然随心所欲不爽就发泄，反正没有任何损失，还能获得某种优越感。怎样解决这种问题？滴滴一直以来做的事情是提高资源供给（引入快车专车顺风车）和提高资源分配效率，去解决出行供不应求导致出租车司机一直是大爷的情况，确实是很大程度上改善了，但在高峰期还是资源不足，这种情况下滴滴作为几乎垄断的平台，用评价体系/奖惩标准等手段是可以避免司机过于强势的，只是看起来滴滴还没做好。

滴滴已经是互联网改变线下资源的典范了，仍有一些资源限制导致的问题，互联网+线下还是有很大局限。互联网提供的数字化服务资源是无限的，成本也并不高，而线下资源始终是有限的，十亿人用微信没问题，十亿人都要打车，都想找场馆踢球，都想看病找好老师，可不像数字服务一样都可以满足得了，人力资源和土地资源总是有限和稀缺的，对这两点依赖越强的行业，互联网带来的提升就越少，例如好医生资源匮乏、球场土地资源匮乏、城市道路资源匮乏，互联网想要改善都很困难，只能有限地提升资源分配的效率和体验，很容易就达到瓶颈。

人和土地是两大问题，城市的土地资源靠纵横两个方向的延伸解决，纵向是越来越高的大厦提高单位面积利用率，横向是越来越发达的交通网络提升可触达的面积，而人力资源方面，传统方法是靠加强教育去提升优质人力资源的供给，效率底下，而现在有另一个看得见曙光的方向，就是AI。其实人力资源就是智能资源，像教师/医生/律师/司机/理财师，大家需要的是他们的智能去解决问题，而 AI 看起来是有可能可以提供这些智能的，AI 最大的威力是数字世界的无限供给，只要一个 AI 程序在某个行业有所突破，就可以爆炸式直接解决行业的人力资源问题，诱惑力相当大，而最近 AI 领域出现的进展让人看到了这种可能，这也是 AI 被看重的原因之一吧。

第一次来上海，第一次参加 QCon，说说观感。

AI

主讲 AI 的主题占到了差不多四成，虽然有主办方选题偏向的因素，但还是能说明 AI 的热度确实很高，是当前最火热的技术领域，火到感觉我作为客户端开发，再不学AI就要失业了。虽然有些虚火的嫌疑，但AI相关技术确实是解决了不少传统做法难以解决的问题。

开场危辉教授讲述人工智能这个概念的历史，表示目前人工智能能解决的问题仍只是在一些有限场景下有一些进展，只能解决一些明确的特定的问题，像取得突破的围棋只是因为它是规则简单边界明确的特定领域，但真正的通用人工智能关键的几个问题一个都没有解决，过去二十年人工智能流行过很多技术，连当年OOP面向对象都被认为可以实现人工智能，而现在流行的是深度mg游戏平台官方网站，有人说下一个流行的会是量子计算，人工智能就像一个圣杯，大家一直用各种技术方案在追逐，目前大家觉得接近了，但实际上我们离真正的模拟人脑能解决通用问题的人工智能还差得很远。

教授是从学术界的角度，从准确的定义上去说人工智能，当然没有错，但实际上一个流行词汇，很可能跟它实际所指的事物并不完全相符，只是方便炒作或方便理解。例如共享单车不是真的共享，HTML5不是HTML一样，现在流行的很多场景下说的人工智能也并不是真的指可以代替人脑解决通用问题的人工智能，主要指靠各种机器mg游戏平台官方网站算法去解决一些特定领域的传统算法难以解决的问题，例如图像识别分类，自然语言/语音识别，兴趣推荐等，查了下业内对这些应用还有个稍微准确点的称呼，叫弱人工智能(弱智???)。从业人士应该不会弄不清楚，也就一些媒体忽悠大众哗众取宠的时候弄混。

会场上听到很多 AI 的应用，paypal 用它做反欺诈反洗钱服务，微博用来辅助检测恶意用户，流利说训练出适合中国人口音的英语发音打分模型，腾讯用AI+ROI把视频编码带宽降低20%，也做了AI自动裁剪视频生成短视频，Pinterset 做推荐系统和拉活，QQ邮箱用来优化文档边缘识别，等等，有些公司已经以AI为中心为业务提供各种支持，给人感觉产品要是不结合AI做点什么都不好意思拿出来说，真有一种拿着锤子四处寻找钉子的感觉。

我还没有实践过 AI 相关项目，听这些主题有些尴尬，只有笼统的观感。个人感觉，程序员就算不投身 AI 领域，也应该要了解下 AI 相关技术，了解在现有技术下的 AI 能做什么，毕竟它的套路跟传统确定性算法不一样，了解了才能在解决自身业务问题的时候多一个思路。现阶段的 AI 虽然没达到可以解决通用问题的程度，但对于那些定义和目标明确的问题都是可以或者说有希望解决的。

AI First

有公司已经从 Mobile first 转为 AI first，iPhone 刚出来前几年，大家对移动端还算挺重视，各个大公司会成立移动事业群/移动部门/移动组，一小拨人专门开发各个业务需要的移动产品，后来移动端越来越受重视，变成 mobile first，不再是专门一群人开发各个业务的移动产品，而是每个业务都自己组建移动端团队，移动渗透到公司每个团队，才能跟上时代。现在 AI First 也是有这样的感觉，现在还处于一个公司里一小拨人专门在做 AI 相关的工作，后续可能会发展到每个业务团队都需要具备 AI 的研发能力，AI 渗透到每个业务团队，才能应用 AI 技术去结合自身业务实现价值。

智能音箱

阿里分享和宣传了 AliGenie，AliGenie 类似 Siri，自然语言处理开放平台，目前应用在智能音箱天猫精灵上，类似 Homepod，以及接入阿里智能硬件，类似 Homekit，真是跟mg游戏网站干上了。

说说个人看法，智能音箱被认为可能是下一个入口，语音不仅包含的信息丰富，还解放了双手，相比键盘/鼠标/触摸灯方式，很多场景下效率提升很多，方便快捷，用户习惯养成后，用户可能越来越多使用智能音箱去完成需求和触达信息，可能用它来购物/支付/打车/听新闻等等，成为下一个入口。看起来确实是很好，但语音助手 Siri 推出到现在已经七年，到现在还没有成为主流，身边使用的人很少，智能音箱会有戏吗？虽然语音很方便，但有两个致命缺陷，就是暴露隐私和骚扰旁人，很多场景下这个缺陷大过带来的便捷性，也就很难去使用和形成使用习惯。若要让语音助手成为入口，需要找到特定的应用场景才行，个人觉得汽车内较有机会，因为多是独处时间，没有隐私和骚扰的缺陷，眼睛和双手被霸占，空间也有限，不会有接收不到或要吼的情况，而面向家庭的智能音箱就难了。

AR/VR

VR 研发热度一直没有火起来，感觉现在做VR有点像功能机时代做手游，硬件环境没跟上，时机还太早，现场只有腾讯分享了下VR的探索，用于做身临其境的游戏直播体验。

AR因为mg游戏网站和谷歌相继推出 ARKit 和 ARCore 又受到关注，不过这次分享都没有这两者，AR 的应用稍微多一些，因为手机上就能实现，不用像 VR 那样主要靠硬件，阿里对 AR 的探索较多，从小游戏到图书增强到家装应用到开放体系，走得很远，在营销上已经有不少应用，不知道数据和效果怎样。

腾讯分享的云游戏是另一类前沿研究，通过视频回传游戏画面，随时随地只要有屏幕和网络就能玩任意游戏，也处于探索阶段，带宽成本高，解决延迟问题较困难，短期内没看到应用的前景，可能可以作为游戏试玩的方案。

前端/客户端

前端和客户端各只有4场分享，在整个QCon一百来场分享里占比可怜，真是药丸。当然技术媒体是追逐热点的，感觉这次追得有点过了，从旁人的反应来看效果不太好。

淘宝分享超级 App 的高可用性保障，也就是保障性能稳定性一整套系统，这块各个大APP都有自己的一套，趋于成熟，淘宝做得更细致些，除了性能数据的采集/监控和展示，也尝试在内存泄漏/资源泄漏/大图异常/线程异常等一些特定的问题上提升问题排查效率，通过记录堆栈追踪问题的来源，例如记录图片/线程/资源是在哪里创建的，从而能快速定位原因。为了解决一些很难排查的疑难杂症，做了更细致的追踪体系，毫秒级记录CPU/内存/存储，追踪方法调用和页面事件，收集数据后再通过分析引擎对比分析。

前端有两个新事物的实践分享，WebAssembly 字节码技术，饿了么于航实践和深入了解后表示 值得关注/标准未定/实践略坑，各大浏览器在实现的路上，短期内还没法用到生产环境。QQ 空间实践了 QUIC 协议，基于 UDP 改进的通信协议，解决 TCP 成为网络传输速度性能瓶颈的问题，目前应用上还有一些坑，用户的网络环境中 UDP 的端口可能会被禁，可能会被限速，也可能丢包率有异常，有些风险，另外目前移动端浏览器都不支持 QUIC，PC端只有少量个位数比例的用户支持，应用还不广泛。

前同事冯牮分享了在QQ邮箱客户端上实现 AI 辅助文档边缘检测。事先针对特定的问题，在后端训练出一个模型，再放到客户端上使用，使客户端本身具备 AI 的能力，这可能是客户端开发后续的一个方向。现在的应用场景是针对一些实时性要求高的，无法回传到后端进行计算的应用，像文档的边缘检测，以及支付宝出的扫描识花的功能，都是这种类型，其他的应用方式大家还在探索中。

其他

蘑菇街侯栋分享的关于黑产的攻防和产业链介绍挺有意思，社会上头脑灵活的人很多，有利益有漏洞就会被人钻，账号会被批量注册，有的用于刷单提升店铺销量信誉，有的通过批量退货赚取退货险的运费差价，有的配合假快递单号套取货品，惊讶于有人为了能套现电商信用卡的钱愿意付出30%的手续费，跟这帮人猫捉老鼠挺有趣的。

区块链有两个分享，都是宣传自家区块链云平台，云服务这个金矿也挺热的，只要自身搭建稍微有成本，就立马有人做出云服务（广告：JSPatch平台也算是热修复云服务）。粗略听下来只能知道区块链可以用于解决信任问题，有些数据放在一家公司里可能会被篡改，不受信任，用区块链可以解决这类问题，应用是可以很广泛的，我没完全搞懂区块链原理，就不多说了。

最后

去年参加 GMTC 有提到过对这种技术大会的看法，这种大会对广大技术人员自然是好的，各界讲师有动力精心准备演讲主题，输出很好的技术分享，但从参与者角度来说，如果单纯去听其实没什么用，时间成本高，单向分享也学不到什么，还不如后续看PPT和视频，参加线下分享会议最主要的还是面对面双向交流的机会，最好能看准人和主题和人，准备好具体问题过去交流，否则参加这个会议跟后续网上看PPT和视频唯一的区别就是更耗时间。

过来参加的大多是一线工程师，目测大部分是传统客户端/前端/服务端开发，而 QCon 的定位高端，现场听到不少人反馈听不懂/离实际太远/太高大上，也可能是AI的主题太多导致。从会场人数来看大伙喜欢听实践踩坑类接地气的主题，毕竟现场的CTO和架构师占比不会很高。本次 QCon 前端客户端相关主题太少，跟上一场 QCon 差别很大，导致作为客户端开发参加起来有些尴尬，希望下场选题上能再平衡下，祝 QCon 越办越好。

一直给自己定下每个月至少要有一篇博客文章的约定，无论是什么类型。这个月临到末尾，因故只发了半篇文章，必须再写一篇扯扯淡把这个空补上。

在杭州一直用电动车上下班，公司所在大楼楼下有电动车停车场，挺好的，不过有一点让人不爽，按这栋大楼规定的路线，电动车从公司骑出来需要绕一个大圈才能到出口，大概需要走300米，但是，如果你不按他规定的路线，逆行50米就可以到达出口。而这个逆行并没有任何危险：

1. 道路很宽，是单行道但宽得走两辆车没问题 。
2. 除了道路还有人行道，跟杭州大路非机动车道差不多宽。
3. 道路很空，在50米距离里人车都很少，很难碰到有人或有车的情况。

这种情况下，你会选择遵守大楼的规则走300米绕个圈，还是不遵守规则走个50米快速到达出口？我选择不遵守规则。但时不时电动车出口处有保安守着，勒令按规则走，挺蛋疼。

我觉得遵守一些不合理、损人不利己、有明显更好解决方案的规则并不是一个好的选择，对于这个案例，在那么宽的道路，只需要划出一小道双向通行的非机动车道就能解决问题了，对行人/机动车没有影响。而规划者不考虑改进这里的用户体验，执行者守着规则站在那里勒令大家遵守，在我看来是比较傻的。

这种情况跟一些蹩脚园林设计一样，草丛捷径被无数人踩出一条路，原本设计的路鲜有人行走，是该质疑行人素质，还是质疑设计者能力？我觉得是后者。

生活中碰到很多这种情况，设计者并不为用户考虑，理所当然地定了一些规则，用户遵守起来感觉像个傻子。像之前住的碧桂园楼盘，访客到门口，必须下车，排队登记，门口工作人员会根据报上来的房号，打电话联系业主，问是否可以让进，再开放行条，才肯让访客进。以给业主和访客添堵的方式去保证小区的安全和人流，这里能让双方都满意的解决方案太多了，但没有人想改进。

而互联网世界则不是这样，不合理的设计大多会被改进，无脑规则并不常见，一是数字世界改进成本低，可以不断迭代，维护成本也相对低；二是覆盖面广，一个小改进能惠泽几百上千万用户，性价比高；三是竞争大，不改进可能导致流失用户。所以再小的细节也会被认真对待。而更重要的是在这些条件影响下，从业者的心智被锻炼成用户体验问题都应该被改进，而现实世界传统行业一些从业者很难有这样的意识，即时是一些成本低的改进也不会想去做，有些人用互联网注重用户体验的意识在传统行业中做事，被称为拥有互联网思维。

今天的扯淡就到这里，下期再见。

微信小程序上线大半年，大部分技术原理也有文章介绍了，本文尝试从需求出发探讨微信小程序技术方案的来源，以及最近公测的支付宝小程序技术方案的考量。

微信小程序

微信小程序的需求是让第三方开发者可以接入，可以使用微信的提供的接口去开发应用嵌入在微信里。对于这个需求，最简单的实现方案是：让外部开发者开发纯H5应用，在微信的 H5 容器里打开，容器提供微信 native 接口，就行了。在有小程序之前，已经有很多这样的业务接入，像京东购物，钱包里的各种友商大众点评/滴滴出行等，都可以认为是一个“小程序”，内嵌在微信里，能调用微信 native 接口，是不是沿着这种模式下去，把相应的接口开放给第三方，再提供个入口就行了？

实际上这种简单的方案不能满足需求，在产品上微信小程序有另外两个很重要的需求：

1. 管控。作为一个平台必须对接入的应用有管控能力，必须能尽量精确控制应用的内容和类型，毕竟若出现非法应用平台是要承担责任的，H5 的方式太过自由，开发者可以随时改变整个应用的内容，平台难以检测到这些改变，无法管控。另外H5开发质量参差不齐，平台也无法管控，这对于一向有洁癖的微信来说无法接受。
2. 体验。作为一个“小程序”需要让体验接近原生，而上述像京东购物这些普通 H5 页面的体验不太行，包括启动速度/页面切换流畅度都有问题，跟原生体验没法比。

所有小程序的技术方案都是为了这两个需求服务。

（更多…）

随着移动设备性能不断增强，web 页面的性能体验逐渐变得可以接受，又因为 web 开发模式的诸多好处(跨平台，动态更新，减体积，无限扩展)，APP 客户端里出现越来越多内嵌 web 页面（为了配上当前流行的说法，以下把所有网页都称为 H5 页面，虽然可能跟 H5 没关系），很多 APP 把一些功能模块改成用 H5 实现。

虽然说 H5 页面性能变好了，但如果没针对性地做一些优化，体验还是很糟糕的，主要两部分体验：

1. 页面启动白屏时间：打开一个 H5 页面需要做一系列处理，会有一段白屏时间，体验糟糕。
2. 响应流畅度：由于 webkit 的渲染机制，单线程，历史包袱等原因，页面刷新/交互的性能体验不如原生。

本文先不讨论第二点，只讨论第一点，怎样减少白屏时间。对 APP 里的一些使用 H5 实现的功能模块，怎样加快它们的启动速度，让它们启动的体验接近原生。

（更多…）