我記得五六年前，當(dāng)我在 Android 開發(fā)領(lǐng)域尚處初出茅廬階段之時(shí)，我曾有一個(gè)執(zhí)念——想看下大公司在研發(fā)一款產(chǎn)品的流程和技術(shù)上跟小公司有什么區(qū)別。公司之大，對(duì)開發(fā)來說，不在于員工規(guī)模，而在于產(chǎn)品的用戶量級(jí)。只有用戶量級(jí)夠大，研發(fā)過程中的小問題才會(huì)被放大。當(dāng)用戶量級(jí)夠大，公司才愿意在技術(shù)上投入更多的人力資源。因此，在大公司里做技術(shù)，對(duì)個(gè)人的眼界、技術(shù)細(xì)節(jié)和深度的提升都有幫助。

我記得之前我曾跟同事調(diào)侃說，有一天我離職了，我可以說我畢業(yè)了，因?yàn)槲疫@幾年學(xué)到了很多?，F(xiàn)在我想借這個(gè)機(jī)會(huì)總結(jié)下這些年在公司里經(jīng)歷的讓我印象深刻的技術(shù)。

1、研發(fā)流程

首先在產(chǎn)品的研發(fā)流程上，我把過去公司的研發(fā)模式分成兩種。

第一種是按需求排期的。在評(píng)審階段一次性評(píng)審很多需求，和開發(fā)溝通后可能刪掉優(yōu)先級(jí)較低的需求，剩下的需求先開發(fā)，再測(cè)試，最后上線。上線的時(shí)間根據(jù)開發(fā)和測(cè)試最終完成的時(shí)間確定。

第二種是雙周迭代模式，屬于敏捷開發(fā)的一種。這種開發(fā)機(jī)制里，兩周一個(gè)版本，時(shí)間是固定的。開發(fā)、測(cè)試和產(chǎn)品不斷往時(shí)間周期里插入需求。如下圖，第一周和第三周的時(shí)間是存在重疊的。具體每個(gè)階段留多少時(shí)間，可以根據(jù)自身的情況決定。如果需求比較大，則可以跨迭代，但發(fā)布的時(shí)間窗口基本是固定的。

有意思的是，第二種開發(fā)機(jī)制一直是我之前的一家公司里負(fù)責(zé)人羨慕的“跑火車”模式。深度參與過兩種開發(fā)模式之后，我說下我的看法。

首先，第一種開發(fā)模式適合排期時(shí)間比較長的需求。但是這種方式時(shí)間利用率相對(duì)較低。比如，在測(cè)試階段，開發(fā)一般是沒什么事情做的（有的會(huì)在這個(gè)時(shí)間階段布置支線需求）。這種開發(fā)流程也有其好處，即溝通和協(xié)調(diào)成本相對(duì)較低。

注意！在這里，我們比較時(shí)間利用率的時(shí)候是默認(rèn)兩種模式的每日工作時(shí)間是相等的且在法律允許范圍內(nèi)。畢竟，不論哪一種研發(fā)流程，強(qiáng)制加班之后，時(shí)間利用率都“高”（至少老板這么覺得）。

第二種開發(fā)方式的好處：

1. 響應(yīng)速度快。可以快速發(fā)現(xiàn)問題并修復(fù)，適合快速試錯(cuò)。
2. 時(shí)間利用率高。相比于按需求排期的方式，不存在開發(fā)和測(cè)試的間隙期。

但這種開發(fā)方式也有缺點(diǎn)：

