2. 程式人生 > >Android利用騰訊Bugly實現一鍵多渠道打包+一包熱更新全渠道

Android利用騰訊Bugly實現一鍵多渠道打包+一包熱更新全渠道

阿新 • • 發佈：2019-01-09

騰訊Bugly，為移動開發者提供專業的異常上報和運營統計，幫助開發者快速發現並解決異常，同時掌握產品運營動態，及時跟進使用者反饋。

Bugly主要功能有異常上報、運營統計和應用升級（包含熱更新和全包更新），這些功能在官網上都有對應的開發文件可供參考，並且在熱更新模組還錄有專門的視訊教程以供參考。

我在按照官方文件和視訊教程使用之後，發現還是會存在部分不太好理解或者操作不順暢的地方，此處便對我的所有操作做一個總結。我目前總結的是將Bugly提供的所有的功能都利用上，並且個人認為操作比較簡單的做法。文末會有我參考到的所有文件資訊，各位也可自行學習改進。

首先我們需要在Bugly上建立自己的應用，從而獲取自己應用的App Key和App ID；然後按照以下步驟進行整合；

整合應用升級+異常上報

一：新增外掛依賴

工程根目錄下“build.gradle”檔案中新增：

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        // tinkersupport外掛, 其中lastest.release指拉取最新版本，也可以指定明確版本號，例如1.0.4
        classpath "com.tencent.bugly:tinker-support:latest.release"
     }
}

二：整合SDK

在app module的“build.gradle”檔案中新增（示例配置）：

android {
    defaultConfig {
       //不開啟multiDex（需要用到設為true）
        multiDexEnabled false
    }
}

dependencies {
      /*騰訊Bugly*/
    compile 'com.tencent.bugly:crashreport_upgrade:latest.release'//latest.release指代最新版本號
    compile "com.android.support:multidex:1.0.1" //多dex配置
}

// 依賴外掛指令碼
apply from: 'tinker-support.gradle'

在app module的“build.gradle”檔案的同級目錄下建立“tinker-support.gradle”檔案，內容如下：

apply plugin: 'com.tencent.bugly.tinker-support'

def bakPath = file("${buildDir}/bakApk/")

/**
 * 此處填寫每次構建生成的基準包目錄
 * 打熱更新包時會修改
 */
def baseApkDir = "app-0208-15-10-00"

/**
 * 對於外掛各引數的詳細解析請參考
 */
tinkerSupport {

    // 開啟tinker-support外掛，預設值true
    enable = true

    // 指定歸檔目錄，預設值當前module的子目錄tinker
    autoBackupApkDir = "${bakPath}"

    // 是否啟用覆蓋tinkerPatch配置功能，預設值false
    // 開啟後tinkerPatch配置不生效，即無需新增tinkerPatch
    overrideTinkerPatchConfiguration = true

    // 編譯補丁包時，必需指定基線版本的apk，預設值為空
    // 如果為空，則表示不是進行補丁包的編譯
    // @{link tinkerPatch.oldApk }
    baseApk = "${bakPath}/${baseApkDir}/app-release.apk"

    // 對應tinker外掛applyMapping
    baseApkProguardMapping = "${bakPath}/${baseApkDir}/app-release-mapping.txt"

    // 對應tinker外掛applyResourceMapping
    baseApkResourceMapping = "${bakPath}/${baseApkDir}/app-release-R.txt"

    // 構建基準包和補丁包都要指定不同的tinkerId，並且必須保證唯一性
    //此處會經常修改，我的習慣：打基準包時“base-序號”，打熱更新包時“patch-序號”
    tinkerId = "base-1.0.1"

    // 構建多渠道補丁時使用
    buildAllFlavorsDir = "${bakPath}/${baseApkDir}"

    // 是否啟用加固模式，預設為false.(tinker-spport 1.0.7起支援）
    isProtectedApp = true

    // 是否開啟反射Application模式
    enableProxyApplication = false

}

/**
 * 一般來說,我們無需對下面的引數做任何的修改
 * 對於各引數的詳細介紹請參考:
 * https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
 */
