微信小程序开发思考总结——腾讯“信用卡还款”项目实践-演道网

本网站用的阿里云ECS,推荐大家用。自己搞个学习研究也不错

小程序概述

昨天晚上,微信团队对外宣布,微信小程序开放公测。开发者可登陆微信公众平台申请,开发完成后可以提交审核,公测期间咱不能发布。

我们前一段时间也进行了小程序开发,现在来对之前的开发体验做一个总结。

1. 小程序是什么?

微信小程序是一种介于原生app、和web app的hybrid。通过微信进行加载,实现类似原生app的流畅。相对原生app来说,小程序更加轻量、更新实时、跨平台;相对web app来说,小程序资源离线,体验更流畅。

微信小程序的设计目标是通过尽可能简单、高效的方式让开发者可以在微信中开发具有原生APP体验的服务。

不说那么多了, 先来看看小程序的效果:

看完效果,是不是对开发充满好奇~

2. 小程序的实现机制

小程序的开发是基于微信提供的一套应用框架进行开发的。微信通过封装微信客户端提供的文件系统、网络通信、任务管理、数据安全等基础功能,对上层提供了一套完整的Javascript Api,使得开发者能够非常方便的使用到微信客户端提供的各种基础功能,快速构建一个应用。框架设计如下:

框架提供了自己的视图层描述语言 WXML 和 WXSS,以及基于 JavaScript 的逻辑层框架,并在视图层与逻辑层之间通过单向数据绑定进行数据传输,使开发者更加聚焦于数据与逻辑上。

3. 支持的特性

接下来我们来看一下,微信框架具体提供的特性:

wxml:一切皆组件(视图组件)

  • view组件(类似 H5中的div)
  • input组件(type = digit,有带小数点的9宫格键盘)
  • modal弹窗组件 (对应的wxml、效果如下)(该组件已换js 实现wx.showModal())


更多wxml组件,请查看微信公众平台小程序文档

4. 功能API:

  • 支付
  • 微信信息的获取
  • 网络请求
  • 录音
  • 上传/下载文件
  • webSocket
  • 访问相册

更多详细的API,请查看微信公众平台小程序文档

5. 其他:

  • 下发消息通知
  • 简要的统计(pv、uv)

现在我们来具体开发~

小程序的开发流程

一、获取微信小程序的 AppID

二、创建项目

创建项目,需要通过开发者工具来完成。(工具在微信小程序公众平台下载)

三、编写代码

首先我们来看一下小程序的目录结构:

微信对小程序的开发有些规定:

上图左侧3个文件是放在小程序的根目录中,其他文件由开发者自由控制。

  • app.js是小程序的脚本代码,用来监听并处理小程序的生命周期函数、声明全局变量
  • app.json 是对整个小程序的全局配置,配置小程序是由哪些页面组成,配置小程序的窗口背景色等。

  • app.wxss 是整个小程序的公共样式表

其中app.js,app.json是必需的。

小程序页面是由同路径下同名的四个不同后缀文件的组成:

  • .js后缀的文件是脚本文件
  • .json后缀的文件是配置文件
  • .wxss后缀的是样式表文件
  • .wxml后缀的文件是页面结构文件

在H5开发中,我们是通过在页面中,引入对应的css、js,而小程序开发不需要在wxml中引入,它们是通过相同的名称,将页面与逻辑js、样式进行关联匹配。

接下来,我们动手具体开发吧~

框架:小程序内嵌微信框架,不需额外框架

一般来说我们开始开发,都会从框架开始进行设计。而小程序在封装了一个为客户端设计的框架,作为小程序的开发者是基于该框架开发的,目前现有的框架不用考虑,并且也不需要考虑。

现有的框架基本都是建立在window、document对象上。小程序是没有window、document,或者说没有浏览器BOM这个宿主环境。你可以理解为小程序的宿主环境是类似node的宿主环境,而不是浏览器客户端。关于这个环境的设计,感兴趣的童鞋可以参考PWS

模块化:形式上支持CommonJs,加载引用更像ES6

