在当前的应用开发中，一个应用因各种原因而推出多个版本的现象很普遍。这种做法背后的构建方式和资源分配策略，引起了众多开发者的极大兴趣。这不仅仅是为了满足不同用户群体的需求，还涉及到资源的有效利用和开发成本的节约。
多种版本的意义
各种应用版本各有其用途。在商业层面，免费版用于吸引访客，而付费版则是为了盈利。按地域划分，国内版本和国际版本能够适应不同地区的法律法规和用户的使用习惯。以某款流行的社交软件为例，国内版主要聚焦于社交分享功能，而国际版则加入了多语言翻译，以适应不同地区的用户需求。不同版本也针对不同的设备进行优化。比如，某些游戏应用的普通版适用于普通配置的设备，而VIP版则专为高端设备用户提供更高质量的图像和更多功能。若开发者忽视了这些差异，可能会遭遇用户流失或成本增加的问题。那么，如何决定自己的应用需要哪些版本的调整？
不同版本能够适应不同消费群体的需求。例如，一款运动软件，基础版本只提供基础的锻炼课程资讯，而高级版本则包括专业教练的个性化课程和实时辅导。这样便满足了不同消费水平用户的需求。
{
...
\"targets\": [
{
// 默认版target名称。
\"name\": \"default\",
\"runtimeOS\": \"HarmonyOS\",
},
{
// tablet版target名称。
\"name\": \"tablet_target\",
\"runtimeOS\": \"HarmonyOS\",
}
]
}
构建流程
构建不同版本并非随意行为。掌握相关知识和模块至关重要。每个模块或条目都支持个性化调整。以办公软件为例，若要打造基础版和高级版，需要在模块的build-.json5文件中对设备类型、代码库、资源、C++依赖的.so文件等进行定制。从代码库角度分析，高级版可能包含更多办公模板功能的代码，而基础版则更为简洁。在设备类型上，高级版可能针对高端设备进行优化，以便支持更复杂的操作。若不按照规定流程进行定制，应用在特定设备或功能上可能存在兼容性问题。
{
...
\"targets\": [
{
// 未定义deviceType，默认支持config.json或module.json5中定义的设备类型。
\"name\": \"default\",
\"runtimeOS\": \"HarmonyOS\"
},
{
\"name\": \"tablet_target\",
\"runtimeOS\": \"HarmonyOS\",
\"config\": {
\"deviceType\": [
// 定义支持的设备类型为tablet，支持的设备类型必须在config.json或module.json5中已经定义。
\"tablet\"
]
}
}
]
}
在讨论设备种类时，定制阶段还需关注各种设备的兼容性。比如，物联网设备的应用，需要在手机版的基础上对界面布局和功能交互进行调整，以适应小屏幕设备。这些都是构建过程中需要克服的难题。
{
\"module\": {
...
\"deviceTypes\": [
\"default\",
\"tablet\"
],
}
}
资源配置要点
{
\"targets\": [
{
// 会员版target名称
\"name\": \"tablet_target\",
\"runtimeOS\": \"HarmonyOS\",
\"source\": {
// 定义stage模型中tablet版本target的pages源码文件，可根据需求选择区别于默认版本的源码文件。
\"pages\": [
\"pages/TabletEntryView\"
]
}
}
]
}
处理资源文件是关键所在。在ArkTS项目中，只有主目录下的资源文件夹可以调整。以图片编辑软件为例，免费版可能只包含基础滤镜的资源，而付费版则会增加更多高级滤镜的资源。每个版本都需要明确自己的资源获取途径。若资源分配杂乱无章，用户在使用过程中可能会遇到功能缺失或体验异常的问题。
开发者在制作资源文件时，需注意实施层级化管理。例如，针对各个功能单元，提前制定相应的资源文件计划，便于在定制不同版本时，能够明确地分配资源。
{
\"targets\": [
{
\"name\": \"default\",
\"runtimeOS\": \"HarmonyOS\",
},
{
// 会员版target名称
\"name\": \"tablet_target\",
\"runtimeOS\": \"HarmonyOS\",
\"resource\": {
// 定义tablet版本使用的资源文件目录，该功能在API 9及以上版本的工程中生效，可根据需求选择区别于默认版本的资源文件。
\"directories\": [
\"./src/main/resources\"
]
}
}
]
}
打包环节考量
在打包阶段，APP的设置与HAP存在关联。每一个HAP对应一个APP包，一对一的关系。比如，设定了试用版和正式版两种版本，它们需分别进行打包。这些版本可能都需要定制签名文件。在某个应用开发案例中，由于签名文件处理不当，其试用版被系统错误地识别为不安全软件。此外，每个APP包可以对应一个或多个HAP，既可单独打包，也可相互匹配打包，因此需要谨慎进行规划。
{
\"app\": {
\"products\": [
{
\"name\": \"default\",
\"signingConfig\": \"default\",
\"compileSdkVersion\": '4.1.0(11)',
\"compatibleSdkVersion\": '4.1.0(11)',
\"runtimeOS\": \"HarmonyOS\"
},
{
\"name\": \"tablet_product\",
// 定义tablet版本的包名
\"bundleName\": \"com.north.commonappdevelopmenttablet\",
// 定义tablet版本的签名文件信息
\"signingConfig\": \"tablet\",
\"compileSdkVersion\": '4.1.0(11)',
\"compatibleSdkVersion\": '4.1.0(11)',
\"runtimeOS\": \"HarmonyOS\"
}
],
},
}
打包时务必留意版本间的差异，尤其是那些功能不同的版本，必须保证用户获取的正是他们期望的版本内容。
{
\"app\": {
\"bundleName\": \"com.north.commonappdevelopmenttablet\",
...
}
}
开发者规划
提前确定版本的名字至关重要。它影响着开发工作的有序性和项目管理的高效性。以一个在线教育应用为例，若要推出基础、进阶和高级三个版本，若在前期未对名称进行规划，那么在后续的开发和推广过程中，可能会出现极大的混乱。开发者需依据目标用户群体和功能特点来设定版本名称。例如，对于零基础的用户，可以命名为“入门版”，而对于已有一定基础的用户，则可以命名为“提升版”。
规划制定时，需预判未来可能出现的版本更新和功能扩展。以短视频应用为例，随着用户需求提升，未来可能增加视频特效制作功能，因此在规划当前版本时，需预留足够空间。
鸿蒙生态人才培养
{
\"modules\": [
{
\"name\": \"entry\",
\"srcPath\": \"./product/entry\",
\"targets\": [
{
// 将default target 打包到default版本的APP中
\"name\": \"default\",
\"applyToProducts\": [
\"default\"
]
},
{
// 将tablet target 打包到tablet_product版本的APP中
\"name\": \"tablet_target\",
// 设置该target适用于tablet_product版本的APP
\"applyToProducts\": [
\"tablet_product\"
]
}
]
}
]
}
推动鸿蒙生态人才培养是当前的发展趋势。梳理出具有学习价值的开发技术学习路径具有重要意义。比如，纯血版鸿蒙（Next）的全栈开发技术学习路径，涵盖了大型应用实战项目开发。这样做有助于吸引更多在职人员、零基础新手、应届计算机专业毕业生、鸿蒙爱好者等加入鸿蒙开发。随着更多人掌握这些技术，也将促进应用的进一步开发，特别是在鸿蒙系统多版本构建和资源配置等复杂任务上。这无疑是一个双方受益的局面。那么，您对鸿蒙生态未来对开发者培养的前景持何种看法？
开发多版本的应用并非易事，涉及诸多考量。从版本规划、构建流程、资源配置到打包步骤，每一个环节都至关重要，彼此间紧密相扣，共同决定着应用的最终效果和市场的收益。我们希望有更多开发者能理解并掌握这一理念，共同为软件市场带来更多优质产品。
