【聚禄鼎】一站式企业服务平台4）小程序tabBar换肤、红点
主要使用的JSAPI及event:my.setTabBarStyle、my.setTabBarItem、page.onTabItemTap，参数查阅官方文档就可以。小程序运行完毕后，可以直接将其保存到后台数据库中。注意事项有以下几点:
- 小程序触发relaunch时，tabBar风格将清空，需重新设定，当前推荐使用app.onShow中的设置逻辑被反复触发。如果没有配置的话，可以先用浏览器来启动应用后再进行修改
- 尽量使用局部图片，在线图片是有一个下载过程，体验并不是很好，而且较弱的网下图片载入也会有失败的风险。小程序更新后如果不及时删除，则需要重新进行配置
- my.setTabBarItem的参数每一项均需要赋值，否则Android可能会报invalidparameter”。如果要添加一个新功能，则需要重新定义配置界面，这样才能正常运行
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年年底我们开展了百度小程序开发，由于在前期积累了小程序开发经验，百度小程序开发更流畅、更快捷，在不到1个月的时间内正式投入运行。同时我们还对其应用场景进行分析与总结
2应用场景
百度小程序入口:
三种入口:百度App搜索关联、百度贴吧相关、还有一些百度生态搜索相关的。通过这三种不同的方法进行了小程序开发并测试后发现它们在界面上具有良好的兼容性，并且能够实现快速切换到新的网页，从而使用户体验得到提升
3开发实战
以下是淘票票百度小程序开发过程中遇到的坑和总结:
1）基础开发
百度小程序开发及微信、头条小程序开发方法与框架概念极为类似，均属前端开发一片子集，主要可分成四块构造百度小程序页面:
- 第一块:HTML。它采用了一种全新的技术——基于内容的网页制作技术。搭建页面框架:用xxx.swan文件建立页面元素框架，具有独特的HTML标签如view，scroll-view等。在创建页面时只需输入一个关键字即可完成整个网页布局
- 第二块:CSS。在创建页面时只需输入一个关键字即可完成整个网页布局。对页面样式进行管理:用xxx.css文件管理页面样式，基本CSS在很大程度上支持样式
- 第三块:JS。写页面逻辑:用xxx.js文件写页面逻辑，小程序在生命周期管理方面有自己独到的方法
- 第四块:JSON。当系统出现问题时，开发人员可以直接从后台调用小程序运行过程中产生的数据信息，从而实现对小程序界面的修改或者是添加新功能。组件注册:百度小程序支持通过组件的方式进行页面的搭建，通过注册xxx.json上的组件为网页提供服务。同时还支持自定义组件、自定义控件以及插件等多种模式，并能根据不同用户需求定制开发各种功能组件
2）template模板使用
与其他的小程序相同，百度小程序同时还提供模板template功能，利用模板可增强工程化及代码的可维护性，开发者可设计模板上的代码片段，对外露出的界面注入外部变量后，这个代码片段可适时使用。如果不知道是否有必要使用该方法来开发自己的小程序的话，则可以通过调用模板进行开发
但当百度小程序使用template时，应该指出的是，在传递数据的时候，要用{}的3层花括号把物体包起来，否则，在数据注入过程中会产生异常现象。此外，"#>；是一个很好的输入控件，它能够实现用户想要输入的内容，并且能将这些信息显示出来，方便使用者进行操作
百度小程序的template的使用:
<；templateis="xxx"data="{{{item}}}"/>
作为对比，头条、微信小程序template需要两层花括号:
<；templateis="xxx"data="{{item}}"/>
3)组件属性的observer使用
在使用组件(Component)是大概率会使用到属性的observer方法，当属性被改变时会执行属性对应的observer方法，此处需要注意在使用observer方法时，避免使用下划线开头的方法名，可能会造成observer方法的循环调用问题.
或者当发现properties中的observer方法被循环调用时，检查一下observer绑定的方法是否有下划线.方法命名移除下划线，大概率可以解决循环调用问题.
会出现observer循环调用的情况:
isShowLoadMore:{type:Boolean，value:falseobserver:"_isshowChange"}，
推荐的写法:
isShowLoadMore:{type:Boolean，value:falseobserver:"isshowChange"}，
4)scroll-view的使用
在使用scroll-view的开发过程中，对存在多个可滑动区域的页面且其中一个滑动区域为fixed样式时，iOS机型会偶现scroll-view空白的问题.
可能存在异常的页面布局如下:
<；viewclass="头部组件"style="position:fixed"/>
<；scroll-viewclass="可滑动区域1"style="position:fixed"/>
<；viewclass="可滑动区域2"/>
其中"可滑动区域2"为依赖内容撑开的页面View，当内容到达一定长度时，页面View会提供滑动能力.如果使用上述写法可能会出现scroll-view空白的问题.
推荐的写法:
<；viewclass="头部组件"style="position:fixed"/>
<；scroll-viewclass="可滑动区域1"style="position:fixed；height:44px"/>
<；scroll-viewclass="可滑动区域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的后台地址投稿，还需提供应用图标。通过以上步骤可以实现将卡片从本地下载至指定地点
四负一屏服务类型卡访问
下面就拿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。通过这个插件实现了客户端到微信公众号的转化过程，并将其集成在一个页面中，使其能直接调用
从刀耕火种中分离出来，开发效率显着提高，但并不理想，视图层仍为2份，而今后每增加一头，都要新抽出一个。这里面还有很多问题需要解决，例如如何实现页面布局、图片展示等
3）优化:走向社区，跨多终端
在开发头条和百度小程序时，行业内也已具备将小程序DSL中封装起来的架构，但那时候看着还不太成熟，基本上就是集中在一个平台上，跨端能力不强，则不在生产环境使用，但不断留意最新的更新动态。后来发现，跨端化是大势所趋，所以在开发头条小程序的时候，开始尝试跨端设计，并且成功地进行了两次跨端实践
2019年，进军微电影领域，再看看市场上的框框，发展速度较快，但也关注了跨端开发这一需求点，选择以Taro为主要框架。因为它是一种轻量级框架，而且还能兼容多种应用场景，因此被广泛使用，并且得到用户认可。这样的框架横评是不会进行的，市场上有不少，浅谈几点选Taro的理由吧:社区比较活跃、支持渐进式切换，TS，reactlike等功能
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）单测
针对核心逻辑编写测试，unittest和snapshottest，我们在内部为端上API保持mock测试库，整个实验可运行于node环境下，确保运行效率。如果有需要修改的话就直接把它添加到新版本中去即可，不需要重新开发脚本
2）Commit规范
指定一个commitmessage规范，但是一眼就能看出来自己是干什么的，在改变哪个端的时候，及后文回归策略中所使用的。这样就避免了用户在使用过程中出错的可能，同时也方便以后升级或更改版本
3）git-hook
使用githook能保证上面的规范能够真正的遵循，确保每一次投稿都有品质。在每一个流程中都要对每个部分进行检查。pre-commit时跑一下Eslint，然后对commit-message进行验证，使其合乎规律，最后在push时，会跑到整体考试中。如果在每个节点都进行了重新计算的话就会有大量错误出现
4）多端回归策略
不做E2E主要是因为小程序限制，case的编制相对困难，且维护性不高，不能实现自动化。如果有了新的方法的话可以自动进行修改和维护，但是在运行过程中会出现一些错误或者出错，这就需要重新开发
我们现在人工回归，怎样确保代码不在别的端再次出现问题？如果有了新功能就必须重新开发和维护，那么为什么还要修改呢？是不是每次修改小程序别的就得马上复出？是否有办法让开发人员把每个新的小程序修改完之后自动回原来的端呢？回答下面的两问，在写代码的时候要考虑影响面的问题，在提交之时，提供了充分的修改信息，合并的时候主要测量当前端的情况就可以了，不必回到全部端。等到另外的端点要下发的时候，拉出版本的commit-message，接着对变更的范围进行了梳理，在这个末端进行回归就可以了。如果需要重新编译或开发，则将源码和配置文件下载到新端的对应位置，再重新启动并进行修改。这就降低了试验的集中消耗并确保了质量。本文还分析了跨端项目中存在的一些问题，并提出相应解决措施
4前景展望
以上是我们对跨端项目的经验总结，收录了技术演进历史和差异控制策略。随着时代的发展，企业越来越重视团队协作和跨领域融合，而这种趋势也使得跨端项目成为了未来发展趋势。在跨端项目中，困难在于应对不同。从管理层面看，跨端项目中，由于每个端点在性能和功能等诸多方面存在很大差别，因此如何实现统一管控成为一个重要问题
- 端上能力参差不齐、业务根据不同情景进行定制，一旦失控，整体人员工程维护性将大打折扣。在项目管理方面，我们应该关注如何去实现和保持跨端的一致性，这一点非常重要
- 业务方面要想清楚，不同的端，是雷同较多还是分歧较大。我们要做的事情是如何把这些差异性进行整合，并将这种差异转化为可执行代码，然后再利用这个可执行文件去开发其他功能，最终达到统一的目标
- 框架方面，近日见到一些开发者已向W3C提出小程序白皮书，整体上向良性的方向迈进，有了好的开端，期待标准化的小程序框架的出现。另外，应该把一些重要的接口做出来，让用户在使用过程中更加方便，也可以让开发者对他们开发的软件有进一步了解和认识