1. 員工壓力大，容易造成人員流失。開發(fā)和測(cè)試時(shí)間穿插，開發(fā)需要保證開發(fā)的質(zhì)量，否則容易影響整個(gè)迭代內(nèi)開發(fā)的進(jìn)度。
2. 溝通成本高。排期階段出現(xiàn)人力沖突需要協(xié)調(diào)。開發(fā)過程中出現(xiàn)問題也需要及時(shí)、有效的溝通。因此，在這種開發(fā)模式里還有一個(gè)角色叫項(xiàng)目經(jīng)理，負(fù)責(zé)在中間協(xié)調(diào)，而第一種開發(fā)模式里項(xiàng)目經(jīng)理的存在感很低。
3. 這種開發(fā)模式中，產(chǎn)品要不斷想需求，很容易導(dǎo)致開發(fā)的需求本身價(jià)值并不大。

做了這么多年開發(fā)，讓人很難拒絕一個(gè)事實(shí)是，絕大多數(shù)互聯(lián)網(wǎng)公司的壁壘既不是技術(shù)，也不是產(chǎn)品，而是“快速迭代，快速試錯(cuò)”。從這個(gè)角度講，雙周迭代開發(fā)機(jī)制更適應(yīng)互聯(lián)網(wǎng)公司的要求。就像我們調(diào)侃公司是給電腦配個(gè)人，這種開發(fā)模式里就是給“研發(fā)流水線”配個(gè)人，從產(chǎn)品、到開發(fā)、到測(cè)試，所有人都像是流水線上的一員。

2、一個(gè)需求的閉環(huán)

以上是需求的研發(fā)流程。如果把一個(gè)需求從產(chǎn)品提出、到上線、到線上數(shù)據(jù)回收……整個(gè)生命周期列出來，將如下圖所示，

這里我整合了幾個(gè)公司的研發(fā)過程。我用顏色分成了幾個(gè)大的流程。相信每個(gè)公司的研發(fā)流程里或多或少都會(huì)包含其中的幾個(gè)。在這個(gè)閉環(huán)里，我說一下我印象比較深刻的幾個(gè)。

2.1 產(chǎn)品流程

大公司做產(chǎn)品一個(gè)顯著的特點(diǎn)是數(shù)據(jù)驅(qū)動(dòng)，一切都拿數(shù)據(jù)說話。一個(gè)需求的提出只是一個(gè)假設(shè)，開發(fā)上線之后效果評(píng)估依賴于數(shù)據(jù)。數(shù)據(jù)來源主要有埋點(diǎn)上報(bào)和輿情監(jiān)控。

1. 數(shù)據(jù)埋點(diǎn)

埋點(diǎn)數(shù)據(jù)不僅用于產(chǎn)品需求的驗(yàn)證，也用于推薦算法的訓(xùn)練。因此，大公司對(duì)數(shù)據(jù)埋點(diǎn)的重視可以說是深入骨髓的。埋點(diǎn)數(shù)據(jù)也經(jīng)常被納入到績效考核里。

開發(fā)埋點(diǎn)大致要經(jīng)過如下流程，

• 1). 產(chǎn)品提出需要埋的點(diǎn)。埋點(diǎn)的類型主要包括曝光和點(diǎn)擊等，此外還附帶一些上報(bào)的參數(shù)，統(tǒng)計(jì)的維度包括用戶 uv 和次數(shù) pv.
• 2). 數(shù)據(jù)設(shè)計(jì)埋點(diǎn)。數(shù)據(jù)拿到產(chǎn)品要埋的點(diǎn)之后，設(shè)計(jì)埋點(diǎn)，并在埋點(diǎn)平臺(tái)錄入。
• 3). 端上開發(fā)埋點(diǎn)。端上包括移動(dòng)客戶端和 Web，當(dāng)然埋點(diǎn)框架也要支持 RN 和 H5.
• 4). 端上驗(yàn)證埋點(diǎn)。端上埋點(diǎn)完成之后需要測(cè)試，上報(bào)埋點(diǎn)，然后再在平臺(tái)做埋點(diǎn)校驗(yàn)。
• 5). 產(chǎn)品提取埋點(diǎn)數(shù)據(jù)。
• 6). 異常埋點(diǎn)數(shù)據(jù)修復(fù)。

