那些年我们踩过的css样式不能引用本地图片资源，只能引用网上资源（background-image），本地图片资源只能用标签引用。{{}}不能执行函数方法，{{}}只支持基本的简单运算和ES6扩展运算符。价格格式化等常见处理只能在js代码中处理，然后在模板中渲染。this.setData({price:this.formatPrice(this.data.price)})通过wxs模块可以解决{{}}中函数无法执行的问题。可以模拟vue.js中过滤器的功能。价格：{{tools.formatPrice(price)}}//wxs模块varformatPrice=function(price){price=price>>0;返回数字（价格/100）.toFixed（2）；}module.exports={formatPrice}小程序不支持分享链接到朋友圈，暂时通用的做法是生成页面小程序的图片保存到本地相册。并且用户发朋友圈，自己转发。前端可以使用canvas实现，减轻服务器压力。但是会出现图片锯齿不清晰的问题。建议预览图和保存到真机的图片采用不同的尺寸。真机中保存的图片是按照750的宽度实现的，相比预览图要大一些，这样保存到手机中的图片会清晰很多。小程序布局采用rpx单位，UI稿按照宽度750绘制，UI稿尺寸直接使用即可。但是1rpx在某些机型上不会显示。可以使用H5来实现1px的效果。对于iphoneX底部按键的适配，可以使用mediaquerytogetwx.getSystemInfo来获取model。参考@mediaonlyscreenand(device-width:375px)and(device-height:812px)and(-webkit-device-pixel-ratio:3){}PageA->PageB，触发B页的操作页面A的数据已更新。A页面的数据返回和更新通常有两种方式（我们公司采用第二种方案）：监听A页面的onShow事件，在onShow事件触发时不加思索地更新页面数据。跨页面通信是通过EventBus实现的。复杂组件开发，省市三级联动选择器开发，微信地址库获取地址代码与业务使用的省区代码不匹配。页面路径的层级不能超过10层。小程序分包加载，微信对小程序包大小有如下限制。整个小程序所有分包大小不超过8M。单个分包/主包大小不能超过2M。相对于微信小程序的主流框架，wepympvueTaropepywepy应该算是最早发布的小程序开发框架了。它提供了类似于vue.js的语法风格和功能。现在stage应该也是使用最广泛的框架了。我开发的几个小程序也使用了wepy框架。先说一下我当初选择这个框架的原因。类Vue.js的语法风格，适合我们团队原有的技术栈。支持组件化（当时微信官方API不支持组件化）。支持加载外部npm包，支持ES6编写。有错误。好在开发者响应及时，基本可以覆盖大部分场景。但最大的陷阱之一是wepy组件的实现方式。组件使用静态编译的组件，即在编译阶段将组件编译成页面，每个组件都是一个唯一的实例。多个组件共享相同的数据。并静态编译组件。这样一来，组件A在A页和B页被引用，代码会被复制两份到A页和B页。导致拆分组件并没有使包的体积减小。后来在微信官方API支持组件化编程后，我们逐渐用原有完善的API重构了一些更核心更大的组件。mpvue由美团团队开发。与wepy一样，mpvue也在小程序上提供了类似vue.js的开发体验。作为后来者，抢占了wepy的不少市场份额（ps：我们团队最近也在考虑从wepy迁移到mpvue）。这个框架的原理比wepy复杂一点。mpvue修改了Vue.js的运行时和编译器实现，以提供更接近vue.js的开发体验。TaroTaro是一款遵循React语法规范，由京东团队开源的多端开发解决方案。对React和Taro了解不多，就不多解释了。具体可以参考开发组的博客和代码了解更多。多端统一开发框架——Taro看到小程序，想从技术角度谈谈我对微信小程序的理解。我认为小程序本身是一个非常好的小程序。HybridApp的技术方案。有很多值得学习的东西，可以应用到我们HybridApp的技术方案设计中。了解和学习小程序的技术原理，也可以更好的优化我们的代码。渲染层和逻辑层分离相对于之前常见的Hybrid方案，小程序采用双线程模型：小程序的渲染层和逻辑层分离，逻辑层通过JSCore解析执行，渲染层通过webview进行渲染。之前常见的Hybrid离线包方案大多是使用webview同时渲染页面和解析js。这样做的结果是隔离了js运行时，无法在js代码中操作webview中的DOM对象和BOM对象。js不能做任何与页面渲染相关的操作。数据只能通过setData从JsCore传递到webview。相对于webview，独立的JS运行环境通过同时处理页面渲染和JS执行带来了一些优势：JS不能在页面中动态插入节点和干预页面渲染，解决了安全和控制的问题，否则小程序在线评论变得毫无意义。渲染层和逻辑层的分离，减轻了webview的压力。js的执行和页面的渲染可以并行进行，不会出现js执行卡在主页面渲染的情况。多个页面可以共享一个JS运行环境，数据可以轻松共享，一个小程序的整个生命周期共享同一个上下文，接近app的体验。缺点是：很多webview和JSCore数据传输消耗比较大，数据需要序列化成字符串格式传输。离线包加载离线包加载，常见的HybridApp通过webview加载H5页面，前端页面放在服务器端。虽然保证了灵活性。但是对加载性能和网速有很大的影响。页面切换到白屏需要很长时间。小程序离线包的加载方式。一次性加载所有前端资源到本地并解压。大大改善了用户体验。不过，为了防止下载离线包的时间进程，微信官方也严格限制了小程序包的大小。（在分包加载的情况下，分包大小不能超过2M，即第一次打开加载的资源不能超过2M。）Multi-webviewarchitectureMulti-webviewpagearchitecture。小程序每打开一个新页面，都会使用一个新的webview进行渲染。为了防止webview消耗内存。小程序可以限制在不超过10个级别。PreloadwebviewPreloadwebview，微信会多预加载一个wkwebview（ios平台）放在后台，节省用户打开小程序时初始化wkwebview的时间。更多技术资料请关注：gzitcast
