微信小程序扫盲篇

微信小程序和独立app哪个好:

小程序除了拥有公众号的低开发成本、低获客成本低以及无需下载等优势，在服务请求延时与用户使用体验是都得到了较大幅度的提升，使得其能够承载跟复杂的服务功能以及使用户获得更好的用户体验。

　　相比原生APP 小程序在使用体验上相差无几，单在开发成本、获客成本以及下载便捷程度上有较大优势，所以在轻应用的应用方面有天然的优势。

　　有了微信小程序，不需要频繁的跳出微信、打开别的应用、重新回到微信，可以在不离开微信的情况下完成很多任务，如果小程序足够全，甚至你打开手机的所有时间可能都泡在微信里。

　　当然也并不意味着它无所不能，小程序毕竟不是原生的APP，和独立的APP比起来肯定有一些功能不能满足，尤其是游戏、娱乐或者文档编辑等复杂应用。另外小程序不能订阅收藏、不能分享朋友圈，只能通过好友分享转发和推荐等社交方式发现新的小程序，用完退出后下次再用找起来比较费劲。

　　对于百度、阿里、360 以及今日头条等高频且对用户来说较为重要的应用考虑到竞争与体验等因素预计不会加入微信小程序，对于低频且重要的应用一方面可以基于微信小程序引流，另一方面基于自身服务的重要性能够对用户产生一定的粘性，而采用独立APP 由于用户使用频次较低可能会导致无法聚集流量而被微信上类似功能的小程序占得先机，所以这类应用未来会逐渐向微信小程序迁移。

微信小程序和手机APP到底有啥不一样呢？

一、面向用户群

微信小程序：面向所有微信用户，月活跃用户超过8亿人，日使用账号5.7亿；

　　App：面向所有智能手机用户，约20亿台；

二、功能实现

微信小程序：限于微信平台提供的功能；

　　App：可实现完整功能；

例如，由于API的限制，小程序就很难和系统进行互动。利用App，你可以轻松和系统对话，

例如情景模式类的App就能够修改系统的音量、震动、网络连接等等，但小程序就无法做到这些常见的功能。

三、下载安装

微信小程序：通过微信（扫描二维码、搜索、分享）即可获得；

　　App：从应用商店（App Store、应用汇等）下载安装；

四、内存占用

微信小程序：无需安装，和微信共用内存使用，占用内存空间忽略不计；

　　App：安装于手机内存，一直占用内存空间，太多的 App 可能会导致内存不足；

五、创业机会

微信小程序：蓝海市场，在新的使用场景中可以寻求很多好机会；

　　App：市场基本饱和，几乎所有的领域均已覆盖；

六、手机适配

　微信小程序：一次开发，多终端适配；

　　App：需适配各种主流手机，开发成本大；

七、开发周期

微信小程序：平均开发周期约2周；

　　App：一款完善的双平台 App 平均的开发周期约2个月；

八、产品发布

微信小程序：提交到微信公众平台审核，云推送；

　　App：向十几个应用商店提交审核，且各应用商店所需资料不一样，非常繁琐；

　九、推广难度

微信小程序：通过二维码、微信搜索、朋友分享等方式直接获得

　　App：需要用户主动下载十几M的安装包，在没有Wi-Fi的情况下推广困难；

十、消息推送

微信小程序：仅能回复模版消息，不允许主动给用户发送广告，良好的产品体验.

　　App：频繁无用广告推送，骚扰用户造成没必要的困扰；

　　最后，将以上区别进行总结：

微信小程序：

　　1）适合快速场景化服务

　　2）可以快速验证客户需求

　　3）适合初创团队

　　4）试错成本低，需要较少时间和资金投入

　　5）可以迅速占领空白领域客户渠道

App：

　　1）适合已验证可行的商业模式

　　2）适合产品复杂度高，功能受限低的产品开发

　　3）适合成熟的商业大公司

　　4）对自我品牌要求较高的企业

　　5）具备充裕的开发时间和资金储备

从开发角度了解小程序原理:

