推广 热搜:   中国  设备  参数  公司  未来  服务  行业  企业  教师 

1.3 独立应用开发的完整流程

   日期:2024-12-13     作者:caijiyuan    caijiyuan   评论:0    移动:http://sicmodule.glev.cn/mobile/news/13066.html
核心提示:付费栏目万字解析「万字解析」是体验少数派付费栏目内容的最佳方式。我们希望用一万字的篇幅,系统、深度地分享有价值的内容,让

付费栏目万字解析

1.3 独立应用开发的完整流程

「万字解析」是体验少数派付费栏目内容的最佳方式。我们希望用一万字的篇幅,系统、深度地分享有价值的内容,让少数派读者可以享受获得新知的愉悦。

本期「万字解析」内容选自《100 小时后请叫我苹果开发者》。《100 小时后请叫我苹果开发者》面向所有有兴趣尝试苹果生态应用开发的读者,帮助初学者从零开始,高效开发出一款应用,先人一步,迈进苹果生态的开发世界。

灵感来源于生活。许多视频博主都会做这样一个挑战,将地图贴在远处的墙上,蒙着眼睛扎飞镖。博主和观众约定扎到哪里就去哪里。本篇文章中,我们将以此为例,构思一个随机地名生成器的应用。二可以借此讲解独立应用开发的完整流程,帮大家梳理出一份学习指南。

明确大概想要做什么之后,接下来需要做的便是将抽象的地标生成器概念具体化。我们会将其转化为可执行的应用方案,并确认目标人群。开篇提到,本应用的灵感来源于飞镖扎中地图上的地名,那么在手机上创建一个飞镖扎地图小游戏合适吗?

目标用户 Target Audience

大想法已定,接下来我们需要考虑目标用户。在本应用中,我们的目标用户是视频博主和热爱旅行但又不希望总被热门目的地左右的背包客。这些潜在用户去搜索,尝试一款随机地名生成器应用的可能性更大。

用户画像 Persona

在产品设计中,有时会进一步描述目标用户中的一个明确个体,这一流程叫做制作用户画像。用户画像可以是设计中的一个理想的客户描述。本应用的用户画像则可以是一个 20 岁左右管理 Bilbili 频道的男性、他经营的是一款美食探索栏目,他比较喜欢尝试新鲜事物,看到目前比较火的随机目的地挑战,他也有兴趣参与进来,去一个未知的目的地拍一期视频尝试当地特色美食。

基于你对生活的观察,你可能会发现身边不同领域存在的改进空间。在这一阶段,你可以使用不同方法来完善一个灵感,比如头脑风暴。

基本可行性产品 MVP

这一阶段则是验证灵感的最重要阶段,MVP 的英文全称为 Minimal Viable Product,你可以将其翻译为最基本的可行的产品。

M 代表着基本、最骨干的功能,用户看到后会知道你在做什么。

V 代表可行的,它意味着在此阶段,这些基本功能可以被一些用户拿来进行尝试。程序设计者常犯的一个错误便是凭空猜测,假设用户需要这些那些的功能,并将自己所知的内容自然而然地当做用户也知道。实际则不然,对于用户来说,他们对你的想法、理念一无所知。制作完 MVP 之后,你就可以拿着你的 MVP 去请用户盲测了。你可以自己设计一个简单的问卷,事先不作说明。拿着 MVP 产品去请用户盲测,之后再按设计好的问题提问,来验证用户的使用流程是否如你预期,以及你所创作的产品是否可以满足用户的实际需求。

迭代周期 Design Cycle

在不同领域中,迭代周期的概念被广泛使用,重复推进这一循环的步骤,可以帮你更好地推进当前产品。收获了产品反馈后,做产品的人通常会选择两个方向继续前进。一类人会将 MVP 完善后直接推向市场,由市场反馈决定接下来的需求和迭代方向;另一类人会继续坐下来完善产品,直到期望的所有功能都完成后再推向市场。

在上一节可行性验证中,我们使用乐高迪士尼乐园的案例,展开探讨了灵感可行性验证和产品迭代的思想。接下来将回到本文的核心案例,随机地名生成器例中,将具体需求记录下来。

