酷播亮新聞
文章基於自身經驗，為我們分享其在開發輕應用時遇到的問題，希望能夠給你帶來借鑒與思考。
首先介紹一下，什麼是輕應用。 簡而言之就是硬件廠商提供的免安裝應用的直達服務。
自從微信推出小程序之後，為了抗衡小程序，各大手機硬件廠商都在默默孵化的免安裝應用。
在宣傳的時候主打幾個特點：低折損、重體驗、強留存、低成本、易傳播。
我廠是國內某養車 B2C 公司，參與小米、華為等安卓輕應用聯盟的內測開發。 因此大家在看不見摸不著的未來可能的巨大利益驅動下，開始了至今為止3個月的開發。
硬件廠商推出的「免安裝應用」後面我們稱之為輕應用。 整體系統架構其實與微信小程序非常的相似。
安卓市場的各位廠商爸爸們規定了一套類似的原生的語法。 這套原生語法可以保持與 app 完整度一致的前提下做到 rpk 包非常小，通常不超過 1M。 且比微信更牛逼的是，他們號稱「系統級應用」。
商務在和廠商爸爸的聊天過程中，他們提到了許多非常誘人的數字，比如裝機量以及激活量都是 app的百倍以上。 同時，轉化率非常高
看到這樣的數字，老闆們都很激動，一聲令下，做！ 便開始了我們苦逼的開發週期。 上週我司請來了業內某前端大神，也是國內某超級大廠輕應用項目的技術負責人，來我司分享經驗。 發現其實在開發過程中大家遇到的坑幾乎是相同的。 下面跟大家講講嘮嘮嗑，講講我們在開發輕應用時遇到的問題。
一、拿到的文檔未必是最新的
第一次看某廠商的技術開發文檔，講真非常懵逼。 文檔非常簡單，只是一個 Word 版本的開發說明，對於一些關鍵點的介紹都非常模糊。 對比微信官方文檔來說，易讀性就不在一個級別。 比如接口文檔上明確提到了此處需要請求廠商的某一個接口，但是翻遍文檔的每一個角落，幾乎都沒有找到這個文檔所說接口的請求地址。
我的建議：一定要多溝通，盡可能的建立高效的溝通模式。 如果對面願意配合你們建 trello 等任務管理工具是做好，如果不行，多溝通是最需要的。
但是多溝通這裡面還是有一些門道。 如果你們公司商務給你們對接到了應用廠商的相關技術人員，那是上上策，不管怎麼樣厚著臉皮要到電話和微信，對面雖然可能電話不接，微信回的慢，但是所有渠道試過之後一定 還是會有回應的。 另外在溝通的時候如果是文檔方面的問題，一定要跟對面的商務/技術講清楚你手上文檔的版本號，有可能你們的技術還在對著V1.0 版本的手冊開發的時候，對面 的技術大大已經更新到V3.0了。
二、廠商的技術也不是萬能的
小程序在推出前在微信內部整整內測了一年，但是輕應用從起頭到現在還不足一年，所以各位可想而知還是非常非常不成熟的，大家不要指望你家遇到的每一個 問題對面都有方法可以解決。
一定要做好對面說：「啊咧？你們怎麼會遇到這個問題啊？抱歉，這個問題我們暫時沒有解決方案」，這個時候考驗你們技術，和你自己產品力的時刻就到了。
我的建議：要做好這樣的心裡預設，並且面對最糟糕的環境還是要做好最充分的準備。 由於我們在陪著各大廠商內測他們的服務。 因此對面還是很願意配合這些事情。 盡量給廠商的技術多提幾個你們的計劃策略，讓對面幫助一起探討這個東西的實現可行性。
如果對面實在沒有好的方案，可以要求對面在open api 上為你們家專門協約參數來滿足你們的需求。 舉個栗子，我們之前為某廠商開發過付費包對接過一次他們的賬戶系統，這次要做輕應用同樣需要對接一次賬戶系統，坑爹的是，廠商目前沒有用來校驗用戶身份唯一性的 字段，也就是我們通常講的「uniion id」，直接導致的結果是我們產品的userid 可能會對應多個廠商賬戶。
這個在後期清洗數據、綁定關係以及對用戶資產處理等產生一系列的影響。 面對這種情況就是考驗各位產品力的時刻，可以和廠商協約唯一參數，也可以更改你們的產品策略。 適合自己的才是最好的
三、你做好盲寫的準備了嗎
本周和某大廠輕應用技術負責人溝通的時候，發現他們也有一樣的苦惱。 由於廠商啟動輕應用的項目是在不成熟且資本大量注入的情況下開始，基本都是邊跑邊打。 很多東西廠商自己都還沒想清楚，就需要我們這些內測應用配合開發上線了。
這個時候最大的困難是和本公司商務、技術開發溝通的問題。 技術大大們在面對一臉懵逼的文檔、不算太清晰的需求、緊張的開發週期一般都會有逆反情緒。 另外你可能還會面對商務大大的脅迫。 居中調節顯得很重要。
我的建議：做好兩方面的心裡預設功課，降低商務對項目完成時間和完成度的預期。 提高技術大大對項目目標感和成就感的預期。
我們在做某大廠卡片對接的過程中，發現對面根本沒有做好卡片對接的一系列環境的預先工作，導致我們整個開發週期都在盲寫中度過。 沒有調試工具，沒有測試環境。
所有的東西寫好之後打成包，由廠商的測試替我們上架，在廠商的環境下進行測試通過驗收。 盲寫的環境下，就會有大量的技術盲點，因此開發在開發過程中會非常的頭大。 建議大家和產品負責人在這塊多溝通。 多協商，安排開發資源的時候也可以要求技術大大不需要全身心的撲在這上面，而是對面有了相關的回應再繼續，以免做無用功。
四、切記投機取巧的事情不要做
這點是我廠目前吃的一個比較大的虧。
最開始在溝通開發輕應用與我廠前端架構一起看文檔的時候，發現輕應用不同於小程序，竟然提供了前端WebView 的接口，也就是說在小程序的環境下，如果你想用Webview 框架 下去實現小程序是不可能的，因為微信當時根本沒有提供那項能力，所以只能老老實實用小程序的原生語法編寫。
但是輕應用不同，輕應用一開始就提供了 WebView 的接口，因此我們前端架構當時提議說，我們根本沒必要使用原生的語法，WebView 可以在和我們移動站 2.0 相同語法下一起同步開發。 聽起來是不是很靠譜，很省力，很美好，心裡是不是美滋滋。 但是開發過程中遇到了無數的坑。
很多原生輕而易舉可以實現的功能，WebView 累的要死都未必可以百分之百實現。 比如說點擊返回按鈕按照用戶操作錨點返回這一功能。 用原生來寫，非常簡單，但是廠商根本沒有提供用WebView 實現倒退的方案，就這個問題我們解決了很久很久，以及其他很多和這個一樣很小，但是解決起來非常麻煩，把上述說的那些問題 都解決完，即使用原生代碼實現也能夠完成了。
另外由於各大廠商現在雖然打著他們用同一套系統架構來實現輕應用，但是總是會有其定制化功能，比如賬戶、推送，這兩點肯定各家都有自己的玩兒法，到 時候再要改寫原生，就非常蛋疼了
五、輕應用的開發不是一蹴而就
輕應用的開發，如果是決定全部用原生寫，其開發成本幾乎等於開發一個小型的app，且要保留產品所有主流常規業務，因此成本是比較高的，因此需要產品經理和技術負責人根據你 司業務發展方向結合對輕應用這個項目預計投入資源來綜合考量後續迭代投入的人員。 講真，輕應用現在的既存渠道來看，數據是非常低的。 我們和某大廠聊下來，他們的輕應用也是完全沒有起量的狀態。
在這個環境下如何平衡投入產出比，對每個產品經理來說不可以不說是一個不小的挑戰。 但是有一句話是我的 mentor 分享給我的，在這裡我也想分享給大家。 輕應用是廠商未來的方向。 並且是安卓應用聯盟各大廠商投入了巨大資源、成本、人力來做的系統級應用產品。 儘管現在沒有起量，隨著他的能力逐步升級，他的流量價值和轉化價值我相信也會逐步顯現。 我覺得的確是未來的方向。
當年，有多少人看衰小程序，有多少人說小程序必死，現在呢？ 一年後呢？ 有多少產品圍繞小程序做業務模式的創新，又有多少產品的小程序獲得了幾乎是現象級的成功，比如拼多多，他的小程序的拼單數據已經和 app 數據快要不相伯仲。 未來，誰都說不准。
作者：晞仔，微信公眾號：晞仔的生活實驗室
本文由 @晞仔 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議