微信小程序使用了前端技术栈 JavaScript/WXML/WXSS。但和常规的前端开发又有一些区别：

JavaScript: 微信小程序的 JavaScript 运行环境即不是 Browser 也不是 Node.js。它运行在微信 App 的上下文中，不能操作 Browser context 下的 DOM，

也不能通过 Node.js 相关接口访问操作系统 API。所以，严格意义来讲，微信小程序并不是 Html5，虽然开发过程和用到的技术栈和 Html5 是相通的。

WXML: 作为微信小程序的展示层，并不是使用 Html，而是自己发明的基于 XML 语法的描述。

WXSS: 用来修饰展示层的样式。官方的描述是 “ WXSS (WeiXin Style Sheets) 是一套样式语言，用于描述 WXML 的组件样式。WXSS 用来决定 WXML

的组件应该怎么显示。” “我们的 WXSS 具有 CSS 大部分特性...我们对 CSS 进行了扩充以及修改。”基于 CSS2 还是 CSS3？大部分是哪些部分？是否支持 CSS3 里的动画？不得而知。

微信小程序官方文档上，有下面这段话：

微信小程序运行在三端：iOS、Android 和用于调试的开发者工具:

在 iOS 上，小程序的 javascript 代码是运行在 JavaScriptCore 中
在 Android 上，小程序的 javascript 代码是通过 X5 内核来解析
在开发工具上，小程序的 javascript 代码是运行在 nwjs（chrome内核）中

小程序的 javascript 代码运行在 nwjs 中。nwjs 是什么鬼呢？官方介绍是这样写的：

NW.js (previously known as node-webkit) lets you call all Node.js modules directly
from DOM and enables a new way of writing applications with all Web technologies.。

nwjs 合并 Browser 和 Node.js 的运行时，可以使用前端开发技术来开发跨平台的应用程序。借助 Node.js 访问操作系统原生 API 的能力，

可以开发中跨平台的应用程序。微信小程序开发工具就是使用 nwjs 开发的。

Electron vs nwjs

这两个平台有什么区别？为什么微信选择 nwjs 呢？我们不妨猜一猜。

从技术角度来讲：

应用程序入口不同：Electron 入口是一个 javascript 脚本，脚本里要自己负责创建浏览器窗口，加载 html 页面。而 nwjs 的入口就是一个 html 页面，框架自己会创建浏览器窗口来显示这个 html 页面。
Node.js 集成方式不同：Electron 直接使用 Node.js 的共享库，不需要修改 Chromium 代码。而 nwjs 为了集成 Node.js ，需要修改 Chromium 代码，以便在浏览器里能通过 Node.js 访问系统原生 API。
Multi-Context: nwjs 有多个上下文，一个是浏览器的上下文，用来访问 Browser 相关 API，比如操作 DOM ，另外一个是 Node 上下文，用来访问操作系统 API。Electron 没有使用多个上下文，对开发者更友好。

从应用角度来讲：

打包后的文件大小：Electron 打包后文件会比 nwjs 小不少。一个 18M 的程序，使用 Electron 打包后是 117M，而使用 nwjs 打包后的程序是 220M。微信小程序开发工具打包后是 219M (v0.10.102800)。没有亲测，评价来源参考文档。
代码保护：Electron 只支持代码混淆来保护，而 nwjs 把核心代码放在 V8 引擎里，不但可以保护代码，还可以提高执行效率。
开源社区活跃度：Electron 应该是完胜的。看看使用 Electron 构建的应用程序就知道了。而据说 nwjs 的开发文档有些都没有及时更新。
应用程序启动时间：Electron 会稍微快一点。没有亲测，评价来源参考文档。

小程序的目录结构:

一个完整的小程序主要由以下几部分组成：
一个入口文件：app.js
一个全局样式：app.wxss
一个全局配置：app.json
页面：pages下，每个页面再按文件夹划分，每个页面4个文件
视图：wxml，wxss
逻辑：js，json（页面配置，不是必须）

注：pages里面还可以再根据模块划分子目录，孙子目录，只需要在app.json里注册时填写路径就行。

小程序架构:

