apk解包打包工具 app,sdk打包工具
因为工作需要，需要打包一个Python脚本，在公司推广。本来以为代码写好之后功能就正常了，没想到Python跨平台打包是一件很麻烦的事情。
公司内部同事使用Linux，Mac OS，大量Windows用户，所以需要Python跨平台打包。
在研究之初，确定了几个选定的工具，py2exe，Pyinstaller，Cx_freeze。后来在google上发现Nuitka也可以完成python打包的任务。
Pyinstaller和Nuitka都自称是跨平台的，但实际上最多只能算是工具本身的跨平台。在实际体验中，不仅打包产生的文件不能跨平台，而且能否成功打包也是不确定的。
这篇博文主要总结了上述工具在研究和使用过程中遇到的坑和解决方法。
先把结论放一边。如果对安全性和速度的要求没那么高，推荐Pyinstaller而不是Nuitka。具体原因会在下面给出。
常见Python打包工具的总结和比较
上面的URL给出了常见打包工具的简单比较。参数方面，真正能做到“跨平台”的只有bbFreeze、CX _ Freeze和PyInstaller。还有Nuitka，可以算作编译器。
Nuitka Nuitka直接把python编译成C代码，再编译C代码生成可执行文件。完全不存在逆向解析问题，非常安全。而且由于可执行文件是用C编译的，所以运行速度会提高。
但是在努特卡的实际体验中发现了很多问题。
使用Nuitka的具体说明如下
努卡-standalone-no freeze-stdlibgclt . py-output-dir=/home/why/python/gcli _ executable包完成后在本地Ubuntu 16.04 LTS下运行，但在CentOS 6服务器上执行时会产生以下错误。
GCLT:/lib64/libc.so.6:找不到Version` glibc _ 2.14 (是/root/gclt/libz.so.1所要求的)可能是因为本地打包使用的C编译器比服务器上的新，导致不兼容。毕竟CentOS 6已经很老了。
如果在服务器上打包，在本地能正常运行吗？新的本地包应该与旧版本的库兼容？
因为Python 2.6自带服务器，所以先用Virtualenv。
事实证明，服务器上的打包文件在本地运行时会遇到以下错误：
回溯(最近一次调用最后):文件“/home/why/gclt . dist/CLT _ HDFS . py”，第71行，模块文件“/home/why/gclt . dist/CLT _ HDFS . py”，第51行，执行文件“/home/why/gclt . dist/requests _ client . py”，第101行，post_hdfs_async文件“/home/why/gclt . dist/requests _ client . py”，第20行，post_auth_json_request文件“/home”检查错误源代码sessions.py行581是下面的代码，
R=adapter.send (request，* * kwargs)错误报告中提到的URL gclt_test.udp.10101111.com可以通过服务器上运行的解包代码和打包的可执行文件正确访问，所以这个问题很吊诡。
到目前为止，还没有找到解决办法。
努特卡的关键问题不在这里。在执行上述打包命令时，由于短时间内大量输出，我们没有注意输出中混杂的错误或警告信息。事实上，输出中有许多警告信息：
nuitka:WARNING:/home/Hadoop/code/trunk/client/ENV/lib/python 2.7/site-packages/poster/encode . py:29:找不到 email。作为相对或绝对导入的包“海报”中的“标题”。Nuitka:警告：/home/Hadoop/code/trunk/client/ENV/lib/Python 2.7/site-packages/requests/compat . py:58:在包“请求”中找不到作为相对或绝对导入的“http.cookies”...............
在包“请求”中找不到作为相对或绝对导入的“http.cookies”。其实造成这个问题的原因是Nuitka只支持在代码开头导入其他库，默认不支持动态_import_()方法。但是由于Python中2.x版和3.x版的兼容性问题，很多Python库中都使用SWIG来基于当前系统动态引入对应版本号的包。但理论上如果使用Python2.7，Nuitka在编译时找不到动态引入的Python 3.x包，应该不会影响最终打包产生的可执行文件。
带着强迫症追求完美的想法，我把警告信息对应的代码都注释了一遍，然后出现了以下错误：
缩进错误可能是因为某些注释代码属于try:catch代码块。
在这一点上，我已经决定放弃使用Nuitka，即使它是安全和高效的。其实高效只是指生成的可执行文件运行速度会很快，实际编译需要将近20分钟，而事后使用Pyinstaller只需要几十秒。考虑到我的剧本没有复杂的逻辑，所以没有努特卡的位置。
相比Nuitka，Pyinstaller真的好用很多。
简单使用
Pyinstaller myscript.py可以获取可执行文件，虽然也存在本地编译的文件无法在服务器上执行的问题：
Gclt:/lib64/libc.so.6:找不到版本 glibc _ 2.14 (是/root/gclt/libz.so.1所必需的)，但是在服务器上编译的代码可以在本地成功执行。当然，所谓跨平台，其实是个伪命题。Linux下编译的可执行文件不能在Windows和Mac上运行。
内存太大放不下，但是在Mac OS下，会直接提示找不到相关的可执行文件。
最后，使用Pyinstaller分别在Linux、Windows和Mac OS下完成了该任务。
经过这次打包风波，我强烈建议你在没有特殊需求的情况下，用Pyinstaller代替Nuitka。虽然Nuitka的功能感觉很高大上，翻译成C再编译成可执行文件，但是这个风骚的功能背后，不仅增加了打包时间，还可能带来很多意想不到的问题。
所以，如果再给我一次机会，脚本应该是用Java写的。虽然写起来麻烦，但是跨平台支持比Python好太多了。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。