小程序形式支持CommonJS,通过require加载,跟node、seajs类似。但是通过require加载的是引用的赋值,而不是CommonJS中的值的缓存。

小程序的模块书写:

小程序的模块运行(类似node,框架会自动添加外层define):

模块化:UI组件设计

在开发时,与视图相关的组件模块化时,我们可能需要注意一下。例如弹框,在H5中,我们一般是将其封装成一个模块组件,这样可以复用。在小程序中,视图只能在wxml中,不能动态生成。

首先,我们看一下微信的弹窗的视图组件modal,微信之前给的api是这样的(该组件微信已经使用其他方式实现, 这里用它来描述问题):

 

看到这样,你是否有联想,如果一个页面需要使用100个弹框,开发者需要创建100wxml组件,及注册对应的100个确定按钮的事件,100个取消按钮的事件。这显然是不合理的。

能不能在框架上进行封装成一个通用组件,开发者只需传入对应的事件句柄即可?后期微信可能会考虑封装吧~

NO~!

为什么呢?我们从框架组件设计来看,框架本身采用面向状态的编程方式,组件部分类似redux的设计(实际不是redux实现的)

组件的View在action操作后,只能通过action的业务处理进行更新View。而框架是单向数据绑定,无法自动更新。

对于这一类View组件自带action的,建议进行必要再封装。封装可以考虑aop的方式动态的注册&卸载

1. 定义组件的通用模版

2. aop方式封装组件的逻辑

1)组件的默认配置:

2)组件的封装实现

3. 组件的使用:

1)在页面wxml中引入组件的模版

2)在页面js中,随时不限次数使用弹框

目前该组件微信已经封装(api:wx.showModal()调用弹框),不过action不能自动更新的特性依旧存在,开发者如果需要自定义其他带有交互的UI组件时,依然会遇见以上问题,可以参考以上解决思路。

具体页面开发

对于业务页面的开发,可以将页面视为一个页面组件。在这个页面组件,完成了以下工作:

  1. 负责初始化组件state(微信)
  2. 负责组合子view组件形成页面效果(开发者)
  3. 确定js 与view 匹配的数据(开发者)
  4. 负责注册业务逻辑对象提供的业务逻辑方法(开发者)
  5. 负责管理业务逻辑对象(开发者)

1) index.wxml

2) index.js

页面wxml与页面js的通信如下(简化了微信框架的工作)

在页面开发我们需要注意的有:

  • index.js中的data数据只读

页面js中,data数据是需要约定为只读。框架是单向数据绑定,修改data中的数据不会自动更新View;更新view,需要使用setData()方法。setData()更新View时,与data中的数据进行Diff比较,不同才会更新。这样如果直接修改data,很容易造成data中的数据与View不一致。

  • setData单次设置的数据不能超过1024kB,需要避免一次设置过多的数据。
  • template,这些模版具有自己独立的作用域。
  • 支持ES6中的…展开模块数据。

{{…cardInfo}},模版中的数据{{card_name}}、{{bank_simple_name}},对应data中的数据就是data:{cardInfo:{card_name“”,bank_simple_name:“”}},方便了对子view的控制。

这样就完成了页面级的开发~~YES!

小程序与H5的区别

在具体写代码,小程序与H5的开发有什么区别呢?

javascript:

(一)限制:

  • 通过传入字符串来执行代码的能力都禁用了

出于安全考虑,凡是通过传入字符串来执行代码的能力都禁用了。具体被禁掉的原生功能有:new Function、eval、Generator。这是同时也比较有效的避免了类似H5 中xss的问题。

禁掉的这些功能,对我们开发来说影响比较显著的应该是字符串转json,以往我们都是通过new Function、eval来处理后台cgi的返回。(移动端一般封装在zepto之类的框架中),小程序开发需要改变一下具体实现。

  • 与浏览器BOM相关的api都是没有的。

在这些BOM中,对开发影响最大的应该是没有cookie。因为其他功能例如storage,小程序有类似的处理方法。而cookie在web开发中是与后台登录相关的。