微信小程序的框架包含两部分View视图层、App Service逻辑层，View层用来渲染页面结构，AppService层用来逻辑处理、数据请求、接口调用，它们在两个进程（两个Webview）里运行。
视图层和逻辑层通过系统层的JSBridage进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务处理。

小程序架构图：

小程序启动时会从CDN下载小程序的完整包，一般是数字命名的,如：_-2082693788_4.wxapkg

小程序技术实现

小程序的UI视图和逻辑处理是用多个webview实现的，逻辑处理的JS代码全部加载到一个Webview里面，称之为AppService，整个小程序只有一个，并且整个生命周期常驻内存，而所有的视图（wxml和wxss）都是单独的Webview来承载，称之为AppView。所以一个小程序打开至少就会有2个webview进程，正式因为每个视图都是一个独立的webview进程，考虑到性能消耗，小程序不允许打开超过5个层级的页面，当然同是也是为了体验更好。

AppService

可以理解AppService即一个简单的页面，主要功能是负责逻辑处理部分的执行，底层提供一个WAService.js的文件来提供各种api接口，主要是以下几个部分：
消息通信封装为WeixinJSBridge（开发环境为window.postMessage, IOS下为WKWebview的window.webkit.messageHandlers.invokeHandler.postMessage，android下用WeixinJSCore.invokeHandler）

1、日志组件Reporter封装
2、wx对象下面的api方法
3、全局的App,Page,getApp,getCurrentPages等全局方法
4、还有就是对AMD模块规范的实现

然后整个页面就是加载一堆JS文件，包括小程序配置config，上面的WAService.js（调试模式下有asdebug.js），剩下就是我们自己写的全部的js文件，一次性都加载。

AppView

这里可以理解为h5的页面，提供UI渲染，底层提供一个WAWebview.js来提供底层的功能,具体如下：
1、消息通信封装为WeixinJSBridge（开发环境为window.postMessage, IOS下为WKWebview的window.webkit.messageHandlers.invokeHandler.postMessage，android下用WeixinJSCore.invokeHandler）
2、日志组件Reporter封装
3、wx对象下的api，这里的api跟WAService里的还不太一样，有几个跟那边功能差不多，但是大部分都是处理UI显示相关的方法
4、小程序组件实现和注册
5、VirtualDOM，Diff和Render UI实现
6、页面事件触发

在此基础上，AppView有一个html模板文件，通过这个模板文件加载具体的页面，这个模板主要就一个方法，$gwx，主要是返回指定page的VirtualDOM，而在打包的时候，会事先把所有页面的WXML转换为ViirtualDOM放到模板文件里，而微信自己写了2个工具wcc（把WXML转换为VirtualDOM）和wcsc（把WXSS转换为一个JS字符串的形式通过style标签append到header里）。

程序是如何在微信 App 里运行的呢？

微信 App 里包含 javascript 运行引擎。

微信 App 里包含了 WXML/WXSS 处理引擎，最终会把界面翻译成系统原生的控件，并展示出来。这样做的目的是为了提供和原生 App 性能相当的用户体验。

小程序加载运行的过程大概过程：

用户点击打开一个小程序
微信 App 从微信服务器下载这个小程序
分析 app.json 得到应用程序的配置信息（导航栏，窗口样式，包含的页面列表等）
加载并运行 app.js
加载并显示在 app.json 里配置的第一个页面

这个只是从开发者眼中看到的一个简化版的过程，实际过程应该比这要复杂得多，涉及到浏览器线程（就是运行我们的逻辑层代码 app.js 等的线程）和 AppService 线程之间的交互。从官方网站上的一个图片可以看出端倪：

至于微信 App 是如何与小程序的逻辑层 javascript 交互的呢？可以简单地归纳如下：

JavaScript 是脚本语言，可以在运行时解释并执行。微信 App 里包含了一个 JavaScript 引擎，由它来负责执行逻辑层的 JavaScript 代码。

那么 JavaScript 调用的小程序相关 API 怎么实现的呢？答案是最终会被翻译成实现在微信 App 里的原生接口。比如开发者调用 wx.getLocation(OBJECT)

