1背景

字節跳動小程序是基于字節跳動的總產品矩陣開發的，它與圖片、視頻等場景自然搭配，帶動小程序的分發，小程序的內容帶來數量和裂變。作為一個高流量、高活躍的平臺，它為用戶提供了巨大的增量挖掘空間。

對于頭條系統應用，同一個小程序可以同時在多臺主機上啟動，今天的頭條、顫音、頭條速度版本已經打開。顫音和今日頭條都屬于內容分發平臺。相比微信官方賬號的讀者，顫音用戶相對年輕，而頭條在三四線城市擁有大量的讀者，正好符合電影作為內容消費的特點，有助于淘寶電影更好的拉倒用戶。基于頭條和顫音平臺的優勢，我們在2019年推出了淘寶電影字節跳動小程序。

2種應用場景

今天頭條的六個主要場景：

信息流推薦

直接搜索

標題安裝小程序

分享

集中入口

保留入口

今天的頭條

顫音的四個主要場景：

小型視頻支架

企業主頁

搜索演示文稿

保留入口

廣告投放

3基本介紹

字節跳動小程序的基本開發思路類似于前端開發，增強了對大量終端的調用能力，性能體驗優于普通Web。上層架構基于JS開發，可以輔助開發人員很好的開發。框架結構和開放性類似于支付寶小程序、微信小程序、百度小程序。

目錄結構：主要分為以下幾類文件：

帶后綴的Json配置文件.JSON，配置小程序所有頁面的路徑和界面呈現方式。

位于末尾的模板文件.ttml用來描述當前頁面的文件結構，類似于網頁中的HTML文件。

結尾的樣式文件。描述頁面樣式的ttss類似于網頁中的CSS文件。

結尾的JS文件.js處理這個頁面和用戶之間的交互。

目錄結構

四張快速申請卡

1概述

目前基于Super   APP的各種小程序明顯削弱了手機廠商的分銷能力和話語權。因此，國內手機廠商在推出快速應用后，逐漸開放了手機負屏的能力，為快速應用等服務提供了直接入口。

2卡類型

快速應用的卡類型可分為應用型卡、服務型卡和其他類型的卡。

應用類型卡：用戶訂閱的卡，內容相對固定。

服務類型卡：可以根據用戶關心的數據狀態實時更改內容。

其他類型的卡片：自定義卡片，根據相應的內容顯示和跳轉。

3應用卡的特定訪問

卡的開發是基于快速應用的，使用的API是快速應用的子集，有些API不能在卡中使用。目前已知的vivo、OPPO、NUBIA都需要卡的開發不依賴于主rpk，即需要獨立于主rpk進行渲染。為了保證卡片的獨立渲染，相關的對象。$app和文件app.ux中聲明的工具類或生成的對象不能使用。1)卡初始化配置

a)配置文件

所有的卡片都需要在manifest.json中聲明，就像快速應用程序中的聲明頁面一樣。具體是在router.widgets里面配置的，不同廠商之間有一些區別，但是差別不大。

b)卡配置文件中的注意事項

請使用小部件中配置的鍵值的路徑名。如果路徑是兩級的(如/A/B)，鍵值配置為‘A/B’，這個值最終對應的是后臺上傳卡時廠商填寫的卡路徑。基于此，廠商可以正確解析上傳到聯盟的統一快速應用包中對應的卡。

卡使用的系統API需要在卡的屬性特征中聲明。這些API已經在外部應用程序的特性中聲明了，所以需要在這里再次聲明，否則無法使用。

2)應用型卡接入(以vivo為例)

負一屏卡在線渲染

a)卡的聲明

除了manifest.json中的上述配置之外，對于卡片，應該注意卡片屬性中的以下字段：

Params字段用于配置卡片更詳細的參數和**的支持參數，需要根據單據進行配置。

TargetManufactorys表示相應制造商適配卡的匹配制造商。詳情請參考文件。

b)卡開發的差異(關于所使用的API和組件的子集，請參見官方文件)

Vivo卡是一個單獨的項目，不能在fast應用項目中配置，需要單獨建立一個新項目。

對應的包類型也需要單獨配置，不同于主要的fast應用，需要使用vivo給出的相關工具。

卡片有獨立設置主題的功能。

卡片有折疊功能。

卡片的可視副本由內容提供商提供。

卡牌開發只需要開發內容區，標題區不需要開發(由vivo的負屏容器繪制)，也就是說下半部分的圓角需要自己繪制。

上傳卡包時需要提供相應的圖標。

c)卡調試

