小程序的开发不可避免的会面临跨平台开发的问题。各小程序平台有哪些特点？如何处理各平台的差异？本文分享淘票票在跨平台开发上的经验总结，包含了技术演进及差异控制策略，希望能帮助同学们提前避坑。在 2019 年，阿里巴巴文娱的淘票票几乎涉足了当时市面上所有的小程序，其中在不少平台上，我们是阿里第一批吃螃蟹的技术团队。回顾过往，我们做过很多尝试，也踩过很多坑。
我们特别整理了支付宝小程序、百度小程序、字节跳动小程序、快应用的开发经验，希望为你带来启发。
一  支付宝小程序
支付宝内的淘票票用户主要是以购票为主，工具属性比较明显。淘票票入口众多，均引导跳转到小程序，引导用户在小程序内进行购票、娱乐消费、收藏、添加到首页/桌面、分享等行为。淘票票支付宝小程序，经历了近一年的起步开发，以及一年多的版本迭代，业务开发涵盖了购票、视频、资讯、社区等多个场景。 
1  小程序开发
1） 在核心业务中慎用 web-view
实际项目线上运行情况及用户反馈表明：web-view 初始化较慢、易受网络干扰、性能差（对比离线包及普通 H5 页面）、问题较多，建议不要在核心业务中使用 web-view 进行承载。
2） 自有城市体系与支付宝城市组件的适配技巧
由于支付宝的城市组件是基于自身城市体系的，淘票票拥有独立的城市体系，所以需要城市选择组件适配不同城市体系的场景。经过几轮推动迭代，淘票票线上已使用城市选择组件，已支持复写当前定位城市、历史访问城市、热门城市、城市列表信息等。使用my.chooseCity、my.onLocatedComplete、my.setLocatedCity 三个 JSAPI 可实现对应效果。
3） 如何实现沉浸式效果（透明导航栏）？
首先在 page.json 配置 “transparentTitle” 为 “auto” 属性，开启沉浸式布局。其次，页面布局适配沉浸式顶部透明导航栏即可，通过 my.getSystemInfo 获取 titleBarHeight 及 statusBarHeight 可计算出顶部透明高度。
注意：Android 5.0 以下由于不支持沉浸式状态栏，所以页面会从状态栏下开始布局。
4） 小程序 tabBar 换肤、红点
主要使用的JSAPI及event：my.setTabBarStyle、my.setTabBarItem、page.onTabItemTap，参数参考官方文档即可。注意事项如下：
小程序触发 relaunch 时，tabBar 的样式会被清除，需要再次设置，目前建议在 app.onShow 里多次触发设置逻辑。尽量使用本地图片，在线图片有个下载的过程，体验不太好，且弱网下图片载入可能失败。
my.setTabBarItem 的参数每一项均需要赋值，否则 Android 可能会报 “invalid parameter”。
2  小程序开发注意事项
不要使用 tnpm 安装依赖，tnpm 软连接目前支持有问题。
devDependencies 和 dependencies 需要分开，将 devDependencies 移到项目代码外层，否则会额外增加包大小。
设置 transparent/pullRefresh 等 window 配置时，跳转别的页面会被继承，需要在 app.json 初始化此类配置信息规避。
web-view 里面的页面会失去下拉刷新、resume 等特性。
Android 低版本不支持 sticky 属性。
某个值控制 dom 是否渲染，下次更新时此值若为 undefined 时不会销毁掉会被忽略掉。
window.atob、window.btoa 需要第三方库来替代。
lodash 某些方法不能直接使用，因为小程序构建时无 global 对象。
3  小程序监控
使用阿里云的 ARMS 平台，参考官方文档接入即可。
优点：有实时大盘，排查用户日志方便，上报更自由、丰富。
缺点：有接入成本、需要开发，增加包大小，且要收费。
4  小程序权限
小程序有权限管控，无论是申请 JSAPI 权限还是 H5 域名配置，都是需要打新的包上传才能生效。
二  百度小程序
1  背景
以微信小程序为蓝本的百度小程序，也同样具备相似的商业定位。依赖百度这样的老牌搜索门户，百度小程序更加偏向目的性强的搜索热词进行小程序的关联调起和互动，这也是百度小程序和其他小程序的区别。
由此，我们在 2018 年底进行了百度小程序的开发工作，由于在前期积累了小程序开发经验，百度小程序的开发更加的平稳和快速，不到一个月就上线运营了。
2  应用场景
百度小程序入口：
三种入口：百度App搜索关联、百度贴吧关联、其他百度生态搜索关联。
3  开发实战
下面是淘票票百度小程序开发过程中遇到的坑和总结：
1）基础开发
百度小程序的开发与微信、头条小程序的开发方式和框架概念非常相似，都属于前端开发的一块子集，主要可以分为 4 块来构建百度小程序的页面：
第一块：HTML。构建页面框架：使用 xxx.swan 文件进行页面元素框架的搭建，具有独特的 HTML 标签如 view，scroll-view 等。
第二块：CSS。管理页面样式：使用 xxx.css 文件进行页面样式的管理，基本的 CSS 的样式都大部分支持。
第三块：JS。编写页面逻辑：使用 xxx.js 文件进行页面逻辑的书写，小程序具有其独特的生命周期管理方法。
第四块：JSON。组件注册：百度小程序支持通过组件的方式进行页面的搭建，通过在 xxx.json 中注册组件供页面使用。
2）template 模板使用
与其他的小程序相同，百度小程序也提供了模板 template 的能力，使用模板可以提高工程化和代码可维护性，开发者可以在模板中设计代码片段，向外暴露接口注入外界变量之后，可以在合适的时机去使用该代码片段。
但是在百度小程序使用 template 使用时，需要注意传递数据时需要使用 {{{ }}} 三层花括号包裹对象，否则数据注入时会出现异常。
百度小程序的 template 的使用：
<template is="xxx" data="{{{item}}}"/>
作为对比，头条、微信小程序 template 需要两层花括号：
<template is="xxx" data="{{item}}"/>
3）组件属性的 observer 使用
在使用组件（Component）是大概率会使用到属性的 observer 方法，当属性被改变时会执行属性对应的 observer 方法，此处需要注意在使用 observer 方法时，避免使用下划线开头的方法名，可能会造成 observer 方法的循环调用问题。
或者当发现 properties 中的 observer 方法被循环调用时，检查一下 observer 绑定的方法是否有下划线。方法命名移除下划线，大概率可以解决循环调用问题。
会出现 observer 循环调用的情况：
isShowLoadMore: {          
  type: Boolean,          
  value: false,          
  observer: '_isshowChange'      
},
推荐的写法：
isShowLoadMore: {          
  type: Boolean,          
  value: false,          
  observer: 'isshowChange'      
},
4）scroll-view 的使用
在使用 scroll-view 的开发过程中，对存在多个可滑动区域的页面且其中一个滑动区域为 fixed 样式时，iOS 机型会偶现 scroll-view 空白的问题。
可能存在异常的页面布局如下:
<view class='头部组件' style='position:fixed'/>
<scroll-view class='可滑动区域1' style='position:fixed' />
<view class='可滑动区域2' />
其中 “可滑动区域 2” 为依赖内容撑开的页面 View，当内容到达一定长度时，页面 View 会提供滑动能力。如果使用上述写法可能会出现 scroll-view 空白的问题。
推荐的写法：
<view class='头部组件' style='position:fixed'/>
<scroll-view class='可滑动区域1' style='position:fixed;height:44px' />
<scroll-view class='可滑动区域2' style='height:80vh' />
5）小程序 DSL 页与 WebView 页的登录流程
小程序的页面实现方式可以分为两种：一种为小程序原生的页面；另外一种是使用 WebView 组件，将 H5 页面展示在小程序中。处理两种页面的登录时一般是先进行 DSL 页登录（小程序原生页面），完成 DSL 页登录后，再进行 H5 容器页的登录。
a) DSL 页登录
先进行小程序的登录授权，获取到小程序的登录凭证，拿着登录凭证去自己的业务服务端获取真实的小程序登录信息，当开发者完成上述流程之后，将登录态信息加密后存储在本地。下次进行需要登录校验的页面时，进行本地登录信息的登录校验，则 DSL 页的登录流程就完成了。
b) WebView 容器页登录
由于百度小程序无法操作到 WebView 容器的 cookie 信息，所以在 WebView 容器页进行登录时，势必要进行一次从服务端获取登录 cookie 的过程。目前可以在进入需要登录校验登录的 WebView 容器页之前，先发起获取 cookie 的服务端请求，服务端处理好用户登录信息校验之后就可以提供一个同步 cookie 的专用页面。当接口返回链接之后，小程序的 WebView 容器需要做的就是访问这条链接将服务端返回的 cookie 同步到 WebView 容器中，这样 WebView 容器就具备了可供校验的登录信息。
完成上述页面的登录操作之后，小程序登录流程就结束了。
4  百度小程序总结
本文着重描述的是开发过程中大概率会遇到的问题和解决方案，最好结合官方文档一起查看。
三  字节跳动小程序
1 背景
字节跳动小程序是基于字节跳动全产品矩阵开发， 与图文、视频等场景有着天然的搭配性，带动小程序分发，由内容为小程序带量以及裂变。作为一个大流量且高度活跃的平台，具有很大用户增量挖掘空间。
对于头条系应用，同一小程序可以同步上线多个宿主端，目前已开放今日头条、抖音、头条极速版。无论是抖音，还是今日头条，都属于内容分发平台，相比公众号读者，抖音用户相对更年轻，而头条则拥有大量三四线城市读者，这正好契合了电影作为内容消费的特质，帮助淘票票更好的拉动下沉用户。基于头条、抖音平台自身的优势，我们在 2019 年上线了淘票票字节跳动小程序。
2  应用场景
今日头条的六个主要场景：
信息流推荐
搜索直达 
头条号挂载小程序 
分享
中心化入口
留存入
今日头条
抖音的四个主要场景：
小视频挂载 
企业号主页 
搜索展示 
留存入口
广告投放
3  基础介绍
字节跳动小程序基本开发思路类似于前端开发，并增强调用大量端能力，性能体验优于普通 Web 。上层架构基于 JS 开发，可以辅助开发者进行良好得开发。框架结构和开放式类似于支付宝小程序、微信小程序和百度小程序。
目录结构：主要分为以下几类的文件：
.json 为后缀的 JSON 配置文件，这个文件配置了小程序所有页面的路径和界面展现样式等。
.ttml 结尾的模板文件，用来描述当前这个页面的文件结构，类似于网页中的 HTML 文件。
.ttss 结尾的样式文件，描述页面样式，类似于网页中的 CSS 文件。
.js 结尾的 JS 文件，处理这个页面和用户的交互。
目录结构
四  快应用卡片
1  概述
当前，基于超级 APP 推出的各种小程序，对手机厂商的分发能力及话语权有明显削弱趋势。因此国内各手机厂商在推出快应用后，也逐渐对外开放手机负一屏的能力，为快应用及其他服务提供直接的入口。
2  卡片类型
快应用的卡片类型可以分为：应用类型的卡片、服务类型的卡片和其它类型的卡片。
应用类型的卡片：是用户订阅的一种卡片，内容相对固定。
服务类型的卡片：针对用户关心数据的状态，内容实时变更。
其它类型的卡片：自定义卡片，根据实现对应内容展示及跳转。
3  应用卡片的具体接入
卡片的开发基于快应用，所使用的 API 是快应用的子集，部分 API 不能在卡片中使用。目前已知的 vivo，OPPO，NUBIA 都需要卡片的开发不依赖主 rpk，也就是需要保证卡片能脱离主 rpk 独立渲染，为保证卡片的独立渲染，不能使用 this.$app 相关对象及文件 app.ux 中声明的工具类或生成的对象。
1）卡片的初始化配置
a) 配置文件
所有的卡片都需要和快应用中声明页面一样在 manifest.json 中声明。具体是在 router.widgets 中配置，各厂商之间有部分差异，但差异不大。
b) 卡片配置文件注意事项
widgets 中配置的 key 值请使用路径名字，如果路径为两级（例：/A/B），则 key 值配置为 "A/B"，且该值最终对应到厂商后台上传卡片时填入的卡片路径，基于此厂商才能正确解析到上传到联盟上统一的快应用包中对应的卡片。
卡片的属性 features 中需要声明该卡片会用到的系统 API，这些 API 在外层应用的  features 中已经声明过，此处需要再次声明，否则不能使用。
2）应用类型卡片接入（以 vivo 为例）
负一屏卡片线上效果图
a) 卡片的声明
在 manifest.json 中的除了上面提到的配置之外，对于卡片需要注意卡片属性中的以下字段：
params 字段用来配置卡片更为详细的参数，及特有的支持参数，需要按照文档进行配置。
targetManufactorys 为对应厂商适配标明该卡片匹配的厂商，具体参看文档。
b) 卡片的开发的不同点（所使用的 API 及组件为其子集具体参看官方文档）
vivo 卡片是单独工程，不能配置在快应用工程中，需要另外建立新的工程。对应包打出也需要单独配置和主快应用不相同，需要用到 vivo 给出的相关工具。
卡片有单独设置主题的功能。
卡片有折叠功能。
卡片视觉稿由内容提供方给出。
卡片开发只需开发内容区域，title 区域无需开发（由 vivo 负一屏容器完成绘制）同时意味着下半部分的圆角需要自己绘制
上传卡片包时需要提供对应的 icon。
c) 卡片调试
卡片调试需要使用 vivo 方提供的工具打出来的 rpk 文件，同时需要使用 vivo 方提供的专用内核及容器，具体按照文档执行即可。
d) 卡片提交
先需要完成自测，自测之后需要使用 vivo 提供的专用打包工具，打包之后到 Jovi 后台地址提交，同时需要提供一个应用图标。
4  负一屏服务类型卡接入
以下以 OPPO 服务卡接入为例：
触发场景：用户在淘票票快应用中购票之后，在影片上映前的固定时间内触发该卡片内容展示，进而提醒用户取票，即消息触发场景。
OPPO 负一屏卡片线上效果图
1）OPPO服务卡卡片的声明
在 manifest.json 中的 router 字段中添加 widgets 字段，并在该字段中添加对应的配置，与 OPPO 应用卡片完全相同。
2) 卡片开发
OPPO 服务卡开发涉及用户关心数据状态改变触发卡片的场景，因此整体需要解决以下几个问题：首先是触发时机问题，然后是要确认触发的卡片 ID，还要解决要触发哪一个 OPPO 用户。
3）OPPO 服务卡整体开发流程
前提：要开通 OPPO 账号服务，保证在快应用中能够拿到 OPPO 当前登录的用户的授权码。
a) 账号绑定，即 OPPO 账号和快应用账号的绑定
账号绑定的入口：该入口由 OPPO 负一屏容器统一提供，位置如下图左：
OPPO 服务卡绑定入口及自定义绑定页面
该入口对应一个快应用内的绑定页面。
b) 绑定页面开发，该页面是快应用页面，主要提供绑定功能
作用是让内容商服务端知道自己的账号和 OPPO 测的对应关系，及换取发消息到 OPPO 端时所需要的 TOKEN 值。
c) 触发对应 OPPO 用户负一屏的卡片
内容服务商在用户关心数据变更时，触发推送消息到 OPPO 服务端，该消息按 OPPO 文档约定，带上对应的 TOKEN 值，要触发的卡片 ID，消息内容，要触发的时机及时长，OPPO 服务端会根据该 TOKEN 找到对应的用户下发消息，并在需要的时机拉起对应 ID 的卡片。
d) 卡片消失
由发送消息中定义的卡片时长决定，展示时间到点后，负一屏容器会自动移除该卡片。
e) 调试
首先，需要 OPPO 服务端参与
其次，需要 OPPO 提供负一屏开发环境版本，以保证 OPPO 服务端日常环境的数据能够到达。
再次，需要提供初步测试完成包含服务卡的 rpk 到 OPPO 侧，把该 rpk 配置到 OPPO 对应的环境。
f) 提交市场
测试完成可以在 OPPO 后台提交该卡片，同时同步正式生成的卡片标示到自己的服务端用来推送消息使用。
g) 综上涉及各端的开发工作如下：
首先，涉及服务端账号绑定开发，TOKEN 刷新维护，触发的消息推送到 OPPO。
其次，涉及前端的服务卡片开发以及绑定页面开发。
涉及其他：OPPO 账号服务开通。
5  踩坑记录
负一屏的 UA 和快应用中不同如果有与 UA 相关的配置需要注意。
对于调试时更新了 rpk 之后，实际打开对应更改没有体现时，可以尝试清除对应卡片容器的 cache，同时保证该容器有相应的读取存储的权限。
对于同一个业务，由于各厂商适配不同及平台不同，需要多处代码编写，但基本业务逻辑基本一致，唯一不同是 UI 展示，所以在一开始还是需要抽离数据逻辑，不同厂商给不一样的 UI 展示即可。
四  淘票票小程序构建演进
我们做了很多的小程序，对多端同构也做了一些尝试。
1  从一端到多端
1) 起步：小程序原生开发
2018 年，随着小程序平台爆发，我们首次踏出了淘宝域内，进行了头条小程序的尝试。这次尝试，使用的是原生的小程序 DSL 语法编写。为了方便复用已有的 H5 样式，加入了 Gulp，用来编译 Less。
这种开发方式轻快，但是同时也暴露出了很多问题：
包体积很难控制。
原生 DSL 没有任何复用性，并且需要重新学习。
无法使用 NPM，一些很常用的社区包，团队基础工具链无法使用。
机型兼容性不好，没有 babel 支持。
2) 摸索：两个端，一套代码？
在开发百度小程序的过程中，吸取了第一次的教训，加入了 webpack 来做一层编译，一是解决了包引入问题，二是加入了 babel 插件，解决 JS 兼容性问题，开启 CommonChunk 插件，解决包大小问题。
总体上，从输出一端变为输出两端，所以出现一些差异。对这些差异，编写了一个插件，对业务层抹平。比如微信端引入 index.wx.js，头条端引入 index.tt.js。
脱离了刀耕火种，开发效率明显提升，但是还不够好，视图层还是两份，而且以后每新增一端就要新拉出来一份。
3) 优化：走向社区，跨多端
在开发头条和百度小程序时，业内也已经有了在小程序 DSL 上封装的框架，但是当时看都不是很成熟，基本都是专注于一个平台，没有什么跨端能力，就没有用到生产环境，而是持续关注更新近况。
2019 年进军微信小程序，再次看市面上的框架，发展的很快，同时也注意到跨端开发这个需求点，选择了 Taro 作为主力框架。这种框架横评就不展开了，市面上很多，简单说几个选择 Taro 的原因：社区相对活跃、支持渐进式切换、TS、react like。
a) 平滑迁移
Taro 支持渐进式切换，也就是 Taro 和 DSL 混写的能力，所以迁移成本可以接受。我们先将首页 Taro 化，后面慢慢迭代将所有的页面都切换为了 Taro，这里值得一提的是，Taro 的跨端差异化处理和我们之前的处理思路一样，因此 Util 迁移起来几乎 0 成本，成本主要集中在视图层。
b)好处是什么，缺点在哪里
使用 Taro 的好处是解决了我们之前遇到的主要问题，是一个一揽子解决方案。
同时这种上层框架在扩展新端时成本低，机动性很高，框架提供了新平台包，适配成本低。
当然也遇到了一些新的问题，比较严重的是调试，因为代码被转译过一次，同时不支持 Soucemap，导致 debug 时体验很差。
2  多端差异
多端必然会有一些差异，业务的差别、端上 API 的差异等，比如微信上的分享能力，抖音上的抖音拍摄器，百度的 feed 流等。最终落在业务上，差别可以分为三部分，输出不同的页面、不使用同的组件(有的端使用原生组件)，细到不同的逻辑。
1) 输出不同的页面
在使用 Taro 时发现不支持，想到可以使用 babel-preval 来编译时输出页面配置，这样包体积也不会受影响，最后我们也反哺回社区。
使用不同的组件，不同的逻辑。根据端上不同的组件我们使用的最多的是多态模式，底层组件对外暴露相同的接口，端上调用时不需要考虑端上的差异，在 import 层会根据不同的端来引入不同的具体组件。
2) 端上逻辑
如果是一些简单的逻辑差异，可以直接使用环境变量来做控制，走不同的逻辑。这种方式针对小一些的逻辑还可以，不过这种代码一多，就不容易维护。
3) 针对维护性的建议
这里推荐几种维护性比较强的差异处理方式：
设计组件时插件化：比如路由，不同端在跳转前后需要有一些不同的操作，实现了插件化后，每一个端只需挂载不同的插件即可。
配置抽离：针对一些端上不同的配置，比如一些文案、固定内容等，可以抽离到一个统一的地方维护，可以少很多 ifelse 逻辑。
用好函数 hook：针对不同端相同的逻辑放在函数中，有差异的逻辑可以单拆函数作为 beforeHook 和 afterHook。
3  项目维护策略
项目输出多端后，每次改动回归就成为一个比较重要的问题，如何保证自己的代码不会再其它端上出问题？每次改一个小程序其他都要立即回归吗？如何快速整理其他端的改动？下面针对多端项目的维护总结了一些经验。
1) 单测
针对核心逻辑编写测试，unit test 和 snapshot test，我们内部维护了一个针对端上 API 的 mock 测试库，整个测试可以在 node 环境中运行，保证运行效率。
2) Commit 规范
指定一个 commit message 规范，可一眼看出你在做什么，在改哪一个端，以及后面回归策略时用到。
3) git-hook
使用 githook 能保证上面的规范能够真正的遵循，保证每次提交的质量。pre-commit 时跑一下 Eslint，然后校验一下 commit-message 是否符合规则，最后 push 时会跑一次整体的测试。
4) 多端的回归策略
没有做 E2E 的主要原因是小程序限制，case 编写难度比较大，并且维护性低，无法自动化。
目前我们是人工回归的，如何保证代码不会再其他端上出问题？难道每一次改一个小程序其它都要立即回归吗？回答下这两个问题，编写代码时考虑影响面，提交时提供足够的改动信息，合并时主要测当前端即可，不需要回归所有端。等另一个端需要发布时，拉出版本的 commit-message，然后梳理出变更范围，在该端做回归即可。这样做减少对测试的集中消耗，保障质量。
4  展望
以上是我们对跨端项目的经验总结，包含技术演进历史以及差异控制策略。跨端项目的难点就是处理差异。
端上能力的参差不齐、业务针对不同场景的定制，一旦控制不好，整个人项目的维护性就会大大降低。
业务方面要思考清楚，不同的端，是相似的更多，还是差异多。
框架方面，最近看到有开发者已经给 W3C 提小程序的白皮书了，总体朝着良性方向发展，这是一个好的开始，期待能够标准化小程序框架。