tinkerPatch {
    //oldApk ="${bakPath}/${appName}/app-release.apk"
    ignoreWarning = false
    useSign = true
    dex {
        dexMode = "jar"
        pattern = ["classes*.dex"]
        loader = []
    }
    lib {
        pattern = ["lib/*/*.so"]
    }

    res {
        pattern = ["res/*", "r/*", "assets/*", "resources.arsc", "AndroidManifest.xml"]
        ignoreChange = []
        largeModSize = 100
    }

    packageConfig {
    }
    sevenZip {
        zipArtifact = "com.tencent.mm:SevenZip:1.1.10"
//        path = "/usr/local/bin/7za"
    }
    buildConfig {
        keepDexApply = false
        //tinkerId = "1.0.1-base"
        //applyMapping = "${bakPath}/${appName}/app-release-mapping.txt" //  可選，設定mapping檔案，建議保持舊apk的proguard混淆方式
        //applyResourceMapping = "${bakPath}/${appName}/app-release-R.txt" // 可選，設定R.txt檔案，通過舊apk檔案保持ResId的分配
    }
}

三：初始化SDK

初始化SDK，Bugly提供了兩種方式，本人採用了Bugly推薦的非反射Application模式，即在“tinker-support.gradle”檔案中設定“enableProxyApplication = false”；

這是Tinker推薦的接入方式，一定程度上會增加接入成本，但具有更好的相容性。

首先我們需要按照以下方式自定義ApplicationLike來實現Application的程式碼（以下是示例）：
自定義Application

public class SampleApplication extends TinkerApplication {
    public SampleApplication() {
        super(ShareConstants.TINKER_ENABLE_ALL, "xxx.xxx.SampleApplicationLike",
                "com.tencent.tinker.loader.TinkerLoader", false);
    }
}

注意：這個類整合TinkerApplication類，這裡面不做任何操作，所有Application的程式碼都會放到ApplicationLike繼承類當中
引數解析
引數1：tinkerFlags 表示Tinker支援的型別 dex only、library only or all suuport，default: TINKER_ENABLE_ALL
引數2：delegateClassName Application代理類 這裡填寫你自定義的ApplicationLike
引數3：loaderClassName Tinker的載入器，使用預設即可
引數4：tinkerLoadVerifyFlag 載入dex或者lib是否驗證md5，預設為false

我們需要您將以前的Applicaton配置為繼承TinkerApplication的類(此處引用Bugly提供的圖片)：

replace_application.png

自定義ApplicationLike：

public class SampleApplicationLike extends DefaultApplicationLike {

    public static final String TAG = "Tinker.SampleApplicationLike";

    public SampleApplicationLike(Application application, int tinkerFlags,
            boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime,
            long applicationStartMillisTime, Intent tinkerResultIntent) {
        super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
    }


