一种app生成方法、装置、处理设备及计算机可读存储介质与流程

文档序号:24413784发布日期:2021-03-26 20:26阅读:97来源:国知局
一种app生成方法、装置、处理设备及计算机可读存储介质与流程

1.本申请涉及应用领域,具体涉及一种app生成方法、装置、处理设备及计算机可读存储介质。


背景技术:

2.在应用(application,app)的开发过程中,涉及到一个编译的处理,将代码等源文件进行编译,方可打包得到一款app的安装包。
3.而编译处理,一般是根据app的操作系统进行适配性调整的,当然,随着不同的操作系统,app的功能以及背后的代码等文件,也会做一些适配性的调整,例如在ios和android两种操作系统中,即时对于应用用户感知而言实现的是相同的应用功能,但是其背后的代码也是不同的。
4.而在现有的相关技术的研究过程中,发明人发现,针对ios操作系统进行app的编译处理时,存在编译效率较慢的情况,而在app的开发过程中,app往往需要多次调整、修正缺陷(bug),这意味着涉及到多次的编译处理,在该情况下,较慢的编译效率愈加凸显对于整体app开发效率造成的不良影响。


技术实现要素:

5.本申请提供了一种app生成方法、装置、处理设备及计算机可读存储介质,用于在一定程度上提高app生成过程中的编译效率,从而提高app的生成效率。
6.第一方面,本申请提供了一种app生成方法,方法包括:处理设备在xcode中确定目标target;处理设备以pod形式集成目标target的初始xcassets,并保留初始xcassets中的app桌面图标,得到目标xcassets,其中,初始xcassets为asset catalog管理的资源;处理设备通过cocoapods配置的脚本,对cocoapods配置的代码资源以及目标xcassets进行编译处理;处理设备根据编译结果,打包生成目标target对应的app。
7.结合本申请第一方面,在本申请第一方面第一种可能的实现方式中,处理设备以pod形式集成目标target的初始xcassets,包括:处理设备通过cocoapods配置的自定义插件,以pod形式集成目标target的初始xcassets,并在集成完成后生成脚本以及buildphase,其中,自定义插件声明于podfile中;处理设备通过cocoapods配置的脚本,对cocoapods配置的代码资源块以及目标xcassets进行编译处理,包括:处理设备通过脚本以及buildphase,分离cocoapods配置的代码资源以及xcassets资源,并对资源进行编译处理,其中,代码资源包括xib资源、storyboard资源。
8.结合本申请第一方面第一种可能的实现方式,在本申请第一方面第二种可能的实现方式中,目标xcassets对应的脚本以及第一buildphase的生成处理,包括:
处理设备获取目标xcassets的第一路径,第一路径包括目标xcassets中在不同configuration下不同xcassets的路径;处理设备将第一路径记录进第一文件中,第一文件用于确定cocoapods管理的xcassets路径;处理设备生成动态获取xcassets的脚本,其中,动态获取xcassets的脚本用于在编译时使用xcodeproj获取当前target中所有xcassets路径;处理设备生成第一目标编译脚本,其中,第一目标编译脚本用于编译目标xcassets;处理设备通过xcodeproj将第一目标编译脚本添加至第一buildphase。
9.结合本申请第一方面第二种可能的实现方式,在本申请第一方面第三种可能的实现方式中,第一buildphase还配置有:记录参与编译的第一xcassets的第一修改时间并将第一xcassets缓存为assets.car;当下一次编译时,确定参与编译的第二xcassets,比较第一修改时间与第二xcassets的第二修改时间;若一致,则复制assets.car至app的编译产物目录。
10.结合本申请第一方面第一种可能的实现方式,在本申请第一方面第四种可能的实现方式中,代码资源对应的脚本以及第二buildphase的生成处理,包括:处理设备获取xib资源以及storyboard资源两者的第二路径;处理设备将第二路径记录进第二文件中,第二文件用于确定cocoapods管理的xib资源路径以及storyboard资源路径;处理设备生成第二目标编译脚本,其中,第二目标编译脚本用于并行编译xib资源以及storyboard资源;处理设备通过xcodeproj将第二目标编译脚本添加至第二buildphase,并设置对应的inputpath以及outputpath。
11.结合本申请第一方面第一种可能的实现方式,在本申请第一方面第五种可能的实现方式中,方法还包括:处理设备在cocoapods原有的buildphase中,移除脚本涉及的资源,并调整对应的inputpath以及outputpath。
12.结合本申请第一方面第一种可能的实现方式,在本申请第一方面第六种可能的实现方式中,在buildphase中,目标xcassets对应的buildphase的排序在copy bundle resource之后。
13.第二方面,本申请提供了一种app生成装置,装置包括:确定单元,用于在xcode中确定目标target;集成单元,用于以pod形式集成目标target的初始xcassets,并保留初始xcassets中的app桌面图标,得到目标xcassets,其中,初始xcassets为asset catalog管理的资源;编译单元,用于通过cocoapods配置的脚本,对cocoapods配置的代码资源以及目标xcassets进行编译处理;打包单元,用于根据编译结果,打包生成目标target对应的app。
14.结合本申请第二方面,在本申请第二方面第一种可能的实现方式中,集成单元,具体用于:通过cocoapods配置的自定义插件,以pod形式集成目标target的初始xcassets;装置还包括生成单元,用于在集成完成后生成脚本以及buildphase,其中,自定义插件声明于podfile中;编译单元,具体用于:通过脚本以及buildphase,分离cocoapods配置的代码资源以及xcassets资源,并对资源进行编译处理,其中,代码资源包括xib资源、storyboard资源。
15.结合本申请第二方面第一种可能的实现方式,在本申请第二方面第二种可能的实现方式中,生成单元具体用于执行目标xcassets对应的脚本以及第一buildphase的生成处理,包括:获取目标xcassets的第一路径,其中,第一路径包括目标xcassets中在不同configuration下不同xcassets的路径;将第一路径记录进第一文件中,其中,第一文件用于确定cocoapods管理的xcassets路径;生成动态获取xcassets的脚本,其中,动态获取xcassets的脚本用于在编译时使用xcodeproj获取当前target中所有xcassets路径;生成第一目标编译脚本,其中,第一目标编译脚本用于编译目标xcassets;通过xcodeproj将第一目标编译脚本添加至第一buildphase。
16.结合本申请第二方面第二种可能的实现方式,在本申请第二方面第三种可能的实现方式中,第一buildphase还配置有:记录参与编译的第一xcassets的第一修改时间并将第一xcassets缓存为assets.car;当下一次编译时, 确定参与编译的第二xcassets,比较第一修改时间与第二xcassets的第二修改时间;若一致,则复制assets.car至app的编译产物目录。
17.结合本申请第二方面第一种可能的实现方式,在本申请第二方面第四种可能的实现方式中,生成单元具体用于执行代码资源对应的脚本以及第二buildphase的生成处理,包括:获取xib资源以及storyboard资源两者的第二路径;将第二路径记录进第二文件中,其中,第二文件用于确定cocoapods管理的xib资源路径以及storyboard资源路径;生成第二目标编译脚本,其中,第二目标编译脚本用于并行编译xib资源以及storyboard资源;通过xcodeproj将第二目标编译脚本添加至第二buildphase,并设置对应的inputpath以及outputpath。
18.结合本申请第二方面第一种可能的实现方式,在本申请第二方面第五种可能的实现方式中,装置还包括移除单元,用于:在cocoapods原有的buildphase中,移除脚本涉及的资源,并调整对应的
inputpath以及outputpath。
19.结合本申请第二方面第一种可能的实现方式,在本申请第二方面第六种可能的实现方式中,在buildphase中,目标xcassets对应的buildphase的排序在copy bundle resource之后。
20.第三方面,本申请提供了一种处理设备,包括处理器和存储器,存储器中存储有计算机程序,处理器调用存储器中的计算机程序时执行本申请第一方面或者本申请第一方面任一种可能的实现方式提供的方法。
21.第四方面,本申请提供了一种计算机可读存储介质,计算机可读存储介质存储有多条指令,指令适于处理器进行加载,以执行本申请第一方面或者本申请第一方面任一种可能的实现方式提供的方法。
22.从以上内容可得出,本申请具有以下的有益效果:针对于ios操作系统的app的生成处理,本申请先在xcode中确定app对应的目标target,再以pod形式集成目标target的初始xcassets,并保留初始xcassets中的app桌面图标,得到目标xcassets,再通过cocoapods配置的脚本,对cocoapods配置的代码资源以及目标xcassets进行编译处理,如此根据编译结果,打包生成目标target对应的app,在涉及的编译处理中,由于以pod的形式集成了初始xcassets,如此cocoapods配置的脚本对集成得到的目标xcassets以及代码资源进行编译时,可在一定程度上减少现有技术中cocoapods统一处理xcassets以及代码资源、重复编译xcassets以及代码资源的情况,明显降低重复编译处理的资源,如此减少了编译处理的耗时,提高app生成过程中的编译效率,从而提高app的生成效率。
附图说明
23.为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
24.图1为本申请app生成方法的一种流程示意图;图2为本申请增量编译的一种流程示意图;图3为本申请app生成装置的一种结构示意图;图4为本申请处理设备的一种结构示意图。
具体实施方式
25.下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
26.本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实
施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块。在本申请中出现的对步骤进行的命名或者编号,并不意味着必须按照命名或者编号所指示的时间/逻辑先后顺序执行方法流程中的步骤,已经命名或者编号的流程步骤可以根据要实现的技术目的变更执行次序,只要能达到相同或者相类似的技术效果即可。
27.本申请中所出现的模块的划分,是一种逻辑上的划分,实际应用中实现时可以有另外的划分方式,例如多个模块可以结合成或集成在另一个系统中,或一些特征可以忽略,或不执行,另外,所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,模块之间的间接耦合或通信连接可以是电性或其他类似的形式,本申请中均不作限定。并且,作为分离部件说明的模块或子模块可以是也可以不是物理上的分离,可以是也可以不是物理模块,或者可以分布到多个电路模块中,可以根据实际的需要选择其中的部分或全部模块来实现本申请方案的目的。
28.在介绍本申请提供的app生成方法之前,首先介绍本申请所涉及的背景内容。
29.本申请提供的app生成方法、装置以及计算机可读存储介质,可应用于处理设备上,用于在一定程度上提高app生成过程中的编译效率,从而提高app的生成效率。
30.本申请提及的app生成方法,其执行主体可以为app生成装置,或者集成了app生成装置的服务器、物理主机或者用户设备(user equipment,ue)等不同类型的处理设备。其中,app生成装置可以采用硬件或者软件的方式实现,ue具体可以为智能手机、平板电脑、笔记本电脑、台式电脑或者个人数字助理(personal digital assistant,pda)等终端设备,处理设备可以通过设备集群的方式设置。
31.下面,开始介绍本申请提供的app生成方法。
32.首先,参阅图1,图1示出了本申请app生成方法的一种流程示意图,本申请提供的app生成方法,具体可包括如下步骤:步骤s101,处理设备在xcode中确定目标target;步骤s102,处理设备以pod形式集成目标target的初始xcassets,并保留初始xcassets中的app桌面图标,得到目标xcassets文其中,初始xcassets为asset catalog管理的资源;步骤s103,处理设备通过cocoapods配置的脚本,对cocoapods配置的代码资源以及目标xcassets进行编译处理;步骤s104,处理设备根据编译结果,打包生成目标target对应的app。
33.从图1所示实施例可看出,针对于ios操作系统的app的生成处理,本申请先在xcode中确定app对应的目标target,再以pod形式集成目标target的初始xcassets,并保留初始xcassets中的app桌面图标,得到目标xcassets,再通过cocoapods配置的脚本,对cocoapods配置的代码资源以及目标xcassets进行编译处理,如此根据编译结果,打包生成目标target对应的app,在涉及的编译处理中,由于以pod的形式集成了初始xcassets,如此cocoapods配置的脚本对集成得到的目标xcassets以及代码资源进行编译时,可在一定程度上减少现有技术中cocoapods统一处理xcassets以及代码资源、重复编译xcassets以及代码资源的情况,明显降低重复编译处理的资源,如此减少了编译处理的耗时,提高app生
成过程中的编译效率,从而提高app的生成效率。
34.下面则对上述图1所示实施例的各个步骤及其在实际应用中可能的实现方式进行详细阐述。
35.首先,可以理解的是,本申请app生成方法,是针对ios操作系统、ios平台或者说ios应用环境所提出来的,其所期望生成的app是在ios操作系统中运行的,类似的,该app的生成项目,也是针对ios操作系统执行的。
36.而app的生成项目,在本申请中,是在ios的开发环境中实现的,例如xcode,下面,针对ios的开发环境在本申请以下内容涉及的相关组件或者程序进行简要说明。
37.cocoapods:开源的包管理工具,用于模块集成;pod:cocoapods管理的代码包称为pod;podfile:集成pod时使用的描述文件,可以声明插件,以及要集成的pod;xcode:ios开发使用的代码编辑器;asset catalog:ios开发中管理图片资源的一种方式;xcassets:asset catalog管理的文件存放于以xcassets为后缀的文件(目录)内,例如image.xcassets;assets.car:asset catalog的编译产物;xib、storyboard:ios开发中的界面资源,可进行图形化编辑;nib、storyboardc:xib、storyboard对应的编译产物;buildphase:xcode中抽象的编译阶段,可在xcode中进行修改,编译时执行,属于xcode工程文件可配置的一部分,用于指定编译任务,可以通过增加自定义的buildephase在编译过程中做额外的数据处理;inputpath、outputpath:buildphase中进行设置,可以决定各buildphase间的依赖关系,并可控制其所属buildphase是否需要编译,或者说,属于buildphase,xcode可以通过配置的路径是否有更改来决定是否执行自定义buildphase中的脚本内容;actool:编译asset catalog使用的工具,由苹果公司提供;ibtool:编译xib、storyboard使用的工具,由苹果公司提供;xcodeproj:用于修改ios工程文件的工具, 为了与工程文件作区分,工程文件使用.xcodeproj表示;target:集成目标。
38.可以看出的是,本申请所提出的app生成方法,是在xcode基于其相关的组件、程序或者工具实现的,与此同时,应当理解到的是,该方法本质上是本申请针对这些组件、程序或者工具的应用原理,结合实际需求,对这些组件、程序或者工具的工作方式进行的调整,而这调整内容并非是这些组件、程序或者工具原有的工作形式,也因此,该方法涉及的技术方案不能简单地认为是这些组件、程序或者工具原有的应用方案,在这些组件、程序或者工具形成的应用环境下,通过该方法,可更好的利用这些组件、程序或者工具,更快的完成编译处理,从而提高app的生成效率。
39.从app的开发需求开始,当开发公司存在某app的开发需求时,例如app的初始立项或者app更新,可确定本次目标项目,在xcode中,该项目可以作为一个target,并准备本次项目的相关配置文件,例如由工作人员提供初始的代码以及资源文件,这些配置文件可配
置进xcode中,并触发本申请的app生成方法。
40.一般的,对于ios项目,通常由cocoapods管理代码,每个代码资源(或者也可称为代码模块、代码文件等)内也可能有代码以外的资源,这些模块中资源的处理由cocoapods在集成模块时生成的脚本决定如何处理,而关于代码资源以及xcassets的编译,也是通过cocoapods执行。
41.而在现有技术中,由于集成目标和各集成模块的资源都是由cocoapods统一处理,由于集成目标自身的xcassets在编译过程中本来就要处理一次,也就是说这部分资源会被处理两次,从而出现资源越多耗时越多的问题。
42.而本申请,考虑到该问题,则提出将本次target的xcassets对应代码资源,以pod的进行集成,仅保留app桌面图标,尤其是可仅保留认为必要留下的app桌面图标,如此,在该设置下,cocoapods在编译时,可使得xcode、cocoapods的脚本重复处理的资源明显下降甚至说减到最低,从而达到减少处理的资源以降低耗时的效果。
43.此外,在应用过程中,还发现还可继续降低编译处理所需的耗时。
44.作为一种适于应用的实现方式,cocoapods所进行的编译处理,其调用的脚本,具体可由cocoapods配置的自定义插件实现自定义控制,可以理解,cocoapods可向工作人员开放插件入口,由工作人员配置相关的自定义插件以实现定制化的cocoapods的工作控制。
45.如此,在本申请中,处理设备,以pod形式集成目标target的初始xcassets,并具体可在集成后通过cocospods配置的自定义插件生成cocoapods相关的脚本以及buildphase,其中,该自定义插件具体可声明(或者说描述)于podfile中。
46.其中,具体的,cocoapods会把它管理的组件(或者称为library)中的xib和xcassets写进一个shell脚本,并添加到buildphase,在该情况下插件可增加和修改它生成的shell脚本和buildphase。
47.且本申请还提供了又一种优化实施方案,即,在上述的自定义插件中加入资源分离策略,如此,cocoapods基于自定义插件所生成的该脚本以及buildphase,在进行编译处理时,可分离cocoapods配置的代码资源以及目标xcassets两者中的资源,并对资源进行编译处理,可减少处理规模,避免在资源未分离前存在重复执行编译处理的情况,提高编译效率。
48.其中,代码资源包括xib资源、storyboard资源。
49.具体的,该资源分离策略可以以脚本拆分的方式实现,相比于现有技术中不同类型的资源,比如xcassets和xib是在同一个脚本中处理的,若需修改xcassets中一个图片,则可能出现也需将1000多个xib重新编译的情况,而本申请,则可在编译处理中通过相互独立的脚本,针对不同类型的文件采取不同的编译处理,例如将xcassets和xib进行分离,达到分离资源、减少一个脚本的处理规模、从整体上提高编译效率的效果。
50.示例性的,作为一种分离策略的体现,本申请对资源的分离处理可通过buildphase实现,具体的可对应代码资源、xcassets,进行builphase的划分。
51.一、对应上述的目标xcassets,其脚本以及buildphase的生成处理可包括:处理设备获取目标xcassets的路径,其中,路径包括目标xcassets中在不同configuration(可以理解为xcode中的配置环境,例如debug、release)下不同xcassets的路径;
处理设备将第一路径记录进文件中,其中,文件用于确定cocoapods管理的xcassets路径;处理设备生成动态获取xcassets的脚本,其中,动态获取xcassets的脚本用于在编译时使用xcodeproj获取当前target中所有xcassets路径;处理设备生成目标编译脚本,其中,目标编译脚本用于编译目标xcassets;处理设备通过xcodeproj将目标编译脚本添加至buildphase。
52.其中,这里记录到脚本里的是cocoapods管理的组件(library, pod)中包含的xcassets路径(不同configuration都会记录)。
53.此外,针对xcassets的编译,本申请还提出了一种增量编译方案,以再次提高编译效率。
54.参阅图2示出的本申请增量编译的一种流程示意图,关于xcassets的增量编译,可包括如下步骤:步骤s201,记录参与编译的第一xcassets的第一修改时间并将第一xcassets缓存为assets.car;步骤s202,当下一次编译时,确定参与编译的第二xcassets,并比较第一修改时间与第二xcassets的第二修改时间,若一致,则触发步骤s203;步骤s203,复制assets.car至app的编译产物目录。
55.可以理解的是,在实际应用中,new build system下有多个buildphase生成assets.car时,xcode原本对xcassets的增量编译无法正常工作。
56.具体的,集成目标和cocoapods的脚本可生成同样的编译产物,xcode 10之后的new build system在预处理时检测到这种情况会报错导致无法进行编译,cocoapods预先建议的迁移方案为使用其提供的resource bundle方案,但该迁移方案带来的修改成本并不小,而如果不迁移到resource bundle方案,则可以修改cocoapods脚本所在buildphase声明的outputpath路径,避免new build system检测到重复的编译产物,但这种方式会导致无法进行增量编译,让开发效率变低。
57.而本申请针对相邻的xcassets,所提出的xcassets的缓存复用机制,在对xcassets进行编译时,具体如上面提及的将目标编译脚本添加至buildphase所涉及的目标xcassets,若未检测到缓存的assets.car时进行缓存处理及其缓存复用,显然,可以避免检测到编译产物的重复,从而可促进增量编译的实现,提高编译效率。
58.二、对应上述的代码资源,其buildphase的生成处理可包括:处理设备获取xib资源以及storyboard资源两者的路径;处理设备将路径记录进文件中,其中,文件用于确定cocoapods管理的xib资源路径以及storyboard资源路径;处理设备生成目标编译脚本,其中,目标编译脚本用于并行编译xib资源以及storyboard资源;处理设备通过xcodeproj将目标编译脚本添加至buildphase,并设置对应的inputpath以及outputpath。
59.可以理解的是,现有技术中的cocoapods,其脚本处理xib资源以及storyboard资源此类资源时,是按顺序逐个进行编译的,显然,串行执行方式未能充分发挥机器的性能,
而本申请如上述引入的多进程的并行执行方式,容易理解,可充分利用机器的性能,更好的实现增量编译,进一步提高编译效率。
60.进一步的,在实际应用中,针对于cocoapods原有的buildphase,本申请还可在cocoapods原有的builphase中,移除脚本涉及的资源,并调整对应的inputpath以及outputpath。
61.如此,相较于现有技术中修改组件中任意的资源,都会导致cocoapods的资源处理脚本在编译时完整执行,资源较多时拖慢开发效率的情况,本申请在修改资源时,仅会重新编译其对应类型的所有资源。
62.其中,针对于上述内容,为适于应用,cocoapods自定义插件所生成的编译目标xcassets的buildphase需要在copy bundle resource之后执行。
63.而当完成编译处理后,则可打包编译结果,生成app。
64.以上是本申请提供的app生成方法的介绍,为便于更好的实施本申请提供的app生成方法,本申请还提供了app生成装置。
65.参阅图3,图3为本申请app生成装置的一种结构示意图,在本申请中,app生成300具体可包括如下结构:确定单元301,用于在xcode中确定目标target;集成单元302,用于以pod形式集成目标target的初始xcassets,并保留初始xcassets中的app桌面图标,得到目标xcassets,其中,初始xcassets为asset catalog管理的资源;编译单元303,用于通过cocoapods组置的脚本,对cocoapods配置的代码资源以及目标xcassets进行编译处理;打包单元304,用于根据编译结果,打包生成目标target对应的app。
66.在一种示例性的实现方式中,集成单元302,具体用于:通过cocoapods配置的自定义插件,以pod形式集成目标target的初始xcassets;装置还包括生成单元305,用于在集成完成后生成脚本以及buildphase,其中,自定义插件声明于podfile中;编译单元303,具体用于:通过脚本以及buildphase,分离cocoapods配置的代码资源以及目标xcassets两者中的资源,并对资源进行编译处理,其中,代码资源包括xib资源、storyboard资源。
67.在又一种示例性的实现方式中,生成单元305具体用于执行目标xcassets对应的脚本以及第一buildphase的生成处理,包括:获取目标xcassets的第一路径,其中,第一路径包括目标xcassets中在不同configuration下不同xcassets的路径;将第一路径记录进第一文件中,其中,第一文件用于确定cocoapods管理的xcassets路径;生成动态获取xcassets的脚本,其中,动态获取xcassets的脚本用于在编译时使用xcodeproj获取当前target中所有xcassets路径;生成第一目标编译脚本,其中,第一目标编译脚本用于编译目标xcassets;通过xcodeproj将第一目标编译脚本添加至第一buildphase。
68.在又一种示例性的实现方式中,第一buildphase还配置有:记录参与编译的第一xcassets的第一修改时间并将第一xcassets缓存为assets.car;当下一次编译时, 确定参与编译的第二xcassets,比较第一修改时间与第二xcassets的第二修改时间;若一致,则复制assets.car至app的编译产物目录。
69.在又一种示例性的实现方式中,生成单元305具体用于执行代码资源对应的脚本以及第二buildphase的生成处理,包括:获取xib资源以及storyboard资源两者的第二路径;将第二路径记录进第二文件中,其中,第二文件用于确定cocoapods管理的xib资源路径以及storyboard资源路径;生成第二目标编译脚本,其中,第二目标编译脚本用于编译xib资源以及storyboard资源;通过xcodeproj将第二目标编译脚本添加至第二buildphase,并设置对应的inputpath以及outputpath。
70.在又一种示例性的实现方式中,装置还包括移除单元306,用于:在cocoapods原有的buildphase中,移除脚本涉及的资源,并调整对应的inputpath以及outputpath。
71.在又一种示例性的实现方式中,在buildphase中,目标xcassets对应的buildphase的排序在copy bundle resource之后。
72.本申请还提供了处理设备,参阅图4,图4示出了本申请处理设备的一种结构示意图,具体的,本申请处理设备可包括处理器401、存储器402以及输入输出设备403,处理器401用于执行存储器402中存储的计算机程序时实现如图1或图2对应实施例中app生成方法的各步骤;或者,处理器401用于执行存储器402中存储的计算机程序时实现如图3对应实施例中各单元的功能,存储器402用于存储处理器401执行上述图1或图2对应实施例中app生成方法所需的计算机程序。
73.示例性的,计算机程序可以被分割成一个或多个模块/单元,一个或者多个模块/单元被存储在存储器402中,并由处理器401执行,以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段,该指令段用于描述计算机程序在计算机装置中的执行过程。
74.处理设备可包括,但不仅限于处理器401、存储器402、输入输出设备403。本领域技术人员可以理解,示意仅仅是处理设备的示例,并不构成对处理设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件,例如处理设备还可以包括网络接入设备、总线等,处理器401、存储器402、输入输出设备403以及网络接入设备等通过总线相连。
75.处理器401可以是中央处理单元(central processing unit,cpu),还可以是其他通用处理器、数字信号处理器(digital signal processor,dsp)、专用集成电路(application specific integrated circuit,asic)、现成可编程门阵列(field

programmable gate array,fpga) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器
件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等,处理器是处理设备的控制中心,利用各种接口和线路连接整个设备的各个部分。
76.存储器402可用于存储计算机程序和/或模块,处理器401通过运行或执行存储在存储器402内的计算机程序和/或模块,以及调用存储在存储器402内的数据,实现计算机装置的各种功能。存储器402可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据处理设备的使用所创建的数据等。此外,存储器可以包括高速随机存取存储器,还可以包括非易失性存储器,例如硬盘、内存、插接式硬盘,智能存储卡(smart media card,smc),安全数字(secure digital,sd)卡,闪存卡(flash card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
77.处理器401用于执行存储器402中存储的计算机程序时,具体可实现以下功能:在xcode中确定目标target;以pod形式集成目标target的初始xcassets,并保留初始xcassets中的app桌面图标,得到目标xcassets,其中,初始xcassets为asset catalog管理的资源;通过cocoapods配置的脚本,对cocoapods配置的代码资源以及目标xcassets进行编译处理;根据编译结果,打包生成目标target对应的app。
78.所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的app生成装置、处理设备及其相应单元的具体工作过程,可以参考如图1或图2对应实施例中app生成方法的说明,具体在此不再赘述。
79.本领域普通技术人员可以理解,上述实施例的各种方法中的全部或部分步骤可以通过指令来完成,或通过指令控制相关的硬件来完成,该指令可以存储于一计算机可读存储介质中,并由处理器进行加载和执行。
80.为此,本申请提供一种计算机可读存储介质,其中存储有多条指令,该指令能够被处理器进行加载,以执行本申请如图1或图2对应实施例中app生成方法中的步骤,具体操作可参考如图1或图2对应实施例中app生成方法的说明,在此不再赘述。
81.其中,该计算机可读存储介质可以包括:只读存储器(read only memory,rom)、随机存取记忆体(random access memory,ram)、磁盘或光盘等。
82.由于该计算机可读存储介质中所存储的指令,可以执行本申请如图1或图2对应实施例中app生成方法中的步骤,因此,可以实现本申请如图1或图2对应实施例中app生成方法所能实现的有益效果,详见前面的说明,在此不再赘述。
83.以上对本申请提供的app生成方法、装置、处理设备以及计算机可读存储介质进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1