SkyFly

最近在研究 VMP 相关的东西，看来最终还是要搞一搞 LLVM 这个大家伙，还蛮有趣的，下面直入主题。

Background

As a Chinese old saying goes: Review the old and know the new (温故而知新). I learnt a lot from the OS class, recently, despite that I have taken this class 5 years ago during my undergraduate study. The latest topic discussed on the class is concurrency and deadlock, I think it is a good time for me to review some concepts of concurrent programming.

Backgound

Recently, I started my master’s study on computer science at NYU. Going back to school life is amazing for me, but at meantime I have to deal with assignments and labs. For me, labs are more interesting than lectures. On doing one of my labs, I met a issue related to today’s topic – getopt

0x00 前言

最近刷 leetcode，又回去回顾了很多数据结构的知识。刷题时经常会碰到使用 HashMap 来实现 O(1) 时间内的元素快速查找，以空间换时间。Hash 表的基本原理就是对 key 进行哈希运算得出 HasCode，然后通过对 HashCode 进行变换得到数组的 index。最后将 value 插入到该 index 位置上。但实际上，并不存在完美的散列算法能使得对于每个不同的输入值都能得到独一无二的 HashCode。这也就意味着对于不同的输入值可能会产生相同的 index，这也就是哈希碰撞。对于哈希碰撞大体上有两种解决方案：按照一定规则寻找数组中其他空余的位置，将 value 插入该位置；在 index 位置上使用链表来保存相同 HashCode 的 key 对应的 value。Java 选择了后者的实现方式。那么问题就来了，在对 HashMap 进行 get 操作的时候，势必要进行 key 值的比较。如果 Key 的长度很大的话，HashMap 的 get 操作耗时应该会显著增加，那么是不是这样呢？ 今天研究了一下这个问题。

OnePassword 解决的问题

网站账户太多导致需要记录的账号和密码太多，一般人很难记住很多不同的密码。于是很多人会在不同的网站使用相同的账号密码，但是一旦其中一个网站被拖库，所有网站的密码就都会遭到泄露，这种做法很不安全。OnePassword 就针对这个情况为人们提供了一个安全的生成，存储和登录自动填充密码的解决方案。

那么，OnePassword 是如何解决这个问题的呢？

0x00 前言

iOS 签名机制比较复杂,涉及到一堆证书，Provisioning Profile，entitlements，CertificateSigningRequest，p12，AppID 等等概念繁多，也很容易出错，下面我们就来看下这些概念到底是什么？是怎么和 iOS App 的签名机制一起工作的？了解这些会有助于理解 iOS 这套复杂的签名机制。

按照我司的现实情况来讲，app 团队基本上维持着一个 10 人以上的移动研发团队，团队里面有项目经理、开发和测试同学，在研发过程中基本上都是多个项目同时进行。在项目的发展中，其中有些项目会参与到各种运营活动之中，需要和其它团队进行协作。所有的代码都耦合在一个客户端里面，每个月至少要发布 2 个版本，大家开发周各自开发暂时相安无事，一旦到了测试周要合代码到一起就出现各种诡异问题导致构建不成功、功能不可用、测试需要反复无数次验证依然惴惴不安。如何才能更好地协作开发，以较高的效率完成 App 开发工作呢？

HTTPS 原理

HTTPS 相比 HTTP 而言多了一个 s，也就是 SSL（Secure Sockets Layer），安全套接层。SSL 做的事情就是将用于通信的对称加密密钥进行非对称加密，以此来实现高效且安全的通信。整个 HTTPS 通信的时序图如下，包含了 HTTPS 四次握手。

0x00 目标产品决定技术方案的选择

短生命周期和长生命周期产品

短生命周期的产品通常要求快速起步并在短时间内出品，目的性极强，技术门槛低、代码随便写、不用考虑任何最佳实践。当它的使命结束时，这些代码会被直接抛弃。比如 项目 Demo，临时活动专用 App。 所以，对于这类产品类似前苏联式的 “快糙猛” 的技术是较好的选择。当然能 “快精猛” 更佳，但在现实的短周期开发中实际上很难做到。

而长生命周期的产品则会对可维护性和可扩展性要求十分强烈，因为它们在相当长的时间内都是无法报废的。甚至对于一些关键的生命线产品，连项目重写都会要求在重写期间线上系统要万无一失地平稳度过，完全平滑地迁移到新技术。这种高水平的要求对团队的工程化能力是个极端的考验。如果工程以及项目管理能力有限，其代价不比用新技术重新写一个功能相同的系统更低。

0x00 Before takeoff

在这个 App 泛滥的时代，从无到有开发一个 App 看似是一个很简单的事情，网上也有大把的教程来告诉你如何开发各种 App 和网站等等。但是在实际工作中，当我们提到“做一个 App”的时候，含义却十分深奥，那么这个坑到底有多深呢？我希望能够通过几篇文章的篇幅来做一个简要的叙述。

要说明的是，这个系列的文章并不会和网上大量的 App 开发指南类文章一样只是简单着眼于技术细节。而是通过对几年工作经验的总结来讲述当你在一个企业中从事客户端或者前端开发工作，面临一个全新的 App 开发任务时需要如何从头开始考虑整个任务以及流程。

只是一点微小的见解，希望能够给观众一点帮助。如有考虑不周，欢迎指教；如有失误，请多包涵（作揖）。