微信小程序这个词可以分解为微信小程序两部分。其中微信可以理解为微信开发，指的是小程序的执行环境；当然微信在提供执行环境的同时也延长了用户使用微信的时间。小程序是说它首先是程序，然后具备轻便的特征。小程序并不像其他应用那样需要安装，而是通过扫描二维码打开后直接执行；用完以后也不需要卸载。这就是所谓用完即走的原则。另外，微信不会提供类似于小程序商店的地方，需要小程序提供者自己通过二维码，群分享的手段来传播，这就是所谓去中心化的形态。微信朋友圈提供了好友之间沟通信息的手段，订阅号提供了面向粉丝推送信息的手段，而小程序则是提供了用户通过自己的操作而与服务实现互动的手段。
快速发展的轻应用
除了在微信中运行的微信小程序之外，还存在众多的「小程序表亲」。例如，有多家手机硬件厂商支持的快应用，就是一个典型的例子。到目前为止，我们知道的的主流厂商几乎都参加了快应用联盟。
快应用的架构，采用的技术 （XML/JSON/JavaScript）和微信小程序几乎完全相同。可以毫不夸张地说，掌握了小程序开发技术，就等于打通了手机应用开发蓝海的出海口！
零基础入门微信小程序开发
本专栏的目标是从零开始带领读者上手实战。专栏中，我们不仅会讲到小程序从开发账号注册到发布的全流程，还会对相关技术也进行相应的介绍。通过这种方式，我希望读者们能够专注于小程序的开发，而不是因为到处寻找资料而导致忘了学习微信小程序的本来目的。换一种说法就是：并不需要另外自己调查，跟着本专栏走下去就好。
零基础学习，初学者轻松入门就算你完全没有开发过微信小程序，甚至没有接触过小程序的相关技术（XML、JSON、JavaScript 等）也可以轻松入门！涵盖开发全周期，助你尽快完成自己的小程序：
麻雀虽小，五脏俱全。专栏通过 9 篇文章覆盖从开发账号注册、开发工具安装、小程序开发，到发布的全过程。
基于最新环境，让你不走弯路
小程序作为新兴技术，无论是开发文档，还是开发工具都在飞速变化。专栏中的所有说明和工具都基于 2020 年 1 月的最新状态，保证读者不会因为环境等细枝末节的问题而走弯路。
入门和提高相结合，为深入开发作准备作为入门系列文章，在讲述基本知识的同时，还为读者提供了进一步开发时所需的信息源和开发示例，以方便读者进一步深入开发自己小程序。
专栏结构
本专栏的目标是从零开始带领读者上手实战。专栏以微信小程序的核心概念作为主线，介绍配置文件、页面样式文件、JavaScript 的基本知识并以指南针为例对基本知识进行扩展。另外加上开发工具的安装、小程序发布等内容，共 9 篇文章，包含四个部分。
第一部分（1-3）带你初步了解小程序是什么，然后进行小程序开发的准备工作，从注册账号到安装开发工具一应俱全。工欲善其事，必先利其器。
第二部分（4-6）。面向入门级读者介绍小程序构成的各个部分。你不需要事前准备任何知识，我们会对需要掌握的部分进行说明，并为需要扩展的部分提供信息的出处。千里之行，始于足下。
第三部分（7-8）通过指南针的例子，介绍一个小程序的实现过程。通过这个实例，综合运用所学知识，使你的小程序开发能力进一步提高。麻雀虽小，五脏俱全。
第四部分（9）只包含一篇文章，具体介绍小程序发布的过程。使读者能够对小程序开发的全过程有一个完整的了解。编筐编篓，全在收口。哪怕你事先没有任何微信小程序相关技术的经验，认真学完专栏之后，也可以掌握基本的小程序开发方法，并具备自主扩展知识面，以及进行更高层次开发的能力。
你的收获
理解小程序的基本架构和开发手法
理解并运用小程序开发中的 Javascript/WXML/WXSS/JSON 技术
掌握小程序从着手到发布的基本流程
获得深入开发小程序必需的技术资料和开发实例的信息源
微信小程序虽然是新事物，但学习方法却不是新的。
我们的方法是，首先完成一个最简单的小程序实例，通过这个实例介绍微信小程序的构造和想法，这是所谓的「学」。然后扩展这些知识点，通过开发一个简单的小程序来运用这些知识点，这是「习」的过程。