需求记录中,你可以从 MVP 的角度来思考你的核心需求。什么是这个应用程序最重要的部分?在随机城市应用中,最核心的部分便是创作一个翻牌的界面,来实现翻牌并给出随机城市的功能。可是这好像还不够,我还希望 MVP 产品中用户可以做些微的自定义,因此将切换「自己国家/全世界」的范围选择按钮也加入考量。

优化需求

我们在迭代周期中介绍过新需求的来源。在应用开发中,这些来源可能是一些符合基本用户认知的需求、帮助程序发展的本地化需求、来自你自己的主观创意、应用商业模式需要的收益需求等等。在随机城市应用中,我罗列的优化需求包括一个翻牌时的延迟动画、翻牌期间的声音与震动反馈、定价方案的制定等等。

已经有了需求,接下来我们便来将需求对应的设计落地。这个应用放在什么地方比较合适?便是对目标设备的考量,对于一款生成随机地名的应用来说,最适合的使用场景很可能是离手边最近的手机,因此我们将其作为主要考虑对象。

视觉框架

在 iOS 生态系统中,常用的视觉框架有三种。第一种叫做 Flutter,它是由 Google 主导开发的 Android 与 iOS 跨平台 UI 框架,目前使用此技术的代表应用为阿里巴巴的闲鱼。Flutter 底层的语言是 Dart,有额外学习成本;其次是 Flutter 并非 Apple 第一方框架,因此使用中遇到的小毛病不方便获取 Apple 官方支持,个人不太推荐。但若你感兴趣,Flutter 描述性语言的特质与本教程学习的 SwiftUI 概念类似,你可以比较容易地做知识迁移。

在 UIKit 中,开发者需要明确定义各界面元素之间的逻辑关系。任何一个界面元素,你都需要明确地告知它在界面元素中的位置。比如应用中常见的分类大标题文字,你需要人为定义文本框的上边栏锚定在距机器顶部 20px 的位置,文本框左侧边栏在距离机器左侧 20px 的位置上。

每个视觉元素在某件事情发生时都会提供一系列状态控制的通知函数,积少成多,一个看似普通的界面往往需要几十个控制界面状态的函数堆放在一起以实现理想的界面逻辑。这些控制函数放在一起,我们称作 ViewController 视觉元素控制器。这一文件常常因为控制界面状态的函数过多而变得非常大而被开发者戏称为「过度肥胖」。

当控制界面的函数过多时,就容易在开发者不注意的地方产生冲突,也就是程序 Bug。当控制界面因函数过多而变得复杂时,我们便很难继续处理好每一个界面间的关系,而需要投入大量精力来寻找原因。

难道就没有一个更好的方法了吗?答案是有的,这便是第三种 UI 框架 SwiftUI。SwiftUI 是 Apple 官方于 2019 年发布的最新 UI 框架,它在 UIKit 上更近了一步,不再是提供一套一致的界面来强行适配不同平台,而是根据不同平台因地制宜,在不同平台上,用符合该平台设计规则的方式将界面元素呈现出来。

SwiftUI 不在乎你的背景如何,非常易学易用,且具有极佳的跨系统支持。但同时你需要认识到 SwiftUI 是一款新生框架,处在逐渐完善的过程中。比如 UIKit 所支持的 CollectionView 或者 Activity Indicator 这些成熟界面元素的替代品,SwiftUI 在 2020 年才给出以上界面的官方支持。截至 2023 年,你所需要的绝大多数功能,都已经能在 SwiftUI 上原生实现啦。

在产品定位时,创作者需要将发布的平台考虑进去。具体来说,你需要知道各平台的优劣与定位,并据此决定应用是否要登陆不同平台。

Apple Watch 是用户最亲密的设备,它具备一些最基本框架的支持。用户长时间举着胳膊并不是个很好的体验,因此为它开发应用时,你需要将用户与应用的交互时间,以及耗电量共同考虑进去。手表的表现力不像手机,若你强行将应用的所有核心功能放置其中,性能会被大幅打折,导致用户不愿意使用。你的应用所提供的,应该是一个适合手表端的简洁操作,这一操作可以是 MVP 的精华,也可以是对核心功能的补充。

那么想放的各种功能应该放在哪里呢?这时你应该考虑 iOS 应用。在 Apple 生态系统的 15 亿用户中,iPhone 用户占大多数。因为基数很大,将应用放在这里,基本上可以确保拥有广阔的市场发展空间。iPhone 拥有的传感器最为丰富,你想实现的各种功能都可以把它当作试验田。

