微信小程序

frank26
412 阅读6分钟

TODO: 持续更新中。。。

原理和思想

小程序是基于WEB规范，采用HTML,CSS和JS等搭建的一套框架.

  • 实现原理：底层是基于Webview来实现的，并没有发明创造新技术，整个框架体系，比较清晰和简单，基于Web规范，保证现有技能价值的最大化，只需了解框架规范即可使用已有Web技术进行开发。易于理解和开发。

  • 数据传递（setData）：小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再通过执行 JS 脚本的形式传递到两边独立环境。 而 evaluateJavascript 的执行会受很多方面的影响，数据到达视图层并不是实时的。

  • 组件机制：引入组件化机制，但是不完全基于组件开发，跟vue一样大部分UI还是模板化渲染，引入组件机制能更好的规范开发模式，也更方便升级和维护。

生命周期（函数）

小程序的生命周期 说明
onLaunch 小程序初始化 当小程序初始化完成时，会触发 onLaunch（全局只触发一次）
onShow 小程序显示 当小程序启动，或从后台进入前台显示，会触发 onShow
onHide 小程序隐藏 当小程序从前台进入后台，会触发 onHide
onError 错误监听函数 当小程序发生脚本错误，或者 api 调用失败时，会触发 onError 并带上错误信息
onPageNotFound 页面不存在监听函数 当小程序出现要打开的页面不存在的情况，会带上页面信息回调该函数，详见下文
页面的生命周期 说明
onLoad 页面加载：一个页面只会调用一次，可以在 onLoad 中获取打开当前页面所调用的 query 参数
onReady 页面初次渲染完成：一个页面只会调用一次，代表页面已经准备妥当，可以和视图层进行交互；对界面的设置如wx.setNavigationBarTitle请在onReady之后设置
onShow 页面显示：每次打开页面都会调用一次
onHide 页面隐藏
onUnload 页面卸载：当redirectTo或navigateBack的时候调用
onPullDownRefresh 下拉刷新：需要在app.json的window选项中或页面配置中开启enablePullDownRefresh；当处理完数据刷新后，wx.stopPullDownRefresh可以停止当前页面的下拉刷新。
onReachBottom 上拉触底：可以在app.json的window选项中或页面配置中设置触发距离onReachBottomDistance；在触发距离内滑动期间，本事件只会被触发一次
onShareAppMessage 用户转发：只有定义了此事件处理函数，右上角菜单才会显示“转发”按钮；用户点击转发按钮的时候会调用；此事件需要 return 一个 Object，用于自定义转发内容
onPageScroll 滑动页面
onTabItemTap 当前是 tab 页时，点击 tab 时触发

组件系统及template

组件化是实现工程化的根本，现前端优秀框架无一不实现了组件化开发。但从文件形式到数据传递机制来看，组件的又多了一套完全照搬老vue的生命周期函数，且其behaviors貌似是polymer框架早已废弃的做法，对于template更是白受诟病，总之小程序做的并不完美。但相比于简单的写静态页面，component和template及slot结合起来用还是很方便的，勉强可以达到vue/react的组件效果，期待并相信腾讯团队的更新及维护。

  • 使用心得：
    • template支持解构赋值用起来很爽；
    • component的事件传递数据机制的穿透，实现跨组件传递数据的效果挺好的，虽然思路与做法看起来极像polymer。

数据传递

方式：

  • 简单粗暴不响应式：
    • 全局变量：主要针对整个app共享的变动频繁的数据
    • 本地存储：主要针对整个app共享的变动相对稳定的数据，对于嵌套复杂的数据结构本地存储的数据在响应式更新方面可能会不和预期
  • props传递：顺应主流思路及前端友好
  • 路由传参：灵活方便
  • 事件对象（主要针对component）

踩坑指南

  • 1 移动端适配：
    • 字体/边框单位：对于字体也要用rpx（以iphone6 750px屏为参考，1rpx=.5pt），边框也可以用rpx
    • 其它单位（rpx/px/pt）：以iphone6 750px屏为参考(1rpx=1pt)
    • 文件路径: 除了js其它小程序文件都支持从根目录引入，对于图片路径可能还有其它限制；
    • 音乐播放器：
      • 多个音频的自定义组件，使用背景音乐管理器暂停及播放方面会存在模拟机上真机上运行正常的情况；
      • 多个音频组件生命周期回调上也有不合预期的bug；
      • 音频播放器及背景音乐播放器andriod上适配性不太好；
    • 五月8日起，微信小程序不支持 iOS 「虚拟支付」

项目经验及教训

  • 分工合作：
    • 对前端本身：
      • 涉及合作就要坚持code review，具体就是开分支，提pr，cr最终merge；
      • 分离UI逻辑与业务逻辑，保证各个模块之间高内聚低耦合，职责分明，不重复不遗漏；
      • 制定good practise保证代码维护性，扩展性，复用性，测试性等的可靠保证（这点对个人对团队均意义重大）；
      • 一个feature或bug，给自己规定一个deadline，如果搞不定，务必及时转变思路或求助他人；
    • 对后端：
      • 首先与他们探讨业务场景，约定数据骨架结构（Schama），约定规范统一详细的错误码；
      • 约定接口出参入参，约定接口种类，数量
      • 测试并使用他们接口，遇到问题或报错，首先看前端本身，然后看他们；务必做到及时反馈
    • 对产品：
      • 及时熟悉了解他们prd文档，领会其设计思路及初衷；
      • 根据自己理解，对不明白不理解或有分歧的地方，及时和他们探讨；
      • 了解领会prd之后，在对前端统筹规划，着手业务逻辑及UI逻辑的划分；
    • 对UI：及时交互反馈
  • 职责分化：
    • 根据业务特点及行业经验，及CTO的合理化建议，首先务必明确哪些事情前端做，哪些后端做；
    • 不要因为任何原因拒绝做（时间紧迫）或主动做（时间充裕），只关注前端领域的事情，明确前后端职责并始终坚持前前后端分离；
    • 为更好协作可以了解后端做事逻辑及特点，不代表做不属于前端的事情；

参考文档

优秀视频教程

avatar
文章
阅读
粉丝