最開始的時候是為了使用騰訊的bugly架構來抓取app中的crash，後來又看到了騰訊的bugly架構之後續，比如自動更新，熱修複等等，這篇文章記錄的主要是bugly介入的流程和遇見的坑（本篇文章不包括內建crash時的符号表插入和熱更的so更新，這些功能會在下篇文章中去更新）
首先來說一下內建bugly中crash的流程
https://bugly.qq.com/docs/user-guide/instruction-manual-android/?v=20180709165613
騰訊官方位址，這個是比較簡單的，按照這個流程一步一步走下去就可以完全搞定。
如果自動內建NDK之後出現以下的錯誤資訊
NDK integration is deprecated in the current plugin. Consider trying the new experimental plugin.
則在項目根目錄的gradle.properties檔案中添加：
android.useDeprecatedNdk=true
注意 ：內建Bugly NDK時，需要同時內建Bugly SDK。但是內建SDK的時候不一定要內建NDK
注：如果您的App需要上傳到，您需要将google play store
權限屏蔽掉或者移除，否則可能會被下架。READ_PHONE_STATE
- 請避免混淆Bugly，在Proguard混淆檔案中增加以下配置：
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}
最簡單的初始化
擷取APP ID并将以下代碼複制到項目Application類onCreate()中，Bugly會為自動檢測環境并完成配置：
CrashReport.initCrashReport(getApplicationContext(), "注冊時申請的APPID", false);
為了保證營運資料的準确性，建議不要在異步線程初始化Bugly。
第三個參數為SDK調試模式開關，調試模式的行為特性如下：建議在測試階段建議設定成true，釋出時設定為false。
- 輸出詳細的Bugly SDK的Log；
- 每一條Crash都會被立即上報；
- 自定義日志将會在Logcat中輸出。
增加上報程序控制
UserStrategy strategy = new UserStrategy(context);
//strategy.xxx()設定需要控制的屬性 具體屬性如下
https://bugly.qq.com/docs/user-guide/advance-features-android/?v=20180709165613
CrashReport.initCrashReport(context, "注冊時申請的APPID", isDebug, strategy);
以上就是crash的功能的簡單使用，
如果你嫌棄這個過程太麻煩了，恭喜你，你可以不用看這個了 ，因為下面的自動更新和熱修複已經及把Crash功能合并在其中了，當然要增加上報程序控制一樣可以如此
UserStrategy strategy = new UserStrategy(context);
//strategy.xxx()設定需要控制的屬性 具體屬性如下
https://bugly.qq.com/docs/user-guide/advance-features-android/?v=20180709165613
Bugly.init(getApplication(),"注冊時申請的APPID",true，strategy );
=============================================分割線=============================================
基于bugly的自動更新
https://bugly.qq.com/docs/user-guide/instruction-manual-android-upgrade/?v=20180709165613
騰訊官方文檔
按照官方文檔來走也是肯定會成功的，
在此僅記錄遇見無法更新的問題，
//設定本機為測試開發裝置
// Bugly.setIsDevelopmentDevice(getApplication(),true);
很是奇怪，我設定本機為開發測試裝置之後竟然收不到更新提示，是以我果斷把此方法注釋掉了
在後來我發現了自動更新的全量更新，也就是所有裝置的，是以無法更新的原因不在于此，最後發現，當确認當期版本無誤之後，官方給的時間是在3s，但是我自己在能提示更新的時間大概在2分鐘之後，（可能因為網速問題，更新提示有延遲）
自動更新在初始化之後就已經調用了，如果後續還需要，那個調用Beta.checkUpgrade(false,false)方法，
參數1：isManual 使用者手動點選檢查，非使用者點選操作請傳false
參數2：isSilence 是否顯示彈窗等互動，[true:沒有彈窗和toast] [false:有彈窗或toast]
預設的Beta.checkUpgrade() == Beta.checkUpgrade(true,false)
還有比較蒙的一點就是，所有的版本的竟然可以在同一時間段同時啟動，這時候我就比較好奇了，我到底更新的是哪一個版本，難道是随機的嗎？這個問題現在還沒有去測試，等有時間測試完成之後會貼上的！！！
之前一直不知道這個政策名稱到底是幹啥用的，後來發現這隻是一個标題的作用
更新和熱修複都有一個beta屬性，具體屬性如下
https://bugly.qq.com/docs/user-guide/advance-features-android-beta/
=============================================分割線==============================================
crash的抓取和自動更新這一塊按照文檔走，隻要你的配置沒有問題，注冊的appid沒有問題，權限沒有問題，網絡沒有問題，那就沒有其他問題了，熱更感覺坑就多了很多了，
首先
官方文檔為了讓我們能更好的學習熱更技術，給我們提供了很多便利，比如bugly的熱更是基于微信tinker開發的，我們隻用去配置少量的代碼就能內建熱更功能，再比如，在頁面的最上面給出了視訊教程，等等
孰能想到這和竟然是空的，如果想看視訊的同學需要去自己找
課時1：Bugly熱更新介紹
https://v.qq.com/x/page/w0384j4xrnd.html
課時2：tinker-support插件的使用
https://v.qq.com/x/page/o03855ejzf4.html
課時3：內建Sdk
https://v.qq.com/x/page/e03855m02j8.html
課時4：生成更新檔包之痛 我懂你
https://v.qq.com/x/page/i0385n7ncro.html
課時5：更新檔包為何傳不上去
https://v.qq.com/x/page/e0385shcfzm.html
課時6：普通打包的熱更新
https://v.qq.com/x/page/k0385qx3tk2.html
課時7：管道包的熱更新
https://v.qq.com/x/page/z0393rt2cmq.html
課時8：加強包的熱更新
https://v.qq.com/x/page/p0398b38vwl.html
相信有不少小夥伴在打包的時候發現build\bakApk\app-0910-13-51-24\，缺失了app-release-mapping.txt
而确實的這個檔案其實是因為混淆沒有打開，
mapping檔案
mapping.txt
列出了原始的類，方法和字段名與混淆後代碼間的映射。這個檔案很重要，當你從release版本中收到一個bug報告時，可以用它來翻譯被混淆的代碼。
mapping目錄在
\app\build\outputs\mapping\release 把它複制到
build\bakApk\app-0910-13-51-24\就好
如果這時候還是找不到這個檔案 就需要在混淆檔案中添加
混淆前後的映射
-printmapping mapping.txt
然後到最後我發現其實沒有這個檔案的時候 我的更新和熱更都是可以用的，抓到的crash日志也是可以正常檢視，但是為避免意外出現，建議還是把app-release-mapping.txt檔案和符号表插件配置好。
另外一定要注意enableProxyApplication 這個屬性
enableProxyApplication = false 的情況
這是Tinker推薦的接入方式，一定程度上會增加接入成本，但具有更好的相容性。
你需要自己去寫ApplicationLike extends DefaultApplicationLike
還要去寫SampleApplication
public SampleApplication() {
super(ShareConstants.TINKER_ENABLE_ALL, "xxx.xxx.SampleApplicationLike",
"com.tencent.tinker.loader.TinkerLoader", false);
}
參數一：表示Tinker支援的類型
參數二：Application代理類 這裡填寫你自定義的ApplicationLike 包名+類名
參數三：Tinker的加載器，使用預設即可
參數四：加載dex或者lib是否驗證md5，預設為false
enableProxyApplication = true 的情況
即正常使用
在編譯的時候如果找不到gradle 請看as最右邊
如果在編譯的時候出現app-release-unsigned.apk情況，這是因為你的apk在打包的時候沒有找到keystore
在build.gradle中添加
// 簽名配置
signingConfigs {
release {
try {
//這個keystore檔案夾和app下的build檔案夾同級
storeFile file("./keystore/xxx.keystore")
storePassword ""//密碼
keyAlias ""//keystore的别名
keyPassword ""//密碼
} catch (ex) {
throw new InvalidUserDataException(ex.toString())
}
}
debug {
storeFile file("./keystore/debug.keystore")
}
}
// 建構類型
buildTypes {
release {
minifyEnabled false
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
debuggable true
minifyEnabled false
signingConfig signingConfigs.debug
}
基準包和更新檔包注意事項：
基準包在沒有更新到下個版本之前，務必不要删除，因為更新檔包要和基準包對應，不然無法比對，導緻上傳更新失敗
生成基準包的時候 baseApkDir 是以一個日期格式生成檔案夾，
在打更新檔包的時候這個字元串一定要換成基準包的檔案夾名。
tinkerId 基本包和更新檔包一定要確定唯一性，但是也可以這樣寫
經過的測試發現隻要更新檔包的baseApkDir能和基準包的對應上，以上也是可以接到更新檔的，同一個基準包同時隻能下發一個更新檔
後下發的更新檔會沖突掉之前的更新檔包
現在我要去看符号表的插入和so檔案的更新了