Weight Loss App Program

Write in front

• Recent company demand is not much, just study the App slimming method, wrote a little summary.

• If you do not know the following questions, you may wish to look at the article.

• What are the benefits of using the. xcassets?

• Will @1x, @2x, and @3x be built into the installation package together?

• What is the difference between PDF and @1x, @2x, and @3x?

• If I have a control of ten X 10 and a control of x 50, how many PDFs does the artist need to make?

• What is Iconfont? What is the difference between PDF and Iconfont?

• How does the start diagram open correctly?

• How much packet volume will be increased by using Swift or mixing?

• Install smallest or Coding fastest?

Analysis

• Before we lose weight, we need to analyze what we can do first. (Take Yep as an example)

Yep is an excellent Swift open source software.

Https://github.com/CatchChat/Yep

Directory Partitioning

• The weight of the App is primarily for the installation package, and the installation package in IOS is a compressed package that ends in. IPA. We can get this. IPA for analysis via iTunes download.

A little tidying up, can be broadly divided into the following categories.

• Resource level:

• Assets.car: all. Xcassets compressed packages in the project

• Image: Picture resource file

• Video && audio: audios or videos.

• Code level:

• Internationalization: International adaptation of String ===> 89K

• Xib && storyboard:xib and Storyboard compiled files.

• YEP: Project executable file.

• Frameworks:embedded frameworks, the dynamic library used in the project

• Other:

• Other: Configuration file

• Plugins:yepshare, a shared plug-in.

The sorted directory

• Although YEP can not represent all the apps, but after Yep's IPA analysis, it can be summed up that the installation package for an App is thin and can start at two levels, both at the resource level and at the code level.

Resource Level

• Before talking about the resource level, I hope we can reach a consensus that the so-called resource file refers to pictures, video, audio.

• Remote: Place the resource file on the server and download it as needed after the user has downloaded the App.

• Local: The resource file is integrated into the installation package.

Remote

• In the way of Remote, if the strategy (such as caching), then theoretically, we can put the non-necessary resource files on the server, so that the resource compression rate reached 100%. This means that the installation package does not have any non-mandatory resource files.

• A resource file is required: such as the app icon, the configuration picture for the start diagram.

• Apple's On-demand Resources (http://benbeng.leanote.com/post/On-Demand-Resources-Guide) The idea of loading resources on demand provides us with a way to load resources in stages, specifically not to expand the description, you can click on the previous link to view. But although the level, tag this way to load resources on demand, but Apple's server for Chinese users is really slow, so it is not recommended to take this approach for the time being. You can implement this strategy on your own server to load images.

ODR mode

ODR Cache Policy

Local

• Of course, it is obviously unrealistic to put non-mandatory resource files on the server, and for some required resource files, you need to integrate the resource files into the installation package.

• Mandatory resource file: The APP will definitely be used when it's installed.

Local Integration Method

• Create group and Create folder references

• These two are actually just drag the resource file in, after Xcode packaging, all the pictures in the executable file under the same directory. This is also the way many old apps or some of the apps are currently used.

• . xcassets

• This is the Apple after Xcode 5, recommended that we use the image management method, provides image rendering, stretching mode mode, model adaptation and other functions. All. xcassets files are placed in a Assets.car file after Xcode is packaged.

The Local development Use method enumerates the analysis.

• General APP image built-in method

• Using drag, the picture contains @1x, @2x, and @3x.

• With drag, the picture contains only @2x and @3x.

• With drag, the image contains only @2x or @3x.

• Using the. Xcassets way, the picture contains @1x, @2x, and @3x.

• Using the. Xcassets method, the image contains only @2x and @3x.

• Using the. Xcassets method, the image contains only @2x or @3x.

• Using the. Xcassets way, the picture uses a PDF.
  (There may be other ways, I hope you can tell me.) )

• Drag the way

• First of all, @1x, @2x and @3x are mainly designed to adapt to different PPI of the machine and made a strategy. @1x is primarily designed to match a non-Retina screen before the iphone 4, @2x is designed to fit a non-plus iphone device, @3x is a 3 * 3 pixel mobile phone that fits a point.

• Because the IPhone 4 before the basic App will not be used to adapt, so generally will be deleted, so there is a "drag the way, the picture contains only @2x and @3x" way. But if you only provide a picture, for example you only provide a picture of @3x, IOS system on IPhone 7 can not find @2x image, will go to find @3x or @1x, and then stretch according to the actual resolution, and finally put the pixel on the screen. So, with the ability to accept the performance cost of finding and stretching, we can just use a common picture, so we have a "drag-and-drop, picture containing @2x or @3x" way.

