關於CodePush在iOS端的簡易使用可以看我這篇,覺得不錯的話可以點個贊或關注。
React Native模組--CodePush
注意:本自述檔案僅與我們外掛的最新版本相關。 如果您使用的是舊版本,請切換到我們的GitHub倉庫中的相關標籤,以檢視該特定版本的文件。
此外掛為CodePush服務提供客戶端整合,允許您輕鬆地向React Native應用程式新增動態更新體驗。
它是如何工作的?
React Native
應用程式由JavaScript
檔案和任何附帶影象組成,這些影象由打包程式捆綁在一起並作為特定於平臺的二進位制檔案(即.ipa
或.apk
檔案)的一部分進行分發。應用程式釋出後,更新JavaScript
程式碼(例如修復錯誤,新增新功能)或影象資源,需要您重新編譯和重新分發整個二進位制檔案,當然,也包括相關商店的稽核時間。
CodePush
外掛通過保持你的JavaScript
和images
與釋出到CodePush
伺服器的更新同步,使得使用者可以立即獲得改進後的產品。通過這種方式,您的應用可以獲得離線移動體驗的好處,以及一旦可用,就可以獲得側面載入更新的“類網路”的敏捷性。這是雙贏的!
為了確保您的終端使用者始終擁有應用程式的正常版本,CodePush
外掛會維護以前更新的副本,以便在您意外推送包含崩潰的更新時,它可以自動回滾。這樣,您可以放心,在您有機會回滾伺服器版本之前,您釋出的新版本不會影響到使用者。這是一個雙贏的局面!
注意:任何與本機程式碼相關的產品更改(例如,修改AppDelegate.m / MainActivity.java
檔案,新增新外掛)都無法通過CodePush
分發,因此必須通過相應的商店進行更新。
入門
根據 "getting started" 設定你的CodePush帳戶,在應用程式的根目錄中執行以下命令,即可在你的React Native
應用程式中使用CodePush-ifying
。
npm install --save react-native-code-push
複製程式碼
與所有其他React Native外掛一樣,iOS和Android的整合體驗也不同,因此請根據您要定位的平臺執行以下設定步驟。 請注意,如果您要定位兩個平臺,建議為每個平臺建立單獨的CodePush應用程式。
如果您想了解其他專案如何與CodePush整合,您可以檢視社群提供的優秀示例應用程式。 此外,如果您想快速熟悉CodePush + React Native
,您可以檢視由Bilal Budhani和/或Deepak Sisodiya製作的精彩入門視訊。
注意:本指南假定您已使用react-native init
命令初始化React Native
專案。 截至2017年3月,命令create-react-native-app
也可用於初始化React Native
專案。 如果使用此命令,請在專案的主目錄中執行npm run eject
,以獲得與react-native init
建立的專案非常相似的專案。
接下來繼續安裝原生模組
外掛使用
下載和連結CodePush外掛,並從CodePush獲取到正確的JS捆綁包後,接下來唯一要做的事就是向你的應用新增必要的程式碼,以控制以下流程:
- 何時(以及多久)檢查一次更新?(例如,在App啟動後,以某個固定時間間隔,定期地響應設定頁面按鈕的點選)
- 當有更新時,如何將其呈現給使用者?
最簡單的方法是使用“CodePush-ify”應用程式的根元件。 為此,您可以選擇以下兩個方法中的一個:
-
方法1:使用
codePush
高階元件包裹您的根元件:import codePush from "react-native-code-push"; class MyApp extends Component { } MyApp = codePush(MyApp); 複製程式碼
-
方法2:使用ES7裝飾器語法:
注意:Babel 6.x待定提案更新尚不支援ES7裝飾器語法。 您可能需要通過安裝和使用babel-preset-react-native-stage-0來啟用它。
import codePush from "react-native-code-push"; @codePush class MyApp extends Component { } 複製程式碼
預設情況下,CodePush
將檢查每個應用程式啟動時的更新。 如果有可用的更新,它將以靜默方式下載,並在下次重新啟動應用程式時安裝(由終端使用者或作業系統明確安裝),這可確保使用者體驗。 如果必需更新,則會立即安裝,確保使用者儘快獲得最新版本。
如果您希望應用程式更快地發現更新,您還可以選擇在每次應用程式從後臺恢復時與CodePush
伺服器同步。
let codePushOptions = { checkFrequency: codePush.CheckFrequency.ON_APP_RESUME };
class MyApp extends Component {
}
MyApp = codePush(codePushOptions)(MyApp);
複製程式碼
或者,如果您希望對檢查發生的時間進行細粒度控制(例如按下按鈕或定時器間隔),您可以隨時使用所需的SyncOptions
呼叫CodePush.sync()
,也可以選擇通過指定一個手動檢查頻率(checkFrequency:
)來關閉CodePush
的自動檢查。
let codePushOptions = { checkFrequency: codePush.CheckFrequency.MANUAL };
class MyApp extends Component {
onButtonPress() {
codePush.sync({
updateDialog: true,
installMode: codePush.InstallMode.IMMEDIATE
});
}
render() {
return (
<View>
<TouchableOpacity onPress={this.onButtonPress}>
<Text>Check for updates</Text>
</TouchableOpacity>
</View>
)
}
}
MyApp = codePush(codePushOptions)(MyApp);
複製程式碼
如果想要顯示確認更新的對話方塊(立即安裝),請在安裝可用更新時進行配置(例如強制立即重啟)或以任何其他方式自定義更新體驗,請參閱codePush()API參考有關如何調整此預設行為的資訊。
注意:如果您使用的是Redux和Redux Saga,您也可以使用react-native-code-push-saga模組,該模組允許您以更簡單/更慣用的方式自定義何時呼叫同步。
商店指南的合規性
雖然Google Play
和內部分散式應用程式(例如Enterprise
,Fabric
,HockeyApp
)對如何使用CodePush
釋出更新沒有任何限制,但在應用程式中整合解決方案之前,您應該注意iOS App Store
及其相應指南中的細緻規則。
第3.3.2段,自2015年以來,Apple
開發者計劃許可協議完全允許對JavaScript
和assets
進行無線更新 - 在最新版本(20170605)中,這一規則更為廣泛:
解釋執行的程式碼可以下載到應用程式,但只有符合以下規則程式碼:
(a)
不會通過提供與提交給App Store
的應用程式的預期和廣告目的不一致的特性或功能來改變應用程式的主要目的。(b)
不為其他程式碼或應用程式建立商店或店面。(c)
不繞過作業系統的簽名,沙箱或其他安全功能。
CodePush
允許您完全遵從這些規則,只要您推送的更新不會使您的產品與提交App Store
稽核時的功能明顯不同。
為了進一步遵守Apple的指導原則,我們建議App Store
分發的應用程式在呼叫sync
時不啟用updateDialog
選項,因為在App Store Review Guidelines中,它寫道:
Apps must not force users to rate the app, review the app, download other apps, or other similar actions in order to access functionality, content, or use of the app.
這不一定是updateDialog的問題,因為它不會強迫使用者下載新版本,但如果你決定要顯示更新,那麼至少你應該知道這些規則。
釋出更新
一旦您的應用程式配置並分發給您的使用者,並且您已經進行了一些JS
和/或assets
更改,就可以立即釋出它們了! 最簡單(和推薦)的方法是在CodePush CLI
中使用release-react
命令,它將處理並捆綁您的JavaScript
和assets
檔案並將更新發布到CodePush
伺服器。
在它最基本的形式中,此命令只需要兩個引數:您的應用程式名稱和要捆綁更新的平臺(ios
或android
)。
code-push release-react <appName> <platform>
code-push release-react MyApp-iOS ios
code-push release-react MyApp-Android android
複製程式碼
release-react
命令啟用了這樣一個簡單的工作流,因為它提供了許多合理的預設值(例如,生成一個釋出包,假設您的應用程式在iOS
上的條目檔案是index.ios.js
或index.js
)。但是,所有這些預設值都可以自定義,以便在必要時提供增量靈活性,這使其非常適合大多數情況。
# Release a mandatory update with a changelog
code-push release-react MyApp-iOS ios -m --description "Modified the header color"
# Release an update for an app that uses a non-standard entry file name, and also capture
# the sourcemap file generated by react-native bundle
code-push release-react MyApp-iOS ios --entryFile MyApp.js --sourcemapOutput ../maps/MyApp.map
# Release a dev Android build to just 1/4 of your end users
code-push release-react MyApp-Android android --rollout 25% --dev true
# Release an update that targets users running any 1.1.* binary, as opposed to
# limiting the update to exact version name in the build.gradle file
code-push release-react MyApp-Android android --targetBinaryVersion "~1.1.0"
複製程式碼
CodePush
客戶端支援差異更新,因此即使您在每次更新時釋出JS
包和assets
,您的終端使用者也只會下載實際所需的檔案。該服務自動處理此問題,以便您可以專注於建立真棒應用程式,我們負責優化使用者的下載。
有關release-react
命令如何工作的更多詳細資訊,以及它公開的各種引數,請參閱CLI文件。 此外,如果您更願意自己處理react-native bundle
命令,因此需要比release-react
更靈活的解決方案,請參閱release命令以獲取更多詳細資訊。
如果您遇到任何問題,或有任何問題/意見/反饋,您可以在Reactiflux
上的#code-push頻道中ping我們,傳送電子郵件給我們和/或檢視下面的故障排除詳情。
注意:CodePush
更新應在除錯模式以外的模式下進行測試。 在除錯模式下,React Native
應用程式總是下載由packager
生成的JS
包,因此CodePush
下載的JS
包不適用。
多部署 測試
在我們的入門文件中,我們說明了如何使用特定的部署金鑰配置CodePush
外掛。 但是,為了有效地測試您的版本,您必須利用首次建立CodePush
應用程式時(或您可能已建立的任何自定義部署)自動生成的暫存(Staging)
和生產部署(Production)
。 這樣,您在驗證更新功能的時候就不會對真實使用者進行釋出操作。
注意:我們的客戶端回滾功能可以使已安裝奔潰版本的使用者進行版本回滾,並且伺服器端回滾(即程式碼推送回滾
)允許您阻止其他使用者在識別後安裝錯誤版本。 但是,如果您可以防止錯誤的更新發布,那麼顯然會更好。
利用階段(Staging)
和生產部署(Production)
,您可以實現以下工作流程(隨意自定義!):
- 使用
code-push release-react
命令(或程式碼推送版本,如果您需要更多控制)向您的Staging部署
釋出CodePush更新
- 執行應用程式的臨時/測試版本,從伺服器同步更新,並驗證它是否按預期工作
- 使用
code-push promote
命令將測試版本從Staging
升級到Production
- 執行應用程式的生產/釋出版本,從伺服器同步更新並驗證它是否按預期工作
*注意:只要你想,您甚至可以選擇執行“分階段部署”作為#3的一部分,這可以讓您通過更新降低額外的潛在風險(例如,您在#2中的測試是否觸控了所有可能的裝置 /條件?)只對一部分使用者提供生產更新(例如: code-push promote <APP_NAME> Staging Production -r 20%
)。 然後,在等待一段合理的時間來檢視是否有任何崩潰報告或客戶反饋後,您可以通過code-push patch <APP_NAME> Production -r 100%
將其擴充套件到整個受眾。*
您會注意到上述步驟涉及應用程式的“階段構建”
和“生產構建”
。 如果您的構建過程已經為每個“環境”生成了不同的二進位制檔案,那麼您不需要再進行任何閱讀,因為更換CodePush部署金鑰就像處理應用程式使用其他服務(例如Facebook)的特定於環境的配置一樣。 但是,如果您正在尋找有關如何設定構建過程以適應此目的的示例(包括演示專案),請參閱以下部分,具體取決於您的應用所針對的平臺:
動態部署分配
上一節說明了如何利用多個CodePush
部署,以便在更新發布給使用者之前,有效地測試您的更新內容。 但是,由於該工作流靜態地將部署分配嵌入到實際二進位制檔案中,因此臨時構建
和生產構建
只會同步該部署的更新內容。在許多情況下,這是足夠的,因為您只希望您的團隊,客戶,利益相關者等與您的預生產版本同步,因此,他們只需要知道如何與該版本同步構建。但是,如果您希望能夠進行A / B測試,或者為某些使用者提供應用程式的早期訪問許可權,那麼能夠在執行時將特定使用者(或受眾)動態地置於特定部署中將非常有用。
為了實現這種工作流,您需要做的就是在呼叫codePush
方法時指定特定使用者同步的部署金鑰。 指定後,此鍵將覆蓋應用程式的Info.plist(iOS)
或MainActivity.java(Android)
檔案中提供的預設鍵。 這允許您生成臨時或生產構建,也可以根據需要動態“重定向”。
// Imagine that "userProfile" is a prop that this component received
// which includes the deployment key that the current user should use.
codePush.sync({ deploymentKey: userProfile.CODEPUSH_KEY });
複製程式碼
有了這樣的變化後,現在只需選擇應用程式如何為當前使用者配置正確的部署金鑰。 在實踐中,通常有兩種解決方案:
- 將更改部署的功能開放給使用者。例如,您的設定頁面可能會有一個切換按鈕以啟用“測試版”的訪問許可權。 如果您不在乎預生產更新的內容被得知,並且您的某些使用者可能希望根據自己的意願選擇使用最新(並且可能有錯誤)的更新(有點像Chrome渠道)。 但是,此解決方案將決策權交給您的使用者,這無法幫助您透明地執行A / B測試。
- 使用額外的後設資料註釋使用者的伺服器端配置檔案,標明與其同步的部署。 預設情況下,您的應用只能使用二進位制嵌入金鑰,但在使用者通過身份驗證後,您的伺服器可以選擇將其“重定向”到其他部署,這樣您就可以根據需要逐步將某些使用者或組放置在不同的部署中。您甚至可以選擇將伺服器響應儲存在本地儲存中,以使其成為新的預設值。 如何將金鑰與使用者的配置檔案一起儲存完全取決於您的身份驗證解決方案(例如Auth0,Firebase,自定義DB + REST API),但這通常非常簡單。
注意:如果需要,您還可以實施混合解決方案,允許終端使用者在不同部署之間切換,同時還允許您的伺服器覆蓋該決策。 這樣,您就擁有了“部署解決方案”的層次結構,可確保您的應用程式能夠自行更新,使用者可以通過獲得最新內容的訪問許可權來獲得最新體驗,但您也有能力根據需要對使用者進行A / B測試。
由於我們建議使用分段(Staging)部署
進行更新的預釋出測試(如上一節所述),因此使用它來對使用者執行A / B測試是不必要的,與此相反,您應該通過允許提前訪問的形式進行(如上面選項#1中所述)。 因此,我們建議您充分利用自定義應用部署,以便您可以根據自己的需求對使用者進行細分。 例如,您可以建立長期甚至一次性部署,向其釋出應用的變體,然後將某些使用者放入其中,以便了解他們的參與方式。
// #1) Create your new deployment to hold releases of a specific app variant
code-push deployment add [APP_NAME] test-variant-one
// #2) Target any new releases at that custom deployment
code-push release-react [APP_NAME] ios -d test-variant-one
複製程式碼
注意:從一個部署“切換”到另一個部署的使用者數,被納入到部署中的“安裝度量”中報告的總使用者數。例如,如果您的生產部署當前報告的使用者總數為1,但您將該使用者動態切換為階段部署,則生產部署將報告0個總使用者,而階段部署將報告1(剛剛切換的使用者)。 即使在使用基於執行時的部署重定向解決方案的情況下,這種行為可以讓你準確地跟蹤您的版本使用情況。
轉載請註明出處。