由此可見，埋點(diǎn)及其校驗(yàn)對(duì)開發(fā)來說也是需要花費(fèi)精力的一環(huán)。它不僅需要多個(gè)角色參與，還需要一個(gè)大數(shù)據(jù)平臺(tái)，一個(gè)錄入、校驗(yàn)和數(shù)據(jù)提取平臺(tái)，以及端上的上報(bào)框架，可以說成本并不低。

2. 輿情監(jiān)控

老實(shí)說，初次接觸輿情監(jiān)控的時(shí)候，它還是給了我一點(diǎn)小震撼的。沒想到大公司已經(jīng)把輿情監(jiān)控做到了軟件身上。

輿情監(jiān)控就是對(duì)網(wǎng)絡(luò)上關(guān)于該 APP 的輿情的監(jiān)控，數(shù)據(jù)來源不僅包括應(yīng)用內(nèi)、外用戶提交的反饋，還包括主流社交平臺(tái)上關(guān)于該軟件的消息。所有數(shù)據(jù)在整合到輿情平臺(tái)之后會(huì)經(jīng)過大數(shù)據(jù)分析和分類，然后進(jìn)行監(jiān)控。輿情監(jiān)控工具可以做到對(duì)產(chǎn)品的負(fù)面信息預(yù)警，幫助產(chǎn)品經(jīng)理優(yōu)化產(chǎn)品，是產(chǎn)品研發(fā)流程中重要的一環(huán)。

3. AB 實(shí)驗(yàn)

很多同學(xué)可能對(duì) AB 實(shí)驗(yàn)都不陌生。AB 實(shí)驗(yàn)就相當(dāng)于同時(shí)提出多套方案，然后左右手博弈，從中擇優(yōu)錄用。AB 實(shí)驗(yàn)的一個(gè)槽點(diǎn)是，它使得你代碼中同時(shí)存在多份作用相同的代碼，像狗皮膏藥一樣，也不能刪除，非常別扭，最后導(dǎo)致的結(jié)果是代碼堆積如山。

4. 路由體系建設(shè)

路由即組件化開發(fā)中的頁面路由。但是在有些應(yīng)用里，會(huì)通過動(dòng)態(tài)下發(fā)路由協(xié)議支持運(yùn)營場(chǎng)景。這在偏運(yùn)營的應(yīng)用里比較常見，比如頁面的推薦流。一個(gè)推薦流里下發(fā)的模塊可能打開不同的頁面，此時(shí)，只需要為每個(gè)頁面配置一個(gè)路由路徑，然后推薦流里根據(jù)需要下發(fā)即可。所以，路由體系也需要 Android 和 iOS 雙端統(tǒng)一，同時(shí)還要兼容 H5 和 RN.

在路由協(xié)議的定義上，我們可以參考 URL 的格式，定義自己的協(xié)議、域名、路徑以及參數(shù)。以 Android 端為例，可以在一個(gè)方法里根據(jù)路由的協(xié)議、域名對(duì)原生、RN 和 H5 等進(jìn)行統(tǒng)一分發(fā)。

2.2 開發(fā)流程

在開發(fā)側(cè)的流程里，我印象深的有以下幾個(gè)。

1. 重視技術(shù)方案和文檔

我記得之前在一家公司里只文檔平臺(tái)就換了幾個(gè)，足見對(duì)文檔的重視。產(chǎn)品側(cè)當(dāng)然更重文檔，而對(duì)研發(fā)側(cè)，文檔主要有如下幾類：1). 周會(huì)文檔；2).流程和規(guī)范；3).技術(shù)方案；4).復(fù)盤資料等。

對(duì)技術(shù)方案，現(xiàn)在即便我自己做技術(shù)也保留了寫大需求技術(shù)方案先行的習(xí)慣。提前寫技術(shù)方案有幾個(gè)好處：

