本發明涉及計算機技術領域,尤其涉及一種應用安裝包發送方法及裝置。
背景技術:
隨著智能手機的大量普及,各類針對智能手機的應用產品越來越多。人們對應用產品上線質量的要求越來越高,因此應用產品在上線之前需進行內部的測試和/或內部使用體驗等等。
現有技術中,開發人員通過計算機將應用產品的安裝包(如ipa/apk)發送至指定用戶(如測試人員或體驗人員)的公司內部郵箱。測試/體驗人員在工作中使用計算機通過查收內部郵箱來獲取ipa/apk。現有技術不僅在郵件發送時需將好幾十兆的安裝包進行傳送,且測試/體驗人員在接收到ipa/apk后要在手機中安裝還比較麻煩,測試/體驗人員在安裝時需要通過數據線將手機與計算機進行連接,然后進行下載及安裝。
技術實現要素:
本發明實施例提供一種應用安裝包發送方法及裝置,用以解決現有技術中應用安裝包在手機中安裝比較麻煩的問題。
于是,在本發明的一個實施例中,提供了一種應用安裝包發送方法。該方法包括:獲取欲通過電子郵件發送至目標用戶的應用安裝包的下載地址;調用二維碼生成器將所述下載地址生成二維碼;將所述二維碼插入所述電子郵件發送至所述目標用戶。
可選地,上述獲取欲通過電子郵件發送至目標用戶的應用安裝包的下載地址,包括:向服務端發送攜帶有所述應用安裝包標識的地址獲取請求;接收所述服務端反饋的所述下載地址。
可選地,上述實施例提供的方法還可包括:獲取可執行文件;根據所述可執行文件中的代碼類型,選擇所述代碼類型對應的打包工具對所述可執行文件進行打包生成所述應用安裝包;將所述應用安裝包上傳至服務端。
可選地,上述獲取可執行文件,包括:定期對項目倉庫進行更新檢測;若檢測到所述項目倉庫中有更新的可執行文件,則從所述項目倉庫中拉取所述可執行文件。或者,所述獲取可執行文件,包括:響應于客戶端提交的文件獲取請求,從所述項目倉庫中拉取所述文件獲取請求指向的所述可執行文件。
可選地,上述實施例提供的方法還可包括:獲取為所述應用安裝包指定的分發類型;根據所述分發類型,從用戶群中查找屬于所述分發類型的用戶作為所述目標用戶。
在本發明的另一實施例中,提供了一種應用安裝包發送裝置。該裝置包括:第一獲取模塊,用于獲取欲通過電子郵件發送至目標用戶的應用安裝包的下載地址;生成模塊,用于調用二維碼生成器將所述下載地址生成二維碼;發送模塊,用于將所述二維碼插入所述電子郵件發送至所述目標用戶。
本發明實施例提供的技術方案,通過將應用安裝包的下載地址生成二維碼,并將二維碼插入電子郵件發送至目標用戶的方式,使得郵件傳輸時僅傳輸下載地址對應的二維碼;目標用戶在通過郵件接收到應用安裝包后可直接使用手機掃描電子郵件中的二維碼獲取下載地址,并基于該下載地址下載對應的應用安裝包,目標用戶無需使用數據線連接計算機,下載安裝更加簡便。
附圖說明
為了更清楚地說明本發明實施例或現有技術中的技術方案,下面將對實施例或現有技術描述中所需要使用的附圖作一簡單地介紹,顯而易見地,下面描述中的附圖是本發明的一些實施例,對于本領域普通技術人員來講,在不付出創造性勞動的前提下,還可以根據這些附圖獲得其他的附圖。
圖1為本發明一實施例提供的應用安裝包發送方法的流程示意圖;
圖2為本發明另一實施例提供的應用安裝包發送方法的流程示意圖;
圖3為本發明一實施例提供的應用安裝包發送裝置的結構框圖。
具體實施方式
為了使本技術領域的人員更好地理解本發明方案,下面將結合本發明實施例中的附圖,對本發明實施例中的技術方案進行清楚、完整地描述。
在本發明的說明書、權利要求書及上述附圖中描述的一些流程中,包含了按照特定順序出現的多個操作,這些操作可以不按照其在本文中出現的順序來執行或并行執行。操作的序號如101、102等,僅僅是用于區分各個不同的操作,序號本身不代表任何的執行順序。另外,這些流程可以包括更多或更少的操作,并且這些操作可以按順序執行或并行執行。需要說明的是,本文中的“第一”、“第二”等描述,是用于區分不同的消息、設備、模塊等,不代表先后順序,也不限定“第一”和“第二”是不同的類型。
下面將結合本發明實施例中的附圖,對本發明實施例中的技術方案進行清楚、完整地描述。顯然,所描述的實施例僅僅是本發明一部分實施例,而不是全部的實施例。基于本發明中的實施例,本領域技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例,都屬于本發明保護的范圍。
圖1示出了本發明一實施例提供的應用安裝包發送方法的流程示意圖。本實施例提供的所述方法的執行主體可以是服務端。如圖1所示,本實施例提供的應用安裝包發送方法包括:
101、獲取欲通過電子郵件發送至目標用戶的應用安裝包的下載地址。
102、調用二維碼生成器將所述下載地址生成二維碼。
103、將所述二維碼插入所述電子郵件發送至所述目標用戶。
上述101中,目標用戶可以是:測試人員、產品開發人員、產品運營人員等等。在具體實施時,可根據用戶的職能對用戶進行分組。一種可實現的技術方案是,獲取用戶的職能屬性;然后將所述用戶劃分至所述職能屬性對應的分組中。其中,用戶的職能屬性可以包括但不限于:用戶所屬部門、所處項目組信息等等。這些信息與該信息對應的用戶信息(用戶標識)被關聯地存儲。每個分組中包含有該組內用戶的標識(如姓名)及通信方式(例如郵箱地址)。每個分組對應一種分發類型,分發類型可根據該分組內用戶的職能屬性來確定,例如,若某一個分組內用戶的職能屬性包括測試部門,則該分組的分發類型為應用測試類型;若某一個分組內用戶的職能屬性包括產品運營部門,則該分組的分發類型可以為應用體驗類型;等等。此處只列舉出了一種可實現方案,實際應用中可根據設計需求人為配置,本發明實施例對此不作具體限定。其中,分組與分發類型的對應關系可預先設置,便于后續根據應用安裝包的分發類型獲取對應的分組,在該分組內的用戶即為目標用戶。例如,在一種可實現的技術方案中,應用安裝包在上傳之前,人為地為應用安裝包指定對應的分發類型。相應的,上述101中目標用戶的確定過程可具體如下:獲取為所述應用安裝包指定的分發類型;根據所述分發類型,從用戶群中查找屬于所述分發類型的用戶作為所述目標用戶。
上述101中,應用安裝包的下載地址可從服務端側獲得。例如:向服務端發送攜帶有所述應用安裝包標識的地址獲取請求;接收所述服務端反饋的所述下載地址。
上述102中調用二維碼生成器將所述下載地址生成二維碼,實質上就是:將下載地址導入二維碼生成器,基于二維碼生成器的二維碼生成算法計算得到二維碼。其中,二維碼生成算法就是將組成二維碼的0、1數字矩陣進行組合計算的過程。本實施例中的二維碼生成器可選用現有技術中已有的二維碼生成器,例如labelpainter,bartender,labelmx等。
上述103中,將二維碼插入所述電子郵件的目的就是為了將二維碼顯示在電子郵件的郵件內容界面中,便于用戶通過掃描電子郵件中的二維碼的方式下載應用安裝包。
本實施例提供的技術方案,通過將應用安裝包的下載地址生成二維碼,并將二維碼插入電子郵件發送至目標用戶的方式,使得郵件傳輸時僅傳輸下載地址對應的二維碼;目標用戶在通過郵件接收到應用安裝包后可直接使用手機掃描電子郵件中的二維碼獲取下載地址,并基于該下載地址下載對應的應用安裝包,目標用戶無需使用數據線連接計算機,下載安裝更加簡便。
圖2示出了本發明另一實施例提供的應用安裝包發送方法的流程示意圖。如圖2所示,本實施例提供的所述方法包括:
201、獲取可執行文件。
202、根據所述可執行文件中代碼的類型,選擇所述類型對應的打包工具對所述可執行文件進行打包生成所述應用安裝包。
203、將所述應用安裝包上傳至服務端。
204、從所述服務端獲取欲通過電子郵件發送至目標用戶的應用安裝包的下載地址。
205、調用二維碼生成器將所述下載地址生成二維碼。
206、將所述二維碼插入所述電子郵件發送至所述目標用戶。
上述201中獲取可執行文件可采用如下步驟實現:
s1、定期對項目倉庫進行更新檢測;
s2、若檢測到所述項目倉庫中有更新的可執行文件,則從所述項目倉庫中拉取所述可執行文件。
或者,上述201中獲取可執行文件可采用如下步驟實現:響應于客戶端提交的文件獲取請求,從所述項目倉庫中拉取所述文件獲取請求指向的所述可執行文件。
上述兩個實現方法實質上就是兩種可執行文件獲取的觸發策略。前述定期檢測更新的觸發策略是一種被動觸發方式。產品開發人員在完成某一項目的可執行文件的編寫后,欲對該可執行文件進行測試或體驗反饋時,可將完成的可執行文件上傳至項目倉庫中;同時可為項目倉庫配置一個更新狀態檢測模塊,以實時檢測項目倉庫中是否有更新的可執行文件;若檢測到所述項目倉庫中有更新的可執行文件,則觸發從所述項目倉庫中拉取所述可執行文件,以便后續對拉取到的可執行文件進行打包、二維碼生成及發送。前述客戶端提交的觸發策略是一種主動觸發方式,即由產品開發人員將完成的可執行文件上傳至項目倉庫后向打包模塊發送拉取請求,以便打包模塊對拉取到的可執行文件進行打包,進而完成后續二維碼生成及發送。當然,除了上述兩種觸發策略外,本實施例還可采用定期拉取策略。即定期(如1小時、12小時、24小時等等)從項目倉庫中拉取前次拉取時刻到當前時刻內新添加的可執行文件,以便后續對拉取到的可執行文件進行打包、二維碼生成及發送。
上述202中,代碼的類型可以包括:ios代碼類型或安卓(andriod)代碼類型等等。目前,很多應用都包含有ios版和android版,以適用不同操作系統的終端。針對不同代碼類型的應用,其所采用的打包工具也是不同的。因此,可預先為不同代碼類型的應用安裝包配置對應的打包工具。一種可實現的方案是,預置代碼類型與打包工具的對應關系;根據代碼類型與打包工具的對應關系,選擇所述可行文件中代碼的類型對應的打包工具對可執行文件進行打包生成所述應用安裝包。
上述204中,從所述服務端獲取欲通過電子郵件發送至目標用戶的應用安裝包的下載地址的過程可參見上述實施例中的相應內容,此處不再贅述。其中,從服務端獲取到的下載地址可以是應用安裝包在服務端側的存儲地址。
上述205和206可參見上述實施例的相應內容此處不再贅述。
本實施例提供的技術方案,通過將應用安裝包的下載地址生成二維碼,并將二維碼插入電子郵件發送至目標用戶的方式,使得郵件傳輸時僅傳輸下載地址對應的二維碼;目標用戶在通過郵件接收到應用安裝包后可直接使用手機掃描電子郵件中的二維碼獲取下載地址,并基于該下載地址下載對應的應用安裝包,目標用戶無需使用數據線連接計算機,下載安裝更加簡便。
本發明實施例提供的技術方案可采用jenkins來實現。jenkins是基于java開發的一種持續集成工具,用于監控持續重復的工作,因此可采用jenkins來實現持續的軟件版本發布/測試項目。本發明實施例就是根據項目需求,現有在團隊內部搭建一個統一的打包平臺,實現對ios和android項目的打包。而且為了方便團隊內部的測試包分發,希望在打包完成后能生成一個二維碼,體驗用戶(產品、運營、測試等人員)通過手機掃描二維碼后就能直接下載安裝測試包。
該平臺主要實現的功能有如下三個:
功能一、按照觸發策略從github倉庫(項目倉庫)中拉取可執行文件,將可執行文件進行打包生成應用安裝包并將其上傳至服務端。
功能二、獲取應用安裝包的下載地址,根據下載地址生成二維碼。
功能三、將二維碼插入到電子郵件內并發送至目標用戶。
在jenkins中,將拉取可執行文件并對其進行打包的過程稱為一個構建項目。構建項目以job的形式存在,因此需要針對每個項目創建一個job。有時候,一個項目中可能有多個分支同時在進行開發,為了分別進行構建,也可以針對每個分支創建一個job。上述觸發策略包括但不限于:定期檢測更新的觸發策略、客戶端提交的觸發策略、定期拉取策略等等。上述策略可擇一,也可多選;若具有上述多種策略,則任一觸發策略滿足就會被觸發。
常用的打包方式是根據可執行文件的代碼類型,安裝對應的插件,然后采用相應的打包方式對其進行打包。例如,若是構建android應用,安裝gradleplugin之后,就可以選擇invokegradlescript,然后采用gradle進行構建;若是構建ios應用,安裝xcodeintegration插件之后,就可以選擇xcode,然后選擇xcode進行構建。另外,對于ios應用的打包還有一個需要額外關注的點,就是開發者證書的配置。如果是采用xcodeintegration插件進行打包需要在jenkins中導入開發證書,并填寫多個配置項。
需要說明的是:上述實施例所提供方法的各步驟的執行主體均可以是同一設備,或者,該方法也由不同設備作為執行主體。比如,步驟101至步驟103的執行主體可以為設備a;又比如,步驟101和102的執行主體可以為設備a,步驟103的執行主體可以為設備b;等等。
圖3示出了本發明一實施例提供的應用安裝包發送裝置的結構框圖。如圖3所示,所述應用安裝包發送裝置包括:第一獲取模塊301、生成模塊302和發送模塊303。其中,第一獲取模塊301用于獲取欲通過電子郵件發送至目標用戶的應用安裝包的下載地址;生成模塊302用于調用二維碼生成器將所述下載地址生成二維碼;發送模塊303用于將所述二維碼插入所述電子郵件發送至所述目標用戶。
本實施例提供的技術方案,通過將應用安裝包的下載地址生成二維碼,并將二維碼插入電子郵件發送至目標用戶的方式,使得郵件傳輸時僅傳輸下載地址對應的二維碼;目標用戶在通過郵件接收到應用安裝包后可直接使用手機掃描電子郵件中的二維碼獲取下載地址,并基于該下載地址下載對應的應用安裝包,目標用戶無需使用數據線連接計算機,下載安裝更加簡便。
進一步的,所述第一獲取模塊301還可用于:向服務端發送攜帶有所述應用安裝包標識的地址獲取請求;接收所述服務端反饋的所述下載地址。
進一步的,上述實施例提供的所述裝置還可包括:第二獲取模塊、打包模塊和上傳模塊。其中,第二獲取模塊用于獲取可執行文件;打包模塊用于根據所述可執行文件中的代碼類型,選擇所述代碼類型對應的打包工具對所述可執行文件進行打包生成所述應用安裝包;上傳模塊用于將所述應用安裝包上傳至服務端。
進一步的,上述的第二獲取模塊還可用于:定期對項目倉庫進行更新檢測;若檢測到所述項目倉庫中有更新的可執行文件,則從所述項目倉庫中拉取所述可執行文件。或者,上述第二獲取模塊還用于:響應于客戶端提交的文件獲取請求,從所述項目倉庫中拉取所述文件獲取請求指向的所述可執行文件。
進一步的,上述應用安裝包發送裝置還可包括:第三獲取模塊和查找模塊。其中,第三獲取模塊用于獲取為所述應用安裝包指定的分發類型;查找模塊用于根據所述分發類型,從用戶群中查找屬于所述分發類型的用戶作為所述目標用戶。
這里需要說明的是:上述實施例提供的應用安裝包發送裝置可實現上述各方法實施例中描述的技術方案,上述各模塊或單元具體實現的原理可參見上述各方法實施例中的相應內容,此處不再贅述。
以上所描述的裝置實施例僅僅是示意性的,其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的,作為單元顯示的部件可以是或者也可以不是物理單元,即可以位于一個地方,或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部模塊來實現本實施例方案的目的。本領域普通技術人員在不付出創造性的勞動的情況下,即可以理解并實施。
通過以上的實施方式的描述,本領域的技術人員可以清楚地了解到各實施方式可借助軟件加必需的通用硬件平臺的方式來實現,當然也可以通過硬件。基于這樣的理解,上述技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來,該計算機軟件產品可以存儲在計算機可讀存儲介質中,如rom/ram、磁碟、光盤等,包括若干指令用以使得一臺計算機設備(可以是個人計算機,服務器,或者網絡設備等)執行各個實施例或者實施例的某些部分所述的方法。
最后應說明的是:以上實施例僅用以說明本發明的技術方案,而非對其限制;盡管參照前述實施例對本發明進行了詳細的說明,本領域的普通技術人員應當理解:其依然可以對前述各實施例所記載的技術方案進行修改,或者對其中部分技術特征進行等同替換;而這些修改或者替換,并不使相應技術方案的本質脫離本發明各實施例技術方案的精神和范圍。