三个月,从无到有,“肆意”生长出一个基于原生nwjs的庞然大物(小程序),希望能大概描述一下当前小程序的“轮廓”,去糟粕取精华。

运行单元:page + component

每一个目录下由三剑客组成scss、wxml、js;

数据状态管理

关于数据的管理,现在相对比较混乱,没有一个确定的规范,列一下目前在用的几种手段;

  1. 全局共享一份数据

实例放进全局app实例中,通过方法进行获取,可以解决拿取数据重复请求的问题

  1. 页面数据

页面尽可能拆分组件,便于状态管理,简化页面结构

  1. 层级跨度较深的联动,通过eventbus解决,尽量不用或者少用
  2. westore,嗯...从入门到放弃,以上三种基本能够满足现在的需求

组件共享

目前项目中的组件主要分为:

  1. 纯ui组件(dxy-image、item)
  2.  布局组件 (card、layout)
  3. 业务组件(输入id => view)
  4. 页面级组件(约等于page)

项目中在主包以及子包中落地对应demo页,展示组件,业务在快速迭代中,落地的demo明显滞后

开发发布流程

项目配置及主要三方包

当前项目主包约1.2M


性能优化

  1. 非可视区域,延迟加载,例如swiperview的使用。
  2. 防止内存泄漏,页面退出要及时清理,例如setInterval等
  3. 多用img lazy-load,对于大图片,backgound-image不是一个好选择,图片合理压缩,对内存帮助很大,根据视窗大小控制压缩比,webp在当前除兼容性较差外,在小米等机型表现也很一般。
  4. 多余数据禁止setData(如audio实例),页面退出及时销毁实例;避免使用多余的coputed属性,多用wxs ;善用延时,非及时数据延迟初始化或懒加载,控制加载时序,必须高内存高运算的持续工作。
  5. 页面隐藏(非销毁状态),停止响应setData,避免不必要的消耗。
  6. asset禁止放置大的图片文件,选择iconfont,不可用iconfont尽量走cdn
  7. 尽量避免sync-api 例如storageSync-api,此类api响应不稳定,并会阻塞全局进程,当前引入的weapp-cookie.js库就是利用的同步api
  8. 配置项目禁止打包非生产环境相关文件,json、js结尾的都会被统一打包,通过配置排除
  9. 打包工具不会对wxss进行压缩,配置压缩wxss减小包体积
  10. 列表尽量采用scroll-view,利用视图recycle提高性能
  11. 从深层次页面回到首页,可以考虑relaunch
  12. ...


未解决问题

  1. 报错日志,例如:

a. setStorageSync:fail;at App onError function;at api request success callback function   同步方法失败,主要存在cookie设置中;

b. SyntaxError: Attempted to redefine property '13'.

c. Error: module "weapp-cookie.js" is not defined

  1. 内存过大、黑屏/闪屏问题在部分机型仍存在(尤其小米8)
  2. ...