iPad 是许多开发者忽视的设备类别。但实际上 iPad 平台具有独特体验,且用户消费意愿很高。这类设备通常能提供更高一个层级的性能,购买 iPad 的用户常常对生产力应用有更高需求。除此之外,值得注意的还有 iPad 所具备的更大屏幕,你的应用程序如何设计才可以更好地利用这些空间?无论你的思考为何,切忌将 iOS 的应用直接照搬,原封不动的照搬很可能会导致原先精心设计的界面在大屏幕上显得杂乱无章。

触摸板、键盘、多点触控、Apple Pencil、鼠标共同构建了 iPad 系统的输入方式。当你对这些输入方式进行更多优化时,当你对大屏幕的体验进行更多思考时,你的思考不会平白浪费。 Apple 在基础框架的构建上付出了很多努力,许多问题你只需要解决一遍,就会发现这些功能在各平台上都完成了适配,这时你优秀的 iPad 应用可以很平滑地变成一个同样优秀的 Mac 应用。

最后要说的,便是国人不太熟悉,但海外有一定用户基数的平台 tvOS。Apple TV 用户选用的屏幕往往是家中最大的那一块,因此它在影视游戏等方面都具备独特的先天优势。当你在思考 tvOS 应用程序时,你考量的可能是如何将最核心的内容放在易于观看的大屏幕上。在你做这些努力时,你会发现你的代码在同一时间也完成了对使用外接显示器用户的适配。

在前几个小节中,我们探讨了随机城市应用的需求与设计,那么务实地说,谁能让我们把这个应用做下去?作为独立开发者,这个应用的最大助推者很大可能是你自己。作为对这个产品的定位、发展方向最了解的人,你要做好在没人支持情况下持续工作一段时间的心理准备。

独立应用开发对创作者多元能力的期望值较高。每个人的背景不同,强压着自己所有的部分对于某些人来说可能不现实,效果可能也达不到你的预期。在这种情况下,你可以选择和你优势互补的人共同经营一个产品,发挥你的个人优势,并在短板处寻求帮助。在互联网时代,将你最薄弱的地方直接请擅长的人来做也不失为一种选择。

也许你的初心便是创作一款心中所想的应用,但你必须意识到,与你自身不同,外来资本的介入需要投资回报,因此你必须让利。是否寻求外来资本的帮助与介入,需要你自己根据实际情况来做判断。本文中我们随机城市的例子规划格局比较小,因此不需要额外资本的介入。

上文我们介绍了 UI 框架 SwiftUI,在代码截图中你可能发现了 SwiftUI 常见的,诸如 Text("文本") 这样的写法。在本小节中,我们将介绍独立开发代码落地阶段最重要的三片拼图,它们分别是 Swift、SwiftUI 和系统框架。

Swift

编程时我们用什么语言呢?你也许已经由 SwiftUI 的名字猜到了,我们要用的是一款名为 Swift 的编程语言。Swift 是一款由 Apple 在 2014 年发布的跨 Apple 生态系统的编程语言,据淘宝开发团队统计,截至 2020 年,北美市场近 80% 的应用都用上了 Swift。编程语言就好比乐高的积木块,是一切的基础。如同我们说话需要中文一样,与电脑沟通时则可以使用 Swift 语言。

说完了 Swift,那么与它名字相似的 SwiftUI 又是什么呢?SwiftUI 是一款 DSL 语言,全称为 domain-specific language,它具有专有语法来实现专有用途。若你将 Swift 理解为日常用语,那么 SwiftUI 便好像是一系列专业术语。它依托于日常用语,又依靠独特词汇提供了日常语境中不涉及的专业内容。

在代码落地的讨论范畴中,我们还缺最后一片拼图,这便是系统框架。那么什么是系统框架呢?系统框架也被 Apple 官方列在科技列表中,它代表的是一系列设备本身所具备的硬件能力。这些能力经 Apple 工程师之手规整好,之后将更容易理解,可直接使用的函数直接开放给开发者,便形成了框架。这些框架可以由创作者根据自身需求自由选用。

