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

这可能是我被问到最多的关于小程序的问题。通常我会说：理论上，小程序能力还挺完整的，大部分 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，期待你的加入。