這篇文章將為大家詳細(xì)講解有關(guān)Android 多渠道打包的示例分析,小編覺得挺實(shí)用的,因此分享給大家做個(gè)參考,希望大家閱讀完這篇文章后可以有所收獲。
創(chuàng)新互聯(lián)公司專注于湄潭企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),商城網(wǎng)站建設(shè)。湄潭網(wǎng)站建設(shè)公司,為湄潭等地區(qū)提供建站服務(wù)。全流程定制設(shè)計(jì),專業(yè)設(shè)計(jì),全程項(xiàng)目跟蹤,創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)
Android是一種基于Linux內(nèi)核的自由及開放源代碼的操作系統(tǒng),主要使用于移動(dòng)設(shè)備,如智能手機(jī)和平板電腦,由美國Google公司和開放手機(jī)聯(lián)盟領(lǐng)導(dǎo)及開發(fā)。
我們?cè)?app 正式發(fā)布的時(shí)候一定會(huì)使用正式簽名的方式來打包,這種方式只能生成唯一的一個(gè)包,但是如今的應(yīng)用商店非常多,如:小米、OPPO、360、百度、豌豆莢、應(yīng)用寶等等。而我們只有一個(gè) apk 文件要投入到這么多的應(yīng)用商店中去,如果你的公司不需要統(tǒng)計(jì)每個(gè)應(yīng)用商店的實(shí)際下載使用量的話,那倒是不會(huì)有這樣的問題。
但是,如果你的公司就是需要統(tǒng)計(jì)每個(gè)商店的實(shí)際下載使用情況,那么你將如何去識(shí)別當(dāng)前用戶是從哪一個(gè)商店下載來的呢?出現(xiàn)問題原因是:我們使用的 apk 安裝包當(dāng)前僅有一個(gè)。
假設(shè),我們可以向 apk 內(nèi)植入一個(gè)字符串,比如我給發(fā)布到小米商店的 apk 中植入“xiaomi” ,然后拷貝一份 apk 安裝包發(fā)布到小米商店中,給百度植入“baidu”,然后也拷貝一份發(fā)布到百度商店中,然后通過 JAVA 代碼在用戶從某一個(gè)商店中下載并使用時(shí),我獲取這個(gè)字符串,然后返回給后臺(tái),這不就可以知道用戶從哪個(gè)商店下載了嗎!
多渠道就是指我們的應(yīng)用程序可以從不同的商店下載,不同的應(yīng)用商店就是不同的渠道。那你可能會(huì)有疑惑,我們?yōu)槭裁匆烙脩魪哪膫€(gè)渠道下載的呢?
這個(gè)問題其實(shí)與利益息息相關(guān),你這樣想。假如你寫一個(gè) app 發(fā)布到不同的商店上,你肯定會(huì)關(guān)注究竟哪一個(gè)商店的用戶使用量比較多、下載量比較大的問題,你可能手頭沒有那么多經(jīng)濟(jì)去每一個(gè)商店平臺(tái)都推廣你的 app ,所以你要記錄哪個(gè)商店用戶量最大,然后著重推廣。
友盟打包
說了這么多,相信你已經(jīng)明白多渠道打包的重要性了。既然我們可以向每一個(gè) apk 中植入一個(gè)標(biāo)志這商店名稱的字符串,那么如果一個(gè)一個(gè)的來的話,顯然是一個(gè)龐大的工作,沒有多大實(shí)際意義,而且 apk 文件是無法直接向里面添加一個(gè)外部文件的,你需要其他的手段來實(shí)現(xiàn),那么我們先來看友盟多渠道打包的方式。
友盟的實(shí)現(xiàn)方式是通過 xxx.keystore 文件來進(jìn)行一個(gè)一個(gè)的壓包,通過代碼的方式來分別生成一個(gè)你指定的應(yīng)用商店的對(duì)應(yīng) apk 文件。這種方式會(huì)比較慢,如果你的需求是要投入到幾百上千個(gè)商店的話,顯然生成文件的速度會(huì)非常慢。但如果你的需求量在幾十上百,我建議你可以使用友盟來打包,公司也通常使用這種方式。
那么我們看看如何實(shí)現(xiàn)吧!
一、引入友盟支持
在工程列表(AndroidManifest.xml)文件中加入友盟提供的支持,這個(gè)與 Activity 并列層級(jí)。
<!-- 添加友盟支持 -->
<meta-data android:value="${UMENG_CHANNEL_VALUE}" android:name="UMENG_CHANNEL"/>
二、添加閉包
然后在 app 的 build.gradle 中添加以下代碼,目的是為了生成對(duì)應(yīng)的應(yīng)用商店的 apk ,添加位置在 android 閉包下,以下代碼不難理解。
注意:在 gradle 中是無法使用數(shù)字開頭的名字,所以你應(yīng)該懂得變更一下。
//友盟閉包 productFlavors { wandoujia {} xiaomi {} baidu {} yingyongbao {} //注意 360:gradle 中不能以數(shù)字開頭 _360{} } productFlavors.all { flavor -> flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name] }
這里注意一下,也許你會(huì)報(bào)這個(gè)錯(cuò)誤:
ERROR: All flavors must now belong to a named flavor dimension.
解決方法就是在上面的 defalutConfig 閉包中添加內(nèi)容:
flavorDimensions "versionCode"
然后再同步一下就沒有問題了。
三、簽名打包
接下來就是打包的過程了,很簡(jiǎn)單,我們只需要選中如下圖中的各個(gè)應(yīng)用商店的版本即可,然后它就會(huì)在你設(shè)定的目錄下生成對(duì)應(yīng)的 apk 文件了。
如果對(duì)簽名打包不懂的可以看這篇文章:Android App正式簽名打包流程
這就是我的項(xiàng)目生成的對(duì)應(yīng)的 apk 文件所在的文件夾,點(diǎn)進(jìn)去就會(huì)看到安裝包啦。
四、添加版本號(hào)
當(dāng)然了,你可能希望加入當(dāng)前 app 的開發(fā)版本號(hào),這樣就對(duì)每個(gè)版本升級(jí)時(shí)所用的 apk 包就一目了然了。這是你需要把當(dāng)前 app build.gradle 中的 deflautConfig閉包下的 versionName 給設(shè)置到打包生成的 apk 名中。那代碼是這樣的:
//為多渠道包添加 app 版本號(hào) applicationVariants.all { variant -> variant.outputs.all { output -> def outputFile = output.outputFile if (outputFile != null && outputFile.name.endsWith(".apk")) { def fileName = outputFile.name.replace(".apk", "-${ defaultConfig.versionName }.apk") outputFileName = fileName; } } }
這是一段 groovy 語言,通常在 jvm 中使用,可以很好的和 java 代碼配合。你只需要將它添加到剛剛寫的友盟閉包后面就可以了,如這樣:
然后你再一次打包一下,就可以在目錄中看到 apk 文件了,一個(gè)是剛剛沒有添加的默認(rèn)版本,一個(gè)是擁有版本號(hào)。
注意:這里會(huì)有一個(gè)警告信息,內(nèi)容是這樣:
WARNING: API 'variantOutput.getPackageApplication()' is obsolete and has been replaced with 'variant.getPackageApplicationProvider()'.It will be removed at the end of 2019.
它是說這個(gè) API 在 2019 年末將要被替換成后面的一個(gè),不過別擔(dān)心,只要你在升級(jí) gradle 的時(shí)候注意一下就好了,在未來它要被替換的時(shí)候,你也要做出相應(yīng)的更改!
五、獲取渠道信息
到目前為止,我們還沒真正的看到這樣打包有什么用處。不著急,我們需要將每個(gè) apk 文件發(fā)布到對(duì)應(yīng)的商店以后才需要獲取這個(gè)字符串,這樣才能夠真正的識(shí)別用戶在哪個(gè)商店中下載來的,然后在用戶使用量最大的商店中去大力推廣。那么如何獲取這個(gè)字符串呢?
我就簡(jiǎn)單一點(diǎn),在 MainActivity 中直接獲取這個(gè)字符串了,在實(shí)際開發(fā)中,顯然是要把這個(gè)信息傳給后臺(tái)進(jìn)行統(tǒng)計(jì)的,不然沒有任何意義。我們的獲取代碼如下:
還記得我們?cè)?meta-data 中定義了 UMENG_CHANNEL 屬性的名字嗎,現(xiàn)在我們就可以利用它來獲取 字符串 了。
import android.content.Context; import android.content.pm.ApplicationInfo; import android.content.pm.PackageManager; public class ChannelUtil { public static String getChannel(Context context) { PackageManager pm = context.getPackageManager(); ApplicationInfo appInfo = null; try { appInfo = pm.getApplicationInfo(context.getPackageName(), PackageManager.GET_META_DATA); return appInfo.metaData.getString("UMENG_CHANNEL"); } catch (PackageManager.NameNotFoundException e) { e.printStackTrace(); } return ""; } }
然后我在啟動(dòng) app 的時(shí)候使用 toast 驗(yàn)證一下是否如我們想象的一樣:
獲取渠道信息
結(jié)果沒錯(cuò),相信大家已經(jīng)明白了多渠道打包的作用了,它的本質(zhì)就是在簽名打包的時(shí)候嵌入一個(gè)字符串,通過不同的 apk 包對(duì)應(yīng)不同的商店名,然后上傳到相應(yīng)的商店,最后獲取這個(gè)字符串值返回給后臺(tái)。那么,本篇關(guān)于多渠道打包的內(nèi)容就這樣講完了。
關(guān)于“Android 多渠道打包的示例分析”這篇文章就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,使各位可以學(xué)到更多知識(shí),如果覺得文章不錯(cuò),請(qǐng)把它分享出去讓更多的人看到。
分享題目:Android多渠道打包的示例分析
文章網(wǎng)址:http://vcdvsql.cn/article10/peshdo.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站改版、標(biāo)簽優(yōu)化、App設(shè)計(jì)、營銷型網(wǎng)站建設(shè)、微信公眾號(hào)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)