微信开发中的前后端之坑

前端是快速呈现与验证产品，并且尝试把这些优秀的交互体验做出来并去实现。在前端级产品的研发过程中，工程师如何去解决他们所遇到的痛点问题，又引发了哪些思考呢？作为早期腾讯白名单成员之一，夏力维今天给大家带来一些在前端技术上面的收获和经验。

之前，我们团队发现了一个问题，这个问题是编码跟发布的过程很繁琐。所以我们为了减轻工作量，做了以下几件事

1、第一件事

CODE ON WEB。我们率先将类微信JSSDK的方式自己写了一套同样的JSSDK方式做控制。

2、第二件事

在这过程中提供了MORE APIs for实时的realtime。因为当你不停地刷开一个页面，为了进入下一个页面而去等待，这样的等待在我们看来是浪费时间和生命。所以在realtime的强调上我们认为，在WeChat Official Accounts的过程中，提供了更多的机会。

3、第三件事

DATA和Platform。目前在市面上的前端级跟原生级的产品中，有大量的公司在尝试建立平台，但这样的平台有问题。当同样一个用户进入了五六个不同厂家的产品，会发现它有五倍的用户量，这样的统计方式实际上是错的。我们认为Personal Tool未来的情况会变得更优秀。

我们在做人工智能预测的时候，预测了几个方向。

第一个是基于一般模型和Personal Tool可以做的个人级修正，我们认为它是一个可行的方向。

第二是目前市面上只能通过个人级，在smallcell的情况下，只能通过语音这个位置进入。

还有一个DEMO。比如今天大家可以通过扫描二维码，填一下手机号跟后台的check 验证捆绑，依靠DEMO SHOW得到人数的数据。

所以，你会发现，产品特别是H5，一定是通过大量的场景互动式得到未来，舍弃古老的方式，用这种巧妙的方式变在整个产品策略中，不停地问一些其他问题做场景预设。在前端都是通过字符串的拼接去完成。当你问出这些问题的时候，其实全靠前端的字符串识别和分割去实现。

很多工程师做到后面的痛点就在于，安卓的浏览器千变万化，腾讯的TBS在微信内表现优秀，提供了大量的元升级的条件。其实我们可以在自己的产品内也同样做这套东西，在产品内部让原生团队来兼容自己，有需要的时候重新渲染。这样的方式交互感会变得更棒。

我们是干嘛的？

我们在产品的体验上认为，应该进入一个沟通的场景。当有需要的时候，可以快速进行一场演讲和答复的获得，把一些所有的历史性的东西完成，并且在这里面实现语音级或者是VR级的产品，这就是我们在DEMO级产品上的思考。

无论你用什么办法在渲染一张全景及图片的时候，第一是速度，第二是拼接方式。那么问题来了，它耗不耗内存，APP会不会崩溃，图要多大。当你真正遇到这些问题的时候会发现，iPhone用户会出现大量的闪退，安卓用户勉强会进入绝对的卡顿状态。

当你把一个DOM层消掉的时候，会发现其实从内存级的角度上来说它并没有被消除，所以要通过多次设置让这个数据离开。很多人没意识到DOM级别的内存管理这件事，甚至会出现多列表的状态。我们建议一个list view只存一百个，当进入下一个list view的时候截取出来。这一招在web view的角度上同样适用。你可以通过JSG内存的角度或是本地存储的方式把你要的数据存下来，这样的话不会出现超大规模渲染时的尴尬。

这里有另外一个DEMO，这是来自于西溪路绿城的一个项目。它的元素特别多，他能够精细化到把这样的场景和幕布都做到，甚至可以用第一视角在里面进行场景级的切换跟浏览。可是它很卡，细究的时候就进入了内存的考量。

前端级的交互产品往上冲量级的时候，当进入对于位算法和优化的内存级考虑，产品会变得越来越有优秀品质体验感。

我们在图片非绝对渲染的时候，采用的是缩略图的策略去省流量。当遇到video级视频的时候，采用了腾讯X5浏览器，这个里面没有出现SRC，当点击屏幕的时候才出现SRC再加载，这样就省流量了。这样就可以节省CDN高昂的费用。有些时候越省钱，就会发现前端技术在思考问题的时候特别有空间感，这件事情就变得很简单。