获取当前地理位置，微信 App 里的 JavaScript 引擎在执行这个代码时，会去调用微信 App 里实现的原生接口来获取地理位置坐标。

小程序由两大线程组成：负责界面的线程（view thread）和服务线程（appservice thread），各司其职由互相配合

小程序的生命周期借鉴了Android的生命周期.

界面线程有四大状态：
1. 初始化状态：初始化界面线程所需要的工作，包括工作机制，基本和我们开发者没有关系，等初始化完毕就向 “服务线程”发送初始化完毕信号，然后进入等待传回初始化数据状态。

2.首次渲染状态：收到“服务线程”发来的初始化数据后（就是 json和js中的data数据），就开始渲染小程序界面，渲染完毕后，发送“首次渲染完毕信号”给服务线程，并将页面展示给用户。

3.持续渲染状态：此时界面线程继续一直等待“服务线程”通过this.setdata（）函数发送来的界面数据，只要收到就重新局部渲染，也因此只要更新数据并发送信号，界面就自动更新。

4.结束状态：结束.

服务线程五大状态：
1 初始化状态：无需和其他模块交流，跟小程序开发也没多大关联，此阶段就是启动服务线程所需的基本功能，比如信号发送模块。系统的初始化工作完毕，就调用自定义的onload和onshow，
然后等待界面线程的“界面线程初始化完成”信号。
onload是只会首次渲染的时候执行一次，onshow是每次界面切换都会执行，简单理解，这就是唯一差别。

2 等待激活状态：接收到“界面线程初始化完成”信号后，将初始化数据发送给“界面线程”，等待界面线程完成初次渲染。

3.激活状态：收到界面线程发送来的“首次渲染完成”信号后，就进入激活状态既程序的正常运行状态，并调用自定义的onReady()函数。
此状态下就可以通过 this.setData 函数发送界面数据给界面线程进行局部渲染，更新页面。

4.后台运行状态：如果界面进入后台，服务线程就进入后台运行状态，

Cookie和Session

1.由于HTTP协议是无状态的协议，所以服务端需要记录用户的状态时，就需要用某种机制来识具体的用户，这个机制就是Session.典型的场景比如购物车，
    当你点击下单按钮时，由于HTTP协议无状态，所以并不知道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session，用用于标识这个用户，
    并且跟踪用户，这样才知道购物车里面有几本书。这个Session是保存在服务端的，有一个唯一标识。在服务端保存Session的方法很多，内存、数据库、
    文件都有。集群的时候也要考虑Session的转移，在大型的网站，一般会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放
    在内存的，使用一些缓存服务比如Memcached之类的来放 Session。
2. 思考一下服务端如何识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应
    用都是用 Cookie 来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每
    次请求把这个会话ID发送到服务器，我就知道你是谁了。有人问，如果客户端的浏览器禁用了 Cookie 怎么办？一般这种情况下，会使用一种叫做URL重写的技
    术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。
3. Cookie其实还可以用在一些方便用户的场景下，设想你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以写到Cookie里面，
    访问网站的时候，网站页面的脚本可以读取这个信息，就自动帮你把用户名给填了，能够方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。
    所以，总结一下：
Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；
Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

获取session_key与openid

说说获取session_key和openid的条件

1.AppID(小程序ID);

2.AppSecret(小程序密钥);

3.登录时获取code;

注意:即使获取到了appid,未通过打款验证,也是不能拿到code的.

获取流程:

公众平台上找到AppID(小程序ID)和AppSecret(小程序密钥);

2.微信小程序中调用API获取code

wx.login({
  success: function(res) {
   console.log(res.code)//这就是code
 });

3.code 换取 session_key和openid

用户允许登录后，回调内容会带上 code（有效期五分钟），开发者需要将 code 发送到开发者服务器后台，使用code 换取 session_key api，将 code 换成 openid 和 session_key

后台访问微信服务器接口就能拿到openid 和 session_key.

当然也可以按照官方文档,后台生成session,以3rd_session为key,session_key+ opneid为value.

正文