动机
“好的代码值得共享”
“快速完成第一版的原型，快速迭代”，如同许多初创Sass公司一样，我们也同样信奉这个时代快速迭代的开发方式，按照设计，我们第一个上线的版本是我们的Web版以及iPhone端，紧接着，我们面临着需要做Android移植开发的需求，这时摆在我们面前的有几个纠结:如果开放iPhone的源码给Android的同学“翻译”一遍iPhone的工程了话可能会面临同样的一个Bug被duplicate了一遍，然后iPhone的改了，再建个任务给Android的同学- “Hi,我们这里改了一个Bug,你们也改改吧”，然后每做一个模块，再各自产生一堆的Bug，再疯狂的改Bug-好的代码没有被复用，只是Bug被一次又一次的提上日程。而且在快速迭代中，我们需要用很少的人力(1 iOS, 1 Android)来完成初期版本的开发，而且在快速的迭代过程中，我们需要频繁的面对诸如接口变动，某个类添加了一个字段这种需求，所以我们自然开始探索起一份跨平台的解决方案。
在探索了当前主流的跨平台技术路线中，runtime方式跨平台的(如嵌入一个WebView)方式由于其性能有明显的滞后感并没有列入我们的考虑范围，我们主要考虑了使用C++这种各个平台都支持的方案以及“翻译系”的方案(j2objc等)后，针对我们的背景:开发人员比较少，而且之后招聘到的人员应当是以原生平台语言为主(这点在事后被证明创业公司非常需要考虑，比如做iOS开发的招到一个会Swift的也会Java的相对来说还是很困难的)，最终决定使用C++ 11作为核心库的语言(核心库指的是MVC中Model层的所有代码)。
在1年半的实践中，C++ 11带来的好处主要有
1.稳定:C++的方法几乎不会出现deprecated的状况，相对于我们iOS使用 Swift 几乎每次Swift都有代码迁移的工作，C++的代码部分极其稳定
2.性能:这点其实在对性能要求相对较低的App开发领域，其实不是特别特别需要考虑的问题
3.容易搜索:作为一门历史悠久的成熟语言，大部分的问题都可以Google出来(这点其实也是非常重要的)
4.单元测试:依赖于gtest，单元只需要写一遍，并且可以运行于所有的平台之上(单元测试是我们目前发现的唯一一种可以保证代码质量的方法)
5.有现成的代码规范:基于Google C++ Code Style以及其提供的lint检测工具，我们可以很大程度上保证C++代码的可读性，这份Code Style很好的解决了C++内存管理部分难以判断的问题
方法
“C++ 11是一门全新的语言”
C++在iOS上可以通过Objective-C++的形式进行几乎原生的调用，并且由于C++ 11 Smart
Pointer的出现，几乎不需要进行额外的内存管理。
在Android平台上，C++是通过NDK进行的调用，对于Java的开发者来说，C++仍然是一门有着比较陡峭的学习曲线的语言，但是在工程开始初期，团队只需要1名C++的编写者，所以还是有比较充分的学习时间留给Android开发的同学。
在成功的Hello World之后接下来就是考虑一些常用模块的迁移(这里也是一个极其重要的需要预先调研的地方，如果一个功能的第三方库没有找到很好的C++的替代品，那么用C++自行实现一次有时候会是一个非常巨大的成本)
对于我们常用的网络链接、缓存等功能，都已经有一些现成的成熟第三方库可以满足我们，对于App开发，常见的有:
HTTP网络连接: (libcurl)
SQLite持久化存储(easySqlite)
JSON解析(json11)
XML解析(tinyxml2)
Websockets(libwebsockets)
Key-value缓存(levelDB或者用SQLite)
结构
如上图所示，我们将所有复杂的核心逻辑都写在了 C++ Core 这层，Objective-C++ 和 Java Wrapper 只是简单的将 C++ 的方法以 Objective-C 和 Java 的形式暴露给了 App Developer 进行调用 (Win C++ 可以直接调用标准 C++，只需要 dll import/export 好了对应的代码就行)。对于 UI 层的界面代码，我们仍然使用 Swift 以及 Java 进行书写，这样可以保证我们最大可能的能获取原生 App 带来的好处，以及对系统自身的 API 访问的便利性，而且原生的 App 开发者在进行产品布局等改动的时候也能最大程度的获得原生平台的大量的第三方库的帮助。
示例代码
Wrapper只是简单的将C++的方法以Objective-C和Java的形式暴露给了App Developer进行调用(Win
C++可以直接调用标准C++，只需要dll
import/export好了对应的代码就行)。对于UI层的界面代码，我们仍然使用Swift以及Java进行书写，这样可以保证我们最大可能的能获
取原生App带来的好处，以及对系统自身的API访问的便利性，而且原生的App开发者在进行产品布局等改动的时候也能最大程度的获得原生平台的大量的第
三方库的帮助。
本篇我们将提供最简单的iOS以及Android [示例代码 ]来阐述我们的结构。
下一节
下一节中我们将以Worktile OpenAPI 介绍我们是如何搭建一个包含网络请求、缓存的应用。
再下一节
下一节中我们将介绍我们如何使用代码自动构建工具构建出我们的Model层代码以节约反复编写同样结构代码的时间。