售后管理系统，又称为客服管理系统或者客服系统。在进入中国市场之后，受到越来越多的企业的青睐。但是，还有很多企业还不知道售后管理系统是什么。售后管理系统是一种可以有效地服务客户，提高客户售后服务满意度，留住更多客户的解决方案。
1.邮件服务工单
现在，很多售后管理系统是通过邮件来转换成服务工单的。例如，可以帮助您将客户发来的邮件转换为服务工单，然后统一进行汇编和整理，并监控邮件的收发数量。
2.多语言售后管理系统
在全球化的今天，国际贸易越来越多，那么肯定会涉及到跨国售后服务。这时，就需要多语言售后管理系统来服务客户了。 可以设置多种语言，选择适合客户的语言为客户提供支持服务，才能更好地解决客户问题。
3.工作流自动化
如果客服人员需要一直执行重复性手动操作，就太浪费时间和精力了。现在的售后管理系统通过自动执行重复性的操作，帮助售后服务人员节省时间，提高效率。
4.售后服务工单分配
轮流分配是一种非常简单的服务工单自动分配方式。在售后管理系统中，您可以按照业务设置，将服务工单平均分配到所有客服人员，也可以根据业务需要分配给相应的客服人员。
5.报表和分析
服务工单的解决情况如何？客户的满意度如何？售后服务人员表现如何呢？您可以通过的详细报表来分析客服团队的业绩表现，统计客户的满意度。企业成功离不开满意的售后服务，选择一款好用的售后管理系统，为您的企业发展保驾护航。

