日常碎碎念 2021.08.22

前言

这周真的是太刺激了，为了同一个需求，从周一一直修复到周五，产品又追，设计又追，还有一大堆兼容性问题(比如折叠屏下，UI会裂开的神奇bug🤯)。终于，周五大致修复完成(理论上有一个点还是没能完全验证修复成功，不过产品那边很急，就先hold住，等排期再验证修复吧🤷‍♂️)。

本周回顾

修复Bug

摸了将近1个月的🐟之后，在8月初的时候，终于来了一个大活了。用Hippy为全民K歌APP开发一个页面，那把我激动的啊，都快睡不着觉了。但前辈的经验已经告诉我们: “期望越大，失望越大”，用Hippy写页面就是大坑。到处都是未知的坑，开发环境与线上构建的包，在真机会出现渲染差异，在双端之间一些标签的不同实现方式，又会出现各种奇奇怪怪的渲染bug。真的是能够活活把人气死。为了解决这些傻逼的Bug，足足花了我一周的时间进行调整。周五才算大致结束了战斗，开始准备发布工作。由于需求改动了APP的一级页面，所以还要跟同事协商灰度策略要怎么改，真的是裂开了😂。以前我总是以为小程序的WXML已经是💩一般的语言了，直到我遇到了Hippy，我才知道WXML是多么的好了。Hippy真的是太💩B了艹。

Thinking:

吐槽归吐槽，但是思考总结🤔还是有必要的，总结当下踩过的屎坑，才能在下一步中做出改进嘛。

为什么大家都争着去做跨端框架？

这个只是我当前的所思所见形成的个人观点，是我一些认为的开发痛点。如果你有其他观点(比如这样设计会更好)，欢迎在下方留言评论，进行交流。

我认为主要是以下的三个方面的原因：设计页面门槛高；不支持热更新；客户端开发需要大量人力物力时间。

第一点，写过Android客户端的朋友就知道，其实使用开发工具，没有一定的开发经验下，想要设计出一个好看的页面是很困难的。即使在当下有着Github、Gitee等开源社区的帮助，有很多前辈们已经开发了许多现成的组件。但凭借着个人的力量，想开发出称心如意的APP界面，还是苦难重重的。究其原因，我认为是语言规范导致的。开发Android界面，就像是在Java中使用Swing来开发页面一样痛苦。即使AS已经做了逻辑的抽象，但是不彻底的抽象，其实还是十分的蛋疼。我举一个例子：滚动列表。在Web开发中，开发者仅仅需要专注于页面的样式，以及事件逻辑。如何渲染的问题大部分都将会交给浏览器解决，比如现有一个超出屏幕大小的列表，浏览器会根据屏幕大小，以及内容大小，自动计算出需要滚动才能显示的区域，并且最终将内容放置在一个可滚动的容器类。我认为这种体验才是符合直觉的。而在原生代码(甚至是等下会聊到的跨端框架中)，都免不了需要开发者去维护一个滚动系统。而这是一件非常痛苦的事情，作为开发者我在思考清楚样式的同时，还得花时间去维护这个滚动系统，我得在页面框架中，就定义好什么地方可以滑动，什么地方不可以。但浏览器为啥可以做到，各家厂商推出的原生语言就不能呢？解决这个不就能提高开发效率了吗？(我猜是为了性能？但是都是经过编译的代码，还会产生这种性能问题吗？)

第二点则是原生代码不支持热更新。Android和iOS两家系统为了最极致的性能，提供的都是各家底层所使用的高级语言，前者用的是Java，Kotlin，后者则是Object-c或者Swift。使用这些底层语言带来的收益是显而易见的，性能肯定是最高的，直接就可以跟底层进行数据交互，完全没有性能损失。当带来的劣势同样是显而易见的，必须编译后才能执行。在开发者阶段，重复编译，不能即时预览虽然是一个痛点，但总体而言，这是一个小事或者说是可以通过硬件的能力提升而解决的问题。通过高性能的工作站，我们最终也能实现更快的预览。在发布阶段，不能热更新的特点，对于运营和产品来说其实是一件比较痛苦的事情。在大厂实习的这段时间，无论做什么开发，只要是toC的业务。我们就必须要做数据上报的工作，及时采集数据交给数据中心进行分析研判。但是在原生开发中，如果要给页面埋点，肯定是非常慢的。每次新的活动都需要跟版本的话，一个产品一个月最多也就是发布两次。对于商业而言其实是不利的，在算法时代，不能及时掌握当下消费者的消费习惯，无疑是危险的，极有可能下一秒就被竞争对手所绞杀。

第三维护双端耗时耗力。维护双端，就意味着要多批人马来负责项目的开发。并且为了产品方向的一致性，有些时候，还必须统一时间发版，需要投入更多的开发者才能维持住高效率的开发。这也是非常烧钱的，所以开软件公司不仅仅是看赚的多，背后的投资也是巨量的。

好用的地方在哪？

部分符合直觉的开发规范
还算不错的性能
即时预览
支持热更新

