话说最近 0 基础开发 Android，之前也是 0 基础开发 iOS（使用 Swift），还是 Android 这边简单一些，综合开发工具、语言掌握难度（应用级的 Java 开发基本不需要学...）还有框架（但 Swift 真是门好语言...）。

我们的产品是一款依赖网络的偏社交类应用，作为后端开发出身，简单熟悉下 Java 热身完毕后，大概是这样的思考路径，整个过程一周多点的时间： （省略了查阅资料选型的过程，老实说这花了大约 1/3 的时间）

• 映射服务器端的 APIs

  • 选择网络库、JSON 解序列化库：最终选择 Retrofit2 + Okhttp3 + Gson
  • 对照 API 文档编写实体类（脏活）
  • 按照 Retrofit 的文档及 API 文档映射 API

• 改进

  • 类似 type、status 的字段使用枚举表示
  • 因为 CDN 使用又拍云，封装 photo_url 字段为 Photo 类，提供 getUrl(Version version) （ Version 是枚举）方便 UI 层获取需要的图片版本 URL
  • 针对非 Java 标准类型（针对上边提到的）需要自定义 Gson 的解序列化规则，查阅文档需要编写相应的 TypeAdapter
  • 登录后需要为每次请求附加 OAuth2 access token，结合 Retrofit2 的使用方式，封装 Session 类，其持有登录状态，并提供方法生成 API 调用对象（和 Retrofit2 的用法有关），附加 token 的逻辑封装在其中

• 周边

  • 持久化配置，Google 可知 Android 提供了 SystemPreferences 类，可以储存配置等数据
  • 初始化时配置 OkHttp、Gson 等库，如设定请求超时时间、编解序列化规则等
  • 日志，方便打印一些调试信息

• 验证

  • 编写登录功能，验证设计可用性、易用性

• 重构

  • Retrofit2 对于复杂的 API 调用复杂（受制于 Java 的表达能力），包一层... 为每个 API 都提供了一个工厂方法，其接受相应的 Form 对象（里面封装了这个 API 接受的字段），返回 API 的调用对象（这个跟 Retrofit2 的使用方法相关），针对列表类 API，设计 Pager 翻页器类，其维持当前页数、每页返回记录数等状态，使得 UI 不需要关注翻页的细节，仅需根据在 API 响应后更新
  • 自定义 Application 类，将 Session、Logger、SystemPreference 等的实例由其持有

• 利用搜索引擎、社交网络了解 Android 的牛人还有完整的项目，看他们的项目结构、依赖，吸收他们的做法，把认为合理的（基于我自己的知识和判断）吸收进来

• 实现一个复杂的 UI，验证之前的全部设计，思考在基础设施方面还需要提供什么？

对于要做什么、怎么做，扯膜式就比较形而上了，一切围绕一个原则：让写 UI 的时候爽。