将java服务器移植到Android
我正在开发一个使用 OpenMRS 作为 Android 后端的医疗记录系统。 OpenMRS 依赖于一些重量级库，包括 Hibernate 和 Spring。
“Deshing”整个 OpenMRS 应用程序会生成一个太大的文件，即使对于 Android classes.dex 文件格式也是如此（这个大小限制已经有详细记录）。为了解决这个问题，我目前正在努力从依赖项创建多个 dex 文件，并在运行时使用 Android 的 dex 类加载器加载它们。
由于实际使用移动版本服务器的方式，尽管存在巨大的依赖性，但实际处理需求将非常低。我不想在这里在我的手机上运行企业服务器。
在我花费几周的时间尝试设计这个之前，我只想问开发者社区：这个策略只是一个白日梦吗？如果我加载所有这些库，整个二进制文件是否会加载到 RAM 中并破坏系统？有没有好的方法来优化这样的应用程序？我在这里缺少一些明显的问题或解决方案吗？
I'm working on developing a medical records system using OpenMRS as a backend for Android. OpenMRS is dependent on some seriously heavyweight libraries, including Hibernate and Spring.
"Dexing" the entire OpenMRS application generates a file that's too big even for the Android classes.dex file format (this size limit is already well-documented). To get around this, I'm currently working at creating multiple dex files from the dependencies and loading them during runtime using Android's dex classloader.
Because of the way the mobile version of the server will be used in practice, the actual processing demands will be very low despite the huge dependencies. I'm not trying to run an enterprise server on my phone here.
Before I spend weeks more of my time trying to engineer this, I just wanted to ask the developer community: is this strategy just a pipe dream? If I load up all these libraries, will the entire binary get loaded into RAM and just break the system? Is there a good way to optimize such an application? Is there some obvious problem or solution I'm missing here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简短的回答是：不要。
长的答案是，大多数设备仍然只为每个堆分配相对少量的内存（40-128 兆 RAM 之间）。您确实需要考虑构建应用程序，以便大量逻辑以及库和重量级代码仍然驻留在服务器上，而移动应用程序只是从服务器读取轻量级数据（JSON？）进行显示。设备实际上应该只利用位置数据等本机项目，并为用户提供与 Android 世界其他部分一致的界面。除此之外，您应该寻找方法将尽可能多的逻辑保留在本机应用程序之外。如果没有其他原因，只是为了保持更安全。对 Android 应用程序进行逆向工程微不足道，并且在服务器端保留的内容越多，就越安全。
The short answer is: Don't.
The long answer is that most devices still only allocate a relatively small amount (between 40-128 megs of RAM) of memory to each heap. You really REALLY need to think about architecting the app so the bulk of the logic and thus the libraries and heavyweight code still reside on a server and the mobile app is just reading lightweight data (JSON?) from the server to display. Devices should really only utilize native items such as location data and provide an interface to the user that is consistent with the rest of the Android universe. Beyond that, you should be looking for ways to keep as much logic out of the native app as possible. If for no other reason than to keep it more secure. Reverse engineering Android applications is trivial and the more you keep on the server side, the more secure you will be.