React Native在Android當中實踐（一）——背景介紹
React Native在Android當中實踐（二）——搭建開發環境
React Native在Android當中實踐（三）——集成到Android項目當中
React Native在Android當中實踐（四）——代碼集成
React Native在Android當中實踐（五）——常見問題
常見問題
若出現libgnustl_shared.so" is 32-bit instead of 64-bit類似錯誤
android {defaultConfig {ndk {abiFilters "armeabi-v7a", "x86"}packagingOptions {exclude "lib/arm64-v8a/librealm-jni.so"}}
}
復制代碼若出現react-native run-android Android project not found
若出現Could not get BatchedBridge, make sure your bundle is packaged correctly
若出現Could not connect to development server
3、飛行模式關閉
4、在cmd中輸入 adb reverse tcp:8081 tcp:8081，結果如下：
Make sure your bundle is packaged correctly or your're running a packager server
index.android.bundle是用來調用原生控件的js腳本，每次當改變了 index.android.js，都需要使用上面的代碼片段，來及時的更新index.android.bundle，然后打包才可以把新的index.android.js應用上，所以當沒有index.android.bundle文件時，React-Native 項目是無法運行的。
解決辦法是
第一步：在Android/app/src/main目錄下創建一個空的assets文件夾（若已經存在請忽略） 出現這個問題是由于
index.android.bundle是用來調用原生控件的js腳本，每次當改變了 index.android.js，都需要使用上面的代碼片段，來及時的更新index.android.bundle，然后打包才可以把新的index.android.js應用上，所以當沒有index.android.bundle文件時，React-Native 項目是無法運行的。
解決辦法是
第一步：在Android/app/src/main目錄下創建一個空的assets文件夾（若已經存在請忽略）
第二步：在Android Studio的Terminal進入項目根目錄執行下面代碼：
react-native bundle --platform android --dev false --entry-file index.android.js --bundle-output app/src/main/assets/index.android.bundle --assets-dest app/src/main/res/
運行完畢后可以看到如下表示已經成功了
React Native的開發者模式
寫在最后
從我個人用 React Native 開發 APP 的體驗來看，React Native 適合 C/S 結構、業務型的 APP 或其中的模塊，對于偏重底層技術的比如工具類 APP （或者模塊），我還沒有使用 RN 嘗試過，不過想必顯然是不太適合的。總的來說，一個對于底層技術依賴不多，業務型，尤其是業務變動頻繁的應用或模塊適合 RN 開發，而且一次開發，基本可以完全重用于兩個平臺，重要的是可以熱更新來應對業務邏輯更新頻繁、更新要求快、迅速修復線上 bug 等需求場景，目前看，RN 的熱更新并沒有被 Apple 封殺。 1.?無需編譯，我在第一次編譯了ipa裝好以后，就再也沒更新過app，只要更新云端的js代碼，reload一下，整個界面就全變了。 2.?多數布局代碼都是JSX，所有Native組件都是標簽化的，這對于前端程序員來說，降低了不少學習成本，也大大減少了代碼量。不信你可以看看JSX編譯后的代碼。 3.?復用React系統，也減少了一定學習和開發成本，更重要的是利用了React里面的分層和diff機制。js層傳給Native層的是一個diff后的json，然后由Native將這個數據映射成真正的布局視圖。 4.?css-layout也是點睛之筆，前端可以繼續用熟悉的類css方式來編寫布局，通過這個工具轉換成constrain布局。 5.?系統只有js-objc的單向調用，就是把原生UI組件的方法通過javascritcore或者webview（低版本iOS）映射到js中來，整個調用過程是異步的，這樣的設計令React native可以讓js運行在桌面chrome中，通過websocket連接Native code和桌面chrome，極大地方便了調試。對其中的機制Bang的一篇文章寫得很詳細，我就不拾人牙慧了：React Native通信機制詳解 ? bang’s blog?。但這樣設計也會帶來一些問題，后面說。 6.?點按操作也被抽象成了一組組件（TouchableXXX），這種抽象方式是我在之前做類似工作中沒有想到的。facebook還列出Native為什么和web「手感」不同的原因：實時的點按反饋和取消能力。React Native?這套相應機制設計得很完善，能像Native code那樣控制整個點按操作的所有過程。 7.?Debug相當方便！修改了js以后，通過內建的nodejs watcher編譯成bundle，在模擬器里面按cmd+r就可以看到效果。而且按cmd+d，可以打開一個chrome窗口，所有的js都移到了chrome里面運行，所以什么斷點單步打調用棧，都不在話下。
上面的既是特點也是優點，下面說說缺點，或者應該說：「仍然遺留的問題」，在我看來，這個方案已經超越了Hybird方案。 1.?系統仍然（不得不）依賴原生組件暴露出來的組件和方法。舉兩個例子，ScrollView這個組件，在Native層是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，這些事件在現有的版本都沒有暴露，基本上做不了組件聯動效果。另外，這個版本中有大量組件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反過來看，剩余的都是一些抽象程度極強的基本組件。這樣，用戶必須在不同的平臺下寫兩套代碼，而且所有能力仍然強烈依賴 React native 開發人員暴露的接口。 2.?由于最外層是React，初次學習成本高，不像往常的Hybird方案，只要多學幾個JS API就可以開始干活了。當然，React的確讓后續開發變得簡單了一些，這么一套外來的（基于iOS）、殘缺不全的（css-layout）在React的包裝下，的確顯得不那么面目可憎了。 另外，React Native仍然很不完善。文檔還不全，我基本上是看著他的示例代碼完成的demo，集成到已有app的文檔也是今天才出來。按照官方的說法，Android版本要到半年后才發布：Blog | React?，屆時整個系統設計可能還會有很大的變化。 ######參考 www.zhihu.com/question/27… github.com/reactnative… www.lcode.org/category/re…
![mysql505復位密碼_mysql5 如何復位根用戶密碼[官方文檔]](http://pic.xiahunao.cn/mysql505復位密碼_mysql5 如何復位根用戶密碼[官方文檔])
![BZOJ 3231: [Sdoi2008]遞歸數列 (JZYZOJ 1353) 矩陣快速冪](http://pic.xiahunao.cn/BZOJ 3231: [Sdoi2008]遞歸數列 (JZYZOJ 1353) 矩陣快速冪)