小程序中是没有Cookie的,为了兼容目前大部分web app 的登录管理是使用cookie的。小程序在请求发送时,客户端可以动态的给请求设置Header发送报文的cookie。

注意一下cookie本身不能在客户端进行读写。

因为没有cookie,H5中的csrf问题理论上是根本解决了。小程序是否存在其他客户端安全问题,需要技术、时间来检验~

(二) 优化

  • 登录:

H5中,通过微信授权一般采用url重定向的方式获取code;在小程序中,通过wx.login获取code,这样避免了之前登录重定向的问题。

  • storage:

小程序用storage替代了H5中的localstorage、sessionstorage。storage对每个小程序的大小是10M,支持同步和异步。

  • 微信支付路径不再受限

(三) 不便

1)每个页面是需要手动在app.json中进行注册。如果没有注册,是不执行该页面的。
2)打开的页面有5个的限制,在开发时需要主要控制打开页面的数量

wxss:

  • wxss 不再支持媒体查询
  • 增加了app的flex布局
  • 引入rpx的概念

rpx(responsive pixel): 可以根据屏幕宽度进行自适应。规定屏幕宽为750rpx。如在iPhone6上,屏幕宽度为375px,共有750个物理像素,则750rpx = 375px = 750物理像素,1rpx = 0.5px = 1物理像素。

  • wxss中,不能使用背景图片。这跟框架的设计思想认为一切皆组件有关
  • wxss动画不支持(目前)
  • 不支持多层选择器.classA {} – 支持; .classA  .classB {} – 不支持 (api说明表示只支持单层选择器,重构测试有时多层是支持的)

四、调试

开发完成后,我们进行调试查看效果,跟移动开发差不多,增加了手机端的log。

开发工具调试:

手机客户端:点击右上角开启调试

五、构建

小程序是采用类似node的本地加载模块,不需考虑seajs中的模块合并,只需要uglify即可。当然如果你采用ES6开发,那还是需要bebal一下。

六、测试环境

具体微信还在调整中…

七、发布

在开发工具中,进行全量提交,通过微信审核后,在微信小程序平台进行最后发布。文件发布加载的流程如下:

八、版本更新

小程序的更新是在启动时进行更新的,首先与客户端版本进行对比,是否有新的版本,如果有新版本,小程序更新,再运行;否则,直接使用本地资源运行。

这样小程序的整体开发发布就Over了~

个人对小程序产品的看法:

优势:

  1. 低门槛下载,作为微信的一环,可以通过微信直接进入,即可使用。几乎可以认为是网页,没有下载门槛。
  2. 跨平台,微信客户端底层封装,支持小程序跨平台
  3. 开发成本低,通过之前的开发对比,小程序的开发比web app 的开发成本还低,并且前端的资源存放、发布运维都集成在微信中(如果和腾讯云功能合加,纯属联想~~ 呵呵)
  4. 页面仿原生,体验更流畅
  5. 小程序可以使用微信的支付功能

局限:

  1. 开发基于微信框架,部分功能受限,不支持现有的其他第三方插件;
  2. 小程序页面只能同时打开5个,如果交互流程较长难以支持;
  3. 小程序包大小限制为1M(目前),所有只适合轻量级

关于微信框架api 的具体内容,请参考

https://mp.weixin.qq.com/debug/wxadoc/dev/index.html

建议在开发小程序时不要以web app的开发思维去思考~

结语

从8月开始加入该项目的内测开发,期间经过了几次地动山摇的调整,及不断的痛苦的迭代,所幸的是框架、开发工具已经趋于完善稳定。期待小程序的正式亮相~~

如果您觉得我们的内容还不错,就请扫描二维码赞赏作者并转发到朋友圈,和小伙伴一起分享吧~


本文系腾讯Bugly独家内容,转载请在文章开头显眼处注明作者和出处“腾讯Bugly(http://bugly.qq.com)”

转载自演道,想查看更及时的互联网产品技术热点文章请点击http://go2live.cn

未经允许不得转载:演道网 » 微信小程序开发思考总结——腾讯“信用卡还款”项目实践-演道网

赞 (0)
分享到:更多 ()