用Qt重写，这个对你来说应该算最快的方式了。

可以使用ndk ，在android中使用java 调用 c++模块代码，编译成动态库so 后，java中定义 native 函数进行调用，具体google 吧

动态调用.so文件，.so文件就是c写的（使用ndk编译）

如果想用C++做跨平台，最好的开发环境就是QT,windows，linux，android，ios。安卓5.0以上版本都是支持的，但是ios得需要苹果的操作系统。据说 VS也要整合android和ios的开发功能。你可以把MFC的程序移植到QT平台下，我感觉qt要比MFC好用。

要不都说用标准C++,不是VC++,问题就出在可移植性,MFC绝对平台相关的,况且MFC丫的微软都不关心...

QT好像有这个功能，但是具体我也不清楚，得靠楼主自己去看看了

WTL MFC COM肯定要全部重构

逻辑部分可以写成*.so库通过jni向上层提供接口
你搜一下android—ndk，这个加上cygwin，就可以实现linux下的动态链接库。os文件
对于C++移植，我想你最先应该知道平台相关指令，因为有的指令并不是通用的。所以如果你是基于windows下写的C/C++的话，应该先修改平台相关的代码，表现层的话，利用android做，具体的实现就是NDK开发流程。

qt for 安卓可以满足你

使用NDK为正解，但是为了方便学习，直接使用coco2dx就完事了，C++生成Android和ios程序。。

coco2dx NDK百度搜这个吧 不会可以找我

首先你要清楚自己的需求，移植什么？是否你提到的你的module里，用到了sdk wtl mfc com,如果你想全盘的移植，那是不可能的。c++角度的所谓的cross platform是你的代码是与平台无关的，或者有一套跨平台的系统相关功能模块，例如thread,file operator,timer,等等，也就是说我们能够多平台使用的code仅限与native c++或跨平台的库。那么，对于你来说，你需要跨平台的mfc.com......所以，重写吧，公用你的与平台无关的code

看可不可以在Android手机上装个c++的运行环境？

lz，你要先想好了，这个是自己有决定权，还是老板给你的任务就是“移植”。

我想说的是，你用了mfc，还封装成com组件，这完完全全就是选择了连微软都抛弃的只能在windows平台下运行不能移植的技术。

在这个情况下，直接推倒重来或者另起炉灶是更佳选择，所以说要问问你是否有决定权，至少是选择权。把功能、界面做的和原先一样就可以了。

wince 也是一个不错的选择 你可以考虑一下

QT，Cocos2D-X都可以跨平台编译的，楼主可以参考下

很难，没法直接移植过去，你用了WTL和MFC，这是微软的东西，安卓虽说可以通过NDK使用C/C++，但是只限于标准的C/C++，所以，你需要将程序中用到的和WTL和MFC有关的地方都通过标准C/C++来实现，或者找到这些功能的arm版，然后把整个源代码放在NDK环境下或者android源码环境下进行编译，如果顺利通过，恭喜你。

想了想，还是直接重写android版吧，只要界面和功能和WINDOWS一样就行了，老板又不懂代码

指令集和寄存器数量都不一样啊。。用交叉编译duang一下，然后自己写个安卓应用型的调用器调用

首先, 正如很多网友指出的, 你已经使用了WTL, MFC, COM 技术, 这些都是微软平
台相关的技术, 因为不清楚你代码的组织方式, 很难说这些平台相关的部分与平台
无关的C/C++部分多大程度上是各自独立并有良好接口的.
以上是你自己提出来的平台相关技术,  还有你没提, 但我觉得也一定或多或少是
个问题的,就是你所使用的C/C++, 有多少是Visual C++编译器特定实现相关的, 有
多少是可移植的C++代码(姑且说符合C++标准吧.)

