一个不同的时代 (A Different Era)

There is now a whole generation of young developers who are starting their careers in Mobile software, which is great because I’d argue they in theory should be more in tune with what the user expects from a software product. If you’re part of the previous generations of developers however, then most of your career has probably been away from the smartphone.

现在已经出现了一代年轻的开发人员，他们开始从事移动软件事业，这很棒，因为我认为从理论上讲，他们应该与用户对软件产品的期望更加一致。 但是，如果您是前几代开发人员的一员，那么您的大部分职业可能都远离了智能手机。

If you go back only a dozen years, modern Mobile software development, as we know it today, wasn’t yet firmly established. The first iOS “SDK” was a collection of WebKit widgets for web-hosted “apps”, before CocoaTouch was released in 2008. Early Android was almost exclusively for the tech geeks. The now-dead Windows Phone platform hadn’t yet replaced Windows CE, the BlackBerry OS hadn’t yet began its death throes, and the modern smartphone application was still in its infancy.

如果仅回溯十二年， 现代的移动软件开发(如我们今天所知)尚未牢固建立。 第一个iOS“ SDK”是Web托管“应用”的WebKit小部件集合，在2008年CocoaTouch发布之前。早期的Android几乎完全是技术怪才专用的。 现在已经死了的Windows Phone平台尚未取代Windows CE，BlackBerry OS尚未开始消亡，而现代智能手机应用程序仍处于起步阶段。

Not too long ago, there weren’t many Senior Developers in this new area. Unless you’re a pioneer, you probably fit into one of the following categories: There were Senior Developers who came from desktop application backgrounds, and there were veteran Mobile Developers using pre-smartphone era handhelds, who were pretty niche, and a bit later on there also were long-time Web Developers looking to repurpose their careers when Adobe Flash bit the dust.

不久之前，这个新领域还没有很多高级开发人员。 除非您是先驱，否则您可能属于以下类别之一：有来自桌面应用程序背景的高级开发人员，并且有使用智能手机时代之前的手持设备的资深移动开发人员，他们相当小众。当Adobe Flash尘埃落定时，也有长期的Web开发人员希望重新定位他们的职业。

If you were working for a small software shop just before smartphone apps became ubiquitous, a lot of us made the jump when our employers wanted to establish a presence in the Mobile space. Most of us just barely knew what we were doing. Sure, there were guidelines and documentation from the SDK developers themselves, but there was vastly a lack of experts in the workforce to shepherd us into a new era of developing smartphone applications. The best we got was the one or two guys on your team who has dabbled in Mobile side-projects or have something in the App Store. Pat yourself on the back if you were one of them. :)

如果您只是在智能手机应用程序普及之前就在一家小型软件商店工作，那么当我们的雇主希望在移动领域建立业务时，我们中的许多人就跳了起来。 我们大多数人几乎不知道我们在做什么。 当然，SDK开发人员本身也提供了指南和文档，但是劳动力队伍中却缺乏专家来引导我们进入开发智能手机应用程序的新时代。 我们得到的最好成绩是团队中只有一两个人涉足Mobile侧边项目或在App Store中拥有东西。 如果您是其中之一，请轻拍自己的背部。 :)

经验VS。 行李 (Experience Vs. Baggage)

With our prior, traditional application development experience, comes a lot of baggage and things which should be unlearned. What is acceptable on the desktop is often not suitable for applications living in a sandbox with limited hardware resources, limited real estate and with multitouch screens.

凭借我们先前的传统应用程序开发经验，带来了很多行李和不应该学习的东西。 桌面上可接受的内容通常不适合生活在沙箱中的应用程序，这些沙箱中的硬件资源有限，空间有限且具有多点触摸屏。

Building a Mobile version for an existing product should result in a cohesive experience, but not in a way that you’re trying to replicate the same thing; that is a potential setup for failure. You want to use the strengths of the platform and not underline its weaknesses. In some cases, using a mobile application to compliment the desktop or web version may be the better approach than trying to replicate it. The same can be said for tablets.

为现有产品构建移动版本应该带来连贯的体验，但不会以您试图复制同一事物的方式产生； 这是潜在的失败设置。 您想利用平台的优势而不是强调其劣势。 在某些情况下，使用移动应用程序补充桌面或Web版本可能比尝试复制它更好。 平板电脑也可以这样说。

To maintain the status quo is to build something underwhelming. Shed some old habits and immerse yourself in the platform and what it has to offer your users if you want to have even a chance at standing out.

