微信小程序用户体系 第1篇
基于以上的几点分析及公司的产品定位，最终得出两个观点，作为早期小程序产品线的产品原则：
秉承这两点基本原则，为了达到产品初期运营目标，最大化发挥小程序开放的产品能力，对小程序的账户体系进行了<三段式设计>，以匹配不同阶段、不同产品目标。以登录注册模块为例：
借助用户手机号快速验证注册，为用户生成唯一UID，一个手机号被认为是一个独立用户。通过手机号注册是目前产品最主流的手段，得益于手机的唯一性、真实性，一举解决了应用用户实名认证的难题。同时，减轻了用户记忆的负担，毕竟APP太多，记住一个号码远胜于多个账号密码。
市面上不少小程序直接手动输入手机验证码动态登录，完全避开第三方开放账户的关联，试图降低不同体系产品之间的耦合程度，尤其是小程序外包系。某种程度而言，是值得赞赏的，单一产品线（仅有小程序）采用这种方式是值得可取的，毕竟用户获取成本并不大且比较简洁、方便。
产品一期MVP版本，这便是我采用的方案，因为推广较弱、用户较少的情况下，这一产品设计方案可以支撑，能达到快速上线的要求，易于后期的增量迭代。
手动手机号-原型设计稿
除了产品经理自定义的小程序产品特性，小程序开放平台本身提供了丰富的集成能力，包括登录/注册的组件。平台自行开放的产品能力是为了开发更高效，产品更方便触达用户。小程序开放了几组登录、授权、用户信息方面的接口：
小程序开发能力
使用【微信手机号授权】的开放产品能力，可以有效缩短用户注册路径，提高获客效率。因而优先给用户登录/注册提供<微信手机号授权>的选择，其次为用户提供手动输入手机号入口，极大改善了用户体验，最大程度留住用户，哪怕有一点恶意的感觉。
产品设计阶段二，便升级了一期的设计方案，市面上有不少小程序采用了这种登录注册机制，而我们仅将其作为过渡方案实现，并没有直接实现落地，再度升级了二代设计方案，尝试一劳永逸解决系统性的问题。于是，便有了第三阶段的思考——Passport融合。
微信手机号授权-原型设计稿
阶段二只简单使用了微信小程序的产品开放能力的一个点，而小程序平台共提供了四个方面的产品能力。经过两次的迭代，我将负责的小程序的账户体系日益完善，形成最符合产品线要求、满足商业需求、满足用户诉求的广场景流程。
将用户类型与使用场景交叉分析得到如下的典型故事（User story）：复合的场景均以图文的形式呈现，如果图中有错误，欢迎指正。
图文解字01-小程序登录注册全场景
图文解字02-小程序登录注册全流程[更新于20180703]
（上图已去掉了我司的任何图标名称，以免有软文嫌疑。图文仅供参考，且未全覆盖小程序登录注册完整生命周期，是一个动态变化的流程，尽请甑别区分理解。）
最终的登录注册产品设计方案，全面引入微信小程序开放的接口（API），极大提升产品的多场景处理能力，同时兼顾了新老用户的使用感受。这里不得不说一句：微信太强大！第三段设计核心升级了以下两个要点：
涉及账户登录注册模块的几个微信开放能力共同解决了一个问题——用户身份的定位，对账户体系的设计账号（Account）的唯一性被认为是根本。从一开始，我就给自己负责的小程序的【登录】一个定义——必须拥有自持账户才认为是登录状态。各种账号（Username）对应到一个账户(Account)！最大程度减少一个用户多个账户的情况，第一时间做账户合并，多账户之间的多级映射。我深知：一人对应多账户是一件痛苦的事，因为我曾经历过。
记得之前好几篇文章提到了账户体系的产品设计，都只限于意识层面的输出，这一次应产品经理朋友之邀，也算是对自己的交代，因为此前很早就想复盘一遍小程序的账户-登录注册模块的产品过程。当然，有不少朋友留言说，见你写的文章大多都是偏理论的，能不能输出一些偏实战的干货。虽然我一直坚信：理论经验的输出要比实践更高级，因为必将投入更多深入的思考的时间，不单是简单叙事流水账。
这一次小程序登录注册体系的产品设计过程，结合了运营、技术、产品、第三方平台的多方规则，让小程序具备了登录注册的系统级能力。正是鉴于实践的需要，让我更加意识到认知的价值，如果说你都不清楚的知道先决规则，那么所做之事又该从何下手呢？当然，这一次产品经历是我个人产品能力的实践（技术开发被折磨的够呛…），场景实在是太多了，着实不容易。
有时候，被产品同行问道：你们公司产品经理都做些什么工作啊？但凡提到产品设计，便被质疑：设计不是交互设计师做的事情吗？哪有那么多交互设计师？产品经理（我）是制定规则的，只是顺便画了个图（原型图）。
我认为：产品设计能力是一个系统能力，着眼的是全流程、全生命周期的描绘，而不只是某个单点的锱铢必较。
小王，人人都是产品经理专栏作家，微信公众号：IPMstory。目前从事电商内容产品，关注大数据、人工智能、商业产品，擅长产品管理、数据分析、商业模式。我是一个会生活的产品经理，喜欢收纳整理、厨艺家务。
微信小程序用户体系 第2篇
客户端在整个登录流程中主要承担两种行为：
作为整个流程的发起者，获取临时登录凭证 code；
作为整个流程的终结者，存储登录态令牌 token。
不过客户端的所有信息和网络请求几乎都是可以被破解或拦截的，所以出于安全的考虑，小程序登录流程中的一些接口被限制不能在客户端中直接调用，而是需要在服务端发起，开发者服务的工作便是处理这些安全敏感的网络请求，体现为上图中使用code 获取 openid 和 session_key的请求，这个请求使用了微信提供的 接口。
而微信接口服务的工作对于开发者来说是不透明的，你需要做的仅仅是根据接口的规范，组装网络请求发送给它，然后根据返回的接口执行分发逻辑。微信服务器会验证网络请求的合法性，对于合法请求下发密钥 session_key 和用户 openid。
微信小程序用户体系 第3篇
如果我们把 unionid 字段为空的数据落库到了“用户中心”的数据库会造成什么问题？不妨举个例子来说明。试下一下这样的场景：一个用户进入小程序，拒绝授权但是登录了手机号 A，然后进入微信网页，也拒绝授权但是登录了手机号 B，我们就会有如下数据。
【openidA-unionid 为空-useridA】
【openidB-unionid 为空-useridB】
假如用户再来访问，在两个环境都允许授权了，会怎么样呢？数据库里面的数据就会被补全，变成如下的样子。
【openidA-unionidA-useridA】
【openidB-unionidA-useridB】
问题来了，如果这个时候公司又开发了一个小程序，这个用户过来访问，允许授权，系统拿到了 openidC 和 unionidA，那该把用户关联到哪个 userid 上面呢？所以我们可以看出来，如果 unionid 字段为空的数据落入了【用户中心】的数据是多么的麻烦，一旦牵扯到两个 appid 系统就立马歇菜了，非常容易出差错，但是如果 unionid 是不允许为空的，那么其实系统的逻辑依旧比较简单，而且很干净。
如果有人不信邪觉得可以通过 appid 或者别的手段去关联，不妨可以试试，在线上运行一段时间，再去 mysql 里面跑数看看，百分百会遇到一个微信号关联两个 userid 的情况，这种时候用户再投诉“订单丢失”的问题，真的是跳进黄河也洗不清。
除了逻辑层面的区别，和上面一小节里纯粹公众号场景处理的方式还有有一个比较大的区别，就是数据库里面理论上会存在这样的两条数据：
微信小程序用户体系 第4篇
做过小程序的铁汁们应该对这张图不陌生了：
图中过程主要是为了获得微信用户的唯一 openid 与 session_key，之后开发者服务器可以根据用户标识来生成自定义登录态，用于后续业务逻辑中前后端交互时识别用户身份。
调用 () 获取临时登录凭证 code，并回传到开发者服务器。
调用 接口，换取用户唯一标识 openid 、用户在微信开放平台帐号下的唯一标识 UnionID（若当前小程序已绑定到微信开放平台帐号）和会话密钥 session_key。
微信小程序用户体系 第5篇
相比APP、WAP产品形态而言，小程序是一个比较新的物种（老酒换新瓶）。那么，之于现有产品线而言，是一个补充，（未来）可能会演变成一种冲击。换句话说，除了诱人的流量红利，部分公司跟进小程序完全是出于对微信生态的敬畏，甚至有有些直接是奉命行事——老板一句话，总之都是是源于内心的产品认知焦虑。以下从两个维度拆解：
一方面是新鲜产品特性的引入，另一方面是运营策略层面的试错，因而很有必要平衡两者之间的价值成本，且保持产品的持续有效迭代。当然，要求我们保持产品的灵活性，也因为小程序平台本身也处于持续开放的状态，两者处于一个共同成长的循环状态。
除了上述两个维度的顾及，针对目标用户和使用场景需要予以不一样的适用范畴的考虑。以下从这两个维度思考：
其实，用户画像和使用场景决定了后续产品迭代过程中，功能的取舍、优先级，或者说迭代的进度次序。一个理想的做法是小步快跑、增量迭代，既经济又现实，符合产品的迭代演进路径。最关键的是，给产品经理预留了充足时间，给产品提供了足够的选择。可问题是：既没给产品（Product）留时间，又没给产品经理（PM）留时间！
微信小程序用户体系 第6篇
通过上面的内容，你应该大致了解小程序诞生的情况和所处的环境了，下面我们就来聊聊小程序的整体设计构架情况。
整个小程序系统构架分成两个部分：视图层(WebView) 和 逻辑层(App Service)，这两个部分分别由两个独立线程管理。
视图层：也称为渲染层，渲染层用来渲染页面结构，主要由 WebView 进行渲染，一个小程序可以存在多个界面，所以渲染层可能存在多个 WebView 线程。
逻辑层：逻辑层采用 JSCore 线程运行 JS 脚本。逻辑层主要用来逻辑处理、数据请求、接口调用等。
视图层和逻辑层之间的沟通则需要借助 系统层(WeixinJsBridage) 进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务逻辑处理。
页面渲染大致过程为：我们把项目进行编译会把 WXML 转化成对应的 JS 对象（Virtual DOM），在逻辑层发生数据变化的时候，我们会通过 setData() 方法把数据从逻辑层传递到视图层，视图层在接收到数据后，会内部进行差异对比，把差异应用在原来的 Dom 树上，再正确的渲染出 UI 界面，完成页面的渲染过程。
通过上面的分析，你是否能理解开头放置的架构图了
上面的分析还提及到了一个 系统层(WeixinJsBridage)，一般简称为 JSBridge，它起到了一个中间桥梁的作用，非常重要。它不仅让视图层与逻辑层两个单独线程能进行通信，而且也架起上层开发与系统底层功能（Native）的桥梁，使得小程序可以通过调用 API 使用原生功能，且部分组件用原生组件实现，从而有良好体验。
逻辑层还有一个重要的操作，发送网络请求，它也是经由 系统层 转发的。
讲到这里，希望你对小程序的整体架构有一定认识了，下面我们开始就讲一下小程序内部的一些机制情况了。
微信小程序用户体系 第7篇
通过学习了小程序的架构原理，我们再来用底层架构的眼光来简单分析一下常见的小程序性能问题是如何产生的。
频繁调用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 扯上关系了。
以上就是微信小程序架构原理基础详解的详细内容
微信小程序用户体系 第8篇
登录态是个逻辑词汇，token 可以理解为登录态的具象化、数据化。在小程序的登录流程图中，你可以看出，token是由开发者服务器创建的一个字符串，而且需要跟 openid 和 session_key 相关联。其实这里并不是强制关联 openid，因为 openid 并不算是私密信息，可以放心地下发到客户端（即小程序）。但是 session_key 是非常私密的信息，一旦泄露有很大的安全隐患，所以强烈建议不要把它下发到客户端。
在获取到 openid 和 session_key 之后，开发者服务器创建一个 token，然后与 openid 和session_key 进行关联，具体的方法根据服务器编程语言的不同有多种实现方案。咱们以JavaScript 语言作为示例，可以创建一个对象，对象的 key 是 token 的值，value 是一个包含 openid 和 session_key 的对象，如下：
关联完成之后开发者服务器将 token下发到客户端，客户端保存在本地，后续的所有请求均需要携带此 token，携带的方法并没有既定的规范，可以通过 URL Query、HTTP Body、Header 等，但通常建议通过 Header 传递，这样相对来说更安全一些。