小程序开发体会

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

小程序快的原理

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

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

前期我曾抓了个包试试，如下：

抓包实例

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

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

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

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

rid/sid

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

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

小程序发布流程思考

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

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

小程序流程图

小程序框架分为两层

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

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

如在视图层：

1
2
3

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

逻辑层：

page({
    data: {
        config: {
            title: '',
            name: ''
        }
    },

    updateData() {
        this.setData({
        'config.title': '腾讯周边',
        'config.name': 'Seven'
        });
    }
})

在View层渲染数据

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

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

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

其他特性

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

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

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

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

class wxLib {
    constructor() {

    }

    share(obj) {
        return {
            title: obj.title,
            desc: obj.desc,
            path: obj.path
        }
    }
}

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

import wxLib from '../../service/lib/wxLib';
Page({
    onShareAppMessage() {
        return wxLib.share({
            title: '腾讯周边',
            desc: '正品周边',
            path: 'page/index/index'
        });
    }
})

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

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

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

关于小程序定位

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

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

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

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