维持现状就是建立了势不可挡的东西。 摆脱一些旧习惯，沉浸在平台中，如果您想有机会脱颖而出，它会为用户提供什么。

现代用户体验 (Modern User Experience)

These days, it is very easy to make your users hate you, that you don’t even have to try to piss them off. The days of software companies dictating how a user “gets” to use your application are long gone, as monopolies in software continue to lose ground to newcomers who seem to get it right with their target audiences. The software industry is user-centric and has been for a little while.

如今，让您的用户讨厌您很容易，您甚至不必尝试激怒他们。 软件公司决定用户如何“使用”您的应用程序的时代早已一去不复返了，因为软件的垄断继续在新来者中失去地位，新来者似乎与目标受众相处得很好。 软件行业是以用户为中心的，已经有一段时间了。

To smartphone users, one false move could mean that your app gets deleted. And by “false move” we’re not talking about frequent crashes or a data loss, no. Your app can “work” in every sense of the word, but if you’re not providing a pleasant, meaningful experience that helps the user get their task done better, your app is going in the trash. Even if your app can save the user hours of otherwise manual work, when your user experience sucks, the users can still rightfully hate on it.

对于智能手机用户，一个错误的举动可能意味着您的应用被删除了。 通过“错误的举动”，我们并不是在谈论频繁的崩溃或数据丢失，不是。 您的应用程序可以在各个方面“发挥作用”，但是，如果您没有提供令人愉悦的有意义的体验来帮助用户更好地完成任务，那么您的应用程序将无济于事。 即使您的应用程序可以为用户节省其他时间的体力劳动，但是当您的用户体验糟糕时，用户仍然可以对它感到讨厌。

There is a finite amount of time people have and a seemingly infinite number of choices to spend their time doing. We should be so lucky if someone is using our app, as most people only use a handful of apps regularly (no pun intended).

人们拥有有限的时间，似乎有无数的选择来度过自己的时间。 如果有人使用我们的应用程序，我们应该很幸运，因为大多数人只会定期使用少数几个应用程序(无双关语)。

If your product is a B2B solution, then I guess the users have no choice but to use it, which is arguably more important that you want to make their experience as good as possible; nobody intends on creating something that people loathe to use out of necessity — but it can happen.

如果您的产品是B2B解决方案，那么我猜用户别无选择，只能使用它。可以说，要使他们的体验尽可能好，这可能更为重要。 没有人打算创建人们讨厌使用的东西，但这是有可能发生的。

UI Toolkit

UI工具包

Aside from having less screen space, your UI toolkit is wildly different from the Desktop and while you can make custom widgets and try to reproduce what is done on a Desktop, you really shouldn’t want to.

除了拥有更少的屏幕空间外，您的UI工具包与台式机也有很大的不同，尽管您可以制作自定义小部件并尝试重现台式机上完成的操作，但您实际上不希望这样做。

Tree views, multi-column tables, horizontal scrolling and input dialogs. Just. Don’t. The standard Mobile UI toolkits lack these things for a reason, so please don’t try too hard to force it. If you can’t solve a problem with the Mobile widgets you have, try considering how you’re approaching the problem. When you do have valid cases for going custom, try seeking existing third-party controls if building UI toolkits isn’t your core competency — or else the future you (or team) may face the wrath of the long-term maintenance implications you didn’t foresee, at the same time while trying to solve actual business/domain problems.

树状视图，多列表，水平滚动和输入对话框。 只是。 别。 标准的Mobile UI工具箱缺少这些东西是有原因的，因此请不要尝试太强硬。 如果您无法使用移动小部件解决问题，请尝试考虑如何解决该问题。 如果确实有有效的案例可以定制，那么如果构建UI工具包不是您的核心能力，请尝试寻找现有的第三方控件-否则您(或团队)的未来可能会面临长期维护隐患的愤怒我们不会同时尝试解决实际的业务/域问题。

UI controls is sometimes where you might clash with your UX Designer. You don’t want to limit their creativity due to technical inconveniences, but you also don’t want to do something that is literally 5x more work to make a certain little control exactly as the designer envisioned, every time they have an idea. Find a balance by working together, providing alternatives and iterating on ideas. A great designer will be able to help you work with what you’ve got, as long as it still provides a pleasant user experience.

UI控件有时可能与UX设计器发生冲突。 您不希望由于技术上的不便而限制他们的创造力，但是您也不希望每次他们有想法时 ，所做的工作实际上要多出5倍，以完全按照设计师的设想进行某种程度的控制。 通过共同努力，提供替代方案和反复讨论想法来找到平衡。 出色的设计师只要能够提供令人满意的用户体验，就可以帮助您处理已有的工作。

