小程序的后端开发资料详解

　　小程序后端开发需要很多相关的技术和资料，如果这些前期准备不够完善，那么开发就很容易遇到或这或那的问题，所以今天微信小程序商店会为大家提供小程序的后端开发资料，希望能够对大家有所帮助。

　　一、小程序的后端开发数据如何获取?

　　小程序的本质其实就是数据的呈现和加工。如果要看小程序客户端开发平台的基本能力，就要看它能处理哪些数据，如果缺少了必要的数据获取方式，就代表还有一定的局限*，这对于开发者而言开发的困难很大。

　　所以，从这点看，小程序是提供的数据获取方式还是相对全面又有些特色的：

　　通过 Https 请求去服务端获取数据 。支持 Http 是最基本的，但小程序对 Http 有所限制，除了要求通信协议是 Https、出现的域名必须提前预设之外，还将应用层协议限定到了 Json 格式下，这一点，可能比任何一个已有客户端平台更为严苛。站在小程序的平台角度来看通过这样的小程序规则，可以对应用中流动的数据有了更强的管控能力。只是对于开发者而言，则需要花些时间去调整自己的服务协议以便适应小程序的要求，即便你对它的设计不认同。

　　类似于 Local Storage，小程序提供了 APIs 供开发者在手机系统上存取文件，可以在本地文件系统上缓存小程序数据 。小程序开发者更是可以利用本地文件来做缓存、做状态记忆，对优化小程序体验有所帮助。

　　可以读写设备中的一部分信息 。小程序开放了一些 APIs，帮助开发者获得设备上的一些基本信息，比如：手机型号、屏幕尺寸，网络状态，等等。其中，比较有趣的是可以选择获取手机上的图片等多媒体文件，这给做一些图像相关的应用提供了可能*;以及，它还提供了不少设备上罗盘、重力感应器、地理位置等相关的信息，对开发者理解用户所处的环境有很大帮助。

　　除此之外， 小程序提供了微信生态中的一些数据。比如账号信息。这对于微信庞大的生态而言，只是非常小的一部分数据，但确是开发小程序应用中最值得利用的一部分数据。举个例子，在其它平台上，如果需要获取到微信的账号信息，需要通过一次用户授权。如果用户暂时不想提供，则会使得程序出于 “未登录” 状态，给整个服务的展开带来困难。而在小程序中，只要用户点开小程序，就意味着完成了授权，开发者可以直接读取到小程序的账号信息，并可以同步到自己的服务端作为该用户的身份标识，从而实现 “始终登录” 的状态，使得后续服务可以更好的提供。

　　很明显，小程序中提供的数据获取方式，基本就等价于一般的浏览器的能力，比原生的客户端还是要局限不少，尤其是涉及到设备能力的方面。最有趣但也是最遗憾的是，小程序暴露了一丢丢微信提供的服务，借着微信的账号体系登个录付个款还是没有问题的(当然，要审核)，但想摸摸会话用用公众号，抱歉，不允许。

　　二、小程序的后端开发界面如何呈现?

　　小程序刚发布的时候，人们惊呼 Html5 的时代就要到来了不懂 Web 技术的码农即将拎着破旧的*能返回老家挖煤。但很快，随着聪明的程序员们就识破了，因为看上去在界面层小程序也运用了 Html/CSS/Javascript 这套 Web 的技术栈，就发现小程序所说的这些，和我们理解中的 Html5 技术，大概就是 Java 和 Javscript 间的差距。

　　在小程序中，和 Html 对应的是 WXML ，它保留下来的只有 Html 的语法概念，而传统的

　　标签都完全被抛弃了。和 Facebook 的 React 类似，小程序引入了自己的 Html 标签，它和 这样的语义标签不同，小程序中的标签，更像是传统客户端开发中的组件 (或者叫控件)，每个组件都有自己背后的职能和使用方式。

　　比如，大量的内容网站，其文章内容都是存储为一个 Html 片段的，这样东西，是没有办法直接在小程序界面上渲染的。如果需要展示，一个思路是构建一个中间服务，将 Html 转译成一种更简单利于渲染的中间格式数据，然后，在小程序端把中间格式的数据转换成小程序的标签进行呈现。我们在做 轻芒生活 的时候，正好设计并实现了一个转义服务，将任意一个 Html 页面转换成中间格式，解决了内容* Html 页在小程序上的呈现问题。　　

