Bugly 多渠道熱更新解決方案
有很多同學可能會採用配置productFlavors來打渠道包,主要是它是原生支援,方便開發者輸出不同定製版本的apk,舉個例子:
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
productFlavors {
flavor1 {
packageName "com.example.flavor1"
versionCode 20
}
flavor2 {
packageName "com.example.flavor2"
minSdkVersion 14
}
}
}
這樣就可以輸出兩個定製的apk,不同包名,版本號也不同。 但是,如果用它來打渠道包是一個非常低效的做法,因為它每一次都會走編譯流程,你想一下如果每打一個渠道包就要走一下編譯流程,100個渠道包那得多慢。
那如果你能忍受這麼低效打渠道包的方式,那回到本文焦點,我先問個問題:“如果你要針對多渠道進行打補丁,你應該怎麼做?”
你可能會回答,那就針對不同的渠道包進行打補丁。沒錯,這個確實行得通,Bugly也是支援以這種方式進行打補丁,tinker-support外掛會為不同渠道包插入不同的TINKER_ID, 唯一標識當前版本的渠道包,我們可以看下gradle打多渠道補丁的配置:
上面的示例只是配置了兩個渠道,如果你配置超過5個的話,那麼就意味著你要一個補丁,一個補丁上傳到Bugly補丁管理後臺,況且我們也只允許同時下發5個版本的補丁。這裡提一下為什麼要上傳所有渠道的補丁,因為通過productFlavors配置,會修改buildConfig類中的FLAVOR欄位,這會導致生成的不同渠道包的dex是不一樣的,所以只能針對具體渠道進行打補丁。這就非常的尷尬了,那怎麼辦呢?有沒有版本通過一個補丁就能夠修復所有渠道,答案是:有的,但前提是你要保證所有渠道包程式碼是一致的。
通過多渠道打包框架快速打多渠道包
這裡推薦使用walle來打多渠道包,新一代多渠道打包神器。
通過walle或者類似的打包工具就不會改變dex的結構,只是修改APK Signature Block來新增自定義的渠道資訊來生成渠道包。
配置示例:
// 多渠道使用walle示例(注:多渠道使用)
apply from: 'multiple-channel.gradle'
建立multiple-channel.gradle,內容如下:
apply plugin: 'walle'walle {
// 指定渠道包的輸出路徑
apkOutputFolder = new File("${project.buildDir}/outputs/channels");
// 定製渠道包的APK的檔名稱
apkFileNameFormat = '${appName}-${packageName}-${channel}-${buildType}-v${versionName}-${versionCode}-${buildTime}.apk';
// 渠道配置檔案
channelFile = new File("${project.getProjectDir()}/channel")
}
建立channel配置:
命令列打多渠道包:
./gradlew clean assembleReleaseChannels
輸出結果如下:
ok,到此已經實現快速打多渠道包了。
如何獲取渠道資訊?
如果你想獲取渠道資訊進行一些統計的分析,可以按照以下方式(具體參考walle):
dependencies {
compile 'com.meituan.android.walle:library:1.1.3'
}
在程式碼中獲取渠道資訊:
String channel = WalleChannelReader.getChannel(this.getApplicationContext());
如果你已經集成了Bugly的異常上報,你就可以通過以下方式來塞入渠道資訊:
String channel = WalleChannelReader.getChannel(getApplication());
Bugly.setAppChannel(getApplication(), channel);
// 這裡實現SDK初始化,appId替換成你的在Bugly平臺申請的appId
Bugly.init(getApplication(), "YOUR_APP_ID", true);
這樣我們就可以按渠道維度來統計你們app的Crash資料了。
一個補丁修復所有渠道
重頭戲,總是留在最後。 在打渠道包的過程,因為會走編譯流程,熱更新外掛也會在bakApk生成對應的基線版本,這個跟普通打包就沒有差別了:
只需要上傳補丁包到補丁管理後臺,然後下發即可。
筆者隨便挑了三個渠道分別安裝到不同裝置,均成功打上補丁:
ok,基本上我們的需求就已經實現啦,媽媽再也不用擔心我加班加點上傳補丁包了。
總結
Bugly目前同時支援兩種方式進行渠道包的熱更新:
-
productFlavors方式打多渠道包
-
快速打渠道包工具(Gradle)
筆者是推薦使用第二種方式,不僅能夠快速打包,也能夠輕鬆實現一個補丁修復所有渠道。
相關推薦
Bugly多渠道熱更新解決方案
Gradle使用productFlavors打渠道包的痛 有很多同學可能會採用配置productFlavors來打渠道包,主要是它是原生支援,方便開發者輸出不同定製版本的apk,舉個例子: android { ... defaultCo
Bugly 多渠道熱更新解決方案
有很多同學可能會採用配置productFlavors來打渠道包,主要是它是原生支援,方便開發者輸出不同定製版本的apk,舉個例子: android { ... defaultConfig { minSdkVersion 8
Bugly多渠道(Walle)熱更新解決方案
上文中講了騰訊Bugly熱更新的接入和具體使用,還沒使用熱更新的小夥伴可以移步去看一下: 一、Bugly熱更新接入和使用 二、Bugly熱更新+Walle(瓦力)多渠道打包解決方案 三、Bugly熱更新+Walle(瓦力)多渠道打包+應用加固解決方案 這篇文章接著上一篇講
xLua 2.1.13 釋出,騰訊開源的手遊熱更新解決方案
新增特性 新增AdaptByDelegate注入模式; 新增xlua.get_generic_method,用於呼叫泛型函式; 支援類似CS.System.Collections.Generic.List(CS.System.Int32)的泛型寫法; 注入新選項
Unity程式碼熱更新解決方案測試結果總結
這幾天一直在研究熱更新方案 主要思路是: 1.先將程式碼打包成dll,然後用unity 打包成assetsbundle, 2.WWW載入進入主程式, 3使用System.Reflection.Assembly來建立程式集, 4.然後通過GetType(className)
PowerBI更新 - 解決方案架構(一圖勝萬字!)
service 包括 obi font 數據模型 ont ima power mis 今天發福利啦!發福利啦!發福利啦! 企業的各種數據整合到PowerBI顯示,瀏覽器,移動端顯示關鍵指標。 一個很好的PowerBI解決方案的圖!一圖勝萬字!你所需要知
會話標示未更新解決方案
會話標示未更新JSF項目,用appscan檢測,報“會話標示未更新”漏洞,漏洞詳情:用戶在登陸應用程序前後,其會話標識一樣,未進行更新,從而可以竊取或操作客戶會話和Cookie,進行查看、變更用戶信息及執行事務等操作。 推理: 測試結果似乎指示存在脆弱性,因為“原始請求”和“響應”中的會話標識相同。這些標誌
Unity Android il2cpp熱更解決方案
1. 簡介 這是Unity Android il2cpp熱更解決方案的Demo(Git地址)的說明。 和現有的熱更解決方案不同的是,他不會引入多餘的語言(只是UnityScript,c#...),對Unity程式設計和編碼沒有任何限制。你可以在預置和場景裡的GameObject上新增任何的Compnent
vue陣列中資料變化但是檢視沒有更新解決方案
原文連結:http://www.cnblogs.com/sufubo/p/6906261.html#undefined 問題:在vue專案中,我更改陣列中的某一條資料,直接arr[i]=newVal ,發現頁面上陣列沒有實時重新整理; 檢視官網發現: 陣列更新檢測 變異方法 Vue 包含一組觀察陣列
針對QT——“在程式檔案中(*ui,*cpp,*h)更改之後編譯執行的程式結果無法更新”——解決方案
本篇文章主要介紹在QT中,對程式檔案(*ui,*cpp,*h)更改之後編譯執行的程式結果卻無法更新的解決方案。 問題描述 在設計QT的GUI使用者介面時,我們需要不斷對程式檔案進行修改以優化使用者體驗,因此需要更新程式的生成檔案。 實際經歷:筆者最近在一個專案中需要將QT的GUI程式
Bugly Android熱更新總結篇
前言 之前發過一篇文章——Bugly熱更新SDK你需要知道的一些事,那是Bugly整合Tinker之後正式釋出的第一個版本—1.2.0,針對我們熱更新能力進行的一些說明,經過之後的版本迭代當中也是不斷的跟進Tinker版本並且不斷優化和簡化開發者的接入,讓開發
vue ajax請求資料不更新 解決方案
這個問題 卡我好久, 找到方法了,分享出來吧 舉個簡單例子 <template> <div> {{a}} </div> </templ
關於cocos2dx客戶端程式的自動更新解決方案
轉載自:簾卷西風的專欄(http://blog.csdn.net/ljxfblog) 隨著手機遊戲的不斷髮展,遊戲包也越來越大,手機網路遊戲已經超過100M了,對於玩家來說,如果每次更新都要重新下載,那簡直是災難。而且如果上IOS平臺,每次重新發包都要稽核,勞神
App增量更新解決方案
開發環境:Ubuntu16.04生成差異包: 1)安裝bsdiff工具 sudo apt-get install bsdiff 2)生成差異包 sudo bsdiff old.apk n
實時交易系統中引數實時更新解決方案
好久沒有寫技術方面的東西了,今天有時間寫點實時交易系統方面的東東! 一. 問題提出 在實時交易系統中,引數的更新管理是整個系統穩定與高效的基礎。當然,如果你的系統中的引數不需要實時的更新,那麼就沒必要看下去了,你可以隨便從檔案中、從資料庫中讀取引數,甚至於把引數寫在
iOS 多渠道打包的解決方案
環境:xcode 6.3.2 開始的思路是用指令碼 解壓.ipa檔案 ,修改.app裡面的自定義渠道檔案,然後再壓縮成ipa檔案。 後來發現打出來的手機裝不上。 於是主意打在了.xcarchive 檔案上。 指令碼如下 #!/bin/sh #在工
Android開發SDK與Gradle更新解決方案
1. 導讀 Android開發工具Eclipse與AndroidStudio 伴隨著Android版本提升,SDK與Gradle也得同時更新,但國內幾乎無法更新,購買了能更新工具Nydus,價格比較合理,在公司Windows 7使用穩定性ok,但在家裡M
Android Things APP版本更新解決方案
<!--Android Things所有許可權--> <uses-permission android:name="com.google.android.things.permission.MANAGE_BLUETOOTH" /> <uses-permission android
PHP 程式碼更新延遲 PHP程式碼沒及時更新解決方案
本部落格第一篇文章。以這篇文章為開始,我將陸續丟擲一些開發過程中的遇到過的問題並附帶解決方案,希望能幫到你們。 問題 修改PHP程式碼,不能及時更新,要等待許久才更新好 修改PHP程式碼,重新整理頁面等待PHP反饋結果,1秒過去了,2秒
使用騰訊bugly整合熱更新使用踩坑記錄
這兩天公司專案需要是用熱更新來提升使用者使用體驗,減少由於bug造成的頻繁發版,最後當然選擇使用triker作為熱更新了,不過我還是決定使用bugly,原因如下: 1.bugly熱更新是對trinker的再次封裝,整合起來相對簡單 2.bugly有操控控制檯,我可以很簡單隨