JSPatch 被禁?你的APP需要另一種發布模式!

灰度發布

讓iOS開發群炸鍋的消息

今天一大早看各個iOS開發群炸鍋了,原來是蘋果大佬禁止了熱更新和JSpatch。導致很多人的項目上線和更新被拒,目前還沒有解決方案。Apple官方警告如下:

app灰度發布

影響廣泛,各路英雄一臉懵逼

13

什么是JSPatch?為什么人多開發者樂此不疲?

JSPatch 是一個 iOS 動態更新框架,只需在項目中引入極小的引擎,就可以使用 JavaScript 調用任何 Objective-C 原生接口,獲得腳本語言的優勢:為項目動態添加模塊,或替換項目原生代碼動態修復 bug。

APPLE為什么要這么做?

踐行自己生態圈大管家的角色,iOS 社區早就有不允許動態更新的條例,只不過一直睜一只眼,閉一只眼罷了,誰知開發者視蘋果爸爸為無物,蹬鼻子上臉,竟然演進除了JS Patch 和 React Native的黑科技。終于暴露出了大問題,去年的關于iOS漏洞的報道:

ab測試
可見,黑客正事利用了熱更新框架的漏洞,攻擊證書發行商,進而獲取臨時證書,終于蘋果爸爸生氣了。說到這里,真替 react native 捏把汗…
針對修復bug,動態發布模塊的強需求,硅谷FLAG的最佳實踐是什么?

 

以Facebook 為例,Facebook的David Wei寫了一篇文章《代碼和產品發布的幾種方式》明確分析了下幾個概念:

 

1、灰度發布:也可以稱為分步代碼發布,是一種代碼發布的方式。基本操作是整個團隊共用一個代碼庫,一定頻率(比如每天一次,或者每周一次)把整個代碼的最新版本做一個新的發布分支(release branch),把發布分支逐步發布到產品線。

2、AB測試:這是一種很成熟的概念,是產品發布的常用手段。比起分步代碼發布,AB測試往往有更長的周期(比如幾個星期甚至幾個月)。基本操作是產品的開發者加一個或者多個配置控制(一般每個產品配置應該帶有配置的ID),允許通過調節相應的配置來讓一個產品發布到“逐步選擇”的用戶群。

 

覃超大魔王介紹過Facebook使用的一大法寶就是灰度發布和 A/B測試。這一利器像宙斯盾一樣(想不出更好的比喻),多次將Facebook從出錯的懸崖上拉回來。

 

Facebook早在2007-2008年就在網頁服務端(PHP)上開發了這套發布和測試系統,代號叫 GateKeeper (最早在Boz的文章中提到),本質上它就是一個開關,可以在一個admin page上定義一個個的開關,然后控制某些開關到底是開還是關。這些開關的屬性預先都緩存在內存中,所以讀取開關的操作不重。示例代碼如下:

15

主要的邏輯就在 if 中,判斷這個開關是否對相應的用戶開啟,如果是則跑實驗代碼,否則跑老代碼。非常直接和簡單對吧!后來,Facebook又陸陸續續對它進行了各種加強,讓其可以更加精細地分割和控制用戶,比如說 對于US的1%用戶開放,或者對于日本的年齡25歲以下的男性用戶開放等等。可以從時間,國家,加入日期,好友數,是否為FB員工,性別,年齡等等各種維度進行控制。

16

這極大方便了我們對于用戶分批進行 A/B測試

 

Gatekeeper(簡稱GK)對于Facebook的整個internal tools組來說一個很重要的基礎設施。隨著Facebook用戶量的增大,每個GK每日的被訪問量也大大增加;同時Facebook自己的功能和相應的GK項也不斷增加, 這對于整個GK的規模能力后來也提出了很大的挑戰。

 

到了移動時代后,iOS和Android的 core team 也相應地推出了比較強大的移動灰度發布和 A/B測試 工具,代號叫做 Airlock ,其中我們的一位中國工程師也參與它的開發。當然,類似的工具還有不少,比如 Twitter 開源的 Clutch IO 。移動上的 Airlock 系統稍微復雜一點:

 

首先,用戶在手機上登錄或者打開Facebook App后,airlock會從FB server取得所有的GK值;然后在本地緩存起來;
然后在 iOS 或者 Android 代碼里寫相同 if 判斷邏輯,來檢查當前用戶是否已經開啟這個屬性。是的話,跑試驗代碼,否則跑老代碼;

 

然后App每隔一段時間去和server同步一次(FB用的是一個小時的間隔);當然App隨時也可以強制去取server上的最新值。

 

最關鍵的是:移動端的logging會把當前用戶的每個GK的值記錄在logging中,這樣當這些logs被上傳到server后, server可以根據這些logs來統計用戶的GK值和相應的動作。

 