In addition to a new widget set, you may also have to think of data display and interactions in an entirely different sequence or workflow. Not only to reduce the amount of “clicks” to get through a workflow, but how many controls should be on one screen at a time also needs to be balanced.

除了新的窗口小部件集，您可能还必须考虑完全不同的顺序或工作流程中的数据显示和交互。 不仅要减少通过工作流的“点击”数量，而且还需要平衡一次在一个屏幕上显示多少个控件。

Research-Backed UX

研究支持的用户体验

Your app should be predictable, intuitive, and engaging. And you don’t learn how to build a Mobile app like that by presuming to know what the user wants, based on X years of experience designing desktop and web screens. You get this by conducting actual user research — or at least that’s how the more inspirational leaders in User Experience are succeeding.

您的应用程序应该可预测，直观且引人入胜。 基于X年来在设计台式机和Web屏幕方面的经验，您不会通过假设知道用户的需求来学习如何构建这样的移动应用程序。 您可以通过进行实际的用户研究来获得这一点，或者至少这是用户体验中更具启发性的领导者成功的方式。

Don’t build something if the user can’t validate that the problem in the use case is being solved. Before building — even before prototyping, you can user-test against wireframes and mockups to validate general workflow and layout before even getting into detailed design.

如果用户无法验证用例中的问题已得到解决，则不要构建任何东西。 在构建之前-甚至在进行原型设计之前，您都可以针对线框和模型进行用户测试，以验证总体工作流程和布局，甚至无需进行详细设计。

Although to be fair, for some industries, it might be hard to get access to users in your target market. Either find a way, or find the next best thing.

尽管很公平，但对于某些行业而言，可能很难在目标市场中接触到用户。 找到一种方法，或者找到下一个最好的东西。

Standard Mobile Expectations

标准移动期望

An important thing here, is to ensure you’re at least aware of the User Experience guidelines of the platform. Both Apple and Google have put in tons of research from some the world’s best to produce their own guidelines, and when we don’t heed that advice sometimes it becomes obvious to most smartphone users.

这里重要的是要确保您至少了解平台的用户体验指南。 苹果和谷歌都从世界上最好的研究机构中进行了大量研究，以制定自己的指南，而当我们不注意该建议时，对于大多数智能手机用户来说，这些建议有时就变得显而易见。

You can scoff at guidelines if you want, ignore the experts and try to do your own thing, but not everyone can be like a FaceBook or a Twitter and define what the mobile experience is, or can be; you need great UX research to pull it off, or the brand power for it to be accepted.

您可以随意嘲笑指导，忽略专家并尝试做自己的事，但不是每个人都可以像FaceBook或Twitter那样定义移动体验是什么，或者可以是什么 ； 您 需要进行大量的用户体验研究才能使其成功实施，或者需要品牌影响力才能被接受。

Providing a decent mobile experience means being a “good citizen of the platform”, as a team lead once taught me. Do what is expected. Notifications, appropriate virtual keyboard layouts, fat-finger-friendliness, multitouch gestures, remembering state when backgrounded, things that matter enough that Mobile users will notice when you don’t put in the effort.

正如团队负责人曾经教给我的那样，提供体面的移动体验意味着成为“平台的好公民”。 做预期的事情。 通知，适当的虚拟键盘布局，胖手指友好性，多点触摸手势，背景时的记忆状态，足够重要的事情，移动用户会在您不费力气时注意到。

Unfortunately, many times mobile concepts are afterthoughts. I believe there is a balance between deferring some of these things in the Minimum Viable Product until later, and waiting until it becomes a problem.

不幸的是，很多时候移动概念都是事后的想法。 我认为，将“最低可行产品”中的某些事项推迟到以后再等到出现问题之间是有平衡的。

Animation is Standard

动画是标准的

Animations aren’t just a flashy gimmick to engage the user to interact more naturally with the screen; they also buy your app a little bit of time. A lot of data prep can be hidden by a clever looking animation when a UI control is being activated. Screen transitions are also a great way to kick off some async work that finishes shortly before or shortly after the new screen is ready. Placeholder data can also be faded into actual data once it becomes available if a screen transition isn’t sufficient.

动画不仅是一种花哨的花招，还可以吸引用户与屏幕进行更自然的交互。 他们也会花一点时间购买您的应用。 激活UI控件时，外观精美的动画可以隐藏很多数据准备。 屏幕转换也是启动一些异步工作的好方法，这些工作会在新屏幕准备就绪之前或之后不久完成。 如果屏幕转换不足，则占位符数据也可以变为可用的实际数据。