    @Override
    public void onCreate() {
        super.onCreate();
        buglyInit();
    }


    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    @Override
    public void onBaseContextAttached(Context base) {
        super.onBaseContextAttached(base);
        // you must install multiDex whatever tinker is installed!
        MultiDex.install(base);

        // 安裝tinker
        // TinkerManager.installTinker(this); 替換成下面Bugly提供的方法
        Beta.installTinker(this);
    }

    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    public void registerActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks) {
        getApplication().registerActivityLifecycleCallbacks(callbacks);
    }

    /**
     * 初始化Bugly升級和CrashReport
     */
    private void buglyInit() {
        /*
         * true表示app啟動自動初始化升級模組;
         * false不會自動初始化;
         * 開發者如果擔心sdk初始化影響app啟動速度，可以設定為false，
         * 在後面某個時刻手動呼叫Beta.init(getApplicationContext(),false);
         */
        Beta.autoInit = true;

        /*
         * true表示初始化時自動檢查升級;
         * false表示不會自動檢查升級,需要手動呼叫Beta.checkUpgrade()方法;
         */
        Beta.autoCheckUpgrade = true;

        /*
         * 設定升級檢查週期為60s(預設檢查週期為0s)，60s內SDK不重複向後臺請求策略);
         */
        Beta.upgradeCheckPeriod = 60 * 1000;

        /*
         * 設定啟動延時為1s（預設延時3s），APP啟動1s後初始化SDK，避免影響APP啟動速度;
         */
        Beta.initDelay = 5 * 1000;

        /*
         * 設定通知欄大圖示，largeIconId為專案中的圖片資源;
         */
        Beta.largeIconId = R.mipmap.ic_launcher;

        /*
         * 設定狀態列小圖示，smallIconId為專案中的圖片資源Id;
         */
        Beta.smallIconId = R.mipmap.ic_launcher;

        /*
         * 設定更新彈窗預設展示的banner，defaultBannerId為專案中的圖片資源Id;
         * 當後臺配置的banner拉取失敗時顯示此banner，預設不設定則展示“loading“;
         */
        Beta.defaultBannerId = R.mipmap.ic_launcher;

        /*
         * 設定sd卡的Download為更新資源儲存目錄;
         * 後續更新資源會儲存在此目錄，需要在manifest中新增WRITE_EXTERNAL_STORAGE許可權;
         */
        Beta.storageDir = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS);

        /*
         * 點選過確認的彈窗在APP下次啟動自動檢查更新時會再次顯示;
         */
        Beta.showInterruptedStrategy = true;

        /*
         * 只允許在MainActivity上顯示更新彈窗，其他activity上不顯示彈窗;
         * 不設定會預設所有activity都可以顯示彈窗;
         */
        Beta.canShowUpgradeActs.add(MainActivity.class);

        /*
         *  設定自定義升級對話方塊UI佈局
         *  注意：因為要保持介面統一，需要使用者在指定控制元件按照以下方式設定tag，否則會影響您的正常使用：
         *  標題：beta_title，如：android:tag="beta_title"
         *  升級資訊：beta_upgrade_info  如： android:tag="beta_upgrade_info"
         *  更新屬性：beta_upgrade_feature 如： android:tag="beta_upgrade_feature"
         *  取消按鈕：beta_cancel_button 如：android:tag="beta_cancel_button"
         *  確定按鈕：beta_confirm_button 如：android:tag="beta_confirm_button"
         *  詳見layout/upgrade_dialog.xml
         */
        Beta.upgradeDialogLayoutId = R.layout.upgrade_dialog;

        // 這裡實現SDK初始化，appId替換成你的在Bugly平臺申請的appId
        // 除錯時，將第三個引數改為true
        Bugly.init(getApplication(), "900029763", false);//初始化Bugly
    }

}

注意：tinker需要你開啟MultiDex,你需要在dependencies中進行配置compile "com.android.support:multidex:1.0.1"才可以使用MultiDex.install方法； SampleApplicationLike這個類是Application的代理類，以前所有在Application的實現必須要全部拷貝到這裡，在onCreate方法呼叫SDK的初始化方法，在onBaseContextAttached中呼叫Beta.installTinker(this);

其中應用升級的詳細配置可以參考應用升級配置文件

第四步：AndroidManifest.xml配置

1. 許可權配置
    <uses-permission android:name="android.permission.READ_PHONE_STATE" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
    <uses-permission android:name="android.permission.READ_LOGS" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
2. Activity配置
<activity
    android:name="com.tencent.bugly.beta.ui.BetaActivity"
    android:configChanges="keyboardHidden|orientation|screenSize|locale"
    android:theme="@android:style/Theme.Translucent" />
3. 配置FileProvider

注意：如果您想相容Android N或者以上的裝置，必須要在AndroidManifest.xml檔案中配置FileProvider來訪問共享路徑的檔案。如果你使用的第三方庫也配置了同樣的FileProvider，你需要將第三方庫配置的路徑copy到我們配置的provider_path檔案下。

<provider
    android:name="android.support.v4.content.FileProvider"
    android:authorities="${applicationId}.fileProvider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/provider_paths"/>
</provider>

${applicationId}請替換為您的包名，例如com.bugly.upgrade.demo。這裡要注意一下，FileProvider類是在support-v4包中的，檢查你的工程是否引入該類庫。

在res目錄新建xml資料夾，建立provider_paths.xml檔案如下：