• 1). 便于事后回憶：當(dāng)我們對(duì)代碼模糊的時(shí)候，可以通過技術(shù)方案快速回憶。
• 2). 便于風(fēng)險(xiǎn)預(yù)知：技術(shù)方案也有助于提前預(yù)知開發(fā)過程中的風(fēng)險(xiǎn)點(diǎn)。前面我們說敏捷開發(fā)提前發(fā)現(xiàn)風(fēng)險(xiǎn)很重要，而做技術(shù)方案就可以做到這點(diǎn)。
• 3). 便于全面思考：技術(shù)方案能幫助我們更全面地思考技術(shù)問題。一上來就寫代碼很容易陷入“只見樹木，不見森林”的困境。

2. Mock 開發(fā)

Mock 開發(fā)也就是基于 Mock 的數(shù)據(jù)進(jìn)行開發(fā)和測(cè)試。在這里它不局限于個(gè)人層面（很多人可能有自己 Mock 數(shù)據(jù)開發(fā)的習(xí)慣），而是在公司層面將其作為一種開發(fā)模式，以實(shí)現(xiàn)前后端分離。典型的場(chǎng)景是客戶端先上線預(yù)埋，而后端開發(fā)可能滯后一段時(shí)間。為了支持 Mock 開發(fā)模式，公司需要專門的平臺(tái)，提供以接口為維度的 Mock 工具。當(dāng)客戶端切換到 Mock 模式之后，上傳到網(wǎng)絡(luò)請(qǐng)求在后端的網(wǎng)關(guān)直接走 Mock 服務(wù)器，拉取 Mock 數(shù)據(jù)而不是真實(shí)數(shù)據(jù)。

這種開發(fā)模式顯然也是為了適應(yīng)敏捷開發(fā)模式而提出的。它可以避免前后端依賴，減輕人力資源協(xié)調(diào)的壓力。這種開發(fā)方式也有其缺點(diǎn)：

• 1). 數(shù)據(jù)結(jié)構(gòu)定義之后無法修改?？蛻舳松暇€之后后端就無法再修改數(shù)據(jù)結(jié)構(gòu)。因此，即便后端不開發(fā)，也需要先投入人力進(jìn)行方案設(shè)計(jì)，定義數(shù)據(jù)結(jié)構(gòu)，并拉客戶端進(jìn)行評(píng)審。
• 2). 缺少真實(shí)數(shù)據(jù)的驗(yàn)證。在傳統(tǒng)的開發(fā)模式中，測(cè)試要經(jīng)過測(cè)試和 UAT 兩個(gè)環(huán)境，而 UAT 本身已經(jīng)比較接近線上環(huán)境，而使用 Mock 開發(fā)就完全做不到這么嚴(yán)謹(jǐn)。當(dāng)我們使用 Mock 數(shù)據(jù)測(cè)試時(shí)，如果我們自己的 Mock 的數(shù)據(jù)本身失真比較嚴(yán)重，那么在意識(shí)上你也不會(huì)在意數(shù)據(jù)的合理性，因此容易忽視一些潛在的問題。

3. 灰度和熱修復(fù)

灰度的機(jī)制是，在用戶群體中選擇部分用戶進(jìn)行應(yīng)用更新提示的推送。這要求應(yīng)用本身支持自動(dòng)更新，同時(shí)需要對(duì)推送的達(dá)到率、用戶的更新率進(jìn)行統(tǒng)計(jì)。需要前后端一套機(jī)制配合?；叶扔兄谔崆鞍l(fā)現(xiàn)應(yīng)用中存在的問題，這對(duì)超大型應(yīng)用非常有幫助，畢竟，現(xiàn)在上架之后發(fā)現(xiàn)問題再修復(fù)的成本非常高。

但如果上架之后確實(shí)出現(xiàn)了問題就需要走熱修復(fù)流程。熱修復(fù)的難點(diǎn)在于熱修復(fù)包的下發(fā)，同時(shí)還需要審核流程，因此需要搭建一個(gè)平臺(tái)。這里涉及的細(xì)節(jié)比較多，后面有時(shí)間再梳理吧。