本小节中,我们介绍了将代码落地的三片拼图,现在你大概了解了它们在独立应用开发的过程中所处的地位。Swift 负责应用程序逻辑,SwiftUI 负责 UI 界面,系统框架负责提供让创作者使用设备上不同功能的途径。对于以上这些话题,我们将在教程的二三四章中对这些技术一一展开。

找到了需求,完成了设计,落实了代码。接下来便是将应用程序分享出去,让这个世界分享你的创作喜悦。在本小节中,我们来讨论应用上架过程中你会遇到的几个重要概念。

应用打包

当你的应用程序开始满足用户需求时,用户便会以不同方式来支持他们喜欢的应用。常见的营收选择有一次性购买、广告、应用内购、自动订阅等方案。针对应用的属性,你也可以自由选择一种或多种营收方案的组合。每种营收方案适用于不同类型的应用,我们会在第六章中详细探讨方案的要求与用法。

对于随机城市应用,我们的目标用户与定位比较明确,为有出行需求的用户提供一个惊喜的旅行地点。但是在应用程序上架后,很大概率我们的应用仍会无人问津。那么如何获取用户呢?

产品描述

广告

为你的应用打广告一定会带来流量、关注、用户群体。但是对谁广告、如何优化广告、花多少钱广告、在哪里广告都是你需要思考的范畴在我看来,决定是否使用这个广告商的标准,便是开销小于获取用户的成本。若你的应用程序由广告带来的用户收益大于实际广告支出,则说明你摸索出了一个针对你应用的可行广告方案。对于广告优化中常见的数据解读,我们将在第六章 - 如何宣传你的应用中详细展开。

多媒体渠道

用户获得信息的方式早已不局限于广告。仔细想想,上一次你装某个新东西时,是不是某个人和你说「哎那个不错,要不你去试试?」当你的应用成熟时,你可以考虑除传统广告商之外的其他途径,比如网站媒体、视频博主等渠道宣传。市场上有非常多的人在做这些工作,也愿意与独立开发者建立互助关系。

权重优化

产品在应用商店的排位决定了产品的曝光量,曝光决定了有机会看到你应用的用户数量,用户数量决定了你的收益,收益多少决定了你的应用是否覆盖投入,可以长期做下去。而是谁决定了你的产品在商店中的排位呢?这便是关键词权重。

权重优化是一个相对来说需要花些时间,但回报颇丰的事情。作为独立应用开发者,你可以在每次应用更新时一并更新你的关键词,并记录每次的效果。我们会在教程中单独开篇讲解关键词及权重优化。

作为开发者,你会希望更多积极的评论显示在应用商店的评论区;对于 Bug 反馈,则更适合直接反馈给开发者,以便及时修复。开发者与用户需要交流反馈,然而正常使用时,用户不会有那么多去反馈的冲动;反而是有负面体验时想到商店评价。那么有什么解决办法呢,其中一个可行方案便是在恰当的时机提出问题。

在某个惊喜的功能推送后,是否询问用户愿意帮忙反馈来让更多人发现你的应用?在 Apple 提供的众多技术框架中,StoreKit 负责用户评价等事宜。你可以直接在应用中向用户收取商店的评分或文字反馈,也可以考虑使用不同的反馈方案,在用户需要的时候为它们提供直接能联系到你的方式。 

更新公告

在开发完整流程的最后,我们来讨论每个开发者都会面对的应用更新。更新的具体原因有很多,但大致目的可能为用户提供新功能、或要修复某个应用 Bug。

做一个应用真的像种一朵花,在前期栽培时你可能除了辛苦付出什么也看不到,因为种子还深埋在泥土里,在独立开发的流程中也适用。但这场历程总是值得的,耐下心来,等待萌芽破土,花茎抬头,花朵一点一点绽放开来。就让我们一起开始这场创作之旅吧!

> 下载 少数派 2.0 客户端、关注 少数派公众号,解锁全新阅读体验

本文地址:http://sicmodule.glev.cn/news/13066.html    歌乐夫 http://sicmodule.glev.cn/ , 查看更多
 
 
更多>同类行业资讯
0相关评论

新闻列表
企业新闻
推荐企业新闻
推荐图文
推荐行业资讯
点击排行
网站首页  |  关于我们  |  联系方式  |  使用协议  |  版权隐私  |  网站地图  |  排名推广  |  广告服务  |  积分换礼  |  网站留言  |  RSS订阅  |  违规举报  |  鄂ICP备2023001713号