provider_paths位置.png
<?xml version="1.0" encoding="utf-8"?>
<paths xmlns:android="http://schemas.android.com/apk/res/android">
    <!-- /storage/emulated/0/Download/${applicationId}/.beta/apk-->
    <external-path name="beta_external_path" path="Download/"/>
    <!--/storage/emulated/0/Android/data/${applicationId}/files/apk/-->
    <external-path name="beta_external_files_path" path="Android/data/"/>
</paths>

這裡配置的兩個外部儲存路徑是升級SDK下載的檔案可能存在的路徑，一定要按照上面格式配置，不然可能會出現錯誤。

第五步：混淆配置

為了避免混淆SDK，在Proguard混淆檔案中增加以下配置：

-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}

如果你使用了support-v4包，你還需要配置以下混淆規則：

-keep class android.support.**{*;}

第六步：新增Bugly符號表配置

我們為了安全都會對我們的apk進行混淆，混淆之後上傳到Bugly的crash資訊有部分就會出現隱藏類名的情況，這樣我們就無法快速的定位到我們程式的bug所在。只有我們上傳對應的符號表資訊後，Bugly會自動匹配並解析出我們想要找的類名。每次發包都要上傳太麻煩，還是配置一個自動上傳的比較方便：

一：新增外掛依賴

工程根目錄下“build.gradle”檔案中新增：

classpath 'com.tencent.bugly:symtabfileuploader:latest.release'//Bugly符號表外掛
二：新增外掛和配置

在module的buid.gradle檔案的頂部新增：

apply plugin: 'bugly'

bugly {
    appId = '<APP_ID>' // 註冊時分配的App ID
    appKey = '<APP_KEY>' // 註冊時分配的App Key
}

其中APP_ID和APP_KEY是必填的，App ID和App key可以從“產品設定”裡面獲取。
符號表配置的詳細文件可以參考Bugly符號表外掛使用指南

新增渠道資訊並實現多渠道打包

我們將採用美團的walle來打多渠道包；

Walle（瓦力）：Android Signature V2 Scheme簽名下的新一代渠道包打包神器

一：新增外掛依賴

工程根目錄下“build.gradle”檔案中新增：

classpath 'com.meituan.android.walle:plugin:1.1.3'//多渠道打包
二：新增外掛和配置

在module的buid.gradle檔案的頂部新增：

apply plugin: 'walle'

//美團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")
}

然後新增打包用的簽名檔案和混淆等配置資訊（此處我是將debug版本和release版本使用了共同的簽名檔案）；

