本發(fā)明涉及計(jì)算機(jī)領(lǐng)域,尤其涉及一種應(yīng)用安裝包打包方法及裝置。
背景技術(shù):
android(安卓)項(xiàng)目開發(fā)完成以后要將androidapp(安卓應(yīng)用)打包成應(yīng)用安裝包(apk),并通過發(fā)布渠道(亦稱發(fā)布平臺(tái))發(fā)布以便于用戶下載使用。在開發(fā)androidapp時(shí),由于android市場(chǎng)的發(fā)布渠道很多,各個(gè)發(fā)布渠道都有自己的app市場(chǎng)。每個(gè)app市場(chǎng)對(duì)應(yīng)用安裝包的展示方式以及平臺(tái)具體業(yè)務(wù)功能的要求是不同的。因此,需要針對(duì)不同的發(fā)布渠道,修改androidapp安裝包,以使其滿足不同渠道的要求。
現(xiàn)有技術(shù)是通過人工手動(dòng)的方式對(duì)不同發(fā)布渠道的apk文件進(jìn)行修改并完成打包的。有時(shí)一個(gè)工程應(yīng)用非常大,每次打包都要浪費(fèi)幾分鐘,再加上手工修改app文件會(huì)增加很多額外的耗費(fèi),并且如果每個(gè)渠道都單獨(dú)發(fā)布,那樣效率會(huì)及其低下;此外,由于渠道數(shù)目多,人工修改極易出錯(cuò)。
技術(shù)實(shí)現(xiàn)要素:
本發(fā)明實(shí)施例提供一種應(yīng)用安裝包打包方法及裝置,用以解決現(xiàn)有技術(shù)中需人工手動(dòng)修改apk文件以滿足不同發(fā)布渠道的要求存在的諸多問題。
于是,在本發(fā)明的一個(gè)實(shí)施例中,提供了一種應(yīng)用安裝包打包方法。該方法包括:根據(jù)待打包文件的發(fā)布渠道,獲取所述發(fā)布渠道對(duì)應(yīng)的資源文件和功能類;根據(jù)所述資源文件及所述功能類,對(duì)所述待打包文件進(jìn)行處理以生成滿足所述發(fā)布渠道所需執(zhí)行邏輯的可執(zhí)行文件;對(duì)所述可執(zhí)行文件進(jìn)行打包,得到所述發(fā)布渠道對(duì)應(yīng)的應(yīng)用安裝包。
可選地,上述根據(jù)待打包文件的發(fā)布渠道,獲取所述發(fā)布渠道對(duì)應(yīng)的資源文件和功能類,包括:根據(jù)預(yù)置的發(fā)布渠道與資源文件的對(duì)應(yīng)關(guān)系,獲取所述發(fā)布渠道對(duì)應(yīng)的資源文件;獲取gradle構(gòu)建工具目錄下的多個(gè)功能類;根據(jù)發(fā)布渠道的功能需求信息,從所述多個(gè)功能類中獲取與所述功能需求信息匹配的所述功能類。
可選地,根據(jù)所述資源文件及所述功能類,對(duì)所述待打包文件進(jìn)行處理以生成滿足所述發(fā)布渠道所需執(zhí)行邏輯的可執(zhí)行文件,包括:將所述資源文件與所述待打包文件進(jìn)行合并得到中間文件;將所述功能類添加到所述中間文件中得到所述可執(zhí)行文件。
可選地,將所述資源文件與所述待打包文件進(jìn)行合并得到中間文件,包括:若所述待打包文件中包含有與所述資源文件重名的子文件,則將所述子文件替換為所述資源文件得到所述中間文件;若所述待打包文件不包含與所述資源文件重名的子文件,則將所述資源文件添加到所述待打包文件中得到所述中間文件。
可選地,將所述功能類添加到所述中間文件中得到所述可執(zhí)行文件,包括:獲取所述中間文件中預(yù)留的添加位置;在所述添加位置處添加所述功能類得到所述可執(zhí)行文件。
在本發(fā)明的另一實(shí)施例中,提供了一種應(yīng)用安裝包打包裝置。該裝置包括:獲取模塊,用于根據(jù)待打包文件的發(fā)布渠道,獲取所述發(fā)布渠道對(duì)應(yīng)的資源文件和功能類;處理模塊,用于根據(jù)所述資源文件及所述功能類,對(duì)所述待打包文件進(jìn)行處理以生成滿足所述發(fā)布渠道所需執(zhí)行邏輯的可執(zhí)行文件;打包模塊,用于對(duì)所述可執(zhí)行文件進(jìn)行打包,得到所述發(fā)布渠道對(duì)應(yīng)的應(yīng)用安裝包。
本發(fā)明實(shí)施例提供的技術(shù)方案,根據(jù)待打包文件的發(fā)布渠道對(duì)應(yīng)的資源文件及功能類,對(duì)待打包文件進(jìn)行打包生成發(fā)布渠道對(duì)應(yīng)的應(yīng)用安裝包,使得應(yīng)用安裝包按照發(fā)布渠道所需執(zhí)行邏輯進(jìn)行運(yùn)行,例如按照資源文件確定應(yīng)用安裝包的展示形式以滿足發(fā)布渠道形式要求,通過調(diào)用功能類使應(yīng)用安裝包具有發(fā)布渠道所要求的具體業(yè)務(wù)功能;由此可知,本發(fā)明實(shí)施例提供的技術(shù)方案實(shí)現(xiàn)了針對(duì)不同發(fā)布渠道的自動(dòng)打包過程,避免了現(xiàn)有技術(shù)中人工手動(dòng)修改所帶來(lái)的諸多問題。
附圖說明
為了更清楚地說明本發(fā)明實(shí)施例或現(xiàn)有技術(shù)中的技術(shù)方案,下面將對(duì)實(shí)施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作一簡(jiǎn)單地介紹,顯而易見地,下面描述中的附圖是本發(fā)明的一些實(shí)施例,對(duì)于本領(lǐng)域普通技術(shù)人員來(lái)講,在不付出創(chuàng)造性勞動(dòng)的前提下,還可以根據(jù)這些附圖獲得其他的附圖。
圖1為本發(fā)明一實(shí)施例提供的應(yīng)用安裝包打包方法的流程示意圖;
圖2為本發(fā)明另一實(shí)施例提供的應(yīng)用安裝包打包方法的流程示意圖;
圖3為本發(fā)明一實(shí)施例提供的應(yīng)用安裝包打包裝置的結(jié)構(gòu)框圖。
具體實(shí)施方式
為了使本技術(shù)領(lǐng)域的人員更好地理解本發(fā)明方案,下面將結(jié)合本發(fā)明實(shí)施例中的附圖,對(duì)本發(fā)明實(shí)施例中的技術(shù)方案進(jìn)行清楚、完整地描述。
在本發(fā)明的說明書、權(quán)利要求書及上述附圖中描述的一些流程中,包含了按照特定順序出現(xiàn)的多個(gè)操作,這些操作可以不按照其在本文中出現(xiàn)的順序來(lái)執(zhí)行或并行執(zhí)行。操作的序號(hào)如101、102等,僅僅是用于區(qū)分各個(gè)不同的操作,序號(hào)本身不代表任何的執(zhí)行順序。另外,這些流程可以包括更多或更少的操作,并且這些操作可以按順序執(zhí)行或并行執(zhí)行。需要說明的是,本文中的“第一”、“第二”等描述,是用于區(qū)分不同的消息、設(shè)備、模塊等,不代表先后順序,也不限定“第一”和“第二”是不同的類型。
下面將結(jié)合本發(fā)明實(shí)施例中的附圖,對(duì)本發(fā)明實(shí)施例中的技術(shù)方案進(jìn)行清楚、完整地描述。顯然,所描述的實(shí)施例僅僅是本發(fā)明一部分實(shí)施例,而不是全部的實(shí)施例?;诒景l(fā)明中的實(shí)施例,本領(lǐng)域技術(shù)人員在沒有做出創(chuàng)造性勞動(dòng)前提下所獲得的所有其他實(shí)施例,都屬于本發(fā)明保護(hù)的范圍。
圖1示出了本發(fā)明一實(shí)施例提供的應(yīng)用安裝包打包方法的流程示意圖。如圖1所示,本實(shí)施例提供的所述方法,包括:
101、根據(jù)待打包文件的發(fā)布渠道,獲取所述發(fā)布渠道對(duì)應(yīng)的資源文件和功能類。
102、根據(jù)所述資源文件及所述功能類,對(duì)所述待打包文件進(jìn)行處理以生成滿足所述發(fā)布渠道所需執(zhí)行邏輯的可執(zhí)行文件。
103、對(duì)所述可執(zhí)行文件進(jìn)行打包,得到所述發(fā)布渠道對(duì)應(yīng)的應(yīng)用安裝包。
上述101中,所述發(fā)布渠道所需的資源文件中包含有:有關(guān)應(yīng)用安裝包展示形式的配置信息,例如,應(yīng)用安裝包在發(fā)布渠道的app市場(chǎng)中的展示圖標(biāo)大小信息、展示圖標(biāo)的樣式信息等等。每個(gè)發(fā)布渠道對(duì)應(yīng)有一個(gè)資源文件,即在具體實(shí)施時(shí),可預(yù)置發(fā)布渠道與資源文件的對(duì)應(yīng)關(guān)系。相應(yīng)的,上述的根據(jù)待打包文件的發(fā)布渠道,確定所述發(fā)布渠道所需的資源文件,可具體為:發(fā)布渠道與資源文件的對(duì)應(yīng)關(guān)系,獲取與所述發(fā)布渠道對(duì)應(yīng)的資源文件,并將獲取到的資源文件作為所述發(fā)布渠道所需的資源文件?;蛘撸鶕?jù)發(fā)布渠道的展示要求生成對(duì)應(yīng)的資源文件,即上述的根據(jù)待打包文件的發(fā)布渠道,確定所述發(fā)布渠道所需的資源文件,可具體為:獲取待打包文件的發(fā)布渠道的形式要求信息(例如圖片大小信息、展示樣式信息等等);根據(jù)所述形式要求信息,生成相應(yīng)的資源文件。功能類可以是實(shí)現(xiàn)具體功能的class()文件。一種可實(shí)現(xiàn)的技術(shù)方案是,本發(fā)明實(shí)施例提供的技術(shù)方案可采用gradle構(gòu)建工具來(lái)實(shí)現(xiàn)。gradle構(gòu)建工具會(huì)在其目錄下預(yù)先生成對(duì)應(yīng)不同功能的類。一個(gè)或多個(gè)功能類可對(duì)應(yīng)一種發(fā)布渠道。因此,上述獲取發(fā)布渠道對(duì)應(yīng)的功能類的過程可包括:獲取gradle構(gòu)建工具目錄下的多個(gè)功能類;根據(jù)發(fā)布渠道與功能類的對(duì)應(yīng)關(guān)系,從所述多個(gè)功能類中獲取所述發(fā)布渠道對(duì)應(yīng)的所述功能類。其中,獲取到的所述功能類可以是一個(gè),也可以是多個(gè)。功能類可包含但不限于:實(shí)現(xiàn)檢查更新功能的類、實(shí)現(xiàn)發(fā)布渠道對(duì)應(yīng)登錄方式的功能類等等。
上述102中對(duì)待打包文件進(jìn)行的處理包括:資源文件的合并處理以及功能類的添加處理。一種可實(shí)現(xiàn)的方案中,將所述資源文件與所述待打包文件進(jìn)行合并得到中間文件;將所述功能類添加到所述中間文件中得到所述可執(zhí)行文件。其中,合并處理及功能類的添加處理均可采用現(xiàn)有技術(shù)中的gradle構(gòu)建工具來(lái)實(shí)現(xiàn),例如,通過調(diào)用gradle構(gòu)建工具中對(duì)應(yīng)的執(zhí)行指令來(lái)實(shí)現(xiàn)。
上述103中對(duì)可執(zhí)行文件打包的過程可參見現(xiàn)有技術(shù)中的androidapp的打包流程,此處不再贅述。
本實(shí)施例提供的技術(shù)方案,根據(jù)待打包文件的發(fā)布渠道對(duì)應(yīng)的資源文件及功能類,對(duì)待打包文件進(jìn)行打包生成發(fā)布渠道對(duì)應(yīng)的應(yīng)用安裝包,使得應(yīng)用安裝包按照發(fā)布渠道所需執(zhí)行邏輯進(jìn)行運(yùn)行,例如按照資源文件確定應(yīng)用安裝包的展示形式以滿足發(fā)布渠道形式要求,通過調(diào)用功能類使應(yīng)用安裝包具有發(fā)布渠道所要求的具體業(yè)務(wù)功能;由此可知,本發(fā)明實(shí)施例提供的技術(shù)方案實(shí)現(xiàn)了針對(duì)不同發(fā)布渠道的自動(dòng)打包過程,避免了現(xiàn)有技術(shù)中人工手動(dòng)修改所帶來(lái)的諸多問題。
圖2示出了本發(fā)明另一實(shí)施例提供的應(yīng)用安裝包打包方法的流程示意圖。如圖2所示,所述方法包括:
201、根據(jù)待打包文件的發(fā)布渠道,獲取所述發(fā)布渠道對(duì)應(yīng)的資源文件和功能類。
202、若所述待打包文件中包含有與所述資源文件重名的子文件,則將所述子文件替換為所述資源文件得到所述中間文件。
203、若所述待打包文件不包含與所述資源文件重名的子文件,則將所述資源文件添加到所述待打包文件中得到所述中間文件。
204、獲取所述中間文件中預(yù)留的添加位置。
205、在所述添加位置處添加所述功能類得到所述可執(zhí)行文件。
206、對(duì)所述可執(zhí)行文件進(jìn)行打包,得到所述發(fā)布渠道對(duì)應(yīng)的應(yīng)用安裝包。
上述201可參見上述實(shí)施例中的相應(yīng)內(nèi)容,此處不再贅述。
上述202和203中,待打包文件通過情況下是包含有資源文件的,當(dāng)然也有例外(即不包含資源文件的情況)。不同的待打包文件中的資源文件的文件名是相同的。因此,在待打包文件中包含有資源文件時(shí),需將該資源文件替換為所述發(fā)布渠道對(duì)應(yīng)的資源文件。若待打包文件中不包含資源文件,則直接將所述發(fā)布渠道對(duì)應(yīng)的資源文件添加到待打包文件中即可。
上述204中,android應(yīng)用程序編寫過程中都會(huì)預(yù)留一些可進(jìn)行功能擴(kuò)展的擴(kuò)展位。通過在擴(kuò)展位中添加相應(yīng)的功能語(yǔ)句,即實(shí)現(xiàn)功能的擴(kuò)展。由此可知,本實(shí)施例即是通過將功能類添加到預(yù)留的擴(kuò)展位(即上述提到的添加位置)來(lái)實(shí)現(xiàn)功能擴(kuò)展以實(shí)現(xiàn)發(fā)布渠道所需的業(yè)務(wù)功能。
上述206中對(duì)可執(zhí)行文件打包的過程可參見現(xiàn)有技術(shù)中的androidapp的打包流程,此處不再贅述。
本實(shí)施例提供的技術(shù)方案,根據(jù)待打包文件的發(fā)布渠道對(duì)應(yīng)的資源文件及功能類,對(duì)待打包文件進(jìn)行打包生成發(fā)布渠道對(duì)應(yīng)的應(yīng)用安裝包,使得應(yīng)用安裝包按照發(fā)布渠道所需執(zhí)行邏輯進(jìn)行運(yùn)行,例如按照資源文件確定應(yīng)用安裝包的展示形式以滿足發(fā)布渠道形式要求,通過調(diào)用功能類使應(yīng)用安裝包具有發(fā)布渠道所要求的具體業(yè)務(wù)功能;由此可知,本發(fā)明實(shí)施例提供的技術(shù)方案實(shí)現(xiàn)了針對(duì)不同發(fā)布渠道的自動(dòng)打包過程,避免了現(xiàn)有技術(shù)中人工手動(dòng)修改所帶來(lái)的諸多問題。
下面以小米發(fā)布渠道為例對(duì)本發(fā)明實(shí)施例提供的技術(shù)方案進(jìn)行說明。
gradle構(gòu)建工具在構(gòu)建待打包文件(構(gòu)建的過程就是針對(duì)小米渠道對(duì)待打包文件進(jìn)行打包的過程)時(shí)會(huì)去判斷其工程里是不是有小米的工程包。若有,則執(zhí)行小米的功能包以將小米渠道對(duì)應(yīng)的資源文件與待打包文件的main()文件進(jìn)行合并。合并過程可參見上述各實(shí)施例中的相應(yīng)內(nèi)容,此處不再贅述。在預(yù)先留好添加位置的main()文件里面添加小米渠道對(duì)應(yīng)的class()類文件得到可執(zhí)行文件,對(duì)可執(zhí)行文件進(jìn)行打包得到小米渠道對(duì)應(yīng)的應(yīng)用安裝包。應(yīng)用安裝包下發(fā)到小米渠道的平臺(tái)后,基于應(yīng)用安裝包中的資源文件指向的展示形式在小米平臺(tái)上展示應(yīng)用安裝包。用戶若通過小米渠道的平臺(tái)下載該應(yīng)用安裝包并進(jìn)行本地安裝時(shí),會(huì)對(duì)main()文件中的功能類進(jìn)行類名的判斷;若mian()文件中存在有指定類名的功能類,則調(diào)用該功能類,以執(zhí)行該功能類對(duì)應(yīng)的邏輯行為;否則,不執(zhí)行該功能對(duì)應(yīng)的邏輯行為。
需要說明的是:上述實(shí)施例所提供方法的各步驟的執(zhí)行主體均可以是同一設(shè)備,或者,該方法也由不同設(shè)備作為執(zhí)行主體。比如,步驟101至步驟103的執(zhí)行主體可以為設(shè)備a;又比如,步驟101和102的執(zhí)行主體可以為設(shè)備a,步驟103的執(zhí)行主體可以為設(shè)備b;等等。
圖3示出了本發(fā)明一實(shí)施例提供的應(yīng)用安裝包打包裝置的結(jié)構(gòu)示意圖。如圖3所示,所述裝置包括:獲取模塊301用于根據(jù)待打包文件的發(fā)布渠道,獲取所述發(fā)布渠道對(duì)應(yīng)的資源文件和功能類;處理模塊302用于根據(jù)所述資源文件及所述功能類,對(duì)所述待打包文件進(jìn)行處理以生成滿足所述發(fā)布渠道所需執(zhí)行邏輯的可執(zhí)行文件;打包模塊303用于對(duì)所述可執(zhí)行文件進(jìn)行打包,得到所述發(fā)布渠道對(duì)應(yīng)的應(yīng)用安裝包。
本實(shí)施例提供的技術(shù)方案,根據(jù)待打包文件的發(fā)布渠道對(duì)應(yīng)的資源文件及功能類,對(duì)待打包文件進(jìn)行打包生成發(fā)布渠道對(duì)應(yīng)的應(yīng)用安裝包,使得應(yīng)用安裝包按照發(fā)布渠道所需執(zhí)行邏輯進(jìn)行運(yùn)行,例如按照資源文件確定應(yīng)用安裝包的展示形式以滿足發(fā)布渠道形式要求,通過調(diào)用功能類使應(yīng)用安裝包具有發(fā)布渠道所要求的具體業(yè)務(wù)功能;由此可知,本發(fā)明實(shí)施例提供的技術(shù)方案實(shí)現(xiàn)了針對(duì)不同發(fā)布渠道的自動(dòng)打包過程,避免了現(xiàn)有技術(shù)中人工手動(dòng)修改所帶來(lái)的諸多問題。
進(jìn)一步的,所述獲取模塊,還用于:根據(jù)預(yù)置的發(fā)布渠道與資源文件的對(duì)應(yīng)關(guān)系,獲取所述發(fā)布渠道對(duì)應(yīng)的資源文件;獲取gradle構(gòu)建工具目錄下的多個(gè)功能類;根據(jù)發(fā)布渠道的功能需求信息,從所述多個(gè)功能類中獲取與所述功能需求信息匹配的所述功能類。
進(jìn)一步的,所述處理模塊,包括:合并單元,用于將所述資源文件與所述待打包文件進(jìn)行合并得到中間文件;添加單元,用于將所述功能類添加到所述中間文件中得到所述可執(zhí)行文件。
進(jìn)一步的,所述合并單元,還用于:若所述待打包文件中包含有與所述資源文件重名的子文件,則將所述子文件替換為所述資源文件得到所述中間文件;若所述待打包文件不包含與所述資源文件重名的子文件,則將所述資源文件添加到所述待打包文件中得到所述中間文件。
進(jìn)一步的,所述添加單元,還用于:獲取所述中間文件中預(yù)留的添加位置;在所述添加位置處添加所述功能類得到所述可執(zhí)行文件。
這里需要說明的是:上述實(shí)施例提供的應(yīng)用安裝包打包裝置可實(shí)現(xiàn)上述各方法實(shí)施例中描述的技術(shù)方案,上述各模塊或單元具體實(shí)現(xiàn)的原理可參見上述各方法實(shí)施例中的相應(yīng)內(nèi)容,此處不再贅述。
以上所描述的裝置實(shí)施例僅僅是示意性的,其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的,作為單元顯示的部件可以是或者也可以不是物理單元,即可以位于一個(gè)地方,或者也可以分布到多個(gè)網(wǎng)絡(luò)單元上??梢愿鶕?jù)實(shí)際的需要選擇其中的部分或者全部模塊來(lái)實(shí)現(xiàn)本實(shí)施例方案的目的。本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性的勞動(dòng)的情況下,即可以理解并實(shí)施。
通過以上的實(shí)施方式的描述,本領(lǐng)域的技術(shù)人員可以清楚地了解到各實(shí)施方式可借助軟件加必需的通用硬件平臺(tái)的方式來(lái)實(shí)現(xiàn),當(dāng)然也可以通過硬件?;谶@樣的理解,上述技術(shù)方案本質(zhì)上或者說對(duì)現(xiàn)有技術(shù)做出貢獻(xiàn)的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來(lái),該計(jì)算機(jī)軟件產(chǎn)品可以存儲(chǔ)在計(jì)算機(jī)可讀存儲(chǔ)介質(zhì)中,如rom/ram、磁碟、光盤等,包括若干指令用以使得一臺(tái)計(jì)算機(jī)設(shè)備(可以是個(gè)人計(jì)算機(jī),服務(wù)器,或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行各個(gè)實(shí)施例或者實(shí)施例的某些部分所述的方法。
最后應(yīng)說明的是:以上實(shí)施例僅用以說明本發(fā)明的技術(shù)方案,而非對(duì)其限制;盡管參照前述實(shí)施例對(duì)本發(fā)明進(jìn)行了詳細(xì)的說明,本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解:其依然可以對(duì)前述各實(shí)施例所記載的技術(shù)方案進(jìn)行修改,或者對(duì)其中部分技術(shù)特征進(jìn)行等同替換;而這些修改或者替換,并不使相應(yīng)技術(shù)方案的本質(zhì)脫離本發(fā)明各實(shí)施例技術(shù)方案的精神和范圍。