上不了线的小程序

写在前面

还是自用的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.json的pages里声明路径
• 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条，比较费劲）