未分类

    小程序开发体会

    过去的两个月,在组里参与了【腾讯充值小程序】以及【腾讯周边】两个项目。
    其中充值项目,由于IOS对于微信小程序的虚拟商品的限制,暂时搁浅上线,周边已上。
    下面是我遇到的一些体会,坑,以及一些感受。


    小程序快的原理

    轻应用,快一定是个最大的优点。小程序为什么这么快?平时开发是在PC端开发者工具上,可以看到各个资源的请求情况,包括js,cgi等。在真实手机上,又是怎么样的呢?

    1. 资源最初全部下载下来
    2. 图片缓存策略
    3. 小程序大小限制,最多1M
    4. 小程序页面状态缓存,webview不会被回收销毁
    5. 每个程序都是单独的进程,并且最多5个进程

    前期我曾抓了个包试试,如下:

    抓包实例

    可以看到没有我们平时在开发者工具上看到的js等资源,原因是小程序在第一次打开时就把资源预先全部从微信服务器 down 了下来到本地,(appbrand/pkg目录下,后缀名为wxapkg),存放在了本地的文件系统中,所以在你使用的过程中,只会有CGI请求发出,不会再请求其他代码资源了。

    所以这也是为什么微信会限制开发者包的大小不得超过1M。这保证了第一次加载的速度,也不至于在无WIFI情况下,耗费太多流量。

    所以如果完全可以通过一些API比如setStorage、getStorage等使用户在离线状态下也可以使用。

    后期我再抓包时,发现请求又有了写变化,如下:

    rid/sid

    猜想(未验证仅参考)这个rid/sid可能是用来判断小程序有没有资源发生变化,比如如果开发者提交了审核新版本,那么这个时候就去判断,如果有变化就从服务器拉去新的资源。如果没有变动,就用本地文件中的资源。

    再:微信对于访问过的图片,都有缓存策略,所以对比如腾讯周边小程序这样的图片很多的应用,也比较快。


    小程序发布流程思考

    1. 开发者本地开发,通过开发者工具,本地预览,提交发布。然后微信通过审核,开发者发布审核版本,用户即可搜到。
    2. 上传的代码是到了微信服务器上,统一管理。所以这里是微信服务器,第三方服务器,微信客户端三方的交互。

    这个过程中情形是这样的:

    小程序流程图

    小程序框架分为两层

    1. View视图层, 用于渲染页面结构。使用Webview渲染。
    2. App Service逻辑层,用来逻辑处理,网络请求,接口调用等等。运行在JSCore中。

    视图层和逻辑层通过JSBridge通信。逻辑层通知视图层数据发生变化,从而出发视图层更新。视图层则绑定事件,通知到逻辑层进行相应的业务处理。

    如在视图层:

    1
    2
    3
    <view>
    <button bindtap="updateData">页面跳转</button>
    </view>

    逻辑层:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    page({
    data: {
    config: {
    title: '',
    name: ''
    }
    },
    updateData() {
    this.setData({
    'config.title': '腾讯周边',
    'config.name': 'Seven'
    });
    }
    })


    在View层渲染数据

    用户打开小程序后,选择左上角的关闭或按返回键时小程序只是隐藏到后台,webview不会被销毁或者回收。比如在ios上,从小程序转到另外一个应用中,再回来微信,打开的webview仍然存在。再android上则是可以在窗口进程中再次找到先前打开的小程序。

    1. Native预先加载额外一个Webview,当打开指定页面时,无需请求额外资源,直接渲染
    2. model和view双线程,单向数据绑定
    3. 重渲染使用Virtual DOM减少开销,采用diff算法局部更新

    这里的单向数据绑定确实是有不方便的地方。先前用过Vue等双向绑定的,能够及时反馈用户的输入,相对来说这种可能更方便操作,也更适合小型应用。
    但是单向绑定就是可能更加高效一些了。


    其他特性

    1.小程序并发请求数不超过5,这里可以做优化,比如使用接口将所有的请求合并。

    2.小程序关于登录态与移动应用和网页应用的不同之处是抛弃了access_token的验证方式,而是采用session_key加签名的方式,为小程序与服务器交换敏感数据提供了对称加密方法。签名方法对小程序透明,后端服务实现相应的解密程序以及登录态验证和控制能力。由于我们部门的后台接口基本都是基于access_token这一套,后来与WX侧协商还是可以用ac.否则后台就会有很大的改动。

    3.要好好的利用小程序模板机制,这样可以减少很多代码量,也更便于维护。

    4.对于WX官方文档上的API,最好是自己封装一个WXLIB文件。这样可以减少代码量,统一整个代码。例如:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    class wxLib {
    constructor() {
    }
    share(obj) {
    return {
    title: obj.title,
    desc: obj.desc,
    path: obj.path
    }
    }
    }

    在每一个想要分享的页面就可以:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    import wxLib from '../../service/lib/wxLib';
    Page({
    onShareAppMessage() {
    return wxLib.share({
    title: '腾讯周边',
    desc: '正品周边',
    path: 'page/index/index'
    });
    }
    })

    (233,这个好像看起来没有代码量减少,但是统一了以后,其他的也统一,就会发现后来方便很多。)

    5.可以利用本地存储,解决离线的时候,黑屏无数据的情况。

    6.文档很容易理解,API也好用。基本上按照文档来大部分功能都可以实现。


    关于小程序定位

    小程序即用即走的定位原本是很好的,比如非常适合线下的营销,非常适合生活服务。比如查火车票,膜拜单车,打麻将和牌的小游戏都很合适。用户生活方便,娱乐也方便。

    但是目前来看小程序除了刚发布的时候,现在的流量目测已经越来越少,除开微信好像没有做很多推广以外,小程序还没有形成用户的习惯,可能是一个问题。

    小程序要发展起来,一定是要在用户形成了使用习惯,产生【不用装这个app,直接用小程序就可以满足我的需求】的这种想法。

    未来会怎样,取决于微信的推广和未来长远的看法。也取决是不是有很好的小程序出来。期待未来超出想象。

    下次准备写一些小程序的用法,比如模板消息,客服等等。以上内容如果有不对的地方,欢迎指正,感谢阅读。