经过多年的行业发展，我国家电市场进入成熟期，随着家电产品的饱和，为用户提供更高价值的增值服务，成为家电企业提升产品竞争力、寻求生存发展的必由之路。对于家电企业来说，售后维保服务是体现品牌价值与品牌实力的重要一环，在产品同质化日益严重的今天，完善的售后维保服务，能提升家电维修质量，为家电企业创造更多盈利机会，体现出了品牌的差异化竞争优势。基于此，智能、高效的家电维修小程序应运而生。
家电企业开发家电维修小程序的重要性：
1、整合维保服务，提升用户体验：
传统的家电维修市场难以为用户提供周全有效的维修服务，并且行业容易出现乱收费、高收费的现象，消费者也需要耗费精力和时间在线下寻找靠谱的维修师傅。但现在只要通过维修小程序，用户就能获取一站式的预约维修、零件购买、家电清洁等服务，还能通过小程序获取靠谱的家电产品购买渠道，打造“维修+保养+换新”的服务闭环，提升用户体验，提高消费者的品牌忠诚度。
2、线上派单模式，服务效率更快：
通过维修小程序与售后系统的整合对接，可以生成维修工单，维修员利用手机就可以接单，便于优化人手配置，提升维修人工的利用率。小程序还能对维修人员的业绩进行考核，掌握系列产品的报修次数和原因，统计维修成本，从而可以跟进改善产品质量，持续提升产品的品质。
家电维修小程序的功能版块：
1、扫码功能：扫描产品上的条形码，即可将家电绑定到维修平台，获取家电的产品详情、安装方式、使用说明和历史维修服务记录等，既能作为产品防伪溯源的凭证，也便于后续对产品进行维保信息的提交。
2、预约报修：预约上门维修时间，快速上传需要维修的产品的图片或视频，并填写故障说明，即可一键对产品进行线上报修。用户能查看接单维修人员的服务单数及客户的评价，随时随地获取即时的售后服务。
3、清洁服务：用户可以在线上购买洗衣机、冰箱、空调、抽油烟机等家电的清洗维护服务，预约上门时间并在线支付。
4、家电商城：通过自主搜索或分类筛选，用户可以快速定位到所需的产品，实现加入购物车、客服咨询、在线支付、物流查询、售后评价等一站式操作。
5、维修师傅入驻：维修师傅可在平台上上传自己的擅长维修技能和维修资质等，通过审核后即可成为平台的线上维修员，为用户提供高效的维修服务。
现如今，因为移动互联网的全面渗透，消费者们的消费习惯和消费观念发生了巨大改变，同时也给国内的传统行业带来了巨大的冲击和影响。传统家电和传统维修行业与互联网结合，以互联网为工具，不仅能够拓宽受众范围，也能够带来更加可观的利润空间。