If you’re not finding a clever way to streamline your data loading, I guarantee you that your users will notice, especially when compared to their everyday smartphone apps.

如果您找不到聪明的方法来简化数据加载，我保证您的用户会注意到，特别是与日常智能手机应用程序相比。

沙盒 (The Sandbox)

If you’re from a web background, you are probably already used to this but if you came from the Desktop, getting used to the limited access to certain hardware, operating system features, and the filesystem in general, may force you to re-think how things are going to get done. You will have to learn how to grant your app access to these features/permissions/entitlements, with consent from the user of course.

如果您来自网络背景，那么您可能已经习惯了，但是如果您来自桌面，那么习惯于对某些硬件，操作系统功能和一般文件系统的访问受限，可能会迫使您重新想想事情将如何完成。 当然，您必须学习如何在用户同意的情况下授予应用访问这些功能/权限/权利的权限。

Interprocess Communication (IPC) is one of those moments. This can be especially true if the other application you want to communicate with is not your own. Fortunately, most system-designed apps will have APIs, events or hooks you can use in your app to control or access their data.

进程间通信(IPC)就是其中之一。 如果您要与之通信的其他应用程序不是您自己的，则尤其如此。 幸运的是，大多数系统设计的应用程序都会具有API，事件或挂钩，您可以在应用程序中使用它们来控制或访问其数据。

Long-running tasks may also be a problem due to the nature of Mobile multitasking, and you must use the appropriate APIs to solve your problem the proper way.

由于移动多任务处理的特性，长时间运行的任务也可能会成为问题，并且您必须使用适当的API以正确的方式解决问题。

If you are able to build a sandboxed application which is far more enjoyable to use than some all-access desktop version of it, then I’d say you’ve mastered the art.

如果您能够构建一个沙盒应用程序，并且该应用程序比某些无障碍桌面版本使用起来更令人愉悦，那么我想您已经掌握了这门技术。

性能 (Performance)

The first modern Mobile app I’ve worked on was an iOS port of a realtime interactive 3D training tool for maintaining complex equipment, such as aircraft engines and weapons, used by the military and aerospace industries. We had our own proprietary 3D software-renderer so it was quite CPU-bound, and this had to run on an iPad 2.

我研究的第一个现代移动应用程序是一个实时交互式3D培训工具的iOS端口，用于维护军事和航空航天业使用的复杂设备，例如飞机引擎和武器。 我们拥有自己的专有3D软件渲染器，因此它非常受CPU限制，并且必须在iPad 2上运行。

Originally, we planned to reuse the desktop code (via Xamarin), hoping we could leverage a decade’s worth of work. It didn’t take long to discover that even with our renderer newly optimized to run on iPad, our application logic that was completely acceptable on Windows, will not be performant on the iPad.

最初，我们计划重用桌面代码(通过Xamarin)，希望可以利用十年的工作价值。 很快就发现，即使我们对渲染器进行了新的优化以在iPad上运行，我们在Windows上完全可以接受的应用程序逻辑在iPad上也无法发挥作用。

We had to worry about things like allocations, and not just from a memory footprint perspective, but also the valuable milliseconds it takes when you have to work with thousands of 4x4 matrices in short periods of time. Preallocating and in-place mutations took us a long way in performance, but also took us further from even wanting to reuse algorithms from the desktop codebase.

我们不得不担心诸如分配之类的事情，不仅要从内存占用的角度考虑，还要担心当您必须在短时间内处理数千个4x4矩阵时所花费的宝贵毫秒数。 预分配和就地突变使我们在性能上走了很长一段路，但也使我们甚至不想重用桌面代码库中的算法。

For complex, 3-Dimensional math, we’d of course still want to use the pseudo-algorithms, but write them in an entirely different way. Sometimes we’d have to spike to see which parts we’d keep in C++ and which can be moved up to C#. For resources intense operations, you also need to think of battery life.

对于复杂的3维数学，我们当然仍然想使用伪算法，但是用完全不同的方式编写它们。 有时我们不得不加急看看要保留在C ++中的哪些部分以及哪些部分可以升级到C＃。 对于资源密集型操作，您还需要考虑电池寿命。

Loading/processing times is a topic that sits somewhere in between performance and user experience. People aren’t going to just stand there and hold their phone while waiting for some long-running task to complete. And if the phone locks, the app might be paused. Find a way to break up work, or to hide it, stream it, or kick off a background task.

