aosp emulator 设置分辨率

转载

数据探索先锋 2024-11-05 10:29:12

文章标签 aosp emulator 设置分辨率 App 解决方案 Android 文章分类 机器学习人工智能

aosp emulator 设置分辨率_解决方案

背景介绍

提起 Kindle，很多人想到的都是亚马逊设计的平板阅读器。目前市面上主要有4款产品，分别针对不同用户群体，它们是：

Kindle E-reader。入门级，最便宜，最轻薄，能存1000+本书。
Kindle Paperwhite。分辨率从166pi提升到300pi，新增4个LED背光灯，解决了阴暗环境中光线不足的问题。
Kindle Voyage。特色是配备自动感光和PagePress压敏按键。
Kindle Oasis。旗舰产品，具备一切Kindle 的优点。针对单手阅读设计，防水，能存2000+本书，背光灯数量增加到12个。价格也最高，是入门版 Kindle 的2.5倍。

Kindle 硬件的诞生可是说是亚马逊发展的必然：亚马逊依靠在线书店起家，随后扩展到万物零售，最后再把书从线下搬到线上，并且以规模效应降低价格，进而最大限度的提高市场占有率。可以说 Kindle 的出现和发展符合亚马逊一以贯之的商业模式，是一款意料之中的产品。

相比于 Kindle 的硬件，Kindle App 在绝大多数时候都起着补充和防御的角色。因为 iPad 和安卓平板的流行，Kindle 平板受到了很大的挑战。为此贝佐斯决定两面下注，一面坚守 Kindle 平板的产品线并不断完善，另一面开发 iOS 和 Android App，以在移动时代的两大平台占据一席之地。

今年是 Kindle 发展的第10个年头。作为十周年庆典的拳头项目，Kindle App 进行了全新的设计和改进，之所以这个时候发布新的 Kindle App 是因为：

硬件的发展空间已经不大。整条 Kindle 产品线经过10年的发展，已经非常成熟完整，各款产品的区别和用户定位也十分清晰。
将 Kindle 打造成软硬兼备的平台。硬件的标签在用户心中已经足够深刻，软件的加强可以为整个平台带来更多的用户。
整合 Goodreads 读书社区。亚马逊收购的 Goodreads 是全美最大的读书和社交社区，将其整合进 Kindle 生态圈势在必行，而新 App 是一个绝佳的切入点。

aosp emulator 设置分辨率_解决方案_02

Kindle 硬件产品线

All-New Kindle App 是怎样炼成的

新的 Kindle App 从两年前就开始构思设计。整个产品从构思到设计到实现都充分贯彻着3W（Why，What，How）原则，并围绕用户展开。具体来说，它们是指：

首先是发现问题。即老 Kindle App 的问题是什么，新 Kindle App 需要解决什么新的问题。

老 Kindle App 的槽点集中在 UI/UX 方面，例如：App 配色过暗只有黑色；Hamburger Menu 功能过于凌乱，本地搜索、网上书店、设置挤在一起。新 Kindle App 需要解决的新问题是如何整合 Goodreads 社区。

这些问题的发现都是经过严格的市场调查和数据分析，它们的来源主要是：

用户的反馈。主要是 App Store，Amazon，Twitter 上面的评论和专门的市场调查。
整合的战略。Goodreads 收购后一直独立运营，和亚马逊现有产品线略有互补却没有融为一体，与 Kindle 一起形成闭环生态圈有利于整合两个平台的用户，同时带来更深入的用户体验。

不仅如此，对于反馈的诸多问题和需要增加的多个功能，Kindle 会依据其对用户影响的深度和广度进行优先排序。有些问题是困扰用户的老问题，而且有很多用户都在抱怨，比如 Hamburger Menu 功能过于拥挤零碎就是这一类问题。还有一类问题例如内存泄漏，影响了 App 的效率 —— 虽然工程上是个大问题，但是用户感受并不明显，而且这类问题也只是在很少的用户使用时会发生。因为时间有限，这类问题，他们的优先级一般较低，放在之后在做。

按照优先级解决老问题，增加新功能，这就是为什么（Why）要做新 Kindle App 的原因。

aosp emulator 设置分辨率_App_03

老 Kindle App 将所有功能放在 Hamburger Menu

其次是定义问题。这是一个将老 Kindle App 中发现的缺点和需要添加的新功能翻译为切实可行的工程任务的过程。

针对配色过暗的问题，解决方案是设计黑白两种颜色主题，用户可以自行选择喜欢的颜色；针对 Hamburger Menu 功能过于集中的问题，解决方案是采用 tab bar 来将类似功能分类，选择起来更加直接清晰；针对 Goodreads 整合的问题，解决方案是将其作为一个独立的 tab 插入到 tab bar 当中，并在“更多”界面中引入 Goodreads 登陆接口。这些解决方案的提出都是市场调研的结果。