• To a 14M picture resources (including @1x, @2x, @3x), if all the pictures to remove @1x can reduce about 1M, to remove the @2x can remove 4M or so. Therefore, the use of "drag the way, the picture contains @2x or @3x" the way although the loss of a bit of performance, a single approximate picture resources about 35% reduced.

• Using the. Xcassets approach

• As we all know, the use of "drag, picture contains @2x or @3x," the way the picture resources probably decreased by about 35%, but slightly lost a bit of performance. Is there any way to reduce this performance drain?

• "Luckily", Apple finally realized the problem in IOS 9, and then offered something called App slicing (shown). App slicing is basically the App Store will be based on different devices to prepare different installation packages (app variant), each installation package (app variant) only the corresponding size of the picture, such as the IPhone 6 to download, will only download to @2x pictures of the installation package ( App Variant). But the premise of this function is that the picture needs to be placed in the. Xcassets to manage.

APP slicing

• So, at present, many apps adopt the ". Xcassets way, the picture contains only @2x or @3x" is meaningless, especially when you are not fit for IOS 8, you are forced to reduce the performance of the app. Of course you have to think that for 8% of non-IOS 9 users to reduce the size of the app installation package to reduce the other 92% of users of the app running performance is no problem, then you can take the above way.

• About PDF

• I first saw it in this blog post (http://martiancraft.com/blog/2014/09/vector-images-xcode6/), and of course YEP is the same way. Basically delete the pictures of @2x and @3x, then replace them with vector PDF and put them into the. Xcassets in the end.

• In the process of packaging, Xcode generates graphs of @1x, @2x, and @3x based on the size of your vector pdf map. For example, if your PDF is 4545px, Xcode will generate the following 3 png:4545px, 9090px, 135135px, and finally Assets.car in the compilation. So using @1x, @2x and @3x and PDF two ways is essentially the same.

• There are a lot of people here who have a misunderstanding, for example, in the App there is a ten pt and a imageView of the same icon. Many people will think that doing one is enough because PDF is a vector image. However, it is necessary to have two PDFs of ten PX and three px, because only one is used, and the other one is the product of a PDF of 10px.

• About compression issues.

• I use Tinypng to compress, should be with the minimum occupancy to achieve the most suitable effect. But in fact, Xcassets will do a part of the compression for you. As shown in the following:

Compression process

• The compression of the. Xcassets should also be processed for the image, which is why 840KB compresses the 81.5%,assets.car without reducing that much.

• It has also been found in the experiment that using some of the compression tools does not seem to have much practical effect, it is also possible because Xcode did some processing when packaging.

Start diagram

• Start diagram in a project resources accounted for actually quite large, before seen a project 6 start diagram about 5 m, the largest is 2M.

• ipad 2 and ipad Mini (@1x): 768 x 1024

• ipad and ipad Mini (Retina @2x): 1536 x 2048

• IPhone 4s (retina @2x) 640 x 960

• IPhone 5 (@2x): 640 x 1136

• IPhone 6 (@2x): 1334 X

• IPhone 6 Plus (@3x): 1242 x 2208

• But since Launchscreen.storyboard came out there's no need to do so many more. Just set the start diagram to Launchscreen.storyboard and then set a imageView on the Launchscreen.storyboard. Finally, you can get a PDF of the start-up diagram.

Iconfont

• First of all, this thing is estimated that many people do not know, I am also at the table at the remind of students to know that the original IOS can also be used Iconfont. This is the first thing for the web design, mainly because the size of the page directly affect the loading speed, so in the compression of even small icon are not spared, of course, there is a main purpose is to reduce the number of requests, because if it is a picture, a picture is a request.

• The specific effect can be seen by using Iconfont to reduce iOS app volume (http://johnwong.github.io/mobile/2015/04/03/using-icon-font-in-ios.html) this article.

• Although it doesn't look like much, it can be a good way for some of the more sophisticated companies to try it out.

Mid-term, PDF and iconfont two are vector concepts, but Iconfont requires only one iconf for the entire App regardless of how many sizes it takes, but PDFs may require multiple.

HTML 5

Some of the features of the APP can be implemented in HTML5 + WebView way. And the HTML 5 This can be done in several ways to optimize the step-by-step:

• Let the front-end to a minimal package built into the App, remove useless code, code obfuscation compression and so on.

• Make all of your images Remote.

• All pages are Remote.

Other

• Of course, also pay attention to the problem of duplication of resource files. There are several main problems in resource file duplication: The same name, the same name and/or similar content.

• For the same name problem, you can change the original drag to. xcassets, he will automatically manage the same name of the picture. And get rid of the excess.

• The same name differs/resembles: You can use the Duplicate Photos tool

• Another problem is that the resource file is useless, but it takes up space, and you can use Lsunusedresources to remove the unused files from your code. Of course, there may be a mistake to delete, such as an array of images loaded, this tool is not recognized.

Code Level Install smallest VS. Coding fastest

language Selection

• I prefer to use Swift to write apps, though. But from the perspective of App slimming, Swift is not recommended, whether it's pure swift or mixed. The reason is simple. Take a look at the following figure:

• This is a collection of dynamic libraries with swift code to support Swift, around 10M. If you use Objective–c, you don't need this stuff at all.

• Of course, I can accept the installation package big 10M to write with Swift.

Database selection

• This is also the problem I found when analyzing Yep's third-party library, because Yep is using Realm, which is said to be the best mobile database for performance at the moment. However, in the three-party library can be seen, Realm support accounted for a large proportion, around 8M. But if you use FMDB, you only need 192KB, and coredata is almost negligible. Here is the section.

FMDB

Realm

Realmswift

MRC VS. ARC

• The first thing to see in this article in bang is that using an arc will cause the executable to be 10% larger than the MRC. I didn't believe it at first, but after I tested the 1.0 version of Sdwebimage, ARC added 14% + to the MRC executable program. So the MRC is smaller than the ARC compiled into an executable file, and the specific test method can go to his blog to see that there is no repetition here.

Summarize

• First analyze the cause of the previous problems:

• Swift && Realm: First Swift is unstable, so the supported dynamic libraries are not integrated into the system's "Dyld shared Cache". While Realm was not developed by Apple itself, the supported dynamic libraries were not integrated into the system's "Dyld shared Cache". So it's built into the APP, and these two features need to be written a lot of code to implement, so the capacity is very large, resulting in the appearance of these two things accounted for a lot of "useless" capacity. (Ps. About the library in iOS, you can go to my notes to see ~)

• Arc: Because arc is called automatic reference counting, the way he implements it is that Xcode automatically gives you the code of the memory tube at compile time, but the machine is not smart after all, and Xcode adds a lot of useless code in many cases, which is why the bottom of the arc is faster than MRC, But the actual performance is sometimes less than MRC, and because of the addition of a lot of useless code, the ARC will eventually compile a package larger than MRC.

• Summing up some of the previous questions, it boils down to the question of install smallest VS. Coding fastest. Many times in order to pursue faster coding speed, there will always be a loss, but in my opinion these things worth it, or why we do not use C instead of objective-c or the assembly instead of C?

Bitcode

• Bitcode is an intermediate form of code that is compiled by a program. Programs that contain Bitcode configuration will be compiled and linked on the App Store. Bitcode allows Apple to re-optimize the binaries of our program at a later stage without requiring us to resubmit a new version to the APP Store.

• When we submit a program to the APP store, Xcode compiles the program into an intermediate representation (Bitcode). The APP store then compiles the bitcode into an executable 64-bit or 32-bit program.

• So, in this way, we can do architecture-level app slicing.

Tips

Combined with the above, plus the Bang Blog (http://blog.cnbang.net/tech/2544/), I've summed up a few Tips. The more forward I feel the more I need to optimize.

Tip 1: Remove duplicate, useless resource files to resolve name duplication issues.

Tip 2: Picture used. xcassets Management without regard to @1x\@2x\@3x issues. The last resort is to use the method of drag, combined with a certain strategy to package thin body.

TIP 3: Images use PDF precedence over PNG, because Xcode will help you with the rest of the task.

TIP 4: Use Tinypng to compress PNG images. The video can be compressed by resolution using software such as Final cut. Audio reduces the bit rate.

Tip 5:icon using Iconfont

TIP 6: A non-mandatory resource file can be placed on its own server, but the required resource file needs to be built into the installation package.

Tip 7:html 5 requires the image to be either remote or the entire HTML 5 page is set to be remote.

Tip 8:build settings->optimization leve release version should choose Fastest, smalllest

Tip 9: Turn on Bitcode

The following are almost impossible to do optimization Tips

Tip 10: Remove useless code, control class name, method name length, redundant string as much as possible

Tip 11: If you want, don't use Swift, don't use realm and even try not to use OC

Tip 12:MRC is smaller than when ARC is compiled into an executable file.

MORE: After work, write a few notes, if necessary can be seen on my GitHub.

Https://github.com/Damonvvong/iOSDevNotes

Reference articles

• APP thinning

  Http://t.cn/RVJ8kNd

• Confirmed:objective-c ARC is slow. Don ' t use it! (Sarcasm off)

  Http://t.cn/zYkzifW

• 4 XCODE ASSET CATALOG secrets need to KNOW

  Http://t.cn/RVJR2c0

• Use Iconfont to reduce iOS app volume

  Http://t.cn/RVU7B3h

• iOS executable Slimming method

  Http://t.cn/RZgnVL3

Weight Loss App Program