Facebook 每次更新App大小都將近200M,產品Roadmap中近期可能上線發布的功能都已經打包在其中,同時在本地代碼加入一個庫,來負責和server同步所有開關的值,以及在logs里記錄好相應的這些開關,便于后來分析用戶的行為,來了解此用戶是暴露在怎樣的開關組合中。

 

下面來看個案例:

Facebook iOS App的演化

下面來說一下iOS下面的Facebook App界面演化過程。眾所周知,Zuck 和 Steve Jobs 的私交一直不錯,Zuck 也把喬幫主當做自己的模樣,私下里經常去喬老爺家里共進晚餐和請教 run company 的竅門。所以,用 iPhone 第一版SDK開始,Facebook就有iOS原生應用開始入駐App Store:

app ab測試

可以看到iOS還是擬物化的風格,Facebook用的是當年紅極一時的九宮格首頁。消息提示在首頁的最下面,當時Facebook還沒有 Like button,只可以comment。此版本的Facebook App為最初一版,由一大牛獨自完成。此大牛把后來的常用組件開源成 Three20 庫。

 

后來Facebook經過一次大的UI改變:

18

最大的變化就是九宮格改為了左側抽屜式的導航欄,左上角出現著名的”Hanburger”按鈕。
于是來到2013年,Facebook App準備進行新一輪的大改版,由左側抽屜式改為 Tab bar 格式:

19

這一版的改動,在意義上主要是讓用戶可以更加方便切換到news feed以外的其他功能區;可是卻引發了另外一個問題:到底下面的tab bar放幾個按鈕?每一個位置上應該放什么?

110

此時已經是2013年,前一年在Facebook在WWW首頁的改版失敗依然影響著公司的engineering team,于是在iOS App決定更偏好保守和務實。Airlock在這次的改版上起到巨大的作用。Facebook iOS core team的人寫好了tab bar的代碼后,并沒有馬上發布給所有用戶,而是開始了長達4個月的灰度發布和A/B測試。

 

測試了下面 tab bar 各種可能的情況:比如 5個tab項 或者 4個? 第二個放 Requests or Messages? Notifications 或者 Groups 暴露在外面? 同時對于右上角的按鈕的功能和樣式也進行了測試,比如是放 通訊錄 還是 Messages? 是放一個圖標還是直接寫字?等等。

 

一度因為出現新的測試組合,以及對于好幾個組合的測試結果在數據上的比較模棱兩可而把發布時間一拖再拖。整個iOS App界面重組的項目由 Mick Johnson 主導,他是我見過執行力最強的Facebook的幾個PM之一。他認真審視了各種組合的數據后,結合Facebook當時要大力推行Messenger的大背景,最后確定上圖的組合順序。這個組合在各種測試中數據的綜合表現最好,能夠有效地讓用戶查看news feed,增加用戶的好友數(好友數是從Facebook data組里試驗出來的一個非常重要的指標,這在文章最后可以和大家介紹),方便地收發消息,以及查看新消息,但是 groups,events,還有其他一些輔助功能被藏入了 “more” 之中。

 

綜合來看,灰度發布 (shadow release) 和 A/B測試的特點和注意事項:

前端代碼預先發布;且有可能同時多套不同版本的代碼存在;

移動端或者前端MVC的代碼需要按照一定頻率獲取來自服務器的控制信息,從而展示相應的形態;

后臺可以對發布進行精密的控制。

 

比如說:發布給多少比例的用戶,用戶所在區域等;并且即使在開放給100%用戶后,只要 GK檢查 沒有清楚,則server仍然可以遠程控制(或回滾)試驗中的功能。在某些嚴重bug出現的情況下,可以完全回滾某一功能。

 

注意:由于有A/B測試的原因,不同用戶A和B坐在一起,都剛剛下載和安裝了最新的Facebook App,但是打開App后所看到的功能(甚至UI布局)卻可能不一樣;并且對于同一用戶,今天看到的App里展示的功能可能和明天展示的也不一樣,即使他并沒有更新自己的App。
蘋果爸爸已經放大招了,如果你可以搞定灰度發布的話,恭喜你!繼續瀟灑吧!如果搞不定的話,也許吆喝科技的解決方案可以幫到你。

15469 Views
即刻實踐文章理論 A/B測試 灰度發布 產品優化 免費申請
Please wait...

訂閱我們

對于每位訂閱讀者,每兩周,吆喝科技會為您發送4篇精選文章,可能是最新的A/B測試實踐,也會是你所期待的增長干貨。
qq宠物捕鱼大师 广东广东快乐十分 捕鱼达人老k版游戏大厅手机版 安徽时时视频直播 山西快乐十分前三走势 500万彩票安卓版 手机游戏下载网站 赛马会net 河北时时号码走势图表大全 秒速飞艇规则 吉林快三开奖