0.0 前期准备
微信小程序的出现极大地降低了个人开发者微创业的门槛, 不需要后端技术, 不需要服务器和域名这些乱七八糟的前置操作, 只需要懂得前端技术, 就能发布一款属于自己的轻量级应用, 简直是前端开发者的福音呐
现在其实更火的当是微信小游戏, 小程序热度排行榜上长期被小游戏霸屏. 但小游戏的开发技术栈比小程序要多, 需要的人力物力也更大. 目前正在研究之中, 有时间再做讨论.
在开始之前需要准备一个邮箱去创建一个小程序账号. 一个邮箱能且只能创建一个小程序, 这让人有点难以理解, 每创建一个小程序就要去申请个邮箱账号, 小游戏同样是这样, 导致我现在都不知道自己有几个邮箱账号了.
0.1 创意
虽然研发成本极大降低, 但想要做出一款成功受青睐的小程序, 还是需要动很大的脑筋的. 据不完全统计, 现在市面上已发布的小程序已经几百万个, 想要在这么多的形形色色的小作品里面脱颖而出, 要么就是你的作品非常有创意, 戳中了一些人的痛点, 要么就是你路走偏锋, 做了漏网之鱼
相比之下, 小游戏却是更能突显创意的战场. 2048, 围住神经猫, 跳一跳这些让人眼前一亮的精致小玩意儿, 都是创意制胜的代表. 奈何在下也是应试教育的产物, 脑子里的创新区域只在做梦的时候才会活跃. 假如你想到了一个有趣可行的点子, 那离用户百万就已经成功了一半. 我一位同事说想做一个实时社交的小程序, 让用户可以实现无障碍沟通. 我当时就想, 这样有理想的人怎么就和我做了同事了呢
0.2 技术
小程序的运行环境
小程序的运行环境可以用一句话概括: 敌情相当复杂.
在 iOS 上, 小程序逻辑层的 JavaScript 代码运行在 JavaScriptCore 中, 视图层是由 WKwebView 来渲染的, 环境有 iOS8,iOS9,iOS10
在 Android 旧版本 上, 小程序逻辑层的 JavaScript 代码运行中 X5 JSCore 中, 视图层是由 X5 基于 Mobile Chrome 57 内核来渲染的
在 Android 新版本 上, 小程序逻辑层的 JavaScript 代码运行在 V8 中, 视图层是由自研 XWeb 引擎基于 Mobile Chrome 67 内核来渲染的
在微信开发者工具上, 小程序逻辑层的 JavaScript 代码是运行在 NW.JS 中, 视图层是由 Chromium 60 Webview 来渲染的
也就是说一切以实物为准, 在微信开发者工具上的表现和真机上的表现不尽相同, 在真机的不同机器上表现也会因机而异
另外由于是寄生在微信上, 所以微信又做了一层封装, 额外加了一些限制, 比如
不支持使用 eval 执行 JS 代码
不支持使用 new Function 创建函数
也就是不让动态执行 JS 代码, 说实话, 这确实挡住了很多骚操作. 正所谓人在屋檐下, 不得不低头. 鉴于微信提供的巨大流量入口和裂变能力, 就这样凑合着用吧
上面这些都是各种限制, 兼容性问题, 当然也有让人开心的地方, 那就是 CSS3 和 ES6 的特性基本上可以随便用, 记住是基本上.
技术栈
众所周知, 浏览器的 Web 技术是 html,CSS 和 JS. 而小程序虽然类似浏览器, 但并不是浏览器. 所以他的技术是 wxml,wxss 和 JS. 应该说并没有什么新的技术, 就是照抄 Web 标准然后本土化了一下. 前端同学基本上可以无缝切入.
我们开发 Web 的时候基本上不会直接去写原生 HTML,CSS,JS, 而是使用一些框架和库提升开发效率, 例如曾经的 jQuery, 现在的 vue,react 等. 小程序也是如此, 通常不会去直接写原生 wxml,wxss. 当然如果喜欢的话也可以直接去写, 但随着项目迭代很快就会难以维护. 要知道软件工程的奥义即在于控制复杂性. 现在 GitHub 上已经有了一些不错的框架出来, 比如 https://github.com/Tencent/wepy , https://github.com/Meituan-Dianping/mpvue .
前端技术 + 小程序官方文档 + 框架文档, 基本上这三样就能 hold 住一个小程序了
说下我的小程序官方文档读后感, 不到一个小时读完了简易教程, 感觉挺简单的嘛, 简直小 case. 然后去读小程序的框架, 组件和 API, 卧槽, 才发现刚才只是读了一本厚书的目录. 接下来断断续续看了将近一个月, 才勉强看了一遍. 哈哈, 一切事情都不会像看上去那么简单呐! 但如果只是作为入门, 不需要很多高级特性, 则不需要读那么多章节.
0.3 实际开发
调试预览
工欲善其事, 必先利其器. 我们开发 Web 时可以随便在某一个你喜欢的浏览器里预览效果, 小程序就没那么随意了. 因为小程序的宿主是微信, 所以小程序只能在微信中才能跑起来. 好在微信团队还是挺给力的, 为开发者专门开发了一个预览调试工具, 即微信开发者工具. 修改代码后即可在该工具上实时看到效果, 但可是, 该工具上呈现的效果并非是真实手机上呈现的效果, 就像 Chrome 开发者工具的模拟设备模式一样, 虽然八九不离十, 但是差之毫厘即谬以千里. 这个工具上常用且实用的功能还挺多的, 建议好好熟悉, 文档在此, 当然最快熟悉的方式还是点点点, 哪里不懂点哪里
选个框架
现在的主流框架选择只有 wepy 和 mpvue 两位, 两者都是向最 nb 的 vue.js 看齐. 经过仔细斟酌, 多方位比对, 最终我还是选了 wepy, 因为发现 wepy 的星星要比 mpvue 的多上几个哈哈. wepy 文档在此 https://tencent.github.io/wepy/ . 用了 wepy 将近一年时间, 发现坑还挺多的, 可能我对他的期待是像 vue 一样吧, 期待太高了.vue 稍微高级一点的特性都不支持, 有一些实现还和 vue 是反着来的. 不过那还能怎样呢, 自己搞一个框架出来? 在下实在才薄智浅. 曾有一段时间被坑得决心要转向 mpvue, 但机智的我先去谷歌了一下 mpvue 的坑, 发现相较 wepy 只多不少, 哈哈我赶紧说服自己还是好好和 wepy 凑合着过吧.
接下来就是写代码开发了, 此处直接省略十万字, 具体开发的细节就不说了哈, 开发 - 调试 -...- 开发 - 调试, 无限循环, 大家都懂的
开发中遇到的坑
[wepy] 多次路由到同一个页面时, 页面上的变量会相互污染 https://github.com/Tencent/wepy/issues/2023
[wepy] 组件是静态组件, 导致每实例化一个标签都需要在 JS 的 components 里声明一次
[wepy] 在更新数据之后需要调用 this.$apply() 更新视图, 准确的说应该是在异步更新数据之后, 也就是说他不是双向绑定
[小程序] 文件下载, webview,Ajax 都需要在小程序管理后台配置安全域名, 否则都会失败.
[小程序] webview 和 h5 通信的方式 postMessage 机制只在特定时机触发, 也就是除了这些时机, webview 和 url 完全无法通信
[小程序] Web-view 中使用 input type='file'闪退
小程序的坑可以单独拿出来写一篇千字作文了, 有时间再总结一下, 此处就不再举例了
0.9 提交微信审核
此时功能已经开发测试完毕. 接下来就是让用户看到我们辛辛苦苦完成的作品, 虽然可能不受待见, 甚至被疯狂吐槽, 但更大的可能是用户根本不会去访问你的小程序, 除非你有自己的推广渠道, 比如公众号, 微博等, 否则微信用户纵然数十亿, 你的小程序用户却很难破零哈哈.
不管结果怎样, 先发布再说. 首先需要点击微信开发者工具工具栏的上传按钮上传小程序代码, 上传成功后即可前往微信公众平台小程序管理后台 https://mp.weixin.qq.com 去提审你的小程序了, 在版本管理里面选择刚才上传的那个版本, 然后填写一些信息即可提交审核. 首次提交审核通常会等待 1~2 个工作日, 之后迭代版本一般 1~2 个小时即可过审.
微信审核还是挺严格的, 审核规范在此. 比较普遍的做法是通过后端接口在提交审核时候过滤敏感内容, 以此混过去, 等发布到线上之后再把敏感内容放开. 哈哈只要思想不滑坡, 办法总比困难多.
1.0 发布上线
终于, 最后的最后, 小程序审核通过了, 可以发布到线上了. 审核通过之后不会自动发布到线上, 需要手动去点发布. 发布到线上之后就可以去微信上任何一个入口搜索自己发布的小程序了.
到此可以长舒一口气了, 因为已经走完了万里长征的第一步, 接下来就是思考怎么去推广和运营小程序, 总之, 这只是刚刚开始.
最后贴一下自己辛辛苦苦的成果
我去看了一下管理后台的访问数据, 果然不出所料, 用户量至今尚未破零
来源: https://juejin.im/post/5c78feb2f265da2da955cee5