上不了线的小程序

写在前面

还是自用的RSSHelper,本来想通过小程序跨平台,丢弃ionic的,后来发现上不了线

零.注意事项

如果准备做个想上线的小程序,务必先仔细确认以下几点:

1.内容能否通过类目审核

一级分类是快递邮政、教育、出行、生活服务、餐饮、旅游、工具、商业服务、体育,向下更细,然后发现竟然没有合适的分类

所以尽早出DEMO提交审核确认内容是否合法,不要吭哧吭哧干了一个月,最后发现无法上线

2.功能及交互能否满足需求

比如取用户信息、定位、音频视频、文件、罗盘蓝牙加速器等等,提到的这些都支持,但支持到什么程度,存在什么限制,都需要通过文档了解,甚至DEMO验证

做到一半发现不支持XXX功能,就麻烦了

比如目前不支持展示H5页面,不能通过小程序直接展示(嵌webview之类的),也不能跳转浏览器打开,对于资讯类App,就是极大的限制

如果想做个自用的小程序,也要考虑上面的问题,因为不上线连自用都不允许(预览有过期限制,半小时吧)

一.限制

1.接口

小程序接口强制要求HTTPS

设置/服务器域名request合法域名
socket合法域名
uploadFile合法域名
downloadFile合法域名

服务接口白名单只能是HTTPS域名,否则IDE开发环境都发不出去请求。如果接口还是HTTP,只能临时走假数据,本地mock服务也不行,因为有严格域名校验

所以第一件事是确认接口支持HTTPS,如果不支持,尽快把服务搬过去,否则需要假数据模拟各种接口,比较麻烦,而且毕竟与真实请求不同,不利于及早发现问题

P.S.关于免费HTTPS,可以参考nginx HTTPS反向代理

2.bundle大小

源码及资源打包后大小不能超过2M,对于图片资源不多的纯手工项目还好,如果:

  • 图片资源很多
  • 依赖一些第三方lib
  • 项目规模较大(代码量)

一级页首屏图片资源非常多的话,除了压缩没有更好的方法,非一级页首屏图片可以放到服务端去。第三方lib尽量少用,2M限制下,引入第三方lib就必须要仔细考虑了。项目本身非常庞大,比如几十万行代码量的话,gg,这算大程序

P.S.bundle大小超出2M的话,无法提交编译包,提示删除文件重试

3.账号类型及认证

与公众号管理方式一样,区分个人号、企业号、认证与否等等:

卡券接口 要求认证
开放平台绑定小程序 要求开发者资质认证

P.S.无论个人公众号还是个人小程序,都无法认证,交钱的机会都不给

相对订阅号与企业号的差别,小程序的限制少了一些,仅卡券API有限制。对于公众号绑定小程序,

另外,个人公众号无法注册小程序(可以关联小程序,提供入口),所以迫不得已又弄了个邮箱

暂不支持个人/媒体/政府/其他组织快速创建小程序,请按照普通流程完成注册。

4.内容审核

分为2部分,类目审核与功能审核

上线难最主要的原因就是类目审核,目前仅支持一部分App类型,限制远比想象的要大,目前似乎集中在信息查询、订单等方面

类目审核没的商量,如果审核结果明确指出暂不开放该类目,只能先放弃

功能审核就是提测,交互不友好、功能不可用、太过简单等等都可能是被拍回来的理由,但能通过改代码解决的问题自然不是问题

5.不支持递归模版

声明并引用模版:

<template name="node">
 <text>{{node.text}}</text>
 <block wx:for="{{node.children}}">
   <template is="node" data="{{item}}"></template>
 </block>
</template><template is="node" data="{{node}}"></template>

希望展示树形数据:

node: {
 text: 1,
 children: [{
   text: 2
 }, {
   text: 3,
   children: [{
     text: 4
   }]
 }]
}

结果只展示了1,没有递归向下,无法满足需要展示无限层次结构的场景

为了解决解析渲染HTML的问题,有人想了一个笨办法,复制n个模版,顺序嵌套:

<template name="node-level0">
 <text>{{node.text}}</text>
 <block wx:for="{{node.children}}">
   <template is="node-level1" data="{{item}}"></template>
 </block>
</template>// copy node-level1
// copy node-level2
// copy node-level3
// ...

这样复制多少份,就能支持多少层,缺点是模版文件会巨大无比,维护也是个问题,但目前还没有更好的办法

二.项目Demo

尝试之后采用这样的结构:

common/
 cache/        内存缓存、持久缓存
 components/   共用组件
 pages/        公用页面
   detail/
   list/
 request.js    接口包装
config/         常量配置
image/
pages/          各独立页面
 tab1/
 tab2/
utils/
<3rdLib>/       第三方依赖
app.js          入口
app.json        应用级配置
app.wxss        应用级样式

需要注意页面声明问题:

  • 所有独立页面,都必须在app.jsonpages里声明路径
  • pages第一项是首页,后续增减页面都要修改pages配置
  • tabBar的第一项必须与首页一致,否则tabBar不显示也不报错

配置相关的一些问题,没有任何报错,很难排查

用到了一个HTML支持库(999颗星了,说明HTML展示需求很旺盛),负责解析HTML,转化成小程序原生组件展示

目前不是很完善,解析结果标签数量很大(iOS上没有发现太明显的性能问题,但肯定有优化空间),另外,对于pre, code, span等的支持效果比较差,代码展示效果不好。可以服务把代码转图片,一劳永逸,或者手动完善该库(结构非常简单,很容易扩展)

接口做好HTTPS之后,3天开发完毕,靓照如下:

wx_RSSHelper_1

wx_RSSHelper_2

三.开发体验

优点:

  • 整套开发调试工具很完备(调试体验很好)
  • CSS支持性非常好(从H5扒下来的样式,基本可以直接用)
  • ES6开发环境
  • 业务框架容易让人接受(数据绑定等模版语法与vue类似)

缺点:

  • IDE很难用
  • 文档不全(按下态样式如何实现之类的,完全没有文档)
  • 上线难(奇怪的类目审核,很难找到准确的类目,审核效率一般)
  • 配置化太高不灵活(一些功能只能通过配置项来完成,比如tab条,比较费劲)

原文发布于微信公众号 - ayqy(gh_690b43d4ba22)

原文发表时间:2019-06-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券