微信生态提供的便利性

从代码级的角度上，我来给大家看下微信生态提供了什么样的便利性。

单实例化通道

因为微信的小程序只能保留一个实时化通道，最早期的时候原生级只提供五个链接。大家在用微信小程序做post的时候，都是通过桥接级完成的，所以它的内存上只留了这么一个有限的量。虽然最近放开了，但是要巧妙地使用这样的产品，让原生和H5级产品很好的沟通和交流。而它的思想不是留在微信现有的生态内，它希望所有原生产品在H5的角度上打开一个web view的时候都能用TBS。这样它可以实现跨APP、跨产品及跨一切产品级的内容和沟通。

协议规则数组化

微信这方面的SDK从来没有放出来过，但是message很早就做了。所以协议化的规则数组的格式可以提前预设，千万不要写死。这个位置你得留下，不要仅思考当前业务，而思考的是远景级场景。如果前端工程师有个新的想法，在那个位置可以写一下，看一下效果如何，前端级呈现完成。

所以在这个过程中，websocket和长链接级别的出现，哪怕用socket.io，我们觉得都能在产品策略上获得更多提升。组件化并且尝试在业务中增加即时性的可能性以及检验效果是否正确非常重要。

区块链

当前所有级别产品在做的过程中都考虑了仅当前业务状态，可是区块链横空出世，和我们有什么关系呢？

区块链级的产品如果通过原生级支付先完成，那么团队的整体成本将直线上升，因为它等于提供了一套多可能性的支付方式。而前端级通过在线即时完成的话，测试成本就极低，因为区块链太慢了。在区块链的过程中，你可以通过前端实时级的验证处理，通过后端大量的httprequest，就等notify回来。所以要在自己的类IM和实时级的场景中出现更多延展性可能以增强产品的实力本身。

区块链

人工智能也是靠数据的累积。当前的业务体量，我们认为smallcompany没有资格介入图像识别的领域，因为它的数据存储量和算例代价太大。但是对语音囤积在本地化算法的过程中，在模型修正的基础上还是有略微空间的。所以存好数据，并且可以方便地把这些历史数据读出来，不停地修正之前语音传下来的识别结果，做到未来的延展力。

快速地听取和对于片碎片化文字的能力已经被微博微信群大量的完成了。速读是对于两三百个文字出现的片段，有对于关键词的抓取能力，已完成快速阅读。我们曾经读书的群体当中流行一句话：谁看的速度快，是因为他看的书多，关键词在他意识中的醒目感和提炼度快。

在商业场景中会出现会有人倒卖前端级工程师的身份数据。倒卖身份数据唯一的识别点在于mobile和身份证是不是同一个人，这样的场景我们称之为预先级私底下的黑色交易会提前出现。已完成在部署和控制端的时候进入数据的验证级，而这里面会出现大量做SDK的公司，但实际上大家可以通过自己H5交互的产品去录段音祝贺一下，这样交互场景都可以出现，可以在产品中考量，它不是为了现在的业务，而是去为未来做积淀。

技术时代的迁移

在我们认为的技术时代变迁过程中，作为前端级工程师可以考量的是，我们从查阅时代到订阅时代到推送的时代到未来的特征平衡，本质上是也许每一个人的云服务会增长，而云服务增长的过程中，进入AR的场景的时候怎样去介入。我们只能用一些工具把它做出来，看到立体式的，这时你会发现上web是最快的方式，但它并没有到绝对业务体量的交互级。所以不仅要用websocket，还要和socket混用，因为有大量的IOT设备需要这样的场景。 从零打造一个产品特别的难，但是去改变别人的产品，增加一个个小功能的情况下，这个概率是有效和实际的。

我们在产品的过程中出现了一些这种具业务级保护的公司。这样的产品量级在未来情况下，我们认为会变得更有优势，也希望大家做前端的情况下，能尝试的在websocket的角度上向公司要一个可测试的demo级场景，去快速发布产品，然后做测试。我们相信未来会在realtime的基础上沟通过程中会变得更有优势和优秀。