原文連接:react-native-code-pushjavascript
關於CodePush在iOS端的簡易使用能夠看我這篇,以爲不錯的話能夠點個贊或關注。java
注意:本自述文件僅與咱們插件的最新版本相關。 若是您使用的是舊版本,請切換到咱們的GitHub倉庫中的相關標籤,以查看該特定版本的文檔。react
此插件爲CodePush服務提供客戶端集成,容許您輕鬆地向React Native應用程序添加動態更新體驗。android
React Native
應用程序由JavaScript
文件和任何附帶圖像組成,這些圖像由打包程序捆綁在一塊兒並做爲特定於平臺的二進制文件(即.ipa
或.apk
文件)的一部分進行分發。應用程序發佈後,更新JavaScript
代碼(例如修復錯誤,添加新功能)或圖像資源,須要您從新編譯和從新分發整個二進制文件,固然,也包括相關商店的審覈時間。ios
CodePush
插件經過保持你的JavaScript
和images
與發佈到CodePush
服務器的更新同步,使得用戶能夠當即得到改進後的產品。經過這種方式,您的應用能夠得到離線移動體驗的好處,以及一旦可用,就能夠得到側面加載更新的「類網絡」的敏捷性。這是共贏的!git
爲了確保您的最終用戶始終擁有應用程序的正常版本,CodePush
插件會維護之前更新的副本,以便在您意外推送包含崩潰的更新時,它能夠自動回滾。這樣,您能夠放心,在您有機會回滾服務器版本以前,您發佈的新版本不會影響到用戶。這是一個共贏的局面!github
注意:任何與本機代碼相關的產品更改(例如,修改AppDelegate.m / MainActivity.java
文件,添加新插件)都沒法經過CodePush
分發,所以必須經過相應的商店進行更新。npm
根據 "getting started" 設置你的CodePush賬戶,在應用程序的根目錄中執行如下命令,便可在你的React Native
應用程序中使用CodePush-ifying
。redux
npm install --save react-native-code-push
複製代碼
與全部其餘React Native插件同樣,iOS和Android的集成體驗也不一樣,所以請根據您要定位的平臺執行如下設置步驟。 請注意,若是您要定位兩個平臺,建議爲每一個平臺建立單獨的CodePush應用程序。react-native
若是您想了解其餘項目如何與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捆綁包後,接下來惟一要作的事就是向你的應用添加必要的代碼,以控制如下流程:
最簡單的方法是使用「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 });
複製代碼
有了這樣的變化後,如今只需選擇應用程序如何爲當前用戶配置正確的部署密鑰。 在實踐中,一般有兩種解決方案:
注意:若是須要,您還能夠實施混合解決方案,容許最終用戶在不一樣部署之間切換,同時還容許您的服務器覆蓋該決策。 這樣,您就擁有了「部署解決方案」的層次結構,可確保您的應用程序可以自行更新,用戶能夠經過得到最新內容的訪問權限來得到最新體驗,但您也有能力根據須要對用戶進行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(剛剛切換的用戶)。 即便在使用基於運行時的部署重定向解決方案的狀況下,這種行爲可讓你準確地跟蹤您的版本使用狀況。
轉載請註明出處。