1、客户报修
小程序扫码售后系统利用微信作为入口，让客户像点外卖那样进行报修，企业受理和派工的相关状态会实时推送至客户微信或短信上，极大提升客户体验，让传统的维修业务也变得如此高效。客户进入小程序，即可通过微信号进行报修和查询：
精准报修：客户需选择设备，序列号，故障现象等必要信息
模糊报修：客户手工输入报修信息
支持上传照片，语音，文字描述
支持同时报修多个设备，可以实时看到以下信息：报修被受理时间、派工时间、工程师姓名及手机号、预计到场时间等
客户在小程序扫码售后系统里，可以实现以下操作：对服务完成进行确认、对服务进行评价打分、对服务报告进行电子签名。
2、派工管理
所有工单和工程师日历在同一个界面上，通过鼠标将工单拖拽到工程师日历上，即完成了派工动作，工程师在小程序中实时收到新工单提醒。工单的紧急程度和工程师的空闲时间，以及工程师所处地图位置一目了然。在派工之前，您需要确认准确的故障现象，同时查看历史维修记录。
工程师地图显示了工程师目前所处位置，工程师日历显示了工程师目前的工单情况和空闲时间，工程师技能表明可以维修的项目
系统帮助您检查检测工具、维修工具、抢修车辆等资源的可用性，以保证资源到位，提高首次完修率
如果客服超过特定的时间期限仍未处理客户的请求，系统将发送警报至上级管理人员
支持通过小程序、微信公众号进行派工
3、工程师签到
根据客户要求的上门时间，当工程师到达客户处500米时，后台作系统自动签到。如果通过现场拍照进行签到，系统会在上传的照片上加时间水印。签到信息同步给客户、客服以及销售人员。
系统管理工程师的按时到场率，这些数据将作为工程师考核的指标之一
4、客户评价
在服务结束时，客户可以在小程序扫码售后系统上作评价，这个评分将直接反馈到系统后台，以保证评价的真实性。系统也支持客服电话回访。
5、报告与分析
小程序扫码售后系统提供设备故障、工单执行、维修成本等分析报告，这些报告可以根据您的要求进行定制。同时提供实时大屏幕看板，全国的维修服务数据实时更新，看板上显示哪些KPI数据亦由您定。