不好用的地方在哪？

继承自原生语言的滚动容器规范
底层能力缺失
费时费力

从什么方向可以改进跨端框架的问题？

Vue不能提供极致的性能，但是能提供一个差不多好的性能

上面那段话不能说是100%原话，但是就这么个意思。我感觉这句话很有道理，当下的所有开发框架，都不是银弹(万能)，不能指望一个框架能解决所有问题，框架肯定会因为时代的局限性，而有部分不足。但是使用较低门槛，提供一个还算不错的结果，有一些小坑也不是不能接受的。反正框架是会发展进步的，以后在实践路上慢慢改进就好了。

首先是前两者纯技术的问题。对于前者，我认为滚动容器的实现，应该要下放到原生实现，面向Web开发者仅仅提供一个内容入口即可，将原生开发者从容器的工程难题中，解放出来，花更多的时间在样式上，能够提高更多的生产效率。另外在原生实现还有一个好处，就是可以利用底层API及时对事件做出相应，比如折叠屏的屏幕变化。在底层通过监听hook，就可以及时变更Web的root容器，而不用web过多的去干预这些底层的事件。对于后者则需要双端开发者的配合，封装出更多原生能力API，提高易用性。(小程序算是一个不错的范例了)

费时费力。看到这个词语，不知道你会不会感同身受。就是当下的双端框架都太傻了，非常难用，无论是Vue、React、uni app，在web端开发的时候还好好的，一旦打包到双端的真机上就会迸发出各种各样诡异的bug，而且由于各家有各家的实现方式，代码本身就变得很难调试，总是需要开发者耗费大量的时间在解决bug上。在我看来，这其实也不算是坏事，通过社区文化来找出其中的问题，并且及时反馈给开发者，帮助开发者及时去修正问题。现在多花一点时间来解决问题，在未来就肯定可以节约更多的开发时间。我也相信在未来肯定会有一天，跨端框架能够部分取代原生开发，并且成为主流。说回到解决方案上，以hippy为例。我认为需要建立自己的开源社区，吸引更多的开发者加入使用，鼓励开发者反馈Bug，并形成良性循环，才是未来要做的事情。小程序就是很好的例子，18年的时候，小程序刚刚起来，那时候真的是非常的难用，我甚至嗤之以鼻，认为小程序就是垃圾。但随着这几年的开源社区以及举办高校开发者大赛，让小程序逐渐有了更多的开发者，其本身也借助这些开发者的反馈正在变得越来越完善，使用体验也在变得越来越好。我认为这对于Hippy来说，是一个值得学习的范例。

深圳文和友

周末的时候，闲着没事，看到大众点评上发的，深圳文和友开业。因此屁颠屁颠的搭着地铁就去了。深圳文和友就在深圳地铁一号线的老街站附近，搭地铁去就行了，非常方便。

说实话，文和友其实哪里都差不多，广州的调性就是70-80年代的老广州，深圳就是九龙城寨的感觉，内核还是传统的商业街。但是透过复古的调性、上档次的品牌以及品牌宣传，来吸引大家来消费。对于周末休闲，情侣来说还是不错的选择，可以来逛逛，不必太唾弃。

里面有一家Top Boy(潮玩店)，看到了这个1:4的雅儿贝德，真的是太太太大(好看)了吧，哧溜～。上万能的某宝一查，全球限量300套，12800一只，骨王也是12800。哭了，好想拥有啊QAQ。

正宗茶颜悦色来深圳开店了，巨多人，因此在隔壁买了这个槟榔糖就溜了，还没吃，不过感觉挺新奇的就入手了，在下周的周志中，给大家分享一下味道如何。

还看到了这个Cyberpunk的招财猫，摆这个在门口，绝对招财，那手臂可比其他家猫猫的大多了😂。

入手AirPods 2代

最近拼多多在搞百亿补贴，769有线版，一下子没忍住，就把AirPods 2代给入手了。虽然这是Apple在2019年发布的产品，但拿在手里还是秒杀身边的一众耳机产品，耳机盒非常的小巧，揣在兜里完全无感。

耳机非常的轻便，待在耳朵上几乎没有感觉，配合着iPhone流畅的动画，真的是爽到了。直接呼出Siri，语音播报，语音接听，一切都很nice。除了接力我没整明白(没法自动切换音频)，其他我都很满意了。你问我为啥不买无线充电版？其实无线版并不是刚需，之前的Freebuds 3虽然配备了无线充电功能，但是由于跟P20 pro一样是Type-C口。所以充电的时候，直接插线其实更方便，使用次数也远比无线充电多。另外就是无线版，没百亿补贴就算了吧😂。至于AirPods 3代，我看过年初有dalao分析过，当时流出的照片只是工程验证样机，距离实际的小规模试产还有一段距离，最快也要9月才能开始试产，最快也要22年的第一季度才能发布，所以综合各路新闻，我还是先入手AirPods 2代玩着先吧。等以后去加拿大之后，我再入手AirPods 3代就好了。(不要掉入消费陷阱😄)