做一个很难的小程序是怎样的体验(一)

2,536 阅读9分钟

“小程序能做什么样的产品?”

这可能是我被问到最多的关于小程序的问题。通常我会说:理论上,小程序能力还挺完整的,大部分 Web 可以做的产品,都可以落地。

但理论终归是理论,唯有实践出真知。

正好,前段时间我们在轻芒做了一个特别不小程序的小程序。这也许是目前小程序中,交互最有特色,实现最有挑战的小程序之一了。开发过程中,我们碰到了很多困难也积累了不少有趣的经验,于是,我开了这个坑,整理了一些心得体会,聊一聊做一个技术上够有挑战的小程序,是怎样的一番体验。

                                                        

我们的实践,源自于研发 轻芒杂志 2.0 小程序版,如果你还没用用过,正好先扫码体验一下(手机党直接在微信中搜索 轻芒杂志 就可以找到了):

                            

轻芒杂志 2.0 是我们对原有产品的改版,核心是围绕内容展开的。在 1.0 我们把从各个应用中收集到的优质内容,重新按照兴趣组织通过算法持续推荐出去,在此基础上,2.0 更多的引入了人的推荐,通过人可以进一步挑选好的内容,并且,通过马克操作,把内容中最精华的部分摘选出来,让好内容也能适合碎片时间来阅读。

为了更好的表达内容上的不同,我们也特别大胆的设计了整个产品架构,尝试创造了很多不一样的交互体验(当然,有的地方步子迈的有点大,不少实现略显粗糙,还在持续改进),并且首选了小程序平台来落地产品。

                                                      

当我们把更丰富的内容、更精细的交互带到小程序上,带了意想不到的技术挑战。我们通常会说,这个产品做起来很难,但难这一个字,背后有着丰富的涵义。

开发之难,可能来自于:

  • 如何让产品有出人意料的功能
  • 如何让产品性能更为卓越
  • 如何让产品更精细,更稳定
  • 如何让开发效率更高,更易于维护
  • ...

总结成一句话,就是开发困难的东西,都是在挑战平台的极限。需要用到的技术不是显而易见或者是最通用的解决方案,这时候需要对平台有更深入的探寻和思考,才能找到最优的答案。

做一个很难的小程序是怎样的体验系列,会围绕这个话题来展开(请原谅这个土鳖名字,我实在想不出来更好的了,总不能叫小程序开发精要吧...)。我们做轻芒杂志的时候,走到了小程序中一些鲜有人去的地方,我想整理这些开发经历,加上我自己对小程序设计的看法,来一起聊聊小程序在功能、设计、性能优化上的一些特点、挑战和解决方案。

                                                     

言归正传。

这篇想聊的,是在小程序中探寻可行性。如果一个功能如何实现不是显而易见的,往往就需要花大量的精力去寻找解决方案,这就是对可行性的探寻,它往往会耗费大量精力而没有产出,这也许是产品研发中最艰辛也最有趣的地方了。

单看客户端开发,可行性往往由平台特性所决定,这其实很容易理解,毕竟客户端开发是在他人构建的沙盒中进行,无法替换,只能探寻。

在类似 Windows 这样的传统客户端,探寻可行性需要在无数种可能中寻求最优解。这些平台提供了海量的 APIs,拼凑一种可行的方案也许不大困难,但想再竞争中脱颖而出,就必须要找到那个最优解。而这个方案,可能会用到藏匿某个 APIs 背后那个鲜为人知的用法,这也就是为什么传统客户端开发,往往需要非常丰富的经验,需要对平台特性有深刻的理解和实践。

而在小程序上,可行性的挑战来自于寻求唯一解。全部 APIs 放眼一望就看尽了,似乎能做什么不能做什么太显然,要想实现一些看似不可能需求时,往往不是把一条路探到底,而像在走迷宫,看上去都是死路,不能硬闯,需要巧妙结合起来各种路线,很有可能找到一条通抵答案的路。

                                                     

做轻芒杂志中,这样的案例有不少,我记忆最深刻的,是对文章马克功能的实现,很能体现在小程序上探寻可行性的过程。

当时,产品的需求是这样:

马克操作的简便性,必须和截屏一样,用户手下去再起来就完成了。在精准性上,需要比截屏更进一步,并且不需要对着放大镜拖着小滑杆一点一点抠。

最后,在 2.0 版本的现实效果是:

打开轻芒杂志进入任何一篇文章,长按文字,吸附选中当前的句子,像推动游戏摇杆似的上下搓动,可以快速调整需要选择的句子和段落,然后,放手就成了(效果如下组图)。

看上去,还比较接近当时的需求,但回想整个过程,其实非常曲折。

最初听上去这个需求觉得应该不是太难,毕竟在 iOS/Android 上,一股脑就可以想到很多可行的方法,比如:可以组合控件、可以直接从排版层(Layout)来控制、抑或完全自行排版,等等。

但落地到小程序上,就傻眼了,所有的思路一下被堵死,因为:

  • 小程序缺少对界面信息的获取方式,即使新增了接口,也很难精确了解界面状况,进而动态的调整交互;
  • 小程序能监听交互事件的方式非常局限,不仅事件少,还灵活度差;
  • 无法获得排版信息
  • 直接绘制?Canvas 官方都不推荐了,因为真的设计的太糟糕没法用
  • 各种 Bugs;
  • ...

怎么解决?像传统方式一样,扎进 APIs 堆里往底层挖,显然不大好使。唯一的策略是跳出单纯的技术策略,一群产品和工程坐在一起,看技术上有什么能用的,然后一起讨论这技术能搭配怎样的设计,然后修改设计,编码尝试,不断迭代。

整个场面类似于:

(抱着头)什么?小程序上想做这个?!你疯了吧!就那么几个 APIs 你让我怎么做?什么?我最厉害了?!好吧,让我想想看。

… 一周后 …

(咬着牙)文档我都翻烂了,好像有一种方式是可行的,但不大确定,我要试试看。来吧,再说一遍我最厉害!

… 一天后 …

(含着泪)你看,我真的实现了!我果然最厉害!

... 一小时后 ...

(锤着胸)为什么会有这样的 Bug!一定是你姿势不对,你看我操作!... 怎么还不好,一定是你手机坏了!我给你扔掉了。什么,你这台是 iPhone X?我的肾去年就卖了一个,我卖不起来了啊!

直到最后,倒腾出了这个方案。大抵是:

  • 发挥数据结构的力量。既然动态捕获不了精确的界面信息,就提前把内容打散,拆成段落、句子、词,映射出一个比较复杂的控件树,这样只要控制每个控件的渲染,了解控件在界面中的信息就够了;
  • 用基本的交互事件来模拟高阶的交互事件。小程序的高阶交互事件(比如长按、滑动)Bugs 太多,只有用基本事件(比如:点击、结束点击)来模拟才能绕过;
  • 修改设计!通过调整成按句子选择、模拟摇杆操作,绕开精确控制的必要性,不仅简化了实现,在用户体验上也更为流畅;

总结一下。就是小程序提供的 APIs 还是比较有限的,解决复杂的问题,不仅需要在技术上反复探寻,组合不同的 APIs,还需要结合调整产品、需求来迎合小程序 APIs 的特点,才可以落地更为理想的产品方案。这也许,是在小程序上做到各种惊艳体验的唯一办法。

                                                        

在写这份初稿的时候,Apple 的新品发布会正在直播,每个人都在等待 iPhone 8,以及 One More Thing 的 iPhone X(可见这稿拖了有多久...)。在这个行业最快乐的事情,就是可以去不断接触这些新平台新技术,把新的想法用新的方式实现了,创造更有趣的产品。

我们在轻芒,也在寻找志同道合的伙伴。如果你喜欢研究算法策略,欢迎和我们一起来琢磨,还有什么办法可以更好的组织和推荐高品质内容;如果你喜欢看到产品像工艺品样在自己手上诞生,欢迎和我们一起来继续改进轻芒杂志小程序,以及正在开工的轻芒杂志 iOS、Android 客户端。

只要你觉得我们做的产品有意思,觉得去寻找更好的内容分发方式是有趣的事情,又具有不错的技术基础,那不论是全职、实习、算法、服务端、Java、Android、iOS、Swift、Kotlin、Scala、等等,都可以直接联系我 duguguiyu@qingmang.me,期待你的加入。