加载/处理时间是一个介于性能和用户体验之间的主题。 人们不仅要站在那里等电话，还要等待一些长期运行的任务完成。 而且，如果手机锁定，则该应用可能会暂停。 找到一种方法来分手工作，或将其隐藏，流化或启动后台任务。

代码共享 (Code Sharing)

It depends on what you are building, but the topic is almost always relevant. Do we build it for Android, for iPhone or both? How can we prevent duplicating work? The choices you make when responding to these questions will impact your product, your developers and your company for years to come.

这取决于您要构建的内容，但是主题几乎总是相关的。 我们是否为Android，iPhone或两者都构建它？ 我们如何防止重复工作？ 在回答这些问题时做出的选择将在未来几年内影响您的产品，开发人员和公司。

If you’re careful there really is no universally “wrong” answer, yet with either choice you will have to make tradeoffs which are not right or not so smooth for the future of your product — but the catch is you may not be able to predict it at the time you need to make this decision.

如果您小心翼翼，实际上并没有一个普遍的“错误”答案，但是无论选择哪种方法，您都必须在产品的未来做出不正确或不那么平滑的权衡–但问题是您可能无法在需要做出决策时进行预测。

There are pros and cons on whether Mobile development teams should share code, and I’ve seen both good and bad on both ends of this. Having cross-functional team members is good for a number of reasons, but niche and expertise on OS-specific details that might matter to some companies could be lost when everyone’s skillset is spread too thinly.

在移动开发团队是否应该共享代码方面，各有利弊，而我在这两端都看到了好与坏。 拥有多个职能部门的团队成员是有好处的，原因有很多，但是，当每个人的技能范围过于分散时，可能对某些公司而言特定于操作系统的细节的利基和专业知识可能会丢失。

记录中 (Logging)

If you’re logging messages for your app to help troubleshooting or debugging, keep in mind that your log files are in a sandbox. If you need users to be able to send you their log files, you should be thinking of how to make this easy. You could consider directly sending it from the app through email or a WebService, but ensure that you’re not violating any privacy concerns.

如果您正在记录应用程序的消息以帮助进行故障排除或调试，请记住，日志文件位于沙箱中。 如果您需要用户能够向您发送其日志文件，则应考虑如何简化此操作。 您可以考虑通过电子邮件或WebService从应用程序直接发送它，但请确保您没有违反任何隐私问题。

Using a mobile app analytics API might be a good all-in-one package, depending on your information gathering needs.

根据您的信息收集需求，使用移动应用程序分析API可能是一个很好的多合一软件包。

部署方式 (Deployment)

Whether it’s Apple’s App Store, the Windows Store (for UWP), Google Play or one of the many Android app markets, deployment is quite different than it was on the desktop. Some might say that Apple is the hardest, and I wouldn’t disagree. Entering a mass market has many advantages, but comes with its own technical requirements, legal concerns, and security requirements.

无论是Apple的App Store，Windows Store(适用于UWP)，Google Play还是众多Android应用市场之一，其部署都与台式机完全不同。 有人可能会说苹果是最难的，我也不会不同意。 进入大众市场具有许多优势，但也有其自身的技术要求，法律问题和安全要求。

If you’re going B2B and not directly to the mass consumer market, sometimes side-loading is an option, if any of the official enterprise deployment models don’t work for you, for whatever reason.

如果您要使用B2B而不是直接进入大众消费者市场，那么有时出于某种原因，如果任何正式的企业部署模型都不适合您，则有时可以选择侧面加载。

For testing purposes, there are other deployment options such as TestFlight, or TestFairy, but I don’t believe they are meant to be (ab)used to get around the official deployment strategies for distribution purposes.

出于测试目的，还有其他部署选项，例如TestFlight或TestFairy，但我不认为它们会被用来滥用官方发行策略以进行分发。

结论 (Conclusion)

We’ve covered many of the regular challenges that a Desktop developer has to go through in transitioning to modern Mobile development. The more experienced of a developer you are, the more potential this has for it to be alien for you.

我们已经介绍了桌面开发人员在过渡到现代移动开发中必须经历的许多常规挑战。 您对开发人员的经验越丰富，对您来说就越有潜力。

I hope that at some point something in this article has been helpful for old time developers who are newcomers to Mobile, or who have struggled to make their Mobile transition.

我希望本文中的某些内容对老手开发人员有所帮助，这些老手开发人员是Mobile的新手，或者一直努力进行Mobile过渡。