4. 配置下發(fā)

配置下發(fā)就是通過平臺(tái)錄入配置，推送，然后在客戶端讀取配置信息。這也是應(yīng)用非常靈活的一個(gè)功能，可以用來下發(fā)比如固定的圖片、文案等。我之前做個(gè)人開發(fā)的時(shí)候也在服務(wù)器上做了配置下發(fā)的功能，主要用來繞過某些應(yīng)用商店的審核，但是在數(shù)據(jù)結(jié)構(gòu)的抽象上做得比較隨意。這里梳理下配置下發(fā)的細(xì)節(jié)。

• 首先，下發(fā)的配置是區(qū)分平臺(tái)特征的。這包括，應(yīng)用的目標(biāo)版本（一個(gè)范圍）、目標(biāo)平臺(tái)（Android、iOS、Web、H5 或者 RN）。
• 其次，為了適應(yīng)組件化開發(fā)，也為了更好地分組管理，下發(fā)的配置命名時(shí)采用 模塊#配置名稱 的形式。
• 最后，下發(fā)的數(shù)據(jù)結(jié)構(gòu)支持，整型、布爾類型、浮點(diǎn)數(shù)、字符串和 Json.

我自己在做配置下發(fā)的時(shí)候還遇到一個(gè)比較棘手的問題——多語言適配。國內(nèi)公司的產(chǎn)品一般只支持中文，這方面就省事得多。

5. 復(fù)盤文化

對(duì)于敏捷開發(fā)，復(fù)盤是不可或缺的一環(huán)。有助于及時(shí)發(fā)現(xiàn)問題，糾正和解決問題。復(fù)盤的時(shí)間可以是定期的，在一個(gè)大需求上線之后，或者出現(xiàn)線上問題之后。

3、技術(shù)特點(diǎn)

3.1 組件化開發(fā)的痛點(diǎn)

在大型應(yīng)用開發(fā)過程中，組件化開發(fā)的意義不僅局限于代碼結(jié)構(gòu)層面。組件化的作用體現(xiàn)在以下幾個(gè)層面：

• 1). 團(tuán)隊(duì)配合的利器。想想幾十個(gè)人往同一份代碼倉庫里提交代碼的場(chǎng)景。組件化可以避免無意義的代碼沖突。
• 2). 提高編譯效率。對(duì)于大型應(yīng)用，全源碼編譯一次的時(shí)間可能要幾十分鐘。將組件打包成 aar 之后可以減少需要編譯的代碼的數(shù)量，提升編譯效率。
• 3). 適應(yīng)組織架構(gòu)。將代碼細(xì)分為各個(gè)組件，每個(gè)小團(tuán)隊(duì)只維護(hù)自己的組件，更方便代碼權(quán)限劃分。

那么，在實(shí)際開發(fā)過程中組件化開發(fā)會(huì)存在哪些問題呢？

1. 組件拆分不合理

這在從單體開發(fā)過渡到組件化開發(fā)的應(yīng)用比較常見，即組件化拆分之后仍然存在某些模塊彼此共用，導(dǎo)致提交代碼的時(shí)候仍然會(huì)出現(xiàn)沖突問題。沖突包含兩個(gè)層面的含義，一是代碼文件的 Git 沖突，二是在打包合入過程中發(fā)布的 aar 版本沖突。比較常見的是，a 同學(xué)合入了代碼到主干之后，b 同學(xué)沒有合并主干到自己的分支就打包，導(dǎo)致發(fā)布的 aar 沒有包含最新的代碼。這涉及打包的問題，是另一個(gè)痛點(diǎn)問題，后面再總結(jié)。

