=。=

gistfile1.txt

> There are typically two ways to use Go on Android and iOS. The first is to write a Go library and use `gomobile bind` to generate language bindings for Java and Objective-C. Building a library does not require the app package. The `gomobile bind` command produces output that you can include in an Android Studio or Xcode project. For more on language bindings, see https://golang.org/x/mobile/cmd/gobind.
The second way is to write an app entirely in Go. The APIs are limited to those that are portable between both Android and iOS, in particular OpenGL, audio, and other Android NDK-like APIs. An all-Go app should use this app package to initialize the app, manage its lifecycle, and receive events.

引用自<https://godoc.org/golang.org/x/mobile/app>

第一种方式，也就是目前我们项目里所做的，采用 Go 生成 RPC 文件，然后在 Android 项目里可以调用它。第二种方式，由于 Android 平台本身就是 Java 写的，大量 API  本身就是基于 Java 的，想封装起来工作量会很大，几乎不现实。而 Android 的 NDK API 是基于 C 写的，所以 GoMobile 把这部分封装了，使得可以用 Go 开发游戏，这些基于 OpenGL 实现的跨平台应用。

所以初步分析，用 GoMobile 是不能实现『用 Go 编写跨平台的 FastLemon』 这样的功能的。然后搜的过程中了解了一下 Facebook 的[react-native](https://facebook.github.io/react-native/)，感觉从概念上来说两者是很类似的，然后 ReactNative 大概原理：
> 1 React Native for Android 和 for IOS的基本原理是一致的，通过android的JavaScriptCore来异步解析js代码(jsbundle文件)，然后根据引入的支持和配置，渲染成原生native组件。
2 复用React系统，也减少了一定学习和开发成本，更重要的是利用了React里面的分层和diff机制。js层传给Native层的是一个diff后的json，然后由Native将这个数据映射成真正的布局视图。

类比到我们项目，我们首先得实现一个界面库，然后要处理这些应用的数据绑定，生命周期，事件处理等等，然后对于 Java API 那部分，要么是用 GoMobile已经实现的那部分 API 自己重新实现一遍，要么全部把 Java API 抠出封装起来。前者感觉工作量很大，写个按钮都得花费很多精力，现在看起来可行，但是肯定越写发现坑越多，相当于重写一个 Android 的轮子，那还不如去找 COS 系统的团队被招安得了；后者，形容一下就是把 Java 的常用 API 都封装起来，然后用 Go 调，但是假如每次新增加了功能都得去封装个新 API，那希望用 Go 开发跨平台应用的意义又在哪呢？
而且比如 React Native 就存在这个问题：
> 系统仍然（不得不）依赖原生组件暴露出来的组件和方法。举两个例子，ScrollView这个组件，在Native层是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，这些事件在现有的版本都没有暴露，基本上做不了组件联动效果。另外，这个版本中有大量组件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反过来看，剩余的都是一些抽象程度极强的基本组件。这样，用户必须在不同的平台下写两套代码，而且所有能力仍然强烈依赖 React native 开发人员暴露的接口。

如上所说，试图通过抽象封装这些控件、 API来实现一个跨平台应用基本是不现实的。然后现在有两个思路，一个是利用全 Web 的方式（利用 Web 这个已经发展好的轮子），另一个是类似游戏开发的模式（用 OpenGL 自己全部实现）。前者如某个不能说名字的那样，Mac 端与 Windows 端都是通过 Web 实现的。后者，就像之前提的那样，基于 OpenGL 自绘控件，类似开发游戏（GoMobile 的 All-App 推荐的场景就是游戏开发）。这种方案不考虑开发成本，从技术上是可行的。

如大师所说，抛弃 Android 自带的那一套，Activity、Fragment 这些都不管，所有操作都在NativeActivity里进行。