android {
    signingConfigs {
        release {
            try {
                keyAlias 'bugly'
                keyPassword '[email protected]#$%^&*('
                storeFile file('bugly.jks')//簽名檔案，位置和module的buid.gradle檔案平級
                storePassword '[email protected]#$%^&*('
            } catch (ex) {
                throw new InvalidUserDataException(ex.toString())
            }
        }
    }

    buildTypes {
        release {
            //移除無用的資原始檔
            shrinkResources true
            zipAlignEnabled true

            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
        debug {
            debuggable true
            minifyEnabled false
            signingConfig signingConfigs.release
        }
    }
}

dependencies {
    /*渠道資訊統計分析*/
    compile 'com.meituan.android.walle:library:1.1.3'
}
channel檔案.png

由於集成了Bugly的異常上報，所以還需要通過以下方式來塞入渠道資訊：即在SampleApplicationLike類中新增

String channel = WalleChannelReader.getChannel(getApplication());
Bugly.setAppChannel(getApplication(), channel);
 // 這裡實現SDK初始化，appId替換成你的在Bugly平臺申請的appId
Bugly.init(getApplication(), "YOUR_APP_ID", true);

這樣Bugly就可以按渠道維度來統計app的Crash資料了。

三：打出多渠道包

同步gradle資訊後按照下圖操作打出多渠道包

打多渠道包步驟.png

打熱更新包

熱更新能力是Bugly為解決開發者緊急修復線上bug，而無需重新發版讓使用者無感知就能把問題修復的一項能力。Bugly目前採用的開源方案，開發者只需要整合我們提供的SDK就可以實現自動下載補丁包、合成、並應用補丁的功能，我們也提供了熱更新管理後臺讓開發者對每個版本補丁進行管理。

之前我們打出了多個渠道包，現在我們要實現一個熱更新包解決所有線上同一個版本的bug（同一個版本是指“tinker-support.gradle”檔案中的“tinkerId”相同）；接著上面的打包情況我們來打熱更新包：

打熱更新包.png

現在我們就可以使用打出的熱更新包來修改我們的線上bug了；
如果大家不清楚如何上傳apk全包和熱更新包，或者在上傳熱更新包的時候遇到一些無法處理的問題都可以參考Bugly錄製的視訊：

相關推薦

Android利用騰訊Bugly實現一鍵多渠道打包+一包熱更新全渠道

騰訊Bugly，為移動開發者提供專業的異常上報和運營統計，幫助開發者快速發現並解決異常，同時掌握產品運營動態，及時跟進使用者反饋。Bugly主要功能有異常上報、運營統計和應用升級（包含熱更新和全包更新），這些功能在官網上都有對應的開發文件可供參考，並且在熱更新模組還錄有專門的視訊教程以供參考。我在按照官方文件

安卓使用騰訊Bugly實現應用升級功能

百度搜索bugly登陸平臺，建立應用，獲取應該用ID，在應用程式程式碼中使用該ID就可以實現該應用與bugly平臺應用對接 進入bugly平臺之後會看到三個模組：異常上報，運營統計，應用升級。也就是說bugly平臺包含著三大功能，今天要研究的就是應用升級模組，此模組包含

iOS 利用騰訊 Bugly 程式除錯 測試程式碼bug 卡頓等情況

1.自己先寫一個 Demo 演示一下利用bugly測試崩潰的具體情況。 在ViewController裡面實現崩潰程式碼如下： 執行後 毫無疑問程式報錯了! 2.使用到第三方的框架Bugly，官方下載bugly 3.進入後利用qq註冊一下，完

教你如何玩轉 AndroidStudio 一鍵多渠道打包

如果你還在手動的對每個市場進行打包，先不說 Low 不 Low，自己也會覺得很痛苦對吧，甚至有的同學使用 Windows build 打包一次就得 3-5min;打 6 個市場包半個小時就過去了，最重要的是這個過程中還有可能出現錯誤，增加測試的難度與成本。 多

【騰訊Bugly乾貨分享】基於RxJava的一種MVP實現

Dev Club 是一個交流移動開發技術，結交朋友，擴充套件人脈的社群，成員都是經過稽核的移動開發工程師。每週都會舉行嘉賓分享，話題討論等活動。 本期，我們邀請了騰訊IEG Android 開發工程師——戴俊，為大家分享《基於RxJava的一種MVP實現》

Android 騰訊Bugly——異常上報和應用更新

schema err hidden eno xmlns 哈哈 map ant export 騰訊Bugly，為移動開發者提供專業的異常上報和運營統計，幫助開發者快速發現並解決異常，同時掌握產品運營動態，及時跟進用戶反饋。 首先Bugly有兩大優點，免費，不用審核 使用步驟如

Android 騰訊Bugly 熱更新

nor 現在 oar rri filter ble 實施 2.2.0 armeabi 這個是一位大佬教我的，我自己照著做寫博客 熱更新雖然看起來很復雜，但是Bugly通過集成，使得這個過程很簡單。我這裏不涉及多渠道熱更新，只講述最簡單的情況。 1.首先我們需要在Bugly上

Android仿騰訊手機管家實現桌面懸浮窗小火箭發射的動畫效果

無標題 服務 ice null obj activit 中間 ktr https 功能分析： 1、小火箭遊離在activity之外，不依附於任何activity，不管activity是否開啟，不影響小火箭的代碼邏輯，所以小火箭的代碼邏輯是要寫在服務中； 2、小火箭掛載在手機

Android 騰訊bugly的學習使用

轉載：https://www.jianshu.com/p/7984b3ee7880 前序：一般一個專案的開發，從需求調研到開發完成正式上線必須要經歷修改bug，修改bug，修改bug 的死迴圈中，而往往一些專案在上線之後由於測試人員沒有測試出一些偶發概率的bug，這就導致使用者在下載使用App的

Android 騰訊Bugly熱更新接入（Kotlin語言）

Android 騰訊Bugly熱更新接入（Kotlin語言） 簡介 一、新增外掛依賴 二、gradle配置 三、新建tinker-support.gradle 四、初始化SDK 五、AndroidManifest.xml配置 六、混淆

【騰訊Bugly乾貨分享】Android程序保活招式大全

【騰訊Bugly乾貨分享】Android程序保活招式大全 本文來自於騰訊bugly開發者社群，非經作者同意，請勿轉載，原文地址：http://dev.qq.com/topic/57ac4a0ea374c75371c08ce8 作者：騰訊——張興華 目前市面上的應用，貌似除了微信和手Q都會

Android中利用Shareinstall進行多渠道一鍵自動打包！

目前國內的安卓渠道有幾百家，我們要根據不同的渠道打不同渠道的apk來統計每個渠道帶來的使用者數，統計每個渠道使用者的存活率和活躍度等等資訊，但是手動對每個渠道的APK進行簽名打包實在是讓人感到厭煩且低效，這時我們需要一個全自動化的打包工具----Shareins

Android中最簡單的整合騰訊Bugly

專案中使用到整合騰訊的Bugly方便應用的版本管理，崩潰日誌的檢視和熱更新的應用，研究了一下寫出來了： 庫檔案匯入 Bugly支援自動整合和手動整合兩種方式，如果您使用Gradle編譯Apk，我們強烈推薦您使用自動接入方式配置庫檔案。 自動整合（推薦） Bugly支援JCenter倉

Android 騰訊Bugly（封裝tinker） 熱更新遇到的坑

這篇文章主要是來講遇到的問題的，如果需要整合教程最好還是到官方的文件中心https://bugly.qq.com/docs/廢話不多說，開始坑1： 所有針對bugly 屬性的設定不生效。原因：屬性設定一定要放在Bugly.init(getApplicationContext(

騰訊bugly crash追蹤平臺的使用（一）（挺好用的喔！）

騰訊的這個bugly crash追蹤平臺跟微信關聯，繫結手機，有使用者在使用app過程中如果出現crash現象，就會收到微信提醒。可以及時檢視程式問題。 那這個東西怎麼用呢，很簡單。 官網下載對應的SDK   didFinishLaunchingWithOptions方

騰訊Bugly乾貨分享：Android機型適配之痛

一、個性化十足的Launcher 快捷方式雖然看起來只是一個很小的功能點，但是它涉及到的機型適配問題很多。 快捷方式建立程式碼： ntent addShortCut = new Intent("com.android.launcher.action.I

【騰訊Bugly乾貨分享】Android減包 － 減少APK大小

本文是對Google官方文件 Reduce APK Size 的翻譯，點選“閱讀原文”可以檢視英文原文。 譯者簡介：damonxia(夏正冬)，天天P圖Android工程師 使用者經常會避免下載看起來體積較大的應用，特別是在不穩定的2G、3G

Android 騰訊bugly的學習使用

前序：一般一個專案的開發，從需求調研到開發完成正式上線必須要經歷修改bug，修改bug，修改bug 的死迴圈中，而往往一些專案在上線之後由於測試人員沒有測試出一些偶發概率的bug，這就導致使用者在下載使用App的過程中出現使用者體驗不好，甚至程式閃退的問題。在遇到這種情況

Android--騰訊Bugly整合文件（吐槽版）

本文是在原有的Bugly官方文件上進行修改（吐槽）而成 準備好入坑了麼？沒準備好的，先去吃個糖壓壓驚ヽ(*。>Д<)o゜゜゜ 介紹（一些廢話，看看即可） 熱更新能力是Bugly為解決開發者緊急修復線上bug，而無需重新發版讓使用者無感知就能把問題修

【騰訊Bugly乾貨分享】Android ListView與RecyclerView對比淺析--快取機制

作者：黃寧源 一，背景 RecyclerView是谷歌官方出的一個用於大量資料展示的新控制元件，可以用來代替傳統的ListView，更加強大和靈活。 最近，自己負責的業務，也遇到這樣的一個問題，關於是否要將ListView替換為Recycl