微信软件架构设计 第1篇
微信划分了http模式（short链接）和tcp 模式（long 链接），分别应对状态协议和数据传输协议
dns check （ ）
dns check ( )
2 说明
是HTTP协议扩展，运行8080 端口，http body为二进制（protobuf）。
主要用途（接口）：
用户登录验证;
好友关系（获取，添加）；
消息sync (newsync)，自有sync机制；
获取用户图像；
用户注销；
行为日志上报。
朋友圈发表刷新
tcp 长连接，端口为8080，类似微软activesync的二进制协议。
主要用途（接口）：
接受/发送文本消息；
接受/发送语音；
接受/发送图片；
接受/发送视频文件等。
所有上面请求都是基于tcp长连接。在发送图片和视频文件等时，分为两个请求；第一个请求是缩略图的方式，第二个请求是全数据的方式。
数据报文方面
增量上传策略：
每次8k左右大小数据上传，服务器确认；在继续传输。
图片上传：
先传缩略图，传文本消息，再传具体文件
下载：
先下载缩略图，在下载原图
下载的时候，全部一次推送。
3 附录
用户登录验证
POST /cgi-bin/micromsg-bin/auth HTTP/
Accept: **
User-Agent: Mozilla/
Content-Type: application/x-www-form-urlencoded
Host:
Content-Length: 174
消息sync (newsync)
POST /cgi-bin/micromsg-bin/newsync HTTP/
Host:
User-Agent: Android QQMail HTTP Client
Cache-Control: no-cache
Connection: Keep-Alive
Content-Type: application/octet-stream
accept: **
Content-Length: 206
用户注销
POST /cgi-bin/micromsg-bin/iphoneunreg HTTP/
Accept: */*
User-Agent: Mozilla/
Cotent-Type: application/x-www-form-urlencoded
Host:
Content-Length: 271
行为日志上报
POST /cgi-bin/stackreport?version=240000a7&filelength=1258&sum=&reporttype=1&username=jolestar HTTP/
Content-Length: 736
Content-Type: binary/octet-stream
Host:
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java )
从现在互联网的发展而言，IM和视频（包括IM里面视频通话）是一个方向，这些都应该成为互联网的基础设施，就像浏览器一样。现在IM还没有一个很好的解决方案，XMPP并不能很好地做到业务逻辑独立开来。从IM的本质来看，IM其实就是将一条消息从一个地方传输到另外一个地方，这个和TCP很像，为什么不实现一个高级点的TCP协议了，只是将TCP/IP里面的IP地址换成了一个类似XMPP的唯一ID而已，其他的很多细节都可以照搬TCP协议。有了这个协议之后，将业务逻辑在现有HTTP server的基础上做，例如发送语音和图片就相当于上传一个文件，服务器在处理完这个文件后就发一条特殊的IM消息。客户端收到这个IM消息后，按照IM消息里面url去HTTP server取语音文件和图片文件。将HTTP server和IM server打通之后，可以做很多事情。但将这个两个server合并在一块并不是一个好事，不然腾讯也不会有2005年的战略转型了。从现在的情况来看，应用除了游戏，都没怎么赚钱，现在能够承载赚钱业务的还是以web为主。IM不可以赚钱，但没有却是不行的，就像一个地方要致富，不修路是不行的道理一样。
微信软件架构设计 第2篇
这个也是IM最核心的内容了，我们要做到在任何网络下等顺畅聊天那就不容易了，好多公司都用的xmpp框架，如果在强网络环境下，xmpp完全没有问题。但是那种弱网络环境下xmpp就束手无策啦，用户体验就很垃圾了。
个人觉得xmpp 可以玩玩， 但是用来真正的产品就差远了。如果遇到一个做IM 的朋友张口闭口都说xmpp 的话，那么不用沟通了，肯定不是什么好产品。微信、QQ以前也曾用过xmpp，但是最后也放弃了xmpp，就知道xmpp有很多弊端了，还有就是报文太大，好臃肿，浪费流量。为了保证稳定，微信用了长链接和短链接相结合，例如：
微信软件架构设计 第3篇
单线程架构，即传统html开发的时候，官方建议script加载js的时候放在Body下方位置。为什么建议在下方插入script呢，就是因为单线程阻塞问题。因为html文件是从上到下渲染的，如果中间插入js的话，则会中断HTML节点渲染，转而去执行js，js执行完后继续渲染节点。就是因为单线程阻塞问题才建议在下方插入script，并且配合可以拿到已经渲染完成的节点。
这种情况当然也可以通过一些手段来规避，比如async、defer等。这两个属性加上后，虽然不会阻塞DOM渲染，但是并不是根本上解决问题，而是合理地安排了资源解析而已。
单线程阻塞问题还没结束，另一个问题又扑面而来。如果所有资源都是通过请求来获取，那么不光会阻塞js解析的时间，还要加上js请求的时长。请求js资源时间不可控，怎么办呢。这个时候另一种选择就至关重要，就是缓存。微信中这一点做的很好，就是WXSDK，微信SDK是一系列jsApi的集合，提供了微信的丰富原生能力和微信内部的方法。
在曾经开发微信公众号h5的时候我们需要手动的注入某个版本的微信SDK到自身的项目中去，这种方式的用户体验并不是很好，因为加载js，并且解析js逻辑的时候是会抢占渲染资源的，原因也就是上面刚讲过的单线程阻塞问题，如果在我们有承接平台的时候，比如微信客户端，将微信SDK这样的资源放在客户端Native中，在加载页面的时候再进行动态的注入，由Native层注入到视图层。这样的做法的好处很明显，首先会使包的体积变小，其次，减少了网络请求的发送。
小程序中也用到了微信SDK，当然不仅仅只有微信SDK做了这样的处理，由Native层注入到双线程中。还有底层基础库、Service等都是事先放在Native层中的，当页面进行加载的时候再进行动态的注入。好比如说公司里给你配了一台电脑来开发项目一样，曾经工作人员都需要自己带着自身的开发工具去公司上班，如果公司统一配好了开发工具，那么你再也不用带着电脑去公司上班了，减少了每个员工为工作需要提前准备的资源。
可以看出，双线程的好处不仅仅是一分为二而已，还有强大的Native层做背后支撑。Native层除了做一些资源的动态注入，还负责着很多的事情，请求的转发，离线存储，组件渲染等等。界面主要由成熟的 Web 技术渲染，辅之以大量的接口提供丰富的客户端原生能力。同时，每个小程序页面都是用不同的WebView去渲染，这样可以提供更好的交互体验，更贴近原生体验，也避免了单个WebView的任务过于繁重。此外，界面渲染这一块还定义了一套内置组件以统一体验，并且提供一些基础和通用的能力，进一步降低开发者的学习门槛。值得一提的是，内置组件有一部分较复杂组件是用客户端原生渲染的，以提供更好的性能。
微信软件架构设计 第4篇
通过上面的内容，你应该大致了解小程序诞生的情况和所处的环境了，下面我们就来聊聊小程序的整体设计构架情况。
整个小程序系统构架分成两个部分：视图层(WebView) 和 逻辑层(App Service)，这两个部分分别由两个独立线程管理。
视图层：也称为渲染层，渲染层用来渲染页面结构，主要由 WebView 进行渲染，一个小程序可以存在多个界面，所以渲染层可能存在多个 WebView 线程。
逻辑层：逻辑层采用 JSCore 线程运行 JS 脚本。逻辑层主要用来逻辑处理、数据请求、接口调用等。
视图层和逻辑层之间的沟通则需要借助 系统层(WeixinJsBridage) 进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务逻辑处理。
页面渲染大致过程为：我们把项目进行编译会把 WXML 转化成对应的 JS 对象（Virtual DOM），在逻辑层发生数据变化的时候，我们会通过 setData() 方法把数据从逻辑层传递到视图层，视图层在接收到数据后，会内部进行差异对比，把差异应用在原来的 Dom 树上，再正确的渲染出 UI 界面，完成页面的渲染过程。
通过上面的分析，你是否能理解开头放置的架构图了
上面的分析还提及到了一个 系统层(WeixinJsBridage)，一般简称为 JSBridge，它起到了一个中间桥梁的作用，非常重要。它不仅让视图层与逻辑层两个单独线程能进行通信，而且也架起上层开发与系统底层功能（Native）的桥梁，使得小程序可以通过调用 API 使用原生功能，且部分组件用原生组件实现，从而有良好体验。
逻辑层还有一个重要的操作，发送网络请求，它也是经由 系统层 转发的。
讲到这里，希望你对小程序的整体架构有一定认识了，下面我们开始就讲一下小程序内部的一些机制情况了。
微信软件架构设计 第5篇
做过小程序的铁汁们应该对这张图不陌生了：
图中过程主要是为了获得微信用户的唯一 openid 与 session_key，之后开发者服务器可以根据用户标识来生成自定义登录态，用于后续业务逻辑中前后端交互时识别用户身份。
调用 () 获取临时登录凭证 code，并回传到开发者服务器。
调用 接口，换取用户唯一标识 openid 、用户在微信开放平台帐号下的唯一标识 UnionID（若当前小程序已绑定到微信开放平台帐号）和会话密钥 session_key。
微信软件架构设计 第6篇
Web 技术来渲染小程序是存在一些不可控因素和安全风险的。这是因为Web技术是非常开放灵活的，我们可以利用JavaScript 脚本随意地跳转网页或者改变界面上的任意内容。这个时候安全问题摆到了微信团队的台面上。如果微信小程序可以离线浏览，只需要小程序开发者把一些应用数据缓存到本地，然后通过javascript脚本把小程序渲染的webview跳转到其他的在线网页，那么这个体验就非常的糟糕。想必前端开发者会非常熟悉这个操作。
除此之外，javascript还可以通过操作DOM，直接获取小程序内部的一些敏感数据，比如用户的信息，商家信息等等，那么小程序将毫无安全可言。
为了解决安全管控问题，小程序阻止开发者使用一些浏览器提供的比如跳转页面、操作DOM、动态执行脚本的开放性接口。如果这些东西一个一个地去禁用，那么势必会进入一个糟糕的循环，因为javascript实在是太灵活了，浏览器的接口也太丰富了，很容易就遗漏一些危险的接口，而且就算是禁用掉了所有感觉到危险的接口，也势必防不住浏览器内核的下次更新。指不定又会出现一些漏洞。
因此，要彻底解决这个问题，必须提供一个沙箱环境来运行开发者的JavaScript 代码。这个沙箱环境不能有任何浏览器相关接口，只提供纯JavaScript 的解释执行环境，那么像HTML5中的ServiceWorker、WebWorker特性就符合这样的条件，这两者都是启用另一线程来执行 javaScript。但是考虑到小程序是一个多 webView 的架构，每一个小程序页面都是不同的webView 渲染后显示的，在这个架构下不好去用某个webView中的ServiceWorker去管理所有的小程序页面。
微信软件架构设计 第7篇
微信小程序的宿主环境为微信客户端，它是依赖于微信客户端上运行的，并且跟小程序 基础库 版本有重大关联关系。
我们可以把 微信客户端 以及 小程序基础库 简称为微信小程序的宿主环境。
微信小程序可以调用宿主环境提供的微信客户端的能力，可以完成许多普通网页无法完成的功能，这就使得小程序比普通网页拥有更多的能力。小程序会运行在不同版本（不同的微信客户端+不同基础库）的宿主环境下，因此针对各个版本的宿主环境做程序上的兼容也是在所难免的。
微信软件架构设计 第8篇
通过学习了小程序的架构原理，我们再来用底层架构的眼光来简单分析一下常见的小程序性能问题是如何产生的。
频繁调用setData()
频繁调用 setData()，这个问题相信已经是很常见的，比如在定时器中调用、在监听页面滚动的钩子中调用，这些场景很容易就会引起小程序的性能问题，容易出现页面卡顿、页面数据更新不及时的情况。
前面在 数据通信机制 中我们讲过小程序是基于双线程的，那就意味着任何在视图层和逻辑层之间的数据传递都是线程间的通信，频繁的去调用 setData()，会使得线程之间一直处于忙碌状态，逻辑层通知到视图层耗时就会上升，视图层收到消息的时候可能已经距离发出的时间超过一定时间了，渲染页面就不够及时了。
庞大的数据量去调用setData()
还是在前面的 数据通信机制 中，我们说过传输的数据需要转换成转换为字符串的形式传递，且通过 JS 脚本的形式去执行，当数据量大时，执行脚本的编译执行时间也会上涨，占用线程。
页面复杂繁多的DOM结构
当一个页面 DOM 结构复杂并且非常多的时候，这必定带来页面显示不及时，页面卡顿，甚至可能会出现页面奔溃的情况，这其中的原因可想而知，是过于 DOM 绘制、计算都是需要时间的，这将使得线程过渡的工作，带来客户端内存占用上升，从而触发系统回收小程序页面。
上面我提到说，对 “逻辑层运行在 JSCore 中” 这句话有点疑问，是因为我在看到表格中列举的逻辑层运行的环境应该是按系统环境区分的才对，那这句话是不是就太笼统了？还是说这句话就是指 IOS 的情况呢？因为是官方文档写的话语，所以我没有直接就否决是写错了，或者单指IOS 的情况。
经过一翻查证，证实其实这句话是没有问题的，要追寻结果的过程，我们需要写了解一下浏览器的大致情况：
浏览器中最核心的部分则是浏览器内核，每个浏览器都有其各自的内核，而对移动领域影响最深的则当属 WebKit。
WebKit 就是一个页面渲染以及逻辑处理引擎，HTML/CSS/JavaScript 经过它的处理，成为可见且可操作的Web页面。
WebKit 由多个重要模块组成
WebKit 由四个部分组成，分别是：
WebKit Embedding API：负责浏览器 UI 与 WebKit 进行交互的部分。
Platform API（WebKit Ports）：让 Webkit 更加方便的移植到各个操作系统、平台上，提供的一些调用Native Library的接口。
WebCore：整个 WebKit 中最核心的渲染引擎。
JavascriptCore：JSCore 是 WebKit 默认内嵌的JS引擎，由苹果使用 C 开发。
我们来重点来关注 JSCore 部分，JSCore 是 WebKit 默认内嵌的JS引擎，之所以说是默认内嵌，是因为很多基于 WebKit 分支开发的浏览器引擎都开发了自家的JS引擎，其中最出名的就是 Chrome的V8 引擎。
V8 引擎，相信前端的小伙伴应该不会很陌生了，既然它是基于 WebKit 的，那底层默认也是内嵌 JSCore 的，而 Android 的逻辑层是运行在 V8 上的。
而 IOS 的浏览器引擎则是 WebKit，内部则就是 JSCore。
最后 开发工具 的逻辑层是运行在 , 上它的官网，看到怎么一段话：
我相信它应该也和 WebKit 扯上关系了。
以上就是微信小程序架构原理基础详解的详细内容