所以第一件事是:
你要自己评估这事值不值得做, 如果不值得做, 还有以下两种说道:
1. 完全放弃
2. 重新开发, 据软件工程研究人员收集到的统计数据得出结论, 软件项目移值如
果有超过30% 部分需要修改, 那就可以考虑重做而不是移值了.

如果值得做, 或者, 因为其它原因, 就是得做, 有以下思路供参考:

1. 认真评估你的项目中对平台相关的部分和平台无关的部分的比例, 以及更重要
的, 它们之间的组织关系,

2.  你的项目中有UI, 而且可能是重点, 你需要考虑一个跨平台的实现UI的方式.
可以考虑的选项有:
    2.1 Qt
    2.2 Java技术实现UI
    2.3 wxWidget 这个我都不知道算不算可选项. 因为你的目标是移植到
    android"等"(我假设这个等是 iOS吧), wxWidget在iOS上表现如何, 我还不清
    楚
    2.4 其实我觉得上面的3个选项都不靠谱,  我真正推荐的做法是, 你要把整个
    项目的UI层和其它部分隔离开来, 然后在各个不同的平台上用那个平台最合适
的UI做, 剩余的部分尽可能做到各个平台能公用.  我相信现实世界中一些大的成
功的跨平台项目是这样做的, 比如netcape浏览器(早期版本), FireFox, chrome浏
览器.
    但是, 你的情况和netcape/chrome这些例子不同, 它们是从一开始就计划要同
时支持的平台, 而且对各个平台的支持必需是同时的, 这样才不至于其中一个平台
逐渐变得更重要, 其它平台逐渐落后最终难以支持.
    不幸的是, 软件开发中的好些质量品质, 都不是能在事后轻易添加上去的, 比
如错误/异常处理策略, 多线程/并行/可扩展性, 以及跨平台.

3. 具体评估时, 建议多利用编译器本身的报错机制, 比如, 先把你的整个项目的
*.vcproj 转换为 目标平台上可以编译的项目组织, 如makefile, 然后用目标平台
上的C++编译器(gcc/clang) 来编译你的项目. 从编译器的错误输出中你可以了解
到你有多少是平台相关的依赖.

在你到目标平台上尝试编译/链接之前, 其实可以通过windows上的本地编译器VC++来检验
你有多少是平台依赖的, 一个简单的办法是, 到VC++项目的属性页(VC不同版本属性位置
也不同, 我只说大概步骤), 编译选项中, 有一项是显示编译过程中包含的头文件, 对应
的命令行开关是/showIncludes, linker选项中, 有一项对应/verbose 开关的, 打开它(
默认是关闭的), 然后rebuild你的程序,  你可以在output窗口看到编译每个.CPP文件都
需要依赖哪些头文件, 链接时每个符号是在哪个库中得到解析的, 从这你可以大致评估出
依赖的程度.

如果我跟你一个公司, 我倒是有兴趣陪你经验这个过程, 我有个同事说, 跨平台项目本身
就是伪科学, 他有他的道理, 虽然我并不认同, 我认为是件难搞的事, 但并非不可能, 毕
竟大把成功的大型跨平台在那摆着, 我对这个主题很感兴趣, 希望过段时间还能看到你对
这个项目的后续跟进的分享.

WTL MFC COM,这几个靠的是Windows的接口，到android上是不行的。
所以和Windows关联接口强的建议换成Qt。
学java重写的整个代价太高，而Qt是C++的。

来学习学习

1. 既然用了COM组件，那在移动平台下需要重写了，因为目前移动平台下不支持COM组件；
2. 重写时有界面要求的话用QT，现在QT全面支持移动平台开放了，QT是一个跨平台的开源项目，移植性非常好。

综上所述，只能重写，MFC之类的全部都得换掉。

只要c++写的功能很容易一直，但界面你需要移植，用java或者QT

> 我在windows平台下基于sdk WTL 及mfc，并混合c语言开发了一个图文编辑器，并封装成了一个com组件的形式。

基本没戏，用 C++(JNI) / Java 重写吧。