單就拆分問題來看，避免上述沖突的一個(gè)解決辦法是在拆分組件過程中盡可能解耦。根據(jù)我之前的觀察，存在沖突的組件主要是數(shù)據(jù)結(jié)構(gòu)和 SPI 接口。這是我之前公司沒做好的地方——數(shù)據(jù)結(jié)構(gòu)倉庫和 SPI 接口是共用的。對(duì)于它們的組件化拆分，我待過的另一家公司做得更好。他們是如下拆分的，這里以 A 和 B 來命名兩個(gè)業(yè)務(wù)模塊。那么，在拆分的時(shí)候做如下處理，

模塊：A-api
模塊：A
模塊：B-api
模塊：B

即每個(gè)業(yè)務(wù)模塊拆分成 api 和實(shí)現(xiàn)兩部分。api 模塊里包含需要共享的數(shù)據(jù)結(jié)構(gòu)和 SPI 接口，實(shí)現(xiàn)模塊里是接口的具體實(shí)現(xiàn)。當(dāng)模塊 A 需要和模塊 B 進(jìn)行交互的時(shí)候，只需要依賴 B 的 api 模塊?？梢詤⒖奸_源項(xiàng)目：arch-android.

2. 打包合入的痛點(diǎn)

上面我們提到了一種沖突的情況。在我之前的公司里，每個(gè)組件有明確的負(fù)責(zé)人，在每個(gè)迭代開發(fā)的時(shí)候，組件負(fù)責(zé)人負(fù)責(zé)拉最新 release 分支。其他同學(xué)在該分支的開發(fā)需要經(jīng)過負(fù)責(zé)人同意再合入到該分支。那么在最終打包的過程中，只需要保證這個(gè)分支的 aar 包含了全部最新的代碼即可。也就是說，這種打包方式只關(guān)心每個(gè) aar 的版本，而不關(guān)心實(shí)際的代碼。因?yàn)樗罱K打包是基于 aar 而不是全源碼編譯。

這種打包方式存在最新的分支代碼沒有被打包的風(fēng)險(xiǎn)。一種可行的規(guī)避方法是，在平臺(tái)通過 Git tag 和 commit 判斷該分支是否已經(jīng)包含最新代碼。此外，還可能存在某個(gè)模塊修改了 SPI 接口，而另一個(gè)模塊沒有更新，導(dǎo)致運(yùn)行時(shí)異常的風(fēng)險(xiǎn)。

另一個(gè)公司是基于全源碼編譯的。不過，全源碼編譯只在最終打包階段或者某個(gè)固定的時(shí)間點(diǎn)進(jìn)行，而不是每次合入都全源碼編譯（一次耗時(shí)太久）。同時(shí)，雖然每個(gè)模塊有明確的負(fù)責(zé)人，但是打包的 aar 不是基于當(dāng)前 release 分支，而是自己的開發(fā)分支。這是為了保障當(dāng)前 release 分支始終是可用的。合并代碼到 release 分支的同時(shí)需要更新 aar 的版本。但它也存在問題，如果合并到 release 而沒有打包 aar，那么可能導(dǎo)致 release 分支無法使用。如果打包了 aar 但是此時(shí)其他同學(xué)也打包了 aar，則可能導(dǎo)致本次打包的 aar 落后，需要重新打包。因此，這種合入方式也是苦不堪言。

有一種方法可以避免上述問題，即將打包和合入事件設(shè)計(jì)成一個(gè)消息隊(duì)列。每次合入之前自動(dòng)化執(zhí)行上述操作，那么自然就可以保證每次操作的原子性（因?yàn)楸旧砭褪菃尉€程的）。

對(duì)比兩種打包和合入流程，顯然第二種方式更靠譜。不過，它需要設(shè)計(jì)一個(gè)流程。這需要花費(fèi)一點(diǎn)功夫。

3. 自動(dòng)化切源碼

