为多个移动设备构建单一应用程序
是否可以为多个移动设备（在 BREW 平台上）构建一个应用程序二进制版本，而不是使用带有条件编译的构建脚本为每个设备进行单独的构建。
特别是是否可以使用针对多个屏幕分辨率构建的单个 BREW 应用程序？
请注意，目标是拥有单个二进制构建。 如果只是拥有一个代码库，那么条件编译和智能构建脚本就可以解决问题。
Is it possible to have one application binary build for multiple mobile devices (on BREW platform), rather than making a separate build for each device using build script with conditional compilation.
In particular is is possible to use single BREW application build for multiple screen resolutions?
Note that the goal is to have a single binary build. If it would be just to have a single codebase, than conditional compilation and smart build script would do the trick.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
另一个想法可能是根据屏幕尺寸将手机分为 2 到 4 个类别，并为它们创建构建。 这也是一条更快的路线，因为您将能够以更低的复杂性支持您想要支持的所有手机。
另一件值得注意的事情是您想要启动的手机上的 BREW 版本。 如果说 BREW 1.1 在一款手机上，并且目标市场中只有一小部分人拥有它，那么努力支持它就没有意义。
Another idea might be to have the handsets divided into 2 to 4 categories based on say screen dimensions and create builds for them. It is a much faster route too as you will be able to support all the handsets you want to support with much lesser complexity.
Another thing to see is the BREW versions on the handsets you want to launch on. If say BREW 1.1 is on one handset and that is owned by a small percentage in your target market, it doesnt make sense to work to support it.
是的，有可能，我们可以在我以前的工作地点做到这一点。 不过，所需要做的事情很棘手：
最后，应用程序越复杂和先进，你走这条路的可能性就越小。 某些设备属性根本无法在运行时可靠地检测到（例如平台 ID），因此需要多次构建。
Yes, it is possible, we were able to do this at my previous place of work. What's required is tricky though:
In the end, the more complex and advanced the application, the less likely you can go this route. Some device properties simply cannot be detected reliably at runtime (such as platform ID) and so multiple builds are then required.
我编写了一个用于 Javaground 的 J2ME 到 Brew 转换。 编写多种分辨率的单一二进制代码是完全可能的。 我们有一个设备错误数据库，以便它可以通过平台 ID 检测设备，然后生成一系列标志来标记哪些错误被标记。 例如，大多数（如果不是全部）Motorola Brew 手机都有一个错误，即来电不会中断应用程序，直到您接听电话，因此我使用 TAPI 来监视来电并生成 hideNotify 事件（因为我们是模拟 Java，尽管生成的代码是纯 C++）。 我在运行时对 Brew 版本进行了一些检查，如果是 Brew 2 而不是 Brew 3，则禁用某些 API。3D
类型的游戏更容易使分辨率独立，因为您在软件中进行缩放。
另外还有 2 个独立的声音 API：IMEDIA 和 ISOUNDPLAYER，ISOUNDPLAYER 是较旧的 API，所有设备都支持，但没有那么多设施（您只能使用 IMEDIA 进行多通道音频）。 我创建了一个 IMEDIA 对象，如果无法获取 IMEDIA 对象，它将回退创建 ISOUNDPLAYER 对象。
完全通用构建的问题在于，功能上存在很大差异，因此值得进行一些构建，较旧的设备只有不到 1MB 的堆（并且屏幕尺寸较小），然后你会得到很多6MB+（176x204 或更大）。
使用 Brew，您确实拥有一组相当一致的键值（与 Java 不同），尽管一些新设备是触摸屏（并且您必须处理指针输入）和旋转屏幕。
还有一些旧的诺基亚手机使用大端模式，这意味着这些文件与普通的 mod 文件不同（除非您想编写一些非常酷的汇编语言前缀头来解码文件）
I wrote a J2ME to Brew conversion that is used at Javaground. It is quite possible to write multiple resolution, single binary code. We have a database of device bugs so that it can detect via platform id the device and then generate a series of flags which mark which bugs are tagged. For example most (if not all) of the Motorola Brew phones have a bug where an incoming call does not interrupt the application until you answer the call, so I use TAPI to monitor for an incoming call and generate a hideNotify event (since we are emulating Java, although the generated code is pure C++). I do some checks at runtime for Brew version, and disable certain APIs if it is Brew 2 rather than Brew 3.
3D type games are easier to make resolution independent since you are scaling in software.
Also there are 2 separate APIs for sound, IMEDIA and ISOUNDPLAYER, ISOUNDPLAYER is the older API and is supported on all devices but doesn't have as many facilities (you can only do multichannel audio using IMEDIA). I create an IMEDIA object, and it will fall back to create an ISOUNDPLAYER object if it can't get the IMEDIA object.
The problem with a totally universal build is that there is a big difference in capability, so it can be worth having a few builds, the older devices only have under 1MB of heap (and a small screen size), and then you get a lot with 6MB+ (176x204 to larger).
With Brew you do have a fairly consistent set of key values (unlike Java), although some of the new devices are touch screen (and you have to handle pointer input) and rotating screens.
There are also some old Nokia phones that use big endian mode which mean the files are not the same as the normal mod files (UNLESS you want to write some REALLY cool assembly language prefix header that decodes the file)