首先我们来了解一下什么是软件开发公司，顾名思义，软件开发公司就是根据客户所提出的需求，对软件进行独立自主开发或二次开发，并以软件开发为主营业务的公司。软件开发公司的业务流程大致为：需求—设计—研发—交付—维护。

 

目前，很多用户对软件定制开发没有太多的概念，而成功的软件开发一切都是以用户需求为基础的，对于中小企业来说，须根据自己的实际业务需求，开发一套合适的企业管理软件，为公司的发展添加催化剂。

 

根据我们以往接触过的客户了解到，通常有以下几点担心：

1、数据迁移

有些公司已经使用了一套软件系统，但有建设新系统的打算，所以对数据迁移的问题十分关心；时常会听到用户提出"我们并不过于关系统的好坏，但需务必保证数据准确"。（当然软件质量的好坏必须也是很重要的）。的确，在以数据为运营基础的行业里，数据本身就是企业竞争力体现的重要部分。

 

定制的软件，从设计的阶段就会充分考虑对已有数据的迁移，其"迁移"成本和风险是最低的；

 

2、软件稳定性

在软件开发过程中，负责任的软件公司都会有软件测试这个环节，会有测试工程师对软件的各项指标进行功能及压力测试。并且定制开发，不全是从零开始，有经验的软件开发公司是在已有大量项目的经验积累上进行的，或是在现有稳定的开发平台上进行开发。