我在之前的一家公司開發(fā)時(shí)，在開發(fā)過程中需要引用另一個(gè)模塊的修改時(shí)，需要對(duì)另一個(gè)模塊打 SNAPSHOT 包。這可行，但有些麻煩。之前我也嘗試過手動(dòng)修改 settings.gradle 文件進(jìn)行源碼依賴開發(fā)。不過，太麻煩了。

后來在另一個(gè)公司里看到一個(gè)方案，即動(dòng)態(tài)切換到源碼開發(fā)?？梢詫⒛硞€(gè)依賴替換為源碼而只需要修改腳本即可。這個(gè)實(shí)踐很棒，我已經(jīng)把它應(yīng)用到獨(dú)立開發(fā)中。之前已經(jīng)梳理過《組件化開發(fā)必備：Gradle 依賴切換源碼的實(shí)踐》.

3.2 大前端化開發(fā)

1. React Native

如今的就業(yè)環(huán)境，哪個(gè) Android 開發(fā)不是同時(shí)會(huì)五六門手藝。跨平臺(tái)開發(fā)幾乎是不可避免的。

之前的公司為什么選擇 React Native 而不是 Flutter 等新銳跨平臺(tái)技術(shù)呢？我當(dāng)時(shí)還刻意問了這個(gè)問題。主要原因：

• 1). 首先是 React Native 相對(duì)更加成熟，畢竟我看了下 Github 第一個(gè)版本發(fā)布已經(jīng)是 9 年前的事情了，并且至今依舊非?；钴S。
• 2). React Native 最近更新了 JavaScript 引擎，頁面啟動(dòng)時(shí)間、包大小和內(nèi)存占用性能都有顯著提升。參考這篇文章《干貨 | 加載速度提升15%，攜程對(duì)RN新一代JS引擎Hermes的調(diào)研》.
• 3). 從團(tuán)隊(duì)人才配置上，對(duì) React Native 熟悉的更多。

React Native 開發(fā)是另一個(gè)領(lǐng)域的東西，不在本文討論范圍內(nèi)。每個(gè)公司選擇 React Native 可能有它的目的。比如，我之前的一家公司存粹是為了提效，即一次開發(fā)雙端運(yùn)行。而另一家公司，則是為了兼顧提效和動(dòng)態(tài)化。如果只為提效，那么本地編譯和打包 js bundle 就可以滿足需求。若要追求動(dòng)態(tài)化，就需要搭建一個(gè) RN 包下發(fā)平臺(tái)。實(shí)際上，在這個(gè)公司開發(fā) RN 的整個(gè)流程，除了編碼環(huán)節(jié)，從代碼 clone 到最終發(fā)布都是在平臺(tái)上執(zhí)行的。平臺(tái)搭建涉及的細(xì)節(jié)比較多，以后用到再總結(jié)。對(duì)于端側(cè)，RN 的動(dòng)態(tài)化依賴本地路由以及 RN 容器。

2. BFF + DSL

DSL 是一種 UI 動(dòng)態(tài)下發(fā)的方案。相比于 React Native，DSL 下發(fā)的維度更細(xì)，是控件級(jí)別的（而 RN 是頁面級(jí)別的）。簡(jiǎn)單的理解是，客戶端和后端約定 UI 格式，然后按照預(yù)定的格式下發(fā)的數(shù)據(jù)?？蛻舳双@取到數(shù)據(jù)之后渲染。DSL 不適合需要復(fù)雜動(dòng)畫的場(chǎng)景。若確實(shí)要復(fù)雜動(dòng)畫，則需要自定義控件。

工作流程如下圖中左側(cè)部分所示，右側(cè)部分是每個(gè)角色的責(zé)任。