在工程上，任务主要依据不同界面进行拆分。tab bar 作为单独的导航模式是个单独的工作块，基于 tab bar，“库”、“社区”、“发现”、“更多”这4个模块亦分别由专人负责。同时通知和搜索栏也是单独的工作模块，这样一共就有7个大的工作任务 —— 在实际操作中，它们又被分为更细小的任务方便监控和执行。

定义问题并拆解任务，回答了新 Kindle App 是什么（What）。

aosp emulator 设置分辨率_App_04

全新的 Kindle App

最后是解决问题。这其中主要包括如何按时完成任务、如何保证产品质量、如何在开发中寻求反馈、如何协调各个组员之间职责的问题。

团队在开发初期就定义了整个项目的发布时间为2017年10月底。整个开发被拆分成了3个阶段。

第一个阶段是主要功能完成。时间长度大概为3-4个月，主要包括全部的 UI 完成。完成后 Kindle App 在公司内部发布了 Beta 版本，获得了大量反馈。

在反馈的基础上则进入第二个阶段，时间长度为2-3个月。主要包括优化架构、国际化翻译、功能修改、添加分析日志、修正主要漏洞等。第二个阶段完成后，App 已经完成了所有的需求功能，已经达到产品发布的水准了。当然，团队会在这之后再次在公司内部发布产品并收集反馈。

第三个阶段就是修 Bug 和产品发布准备了，时间长度为1-2个月。这期间大家集中全力消灭 Bug 并做大量测试以保证万无一失。公司内部开始和媒体接触并准备发布产品。

之所以强调时间长度，是因为 All-New Kindle App 是一个日期驱动（Date-Driven）的项目。这就要求了各个时间节点要协调一致，对于拖延和提早完成的情况，每个阶段又要相互调整。实际上团队在一开始计算任务耗时的时候，每个阶段都预留了3周以上的时间来防止意外发生和处理反馈，实际中也确实出现了很多料想不到的情况 —— 幸好预早有应对，最后 App 才有惊无险的按照既定时间出现在了用户面前。

整个解决问题的过程，定义了 App 是怎样（How）一步一步炼成的。

aosp emulator 设置分辨率_Android_05

Kindle 与 Goodreads 整合，使得其社交功能大幅增强

亚马逊内部的团队合作

如何在限定时间内，高质量的完成一款影响全球范围内千万用户级别的应用，非常考验亚马逊的团队效率。亚马逊作为建制完善、流程严谨的跨国公司，这次项目的成功，我个人觉得是依赖于各司其职、分工细密的团队合作。其中，这四个职位我觉得值得一谈：团队经理、项目经理、工程师、设计师。

工程经理：从项目的确立、讨论、执行全程参与。上与领导层讨论决策；下与产品经理制定目标；再到给工程师分配任务，密切关注项目进度和把控质量；平时还要与其他组的团队经理进行沟通和协调。如果以一个稳定运转的系统来类比，经理就相当于是 Dispatcher，是最为核心的节点。负责新Kindle App级别的工程经理大多拥有深厚的技术背景和管理经验，可以说是技术硬实力和沟通软技巧兼备，非常值得信赖。
产品经理：负责任务的确立、拆分、跟进，以及反馈的处理。主要是将用户的需求转化为具体的功能；再与工程师沟通，将功能转化为一个个可实现的工程任务；同时还要遵循敏捷开发流程将反馈的信息传达并跟进。亚马逊的产品经理都具有相当的工程背景，很多甚至是软件工程师转行。
工程师：高级工程师会去参与项目初期的讨论，确定工程上的可行性。然后所有工程师会全部参与到具体项目的开发和测试中。开发工程师的工作就是实现功能、优化架构、消除 Bug、单元测试。之前提到过的7个大任务，每个都有1个主工程师负责，这样确保了问责到人。同时在 code review 时，每次有至少2名工程师、必须在24小时内审阅代码给出反馈，这样保证了团队中其他人对整体代码更新的熟悉。测试工程师主要负责的是单元测试之外的检测。亚马逊内部还有定期的查虫（debug）大会，就是所有相关人员聚在一起随意对 App 在各种平板和手机上进行试用，并将发现的问题和不合理的设计进行反馈。
设计师：前期参与项目的原型设计。在 PM 反馈信息后作出原型修改。将修改后的设计图和需要的素材交给工程师去进行开发。在工程师开发完毕后设计师会第一时间试用，并向工程师进行用户体验和视觉上的反馈。亚马逊的设计师使用 Sketch 和 Invision 进行工作，他们同时也参与日常的开发会议中以确保 UI 开发的正确。

aosp emulator 设置分辨率_Android_06