卡調試需要使用vivo提供的工具打出來的rpk文件，也需要使用vivo提供的專用內核和容器，可以根據文檔實現。

d)卡提交

首先，你需要完成自測。自測結束后，需要使用vivo提供的專用包裝工具。打包后，需要提交給Jovi后臺地址，并提供一個應用圖標。

4負一屏服務類型卡訪問

以OPPO服務卡接入為例：

觸發場景：用戶在淘寶Film   Express應用中購票后，在電影上映前的固定時間內觸發卡內容顯示，然后提醒用戶取票，即消息觸發場景。OPPO負一屏卡在線效果圖

1)申報1)OPPO服務卡

在manifest.json中的router字段添加widgets字段，在這個字段添加相應的配置，和OPPO應用卡一模一樣。

2)卡開發

OPPO服務卡開發涉及到用戶關注數據狀態變化導致觸發卡的場景，因此需要整體解決以下幾個問題：首先是觸發時機，然后要確認被觸發卡的ID，觸發哪個OPPO用戶。

3)3)OPPO服務卡整體開發流程

前提：需要開通OPPO賬戶服務，在快速申請中可以獲得OPPO當前登錄用戶的授權碼。

a)賬戶綁定，即OPPO賬戶和快速申請賬戶的綁定

賬戶綁定分錄：該分錄由OPPO負屏容器統一提供，其位置如下圖左側所示：

OPPO服務卡綁定條目和自定義綁定頁面

該條目對應于快速應用程序中的綁定頁面。

b)綁定頁面的開發，這是一個快速的應用頁面，主要提供綁定功能

功能是讓內容提供商服務器知道其賬號與OPPO測試的對應關系，交換向OPPO發送消息時需要的TOKEN值。

c)觸發對應OPPO用戶的負屏卡

當用戶關心數據變化時，內容服務提供商向OPPO服務器觸發推送消息。消息攜帶相應的令牌值、要觸發的卡標識、消息內容以及觸發的時間和長度。OPPO服務器會根據TOKEN找到對應的用戶發送消息，必要時拉起對應ID的卡。

d)卡消失

它由發送消息中定義的卡持續時間決定。顯示時間結束后，負屏容器會自動取出卡片。

e)調試

首先你需要OPPO服務器參與

其次，要求OPPO提供負一屏開發環境版本，保證OPPO服務器的日常環境數據能夠到達。

再次，需要將初步測試后的包括服務卡在內的rpk提供給OPPO端，并將rpk配置到OPPO對應的環境中。

f)向市場提交

測試完成后，可以在OPPO后臺提交卡，同時同步正式生成的卡，并在自己的服務器上標記，推送消息使用。

g)綜上所述，涉及各端的開發工作如下：

首先涉及服務器賬號綁定、TOKEN刷新、維護的開發，觸發的消息推送至OPPO。

其次，涉及前端服務卡開發和綁定頁面開發。其他涉及：開通OPPO賬戶服務。

5踩坑記錄

負屏UA不同于快速應用中的UA。如果有與UA相關的配置，要注意。

在調試過程中更新rpk后，當實際打開的對應更改沒有反映出來時，可以嘗試清除對應卡容器的緩存，確保該容器具有相應的讀取和存儲權限。

對于同一個業務，由于不同廠商的適配和平臺不同，需要寫很多代碼，但是基本的業務邏輯是基本相同的，**的區別就是UI顯示，所以一開始就要把數據邏輯撤了，不同廠商可以顯示不同的UI。

4.淘寶電影小程序建設的演進

我們做了很多小程序，對多終端同構做了一些嘗試。

1從一端到多端

1)開始：小程序的原生開發

2018年，隨著小程序平臺的爆發，我們**次走出淘寶，試圖登上頭條。這種嘗試，使用原生小程序的DSL語法。為了重用現有的H5風格，在編譯Less時加入了glaugh。

這種開發方法雖然輕快，但也暴露了很多問題：

包裝體積難以控制。

原生DSL沒有復用性，需要重新學習。

無法使用NPM，一些常用的社區包和團隊基本工具鏈。

模型兼容性不好，沒有巴別塔支持。

2)摸索：兩頭，一套代碼？

在開發百度小程序的過程中，我們**次吸取了教訓，加了webpack做了一層編譯。一是解決了套餐介紹問題；其次，我們添加了babel插件來解決JS兼容性問題，并打開了CommonChunk插件來解決包大小問題。

一般來說是從輸出的一端變到輸出的兩端，所以有一些區別。針對這些差異，編寫了一個插件來平滑業務層。比如微信上介紹index.wx.js，頭條上介紹index.tt.js。