客戶端將當(dāng)前頁面和位置信息傳給 DSL 服務(wù)器。服務(wù)器根據(jù)上傳的信息和位置信息找到業(yè)務(wù)接口，調(diào)用業(yè)務(wù)接口拉取數(shù)據(jù)。獲取到數(shù)據(jù)后根據(jù)開發(fā)過程中配置的腳本對(duì)數(shù)據(jù)進(jìn)行處理。數(shù)據(jù)處理完成之后再交給 DSL 服務(wù)器渲染。渲染完成之后將數(shù)據(jù)下發(fā)給客戶端?？蛻舳嗽俑鶕?jù)下發(fā)的 UI 信息進(jìn)行渲染。其中接口數(shù)據(jù)的處理是通過 BFF 實(shí)現(xiàn)的，由客戶端通過編寫 Groovy 腳本實(shí)現(xiàn)數(shù)據(jù)結(jié)構(gòu)的轉(zhuǎn)換。

這種工作流程中，大部分邏輯在客戶端這邊，需要預(yù)埋點(diǎn)位信息。預(yù)埋之后可以根據(jù)需求進(jìn)行下發(fā)。這種開發(fā)的一個(gè)痛點(diǎn)在于調(diào)試成本高。因?yàn)?DSL 服務(wù)器是一個(gè)黑盒調(diào)用。中間需要配置的信息過多，搭建 UI 和編寫腳本的平臺(tái)分散，出現(xiàn)問題不易排查。

總結(jié)

所謂他山之石，可以攻玉。在這篇文章中，我只是選取了幾個(gè)自己印象深刻的技術(shù)點(diǎn)，零零碎碎地寫了很多，比較散。對(duì)于有這方面需求的人，會(huì)有借鑒意義。

如果你看到了這里，覺得文章寫得不錯(cuò)就給個(gè)贊唄？
更多Android進(jìn)階指南 可以掃碼 解鎖更多Android進(jìn)階資料

1、《Android性能優(yōu)化實(shí)戰(zhàn)篇》
2、《音視頻精編源碼解析》
3、24種設(shè)計(jì)模式介紹與6大設(shè)計(jì)原則
4、360°全方面性能調(diào)優(yōu)
5、2021最新版數(shù)據(jù)結(jié)構(gòu)與算法面試題手冊(cè) 1
6、2023年Android中高級(jí)最全面試真題答案解析
7、Android Compose 強(qiáng)化實(shí)戰(zhàn)
8、Android Framework 源碼開發(fā)揭秘(2)
9、Android Jetpack Compose開發(fā)應(yīng)用指南第三版
10、Android 音視頻開發(fā)進(jìn)階指南-無水印(1)
11、Android車載操作系統(tǒng)開發(fā)揭秘
12、Android車載系統(tǒng)應(yīng)用指南(1)
13、Android多媒體應(yīng)用開發(fā)實(shí)戰(zhàn)詳解：圖像、音頻、視頻、2D和3D-2
14、Android高級(jí)UI開源框架進(jìn)階解密(1)無水印版
15、Android源碼解析(1)
16、Flutter技術(shù)解析與實(shí)戰(zhàn)
17、Flutter技術(shù)進(jìn)階
18、Flutter入門與實(shí)戰(zhàn) 無水印
19、Flutter完整開發(fā)實(shí)戰(zhàn)詳解
20、Jetpack架構(gòu)組件從入門到精通
21、KMM跨平臺(tái)框架入門教程無水印
22、Kotlin 入門教程指南(1)
23、kotlin從入門到精通
24、高級(jí)Android插件化強(qiáng)化實(shí)戰(zhàn)（附源碼）
25、高級(jí)Android組件化強(qiáng)化實(shí)戰(zhàn)（附源碼）
26、高級(jí)Jetpack強(qiáng)化實(shí)戰(zhàn)
27、高級(jí)Kotlin強(qiáng)化實(shí)戰(zhàn)（附Demo）
28、鴻蒙零基礎(chǔ)入門學(xué)習(xí)指南
29、史上最詳android版kotlin協(xié)程入門進(jìn)階實(shí)戰(zhàn)指南
30、音視頻開發(fā)教程(附面試題)
敲代碼不易，關(guān)注一下吧。?( ′･?･` )