3、标准化

每一类行业软件经过长时间的沉淀，都已经存在了客观上的一个标准，这个标准在开发产品的时候软件开发设计人员需要充分考虑。

 

4、后续服务

一般软件开发商把最核心功能做成产品化，有完善的用户手册支持，而且能够具备一系列的编码、文档、技术规范，接手维护也不会存在难度。

 

因此，有了上面的几点之后，企业到底如何选择软件定制开发呢?

 

在现有软件基础上的二次开发：分为局部定制开发和大量的定制开发，局部开发一般是在现有软件产品的基础上进行少量的修改，开发的工作量少，风险低。大量的定制开发对软件产品的平台和架构要求比较高，而且开发的周期长，需要处理好在定制开发中对产品的修改，影响后续系统升级的问题。

 

基于软件开发平台的定制开发：软件开发平台为应用开发提供了权限认证，安全管理，资源管理，事务，数据管理，二次开发接口，系统集成等基础功能和服务。基于软件开发平台构建的应用系统 拥有良好的集成性，扩展性，拥有更好的性能和安全，整个应用系统具有更强的生命力。能够满足后续应用扩展和变化的需要。在定制开发过程中可以简化系统的设计，降低技术难度，通过定制代替开发缩短项目周期、大大降低系统的错误率，让系统的维护更加容易，提高用户整体的满意度。

 

完全的定制开发：没有依托软件产品和软件平台进行的开发，这种开发一般风险大、周期长，成本也比较高，对项目技术人员的依赖程度大，如果需求复杂则容易导致项目的失败，因此需要在前期需求调研和软件设计过程中和软件公司进行充分沟通，不至于在编码过程中再去进行大的调整。

 

因此评定一个软件公司是否有能力去完成你的软件项目，以上这些因素是必不可少的，也是衡量软件公司是否专业的一个标准。要选择那些专注于软件定制和软件开发的软件公司，专业公司会凭借实践经验和软件技术研发平台为客户打造一款优秀的管理软件。