脫離刀耕火種的耕作，開發效率明顯提高，但還不夠好。還有兩種觀點，以后每一種新的結局都會拉出一個新的。

3)優化：走向社區，跨越多個終點

在開發頭條和百度小程序的時候，業界已經有了一個封裝在小程序DSL上的框架，但是當時還不是很成熟，基本都集中在一個平臺上。沒有跨端能力，他們沒有使用生產環境，而是一直關注更新狀態。

2019年我進入微信小程序，再一次看市場上的框架，發展很快。同時也注意到了跨端開發的需求點，選擇了芋頭作為主要框架。這種框架交叉評價就不展開了。選擇芋頭的原因有很多：相對活躍的社區，支持逐步交接，TS，反應喜歡。a)平穩遷移

Taro支持漸進式切換，也就是Taro和DSL混合寫入的能力，所以遷移成本可以接受。我們先Taro主頁，然后慢慢迭代把所有頁面切換到Taro。這里值得一提的是，芋頭的跨端分化加工和我們之前的加工思路是一樣的，所以遷移Util的成本幾乎為零，成本主要集中在視圖層。

b)優點和缺點是什么

用芋頭的好處是解決了我們之前遇到的主要問題，是一個打包解決方案。

同時，上層框架在擴展新端時成本低，移動性高，框架提供了低適配成本的新平臺包。

當然也有一些新的問題，比較嚴重的是調試，因為代碼已經翻譯過一次了，而且不支持Soucemap，導致調試體驗很差。

2多端差異

多終端難免會有一些差異，比如微信上的分享能力，顫音上的顫音攝像頭，百度的feed   stream，這種差異可以分為三個部分：輸出不同的頁面，不使用相同的組件(有的端使用原生組件)，細化到不同的邏輯。

1)輸出不同的頁面

用芋頭的時候發現不支持。我以為編譯時可以用babel-preval輸出頁面配置，這樣就不會影響包的體積了。最后，我們反饋給社區。

使用不同的組件，不同的邏輯。根據最終的組件不同，我們最常使用多態模式，底層組件向外界公開相同的接口。在端調用時，不需要考慮端的差異，在導入層會根據不同的端引入不同的具體組件。

2)結束邏輯

如果有一些簡單的邏輯差異，可以直接使用環境變量進行控制，采取不同的邏輯。這種方法對于較小的邏輯是可以的，但是在代碼較多的情況下不容易維護。

3)可維護性建議

這里推薦幾種可維護的差異處理方法：

設計組件時的插件：比如路由，不同的終端需要在跳轉前后有一些不同的操作。插件實現后，每個終端只需要掛載不同的插件。

配置拉走：對于一些不同的配置，比如一些文案和固定內容，可以拉到一個統一的地方進行維護，可以少很多ifelse邏輯。

善用函數hook:針對不同的目的，在函數中放入相同的邏輯，將不同的邏輯拆分為beforeHook和afterHook。

3項目維護策略項目產出多端后，每一次變化和回歸都成為一個重要問題。如何保證自己的代碼在另一端不會出錯？每次換一個小程序，都要馬上返回嗎？如何快速整理其他變化？下面總結一下多終端項目維護的一些經驗。

1)單一測量

為核心邏輯、單元測試和快照測試編寫測試，并在內部維護終端應用編程接口的模擬測試庫。整個測試可以在節點環境下運行，以保證運行效率。

2)提交規范

指定一個提交消息規范，你就可以一目了然的看到你在做什么，你在改變哪一個端，以后回到策略的時候用什么。

3)吉特-胡克

使用githook可以保證以上規范能夠真正被遵循，保證每次提交的質量。在預提交期間運行Eslint，然后檢查提交消息是否符合規則，最后在推送期間運行整體測試。

4)多元回歸策略

不做E2E的主要原因是小程序的限制，這使得編寫case很困難，可維護性低，不能自動化。

目前，我們正在手動返回。如何才能保證代碼在其他端不會出錯？每次換小程序都要馬上返回嗎？回答這兩個問題，寫代碼的時候考慮影響面，提交的時候提供足夠的變更信息，合并的時候主要衡量當前端，不返回所有端。當另一端需要發布時，拉出commit-message的版本，整理變更范圍，在這一端做回歸。這樣可以減少測試的集中消耗，保證質量。

*****是一家主營:煙臺小程序開發,煙臺網站制作,煙臺網頁制作,煙臺微信開發,煙臺app開發,煙臺網站建設,煙臺物聯網開發,煙臺網絡公司,煙臺網站制作公司,物聯網系統開發,煙臺app開發公司.歡迎來電咨詢！