　　(在小程序后端呈现 Html 内容页)

　　和 Html 相比，小程序的 WXSS 算是比较完整的保留了 CSS 的特征，这一点在我看来，是个负面消息。WXSS 在语义上最大的不同，一是在于它支持了相对尺寸单位 rpx ，每 750rpx 等价于当前设备的屏幕宽度，这个相对尺寸单位的引入，确实能把繁复的屏幕尺寸适配变得简单了不少。而和 CSS 的另一个不同，是它更像传统控件样式用法，不支持 CSS3 那么多的选择器和联级，使用中，更多的是一个控件一个 class 这样来使用。

　　小程序中虽然号称支持 ES6 标准的 Javascript(然后 ES6 转 ES5，可用*奇差)，但窗口级的 Javascript 在小程序中完全被废弃掉了，你无法用 Javascript 去调用 window、document 对象来修改界面元素完成逻辑。小程序中的 Javascript 其实直接对应 node.js 的用法，用来完成后台业务逻辑，而不是直接控制交互。小程序的这个设计，使其可以用到 virtual dom 的方式来渲染界面，让界面数据更新时的*能优化成为可能，但付出的代价就是少了窗口级 Javscript 的那层胶水的黏合，使得很多功能的开发变得极其呆板和繁复。

　　三、小程序的后端交互如何传导?

　　所谓交互的传导，是当用户和小程序界面发生交互式，平台框架通过某种方式告诉业务层，并将处理后的变化呈现回交互界面上。如果把 WXSS + WXML 绘制的页面看成 “前端”，把 Javascript 撰写的业务逻辑看成 “后端”，你会发现，小程序的前后端交互特别像 Web 1.0 的模式，前端把交互行为封装成事件(event)发送到后端，后端处理完成后，通过 setData 方法将数据回传到前端。

　　小程序提供的 Events，有类似单击、长按、触摸、滑动，等等，对于视频播放器等控件，还有监听播放、暂停之类的。这些事件涵盖算是比较基础的，更高级的手势、多点触控，等等，就欠奉了。

　　而小程序给界面响应的唯一方式，是通过 Page 中的 setData API 对界面上的数据进行更新， 小程序自己来比较两次调用期间数据的变化，进而决策需要更新哪部分的交互界面。

　　举个实际的例子，假设开发者需要做一个滑动切换页面的效果，在小程序中该如何实现?首先，可能需要引入一个模版参数，假设是 distance，放到需要移动的页面组件上。然后，给支持移动的控件，全部绑上 bindtouchstart 之类的事件回调函数。当用户开始滑动，事件就触发了，回调中的 Javascript 就开始计算 distance 的值，并通过 setData 告诉前端。小程序会算出来这次需要变化的东西，然后修改对应的 virtual dom 节点，而后渲染。

　　这个交互模式，是典型的单向模式，前端回传事件，数据单向的推到前端，而不是通过类似 “变量” “状态” 这样的方式直接控制。这样，开发者对界面变化的控制往往不可能太精准，整个核心，都依赖小程序对两次数据变化的 diff 计算，这个会最终影响整个交互的*能。

　　四、小程序的后端开发模式的特点是什么?

　　稍微梳理一下。小程序是借了 Web 开发的技术栈，行了传统客户端开发的模式，这一点和 React 等平台会比较相近，也算是站在巨人的肩膀上又弄了一套似而非似的私家轮子。

　　在整个小程序框架上，最大的限制是小程序开发者其实是无法通过 Javascript 这样的编程语言对界面直接进行控制的，而是需要通过小程序数据来间接实现。这对于缺少开发经验的人而言，降低了理解的门槛，是一件有益的事情。但对于复杂的应用而言，这个模式开发起来增加了理解小程序代码的成本。

　　以上就是小编找到的关于小程序的后端开发资料的全部内容了，很全面吧?基本上大家实现小程序后端开发需要掌握的资料都在上面了，希望大家开发成功哦!

　　微信小程序后端php开发介绍及开发步骤

　　微信小程序后端开发的步骤

　　微信小程序后端JAVA的使用代码详解