Huawei today announced HongMeng OS open source, as after seeing live most of the developers, with a sigh, the world of technology becomes really fast, and huawei architecture ability, mobile phones of a few large ability such as shooting of abstracting, make big xinjiang unmanned aerial vehicle (uav) camera, this idea is very good, with more and more portable electronic equipment, cross-platform, Distributed operating system is an important direction in the future.

On the other hand, the company has a team recently working on a voice room app that uses flutter at the UI level and did a share just before the first version was completed. Take meeting notes, memos.

Got some potholes

  • Naming conventions for file names

Because it was my first time to do flutter project and my team mates didn’t have enough development experience, I didn’t think much about other things besides meeting the needs. Everyone thought little about creating DART files. Of course, choosing a name was also a professional thing, because a good name decided the life of app.

Dart, but if login involves some verification, such as popup, verification code input, third-party login, mobile phone login, password login, etc., then login does not meet the requirements. The need to split login’s other modules is not well thought out in this area.

  • Memory problems

The Flutter starts with a hundred megabytes of memory. There are solutions that reduce the memory partially, but also risk crashing. This is an internal implementation of the Engine.

The internal implementation of UIImage does not size the Image cache. Now, for example, when the Image memory usage reaches 100M, it automatically reclaims part of the memory. The usage mode can also be based on the path loading path. So when it’s loaded, it’s released. Development of this problem is actually controllable.

  • The inclusion size

By default, the engine of Flutter has an additional size of 10 MB +. The problem is not big or small. Because it is an overseas project and many low-end models abroad, the size of this engine is inevitable, which should be solved at least in the view of the leader. Although many developers are reluctant.

  • Classification of log

At a certain level of complexity in a native development project, log analysis is necessary, but log generation is added when writing code to provide the only way to analyze online problems later.

There is little planning for log classification within FLUTTER, especially for small projects. Currently, flutter logs are mixed with the original logs. If the project becomes larger, tracking online problems will definitely be troublesome in the future.

Simply put, the FLUTTER log should be placed in a separate file. The format is similar to the native format: time + file name + line number + method name + Tag +log content

  • Collapse to collect

The flutter crash differs from its native one. Instead of crashing, the flutter crash appears white or red, forcing the user to kill the process. Such crash analysis systems are currently available, but do not meet company standards. The company wanted a standard that crashes would be reported automatically to the company’s internal crash system, with stack information, and the ability to assign bugs to the right person with one click. Being outside the company system is bad news on a project management level, after all.

  • Performance FPS, CPU, GPU, and power consumption

It’s all about fluidity. Cross-platform is the advantage of Flutter.

But also that’s all right, don’t too boast, these are the cliches, but its CPU, gpu, power consumption for simple app, of course, no problem, but involves the audio and video, these programs, it is a problem, native to flutter is the problem, the problem is not the language, but in the analysis of incomplete tool side, Performance is a good choice, but for those who are used to native performance measurement like Instrument, flutter feels weak.

For one pain point, audio on the iphonex consumes 35% power in half an hour, how to check on the flutter. The chicken thief’s solution is to leave it to the SDK to check. How to check if these SDK modules are written with FLUTTER in the future?

  • Event notification processing is chaotic

Both EventBus and Stream handle event sending and receiving. Everyone also has their own way, which before there was no unified standard writing method, resulting in confusion. Cross module problems currently have some good solutions in the direction of flutter, such as fish redux for idle fish

  • Cross-module encapsulation issues

There are a lot of flutter codes, so we need to consider reuse, precipitation some things out, encapsulation and cross-module, decoupling is the ultimate problem, actually has nothing to do with language, learn from industry experience, decoupling is to abstract again and again, different ideas, different writing method. The plug-and-pull pattern idea should abstract out the component, provide a method to register, provide a method to unregister, and provide a method to fetch. Each module follows some protocol.

  • Other projects and SDK’s Flutter plan

An AUDIO and video SDK doesn’t have to be just this SDK, it actually relies on other SDKS, such as logging, statistics, face recognition, and other third parties. Of course it is not practical to use all of flutter. At present, the company has the intention to partially implement a slow flutter, but the process will be long and the effect will not be ideal.

However, for the new app, flutter can be used without suspense, which is an advantage in terms of cost. On the other hand, flutter does not lose performance, which means that it costs less to do the same thing. Of course we’re happy to see it happen.

  • The follow-up plan

In order not to lose performance, the flutter can no longer be relied on to do superficial things like UI. You have to go further, reduce package size, reduce memory, increase CPU efficiency, and so on.