通过编程模式起底小程序开发技术特点

比如，大量的内容网站，其文章内容都是存储为一个 Html 片段的，这样就无法直接呈现在小程序中。如果需要展示，一个思路是构建一个中间服务，将 Html 转译成一种更简单利于渲染的中间格式数据，然后，在小程序端把中间格式的数据转换成小程序的标签进行呈现。我们在做 [轻芒生活](http://s.qingmang.mobi/10c) 的时候，正好设计并实现了一个转义服务，将任意一个 Html 页面转换成中间格式（内部名是 RAML），解决了内容性 Html 页在小程序上的呈现问题。

（在小程序中呈现 Html 内容页）

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

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

交互如何传导？

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

（小程序的交互传导）

小程序提供的 Events，基础的有类似单击、长按、触摸、滑动，等等，对于视频播放器等控件，还有监听播放、暂停等等。这些事件涵盖算是比较基础的，没有更高级的手势、多点触控等相关事件，但也还是足够让开发者具体了解用户的输入，进而做出响应。

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

举个实际的例子，假设开发者需要做一个滑动切换页面的效果，在小程序中该如何实现？首先，是将变量数据引入渲染页面：

可以看到， `distance` 是一个模版参数，它初始值为 0，表示移动的距离。通过 **bindtouchstart** 等函数绑定上 Javascript 的方法，将事件回传。

 
 
 
 
  
  
  
  
movePage: function(event) { 
  
  
  
  
 
  
  
  
  
var status = { 
  
  
  
  
 
  
  
  
  
needUpdate: false, 
  
  
  
  
 
  
  
  
  
distance: 0 
  
  
  
  
 
  
  
  
  
} 
  
  
  
  
 
  
  
  
  
// 处理各种事件，计算是否需要刷新，和移动方向 
  
  
  
  
 
  
  
  
  
if ("touchstart" === event.type) { 
  
  
  
  
 
  
  
  
  
// 开始计算移动 
  
  
  
  
 
  
  
  
  
... 
  
  
  
  
 
  
  
  
  
} else if ("touchend" === event.type) { 
  
  
  
  
 
  
  
  
  
// 判定移动的距离是否足够. 
  
  
  
  
 
  
  
  
  
... 
  
  
  
  
 
  
  
  
  
} else if ("touchcancel" === event.type) { 
  
  
  
  
 
  
  
  
  
// 被打断就算了. 
  
  
  
  
 
  
  
  
  
... 
  
  
  
  
 
  
  
  
  
} else if ("touchmove" === event.type) { 
  
  
  
  
 
  
  
  
  
// 计算移动距离 
  
  
  
  
 
  
  
  
  
... 
  
  
  
  
 
  
  
  
  
} 
  
  
  
  
 
  
  
  
  
// 根据移动的距离，来更新界面 
  
  
  
  
 
  
  
  
  
if (status.needUpdate) { 
  
  
  
  
 
  
  
  
  
this.setData({ 
  
  
  
  
 
  
  
  
  
distance: status.distance 
  
  
  
  
 
  
  
  
  
}) 
  
  
  
  
 
  
  
  
  
} 
  
  
  
  
 
  
  
  
  
} 
 
 
 

而在 Javascript 一端，则捕获事件、计算偏移量，然后将新的偏移量送到前端界面。

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

小程序开发模式的特点

至此，我们可以来总结一下小程序开发的一些特点了。整体来看，小程序是借了 Html5 的技术栈，行了传统客户端开发的模式，这一点和 React 等平台会比较相近，可以视为 HTMLl5 的一个新分支。

从设计思路看，小程序做了大量的 “限制”，***的限制，是开发者其实是无法通过 Javascript 这样的编程语言，直接对界面进行控制，而是通过数据驱动来间接实现。这对于缺少开发经验的人而言，是有益的事情，因为这降低了理解的门槛，但对于复杂的应用而言，这个模式开发起来比较呆板，往往是一个变化多处修改，增加了理解代码的成本。

开发小程序的坑

开发小程序的日子，也是一个踩坑的历程。简单总结，小程序中的坑大概来自这几个方面：

和 Web 的兼容性。小程序引入了 Html/CSS 做为技术栈，并在其基础上进行了定制。很多开发中的问题都来自于 “定制”，因为你并不知道哪部分就被定制了，哪部分是被继承了。比如，你用了一个 CSS 语法，发现并不生效，或者效果和浏览器中的不一样，于是，你只能换一个写法，结果很有可能，又会继续发现，这个新的写法可能效果也不对，于是你只能继续尝试，如此反复，可能会消耗大量的时间。

开发环境不稳定。小程序的开发，是基于微信自制的一个 IDE，但当下，IDE 的稳定性、易用性都非常之差，时常出现 Bug，你以为是你的程序写错了，但其实，是 IDE 的 Bug，重启一下 IDE，一切都引刃而解了。于是，当你日后开发小程序时出现某种异样，先重启 IDE，再看问题还在不在，也许是种更节省时间的方式。

缺少真机调试环境。小程序的运行时其实就是微信，微信几乎没提供任何真机上调试工具给你（也不能说完全没有，有一个只能在真机上瞪着眼睛看的日志框）。你在模拟器中调试好的程序，可能在真机上运行起来并不如预期。比如，我们碰到过真机上白屏、位置错乱、动画效果不对，以及 Android 上至今还不能运行，等等问题。这对于稍微复杂的程序而言，颇为梦魇，想做一些细粒度的调整和优化，基本只能靠猜。

闭源且缺少学习资料。小程序整体上是闭源状态（虽然模拟器和 IDE 部分可以通过反编译来看），且缺少足够的学习资料，如果一旦碰到控件如何使用、为什么这么用不对，之类的问题，就只能靠不停的试来解决，也需要耗费大量时间。

***介绍下「轻芒小程序+」。「轻芒小程序+」是由轻芒团队提出的小程序解决方案，它将替内容创业者免费搭建属于自己的微信小程序，其创建的小程序在内容发布之外，还将具有评论、笔记、付费阅读等特色功能。轻芒小程序+ 不打算创建一个新的内容平台，而是将内容创业者现有的自媒体账号转化成微信小程序。内容创业者只要照常更新自媒体，这些内容就能自动更新到小程序。

简而言之，做为一个新的开发平台，微信小程序从本身的稳定性，以及配套的工具链上都不算完善，这对于早期开发者而言，需要耗费额外精力去尝试和探索，但这也许就是一个新平台的价值和代价吧。