“小程式能做什麼樣的產品？”
這可能是我被問到最多的關於小程式的問題。通常我會說：理論上，小程式能力還挺完整的，大部分 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，期待你的加入。